วิธีทำให้ AI agent น่าเชื่อถือ: แผนงานทีละขั้นตั้งแต่การวัดผลจนถึงการทำงานอัตโนมัติ

ทำไม agent ไม่น่าเชื่อถือแม้โมเดลจะแข็งแรง

ความน่าเชื่อถือของ agent เป็นคุณสมบัติของระบบทั้งหมด ไม่ใช่ของโมเดลเพียงอย่างเดียว งานที่ยาวประกอบด้วยขั้นตอนหลายสิบขั้น และข้อผิดพลาดสะสมขึ้นเรื่อย ๆ ถ้าแต่ละขั้นถูกต้อง 95% โอกาสที่สายงานสิบขั้นจะไม่มีข้อผิดพลาดเลยอยู่ที่ราว 60% (0.95^10 ≈ 0.60) และสายงานห้าสิบขั้นต่ำกว่า 10% คุณปรับความแม่นยำของโมเดลไม่ได้ แต่คุณจับข้อผิดพลาดได้ในขั้นที่มันเกิดขึ้น และทำให้มันถูกแก้ได้ในราคาถูก นี่คืองานของ harness ได้แก่ คำสั่ง เครื่องมือ สภาพแวดล้อม สถานะ และวงป้อนกลับที่อยู่รอบโมเดล

ด้านล่างคือแผนที่พาคุณจากการทำงานแบบ «ตามความรู้สึก» ไปสู่ความน่าเชื่อถือที่วัดได้ และต่อไปจนถึงการทำงานอัตโนมัติ ขั้นตอนเรียงตามผลที่ได้รับ โดยแต่ละขั้นต่อยอดจากขั้นก่อนหน้า

ขั้นที่ 1. เลิกประเมินด้วยความรู้สึก

วิศวกรคนหนึ่งเชื่อว่าพรอมป์ตใหม่เปลี่ยนทุกอย่าง อีกคนมองไม่เห็นความต่าง และไม่มีใครวัดค่าเลย เริ่มจากการบันทึกความล้มเหลว: ทุกครั้งที่ agent ติดขัด ทำอะไรพัง หรือรายงานฟีเจอร์ที่ใช้งานไม่ได้ ให้จดหนึ่งบรรทัด

| วันที่ | งาน              | สิ่งที่เกิดขึ้น                 | ระบบย่อย    |
|--------|------------------|--------------------------------|-------------|
| 10/10  | ส่วนลดในตะกร้า   | «เสร็จแล้ว» แต่ไม่ได้รัน e2e    | วงป้อนกลับ  |
| 10/10  | webhook การชำระ  | เปิดฐานข้อมูลไม่ได้            | สภาพแวดล้อม |
| 11/10  | refactor API     | ทำซ้ำวิธีที่ถูกปฏิเสธไปแล้ว   | สถานะ       |

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

ขั้นที่ 2. ใช้สองตัวชี้วัด: MTBF และ MTTR

ความน่าเชื่อถือประกอบด้วยสองตัวเลข MTBF (เวลาเฉลี่ยระหว่างความล้มเหลว) สำหรับ agent คือจำนวนขั้นที่มันทำได้ก่อนจะติด MTTR (เวลาเฉลี่ยในการกู้คืน) คือเวลาที่ใช้ในการนำ agent กลับสู่สถานะทำงานหลังเกิดความล้มเหลว ความพร้อมใช้งานเพิ่มขึ้นได้จากทั้งการเพิ่มตัวแรกและการลดตัวที่สอง

การไล่ตาม agent ที่ไม่ผิดพลาดเลยเป็นการแข่งขันที่ไม่มีวันจบ การลด MTTR มักทำได้ภายในหนึ่งวัน ดังนั้นให้เริ่มจากตัวเลขตัวที่สอง

ขั้นที่ 3. ทำให้ความผิดพลาดมีราคาถูก

การปล่อยให้ agent ทำงานอัตโนมัติจะยอมรับได้ เมื่อต้นทุนของความผิดพลาดลดลงจนเกือบเป็นศูนย์ ไม่ใช่เมื่อ agent หยุดผิดพลาด ซึ่งต้องอาศัยสามสิ่ง:

• commit เล็กและสะอาด ย้อนการแก้ไขใด ๆ ได้ด้วยคำสั่งเดียว
• การแยกส่วน agent ทำงานในสาขาหรือสำเนาโค้ดแยกต่างหาก เช่นผ่าน git worktree และใน sandbox ที่ไม่มีสิทธิ์เข้าถึง production
• สคริปต์รีเซ็ตสภาพแวดล้อม ฐานข้อมูล dependencies และบริการกลับสู่สถานะเริ่มต้นด้วยคำสั่งเดียว

git worktree add ../shop-agent -b agent/discount
cd ../shop-agent
make reset   # สร้างฐานข้อมูลใหม่ ใช้ migration โหลด fixtures

จับเวลาดูว่าการกลับสู่สถานะทำงานเต็มรูปแบบใช้เวลานานเท่าไร นั่นคือ MTTR ของคุณ และให้จำกัดรัศมีความเสียหายด้วย เช่น กำหนดขนาด diff สูงสุดของแต่ละงาน และห้ามแก้ไฟล์นอกขอบเขตของงานนั้น

ขั้นที่ 4. ปิดวงป้อนกลับ

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

• Fail-fast: การตรวจสอบล้มทันทีที่พบข้อผิดพลาดแรก พร้อมข้อความที่เข้าใจง่าย ไม่พ่นข้อความรกหนึ่งร้อยบรรทัด
• การตรวจสอบเร็วหลังทุกการแก้ไข: linter และการตรวจชนิดข้อมูลผ่าน hook ของ agent
• ความซ้ำซ้อน: การตรวจสอบอิสระชั้นที่สองสำหรับคุณสมบัติเดียวกัน คือสถานการณ์ E2E ที่อยู่เหนือ unit tests เทสต์ยูนิตที่ผ่านไม่ได้พิสูจน์ว่าฟีเจอร์ใช้งานได้จริงกับผู้ใช้

บันทึกเกณฑ์ «เสร็จแล้ว» เป็นเงื่อนไขที่ตรวจสอบได้ เช่น «สถานการณ์ E2E ของการสั่งซื้อด้วยโค้ดโปรโมชันผ่าน» ไม่ใช่ «ส่วนลดถูกนำไปใช้แล้ว»

ขั้นที่ 5. ย้ายความจำไปไว้ในไฟล์

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

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

ขั้นที่ 6. ทีละงาน

กฎของ Little: จำนวนงานที่กำลังทำอยู่เท่ากับอัตราการรับงานคูณด้วยเวลาที่งานแต่ละชิ้นอยู่ในระบบ เมื่อความจุในการประมวลผลคงที่ การทำงานหลายชิ้นพร้อมกันไม่ทำให้เร็วขึ้น แต่ทำให้แต่ละชิ้นช้าลง สำหรับ agent สิ่งนี้เข้มข้นกว่า เพราะฟีเจอร์สามอย่างคือโมเดลโดเมนสามชุดในหน้าต่างบริบทเดียวกัน

• รักษา WIP=1: ทำฟีเจอร์เดียวจนได้ผลลัพธ์ที่ตรวจสอบแล้ว
• แบ่งงานให้เล็ก: หนึ่งความสามารถของผู้ใช้ที่ตรวจสอบได้ 1–3 ไฟล์ และการตรวจสอบเสร็จภายในหนึ่งนาที
• สร้าง BACKLOG.md เป็นช่องระบายสำหรับเรื่อง «เผื่อ» เมื่อเจอข้อบกพร่องใกล้เคียง ให้เพิ่มหนึ่งบรรทัดในแบ็กล็อก อย่าแก้เองโดยพลการ

ขั้นที่ 7. แยกผู้ทำและผู้ตรวจ

การที่ agent ประเมินงานของตัวเองเป็นเบรกที่อ่อน: เซสชันเดียวกันที่เขียนโค้ดมักมีแนวโน้มจะคิดว่าโค้ดนั้นถูกต้อง ให้ subagent หรือเซสชันแยกเป็นผู้ประเมินผลลัพธ์ โดยรับเพียงข้อกำหนด diff และผลการตรวจสอบ โดยไม่รับเหตุผลของผู้ทำ การตัดสินของผู้ประเมินต้องอ้างอิงการตรวจสอบด้วยเครื่อง ไม่ใช่ «ดูโอเคดี»

ขั้นที่ 8. ปล่อย agent เข้าสู่วงวนอัตโนมัติ

Harness ทำให้การรันหนึ่งครั้งน่าเชื่อถือ ส่วนวงวนทำให้ชุดการรันเป็นอัตโนมัติ วงวนที่วางบน harness ที่อ่อนแอจะทำให้ข้อผิดพลาดเพิ่มขึ้นเร็วขึ้นเท่านั้น ขั้นนี้จึงมาเป็นลำดับสุดท้าย วงวนที่ง่ายที่สุดอธิบายได้ด้วยสามบรรทัด:

เป้าหมาย:    สถานการณ์ e2e การชำระเงินด้วยโค้ดโปรโมชันผ่าน
ตรวจสอบ:    make lint && make test && make e2e
หยุด:       ถึงเป้าหมาย หรือ 15 ครั้ง หรือ 2 ชั่วโมง → เรียกคน

เลือกชนิดของวงวนให้เหมาะกับงาน หากงานมีเส้นชัย ต้องใช้วงวนตามเป้าหมาย ซึ่งมีความจำของความคืบหน้า ผู้ประเมินอิสระ และงบประมาณจำนวนขั้น หากไม่มีจุดจบ (เช่น ตรวจ CI ทุกเช้า วิเคราะห์ข้อผิดพลาดใหม่) ใช้วงวนตามตารางเวลา ข้อผิดพลาดที่พบบ่อยคือการตั้งเวลารันงานที่มีจุดจบ ทำให้ทุกครั้งที่รันเริ่มใหม่จากศูนย์

กฎของการทำงานอัตโนมัติอย่างปลอดภัย

• เงื่อนไขการหยุดต้องเป็นสิ่งที่เครื่องตรวจได้เท่านั้น บวกด้วยขีดจำกัดจำนวนครั้งและงบประมาณ
• การส่งต่อให้คน: ระบุล่วงหน้าว่ามีอะไรที่วงวนไม่ได้รับความไว้วางใจ (migration ของ production เงิน การลบข้อมูล)
• ถ้างานติดอยู่และความคืบหน้าไม่เพิ่มขึ้นจริง นั่นเป็นสัญญาณให้ส่งต่อให้คน อย่าหมุนวนต่อไป
• อ่าน diff ความเร็วของวงวนต้องไม่เกินความเร็วที่คุณอ่านได้ ไม่เช่นนั้นคุณจะไม่เข้าใจโค้ดเบสของตัวเองอีกต่อไป

ความผิดพลาดที่พบบ่อยระหว่างทาง

เริ่มด้วยการเขียนคำสั่งใหม่

การตอบสนองที่พบบ่อยที่สุดเมื่อ agent ล้มเหลวคือเพิ่มกฎลงใน AGENTS.md ผ่านไปไม่กี่เดือน ไฟล์บวมเป็นร้อยบรรทัดและกฎสำคัญจมหาย ถ้าบันทึกความล้มเหลวแสดงว่า agent ไม่ได้รันการตรวจสอบ ให้แก้ที่วงป้อนกลับ คือใส่คำสั่งตรวจสอบและ hook ไม่ใช่เพิ่มย่อหน้าข้อความอีก

แก้ทุกอย่างพร้อมกัน

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

สับสน «เทสต์เขียว» กับ «ฟีเจอร์ใช้งานได้»

agent อาจเขียนเทสต์ที่ตรวจสอบการใช้งานของตัวเอง แทนที่จะตรวจข้อกำหนด เทสต์แบบนั้นจะเขียวเสมอ การป้องกันคือการตรวจสอบระดับผู้ใช้ (สถานการณ์ E2E) ที่เขียนก่อนลงมือทำ หรือโดยผู้ตรวจอิสระ พร้อมกฎว่า agent ไม่แก้เทสต์เพื่อให้มันผ่าน

ปิดการตรวจสอบเพื่อให้เร็วขึ้น

การตรวจสอบที่ช้าทำให้อยากข้าม «แค่ครั้งนี้» ควรแยกมันออก: linter และการตรวจชนิดข้อมูลที่เร็วหลังทุกการแก้ไข ส่วนชุดเทสต์เต็มและ E2E ก่อนพูดว่า «เสร็จแล้ว» วิธีนี้วงป้อนกลับยังสั้นและไม่รบกวนการทำงาน

มองว่า ablation คือขั้นแรก

คุณอาจปิดระบบย่อยของ harness ทีละตัวแล้วดูว่าคุณภาพลดลงเท่าไร นี่เป็นการตรวจสอบที่มีประโยชน์ แต่มีค่าใช้จ่ายสูงและไม่ควรทำเป็นอย่างแรก บันทึกความล้มเหลวจะชี้คอขวดก่อน ส่วน ablation เป็นเพียงการยืนยันสมมติฐาน การที่คุณภาพไม่ลดลงเมื่อปิดส่วนประกอบหนึ่งไม่ได้แปลว่าส่วนนั้นไม่จำเป็น อาจเป็นเพราะชุดงานที่เลือกไว้ไม่ได้ใช้มัน

ขั้นบันไดของความเป็นผู้ใหญ่

สรุป

วิธีทำให้ AI agent น่าเชื่อถือ: วัดผล ค้นหาระบบย่อยที่อ่อนแอจากบันทึกความล้มเหลว ทำให้ความผิดพลาดมีราคาถูก ปิดวงป้อนกลับ ย้ายความจำไปไว้ในไฟล์ ทำงานทีละชิ้น และแยกผู้ทำออกจากผู้ตรวจ หลังจากนั้นวงวนอัตโนมัติที่มีเงื่อนไขหยุดด้วยเครื่องจึงจะปลอดภัย ทุกขั้นตอนในแผนนี้ถูกอธิบายในทางปฏิบัติในหลักสูตร harness engineering