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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{
  "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 หน่วยความจำที่มีที่มาและวันหมดอายุ

แผน.ม., รัฐ.ม., และ ส่งต่อ.md ข้อมูลสรุปจะมีประโยชน์ก็ต่อเมื่อมันอ้างอิงถึงข้อเท็จจริงเท่านั้น บันทึกว่าข้อความนั้นมาจากที่ใด เขียนเมื่อใด เกี่ยวข้องกับสาขาใด และควรตรวจสอบอีกครั้งเมื่อใด โค้ดปัจจุบัน การคอมมิต คำขอพูล CI และการทดสอบมีความสำคัญมากกว่าข้อมูลสรุปเก่าๆ

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

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

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

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

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

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

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

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

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

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

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

MoE เพิ่มความจุของพารามิเตอร์ในขณะที่เปิดใช้งานเพียงบางส่วนของโมเดลสำหรับโทเค็น MLA ลดต้นทุนของความสนใจและการจัดการแคช KV สำหรับการอนุมานบริบทที่ยาว รายงาน V 3 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 ตาล็อกในบทความนี้มาจากเกตเวย์ที่ได้รับการตรวจสอบความถูกต้องแล้ว แบบจำลอง-ข้อมูล json ภาพรวมที่บันทึกไว้เมื่อวันที่ 2026-07-24 จำนวนที่แสดงสะท้อนถึงฟิลด์ในภาพรวมนั้น ไม่ใช่การรับประกันคุณภาพหรือความพร้อมใช้งาน
• OpenAI เปิดเผยวงจรการทำงานของเอเจนต์ Codex
• OpenAI, Harness Engineering
• Claude Code, สร้างตัวแทนย่อยแบบกำหนดเอง
• รายงานทางเทคนิค DeepSeek-V3