Cursor Agent SDK: เมื่อ Agent กลายเป็นโค้ดที่รีวิวได้ และ Deploy ได้ในคำสั่งเดียว

ถ้าถามว่า agent ที่ทีมผมใช้อยู่ "อยู่ที่ไหน" คำตอบที่ตรงที่สุดคือ กระจายอยู่ทุกที่ครับ

prompt ดี ๆ บางอันอยู่ในแชตของใครสักคน บางอันอยู่ในโน้ต บางอันถูกก๊อปไปแปะในอีกโปรเจกต์แล้วแก้ไปคนละทาง พอผลลัพธ์เริ่มเพี้ยน ไม่มีใครตอบได้ว่าเปลี่ยนอะไรไปเมื่อไหร่ ใครเปลี่ยน และเปลี่ยนแล้วดีขึ้นหรือแย่ลง สำหรับคนที่ดูแลทีม junior สี่ทีมอย่างผม นี่คือปัญหาเดียวกับโค้ดที่ไม่มี Git นั่นแหละ

ช่วงนี้ใน X มีหัวข้อที่ขึ้น trending เรื่อง Cursor ปล่อย Agent SDK ที่ขายไอเดีย "agent as code" ผมเลยตามไปอ่านของจริงจาก Cursor เอง ไม่ใช่แค่โพสต์สรุป

โพสต์นี้อยู่ในซีรีส์ Critical Thinking ครับ ต่อจากเรื่อง agent ตัวเดียวมักชนะทั้งฝูง ซึ่งจบด้วยคำว่า "ต้องวัด" คราวนี้เป็นคำถามต่อมาว่า ถ้าจะวัดและดูแล agent ให้จริงจัง มันควรอยู่ในรูปแบบไหน

จุดยืนของผมสั้น ๆ คือ agent as code เป็นทิศทางที่ถูก แต่การ deploy ง่ายขึ้นไม่ได้แปลว่าการตัดสินใจว่าควร deploy ง่ายขึ้นตาม

Cursor พูดอะไรจริง ๆ

แหล่งข้อมูลหลักมีสามชิ้นครับ คือ บล็อกเปิดตัว "Introducing the Agent SDK" (20 ตุลาคม 2026) changelog ของ Agent SDK และ หน้า docs บวกกับโพสต์ประกาศของ Cursor บน X ทั้งบล็อกและ changelog บอกว่าเป็น generally available แล้ว ไม่ใช่ beta

ใจความหลักที่ผมสรุปได้มีประมาณนี้

agent คือโปรเจกต์หนึ่งโฟลเดอร์ changelog อธิบายว่า instructions.md คือ prompt ไฟล์แต่ละไฟล์ใน tools/ คือ action ที่มี type หนึ่งอย่างที่โมเดลเรียกได้ skills/ เก็บขั้นตอนที่โมเดลโหลดเมื่อต้องใช้ mcp-connections/ เพิ่ม tool จาก MCP server และ channels/ กำหนดว่า agent รับและตอบข้อความจากที่ไหน ส่วน docs ใช้คำว่าพฤติกรรมของ agent ถูกนิยามด้วยโฟลเดอร์ของ Markdown กับ TypeScript ที่ผสมโค้ดแบบ deterministic เข้ากับการตัดสินใจของโมเดล

deploy ด้วยคำสั่งเดียว รัน agent-sdk deploy ในโฟลเดอร์โปรเจกต์ คำสั่งจะ build agent ให้ URL และสตาร์ทบน infrastructure ของ Cursor ส่วน secret กับ integration จัดการผ่าน dashboard ถ้าไม่อยากใช้ของ Cursor บล็อกบอกว่าแต่ละ agent รันเป็น Node process เดียว เอาไปใส่ container รันเองได้

มี eval กับ replay มาในตัว changelog อธิบายว่า eval คือการส่งข้อความที่กำหนดไว้ให้ agent แล้วตรวจว่ามันทำอะไรไปบ้าง คือเรียก tool ไหน ด้วย input อะไร และคำตอบหน้าตาเป็นแบบไหน รันด้วย agent-sdk eval ได้ทั้งบนเครื่องและใน CI และมีคำสั่ง agent-sdk github replay ที่แปลง pull request จริงเป็น webhook payload แล้วส่งให้ agent ถ้าใส่ --dry-run --fixtures-dir fixtures/ จะเก็บ payload ไว้เป็น fixture สำหรับ eval แทน

ปลุกได้จากหลายทาง ตาม changelog agent ตื่นได้จาก event ของ PR, comment และ CI บน GitHub, GitLab และ Bitbucket จากการ mention หรือ DM ใน Slack จาก webhook ของผู้ให้บริการไหนก็ได้ และจาก cron schedule

เป็นของที่ Cursor ใช้เอง บล็อกบอกว่านี่คือ framework เดียวกับที่ Cursor ใช้สร้าง managed agent ของตัวเองอย่าง Bugbot, Security Reviewer และ Rollouts และ init มี template ให้เริ่ม เช่น security reviewer, PR autofixer และ triager สำหรับ Linear หรือ Jira

ส่วนที่ผม ยืนยันไม่ได้ ก็ต้องบอกตรง ๆ ครับ หน้า docs ย่อยเรื่องราคา limits รูปแบบไฟล์ eval และรายละเอียดการ self-host ผมเปิดไม่ได้ตอนเขียน เลยไม่มีตัวเลขเรื่องค่าใช้จ่ายมาให้ และตอนที่เขียน ชื่อแพ็กเกจ npm ในหน้า docs กับใน changelog และบล็อกยังเขียนไม่ตรงกัน ใครจะลองติดตั้ง ให้เช็คหน้า docs ล่าสุดก่อนนะครับ อย่าก๊อปคำสั่งจากโพสต์สรุป (รวมถึงโพสต์นี้) ไปรันเลย

agent as code เปลี่ยนอะไร

ไอเดีย "เก็บ prompt ไว้ในไฟล์" ไม่ใช่เรื่องใหม่ครับ ใน repo บล็อกนี้เองผมก็เก็บ subagent สำหรับค้นข้อมูล เขียน และรีวิวบทความไว้เป็น Markdown ใน .cursor/agents/ สิ่งที่ Agent SDK เพิ่มเข้ามาคือทำให้ prompt, tool, ช่องทางรับงาน และ eval อยู่ในโครงสร้างเดียวกัน แล้วพาไปถึงการ deploy ได้ ผมว่ามันเปลี่ยนสี่เรื่องที่สำคัญกับคนคุมทีม

1. Versioning: agent มีประวัติแล้ว พอ instructions.md อยู่ใน Git ทุกการแก้ prompt คือ commit ที่มีคนเขียน มีวันที่ และ revert ได้ คำถาม "agent มันเริ่มตอบแปลก ๆ ตั้งแต่เมื่อไหร่" กลายเป็นคำถามที่ git log ตอบได้ ไม่ใช่การนั่งเดา

2. Review: prompt ต้องผ่าน PR เหมือนโค้ด นี่คือเรื่องที่ผมชอบที่สุด เพราะการแก้ prompt หนึ่งบรรทัดอาจเปลี่ยนพฤติกรรมมากกว่าการแก้โค้ดร้อยบรรทัด แต่ที่ผ่านมามันไม่เคยถูกรีวิวเลย ข้อควรระวังคือ diff ของ Markdown อ่านง่ายจนรีวิวผ่าน ๆ ได้ง่ายเช่นกัน คนรีวิวต้องถามว่า "ประโยคนี้จะเปลี่ยนการตัดสินใจของ agent ยังไง" ไม่ใช่แค่ตรวจคำผิด

3. Testing: เปลี่ยนจาก "รู้สึกว่าดีขึ้น" เป็น "eval ผ่านกี่เคส" ในโพสต์ก่อนผมเขียนว่าปัญหาใหญ่ของการปรับ agent คือเราไม่มีตัวเลขอะไรเลย eval ที่รันใน CI ได้แก้ตรงนั้นตรง ๆ และ replay จาก PR จริงช่วยให้ชุดทดสอบมาจากงานจริง ไม่ใช่ตัวอย่างที่เราแต่งขึ้นให้ผ่านง่าย ๆ

4. Reuse ข้ามทีม: แชร์เป็นโปรเจกต์ ไม่ใช่แชร์เป็นข้อความ สมมติว่าทีม A ทำ agent ที่ triage ticket ได้ดี ทีม B อยากใช้บ้าง แบบเดิมคือก๊อป prompt ไปแก้ แล้วสองเดือนต่อมาก็กลายเป็นสอง agent ที่ไม่มีใครรู้ว่าต่างกันตรงไหน แบบ agent as code ทีม B fork หรือเปิด PR กลับไปได้ และ skill ที่ใช้ร่วมกันก็แยกเป็นไฟล์ชัดเจน สำหรับคนดูแลหลายทีม นี่คือความต่างระหว่าง "มีของดีอยู่กระจัดกระจาย" กับ "มีของกลางที่ดูแลได้"

จุดที่ผมจะระวัง

eval ตรวจพฤติกรรมได้ แต่ไม่ได้ตรวจวิจารณญาณทั้งหมด ตามที่ changelog อธิบาย eval ตรวจว่าเรียก tool ไหน ด้วย input อะไร และคำตอบหน้าตาแบบไหน ซึ่งดีมากสำหรับจับ regression แต่ "เรียก tool ถูกตัว" ไม่ได้แปลว่า "ตัดสินใจถูก" เสมอไป เช่น security reviewer ที่เรียก tool ครบทุกตัวแต่มองข้ามช่องโหว่สำคัญ ก็ยังผ่าน eval ได้ถ้าเราไม่ได้เขียนเคสนั้นไว้ eval ผ่านทั้งหมดจึงแปลว่า "ไม่พังในเคสที่เราคิดออก" เท่านั้น เรื่องนี้ต่อเนื่องกับที่ผมเขียนไว้ในนิสัยการ verify ครับ

โมเดลไม่ได้ให้ผลเหมือนเดิมทุกรอบ test ของโค้ดปกติ ผ่านคือผ่าน แต่ agent อาจผ่านรอบนี้แล้วพังรอบหน้าด้วย input เดิม ถ้าทีมรัน eval รอบเดียวแล้วถือว่าเขียว ก็จะได้ความมั่นใจที่ไม่มีอยู่จริง ผมจะให้เคสสำคัญรันซ้ำหลายรอบ และดูว่าเคสไหนเปลี่ยนจากผ่านเป็นไม่ผ่าน ไม่ใช่ดูแค่ตัวเลขรวม

deploy ง่าย = เกิด agent เถื่อนง่าย คำสั่งเดียวได้ URL ที่รันอยู่บน infrastructure จริง ฟังดูดี แต่สมมติว่า junior คนหนึ่งลอง deploy agent ที่ต่อ Slack และอ่าน repo ได้ เพื่อทดลองเล่น แล้วลืมปิด ตอนนี้องค์กรมีระบบที่รับ input จากภายนอก ถือ secret และไม่มีใครเป็นเจ้าของ เรื่องนี้ไม่ใช่ความผิดของ SDK แต่เป็นเรื่องที่ทีมต้องกำหนดกติกาเอง ใครสนใจมุม threat model ของ agent ผมเขียนไว้ในบทความ OWASP สำหรับ agentic app

tool คือสิทธิ์ ไม่ใช่แค่ฟังก์ชัน ไฟล์ใน tools/ แต่ละไฟล์คือสิ่งที่โมเดลเลือกเรียกได้เอง ยิ่งเพิ่ม tool ที่เขียนข้อมูลได้ เช่น comment บน PR, แก้ ticket หรือ push โค้ด ยิ่งต้องรีวิวเข้มกว่า prompt และ agent ที่รับ input จาก webhook หรือ comment ของใครก็ได้ ต้องคิดเผื่อ prompt injection เสมอ

ต้นทุนยังเป็นคำถามเปิด ผมหาข้อมูลราคาและ limits ที่ยืนยันได้ไม่เจอตอนเขียน agent ที่ตื่นทุกครั้งที่มี PR หรือ comment ในหลาย repo อาจถูกเรียกบ่อยกว่าที่คิดมาก ก่อนเปิดใช้กว้าง ๆ ควรรู้ว่าแต่ละรอบเสียเท่าไหร่

ผูกกับ framework ของคนอื่น การ self-host ได้ช่วยเรื่องที่รัน แต่โครงสร้างโปรเจกต์ คำสั่ง และรูปแบบ eval ยังเป็นของ Cursor ถ้าวันหนึ่งต้องย้าย สิ่งที่พกไปได้ง่ายที่สุดคือ prompt กับ logic ใน tool ที่เขียนเป็น TypeScript ธรรมดา ผมเลยอยากให้ logic สำคัญอยู่ในฟังก์ชันที่ไม่ผูกกับ SDK มากเกินไป

อย่าลืมบทเรียนเรื่องฝูง agent พอสร้าง agent ง่ายขนาดนี้ มันจะยั่วให้สร้างตัวใหม่ทุกครั้งที่มีปัญหา หลักเดิมยังใช้ได้ครับ เริ่มจากตัวเดียวที่มี skill กับ tool ครบ แล้วแตกเมื่อวัดได้ว่าคุ้มเท่านั้น

ตารางว่างานแบบไหนควรเป็น agent as code

แถวสุดท้ายสำคัญที่สุดสำหรับผมครับ ถ้าเรายังนิยามผลลัพธ์ที่ถูกไม่ได้ ปัญหาไม่ได้อยู่ที่เครื่องมือ แต่อยู่ที่ requirement ซึ่งเป็นงานของ PO ไม่ใช่งานของ SDK

Checklist ก่อนกด deploy

ก่อนเริ่มโปรเจกต์

• เขียนได้ไหมว่า agent นี้รับงานจากไหน ทำอะไร และส่งผลไปที่ไหน ในสามบรรทัด
• มีตัวอย่างงานจริงอย่างน้อยจำนวนหนึ่งที่รู้ว่า "ผลที่ถูก" คืออะไร ไว้ทำ eval
• มีเจ้าของที่ชัดเจน หนึ่งคนหรือหนึ่งทีม ไม่ใช่ "ทุกคน"

ระหว่างพัฒนา

• การแก้ instructions.md, skill และ tool ต้องผ่าน PR และมีคนรีวิวที่เข้าใจว่าประโยคนั้นเปลี่ยนพฤติกรรมยังไง
• tool ที่เขียนข้อมูลได้ ถูกรีวิวแยกเรื่องสิทธิ์ และจำกัดขอบเขตให้แคบที่สุด
• eval รันใน CI และเคสสำคัญรันซ้ำมากกว่าหนึ่งรอบ
• เคสที่ agent เคยพลาด ถูกเพิ่มกลับเป็น eval ทุกครั้ง

ก่อนและหลัง deploy

• เช็คชื่อแพ็กเกจ คำสั่ง และ limits จาก docs ล่าสุด ไม่ใช่จากโพสต์สรุป
• รู้ว่า secret อะไรถูกใช้ ใครเข้าถึง dashboard ได้
• รู้ต้นทุนต่อรอบโดยประมาณ และรู้ว่าจะปิด agent ยังไงถ้ามันทำงานผิด
• ทบทวนเป็นระยะว่า agent ที่ deploy ไว้ยังมีคนใช้และยังมีเจ้าของอยู่ไหม

ถ้าผมจะเริ่มใช้กับทีม

ผมยังไม่ได้เอา Agent SDK มาใช้จริงกับทีมนะครับ ส่วนนี้คือแผนที่ผมคิดไว้ถ้าจะเริ่ม

ถ้าทีมผมจะลอง ผมจะเริ่มจากงานเดียวที่เกิดซ้ำและวัดผลง่าย เช่น agent ที่รีวิว PR ของทีม junior ตาม convention ของโปรเจกต์ เพราะมี PR เก่าให้ replay เป็น eval ได้ทันที และมีคนรีวิวจริงคอยเทียบอยู่แล้ว ผมจะไม่ให้มันแก้โค้ดหรือ approve อะไรเอง แค่ comment ข้อสังเกต แล้วดูว่า comment ไหนที่คนรีวิวเห็นด้วยและไม่เห็นด้วย

สิ่งที่ผมอยากได้จากการทดลองไม่ใช่ "agent รีวิวได้เก่งแค่ไหน" แต่เป็นคำตอบว่าทีมผมพร้อมดูแล agent แบบที่ดูแลโค้ดหรือยัง คือมีคนรีวิว prompt จริง มีคนเพิ่ม eval จากเคสที่พลาด และมีคนรับผิดชอบเมื่อมันทำผิด ถ้ายังไม่พร้อม การ deploy ได้ในคำสั่งเดียวก็แค่ทำให้เราสร้างปัญหาได้เร็วขึ้น

ท้ายที่สุด

ผมว่า Agent SDK ทำสิ่งที่ควรเกิดขึ้นนานแล้ว คือดึง agent ออกจากแชตและโน้ตส่วนตัว มาอยู่ในที่ที่ทีมคุ้นเคยที่สุด คือ repo, PR และ CI ซึ่งทำให้คำถามแบบ "ใครเปลี่ยน" "เปลี่ยนแล้วดีขึ้นไหม" และ "ทีมอื่นใช้ต่อได้ไหม" มีที่ตอบ

แต่เครื่องมือแค่ทำให้วินัยเป็นไปได้ ไม่ได้สร้างวินัยให้เรา PR ที่ไม่มีใครรีวิวจริง eval ที่เขียนไว้แค่ให้ผ่าน และ agent ที่ deploy แล้วไม่มีเจ้าของ จะพาเรากลับไปที่ปัญหาเดิม แค่คราวนี้มันอยู่ใน Git

คำถามที่ผมจะถามก่อนกด deploy ทุกครั้งจึงไม่ใช่ "มันทำงานได้ไหม" แต่เป็น "ถ้ามันทำผิดพรุ่งนี้ เรารู้ไหมว่าใครต้องแก้ และแก้ที่ไฟล์ไหน" ถ้ายังตอบไม่ได้ ก็ยังไม่ถึงเวลาครับ