ฮาร์เนสเอเจนต์คืออะไร: งานวิจัย โครงการโอเพนซอร์ส และแนวปฏิบัติในอุตสาหกรรม

เอเจนต์สองตัวอาจใช้โมเดลเดียวกันทุกประการ แต่ทำคะแนนบนเบนช์มาร์กเดียวกันต่างกันอย่างมาก OpenAI วัดเรื่องนี้โดยตรง: บน SWE-bench Lite, GPT-4 ทำคะแนน 2.7% ด้วยฮาร์เนสหนึ่ง และ 28.3% ด้วยอีกฮาร์เนสหนึ่ง ซึ่งต่างกัน 10 เท่าโดยเกิดจากฮาร์เนสทั้งหมด เมื่ออุตสาหกรรมเปลี่ยนจากคำถามว่า “โมเดลใดฉลาดที่สุด” เป็น “เอเจนต์ใดทำงานสำเร็จจริง” ฮาร์เนสเอเจนต์จึงกลายเป็นชั้นที่ตัดสินความน่าเชื่อถือ อ่านต่อเพื่อทำความเข้าใจว่าฮาร์เนสเอเจนต์คืออะไร งานวิจัยและเบนช์มาร์กล่าสุดกล่าวถึงการออกแบบฮาร์เนสอย่างไร ฮาร์เนสโอเพนซอร์สใดคุ้มค่ากับเวลาของคุณ และแล็บ AI รายใหญ่สร้างของตนเองอย่างไร รวมถึง Kimi K3.1 Pro โมเดลโอเพนเวตที่ Moonshot AI จับคู่กับฮาร์เนสของตนเอง

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

คำนี้มาจากแวดวงการประเมินผล โดย “test harness” คือชุดทดสอบที่รันระบบภายใต้เงื่อนไขควบคุม ใน AI เชิงเอเจนต์ แนวคิดเดียวกันนี้ขยายไปสู่การใช้งานจริง กล่าวคือ ฮาร์เนสเป็นทั้งชุดที่ใช้วัดผลเอเจนต์ (เช่น ใน SWE-bench หรือ Terminal-Bench) และฮาร์เนสที่ใช้รันเอเจนต์ (เช่น ใน SWE-agent, OpenHands หรือ Claude Code)

งานวิจัย SWE-bench ของ Anthropic อธิบายไว้อย่างชัดเจนว่า เบนช์มาร์กนี้ “ไม่ได้ประเมินเพียงโมเดล AI แบบแยกเดี่ยว แต่ประเมินระบบ ‘เอเจนต์’ ทั้งระบบ” โดยเอเจนต์คือ “การผสานกันระหว่างโมเดล AI กับโครงสร้างซอฟต์แวร์โดยรอบ” Claude 3.5 Sonnet รุ่นอัปเกรดของพวกเขาทำคะแนน 49% บน SWE-bench Verified ได้โดยไม่ใช้เฟรมเวิร์กซับซ้อน แต่ใช้ฮาร์เนสแบบเรียบง่ายที่มี prompt หนึ่งรายการและเครื่องมืออเนกประสงค์สองตัว (เครื่องมือ Bash และเครื่องมือ Edit)

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

ประการแรกคือผลลัพธ์ “น้อยแต่มาก”: ในเดือนกรกฎาคม 2025 ทีม SWE-bench เปิดตัว mini-SWE-agent ซึ่งเป็นฮาร์เนส Python ราว 100 บรรทัด ไม่มีเครื่องมืออื่นนอกจาก bash มีประวัติข้อความแบบเส้นตรงทั้งหมด และรันทุกการกระทำเป็นการเรียก subprocess.run แยกกัน มันทำคะแนนเบนช์มาร์กได้ทัดเทียมกับเฟรมเวิร์กที่ซับซ้อนกว่ามาก (ดูรายละเอียดในส่วนงานวิจัยด้านล่าง) บทเรียนที่ชวนคิดคือ เมื่อโมเดลมีความสามารถมากพอ ฮาร์เนสที่เรียบง่ายและคาดเดาได้อย่างยิ่งอาจเอาชนะฮาร์เนสขนาดใหญ่ได้ ปัจจุบัน Meta, NVIDIA, IBM, Princeton และ Stanford ใช้มันเป็นค่าอ้างอิงแล้ว

ประการที่สองคือผลลัพธ์แบบ “ยิ่งมากยิ่งได้น้อย”: harness ที่ออกแบบได้ไม่ดี — เช่น เอาต์พุตจากเครื่องมือที่มีสัญญาณรบกวน ลูปที่ไม่มีขอบเขต และการกู้คืนจากข้อผิดพลาดที่แย่ — อาจทำให้โมเดลแนวหน้าดูมีความสามารถเพียงปานกลาง OpenAI พบว่าการแก้ไขงานที่มีข้อบกพร่องใน SWE-bench (รายละเอียดอยู่ในส่วน OpenAI ด้านล่าง) ช่วยเพิ่มประสิทธิภาพของโมเดลที่วัดได้มากกว่าสองเท่า

นี่จึงเป็นเหตุผลที่วิศวกรรม harness กลายเป็นศาสตร์เฉพาะทางของตัวเอง harness เป็นตัวกำหนดว่า:

• สิ่งที่โมเดลเห็น: โครงสร้าง prompt, สคีมาของเครื่องมือ, ปริมาณสถานะของสภาพแวดล้อมและประวัติที่จะรวมไว้ในหน้าต่างบริบท

• สิ่งที่โมเดลทำได้: เครื่องมือที่ใช้งานได้ (shell, โปรแกรมแก้ไขไฟล์, เบราว์เซอร์, การค้นหา) รวมถึงวิธีแยกวิเคราะห์และตรวจสอบการกระทำก่อนนำไปดำเนินการ

• วิธีจัดการความล้มเหลว: การลองใหม่, การหมดเวลา, การย่อบริบทเมื่อหน้าต่างบริบทเต็ม และการยุติการทำงานอย่างเหมาะสม

• วิธีวัดผลงาน: การบันทึกเส้นทางการทำงาน, การให้คะแนน และการคิดต้นทุน — หากไม่มีสิ่งเหล่านี้ ก็ไม่มีทั้งการประเมินและวงจรการปรับปรุง

ไม่ว่าจะเป็นชุดทดสอบเพื่อการวิจัยหรือผู้ช่วยเขียนโค้ดที่ใช้งานจริง agent harness เกือบทุกตัวมีวงจรหลักเหมือนกัน:

1. การรับงาน: อ่าน issue, คำสั่ง หรือเป้าหมาย แล้วเริ่มต้นสภาพแวดล้อมที่แยกออกมา (โดยปกติคือ Docker container หรือ VM snapshot)

2. การประกอบ prompt: รวม system prompt, คำนิยามเครื่องมือ, คำอธิบายงาน และประวัติการกระทำกับข้อสังเกตที่สะสมมา

3. การแยกวิเคราะห์การกระทำ: แปลงเอาต์พุตของโมเดลเป็นการเรียกใช้เครื่องมือที่ชัดเจน — คำสั่ง bash, การแก้ไขไฟล์, คำขอ API — และปฏิเสธการกระทำที่มีรูปแบบไม่ถูกต้อง

4. การดำเนินการและการสังเกต: รันการกระทำในสภาพแวดล้อม จับ stdout/stderr หรือสถานะ UI แล้วตัดทอนให้พอดีกับงบประมาณบริบท

5. การควบคุมลำดับงาน: บังคับใช้ข้อจำกัดจำนวนขั้นตอน ข้อจำกัดต้นทุน และเงื่อนไขการหยุด; ตัดสินใจว่าเมื่อใดควรถามมนุษย์หรือจบตอนการทำงาน

6. การบันทึกและการให้คะแนน: บันทึกเส้นทางการทำงานทั้งหมด และประเมินสถานะสุดท้าย — เช่น รันชุดทดสอบของ repository ใน SWE-bench

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

วรรณกรรมวิชาการเกี่ยวกับ agent harness ได้ข้อสรุปสำคัญที่ได้มาอย่างยากลำบากอยู่ไม่กี่ข้อ แทนที่จะรวบรวมทุก benchmark ส่วนนี้จะติดตามคำถามวิจัยที่ทำให้วงการต้องหันมาให้ความสำคัญกับ harness อย่างจริงจัง

ก่อนเข้าสู่บทความวิชาการ มาดูพื้นฐานอย่างรวดเร็ว benchmark คือชุดงานที่กำหนดตายตัวพร้อมกฎการให้คะแนน ออกแบบมาเพื่อให้เปรียบเทียบระบบต่าง ๆ ได้บนพื้นฐานเดียวกัน ในการประเมิน agent benchmark มีองค์ประกอบที่เปลี่ยนแปลงได้สามส่วน ได้แก่ ชุดงาน (issue จริงบน GitHub, คำสั่ง terminal, งานบนเว็บ), สภาพแวดล้อมสำหรับดำเนินการ (Docker container, เบราว์เซอร์, terminal) และ ตัวให้คะแนน (ชุดทดสอบ, การตรวจสอบสถานะ, การรีวิวโดยมนุษย์) harness อยู่ระหว่างโมเดลกับทั้งสามส่วน — เป็นตัวแปรที่กำหนดว่าความสามารถของโมเดลจะแสดงออกมาในคะแนนหรือไม่

วิธีวัดคะแนนจริงสำคัญกว่าตัวเลขพาดหัว ใน SWE-bench เอเจนต์จะสร้าง code patch จากนั้น benchmark จะรันชุดทดสอบสองชุด ได้แก่ FAIL_TO_PASS (การทดสอบที่ล้มเหลวก่อนแก้ไขและตอนนี้ต้องผ่าน) และ PASS_TO_PASS (การทดสอบที่ผ่านอยู่แล้วและต้องไม่ล้มเหลว) งานจะนับว่าแก้ไขสำเร็จก็ต่อเมื่อผ่านทั้งสองชุดเท่านั้น ด้วยเหตุนี้ ฟีเจอร์ของ harness เช่น การรันการทดสอบและการสร้าง diff จึงไม่ใช่ส่วนเสริมที่มีหรือไม่มีก็ได้ — แต่เป็นจุดที่คะแนนได้หรือเสีย

กฎสามข้อในการอ่านคะแนน benchmark:

1. ถามว่าคะแนนซ่อนอะไรไว้บ้าง โมเดลที่ฝึกด้วยข้อมูล GitHub สาธารณะอาจเคยเห็น issue เดียวกับที่กำลังถูกทดสอบ — การปนเปื้อนของข้อมูลอาจทำให้คะแนนสูงขึ้นโดยที่ความสามารถจริงไม่ได้เพิ่มขึ้น สภาพแวดล้อมที่ทำซ้ำได้และชุดงานที่กันไว้ต่างหากคือวิธีแก้ปัญหา

2. ระวังกฎของ Goodhart: เมื่อสิ่งที่ใช้วัดกลายเป็นเป้าหมาย มันจะเลิกเป็นตัววัดที่ดี harness ที่ปรับแต่งเพื่อทำคะแนนสูงใน benchmark เดียวอาจกำลังเรียนรู้กลเม็ดเฉพาะของ benchmark แทนความสามารถทั่วไป — นี่จึงเป็นเหตุผลที่ทีมจริงจังประเมินผลกับมากกว่าหนึ่ง benchmark

3. ตรวจสอบ harness ไม่ใช่แค่โมเดล ดังที่ส่วนที่เหลือของหัวข้อนี้แสดงให้เห็น โมเดลเดียวกันอาจได้คะแนน 2.7% หรือ 28.3% ขึ้นอยู่กับโครงสร้างสนับสนุน คะแนนที่ไม่ระบุชื่อ harness เป็นเพียงเรื่องเล่า ไม่ใช่การวัดผล

บทความ SWE-bench ฉบับต้นฉบับ ("Can Language Models Resolve Real-World GitHub Issues?") นำเสนอการประเมินที่กลายเป็นมาตรฐานในปัจจุบัน: ให้โมเดลได้รับ issue จริงบน GitHub และ repository ทั้งหมด แล้วประเมินว่า patch ของโมเดลทำให้การทดสอบที่เคยล้มเหลวผ่านได้หรือไม่ ผลลัพธ์ที่ถูกอ้างถึงมากที่สุดมักถูกตีความผิด: Claude 2 ซึ่งเป็นโมเดลที่ดีที่สุดในขณะนั้น แก้ได้เพียง 1.96% ของงานเท่านั้น ผู้เขียนอธิบายว่ามาตรวัดนี้ทดสอบ “การให้เหตุผลที่ซับซ้อนซึ่งไกลเกินกว่าการสร้างโค้ดแบบดั้งเดิมมาก” — แต่งานวิจัยที่ตามมาชี้ชัดว่าช่องว่างส่วนใหญ่ไม่ได้เกิดจากความสามารถในการให้เหตุผล หากแต่เป็นเพราะไม่มี harness ที่สามารถสำรวจ repository รันการทดสอบ และทำซ้ำปรับแก้ได้ กล่าวอีกนัยหนึ่ง SWE-bench ไม่ได้เพียงวัดโมเดล แต่เผยให้เห็นว่า harness ที่อยู่รอบโมเดลคือชิ้นส่วนที่ขาดหายไป

บทความ SWE-agent ("Agent-Computer Interfaces Enable Automated Software Engineering") เป็นเอกสารรากฐานของวงการสำหรับการออกแบบ harness ข้อเสนอหลักคือ การออกแบบ interface เป็นตัวแปรระดับต้น: ผู้เขียนบัญญัติคำว่า Agent-Computer Interface (ACI) และแสดงให้เห็นว่า interface ที่สร้างขึ้นเพื่อจุดประสงค์เฉพาะ — โปรแกรมแก้ไขไฟล์ที่มี linter คอยตรวจ, ฟีดแบ็กจาก shell ที่กระชับ, กลไกป้องกันคำสั่งที่มีรูปแบบไม่ถูกต้อง — ช่วยเพิ่ม pass@1 บน SWE-bench จากระดับเลขหลักเดียวต่ำ ๆ เป็น 12.5% ซึ่งเป็นผลงานดีที่สุดในขณะนั้น ผลงานที่ทรงอิทธิพลยาวนานของบทความนี้คือข้อโต้แย้งว่า “LM agents เป็นผู้ใช้ปลายทางประเภทใหม่” ที่ต้องการซอฟต์แวร์ซึ่งสร้างขึ้นเพื่อพวกเขา เช่นเดียวกับที่มนุษย์ต้องการ IDEs บทความเกี่ยวกับ harness ทุกฉบับหลังจากนั้นล้วนอ้างอิงผลลัพธ์นี้

บทความสองฉบับในปี 2024 ขยายงานวิจัย harness จาก repository โค้ดสู่คอมพิวเตอร์ทั้งเครื่อง OSWorld สร้างสภาพแวดล้อมคอมพิวเตอร์จริงที่ขยายขนาดได้แห่งแรก ครอบคลุม Ubuntu, Windows และ macOS พร้อมงาน 369 งานในแอปเว็บและเดสก์ท็อป ตัวเลขสำคัญของงานนี้ — มนุษย์ทำงานสำเร็จ 72.36% ส่วนโมเดลที่ดีที่สุดทำได้ 12.24% — ระบุว่า GUI grounding (การแปลงเอาต์พุตของโมเดลให้เป็นการคลิกและการกดแป้นพิมพ์ที่ถูกต้อง) คือรูปแบบความล้มเหลวหลัก ซึ่งเป็นปัญหาของ harness ไม่ใช่ปัญหาด้านความรู้ WebArena มองจากอีกมุมหนึ่ง: สภาพแวดล้อมเว็บที่โฮสต์เองและทำซ้ำได้ทั้งหมด (อีคอมเมิร์ซ, ฟอรัม, GitLab, CMS) ซึ่ง GPT-4 มีอัตราสำเร็จแบบครบกระบวนการเพียง 14.41% เทียบกับ 78.24% ของมนุษย์ ทั้งสองบทความยืนยันว่าการประเมิน harness ต้องเป็นแบบ อิงการดำเนินการจริง (ตรวจสอบสถานะสุดท้ายของสภาพแวดล้อม) ไม่ใช่จับคู่รูปแบบกับเอาต์พุตของโมเดล

τ-bench ของ Sierra ("เกณฑ์ทดสอบสำหรับปฏิสัมพันธ์ระหว่างเครื่องมือ เอเจนต์ และผู้ใช้ในโดเมนโลกจริง") ชี้ให้เห็นประเด็นที่ละเอียดอ่อนกว่า: ในการใช้งานจริง ฮาร์เนสไม่ได้เพียงครอบโมเดลและสภาพแวดล้อมเท่านั้น แต่ยังเป็นตัวกลางให้กับ ผู้ใช้ ด้วย เกณฑ์ทดสอบนี้จำลองบทสนทนาแบบไดนามิกระหว่างผู้ใช้ที่เป็นโมเดลภาษากับเอเจนต์ซึ่งมี API เฉพาะโดเมนและแนวทางเชิงนโยบาย จากนั้นประเมินสถานะสุดท้ายของฐานข้อมูล ตัวชี้วัดหลักคือ pass^k (ความสำเร็จจากการทดลองอิสระ k ครั้ง) ซึ่งเผยให้เห็นว่าเอเจนต์มีความ ไม่สม่ำเสมอ เพียงใด: GPT-4o แก้โจทย์ได้ไม่ถึง 50% แม้ในการทดลองครั้งเดียว และค่า pass^8 ลดลงต่ำกว่า 25% ในงานค้าปลีก บทเรียนสำหรับผู้สร้างฮาร์เนสคือ ความน่าเชื่อถือเป็นคุณสมบัติของการกระจายผลลัพธ์ ไม่ใช่คุณสมบัติของการรันครั้งเดียว — ฮาร์เนสที่ใช้ได้เพียงครั้งเดียวก็ไม่ใช่ฮาร์เนสที่ใช้ได้จริง

งาน "การวัดความสามารถของ AI ในการทำงานซอฟต์แวร์ระยะยาวให้เสร็จ" ของ METR เสนอแนวคิด ขอบเขตเวลาสำหรับการทำงานสำเร็จ 50%: ความยาวของงาน (วัดจากเวลาที่มนุษย์ใช้ทำจนเสร็จ) ที่โมเดลทำสำเร็จได้ด้วยความน่าเชื่อถือ 50% โมเดลระดับแนวหน้าพัฒนาจากทำงานได้ไม่กี่นาทีเป็นราวหนึ่งชั่วโมงระหว่างปี 2019 ถึง 2025 โดยเพิ่มขึ้นเท่าตัวประมาณทุกเจ็ดเดือน สำหรับวิศวกรรมฮาร์เนส นี่คือข้อค้นพบที่สำคัญที่สุดของทศวรรษ: ฮาร์เนสที่ใช้จำกัดโมเดลในปี 2024 จะกลายเป็นภาระไร้ประโยชน์สำหรับโมเดลในปี 2026 Anthropic อธิบายว่าองค์ประกอบทุกส่วนในฮาร์เนสล้วนแฝงสมมติฐานเกี่ยวกับสิ่งที่โมเดลทำไม่ได้ — และสมมติฐานเหล่านั้นจะล้าสมัยเมื่อโมเดลพัฒนาขึ้น

เกณฑ์ทดสอบดั้งเดิมได้เติบโตเป็นระบบนิเวศที่นำบทเรียนเหล่านี้ไปใช้จริง:

• SWE-bench Verified (ร่วมกับ OpenAI, 2024): ชุดย่อย 500 กรณีที่ผ่านการคัดกรองโดยมนุษย์ เพื่อตัดงานที่ระบุรายละเอียดไม่เพียงพอหรือประเมินผลอย่างไม่เป็นธรรมออก — 68.3% ของชุดข้อมูลเดิมถูกตัดออก ซึ่งทำให้คะแนนที่วัดได้เพิ่มขึ้นกว่าสองเท่า และกลายเป็นลีดเดอร์บอร์ดมาตรฐาน

• SWE-smith (2025): ไปป์ไลน์สำหรับสร้างงานฝึกแบบสังเคราะห์ เพื่อให้ฝึกโมเดลสำหรับฮาร์เนสแบบเอเจนต์ได้ ไม่ใช่เพียงใช้ประเมินผลกับฮาร์เนสเหล่านั้น

• mini-SWE-agent (2025): ฮาร์เนสความยาวราว 100 บรรทัดที่ปัจจุบันทำคะแนน SWE-bench Verified ได้เกิน 74% แสดงให้เห็นว่าเมื่อโมเดลมีความสามารถเพียงพอ ลูปที่เรียบง่าย ใช้เพียง bash และมีประวัติแบบเส้นตรงก็เพียงพอ — และกำลังกลายเป็นเกณฑ์อ้างอิงมาตรฐานของชุมชน

• Terminal-Bench (Stanford × Laude, 2025): การประเมินงานบนเทอร์มินัลที่สร้างบนเฟรมเวิร์ก Harbor ซึ่งขยายขอบเขตของฮาร์เนสจากการแก้ไขโค้ดไปสู่งานดูแลระบบ

• CodeClash (2025) และ ProgramBench (2026): การสร้างซอฟต์แวร์ตามเป้าหมายและการสร้างขึ้นใหม่ทั้งหมด ซึ่งขยายฮาร์เนสจากการแก้ไขปัญหาเดี่ยวไปสู่การพัฒนาแบบปลายเปิด

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

ฮาร์เนสโอเพนซอร์สคือจุดเริ่มต้นของทีมส่วนใหญ่ โปรเจกต์ด้านล่างนี้มีทั้งชุมชน GitHub ขนาดใหญ่ (ผู้นำมีดาวหลายหมื่นดวง) และการบำรุงรักษาอย่างต่อเนื่อง:

เมื่อต้องเลือกใช้ระหว่างตัวเลือกเหล่านี้ หลักเกณฑ์ที่ชุมชนใช้คือ เลือกฮาร์เนสที่เรียบง่ายที่สุดซึ่งถ่ายทอดงานของคุณได้ (ตามแนวคิดของ mini-SWE-agent) และเพิ่มความซับซ้อนเฉพาะเมื่อความล้มเหลวที่วัดได้เรียกร้องให้ทำเช่นนั้น DeepSeek Harness อยู่คนละสุดของสเปกตรัม — เป็นแพลตฟอร์มที่ขับเคลื่อนด้วยปลั๊กอินอย่างเต็มรูปแบบสำหรับทีมที่ต้องการให้ทุกชั้นเปลี่ยนทดแทนได้ — แต่ทั้งสองมีวินัยร่วมกันคือ ใช้บันทึกเซสชันแบบคงทนที่เพิ่มข้อมูลต่อท้ายเท่านั้นเป็นแหล่งข้อมูลจริงเพียงหนึ่งเดียวของสิ่งที่โมเดลเห็น

ห้องแล็บแนวหน้ามองวิศวกรรมฮาร์เนสเป็นทรัพย์สินทางปัญญาหลัก และหลายแห่งได้เผยแพร่แนวคิดของตนอย่างละเอียดเป็นพิเศษ

Anthropic เผยแพร่บันทึกสาธารณะที่สมบูรณ์ที่สุดเกี่ยวกับวิศวกรรมฮาร์เนส และสถาปัตยกรรมของบริษัท — ซึ่งอธิบายโดยละเอียดใน การสร้างเอเจนต์ที่มีประสิทธิภาพ (2024), บทความเกี่ยวกับฮาร์เนส SWE-bench (2024) และ Managed Agents (2026) — สามารถมองได้ว่าเป็นสามชั้นที่ซ้อนศูนย์กลางเดียวกัน

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

ชั้นเซสชัน คือบันทึกเหตุการณ์แบบคงทนที่เพิ่มข้อมูลต่อท้ายเท่านั้น ซึ่งอยู่นอกหน้าต่างบริบทของโมเดล ทุกการกระทำและข้อสังเกตจะถูกบันทึกไว้ที่นั่น; บริบทของโมเดลเป็นเพียงภาพฉายของบันทึกนั้น ไม่ใช่ตัวบันทึกเอง การแยกส่วนนี้ทำให้กระบวนการฮาร์เนสที่ล้มเหลวสามารถรีบูตและทำงานต่อระหว่างงานได้ และทำให้ฮาร์เนสเป็น "ปศุสัตว์" ที่เปลี่ยนทดแทนได้ แทนที่จะเป็นสัตว์เลี้ยงที่ต้องดูแลเป็นพิเศษ

ชั้นการประสานงาน — ซึ่ง Anthropic เรียกว่า "เมตาฮาร์เนส" — แยก "สมอง" (โมเดลและลูปของมัน) ออกจาก "มือ" (แซนด์บ็อกซ์และเครื่องมือ) ผ่านอินเทอร์เฟซที่กำหนดไว้อย่างชัดเจน เนื่องจากสมองไม่ได้อยู่ภายในคอนเทนเนอร์สำหรับดำเนินการอีกต่อไป จึงจัดเตรียมแซนด์บ็อกซ์ตามต้องการได้ และเก็บข้อมูลรับรองไว้ในห้องนิรภัยที่แซนด์บ็อกซ์ไม่เคยเข้าถึง ผลลัพธ์ที่รายงานเป็นเชิงโครงสร้าง ไม่ใช่แค่ด้านรูปลักษณ์: เวลา p50 จนถึง token แรกลดลงราว 60% และ p95 ลดลงมากกว่า 90% เพราะเซสชันไม่ต้องรอคอนเทนเนอร์ที่อาจไม่มีวันได้ใช้แล้ว

เอกสารสามฉบับบันทึกวิวัฒนาการนี้ไว้: การสร้างเอเจนต์ที่มีประสิทธิภาพ (2024), บทความเกี่ยวกับฮาร์เนส SWE-bench (2024) และ Managed Agents (2026)

OpenAI ร่วมมือกับทีม SWE-bench เพื่อสร้างชุดแบ่ง Verified ที่ผ่านการตรวจสอบโดยมนุษย์ เพราะฮาร์เนสต้องการงานที่สะอาด: แคมเปญการทำคำอธิบายกำกับของพวกเขา (นักพัฒนา 93 คน, ตัวอย่าง 1,699 รายการ) พบว่า 68.3% ของงานในเบนช์มาร์กเดิมมีปัญหา และการตัดงานเหล่านั้นออกทำให้ประสิทธิภาพที่วัดได้เพิ่มขึ้นมากกว่าสองเท่า บทความเดียวกันระบุว่าเพียงการเลือกฮาร์เนสก็ทำให้ GPT-4 มีผลลัพธ์บน SWE-bench Lite จาก 2.7% เป็น 28.3% — ช่วงความแตกต่างที่พวกเขายกมาเพื่อชี้ว่าการประเมินต้องคำนึงถึงความก้าวหน้าของฮาร์เนสที่ชุมชนสร้างขึ้น

ในฝั่งโอเพนซอร์ส Codex CLI มาพร้อมฮาร์เนสอ้างอิงที่สมบูรณ์ สถาปัตยกรรมของมันแบ่งเป็นชั้นในลักษณะที่สะท้อนระบบอื่นในส่วนนี้: ลูปเอเจนต์หลัก จัดการการวางแผนและการเรียกใช้เครื่องมือ; ชั้นแซนด์บ็อกซ์ แยกการดำเนินการด้วยนโยบายที่กำหนดค่าได้สำหรับแต่ละงาน; ชั้นเซสชัน เก็บการสนทนาอย่างถาวรเพื่อให้กลับมาทำต่อ แยกแขนง หรือย่อได้; และ ชั้นเครื่องมือ เปิดให้เข้าถึงทั้งเชลล์ภายในเครื่องและเครื่องมือภายนอกที่ใช้ MCP แทนที่จะกำหนดอินเทอร์เฟซเดียวตายตัว เอนจินเดียวกันนี้ถูกเปิดให้ใช้งานผ่านสามช่องทาง — UI เทอร์มินัลสำหรับงานเชิงโต้ตอบ, app server แบบ JSON-RPC สำหรับไคลเอนต์ที่มีความสามารถสูงอย่าง VS Code และบริการรันโค้ดระยะไกลสำหรับแซนด์บ็อกซ์บนคลาวด์ — เพื่อให้ฮาร์เนสทำงานในเครื่องหรือถูกควบคุมด้วยโปรแกรมได้ การออกแบบนี้เลือกสมดุลแบบเดียวกับที่งานวิจัยแนะนำ: ลูปที่เรียบง่าย แซนด์บ็อกซ์ที่แข็งแกร่ง การจัดการบริบทอย่างชัดเจน และขอบเขตที่ชัดเจนระหว่างโมเดลกับโลกภายนอก

ด้วย Agent Development Kit (ADK) และ โปรโตคอล Agent2Agent (A2A) ซึ่งเปิดตัวเมื่อเดือนเมษายน 2025 พร้อมพันธมิตรด้านเทคโนโลยีกว่า 50 ราย รวมถึง Atlassian, Salesforce, SAP และ ServiceNow — Google กำลังทำให้เลเยอร์ฮาร์เนสเป็นผลิตภัณฑ์ A2A กำหนดมาตรฐานวิธีที่เอเจนต์ประกาศความสามารถ (ผ่าน JSON "Agent Cards") จัดการงานที่ใช้เวลานาน แลกเปลี่ยนอาร์ติแฟกต์ และตกลงรูปแบบ UI เพื่อให้ฮาร์เนสกลายเป็นโครงสร้างพื้นฐานที่ทำงานร่วมกันได้ แทนที่จะเป็นโค้ดเชื่อมต่อที่สร้างเฉพาะกิจ โดยออกแบบมาให้ทำงานเสริมกับ Model Context Protocol (MCP) ของ Anthropic ซึ่งกำหนดมาตรฐานด้านเครื่องมือของฮาร์เนสโดยเฉพาะ

AutoGen และ Magentic-One ของ Microsoft มาพร้อมฮาร์เนสที่มีเอเจนต์ออร์เคสเตรเตอร์คอยจัดการบันทึกข้อเท็จจริงและความคืบหน้า ซึ่งเป็นการออกแบบที่เผยแพร่ไว้เพื่อป้องกันลูปไร้ขอบเขตที่มักเกิดกับฮาร์เนสแบบพื้นฐาน GAIA ของ Meta และ Hugging Face สร้างเบนช์มาร์กผู้ช่วยอเนกประสงค์ที่ฮาร์เนสใช้ประเมินคำถามในโลกจริงซึ่งต้องอาศัยการนำทางเว็บและจัดการไฟล์ ขณะที่ Open Agent Leaderboard ของ Hugging Face ยังคงผลักดันการจัดอันดับที่เปรียบเทียบกันได้และคำนึงถึงฮาร์เนส

DeepSeek Harness (dsh) นำแนวคิดเมตาฮาร์เนสมาทำให้ประกอบเข้าด้วยกันได้ สถาปัตยกรรมสร้างบนเฟรมเวิร์ก Cordis และมีข้อเสนอหลักว่า ทุกส่วนของฮาร์เนสเป็นปลั๊กอินที่เปลี่ยนแทนได้ — รวมถึงอะแดปเตอร์โมเดล รีจิสทรีเครื่องมือ บันทึกเซสชัน และแม้แต่ลูปเอเจนต์เอง

การออกแบบนี้ตั้งอยู่บนองค์ประกอบพื้นฐานสามประการ ประการแรกคือ บันทึกเซสชันแบบคงทน ซึ่งเป็นแหล่งข้อมูลจริงเพียงหนึ่งเดียวสำหรับสิ่งที่โมเดลเห็น ทุกสิ่งที่ส่งถึงโมเดลต้องสร้างย้อนกลับจากบันทึกได้ โดยบังคับเป็นเงื่อนไขคงตัวขณะรันไทม์ ประการที่สองคือ รอยต่อความสามารถ: อินเทอร์เฟซผู้ให้บริการที่สับเปลี่ยนได้ระหว่างเอเจนต์กับโลกภายนอก ดังนั้นการชี้ผู้ให้บริการระบบไฟล์และซับโปรเซสไปยังแซนด์บ็อกซ์ระยะไกล ก็จะย้ายการเข้าถึง Bash เทอร์มินัล และ language server ไปพร้อมกันโดยไม่ต้องแยกฮาร์เนส ประการที่สามคือ วงจรชีวิตของเทิร์น/ขั้นตอน ที่ชัดเจน พร้อมเหตุการณ์ส่วนขยายที่มีชื่อกำกับ (agent/pre-step, tools/execute, agent/turn-stopping) ซึ่งเปิดให้ปลั๊กอินดักจับหรือเขียนลูปใหม่ได้โดยไม่ต้องแก้โค้ดหลัก

ผลลัพธ์คือการทำให้เมตาฮาร์เนสของ Anthropic เป็นจริงในแบบโอเพนซอร์สที่ใกล้เคียงที่สุด: ฮาร์เนสที่โครงสร้างไม่ใช่เฟรมเวิร์กตายตัว แต่เป็นชุดประกอบของปลั๊กอินที่สับเปลี่ยนได้ผ่านการตั้งค่า ด้วยดาว GitHub กว่า 170k ภายในไม่กี่เดือนแรก สิ่งนี้บ่งชี้ว่าฮาร์เนสเอเจนต์กำลังกลายเป็นหมวดหมู่ผลิตภัณฑ์ในตัวเอง

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

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

แต่ทิศทางการวิจัยที่กล่าวถึงข้างต้นชี้ไปยังที่อื่น τ-bench นำผู้ใช้เข้ามาอยู่ภายในฮาร์เนส METR แสดงให้เห็นเอเจนต์ที่รับงานซึ่งกินเวลาหลายวัน ไม่ใช่หลายนาที OSWorld และ WebArena ย้ายสภาพแวดล้อมจากรีโพซิทอรีที่สะอาดไปสู่โลกจริงอันยุ่งเหยิง ทิศทางนี้สอดคล้องกัน: เมื่อเอเจนต์เปลี่ยนจากเครื่องมือเขียนโค้ดไปเป็นผู้ช่วยทำงานจริง สภาพแวดล้อมที่ต้องนำทางก็ไม่ใช่แค่ซิลิคอนอีกต่อไป — แต่คือผู้คน ผู้ใช้ที่มีความคาดหวัง ทีมที่มีประวัติ องค์กรที่มีสิทธิ์อนุญาตและองค์ความรู้เชิงสถาบัน

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

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

พอร์ตโฟลิโอฮาร์เนสของ Moonshot AI นำกายวิภาคที่นิยามไว้ก่อนหน้านี้ในบทความนี้มาวางบนสแต็กที่มีการจัดการเดียว สำหรับปัญหาเอเจนต์ × คอมพิวเตอร์ ฮาร์เนสของบริษัทขยายลูปมาตรฐาน: Kimi Browser Extension ควบคุมเซสชันเบราว์เซอร์จริงผ่าน Chrome DevTools Protocol แทนแซนด์บ็อกซ์ปลอดเชื้อ รอยต่อ ถามก่อนดำเนินการ บังคับใช้ความยินยอมในระดับระบบไฟล์ และ Agent Swarm ขยายการออร์เคสเตรตไปยังเอเจนต์ย่อย 300 ตัวสำหรับงานระยะยาว

สิ่งที่ขับเคลื่อนลูปนั้นคือ Kimi K3.1 Pro — โมเดลแรกในซีรีส์ K3.1 และโมเดล open-weight ระดับ 3T ที่มีความสามารถสูงสุดของ Moonshot AI จนถึงปัจจุบัน พร้อมหน้าต่างบริบท 1,048,576 token คุณสมบัติสามข้อของโมเดลนี้เกี่ยวข้องโดยตรงกับการออกแบบฮาร์เนส:

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

• ระดับความพยายามในการให้เหตุผลเป็นปุ่มปรับของฮาร์เนส K3.1 Pro คิดอยู่เสมอ และ reasoning_effort รับค่า low, high หรือ max โดยมี max เป็นค่าเริ่มต้น สิ่งนี้เปลี่ยนต้นทุนการให้เหตุผลของโมเดลให้เป็นงบประมาณต่องานที่ฮาร์เนสกำหนด แทนที่จะเป็นราคาคงที่ที่ต้องจ่ายเพื่อเริ่มใช้งาน

• เครื่องมือที่เข้ามาระหว่างเอพิโซด การโหลดเครื่องมือแบบไดนามิกช่วยให้ฮาร์เนสแทรกคำจำกัดความของเครื่องมือแบบสมบูรณ์ไว้ในข้อความระบบได้ เครื่องมือจึงพร้อมใช้งานตั้งแต่ข้อความนั้นเป็นต้นไป — ไม่ต้องเริ่มใหม่ และไม่ต้องเสียค่า schema ของเครื่องมือในทุกเทิร์นของบทสนทนาที่ไม่เคยใช้เครื่องมือนั้น

Moonshot รายงานผลฮาร์เนสควบคู่กับโมเดล ซึ่งเป็นหลักปฏิบัติที่บทความนี้เสนอแนะตลอดมา บน Terminal-Bench 4.0 — ซึ่งให้คะแนนเอเจนต์เขียนโค้ดจากงานเทอร์มินัลที่สมจริงและมีข้อจำกัดด้านทรัพยากร ภายใต้การทดสอบเฉพาะงานที่เข้มงวด — K3.1 Pro ได้ 65.7% นำหน้า GPT-6 Astra (58.2%) และตามหลัง Claude Opus 5.5 (66.4%) เพียงเล็กน้อย บน Kimi Code Bench 3.0 Long-horizon ซึ่งเป็นเบนช์มาร์กภายในสำหรับการดำเนินการหลายขั้นตอน การใช้เครื่องมือ และการแก้ปัญหาแบบครบวงจร โมเดลทำได้ 61.2% เทียบกับ 55.95% ของ K3 เอกสารยังระบุความเชื่อมโยงในทิศทางกลับกันอย่างชัดเจน: พารามิเตอร์การสุ่มตัวอย่าง เช่น temperature และ top_p ถูกกำหนดตายตัวและต้องไม่ใส่ในคำขอ อีกทั้งต้องส่งคืนข้อความ assistant ฉบับสมบูรณ์โดยไม่เปลี่ยนแปลงข้ามแต่ละเทิร์น — ฮาร์เนสที่เขียนข้อความใหม่จะทำให้เหตุผลที่การเรียกใช้เครื่องมือครั้งถัดไปต้องพึ่งพาหายไป

โมเดลเดียวกันทำงานบนทุกส่วนของผลิตภัณฑ์ คุณสามารถลองใช้เวอร์ชันเว็บที่มีการจัดการผ่าน Kimi Agent รันฮาร์เนสภายในเครื่องแบบเต็มรูปแบบด้วย Kimi Work ทำงานในเทอร์มินัลด้วย Kimi Code หรือเรียก kimi-k3.1-pro โดยตรงผ่าน Kimi API รุ่น kimi-k3.1-pro-highspeed แลกกับราคา token ราวสองเท่า เพื่อความเร็วเอาต์พุตเพิ่มขึ้นสองถึงสามเท่า

ไม่ว่าคุณจะกำลังประเมินโมเดลหรือส่งมอบผลิตภัณฑ์ รายการตรวจสอบเดียวกันนี้ใช้ได้เสมอ:

1. เริ่มจากงาน ไม่ใช่เฟรมเวิร์ก หากเอเจนต์ของคุณแก้ไขโค้ด ฮาร์เนสที่มี bash และเอดิเตอร์อย่าง ACI ของ SWE-agent เป็นแนวทางที่พิสูจน์แล้ว หากเอเจนต์ควบคุม GUI หรือเว็บจริง คุณต้องมีการสังเกตจากเซสชันจริงและการกระทำระดับการคลิก

2. ทำให้สภาพแวดล้อมทำซ้ำได้ อิมเมจ Docker, dependency ที่ปักเวอร์ชัน และข้อมูลที่กำหนด seed คือสิ่งที่แยกเบนช์มาร์กออกจากเกร็ดเล่า

3. กำหนดงบหน้าต่างบริบทอย่างตั้งใจ การตัดทอนข้อมูลสังเกต การสรุปประวัติ และการย่อบริบท เป็นคุณสมบัติของฮาร์เนสที่ส่งผลโดยตรงต่อคะแนนและต้นทุน — และเป็นเหตุผลที่โมเดลบริบทยาวช่วยลดปริมาณข้อมูลที่ฮาร์เนสต้องทิ้ง

4. บังคับใช้ขีดจำกัดที่เข้มงวด การจำกัดจำนวนขั้นตอน การหมดเวลาตามเวลาจริง และงบประมาณดอลลาร์ต่อเอพิโซด ช่วยให้เอเจนต์ปลอดภัยและทำให้การประเมินเปรียบเทียบกันได้

5. บันทึกเส้นทางการทำงานทั้งหมดตั้งแต่วันแรก วงจรการปรับปรุงที่จริงจังทุกแบบ — การตรวจทานโดยมนุษย์ การจัดกลุ่มความล้มเหลว การปรับจูนละเอียด — ล้วนใช้ข้อมูลเส้นทางการทำงาน Anthropic's Managed Agents และ DeepSeek Harness ไปไกลกว่านั้น: เก็บบันทึกเซสชันไว้นอกลูปฮาร์เนสในรูปแบบสตรีมเหตุการณ์แบบ append-only เพื่อให้ตัวฮาร์เนสเองเปลี่ยนทิ้งได้ และสร้างบริบทของโมเดลกลับขึ้นมาใหม่ได้เสมอ

6. ประเมินผลบนฮาร์เนสมากกว่าหนึ่งแบบ หากเอเจนต์ของคุณทำงานได้เฉพาะในฮาร์เนสเดียว สิ่งที่คุณสร้างคือพฤติกรรมเฉพาะฮาร์เนส ไม่ใช่ความสามารถ

7. เก็บข้อมูลรับรองไว้นอกแซนด์บ็อกซ์ — หรือไม่ให้ขึ้นคลาวด์เลย ปฏิบัติต่อสภาพแวดล้อมรันงานของเอเจนต์ว่าไม่น่าเชื่อถือ เก็บ token ไว้ใน vault แล้วส่งผ่าน proxy หรือรันทั้งเซสชันภายในเครื่อง เพื่อไม่ให้ข้อมูลรับรองและเนื้อหาหน้าเว็บออกจากอุปกรณ์ — ซึ่งเป็นแนวทางที่ Kimi ใช้กับฮาร์เนสภายในเครื่องของตน

agent harness ได้กลายเป็นชั้นที่สำคัญที่สุดของสแตกเอเจนต์อย่างเงียบ ๆ งานวิจัยจาก SWE-bench, mini-SWE-agent, Terminal-Bench และ METR แสดงให้เห็นว่าการออกแบบ harness ให้ผลกระทบได้ทัดเทียมกับการอัปเกรดโมเดล ขณะที่โครงการโอเพนซอร์สอย่าง DeepSeek Harness, OpenHands, SWE-agent และ Aider ทำให้ทุกคนเข้าถึง harness ระดับพร้อมใช้งานจริงได้ และปัจจุบัน Anthropic, OpenAI, Google, Microsoft และ Moonshot AI ต่างให้ความสำคัญกับวิศวกรรม harness ในฐานะงานหลัก

แต่การเปลี่ยนแปลงที่ลึกกว่านั้นอยู่ที่แนวคิด harness รุ่นแรกแก้ปัญหา เอเจนต์ × คอมพิวเตอร์ โดยมอบมือที่เชื่อถือได้ให้โมเดลใช้กับเทอร์มินัล เบราว์เซอร์ และระบบไฟล์ ส่วนรุ่นถัดมากำลังแก้ปัญหาบริบทที่สภาพแวดล้อมเหล่านั้นสร้างขึ้น นั่นคืองานที่กินเวลาหลายวัน เกี่ยวข้องกับผู้มีส่วนได้ส่วนเสียและรีโพซิทอรี ซึ่งไม่มีตัวสรุปใดบีบอัดได้โดยไม่สูญเสียข้อมูล harness กำลังพัฒนาจากโครงค้ำจุนไปสู่สภาพแวดล้อมการทำงาน และเส้นแบ่งระหว่างสิ่งที่ harness ต้องจัดการกับสิ่งที่โมเดลเก็บไว้เองได้ก็ยังเปลี่ยนแปลงอยู่เสมอ หน้าต่างบริบทหนึ่งล้าน token ของ Kimi K3.1 Pro คือตัวอย่างปัจจุบันที่ชัดเจนที่สุดของการเปลี่ยนแปลงในโมเดลที่ตัดงานซึ่งเดิม harness ต้องทำออกไป

ไม่ว่าคุณจะสร้างเอง เลือกใช้เฟรมเวิร์กโอเพนซอร์ส หรือใช้งาน harness ในระบบจริง ทีมที่มอง harness เป็นซอฟต์แวร์ที่ผ่านการออกแบบทางวิศวกรรม มีการกำหนดเวอร์ชัน และวัดผลได้ คือทีมที่เอเจนต์ทำงานจนเสร็จได้จริง