Code as Agent Harness — แบบสำรวจ 102 หน้าที่มองโค้ดเป็นฐานการทำงานของเอเจนต์

 (code-as-harness.github.io)
4 คะแนน โดย johnonlee 4 시간 전 | ยังไม่มีความคิดเห็น | แชร์ทาง WhatsApp

ผลงานร่วมของ UIUC × Meta × Stanford เป็นบทความสำรวจที่ขึ้นบน arXiv เมื่อเดือนพฤษภาคม และมุมมองค่อนข้างน่าสนใจมาก

ข้อเสนอหลัก

"โค้ดไม่ใช่ผลลัพธ์ที่ LLM สร้างขึ้นอีกต่อไป แต่เป็น operational substrate (ฐานการทำงาน) ที่เอเจนต์ใช้ในการให้เหตุผล ลงมือทำ จัดเก็บสถานะ และตรวจสอบฟีดแบ็ก"

กล่าวคือ โค้ดไม่ได้เป็นแค่ไฟล์ .py แต่เป็น โลกทั้งใบที่เอเจนต์อาศัยอยู่ มุมมองนี้ถูกเรียกว่า code as agent harness

โครงสร้าง 3 ชั้น

บทความนี้วิเคราะห์ระบบเอเจนต์โดยแบ่งเป็น 3 เลเยอร์:

① Harness Interface — วิธีที่โค้ดเชื่อมเอเจนต์เข้ากับสภาพแวดล้อม

  • ทำให้การให้เหตุผลถูก externalize เป็นโค้ดเพื่อรัน/ตรวจสอบ แบบ Program-of-Thoughts
  • ในการควบคุม GUI/หุ่นยนต์ โปรแกรมที่สร้างขึ้นทำงานเป็น policy
  • codebase, trace, simulator เป็นตัวแทนของสภาพแวดล้อมนั้นเอง

② Harness Mechanisms — ระบบควบคุมที่ทำให้การรันระยะยาวดำเนินต่อไปได้

  • Planning: กำลังพัฒนาไปไกลกว่าการ decomposition แบบง่าย ๆ สู่การวางแผนต่อเนื่องบนไฟล์ซิสเต็ม เช่นไฟล์ PLAN.md โดย Meta-Harness มองแม้แต่การออกแบบ harness เองเป็น search space
  • Memory: วิเคราะห์แยกเป็น working/semantic/experiential/long-term/multi-agent พร้อม context compaction โดยประเด็นสำคัญคือ "เมมโมรีไม่ใช่ vector DB เดี่ยว ๆ แต่เป็นเลเยอร์จัดการสถานะแบบบูรณาการ"
  • PEV Loop: นิยามวงจร Plan → Execute → Verify ใหม่ให้เป็น cybernetic governor โดยการรันมีโมเดลสิทธิ์ 3 ระดับคือ read-only → sandbox-edit → full-access(HITL)
  • AHE: เมตาเลเยอร์สำหรับวัดและปรับแต่ง harness เอง

③ Scaling the Harness — วิธีที่มัลติเอเจนต์ร่วมมือกันบนโค้ดซึ่งเป็นสื่อกลางร่วม

  • ข้อค้นพบที่น่าสนใจ: "ความซับซ้อนของโทโพโลยีคือภาษีที่เกิดจากความยังไม่สมบูรณ์ของการแทนสถานะร่วม" — ระบบที่ออกแบบสถานะได้ดีทำงานได้ด้วยโครงสร้างที่เรียบง่าย ส่วนระบบที่พึ่งพาสถานะแฝงจะต้องชดเชยข้อบกพร่องนั้นด้วยโทโพโลยีที่ซับซ้อน

จุดที่น่าประทับใจ

  • Context Compaction + State Offloading: อย่าใส่ทุกอย่างลงใน context window แต่เก็บไว้เฉพาะสรุปที่จำเป็นต่อการตัดสินใจใน active context แล้ว offload ข้อมูลทั้งหมดผ่านโปรโตคอลสไตล์ MCP — อันนี้เป็นเคล็ดลับใช้งานจริงชัด ๆ
  • ใช้การตรวจสอบเป็นเซ็นเซอร์แบบกำหนดแน่นอน: ฟีดแบ็กแบบกำหนดแน่นอนจาก linter, type checker, test, fuzzer เชื่อถือได้มากกว่าสัญญาณควบคุมจาก LLM critique
  • สาเหตุของความล้มเหลวไม่ได้อยู่ที่โมเดล แต่อยู่ที่ harness: "ความล้มเหลวของเอเจนต์ส่วนใหญ่มาจากบริบทของที่เก็บข้อมูลไม่เพียงพอ อินเทอร์เฟซเครื่องมือที่เปราะบาง ตัวตรวจสอบที่อ่อนแอ ต้นทุนโทเค็นที่สูงเกินไป และนโยบายการลองใหม่ที่ผิดพลาด"

Open Problems

ในบรรดาโจทย์เปิด 7 ข้อที่บทความทิ้งไว้:

  • การประเมินที่ไม่ยึดแค่ความสำเร็จสุดท้าย: ให้ trace ระหว่างทาง ความพยายามกู้คืน และการตรวจสอบความปลอดภัย เป็นตัวชี้วัดชั้นหนึ่งด้วย
  • การปรับปรุง harness โดยไม่ก่อ regression: จะเรียนรู้จากความล้มเหลวโดยไม่ทำให้พฤติกรรมเดิมพังได้อย่างไร
  • สถานะร่วมแบบ transactional ระหว่างมัลติเอเจนต์: การแก้ความขัดแย้งเมื่อหลายเอเจนต์แก้โค้ดพร้อมกัน

อ้างอิง

บทความที่เกี่ยวข้อง

ยังไม่มีความคิดเห็น

ยังไม่มีความคิดเห็น