เจาะลึก 3 รูปแบบการรัน Agent Loop: เหตุใด Harness จึงสำคัญกว่า Model และผลต่อต้นทุน Inference

ทีมพัฒนาส่วนใหญ่มักให้ความสำคัญกับการตัดสินใจเลือกโมเดล (Model) ที่จะนำมาใช้งาน แต่ข้อมูลจากเอกสารวิศวกรรมด้าน Harness กลับชี้ให้เห็นมุมมองที่ต่างออกไป ใน การทดลอง Terminal-Bench ของ LangChain พบว่าการเปลี่ยนเพียงตัว Harness โดยใช้โมเดลเดิมตลอดการทดสอบ สามารถเลื่อนอันดับ Coding Agent จากประมาณอันดับที่ 30 ขึ้นมาติด Top 5 ได้อย่างน่าทึ่ง

ผลลัพธ์นี้เปลี่ยนมุมมองต่อการออกแบบระบบใหม่ หาก Harness คือตัวกำหนดคุณภาพ วิธีการรัน Loop จึงกลายเป็นหัวใจสำคัญของการตัดสินใจด้านสถาปัตยกรรม ไม่ใช่เพียงรายละเอียดการปรับใช้ทั่วไป หลักสูตร Open-source ของ Paul Iusztin ที่ชื่อว่า Building a Coding Agent From Scratch ได้สร้าง Python Agent ชื่อ Decode ซึ่งเผยแพร่ผ่าน Decoding AI โดยมีการแยกโหมดการรันออกเป็น 3 รูปแบบที่มีลักษณะ Latency และความเหมาะสมกับผู้ให้บริการ Inference ที่แตกต่างกัน

หนึ่งแกนหลักแบบ Headless กับสามรูปทรงการใช้งาน

ศูนย์กลางของระบบคือ Headless Harness ที่ไม่มี Interface เป็นของตัวเอง ภายในจะรัน Agent Loop พื้นฐานที่ทุก Harness ใช้งานร่วมกัน ประกอบด้วย LLM เลือกการดำเนินการ (Action), เครื่องมือ (Tool) ทำงาน และส่งผลการสังเกต (Observation) กลับมา โดยข้อมูลทั้งหมดจะถูกจัดการผ่าน Context Window

ตัว Agent เองนั้นมีขนาดกะทัดรัดมาก ใน Decode มันคือการนิยาม Pydantic AI ความยาวเพียง 20 บรรทัด ส่วนองค์ประกอบอื่นๆ อย่างหน่วยความจำ (Memory), ทักษะ (Skills), Sandbox และการจัดการการตอบกลับ ล้วนเป็นส่วนการทำงานของ Harness ทั้งสิ้น

จากนั้น Interface จะถูกเชื่อมต่อเข้ากับแกนหลัก และนี่คือจุดที่โหมดทั้ง 3 ปรากฏขึ้น:

โหมด 1: Interactive, online

Terminal UI จะเชื่อมต่อกับ Session เดียวที่ทำงานแบบสดในหน่วยความจำ โดยส่งเหตุการณ์กลับผ่าน Async Generators เป็นรูปแบบ Stream เมื่อ Token มาถึง ปัญหาหลักของโหมดนี้คือการควบคุม (Steering) หากมีการพิมพ์แทรกขณะเครื่องมือกำลังทำงาน อาจทำให้รอบการทำงานเสียหาย

Decode แก้ปัญหานี้ด้วย Steering Queue และ Priority Gate เพื่อพักข้อมูลอินพุตและแทรกเข้าสู่ Loop ในช่วงที่ปลอดภัยเท่านั้น คือช่วง MODEL_REQUEST ก่อนเรียกโมเดลครั้งถัดไป และ WOULD_STOP เมื่อสิ้นสุดรอบการทำงาน โดยรองรับการควบคุมผ่าน Enter ปกติ, Alt+Enter เพื่อจองคิวถัดไป และ Esc เพื่อยกเลิกงานอย่างเป็นระบบ โหมดนี้จึงเหมาะกับ API แบบ Hosted ที่มี Latency ต่ำเนื่องจากมีผู้ใช้เฝ้ารอผลลัพธ์

โหมด 2: Remote, offline

โหมด Remote จะรันแบบ Headless บนเซิร์ฟเวอร์ผ่าน Agent Runtime โดย Decode ใช้ Kitaru ของ ZenML บนระบบ GCP และรัน Agent บน Modal โหมดนี้เน้นการทำงานขนานกันเพื่อจัดการ Backlog ปริมาณมาก

ระบบจะบันทึกความคืบหน้าทีละขั้นตอน ทำให้ Sandbox ที่หยุดทำงานสามารถกลับมาทำต่อได้ทันทีโดยไม่ต้องเริ่มใหม่ หากต้องรออินพุตจากมนุษย์ งานจะถูกแช่แข็งไว้เพื่อไม่ให้สิ้นเปลืองทรัพยากร Compute ตัวชี้วัดสำคัญของโหมดนี้คือปริมาณงานต่อดอลลาร์ (Throughput per dollar) ไม่ใช่ความเร็วของ Token แรก

โหมด 3: Async, online

เป็นรูปแบบลูกผสมระหว่างสองโหมดแรก โดย Session แบบสดจะส่งมอบงานไปยังคิว (Job Queue) และส่งคืนผลลัพธ์ทันที เวิร์กโฟลว์เบื้องหลังจะค่อยๆ จัดการการเรียก LLM และส่งผลกลับมาในภายหลัง เช่น การทำงานของ Agent ใน Slack หรือระบบรีวิว PR อัตโนมัติ ซึ่งการคิดค่าบริการจะใกล้เคียงกับรูปแบบ Batch

ทำไมผู้ให้บริการจึงเปลี่ยนไปตามโหมดการใช้งาน

รูปแบบต้นทุนจะผันแปรตามความต้องการด้าน Latency ซึ่งมีส่วนต่างมหาศาล ตัวอย่างเช่น การประมวลผลเอกสาร 1,000 ฉบับผ่าน Frontier API อาจมีค่าใช้จ่ายสูงถึง 97 ดอลลาร์ แต่หากทำแบบ Batched บน Serverless GPU จะใช้เงินเพียงประมาณ 13 ดอลลาร์ เท่านั้น

ในทางกลับกัน หากรัน Interactive Agent บน GPU ประสิทธิภาพสูงอย่าง H200 ผ่าน Modal ซึ่งคิดราคาตามเวลาใช้งาน การเปิดเครื่องทิ้งไว้ข้ามคืนเพื่อรอการยืนยันจากมนุษย์เพียงอย่างเดียวอาจทำให้เสียค่าใช้จ่ายฟรีถึง 45 ดอลลาร์ ดังนั้นงานแบบ Interactive จึงควรจ่ายตามจำนวน Token ส่วนงาน Offline ควรจ่ายตามชั่วโมง GPU เพื่อประสิทธิภาพสูงสุด

ประเด็นสำคัญที่ต้องพิจารณาคือการเลือกระหว่าง Serverless กับ Reserved Capacity จาก การวิเคราะห์ของ Modal พบว่าระบบ Serverless จะคุ้มค่ากว่าเมื่ออัตราส่วนการใช้งานช่วง Peak สูงกว่าค่าเฉลี่ยมากๆ ซึ่งปกติในงาน Agentic Development มักมีการใช้งานจริง (Utilization) ต่ำกว่า 30% ทำให้ Serverless กลายเป็นตัวเลือกที่ประหยัดกว่าในระยะยาว

สรุปประเด็นสำคัญ

Harness สำคัญกว่า Model: การปรับแต่ง Harness ที่ดีช่วยยกระดับประสิทธิภาพ Agent ได้อย่างมหาศาลโดยไม่ต้องอัปเกรดโมเดล
Interactive Mode: ถูกจำกัดด้วย Latency ต้องมีการควบคุมคิวอินพุตที่แม่นยำ เหมาะกับการจ่ายตามจำนวน Token
Offline & Async Mode: เน้นปริมาณงาน (Throughput) การจ่ายตามชั่วโมง GPU หรือแบบ Batch จะช่วยประหยัดต้นทุนได้มากกว่า 7-8 เท่า
Serverless คือทางออก: สำหรับงาน Agent ที่มีความต้องการใช้งานไม่สม่ำเสมอ Serverless ให้ความคุ้มค่าสูงกว่าการจอง GPU แบบรายเดือน

แหล่งที่มา:

Building a Coding Agent From Scratch (Lesson 1) The Bare-Bones Coding Agent Loop (Lesson 2) From a Raw Shell to a Sandboxed Coding Agent (Lesson 3) Course repository Modal pricing How to price serverless GPUs LangChain: The anatomy of an agent harness