แนวคิดที่ Anthropic ยกมาคือ ให้ Sonnet 5 เป็น executor ทำงานหลักใน loop ปกติ แล้วให้ Fable 5 เป็น advisor ที่ถูกเรียกเฉพาะตอนต้องใช้ judgment สูง เช่น วางแผน ตัดสินใจ architecture แก้ทางเมื่อเริ่มหลุด หรือ review ก่อนจบงาน ผมว่ามันเป็น pattern ที่ practical มาก เพราะมันไม่ได้พยายามลดคุณภาพด้วยการใช้โมเดลเล็กอย่างเดียว แต่ใช้โมเดลฉลาดให้ถูกจังหวะมากกว่า

หมายเหตุ: บทความนี้ฟิวส์กับเอเจ้นชมพูช่วยกันเรียบเรียง โดยอิงจากโพสต์ของ ClaudeDevs บน X, เอกสาร Advisor tool ของ Anthropic และ Claude Cookbook แล้วนำมาตีความเป็นแนวทางใช้งานจริงสำหรับคนทำ AI agent / coding agent

ต้นทางของเรื่องนี้สรุปไว้สั้นมากว่า หนึ่งใน pattern ที่ Anthropic ใช้กับ Fable 5 คือ “ใช้ Fable 5 เป็น advisor” โดย executor อย่าง Sonnet 5 จะเรียก Fable 5 เพื่อขอคำแนะนำ ดังนั้นการทำงานส่วนใหญ่จะใช้ token ไปกับ executor ที่ Sonnet 5 ทำมากกว่า

ต้องเข้าใจก่อนว่า agent workload ไม่ต้องใช้โมเดลฉลาดทุกงาน

เวลาพูดถึง AI coding agent หรือ agent ที่ทำงานหลาย step ผมคิดว่าหลายคนมักติดกับดักว่า “ใช้โมเดลฉลาดสุดไปเลยจะได้จบ” ซึ่งจริงในบางงาน แต่ไม่จริงเสมอไป โดยเฉพาะงานยาวๆ ที่มี token จำนวนมากถูกใช้ไปกับงาน mechanical มากกว่า reasoning

ในงานหนึ่งๆ มักมี 2 ส่วนปนกัน:

• ส่วนที่ต้องคิดจริง: แตกโจทย์, ตีความ requirement, เลือก architecture, ประเมิน trade-off, หาทางออกตอนติดปัญหา
• ส่วนที่ต้องทำเยอะ: อ่านไฟล์, อ่านเว็บ, grep โค้ด, ดู log, แก้ไฟล์, รัน test, สรุป output จาก tool

ถ้าใช้โมเดลระดับ frontier ทำทั้งสองส่วนทั้งหมด ก็โครตจะเปลือง token เลยครับ เพราะถูกใช้ไปกับงานทั่วไปที่ไม่ต้องการ frontier reasoning ทุกบรรทัด เช่น อ่านหน้าเว็บยาวๆ หรือไล่ log หลายพันบรรทัด ตรงนี้เองที่ทำให้ค่าใช้จ่ายสูงโดยไม่จำเป็น

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

หรือเทียบในงานก่อสร้าง ก็เหมือนเอาวิศะไปก่ออิฐฉาบปูนแทนคนงานก่อสร้าง แทนที่วิศวะจะออกแบบ วางแผน และคนงานจะเป็นคนทำ

เแนวคิด: Sonnet 5 เป็นคนทำงานหลัก ส่วน Fable 5 เป็นคนให้คำปรึกษา

จาก diagram ในโพสต์ของ ClaudeDevs โครงสร้างคือ Sonnet 5 ทำหน้าที่ executor และรัน main loop ทุก turn ส่วน Fable 5 เป็น advisor ที่ถูกเรียกผ่าน tool call เฉพาะเมื่อจำเป็น พูดง่ายๆ คือ Sonnet ทำงานหนัก แต่ Fable ช่วยคิดตอนที่ต้องคิดอย่างมีเหตุมีผล

เอกสาร Advisor tool ของ Anthropic อธิบายแนวคิดนี้ว่า executor model ที่เร็วกว่า/ต้นทุนต่ำกว่า สามารถ consult advisor model ที่ฉลาดกว่า mid-generation ได้ โดย advisor จะเห็น conversation transcript ทั้งหมด แล้วส่งคำแนะนำกลับมาให้ executor ทำงานต่อ

จุดที่ผมว่าสำคัญคือ advisor ไม่ได้มาแทน executor แต่เป็นเหมือน reviewer หรือ architect ที่ถูกเรียกในจังหวะที่ควรเรียก ทำให้เรายังได้คุณภาพจากโมเดลใหญ่ในการตัดสินใจสำคัญๆ แต่ไม่ต้องจ่ายราคาโมเดลใหญ่กับทุกการทำงานง่ายๆ หลายงาน

แล้ว Advisor tool ทำงานยังไง?

เมื่อเราเพิ่ม advisor tool เข้าไปใน tools array แล้ว ตัว executor จะตัดสินใจเองว่าจะเรียก advisor เมื่อไรเหมือน tool อื่นๆ แต่การ call นี้เกิดฝั่ง server ภายใน request เดียว ไม่ใช่ client ต้อง orchestration เองหลายรอบ

• executor สร้าง server_tool_use ชื่อ advisor
• server ส่ง transcript ทั้งหมดให้ advisor model
• advisor ส่งคำแนะนำกลับมาเป็น advisor_tool_result
• executor ใช้คำแนะนำนี้ทำงานต่อจนจบ

ตัวอย่างแบบย่อจากเอกสาร Anthropic:

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=4096,
    betas=["advisor-tool-2026-03-01"],
    tools=[
        {
            "type": "advisor_20260301",
            "name": "advisor",
            "model": "claude-opus-4-8",
        }
    ],
    messages=[
        {
            "role": "user",
            "content": "Build a concurrent worker pool in Go with graceful shutdown.",
        }
    ],
)

ถ้านำ concept นี้มาเทียบกับโพสต์ Fable 5 ภาพในหัวจะประมาณนี้:

tools=[
    {
        "type": "advisor_20260301",
        "name": "advisor",
        "model": "claude-fable-5",
        "max_tokens": 2048,
        "max_uses": 2,
    }
]

ตรงนี้ max_tokens กับ max_uses สำคัญมาก เพราะถ้าเปิด advisor ไว้แบบไม่จำกัด มันอาจกลายเป็น “เรียกโมเดลแพงบ่อยขึ้น” แทนที่จะช่วยประหยัด token

วิธีใช้ให้ประหยัด token จริง

1. ให้ executor อ่านบริบทก่อน แล้วค่อยเรียก advisor

ผมคิดว่าเราไม่ควรเรียก Fable 5 ตั้งแต่ครั้งแรกที่ยังไม่รู้อะไรเลย เพราะคำแนะนำจะกว้างเกินไป วิธีที่ดีกว่าคือให้ Sonnet 5 อ่านทำความเข้าใจบริบทแรกของเราก่อน เช่น requirement, โครง repo, error log หรือไฟล์หลัก แล้วค่อยเรียก Fable 5 เพื่อช่วยวางแผน

2. ใช้ advisor ในจุดที่ตัดสินใจผิดแล้วแพง

จุดที่คุ้มจะเรียก advisor คือจุดที่ถ้าคิดผิดแล้วต้องแก้งานเยอะ เช่น:

• เลือก architecture หรือ migration strategy
• ตีความ requirement ที่กำกวม
• เจอ test fail ซ้ำๆ แล้วแนวทางเดิมแก้ไม่ได้ หรือไม่ครอบคลุม
• ก่อนจบงาน เพื่อ review ว่าหลุด security, edge case หรือ test อะไรไหม

3. จำกัดจำนวนครั้งด้วย max_uses

ถ้างานหนึ่งควรเรียก advisor แค่ 1–2 ครั้ง ก็ตั้ง max_uses ไว้เลย จะช่วยไม่ให้ executor เรียก advisor ถี่เกินไปใน request เดียว

4. จำกัดคำตอบของ advisor ด้วย max_tokens

เอกสาร Anthropic แนะนำจุดเริ่มต้นที่ max_tokens: 2048 สำหรับ advisor output cap โดยระบุว่าในการทดสอบของเขา การตั้ง cap นี้ลด output ของ advisor ได้มากเมื่อเทียบกับการไม่ตั้ง และยังไม่เห็นว่าคุณภาพลดลงเท่าไรอย่างชัดเจน (quality degradation) แต่ประโยคสำคัญคือ เราต้องตรวจสอบกับ workload ของตัวเองเสมอนะ เพื่อป้องกันความผิดพลาด เนื่องจากจำกัด token (ผมเคยเจอบ่อยว่า output งานออกมาได้ไม่ถูกต้อง หรือโค้ดไม่ครบ)

5. เปิด caching เฉพาะงานที่เรียก advisor หลายครั้ง

ใน docs ระบุว่า advisor-side caching จะเริ่มคุ้มเมื่อคาดว่าจะมี advisor call ประมาณ 3 ครั้งขึ้นไปใน conversation เดียว ถ้างานสั้นๆ เรียกครั้งเดียวหรือสองครั้ง การเปิด cache อาจไม่คุ้ม เพราะ cache write ก็มีต้นทุนของมันเอง

อีกแนวคิดที่คล้ายกัน คือ Plan big, execute small

ใน Claude Cookbook เรื่อง Coordinator pattern Anthropic อธิบายอีก pattern ที่คล้ายกันมาก คือให้โมเดลใหญ่เป็น coordinator สำหรับวางแผนและสังเคราะห์คำตอบ ส่วน worker model ที่ถูกกว่าเป็นคนอ่านเว็บหรือดึงข้อมูลจำนวนมากใน context ของตัวเอง

ในการทดลองที่ Anthropic ยกตัวอย่าง ทีมแบบ split ราคาจะถูกลงกว่าประมาณ 2.5x และทำงานเร็วขึ้นประมาณ 3x โดยจำนวน input token 84–98% ถูกคิดที่ worker ที่ใช้ราคา Token ถูกกว่า

แต่ๆๆ เขาบอกว่า นี่แค่ตัวอย่างนะ อย่าเอาตัวเลขนี้ไปใช้อ้างอิงว่าทุกงานจะประหยัดเท่านี้ เพราะมันขึ้นกับ workload แต่ละงาน

แต่โครงสร้างวิธีการทำแบบนี้ก็ชัดเจนดี คือ งานอ่านเยอะๆ ให้ worker ทำ ส่วนโมเดลใหญ่แตะเฉพาะ planning/synthesis

จากที่อ่าน ถ้าผมจะใช้จริง จะวาง flow แบบนี้

1. เริ่มด้วย Sonnet 5: ให้ทำงานหลัก อ่านไฟล์ เรียก tool แก้โค้ด รัน test
2. Orientation: เก็บบริบทขั้นต่ำก่อน เช่น requirement, repo structure, error หลัก
3. Advisor call แรก: เรียก Fable 5 ให้ช่วยวางแผนและชี้ risk
4. Execute: ให้ Sonnet 5 ลงมือทำตาม plan โดยไม่เรียก advisor ทุกจุด
5. Replan เมื่อจำเป็น: ถ้า error วนหรือทางเดิมไม่ไปต่อ ค่อยเรียก Fable 5 อีกครั้ง
6. Review ก่อนจบ: เรียก advisor ช่วยดูว่าตกหล่น test, security, edge case หรือ assumption อะไรไหม
7. Finish: ให้ executor สรุปผลพร้อม evidence จาก test/diff/tool output

ต้องบอกว่า ผมยังแค่คิดนะ เพราะยังไม่มีโจทย์ซับซ้อนพอที่จะใช้ Fable ทำงาน และยังไม่อยากลองรันเทียบ เพราะต้องทำหลายครั้ง อาจจะเสีย Token เยอะ ฮาา, ไว้รอมีผลการทดสอบจากผู้กล้า หรือได้ลองจริงๆ แล้วจะเอามาเล่าให้ฟังอีกที หรือหากใครลองแล้วก็มาแชร์กันหน่อยครับ

ข้อควรระวัง

• งานเล็กมากอาจไม่คุ้ม: ถ้าเป็น single-turn Q&A หรือแก้ typo เล็กๆ advisor อาจเพิ่ม overhead มากกว่าประโยชน์
• ต้องวัดกับ workload จริง: ตัวเลขประหยัด token ไม่ใช่ค่าคงที่ ขึ้นกับชนิดงานและความยาวของ context
• อย่าแตกงานย่อยจนเกินพอดี: ใน cookbook เองก็เตือนว่าการแตก brief แคบเกินไปมี floor cost ของ worker thread (ขออธิบายเพิ่มเติมครับ: มันคือต้นทุนขั้นต่ำต่อ worker thread หมายถึง ทุกครั้งที่สร้าง worker หรือ sub-agent ใหม่ มันมี “ต้นทุนตั้งต้น” เสมอ ไม่ว่าจะงานเล็กหรือใหญ่ เช่น เปิด session ,รับ prompt, อ่าน context, เรียก Skill)
• advisor แก้โจทย์เท่าที่ได้รับจาก context: ถ้า executor ยังไม่ได้อ่านของสำคัญก่อนเรียก advisor คำแนะนำก็อาจกว้างหรือผิดทิศได้ เช่นเราใส่บริบทไม่ครบหรือไม่เข้าใจให้ advisor เองแต่แรก (นั่นคือเหตุผลของ Anthopic ว่าทำไมไม่ควรเอาตัวฉลาดมารับงานก่อน)
• ต้อง track cost แยก: usage ของ advisor อยู่ใน usage.iterations เป็น advisor_message เพราะถูก bill คนละ rate กับ executor

ผมขอขยายความข้อสุดท้ายนิดนึงคือ มันไม่สามารถคิด token cost แบบ usage.input_tokens + usage.output_tokens ทั่วไปนะ เพราะอาจจะเข้าใจผิดคิดว่าแพงทั้งหมด แต่ควรคิดจาก

total_cost = executor_tokens × ราคา Sonnet 5 + advisor_tokens × ราคา Fable 5

ดังนั้น ใน Anthropic API ที่ส่งค่า usage.iterations กลับมา เราต้องคิดราคาแยกตาม type ด้วย ว่าอะไรคือ executor (message) และอะไรคือ advisor (advisor_message)

สรุป

ผมคิดว่า “Fable 5 เป็น advisor” เป็นแนวทางที่น่าลองมากสำหรับ agent workflow ที่เราจะให้มันทำงานยากๆ หรือต้องใช้การตัดสินใจอย่างมีเหตุมีผลสูงมาก ส่วนงานง่ายๆ อย่างการ อ่าน/ทำ/ตรวจซ้ำ ก็ให้ใช้โมเดลรองๆ ลงมา ทำก็คิดว่าเพียงพอแล้ว (อย่างน้องชมพูที่ผมให้แชต ก็ใช้แค่ ChatGPT mini แต่หาข้อมูลและเขียนบทความ ผมจะใช้ ChatGPT ปกติ

อ้างอิง

• ClaudeDevs on X — Fable 5 as advisor pattern
• Anthropic Claude Platform Docs — Advisor tool
• Anthropic Claude Cookbooks — Coordinator pattern: big models for planning, small models for execution

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

ผมเลยอยากเอาบทความนี้มาเล่าในมุมที่นำไปต่อยอดได้จริง โดยเฉพาะสำหรับคนที่กำลังสนใจเรื่อง AI Agent, coding agent, workflow automation หรือระบบที่ให้ AI ทำงานต่อเนื่องแทนการ prompt ทีละครั้ง

หมายเหตุ: บทความนี้ฟิวส์กับเอเจ้นชมพู ได้เรียบเรียงและต่อยอดจากบทความต้นฉบับของ Anthropic Engineering เรื่อง Harness design for long-running application development เขียนโดย Prithvi Rajasekaran

Harness คืออะไรในบริบทของ AI Agent

ถ้าแปลแบบง่ายๆ harness คือชุดเครื่องมือที่หุ้ม AI Agent อีกทีเพื่อให้มันทำงานได้เป็นระบบ ไม่ใช่แค่โยน prompt ให้ model แล้วหวังว่ามันจะทำทุกอย่างถูกต้องเอง

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

Harness ของ AI Agent อาจรวมหลายอย่าง เช่น

• วิธีแตกงานใหญ่ให้เล็กลง
• วิธีให้ agent วางแผนก่อนลงมือทำ
• วิธีเก็บ state ของงานไว้นอก context window
• วิธีส่งต่องานระหว่าง agent หรือ session
• วิธีตรวจคุณภาพของงานที่ทำเสร็จ
• วิธีบังคับให้ agent แก้ไขงานตาม feedback
• วิธีหยุดงานเมื่อถึงเงื่อนไขบางอย่าง

พูดอีกแบบคือ ถ้า model คือสมอง harness ก็คือระบบการทำงานรอบสมองนั้น

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

จริงๆ ลองทดสอบได้ง่ายๆ ครับ ถ้าเอา prompt ใส่ใน Claude Web ตั้งโมเดลเป็น Opus 4.8 กับใส่ในระบบแชตแจกฟรีเช่น Langflow โดยต่อโมเดล Opus 4.8 ผ่าน Claude API, คำตอบที่ได้ออกมาจะไม่เหมือนกัน แม้ว่าใช้สมอง Opus 4.8 เหมือนกัน (เรื่องนี้ 9arm ก็มีเล่าให้ฟังตอนทำ 9arm AI Passport)

ปัญหาของ Agent ที่ให้ทำงานยาวๆ

บทความนี้เริ่มจากโจทย์ที่ Anthropic ทดลองอยู่ 2 เรื่อง คือทำให้ Claude สร้าง frontend design ที่มีคุณภาพสูงขึ้น และทำให้ Claude สร้าง application เต็มรูปแบบได้โดยไม่ต้องมีมนุษย์เข้าไปช่วยระหว่างทาง

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

1. Context เต็มแล้วเริ่มหลุด

งานที่ยาวหลายชั่วโมงจะมีข้อมูลสะสมเยอะมาก ตั้งแต่ requirement, decision, bug, code, test result, feedback ไปจนถึงสิ่งที่ลองแล้วไม่เวิร์ก ถ้าทุกอย่างถูกกองอยู่ใน context window เดียว สุดท้าย agent จะเริ่มจับประเด็นไม่ครบ

Anthropic ยังพูดถึงอาการที่น่าสนใจชื่อว่า context anxiety คือ model เริ่มเหมือนรู้ตัวว่าบริบทใกล้เต็ม แล้วพยายามรีบ wrap up งานก่อนเวลา ทั้งที่งานจริงยังไม่เสร็จดี

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

2. Agent มักตรวจงานตัวเองใจดีเกินไป

อีกปัญหาหนึ่งที่ตรงมากคือ self-evaluation

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

งาน coding ยังพอมี test ช่วยจับได้บ้าง แต่งานอย่าง design, UX, product completeness หรือบทความนี่ตรวจยากกว่าเยอะ เพราะไม่มีคำตอบแบบ pass/fail ชัดเจน

Anthropic เลยใช้แนวทางแยก agent ที่สร้างงาน ออกจาก agent ที่ตรวจงาน ซึ่งผมคิดว่าเป็น pattern ที่ควรใช้จริงในระบบ agent ที่ต้องการคุณภาพ

แนวคิดหลัก: Planner, Generator, Evaluator

โครงสร้างที่บทความนี้พูดถึงคือการแบ่ง agent ออกเป็น 3 บทบาทหลัก

ถ้ามองในเชิงทีมซอฟต์แวร์ มันก็คล้ายๆ การแยก role ในทีมจริง

• Planner ทำหน้าที่คล้าย product/tech lead
• Generator ทำหน้าที่คล้าย developer
• Evaluator ทำหน้าที่คล้าย QA, reviewer และ product tester

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

ทำเรื่อง subjective ให้ตรวจได้

ส่วนที่ผมชอบมากในบทความคือการทดลองกับ frontend design เพราะ design เป็นเรื่องที่วัดยาก

Anthropic พบว่า Claude มักสร้าง UI ที่ technically ใช้งานได้ แต่ดู generic มาก เช่น layout ปลอดภัย card เยอะๆ gradient เดิมๆ หรือหน้าตาที่ดูเหมือน AI สร้างแบบไม่มี character

เขาเลยสร้าง evaluator ที่มี criteria ชัดเจน เช่น

• Design quality งานดูเป็นภาพรวมเดียวกันไหม
• Originality มีความคิดสร้างสรรค์จริงไหม หรือเป็น template
• Craft typography, spacing, contrast, color harmony ดีไหม
• Functionality ผู้ใช้เข้าใจและใช้งานได้จริงไหม

จุดสำคัญคือเขาไม่ได้ถามกว้างๆ ว่า “สวยไหม” แต่แตกคำว่าสวยให้กลายเป็น rubric ที่ตรวจได้

ผมว่านี่เอาไปใช้กับงานอื่นได้เยอะมาก เช่นบทความดีไหม requirement ชัดไหม dashboard ใช้งานง่ายไหม หรือแม้แต่ระบบ automation ที่ agent สร้างขึ้นมามี failure mode อะไรบ้าง ถ้าเราไม่มี rubric evaluator ก็จะตอบกว้างๆ และหลุดง่าย

Context Reset ไม่ใช่แค่ล้างแชท แต่ต้องมี Handoff

อีกเรื่องที่สำคัญมากคือ structured handoff

ถ้า agent ทำงานยาวจนต้องเริ่ม session ใหม่ หรือให้ agent ตัวใหม่มารับช่วงต่อ เราไม่ควรส่งต่อด้วย chat history ยาวๆ อย่างเดียว แต่ควรมี artifact ที่สรุปสถานะงานอย่างเป็นระบบ

handoff ที่ดีควรบอกอย่างน้อยว่า

• เป้าหมายของงานคืออะไร
• ทำอะไรเสร็จแล้ว
• ไฟล์ไหนถูกแก้
• คำสั่งไหนรันแล้ว
• ผลลัพธ์จริงคืออะไร
• ยังเหลือปัญหาอะไร
• next step คืออะไร

ถ้าเป็นงาน coding ก็ควรมี test result, git diff, known issue และคำอธิบาย decision ที่สำคัญด้วย

ในมุมผม นี่คือจุดที่ทำให้ agent system เริ่มจริงจังขึ้นมาก เพราะเราเริ่มย้าย source of truth จาก “บทสนทนา” ไปอยู่ใน “artifact” ที่อ่านซ้ำได้ ตรวจได้ และส่งต่อได้

Sprint Contract: ก่อนทำ ต้องรู้ก่อนว่า Done คืออะไร

อีกไอเดียที่น่าสนใจคือก่อนแต่ละ sprint ให้ Generator และ Evaluator ตกลงกันก่อนว่า sprint นี้จะทำอะไร และจะตรวจยังไงถึงเรียกว่าสำเร็จ

ผมมองว่านี่คือ acceptance criteria สำหรับ agent โดยเฉพาะ

ถ้าให้ agent “สร้างระบบ task management” เฉยๆ มันอาจทำหน้าจอสวย แต่ข้อมูลไม่ persist หรือ filter ใช้ไม่ได้ แต่ถ้ามี sprint contract เช่น

• สร้าง task ได้
• แก้สถานะ task ได้
• filter ตาม status ได้
• refresh แล้วข้อมูลยังอยู่
• Evaluator ต้องทดสอบผ่าน browser จริง

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

ผลลัพธ์ที่ Anthropic เจอ

บทความยกตัวอย่างให้ Claude สร้าง 2D retro game maker แล้วเทียบระหว่าง solo agent กับ full harness

full harness แพงกว่ามาก แต่คุณภาพต่างกันชัดเจน solo agent ทำหน้าตาได้บางส่วน แต่เกมเล่นจริงไม่ได้ดีนัก ส่วน full harness ทำ feature ได้ลึกกว่า polished กว่า และ play mode ใช้งานได้จริงกว่า

นี่เป็น trade-off ที่ต้องจำไว้ ไม่ใช่ว่าเราควรใช้ harness หนักๆ กับทุกงาน เพราะบางงาน single agent ก็พอ แต่ถ้างานสำคัญ งานซับซ้อน หรืองานที่ต้องการคุณภาพสูงมาก harness แบบนี้อาจคุ้ม

เมื่อ Model เก่งขึ้น Harness ก็ต้องเปลี่ยน

อีกประเด็นที่ผมชอบคือ Anthropic บอกว่าเมื่อ model รุ่นใหม่เก่งขึ้น บางส่วนของ harness ที่เคยจำเป็นอาจไม่จำเป็นอีกต่อไป

นี่เป็นความจริงที่สำคัญมาก ทุก component ใน harness คือสมมติฐานบางอย่างว่า model ยังทำเองได้ไม่ดีพอ เช่น ยังวางแผนไม่ดีพอ ยัง review ตัวเองไม่ดีพอ ยังทำงานยาวไม่ได้พอ หรือยังต้องแตกงานเป็น sprint เล็กๆ

แต่เมื่อ model ดีขึ้น สมมติฐานเหล่านี้อาจหมดอายุ

ดังนั้น harness ที่ดีไม่ควรเป็น pipeline แข็งๆ แต่ควรเป็นระบบที่ปรับได้ เช่น

• เปิดหรือปิด planner ได้
• เลือก evaluator แบบเบาหรือหนักได้
• ปรับจำนวนรอบ iteration ได้
• เลือกใช้ context reset หรือ compaction ได้
• ถอด component ที่ไม่ load-bearing ออกได้

ผมคิดว่านี่คือแนวคิดที่ดีมากสำหรับคนทำ agent platform เพราะเราไม่ได้ออกแบบระบบเพื่อ model รุ่นเดียว แต่ต้องออกแบบให้ evolve ตาม model ได้

ถ้าจะเอามาพัฒนาต่อ ผมจะเริ่มจากอะไร

ถ้าเอาแนวคิดนี้มาใช้กับระบบ agent ที่ผมกำลังทำอยู่ ผมคิดว่าสิ่งที่ควรเริ่มมีคือ 5 เรื่องนี้

1. Artifact-first workflow

อย่าให้ chat เป็นที่เก็บ state หลักของงาน แต่ให้ agent ทำงานผ่านไฟล์หรือ object ที่ชัดเจน เช่น

• SPEC.md
• PLAN.md
• TASKS.md
• STATE.md
• EVAL.md
• HANDOFF.md

ไฟล์เหล่านี้ทำให้ agent ตัวถัดไปอ่านต่อได้ และมนุษย์ก็ตรวจได้ด้วย

ซึ่งหากใครใช้ skill พวกทำ Spec Driven มันจะสร้างเอกสาร spec/plan/adr ให้อัตโนมัติ คอนเซ็ปประมาณนี้เลย

2. Maker กับ Checker ต้องแยกกัน

งานสำคัญไม่ควรให้ agent ตัวเดียวสร้างและรับรองงานตัวเอง ควรมี reviewer หรือ evaluator แยกออกมาเสมอ โดยเฉพาะงานที่ต้อง publish, deploy หรือกระทบข้อมูลจริง

3. Evaluator ต้องมี Rubric

rubric คือชุดเกณฑ์การให้คะแนน หรือเครื่องมือประเมินผลที่อธิบายระดับคุณภาพของชิ้นงาน

ดังนั้น Evaluator ที่ไม่มี rubric จะตรวจแบบลอยๆ และมักใจดีเกินไป rubric ที่ดีควรบอกว่าอะไรคือ pass, อะไรคือ fail, ต้องลอง edge case ไหน และอะไรที่ห้ามมองข้าม

4. Context Reset ต้องเป็น Feature ไม่ใช่ปล่อยให้แก้ตอนเต็ม

ถ้างานยาวพอ เราควรออกแบบไว้เลยว่า agent จะ reset ตอนไหน ส่งต่ออะไร และ agent ตัวใหม่ต้องอ่านอะไรบ้าง ไม่ใช่รอให้ context เต็มแล้วค่อยหาทางรอด

5. ต้องมี Stop Condition

Agent ที่ทำงานเองได้ต้องรู้ด้วยว่าเมื่อไรควรหยุด ถ้าไม่มี stop condition มันอาจวนแก้ไปเรื่อยๆ ใช้ token ใช้เวลา แต่คุณภาพไม่ได้ดีขึ้นตามสัดส่วน

ข้อควรระวัง

แนวทางนี้น่าสนใจมาก แต่ก็มีข้อควรระวังเยอะเหมือนกัน

• Cost สูงขึ้น เพราะใช้หลาย agent ทำงานหลายรอบ และต้องมี evaluation loop
• สร้างงานได้ช้าขึ้น เพราะงานบางอย่างต้องรอ browser test, QA หรือ iteration
• ซับซ้อนขึ้น เพราะต้องดูแล state, artifact, prompt, rubric และ orchestration
• Evaluator ก็พลาดได้ ถ้า rubric ไม่ดีหรือทดสอบไม่ลึกพอ
• Handoff ที่ไม่ดีอันตรายมาก เพราะ agent รุ่นถัดไปอาจสานต่อจากข้อมูลผิด

ดังนั้นผมคิดว่าควรใช้ harness หนักๆ เฉพาะงานที่คุ้มจริง เช่นงานที่มีผลลัพธ์สำคัญ งานที่ต้องใช้ซ้ำ หรืองานที่ถ้าพลาดแล้วเสียเวลามาก

สรุป

บทความนี้ทำให้ผมยิ่งเชื่อว่าอนาคตของ AI Agent ไม่ได้อยู่ที่ prompt อย่างเดียว แต่อยู่ที่การออกแบบ harness รอบๆ model ให้ดีพอ

Agent ที่ทำงานยาวได้จริงต้องมี plan ต้องมี state ต้องมี handoff ต้องมี evaluator ต้องมี rubric และต้องมีวิธีรู้ว่าเมื่อไรควรทำต่อหรือหยุด

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

สำหรับผม นี่เป็นทิศทางที่น่าทดลองมาก และน่าจะเป็นแกนสำคัญของระบบ agent รุ่นถัดไปที่ไม่ได้แค่ “ตอบเก่ง” แต่ “ทำงานเป็นระบบ” ได้จริง