เรื่องนี้ตรงกับสิ่งที่ผมเองก็กำลังทดลองและพัฒนาอยู่เหมือนกัน โจทย์คือจะทำยังไงให้ 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 รุ่นถัดไปที่ไม่ได้แค่ “ตอบเก่ง” แต่ “ทำงานเป็นระบบ” ได้จริง