Cursor Cloud Agents: Agent เก่งแค่ไหนก็แพ้ ถ้าระบบหลังบ้านไม่พร้อม

Cursor เผยแพร่บทความ What we’ve learned building cloud agents เมื่อวันที่ 21 พฤษภาคม 2026

บทความนี้น่าสนใจเพราะไม่ได้ขายฟีเจอร์แบบปกติ แต่เล่าบทเรียนจากการสร้าง cloud agents จริงตลอดหนึ่งปี

ใจความสำคัญคือ:

cloud agent ไม่ใช่ local agent ที่ย้ายไปอยู่บน server เฉย ๆ

เมื่อ agent รันบน VM ของตัวเอง ทำงานพร้อมกันหลายตัว ทำงานยาวขึ้น และมีสิทธิ์เข้าถึง repo, dependency, network, secret, tools, PR และ logs มากขึ้น มันเริ่มต้องการระบบหลังบ้านแบบที่บริษัทใช้กับคนและ workload จริง

นี่คือจุดที่ agent เปลี่ยนจาก “ผู้ช่วยใน editor” ไปเป็น “operating layer” ของงาน software

1) Development environment คือ product

Cursor บอกว่าปัจจัยใหญ่ที่สุดของคุณภาพ cloud agent คือ agent ต้องมี development environment ที่ครบเหมือน developer คนหนึ่ง

ตอน agent ทำงานบนเครื่องเรา มันได้ environment หลายอย่างฟรี:

• repo ที่ clone ไว้แล้ว
• dependency ที่ติดตั้งแล้ว
• credential บางอย่างที่ตั้งไว้
• command และ test ที่เราใช้ประจำ
• local service หรือ API ที่เข้าถึงได้

แต่พอ agent ไปอยู่บน cloud สิ่งเหล่านี้ต้องถูกสร้างใหม่

ปัญหาคือถ้า environment ไม่ครบ ผลลัพธ์อาจไม่พังแบบชัด ๆ

มันอาจแค่ทำงานคุณภาพต่ำลง, verify ไม่ได้, run test ไม่ครบ, หรือใช้ workaround แปลก ๆ แล้วคนไปโทษ model ว่าไม่เก่งพอ

สำหรับทีมที่เริ่มใช้ cloud agents นี่คือบทเรียนสำคัญ:

อย่าคิดว่า “เลือก model เก่ง” แล้วจบ

ต้องมี environment spec ที่ชัด:

• repo ไหนอยู่ใน scope
• dependency ติดตั้งอย่างไร
• test command คืออะไร
• service ไหนเข้าถึงได้
• secret ไหนใช้ได้
• network ออกไปที่ไหนได้
• ถ้า setup fail ให้เตือนอย่างไร

ถ้าไม่มีชั้นนี้ agent จะทำงานเหมือนพนักงานใหม่ที่ถูกโยนเข้าบริษัทโดยไม่มี laptop, ไม่มีสิทธิ์เข้า system, ไม่มีเอกสาร onboarding และไม่มีคนบอกว่าคำว่า done วัดจากอะไร

2) Cloud agent ต้องมี durable execution

บทเรียนที่สองคือ cloud agents ต้องทำงานได้นานและรอดจากความไม่เสถียรของ infrastructure

Cursor เล่าว่างาน cloud agent อาจใช้เวลาหลายชั่วโมง หลายวัน หรือหลายสัปดาห์ และอาจเจอปัญหาเช่น inference provider outage, pod ถูกเปลี่ยน, EC2 node ล่ม, หรือ VM ต้อง hibernate/resume

นี่ต่างจาก local agent บน laptop

ถ้า local agent ค้าง เราเห็นทันที

แต่ถ้า cloud agent ค้างในระบบหลังบ้าน เราอาจไม่รู้จนกว่าจะกลับมาดูอีกหลายชั่วโมง

Cursor จึงย้าย agent loop ไปอยู่บน Temporal เพื่อได้ primitive อย่าง retry, scheduling, durability, และการรอดจาก node failure

มุมที่ธุรกิจควรจำ:

งาน agent ที่ยาวเกินหนึ่ง prompt ต้องคิดเหมือน workflow ไม่ใช่ chat

ถ้า agent ทำงานสำคัญ เช่น CI autofix, PR generation, migration, report automation หรือ data ops ต้องตอบคำถามเหล่านี้ได้:

• retry อย่างไร
• timeout ตรงไหน
• checkpoint เก็บเมื่อไร
• resume จากจุดไหน
• error แบบไหนต้องถามคน
• error แบบไหนให้ agent แก้เอง
• proof สุดท้ายเก็บไว้ที่ไหน

ไม่มี durable execution ก็เท่ากับให้พนักงานดิจิทัลทำงานยาว ๆ โดยไม่มี task manager

3) แยก agent, machine state, conversation state

อีกจุดที่ดีมากในบทความคือ Cursor แยกสามสิ่งออกจากกัน:

• agent loop
• machine state
• conversation state

นี่เป็นเรื่องสำคัญมากเมื่อ agent เริ่ม spawn subagent, ย้ายจาก local ไป cloud, หรือทำงานบน VM หลายแบบ

ถ้าทุกอย่างผูกกับเครื่องเดียวหรือ thread เดียว ระบบจะเปราะทันที

แต่ถ้าแยก state ได้:

• agent loop รันบน workflow engine ได้
• VM hibernate/resume ได้
• subagent ใช้ pod คนละแบบได้
• conversation stream retry ได้โดยไม่ทำให้ UI เห็นข้อมูลผิด
• machine lifecycle ถูกจัดการแยกจากประวัติการคุย

สำหรับองค์กร นี่คือ pattern ที่ควรเอาไปใช้กับ agent runtime ทุกตัว ไม่ว่าจะใช้ Cursor, Claude Managed Agents, Codex, Gemini stack หรือระบบ internal

อย่าเก็บทุกอย่างไว้ใน “แชตเดียวที่จำทุกอย่าง”

ให้แยก:

• task state: งานอยู่ขั้นตอนไหน
• execution state: รันอยู่ที่ environment ไหน
• conversation state: ผู้ใช้และ agent คุยอะไร
• artifact state: diff, PR, log, report, screenshot, test result อยู่ที่ไหน
• approval state: ใครต้องตัดสินใจอะไร

ถ้าแยก state ดี ระบบจะ recover, audit, handoff และ improve ได้ง่ายขึ้นมาก

4) Harness ที่ดีรู้ว่าเมื่อไรควรถอย

Cursor เล่าว่าในช่วงแรก harness ไม่ไว้ใจ agent มากนัก จึงบังคับหลายอย่าง เช่น double-check งานทุกครั้ง, force commit, push ให้เอง

แต่เมื่อ model เก่งขึ้น Cursor เริ่มย้าย logic บางส่วนออกจาก harness ไปเป็น tools ที่ agent ควบคุมเอง

นี่เป็นบทเรียนที่ละเอียดมาก

ระบบ agent ที่ดีไม่ใช่ระบบที่ hardcode ทุกอย่าง

แต่ก็ไม่ใช่ระบบที่ปล่อย agent ทำอะไรก็ได้

คำถามจริงคือ:

อะไรควรเป็น policy ของระบบ และอะไรควรเป็น decision ของ agent

ตัวอย่าง:

• policy: ห้าม deploy production เอง
• agent decision: เลือก test ที่เหมาะกับงาน
• policy: secret ห้ามถูกพิมพ์ลง log
• agent decision: จะอ่าน docs หรือ grep code ก่อน
• policy: PR ต้องมี proof
• agent decision: proof แบบไหนเหมาะกับ diff นี้

สำหรับทีมไทย ผมแนะนำให้เริ่มจาก policy 5 ชั้น:

1. Scope: agent แตะ repo/folder/service ไหนได้
2. Permission: read/write/network/secret แยกตามงาน
3. Approval: งานไหนต้องหยุดถามคน
4. Proof: ก่อน done ต้องมีหลักฐานอะไร
5. Rollback: ถ้าผิดจะย้อนอย่างไร

ถ้าไม่มี policy พวกนี้ agent จะเร็วขึ้น แต่ blast radius ก็ใหญ่ขึ้นตาม

5) Self-healing environment คือทิศทางถัดไป

ช่วงท้าย Cursor พูดถึง self-healing agent environments

แนวคิดคือแทนที่จะเลือกระหว่าง “จับมือ agent ทุกขั้น” กับ “ปล่อย agent ไปเองหมด” ระบบควรให้ agent มีเครื่องมือสำหรับเข้าใจปัญหารอบตัว

เช่น:

• secret หาย
• network ถูก block
• dependency ไม่ครบ
• environment version ผิด
• test service ไม่พร้อม

แล้ว agent ควร report หรือแก้บางส่วนเองได้ภายใต้กรอบที่กำหนด

นี่เป็นทิศทางที่สำคัญ เพราะถ้า agent ต้องรอคนแก้ environment ทุกครั้ง cloud automation จะเสียแรงไปเยอะ

แต่ self-healing ต้องมาพร้อม guardrail

ให้ agent แก้ setup dependency ได้ อาจโอเค

ให้ agent เปิด network egress เองหรือเพิ่ม production secret เอง ไม่ควรเริ่มตรงนั้น

6) บทเรียนสำหรับทีมไทย

ถ้าทีมของคุณเริ่มใช้ cloud agents หรือกำลังจะเริ่ม ผมจะไม่เริ่มจากคำถามว่า “ซื้อ tool ไหน”

ผมจะเริ่มจากตารางนี้:

คำถาม	ทำไมสำคัญ
งานแรกที่ให้ agent ทำคืออะไร	เลือกงานเล็กที่ proof ชัดก่อน
Environment มีอะไรบ้าง	Agent ทำงานไม่ได้ถ้า run/test/verify ไม่ได้
Secret อยู่ตรงไหน	อย่าให้ raw secret หลุดเข้า context/log
Network ไปไหนได้	ลด blast radius ตั้งแต่วันแรก
งาน resume ได้ไหม	Cloud agent ต้องรอดจาก outage และเวลายาว
ใคร approve PR/deploy	Public/production action ต้องมีคนหรือ policy ชัด
วัดคุณภาพอย่างไร	อย่าวัดแค่จำนวน task ที่ agent ปิด

งานเริ่มต้นที่เหมาะ:

• สรุป failing CI พร้อมลิงก์ log
• เปิด PR แก้ lint/test เล็ก ๆ
• ตรวจ release note ของ dependency
• สร้าง draft migration plan
• หา flaky test pattern
• สรุป issue triage รายวัน

งานที่ยังไม่ควรเริ่มถ้าระบบไม่พร้อม:

• deploy production
• แก้ infra permission
• เปิด network/secret ใหม่
• run migration บน production database
• ส่งข้อความ public หรือ email จริง
• ตัดสินใจ pricing หรือ customer contract

7) มุมมองของผม

ผมว่าบทความ Cursor รอบนี้เป็นหนึ่งในสัญญาณที่ชัดว่า agent market กำลังขยับจาก “tool UX” ไปสู่ “agent operations”

ปีที่แล้วคนแข่งกันว่า agent ตัวไหนเขียนโค้ดเก่งกว่า

ปีนี้คำถามเริ่มเปลี่ยนเป็น:

• agent อยู่ใน environment แบบไหน
• งานยาว recover อย่างไร
• state ถูกแยกอย่างไร
• secret และ network คุมอย่างไร
• proof และ approval วิ่งในระบบไหน
• harness วัดคุณภาพและลด error อย่างไร

นี่เข้ากับภาพใหญ่ของ Data-Espresso มาก:

AI agent ที่ใช้งานจริงไม่ใช่เวทมนตร์

มันคือคนทำงานดิจิทัลที่ต้องมีโต๊ะทำงาน, สิทธิ์, เครื่องมือ, process, log, reviewer และ manager

ถ้าอยากให้ agent ทำงานได้ดีขึ้น อย่ามองแค่ model

ให้มองทั้ง operating layer ที่ทำให้มันทำงานได้ ตรวจได้ และหยุดได้ตอนควรหยุด