เอเจนต์การเขียนโค้ดที่ทำงานต่อเนื่องยาวนานต้องการระบบควบคุมที่ครอบคลุม ไม่ใช่แค่โมเดลที่ใหญ่ขึ้น

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

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

ค่าเริ่มต้นที่มีประโยชน์คือการตัดสินใจแยกกันสองครั้ง:

1. กำหนดเส้นทางการทำงานของโมเดลโดยพิจารณาจากข้อจำกัดด้านอินพุตและการดำเนินการที่อาจทำให้งานล้มเหลว
2. นำงานผ่านระบบติดตามที่บันทึกสถานะ จำกัดการกระทำ ตรวจสอบหลักฐาน และสร้างการส่งมอบงานที่สามารถเริ่มต้นใหม่ได้

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

สินค้าคงคลังเส้นทางปัจจุบัน

สแนปช็อตแคตตาล็อกของเราที่กระทบยอดกับเกตเวย์แล้วและบันทึกเมื่อ 2026-07-24 ประกอบด้วย model IDs แบบคิดราคาต่อโทเค็นที่ใช้งานได้ 25 รายการซึ่งทุกรายการติดแท็ก Reasoning และ Tools ในเมทาดาทาของแคตตาล็อก โดยมี 11 รายการที่ระบุหน้าต่างบริบทขนาด 1M-token และ 6 รายการที่รวมบริบท 1M การรองรับเครื่องมือ และอินพุตภาพไว้ด้วยกัน

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

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

สำหรับ ID ที่ถูกต้องตรงตัว อัตราที่แสดงอยู่ในปัจจุบัน และการเปลี่ยนแปลงในแคตตาล็อก ให้ตรวจสอบราคาแบบเรียลไทม์ก่อนใช้งานจริง คู่มือ Cursor, Cline, และ LiteLLM แสดง endpoint แบบ OpenAI-compatible เดียวกันในการตั้งค่าเฉพาะของแต่ละเครื่องมือ

เส้นทางตัวอย่างไม่ใช่สัญญาจ้างงาน

ตัวแทนอาจมีแบบจำลองที่ยอดเยี่ยม แต่ก็ยังอาจล้มเหลวในงานระยะยาวด้วยเหตุผลธรรมดาๆ ทั่วไปได้:

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

ปัญหาเหล่านั้นไม่ใช่ปัญหาเกี่ยวกับแบบจำลองภาษาเป็นหลัก แต่เป็นปัญหาเกี่ยวกับสถานะของงาน อำนาจ และการตรวจสอบความถูกต้อง

OpenAI อธิบายว่า Codex harness ของตนคือเลเยอร์ที่ประสานการทำงานระหว่างผู้ใช้ โมเดล และเครื่องมือในลูปของเอเจนต์ ทีมวิศวกรรมของบริษัทยังอธิบายว่างานที่เกี่ยวข้องกับเอเจนต์คือการกำหนดสภาพแวดล้อมและลูปป้อนกลับ ไม่ใช่เพียงการเขียนพรอมต์ที่ดีขึ้น อ่านคำอธิบายเรื่องลูปของเอเจนต์และรายงาน Harness Engineering.

ผลลัพธ์ในทางปฏิบัติก็ง่ายๆ ให้ถือว่าการเลือกแบบจำลองเป็นเพียงช่องหนึ่งในบัตรงาน ไม่ใช่แผนงานทั้งหมด

เริ่มต้นทุกงานที่ใช้เวลานานด้วยการ์ดงานที่มีขอบเขตชัดเจน

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

{
  "task_id": "repo-bugfix-01",
  "task_type": "repository_bugfix",
  "candidate_model": "LongCat-2.0",
  "escalation_model": "glm-5.2",
  "source_modalities": ["repository_text", "issue", "test_log"],
  "context_requirement": "1m",
  "needs_tools": true,
  "max_tool_rounds": 8,
  "max_attempts": 2,
  "max_cost_usd": "set per task",
  "acceptance_checks": [
    "targeted test passes",
    "diff stays inside the named module",
    "no unsupported claim in the handoff"
  ],
  "human_approval_required_for": ["production deploy", "data deletion", "credential change"]
}

สองฟิลด์แรกที่ควรให้ความสนใจไม่ใช่ชื่อโมเดล แต่คือ source_modalities และ acceptance_checks.

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

นี่คือจุดเริ่ม OpenAI-compatible ที่เล็กที่สุดสำหรับแบบจำลองผู้สมัครข้างต้น:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["CHINAAPI_API_KEY"],
    base_url="https://api.chinaapi.ai/v1",
)

response = client.chat.completions.create(
    model="LongCat-2.0",
    messages=[
        {"role": "system", "content": "Work only within the stated task card."},
        {"role": "user", "content": "Inspect the failing test before proposing a patch."},
    ],
)
print(response.choices[0].message.content)

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

ห้าวิธีควบคุมที่จะเปลี่ยนการวนลูปแชทให้กลายเป็นระบบที่กู้คืนได้

1 แผนผังงาน ไม่ใช่บทสนทนาแบบเลื่อนดู

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

2 หน่วยความจำที่มีที่มาและวันหมดอายุ

PLAN.md, STATE.md, และ HANDOFF.md จะมีประโยชน์ก็ต่อเมื่ออ้างอิงกลับไปยังข้อเท็จจริงเท่านั้น ให้บันทึกว่าข้อความแต่ละข้อมาจากที่ใด เขียนขึ้นเมื่อใด ใช้กับ branch ใด และควรตรวจสอบอีกครั้งเมื่อใด โค้ดปัจจุบัน คอมมิต พูลรีเควสต์ CI และการทดสอบ มีน้ำหนักเหนือกว่าบทสรุปเก่า

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

3 ร่องรอยที่สามารถอธิบายความล้มเหลวได้

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

4 ขอบเขตที่บังคับใช้ได้

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

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

5 จุดตรวจสอบที่เซสชันใหม่สามารถใช้งานได้จริง

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

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

บริบทที่ยาวนานช่วยได้ แต่ไม่ใช่ปัจจัยกำหนดทั้งหมด

เป็นเรื่องง่ายที่จะสับสนระหว่างสถาปัตยกรรมโมเดลกับการกำกับดูแลเอเจนต์ ทั้งสองอย่างมาบรรจบกันในการประชุมระยะยาว แต่แก้ปัญหาที่แตกต่างกัน

MoE เพิ่มความจุของพารามิเตอร์โดยเปิดใช้งานเพียงบางส่วนของโมเดลสำหรับแต่ละโทเค็น MLA ลดต้นทุนของ attention และการจัดการ KV cache สำหรับการอนุมานที่ใช้บริบทยาว รายงาน V3 ของ DeepSeek อธิบายทั้งสองเทคนิคไว้ในการออกแบบด้านประสิทธิภาพ อ่านรายงานทางเทคนิค.

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

บริบทที่ยาวนานจะตอบคำถามว่า “แบบจำลองสามารถเก็บรักษาข้อมูลได้มากขึ้นหรือไม่”

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

อย่าใช้สิ่งหนึ่งแทนอีกสิ่งหนึ่ง

เปลี่ยนความล้มเหลวให้เป็นข้อมูลสำหรับการประเมินผล ไม่ใช่เรื่องเล่าปรัมปรา

ร่องรอยความล้มเหลวของเจ้าหน้าที่เป็นวัตถุดิบ ไม่ใช่ตัวอย่างการฝึกอบรมสำเร็จรูป

ขั้นแรกให้จำแนกประเภทก่อน ไฟล์หน่วยความจำทำให้เอเจนต์เข้าใจผิดหรือไม่? การส่งต่อข้อมูลละเลยความเสี่ยงหรือไม่? ตัวกำหนดตารางเวลาทำงานแบบขนานกับงานที่ไม่ถูกต้องหรือไม่? เอเจนต์ข้ามหลักฐาน CI ไปหรือไม่? โมเดลล้มเหลวภายในสัญญาการทำงานที่ถูกต้องหรือไม่? แต่ละประเภทแนะนำการแก้ไขที่แตกต่างกัน เช่น การตรวจสอบความทันสมัย ฟิลด์จุดตรวจสอบ การเชื่อมต่อ การประเมิน อินเทอร์เฟซเครื่องมือที่ดีขึ้น หรือกฎการกำหนดเส้นทางที่เปลี่ยนแปลง

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

สิ่งที่คู่มือนี้ไม่ได้กล่าวอ้าง

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

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

ขั้นตอนการทำงานในทางปฏิบัติอาจไม่ดูหรูหรา แต่เชื่อถือได้:

route by required inputs and constraints
→ bound the task with a card and acceptance checks
→ execute under permissions, trace, and budgets
→ checkpoint verified facts for recovery
→ convert recurring failures into evals and guardrails

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

แหล่งที่มาและวิธีการ

• ข้อเท็จจริงเกี่ยวกับแคตตาล็อกของ ChinaAPI ในบทความนี้มาจากสแนปช็อต models-data.json ที่กระทบยอดกับเกตเวย์แล้วและบันทึกเมื่อ 2026-07-24 ตัวเลขจำนวนต่าง ๆ สะท้อนฟิลด์ในสแนปช็อตนั้น ไม่ได้เป็นการรับประกันคุณภาพหรือความพร้อมใช้งาน
• OpenAI เปิดเผยวงจรการทำงานของเอเจนต์ Codex
• OpenAI, Harness Engineering
• Claude Code, สร้างตัวแทนย่อยแบบกำหนดเอง
• รายงานทางเทคนิค DeepSeek-V3