การออกแบบ Agent Harness: เลือกโมเดลที่เหมาะสม

Model routing เป็นเรื่องของการควบคุมงานปฏิบัติการ ไม่ใช่การแข่งขัน benchmark ความเป็นส่วนตัวและ data residency ต้องกำหนดกลุ่มโมเดลที่อนุญาตก่อน จากนั้นจึงวัดความสำเร็จของงานและคุณภาพ แล้วค่อยปรับ token, latency และ cost โมเดล local มักต้องใช้การแยกงาน retrieval และ deterministic verification ที่เข้มกว่า

Harness คือหน่วยที่สร้างผลงาน

Enterprise Agent ไม่ใช่โมเดลกับ system prompt ยาว ๆ แต่คือ harness ที่รวม intake, context, policy gate, model, tool, state, verification, retry, observability และ escalation โมเดลเป็นเพียงส่วนที่เปลี่ยนได้ เราไม่ได้เลือก “โมเดลที่ดีที่สุด” แต่เลือกเส้นทางที่อนุญาตและพางานไปถึงสถานะธุรกิจที่ตรวจสอบแล้ว ชั้นปฏิบัติการ AI แบบ thread ช่วยคง routing, state, authority และ evidence เมื่อเปลี่ยน executor

Gate หนึ่ง: Privacy, Residency และข้อกำหนดตามสัญญา

โปรไฟล์ของแต่ละ task ครอบคลุมการจัดชั้นข้อมูล ภูมิภาคประมวลผลและจัดเก็บ retention, logging, training use, subprocessor, การโอนข้ามแดน encryption, identity, audit, สิทธิ์ production และการนำเอกสาร retrieval ออกจากสภาพแวดล้อมควบคุม endpoint ที่ไม่ผ่านต้องถูกตัดออกก่อนประเมินคุณภาพ

Residency ครอบคลุมไฟล์ชั่วคราว index, trace, review queue และ backup ไม่ใช่แค่ endpoint การลบชื่อแต่คงรหัสเฉพาะไว้ไม่ใช่ anonymization gate นี้สร้างตัวเลือกที่อนุญาต แต่ยังไม่เลือกผู้ชนะ

Gate สอง: ความสำเร็จของ Task ก่อนคุณภาพ

ความสำเร็จคือคำตอบที่มีแหล่งอ้างอิงตรวจได้ record ที่ตรง schema และเชื่อม source span หรือ action ที่ผ่าน dry run การอนุมัติ และ readback ข้อความสวยแต่ schema ผิด ใช้ tool ต้องห้าม หรือไม่มีหลักฐาน ถือว่าล้มเหลว

ชุดประเมินต้องมีกรณีทั่วไป ขอบเขต policy ข้อมูลขาดหรือขัดแย้ง tool failure, prompt injection, กรณีที่ต้อง escalate และความต่างด้านภาษาและรูปแบบ Schema, authority, evidence และ abstention ที่ถูกต้องมาก่อนสไตล์ Agent Skills เฉพาะโดเมน ทำให้ขั้นตอนและการตรวจสอบคงที่

Gate สาม: Tokens, Latency และ Cost

เราวัด cost ต่อ task ที่ตรวจสอบแล้ว ไม่ใช่ราคาต่อ token

มิติ	ตัวชี้วัดระดับ Harness
ความสำเร็จ	งานเสร็จที่ยืนยันแล้วต่อการลองที่อนุญาต
คุณภาพ	first-pass, ความรุนแรง และ escape rate
Tokens	input, cache, output และ retry ต่อหนึ่งงาน
Latency	ค่ากลางและช่วงปลายจนถึงสถานะยืนยัน
Cost	inference, retrieval, tool, review และ rework
ความเสถียร	ความแปรผันตามเวลา รูปแบบ และประเภทงาน

กำหนด route ปัจจุบันเป็น Baseline = 100 ทางเลือกที่ถูกกว่าจะมีคุณค่าก็ต่อเมื่อไม่ลด success rate เพิ่ม exception load หรือเพิ่มเวลา review

Route ตาม Task ไม่ใช่ตาม User

task_type: extract | classify | synthesize | plan | act | verify
data_class: public | internal | confidential | restricted
residency: approved_regions
authority: read | recommend | dry_run | approved_write
evidence: source_ids and freshness requirements
output_contract: schema or rubric version
risk: consequence and reversibility
latency_budget: interactive | asynchronous | batch

Data class, residency และ authority ต้องเป็นกฎ deterministic หากไม่แน่ใจให้เลือกเส้นทางที่ปลอดภัยกว่า routing receipt บันทึก policy, model, prompt/skill, source, tool call, verifier และ final state

เหตุผลที่โมเดล Local ต้องใช้ Harness ต่างออกไป

Local inference ให้การควบคุมข้อมูล ต้นทุนคาดการณ์ได้ และทำงาน offline แต่บางครั้งไม่สม่ำเสมอเรื่องคำสั่ง tool, long context และหลายภาษา

แยกงานให้ละเอียดขึ้น

แยกการเลือกเอกสาร การสกัด การจัดประเภท การร่าง และการตรวจสอบ แต่ละขั้นมี input/output contract แคบและ checkpoint

Retrieval ให้น้อยแต่แม่นกว่า

การใส่ repository ทั้งหมดใน context ไม่ใช่ retrieval ควรใช้ index, metadata filter, freshness และ evidence packet สั้น ๆ ผู้ช่วย AI local ที่มี retrieval และ web search แสดงความสำคัญของชั้นเครื่องมือและหลักฐาน

ตรวจสอบแบบ Deterministic

ใช้ schema, parser, allow-list, database constraint, calculation, policy engine และ readback ตรวจฟิลด์ ID ยอดรวม สิทธิ์ และสถานะสุดท้าย การเรียกครั้งเดียวไม่ควรสร้าง ให้คะแนน และอนุมัติผลงานของตนเอง

Cascade, Fallback และ Abstention

เริ่มจาก route ราคาต่ำสุดที่ผ่านเกณฑ์ แล้ว escalate เมื่อ schema ผิด หลักฐานขาด source ขัดแย้ง tool ใช้ไม่ได้ ชน policy gate หรือ verifier ล้มเหลว Fallback ห้ามข้าม residency หรือ authority และห้ามแสร้งว่า action เกิดแล้ว การปฏิเสธหรือ escalate อย่างถูกต้องถือเป็นความสำเร็จเมื่อ task contract กำหนด

State, Version และ Reproducibility

เรา version task, policy, provider, region, model, prompt, skill, tool schema, retrieval query, source ID, freshness, parameter, verifier, retry, review, action และ readback ความทำซ้ำได้มาจาก input, configuration, external action และ evidence ไม่ใช่การเก็บ chain-of-thought ไม่จำกัด การปรับ agent เฉพาะโครงการ ก็ต้องทำให้การเปลี่ยนแปลงและ failure มองเห็นได้

กระบวนการเลือกที่ใช้งานได้จริง

1. กำหนดประเภท task 2. ใช้ admissibility gate 3. สร้างกรณีตัวแทน ขอบเขต และ adversarial 4. ทดสอบใน harness จริง 5. ตัด hard failure 6. วัด success และ quality 7. วัดประสิทธิภาพรวม 8. pilot แบบ shadow/dry-run 9. อนุมัติตามประเภท 10. ประเมินใหม่เมื่อเปลี่ยนหรือ drift

กฎการตัดสินใจ

Privacy, residency และ contract กำหนดสิ่งที่อนุญาต ความสำเร็จที่ตรวจแล้วและคุณภาพกำหนดสิ่งที่ทำได้ ส่วน token, latency และ total cost กำหนดสิ่งที่มีประสิทธิภาพ ทางเลือกที่ถูกต้องคือระบบเล็กที่สุดที่อนุญาต ทำ task สำเร็จภายในขอบเขตคุณภาพ และพิสูจน์ผลได้

Insights ที่เกี่ยวข้อง

• สถาปัตยกรรมชั้นปฏิบัติการ AI แบบ thread — routing, state, authority และ verification
• Agent Skills สำหรับ workflow เฉพาะโดเมน — ขั้นตอนและการตรวจเฉพาะทาง
• ผู้ช่วย AI local พร้อม web search และ retrieval — รูปแบบของ local inference, evidence และ tools