การขยาย Managed Agents: แยกสมองออกจากมือ

• Managed Agents ซึ่งเป็นบริการโฮสต์สำหรับเอเจนต์ที่ทำงานระยะยาว ใช้สถาปัตยกรรมแบบอิงอินเทอร์เฟซที่คงความเสถียรได้ แม้ว่า harness จะเปลี่ยนไปตามพัฒนาการของโมเดล
• harness เข้ารหัสสมมติฐานเกี่ยวกับงานที่ Claude ยังทำเองไม่ได้ แต่เมื่อโมเดลพัฒนาขึ้น สมมติฐานเหล่านั้นจะล้าสมัย (stale) และก่อให้เกิดโอเวอร์เฮดที่ไม่จำเป็น
• เช่นเดียวกับที่ระบบปฏิบัติการจำลองฮาร์ดแวร์ด้วยนามธรรมอย่าง process และ file Managed Agents ก็จำลององค์ประกอบของเอเจนต์ (session, harness, sandbox) เพื่อให้เปลี่ยนแทนกันได้อย่างอิสระ
• ด้วยการแยกสมอง (harness) ออกจากมือ (sandbox และเครื่องมือ) จึงได้การปรับปรุงประสิทธิภาพ โดยp50 TTFT ลดลงราว 60% และ p95 ลดลงมากกว่า 90%
• การออกแบบนี้ทำหน้าที่เป็นmeta-harness ที่รองรับได้ไม่ว่าในอนาคตจะมี harness หรือ sandbox แบบใดเกิดขึ้น

---

สมมติฐานของ harness จะล้าสมัยตามพัฒนาการของโมเดล

• harness เป็นโครงสร้างที่เข้ารหัสสมมติฐานเกี่ยวกับงานที่ Claude ยังทำเองไม่ได้ แต่เมื่อโมเดลพัฒนาขึ้น สมมติฐานเหล่านั้นก็ไม่จำเป็นอีกต่อไป
• ใน Claude Sonnet 4.5 มีอาการ "context anxiety" ที่จะจบงานก่อนเวลาเมื่อเข้าใกล้ขีดจำกัดของคอนเท็กซ์ จึงเพิ่มการรีเซ็ตคอนเท็กซ์ไว้ใน harness
• ใน Claude Opus 4.5 พฤติกรรมดังกล่าวหายไป ทำให้ตรรกะการรีเซ็ตกลายเป็นโค้ดที่ไม่จำเป็น
• เพราะคาดว่า harness จะยังเปลี่ยนแปลงต่อไป จึงสร้างบริการ Managed Agents บนพื้นฐานของอินเทอร์เฟซทั่วไปที่ไม่ผูกกับ implementation ใด implementation หนึ่ง

ปรัชญาการออกแบบที่ได้แรงบันดาลใจจากระบบปฏิบัติการ

• ระบบปฏิบัติการจำลองฮาร์ดแวร์ด้วยนามธรรมอย่างprocess และ file เพื่อให้ออกแบบมาให้รันโปรแกรมที่ยังไม่มีอยู่ในตอนนี้ได้
• เช่นเดียวกับที่คำสั่ง read() ทำงานเหมือนกันไม่ว่าจะเป็นดิสก์แพ็กยุค 1970 หรือ SSD สมัยใหม่ นามธรรมจะมีอายุยืนกว่าฮาร์ดแวร์
• Managed Agents ก็ใช้รูปแบบเดียวกันในการจำลององค์ประกอบของเอเจนต์
  • session: ล็อกแบบ append-only ของทุกเหตุการณ์ที่เกิดขึ้น
  • harness: ลูปที่เรียก Claude และ route การเรียกใช้เครื่องมือ
  • sandbox: สภาพแวดล้อมรันไทม์ที่ Claude ใช้รันโค้ดและแก้ไขไฟล์

การออกแบบช่วงแรก: ข้อจำกัดของคอนเทนเนอร์เดี่ยว (ปัญหา "Pet")

• ในช่วงแรก วาง session, harness และ sandbox ไว้ในคอนเทนเนอร์เดียว
• มีข้อดีคือแก้ไขไฟล์ผ่าน syscall ได้โดยตรง และไม่ต้องออกแบบขอบเขตระหว่างบริการ
• แต่เกิดปัญหาที่คอนเทนเนอร์กลายเป็น**"pet"** (อินสแตนซ์เฉพาะตัวที่แทนที่ไม่ได้)
  • หากคอนเทนเนอร์ล้มเหลว session จะหายไป
  • หากไม่ตอบสนอง ต้องกู้คืนคอนเทนเนอร์ด้วยตนเอง
• ในมุมของการดีบัก การมีเพียงสตรีมเหตุการณ์ WebSocket ทำให้ไม่สามารถระบุจุดที่เกิดความขัดข้องได้ และเมื่อเข้าเชลล์ของคอนเทนเนอร์ก็มีข้อมูลผู้ใช้อยู่ด้วย จึงทำให้การดีบักเองก็ยาก
• harness ตั้งสมมติฐานว่างานทั้งหมดอยู่ภายในคอนเทนเนอร์ ดังนั้นเมื่อมีความต้องการเชื่อมต่อกับ VPC ของลูกค้า จึงจำเป็นต้องทำ network peering หรือรัน harness ในสภาพแวดล้อมของลูกค้าเอง

การแยกสมองออกจากมือ (สถาปัตยกรรมหลัก)

• แยก "สมอง" (Claude และ harness), "มือ" (sandbox และเครื่องมือ) และ "session" (ล็อกเหตุการณ์) ออกเป็นอินเทอร์เฟซอิสระจากกัน
• แต่ละองค์ประกอบสามารถล้มเหลวหรือถูกเปลี่ยนแทนได้อย่างอิสระ

harness ออกจากคอนเทนเนอร์

• ย้าย harness ออกนอกคอนเทนเนอร์ ทำให้สามารถเรียกคอนเทนเนอร์เหมือนเครื่องมืออื่นผ่าน execute(name, input) → string
• คอนเทนเนอร์จึงเปลี่ยนจาก "cattle" (อินสแตนซ์ที่เปลี่ยนแทนได้)
• เมื่อคอนเทนเนอร์ล้มเหลว harness จะจัดการเป็นข้อผิดพลาดจากการเรียกเครื่องมือ และถ้า Claude ตัดสินใจลองใหม่ ก็จะใช้ provision({resources}) เพื่อเริ่มต้นคอนเทนเนอร์ใหม่

การกู้คืนเมื่อ harness ล้มเหลว

• เพราะ session log อยู่ภายนอก harness จึงไม่มีสถานะใดในตัว harness ที่ต้องคงอยู่
• เมื่อเกิดความขัดข้อง สามารถใช้ wake(sessionId) → getSession(id) เพื่อดึง event log และกลับมาทำงานต่อจากเหตุการณ์สุดท้าย
• ระหว่าง agent loop harness จะใช้ emitEvent(id, event) เพื่อคงไว้ซึ่งการบันทึกเหตุการณ์แบบทนทาน

ขอบเขตด้านความปลอดภัย

• ในการออกแบบแบบผูกติดกัน โค้ดที่ Claude สร้างซึ่งไม่น่าเชื่อถือจะรันอยู่ในคอนเทนเนอร์เดียวกับข้อมูลรับรอง ทำให้ prompt injection สามารถขโมย environment variable ได้
• หากผู้โจมตีได้โทเค็นไป ก็สามารถสร้าง session ใหม่และมอบหมายงานได้โดยแทบไม่มีข้อจำกัด
• วิธีแก้เชิงโครงสร้างคือแยกออกเพื่อให้ sandbox ไม่มีทางเข้าถึงโทเค็นได้เลย
• Git: ตอนเริ่มต้น sandbox จะ clone ด้วยโทเค็นสำหรับเข้าถึงรีโพซิทอรีและเชื่อมกับ git remote ในเครื่อง ทำให้เอเจนต์สั่ง push/pull ได้โดยไม่ต้องจับโทเค็นโดยตรง
• เครื่องมือแบบกำหนดเองของ MCP: เก็บ OAuth token ไว้ใน vault ที่ปลอดภัย และเมื่อเรียกเครื่องมือ MCP ผ่านพร็อกซีเฉพาะ ระบบจะดึงข้อมูลรับรองจาก vault ด้วยโทเค็นที่ผูกกับ session เพื่อเรียกบริการภายนอก

session ไม่ใช่ context window ของ Claude

• งานระยะยาวมักยาวเกิน context window ของ Claude จึงจำเป็นต้องมีการตัดสินใจแบบย้อนกลับไม่ได้ว่าอะไรควรถูกเก็บไว้
• compaction: ให้ Claude เก็บสรุปของ context window
• เครื่องมือ memory: ให้ Claude เขียนคอนเท็กซ์ลงไฟล์เพื่อเรียนรู้ข้าม session ได้
• การ trim context: ลบโทเค็นที่เลือกได้ เช่น ผลลัพธ์เครื่องมือเก่า หรือบล็อกความคิด
• การทิ้งคอนเท็กซ์แบบย้อนกลับไม่ได้อาจนำไปสู่ความล้มเหลว เพราะยากที่จะคาดเดาว่าโทเค็นใดที่เทิร์นในอนาคตจะต้องใช้
• งานวิจัยก่อนหน้านี้สำรวจแนวทางเก็บคอนเท็กซ์เป็นออบเจ็กต์ที่อยู่นอก context window แล้วให้ LLM เขียนโค้ดเพื่อเข้าถึงมันเชิงโปรแกรม

การใช้ session log ใน Managed Agents

• session ทำหน้าที่เป็นออบเจ็กต์คอนเท็กซ์ที่อยู่นอก context window
• ถูกเก็บอย่างทนทานในsession log ไม่ใช่ใน sandbox หรือ REPL
• ผ่านอินเทอร์เฟซ getEvents() สามารถเลือกslice ของ event stream ตามตำแหน่งได้
  • อ่านต่อจากจุดที่อ่านล่าสุด
  • ย้อนกลับไปดูหลายเหตุการณ์ก่อนจุดเวลาที่กำหนด
  • อ่านคอนเท็กซ์ซ้ำก่อน action บางอย่าง
• เหตุการณ์ที่ดึงมาแล้วสามารถแปลงใน harness ก่อนส่งเข้า context window ของ Claude
• การแปลงนี้รวมถึงการจัดระเบียบคอนเท็กซ์และ context engineering เพื่อให้ได้อัตรา prompt cache hit สูง
• session รับประกันเพียงการเก็บและเรียกดูแบบทนทาน ส่วนการจัดการคอนเท็กซ์อย่างเป็นรูปธรรมมอบให้ harness เพื่อรองรับความต้องการของโมเดลในอนาคตที่อาจเปลี่ยนไป

หลายสมอง หลายมือ

หลายสมอง (Many Brains)

• การแยกสมองออกจากมือช่วยแก้ปัญหาข้อร้องเรียนช่วงแรกของลูกค้า: เมื่อต้องทำงานกับทรัพยากรใน VPC ก็ไม่จำเป็นต้องทำ network peering อีกต่อไป
• ในการออกแบบเดิม แต่ละสมองต้องมีคอนเทนเนอร์ของตัวเอง ทำให้เริ่มอนุมานไม่ได้จนกว่าการ provision คอนเทนเนอร์จะเสร็จ
• แม้แต่ session ที่ไม่ต้องใช้ sandbox ก็ยังต้องแบกรับต้นทุนการตั้งค่าคอนเทนเนอร์เต็มรูปแบบ เช่น clone รีโพซิทอรี บูตโปรเซส และดึง pending event
• หลังแยกออก จะ provision เป็นการเรียกเครื่องมือเฉพาะเมื่อจำเป็นต้องมีคอนเทนเนอร์ จึงตัดเวลารอที่ไม่จำเป็นออกไป
• การอนุมานเริ่มได้ทันทีที่ orchestration layer ดึง pending event จาก session log
• p50 TTFT ลดลงราว 60%, และ p95 TTFT ลดลงมากกว่า 90%
• การขยายเป็นหลายสมองทำได้ง่าย ๆ ด้วยการเริ่ม harness แบบ stateless หลายตัว และเชื่อมกับมือเมื่อจำเป็นเท่านั้น

หลายมือ (Many Hands)

• ต้องมีความสามารถในการเชื่อมแต่ละสมองเข้ากับสภาพแวดล้อมการทำงานหลายชุด
• เพราะ Claude ต้องให้เหตุผลเกี่ยวกับหลายสภาพแวดล้อมและตัดสินใจจัดสรรงาน จึงเป็นภารกิจที่ยากเชิงความคิดมากกว่าการมีเชลล์เดียว
• ช่วงแรกวางสมองไว้ในคอนเทนเนอร์เดียวเพราะความสามารถของโมเดลยังไม่พอ แต่เมื่อความฉลาดดีขึ้น คอนเทนเนอร์เดี่ยวกลับกลายเป็นข้อจำกัด
• ในการออกแบบแบบแยก แต่ละมือถูกมองเป็นเครื่องมือ execute(name, input) → string
  • รองรับทั้งเครื่องมือแบบกำหนดเอง, เซิร์ฟเวอร์ MCP และเครื่องมือภายใน
  • harness ไม่จำเป็นต้องรู้ว่า sandbox เป็นคอนเทนเนอร์ โทรศัพท์ หรืออีมูเลเตอร์ Pokémon
• เพราะสมองและมือไม่ได้ผูกติดกัน จึงสามารถส่งต่อมือข้ามสมองได้ด้วย

บทสรุป: Managed Agents ในฐานะ meta-harness

• เป็นแนวทางเดียวกับที่ระบบปฏิบัติการจำลองฮาร์ดแวร์เพื่อรองรับโปรแกรมที่ยังไม่มีอยู่
• Managed Agents เป็นmeta-harness ที่ไม่ผูกกับ harness แบบใดแบบหนึ่ง และให้อินเทอร์เฟซทั่วไปที่รองรับ harness ได้หลากหลาย
• Claude Code ก็สามารถใช้เป็น harness แบบหนึ่งได้ และยังรองรับagent harness ที่ปรับแต่งตามงานเฉพาะได้ด้วย
• มีจุดยืนที่ชัดเจนต่ออินเทอร์เฟซ: Claude ต้องมีความสามารถในการจัดการสถานะ (session) และ ดำเนินการคำนวณ (sandbox)
• เป็นการออกแบบอินเทอร์เฟซเพื่อการขยายไปสู่หลายสมองและหลายมือ รวมถึงการปฏิบัติการที่มั่นคงและปลอดภัยในระยะยาว
• ไม่มีการตั้งสมมติฐานใด ๆ เกี่ยวกับจำนวนหรือตำแหน่งของสมองและมือ