เอเจนต์ของผมส่ง 3 PR ได้ภายในเย็นเดียว แต่ 40% ของข้อความที่ผมส่งไปคือการแก้ไข

เอเจนต์เขียนโค้ดที่ขับเคลื่อนด้วย AI ของผมส่ง pull requests ออกมา 3 รายการภายในเย็นเดียว แต่ 40% จาก 30 ข้อความที่ผมส่งไปนั้นเป็นการแก้ไข

เซสชันนี้สร้างทั้ง MCP client, Azure AI Agent และ M365 Copilot Agent การตรวจสอบอัตโนมัติผ่าน PR ทั้งสามรายการ และผมไม่เคยต้องแก้ไขโค้ดแม้แต่บรรทัดเดียว แต่บันทึกการสนทนากลับบอกเรื่องที่ต่างออกไป: จากข้อความทั้งหมด 710 ข้อความ ผมพิมพ์ไป 30 ข้อความ และ 12 ข้อความในนั้นคือการดึงเอเจนต์กลับเข้าสู่เส้นทางที่ถูกต้อง “steering rate” หรือสัดส่วนของข้อความที่ผมส่งไปเพื่อการแก้ไขนั้นอยู่ที่ 40%

โครงสร้างของ Pipeline เป็นอย่างไร

  • Claude ร่างแผนการดำเนินงานระดับสูง
  • DeepSeek V4-Flash ทำหน้าที่เป็น orchestrator เพื่อตรวจสอบแผนงาน
  • Codex เป็นผู้สร้างโค้ดจริง
  • Orchestrator ทำการตรวจสอบโค้ดและเปิด pull requests

บทบาทที่ตั้งใจไว้ของ orchestrator คือการเป็นตัวเชื่อมต่อเท่านั้น—มันควรทำหน้าที่จัดการความขัดแย้งระหว่างส่วนประกอบต่างๆ ไม่ใช่เขียนโค้ดด้วยตัวเอง ในทางปฏิบัติ เอเจนต์สร้างโค้ดขึ้นมา 3,500 บรรทัดผ่าน 3 PR ภายในเวลาประมาณ 40 นาที แต่ก็ยังมีข้อผิดพลาดที่เกิดขึ้นซ้ำๆ อยู่ 2 ประเภท

ข้อผิดพลาด 2 รูปแบบ

  1. การละเมิดเวิร์กโฟลว์ (Workflow violations) – ในบางครั้ง orchestrator เข้าไปทำขั้นตอนการเขียนโค้ดเอง โดยละเลยบทบาทการเป็น "ตัวเชื่อม" (glue) และลงมือเขียนรายละเอียดการทำงานด้วยตัวเอง
  2. ความล้มเหลวในการดึงข้อมูลบริบท (Context-retrieval failures) – แม้จะมีคำสั่งที่ชัดเจน แต่เอเจนต์กลับเลือก SDK หรือเวอร์ชันที่ผิด ข้อมูลที่ถูกต้องมีอยู่ในบริบทของ prompt อยู่แล้ว แต่โมเดลกลับไม่สามารถดึงข้อมูลนั้นออกมาใช้ในจังหวะที่เหมาะสมได้

สิ่งเหล่านี้ไม่ใช่ช่องว่างของความสามารถในการใช้เหตุผล แต่เป็นบั๊กทางวิศวกรรมในวิธีการควบคุมเวิร์กโฟลว์ แม้แต่โมเดลภาษาที่มีความสามารถสูงกว่านี้ ก็ยังจำเป็นต้องมีกฎที่เข้มงวดและชัดเจนเพื่อตีกรอบให้ orchestrator ทำหน้าที่ที่ไม่ใช่การเขียนโค้ด และบังคับให้เลือก SDK ที่ถูกต้อง

สิ่งที่ผมเปลี่ยนเพื่อควบคุมเอเจนต์

ผมเลิกคาดหวังว่าระบบจะอนุมานบทบาทของมันเองจากรายการขั้นตอนการทำงาน ผมจึงเพิ่มคำสั่งโดยตรงว่า: “You are an orchestrator. You do not implement.” ต้องใช้ข้อความแก้ไขถึง 5 ครั้งกว่าคำสั่งนี้จะเริ่มได้ผล หลังจากนั้นเอเจนต์ก็เคารพขอบเขตดังกล่าว

ผมยังได้ปรับปรุงตรรกะการดึงข้อมูลบริบทให้รัดกุมขึ้น เมื่อมีการใช้เครื่องมือที่ผิด ผมมองว่ามันเป็นบั๊กใน pipeline การดึงข้อมูลมากกว่าจะเป็นอาการหลอน (hallucination) และผมได้เขียน prompt ที่ป้อนรายละเอียด SDK ใหม่ เพื่อทำให้การเลือกเวอร์ชันที่ถูกต้องเป็นสิ่งที่พลาดไม่ได้

บทเรียนที่นำไปใช้ได้จริงสำหรับการพัฒนาด้วย AI

  • นับจำนวนข้อความของคุณเอง จำนวน PR ที่ผ่านการยอมรับจำนวนมากอาจบดบังกระบวนการที่บกพร่องได้ จำนวนการแก้ไขของคุณคือตัวบ่งชี้ล่วงหน้าว่าระบบควบคุมของคุณกำลังมีช่องโหว่ตรงไหน
  • ระบุบทบาทให้ชัดเจน เอเจนต์ไม่สามารถอนุมานตัวตนจากรายการตรวจสอบ (checklist) ได้ พวกมันต้องการคำสั่งที่ชัดเจนและคงที่ว่าพวกมันคือใครและสามารถทำอะไรได้บ้าง
  • มองว่าข้อผิดพลาดในการเลือกเครื่องมือคือบั๊กทางวิศวกรรม หากเอเจนต์เพิกเฉยต่อ SDK ที่ระบุไว้ ความผิดพลาดนั้นอยู่ที่กลไกการส่งมอบบริบท ไม่ใช่ที่ "ความรู้" ของโมเดล
  • เปลี่ยนความผิดพลาดให้เป็นทักษะที่นำกลับมาใช้ใหม่ได้ ผมให้เอเจนต์สร้างขั้นตอนการตรวจสอบ (validation routine) จากข้อผิดพลาดของมันเอง เปลี่ยนความล้มเหลวให้กลายเป็นเกราะป้องกันในอนาคต

เดิมพันที่กว้างกว่านั้น