Cursor 3.8 เปิด Automations — สั่งงานเอเจนต์ด้วยภาษาคน ผูก trigger จาก GitHub/Slack แล้วให้รันเองบนคลาวด์

ในรอบสองวัน (17–18 มิถุนายน 2026) Cursor ปล่อยอัปเดตติดกันสองเวอร์ชันที่ดันเครื่องมือให้ขยับจาก “ผู้ช่วยเขียนโค้ดในเอดิเตอร์” ไปเป็น แพลตฟอร์มรันเอเจนต์แบบ async เต็มตัว ไฮไลต์คือ Cursor 3.8 ที่เปิดฟีเจอร์ Automations — สั่งให้เอเจนต์ทำงานเองตามเงื่อนไขที่เรากำหนด โดยอธิบายเป็นภาษาคนล้วนๆ ไม่ต้องเขียน config

สำหรับนักพัฒนาที่ใช้ AI coding agent อยู่แล้ว นี่คือก้าวจาก “พิมพ์สั่งทีละครั้ง” ไปสู่ “ตั้งให้มันคอยทำงานให้เองเมื่อมีอะไรเกิดขึ้นในโปรเจกต์”

Automations: บอกเป็นภาษาคน แล้วให้ trigger ลั่นเอง

ใน 3.8 พิมพ์คำสั่ง /automate ใน session ของ agent บนเครื่องได้เลย แล้วอธิบายงานที่อยากให้เกิดซ้ำๆ เป็นประโยคธรรมดา Cursor จะแปลงเป็น automation ให้ จุดที่ทำให้มันใช้งานจริงได้คือ ตัวจุดชนวน (trigger) ที่ผูกกับเหตุการณ์ในเวิร์กโฟลว์จริง:

• GitHub — 5 trigger ใหม่: คอมเมนต์ใน issue, คอมเมนต์รีวิวใน PR, การ submit รีวิว, อัปเดตใน thread และ workflow ที่รันเสร็จ
• Slack: ใช้การ react อีโมจิเป็นตัวสั่งงาน automation ได้

แปลว่าเหตุการณ์อย่าง “มีคนรีวิว PR แล้วขอแก้” หรือ “CI รันเสร็จ” กลายเป็นชนวนให้ agent ลงมือต่อโดยไม่ต้องมีคนมานั่งกดเอง

Cloud agent ที่ลงมือทำ “บนเครื่องของมันเอง”

อีกหมุดที่น่าสนใจของ 3.8 คือ cloud agent ที่ถูกจุดโดย automation สามารถใช้ “คอมพิวเตอร์ของตัวเอง” เพื่อผลิตเดโมหรือ artifact ของงานได้ — ไม่ใช่แค่แก้โค้ดแล้วเปิด PR แต่รันแอป ถ่ายผลลัพธ์ หรือประกอบของให้ดูได้ในตัว ต่อยอดตรงจาก Cursor 3.7 (17 มิ.ย.) ที่ย้าย cloud agent เข้ามาอยู่ใน Agents Window ของแอปเดสก์ท็อป และเพิ่มความสามารถสำคัญ:

• เซ็ต dev environment บนคลาวด์ได้ในไม่ถึง 10 นาที — เฝ้าดู agent ลง dependency ผ่าน terminal ที่แชร์ร่วมกัน แล้วเก็บสภาพแวดล้อมเป็น snapshot ใช้ซ้ำ ให้ครั้งต่อไปสตาร์ตเร็วขึ้น
• /in-cloud สำหรับแยกงานไปทำใน VM ของตัวเอง (cloud subagent)
• ส่งต่อ session ระหว่างเครื่อง local กับคลาวด์ ได้นิ่งขึ้น

รวมกันแล้วภาพคือ: เขียนนิยามงานบนเครื่อง → ส่งขึ้นไปรันบนคลาวด์แบบ isolate → ผูกให้ลั่นเองตามเหตุการณ์ → ได้ artifact กลับมา

มุมมอง AI Curator

ทิศทางของ Cursor 3.7–3.8 บอกชัดว่าสนามแข่ง AI coding agent กำลังย้ายจาก “ใครเขียนโค้ดในเอดิเตอร์ได้เนียนกว่า” ไปสู่ “ใครรันเอเจนต์แบบไม่ต้องเฝ้าได้ดีกว่า” ซึ่งเป็นโจทย์เดียวกับที่ Claude Code, GitHub Copilot และ Antigravity กำลังชนกัน การเอา trigger จาก GitHub/Slack มาเป็นชนวน คือการยอมรับว่าที่ที่งานจริงเกิดไม่ใช่ในเอดิเตอร์ แต่อยู่ใน PR, รีวิว และแชตของทีม — ใครเชื่อมจุดเหล่านั้นเข้ากับ agent ได้ลื่นที่สุดจะกินตลาด

สำหรับทีมไทยและ SEA มีสองมุมต้องชั่ง หนึ่ง — Automations ที่สั่งด้วยภาษาคนลดกำแพงให้ทีมเล็กตั้ง agent อัตโนมัติได้โดยไม่ต้องมี DevOps มาเขียน pipeline เอง เข้าทางทีมสตาร์ตอัปและเอเจนซีที่คนน้อยแต่โปรเจกต์เยอะ สอง — แต่ “cloud agent ที่รันเองตาม trigger บนเครื่องของมัน” คือการมอบสิทธิ์ให้ระบบลงมือกับโค้ดเบสและรันโค้ดโดยไม่มีคนกดยืนยันทุกครั้ง องค์กรที่ดูแลข้อมูลลูกค้าควรวาง guardrail ตั้งแต่วันแรก: จำกัดว่า automation ตัวไหนแตะ repo ไหนได้, ใคร approve ก่อน merge, และ trigger จาก Slack/GitHub ที่ “ใครก็กดได้” จะกลายเป็นช่องให้สั่งงาน agent โดยไม่ตั้งใจหรือไม่ ยิ่ง agent ทำงานเองได้มากเท่าไหร่ การกำหนดขอบเขตให้ชัดยิ่งเป็นงานที่เลี่ยงไม่ได้

แหล่งข่าว:

• Cursor Changelog — 3.8 Automations & 3.7 Cloud Agents
• Cursor Docs — Automations (triggers, /automate, GitHub & Slack)