หยุดป้อนคำสั่ง AI เขียนโค้ดด้วยมือ สร้างลูปสั่งงานอัตโนมัติแทน

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

สรุปสั้นๆ

ลูปเอเจนต์เขียนโค้ดคือโครงสร้างควบคุมที่รันเอเจนต์ซ้ำๆ: สร้างการเปลี่ยนแปลง, รันมัน, ตรวจสอบผลลัพธ์กับสัญญาณที่ชัดเจน, ส่งข้อผิดพลาดกลับไป, ทำซ้ำจนกว่าการตรวจสอบจะผ่านหรือถึงขีดจำกัด เอเจนต์ไม่ใช่ส่วนที่ยาก ส่วนที่ยากคือด่านตรวจสอบ (verification gate) ลูปที่มีด่านตรวจสอบคลุมเครือ (“ดูดี ลองอีกครั้ง”) จะเบี่ยงเบนและหลงผิดว่า “เสร็จแล้ว” ลูปที่มีด่านตรวจสอบที่คาดการณ์ได้ (เช่น การทดสอบล้มเหลว, schema ไม่ตรงกัน, สัญญาผิดพลาด) จะมุ่งเข้าสู่เป้าหมาย สำหรับงาน API และแบ็กเอนด์ ชุดการทดสอบอัตโนมัติและการตรวจสอบสัญญาของคุณคือด่านตรวจสอบนั้น นี่คือเหตุผลว่าทำไม การทดสอบ API จึงควรเป็นหัวใจของเวิร์กโฟลว์แบบเอเจนต์ ไม่ใช่สิ่งที่มาต่อเติมในตอนท้าย

จากการป้อนคำสั่งสู่การออกแบบลูป

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

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

การออกแบบลูปจะพลิกกลับสิ่งนั้น แทนที่จะเป็นผู้ที่อ่านผลลัพธ์และตัดสินใจว่าจะป้อนคำสั่งอะไรต่อไป คุณสร้างชุดควบคุม (harness) ที่ทำสิ่งนั้นโดยอัตโนมัติ เอเจนต์เขียนโค้ด สคริปต์รันมัน ผลลัพธ์ถูกบันทึกไว้ หากล้มเหลว ข้อผิดพลาดจะถูกส่งกลับไปยังเอเจนต์โดยตรงเพื่อเป็นคำสั่งต่อไป ไม่มีมนุษย์อยู่ในลูปภายใน คุณจะเข้ามาเกี่ยวข้องเฉพาะในส่วนขอบ: เพื่อกำหนดงาน, เพื่ออนุมัติผลลัพธ์, เพื่อยุติการทำงานหากมันผิดพลาด บทความของ Anthropic เรื่อง การสร้างเอเจนต์ที่มีประสิทธิภาพ ก็ชี้ให้เห็นประเด็นเดียวกันนี้ด้วยคำพูดที่แตกต่างกัน ชัยชนะมาจากสภาพแวดล้อมที่คุณเชื่อมต่อกับโมเดล ไม่ใช่มาจากคำสั่งเดี่ยวที่ฉลาดกว่า

การเปลี่ยนกระบวนทัศน์ทางความคิดนั้นเล็กน้อยแต่สมบูรณ์ เลิกถามว่า “ฉันควรบอกอะไรเอเจนต์ดี?” เริ่มถามว่า “ลูปแบบไหนที่จะทำให้เอเจนต์บอกตัวเองได้?”

ลูปเอเจนต์เขียนโค้ดคืออะไรกันแน่

หากตัดเรื่องความหวือหวาออกไป ลูปเอเจนต์เขียนโค้ดมีห้าส่วน หากขาดไปเพียงส่วนเดียว ลูปก็จะไม่สิ้นสุดหรือไม่ก็สิ้นสุดผิดพลาด

1. ข้อกำหนดงาน คำอธิบายที่ชัดเจนและเป็นลายลักษณ์อักษรว่างานที่เสร็จสมบูรณ์ควรเป็นอย่างไร ไม่ใช่แค่ “ทำให้มันทำงานได้” แต่คือ “ปลายทาง POST /orders คืนค่า 201 พร้อมคำสั่งซื้อที่สร้างขึ้น, ตรวจสอบเนื้อหาตาม schema, และปฏิเสธฟิลด์ที่ขาดหายไปด้วย 422”
2. เอเจนต์ โมเดลพร้อมเครื่องมือ: อ่านไฟล์, เขียนไฟล์, รันคำสั่งเชลล์ นี่คือส่วนที่ทุกคนให้ความสำคัญมากที่สุด และเป็นส่วนที่คุณควบคุมได้น้อยที่สุด
3. ขั้นตอนการดำเนินการ เอเจนต์ทำการเปลี่ยนแปลง จากนั้นมีบางอย่างรันมันจริงๆ การทดสอบ, การสร้าง, การตรวจสอบชนิดข้อมูล, การส่งคำขอไปยังปลายทางจริง
4. ด่านตรวจสอบ การตรวจสอบที่คาดการณ์ได้ซึ่งคืนค่าผ่านหรือไม่ผ่านพร้อมเหตุผลที่ชัดเจน นี่คือพวงมาลัย เราจะใช้เวลาส่วนใหญ่ของโพสต์นี้ที่นี่
5. เงื่อนไขการสิ้นสุด ลูปจะหยุดเมื่อใด? ด่านผ่าน, หรือคุณถึงจำนวนการวนซ้ำสูงสุด, หรือคุณใช้งบประมาณเกิน ลูปที่ไม่มีทางออกคือการทำงานที่ควบคุมไม่ได้ ไม่ใช่เวิร์กโฟลว์

ในรูปแบบซูโดโค้ด รูปแบบทั้งหมดนี้สามารถสรุปได้ในไม่กี่บรรทัด:

task = load_spec("orders-endpoint.md")
for attempt in range(MAX_ITERATIONS):
    agent.run(task, feedback=last_result)   # สร้าง
    result = run_verification()             # รัน + ตรวจสอบด่าน
    if result.passed:
        break                               # สิ้นสุด: สำเร็จ
    last_result = result.failures           # ป้อนข้อผิดพลาดกลับ
else:
    escalate_to_human(last_result)          # สิ้นสุด: ยอมแพ้

ลูปนั้นคือแนวคิดทั้งหมด เอเจนต์สร้าง, ด่านตัดสิน, ข้อผิดพลาดกลายเป็นคำสั่งต่อไป, และทุกอย่างจะดำเนินไปจนกว่าจะสำเร็จ (เป็นสีเขียว) หรือหมดความพยายาม รูปแบบที่ผู้คนแชร์ออนไลน์ว่าเป็นเทคนิค “Ralph” ก็คือสิ่งนี้โดยที่ MAX_ITERATIONS ถูกตั้งค่าสูงและข้อกำหนดถูกเขียนอย่างเข้มงวด หากคุณได้อ่านบทวิเคราะห์ของเราเกี่ยวกับ สถาปัตยกรรมชุดควบคุมเอเจนต์ นี่คือชุดควบคุมในรูปแบบที่เล็กที่สุดและซื่อตรงที่สุด

ทำไมการป้อนคำสั่งครั้งเดียวถึงติดขัด

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

โมเดลเก่งในการสร้างโค้ดที่ดูเป็นไปได้ แต่ไม่เก่งในการรู้ว่าโค้ดนั้นถูกต้องหรือไม่ พวกมันจะเขียนปลายทางที่ดูถูกต้อง คอมไพล์ได้ และส่งคืนรหัสสถานะผิดพลาดอย่างเงียบๆ ในกรณีพิเศษ (edge case) ในการแชท คุณอาจไม่ทันสังเกตจนกว่าจะถึงขั้นตอนการผลิตจริง โมเดลไม่มีข้อมูลป้อนกลับที่บอกว่ากรณีพิเศษนั้นล้มเหลว ดังนั้นมันจึงรายงานความสำเร็จอย่างมั่นใจ ช่องว่างระหว่าง “ดูเหมือนเสร็จแล้ว” กับ “เสร็จแล้วจริงๆ” คือจุดที่ลูปเข้ามามีบทบาทสำคัญ

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

ยังมีมุมมองด้านประสิทธิภาพการทำงานด้วย การป้อนคำสั่งด้วยมือจำกัดปริมาณงานของคุณที่เอเจนต์ตัวเดียวที่คุณกำลังเฝ้าดูอย่างกระตือรือร้น ลูปช่วยให้คุณสามารถรันหลายตัวพร้อมกันได้ แต่ละตัวทำงานในงานของตัวเองโดยเทียบกับด่านตรวจสอบของตัวเอง เพราะไม่มีตัวใดต้องการคุณอยู่ในวัฏจักรภายใน (inner cycle) นั่นคือการก้าวกระโดดที่บทความของเราเกี่ยวกับ เวิร์กโฟลว์เอเจนต์แบบไดนามิกและขนานกัน ได้กล่าวถึง: เมื่อลูปเป็นระบบอัตโนมัติแล้ว คุณก็สามารถขยายขนาดได้โดยการเพิ่มลูป ไม่ใช่โดยการพิมพ์เร็วขึ้น

ส่วนที่ทุกคนสร้างน้อยเกินไป: ด่านตรวจสอบ

นี่คือความจริงที่น่าอึดอัดใจ เวิร์กโฟลว์เอเจนต์ที่ล้มเหลวส่วนใหญ่ไม่ได้ล้มเหลวเพราะโมเดลอ่อนแอเกินไป พวกมันล้มเหลวเพราะสัญญาณป้อนกลับอ่อนแอเกินไป

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

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

อะไรที่ทำให้เป็นด่านตรวจสอบที่ดี?

• เป็นแบบไบนารีและสามารถทำซ้ำได้ อินพุตเดียวกัน, ผลลัพธ์เดียวกัน, ทุกครั้ง ไม่มี “ขึ้นอยู่กับว่าโมเดลรู้สึกอย่างไรในวันนี้”
• มันล้มเหลวอย่างชัดเจนพร้อมเหตุผล ชื่อการทดสอบ, ความแตกต่างระหว่างที่คาดหวังกับของจริง, หมายเลขบรรทัด, รหัสข้อผิดพลาด เหตุผลคือคำสั่งต่อไป ดังนั้นมันจึงต้องเฉพาะเจาะจง
• เอเจนต์ไม่สามารถแก้ไขมันอย่างเงียบๆ ได้ หากเอเจนต์สามารถเปลี่ยนการทดสอบเพื่อให้มันผ่านได้ ด่านตรวจสอบนั้นก็แค่ละคร ปกป้องด่านตรวจสอบ ปฏิบัติเสมือนว่ามันเป็นข้อกำหนด ไม่ใช่โค้ดที่เอเจนต์เป็นเจ้าของ
• มันทำงานเร็วพอที่จะวนซ้ำได้ ด่านตรวจสอบที่ใช้เวลา 20 นาทีจะจำกัดความเร็วในการวนซ้ำของคุณ ลูปที่กระชับต้องการการตรวจสอบที่รวดเร็ว

ด่านตรวจสอบที่ดีมีอยู่แล้วในโค้ดเบสที่สมบูรณ์ทุกที่ การทดสอบหน่วย (Unit tests) ตัวตรวจสอบชนิดข้อมูล (Type checkers) Linter คอมไพเลอร์ ตัวตรวจสอบ Schema การทดสอบสัญญา (Contract tests) สิ่งเหล่านี้คือตัวบอกผลลัพธ์ที่คาดการณ์ได้ พวกมันถูกสร้างมาเพื่อบอกมนุษย์ว่า “นี่คือสิ่งที่ผิดและนี่คือเหตุผล” ซึ่งเป็นสัญญาณที่ลูปเอเจนต์ต้องการอย่างแม่นยำ คุณไม่จำเป็นต้องประดิษฐ์ด่านตรวจสอบขึ้นมาใหม่ คุณเพียงแค่ต้องชี้ลูปไปยังด่านตรวจสอบที่คุณเชื่อถืออยู่แล้ว และเขียนใหม่ในส่วนที่ครอบคลุมน้อย หากคุณไม่เคยทำให้เลเยอร์นั้นเป็นทางการมาก่อน คำแนะนำของเราเกี่ยวกับ การทดสอบอัตโนมัติคืออะไรกันแน่ เป็นพื้นฐานที่ดีก่อนที่คุณจะเชื่อมต่อมันเข้ากับลูป

สำหรับงาน API และแบ็กเอนด์ ชุดทดสอบของคุณคือลูป

นี่คือจุดที่แนวคิดเชิงนามธรรมกลายเป็นรูปธรรมสำหรับทุกคนที่สร้างบริการ เมื่อเอเจนต์เขียนปลายทาง API อะไรคือความจริงพื้นฐานที่บอกว่ามันใช้งานได้? ไม่ใช่บทสรุปของโมเดล คือพฤติกรรมที่แท้จริงของปลายทางที่กำลังทดสอบ: รหัสสถานะที่ถูกต้อง, เนื้อหาการตอบกลับที่ตรงกับ schema, การบังคับใช้การตรวจสอบสิทธิ์, การปฏิเสธอินพุตที่ไม่ถูกต้อง, การปฏิบัติตามสัญญา

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

ลูปที่จับต้องได้สำหรับงานปลายทางมีลักษณะดังนี้:

1. เอเจนต์อ่านข้อกำหนดงานและคำนิยาม OpenAPI จากนั้นเขียนหรือแก้ไขปลายทาง
2. ชุดควบคุมรันชุดทดสอบ API เทียบกับบริการที่กำลังทำงาน: การยืนยันสถานะ, การตรวจสอบ JSON schema ในทุกการตอบกลับ, การตรวจสอบสัญญาเทียบกับข้อกำหนด
3. ข้อผิดพลาดจะกลับมาในรูปแบบที่มีโครงสร้าง “คาดว่าจะเป็น 422 เมื่อ customer_id หายไป แต่ได้ 500” “ฟิลด์ total ในการตอบกลับเป็นสตริง แต่ schema ระบุว่าเป็นตัวเลข” “ปลายทาง /orders/{id} ในข้อกำหนดไม่มีการใช้งาน”
4. ข้อผิดพลาดที่มีโครงสร้างนั้นกลายเป็นคำสั่งต่อไปของเอเจนต์ มันจะแก้ไขช่องว่างที่เฉพาะเจาะจง
5. ทำซ้ำจนกว่าชุดทดสอบจะเป็นสีเขียว จากนั้นส่งต่อให้มนุษย์ตรวจสอบ

หัวใจสำคัญคือข้อมูลป้อนกลับในขั้นตอนที่ 3 นั้นแม่นยำและถูกสร้างโดยเครื่องจักร ไม่ใช่อารมณ์ความรู้สึก นั่นคือสิ่งที่ทำให้ลูปบรรจบกันแทนที่จะหลงทาง การทดสอบแบบ Schema-first และ Contract testing มีความสำคัญมากกว่าที่เคยในที่นี้ เพราะ ข้อกำหนด OpenAPI กลายเป็นแหล่งความจริงร่วมกันที่ทั้งเอเจนต์และด่านตรวจสอบใช้อ้างอิง ความคลาดเคลื่อนระหว่างโค้ดและข้อกำหนดจะหยุดเป็นปัญหาเอกสารที่ล่าช้า และกลายเป็นด่านตรวจสอบสีแดงในทันที

นี่คือบทบาทที่ Apidog มีในเวิร์กโฟลว์แบบเอเจนต์ เป็นแพลตฟอร์ม API แบบครบวงจรที่การออกแบบ, schema, mock server และการทดสอบอัตโนมัติอยู่รวมกันในที่เดียว ซึ่งหมายความว่าด่านตรวจสอบและข้อกำหนดจะคงความสอดคล้องกันโดยค่าเริ่มต้น คุณชี้ลูปไปที่สถานการณ์ทดสอบของ Apidog, เอเจนต์จะได้รับการตรวจสอบ pass/fail ตาม schema ในทุกการวนซ้ำ, และ mock server จะทำหน้าที่แทนการพึ่งพาที่ยังไม่ได้สร้าง เพื่อให้เอเจนต์สามารถทำงานกับเป้าหมายที่เสถียรได้ ทีมที่ใช้รูปแบบนี้อยู่แล้วจะเชื่อมต่อการเข้าถึงเครื่องมือของเอเจนต์ผ่านเครื่องมืออย่าง Apidog AI agent debugger เพื่อให้เอเจนต์สามารถเรียกใช้และตรวจสอบปลายทางได้เช่นเดียวกับที่ผู้ทดสอบที่เป็นมนุษย์ทำ ดาวน์โหลด Apidog หากคุณต้องการสร้างด่านตรวจสอบด้วยภาพแทนการสร้าง test runner ด้วยตัวเอง

สร้างลูป API ที่แก้ไขตัวเองได้ขั้นต่ำสุดวันนี้

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

ขั้นตอนที่ 1: เขียนข้อกำหนดตามเจตนาของด่านตรวจสอบ ใส่สัญญาไว้ในไฟล์ OpenAPI และพฤติกรรมในกรณีทดสอบ เอเจนต์อ่านทั้งสองอย่าง สิ่งนี้ยังเป็นเอกสารประกอบด้วย ดังนั้นจึงไม่ใช่งานที่ทำทิ้งๆ ขว้างๆ

ขั้นตอนที่ 2: เลือกคำสั่งทดสอบที่คืนค่าที่ไม่ใช่ศูนย์เมื่อล้มเหลว อะไรก็ได้ใช้ได้ ตราบใดที่รหัสออกนั้นถูกต้อง ชุดทดสอบ pytest, การรัน Newman, สถานการณ์ทดสอบ Apidog CLI ลูปสนใจเพียงแค่ผ่าน/ไม่ผ่าน และผลลัพธ์ที่บันทึกไว้

# ด่านตรวจสอบ, ในรูปแบบคำสั่งเดียว
apidog run ./tests/orders-suite --reporter json > result.json

ขั้นตอนที่ 3: เชื่อมต่อลูป รันเอเจนต์, รันด่านตรวจสอบ, แยกตามผลลัพธ์

MAX_ITERATIONS = 8
feedback = None
for attempt in range(MAX_ITERATIONS):
    run_agent(task="implement orders API per spec", feedback=feedback)
    gate = subprocess.run(["apidog", "run", "./tests/orders-suite",
                           "--reporter", "json"], capture_output=True)
    if gate.returncode == 0:
        print(f"green on attempt {attempt + 1}")
        break
    feedback = parse_failures(gate.stdout)   # คำสั่งต่อไปจะเขียนตัวเอง
else:
    print("8 attempts, still red; escalating to a human") # ยังเป็นสีแดง; ส่งต่อให้มนุษย์

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

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

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

การออกแบบลูปที่ดี: ข้อผิดพลาดที่ต้องระวัง

มีรูปแบบไม่กี่อย่างที่แบ่งแยกลูปที่ใช้งานได้จริงออกจากลูปที่เปลืองเงินอย่างเงียบๆ

• การปล่อยให้เอเจนต์ตรวจการบ้านของตัวเอง หากการตรวจสอบเดียวคือ “เอเจนต์ คุณเสร็จแล้วหรือยัง?” คุณไม่มีลูป คุณมีแค่แชทบอทที่มีขั้นตอนเพิ่มเติม ด่านตรวจสอบจะต้องอยู่ภายนอกเอเจนต์
• ด่านตรวจสอบที่หยาบเกินไป “การทดสอบผ่าน” ด้วยการทดสอบตื้นๆ สามครั้ง หมายความว่าเอเจนต์ทำตามการทดสอบสามครั้งนั้นและส่งมอบบั๊กในส่วนที่ไม่ได้ครอบคลุม คุณภาพของลูปถูกจำกัดด้วยการครอบคลุมของด่านตรวจสอบ การทดสอบที่บางเบา, ผลลัพธ์ที่บางเบา
• ไม่มีตัวป้องกันการสิ้นสุด ลูปที่ไม่มีจำนวนการวนซ้ำสูงสุดและขีดจำกัดค่าใช้จ่ายสามารถทำงานไปเรื่อยๆ กับงานที่โมเดลไม่สามารถแก้ปัญหาได้ ตั้งค่าทางออกเสมอ และส่งต่อให้มนุษย์เสมอเมื่อมันติดขัด
• ด่านตรวจสอบที่ช้า ชุดการรวมระบบที่ใช้เวลา 15 นาทีเป็นสิ่งที่ดีสำหรับการตรวจสอบประจำคืน แต่เป็นลูปภายในที่แย่มาก ใช้ด่านตรวจสอบที่รวดเร็วสำหรับลูป และด่านตรวจสอบที่ละเอียดสำหรับเมื่อรวมโค้ด จำลองการพึ่งพาภายนอกเพื่อให้ลูปไม่ต้องรอการทำงานของบุคคลที่สามที่ไม่เสถียร
• ข้อกำหนดที่เปลี่ยนแปลงได้ หากเอเจนต์แก้ไขไฟล์ OpenAPI ให้ตรงกับโค้ดที่มีข้อผิดพลาด การทดสอบสัญญาจะผ่านด้วยเหตุผลที่ผิด ข้อกำหนดคือรัฐธรรมนูญ เอเจนต์ทำงานภายใต้ข้อกำหนดนั้น ไม่ใช่ทำงานเพื่อแก้ไขมัน
• งานขนาดใหญ่เพียงงานเดียว ลูปที่ทำงานเกี่ยวกับ “สร้างบริการทั้งหมด” แทบไม่บรรจบกัน แยกงานออกเป็นงานย่อยขนาดปลายทาง (endpoint-sized tasks) โดยแต่ละงานมีด่านตรวจสอบของตัวเอง ลูปเล็กๆ จะเสร็จสิ้น; ลูปใหญ่ๆ จะวุ่นวาย

ส่วนใหญ่ของสิ่งเหล่านี้สรุปได้ในหลักการเดียวกัน: ลงทุนในสัญญาณ ไม่ใช่ในคำสั่ง รูปแบบการเชื่อมต่อและโหมดความล้มเหลวในที่นี้สอดคล้องกับสิ่งที่เราได้กล่าวถึงใน การเชื่อมต่อเครื่องมือในเวิร์กโฟลว์แบบเอเจนต์ และสิ่งเหล่านี้ยังคงใช้ได้ไม่ว่าเอเจนต์ของคุณจะเป็น Claude Code, Cursor, Codex หรือสิ่งที่คุณสร้างขึ้นเอง

ทิศทางที่จะไป

ประโยคที่ว่า “หยุดป้อนคำสั่ง เริ่มสร้างลูป” เป็นภาพรวมของแนวโน้มที่ยาวนานขึ้น ทักษะที่กำลังมีคุณค่าไม่ใช่การสร้างคำสั่ง (prompt-craft) แต่มันคือการสร้างลูป (loop-craft): การเขียนข้อกำหนดที่ชัดเจน, การสร้างด่านตรวจสอบที่คาดการณ์ได้, การเลือกเงื่อนไขการสิ้นสุด, และการตัดสินใจว่าเอเจนต์ได้รับอนุญาตให้แตะต้องอะไรได้บ้างและอะไรไม่ได้ นั่นใกล้เคียงกับการออกแบบระบบมากกว่าวิศวกรรมพรอมต์ (prompt engineering) และมันให้ผลตอบแทนแก่วิศวกรที่คิดในแง่ของการทดสอบ, สัญญา, และ CI อยู่แล้ว

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

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

ข้อคิดสำคัญ

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

เริ่มจากเล็กๆ เขียนข้อกำหนดที่กระชับหนึ่งชุด, ชี้ลูปไปยังชุดทดสอบ API ที่รวดเร็วหนึ่งชุด, ปกป้องด่านตรวจสอบ, จำกัดจำนวนการวนซ้ำ, และดูเอเจนต์ทำงานจากปลายทางที่เป็นสีแดงจนกลายเป็นสีเขียวโดยที่คุณไม่ต้องเข้าไปอยู่ในลูปภายใน จากนั้นสร้างลูปถัดไป หากคุณต้องการให้ด่านตรวจสอบเป็นภาพ, รับรู้ schema, และสามารถแชร์ข้ามทีมได้, Apidog ให้คุณมีการออกแบบ, การจำลอง (mocking), และการทดสอบอัตโนมัติในพื้นที่ทำงานเดียว; ดาวน์โหลดเลย และทำให้การทดสอบของคุณเป็นสิ่งที่ขับเคลื่อนเอเจนต์ของคุณ