เวลาที่เราวางสถาปัตยกรรม Multi-Agent สำหรับการพัฒนาซอฟต์แวร์ โดยมี Lead Agent และบรรดา Sub-agents ทำงานร่วมกัน สิ่งที่นักพัฒนาซอฟต์แวร์มักมองข้ามไม่ได้คือเรื่องของ "การกำหนดบทบาทและการบริหาร Token Budget" คำถามคือเราควรยัดทุกอย่างไว้ในที่เดียว หรือควรแยกย่อยเพื่อคุมขอบเขตงานอย่างเหมาะสม?
หากเราใส่ฟังก์ชัน คู่มือ หรือเวิร์กโฟลว์ทั้งหมดลงไปใน System Instruction ของ Agent ตัวเดียวแบบเบ็ดเสร็จ ตัว Config จะพองโตขึ้นจนเกิดภาวะ Token Bloat ทันที ผลลัพธ์คือในทุกๆ Turn ของการสนทนา ระบบจะต้องส่งก้อนข้อมูลมหาศาลนี้วนซ้ำเข้า In-memory Context ซ้ำแล้วซ้ำเล่า ทำให้เปลืองค่าใช้จ่าย และส่งผลให้ Runtime ในการประมวลผลช้าลงอย่างเห็นได้ชัด ดังนั้น การทำความเข้าใจเส้นแบ่งระหว่างสิ่งที่ควรอยู่ใน System Instruction และสิ่งที่ควรถูกผลักไปเป็น Skill จึงเป็นกุญแจสำคัญในการแก้ปัญหานี้
สิ่งไหนควรอยู่ และสิ่งไหนไม่ควรอยู่ใน System Instruction
สิ่งที่ "ควรอยู่" ใน System Instruction (Persistent Baseline)
ใส่เฉพาะสิ่งที่จำเป็นต่อการเป็น Orchestrator และควบคุมขอบเขตความปลอดภัยตลอดการทำงาน:
- Execution Boundaries & Safety: กฎเหล็กเรื่องการป้องกัน Secret Files, การจำกัด Directory Access และการห้ามสั่ง Git Push หรือ Commit โดยไม่ผ่านการ Confirm
- Core Delegation Loop: กระบวนการสั่งการขั้นพื้นฐาน เช่น การอ่าน Plan, การส่งต่อ Scope งานให้ Sub-agents (เช่น Backend, Frontend, Tester) และการจัดการเมื่อเกิด Error
- Sub-agent Isolation Rules: กำหนดสิทธิ์ของ Sub-agents แต่ละตัวให้อยู่ใน Scope ตนเอง เพื่อไม่ให้ Context ของ Sub-agents ตีกันเอง
- Fallback Behavior: แนวทางเมื่อเกิด Concern หรือข้อผิดพลาด เช่น บันทึก Log ลงไฟล์ แล้ว Skip ไปรัน Plan ถัดไปเพื่อไม่ให้ระบบค้าง
สิ่งที่ "ไม่ควรอยู่" ใน System Instruction (ควรย้ายไปเป็น Skill)
เมื่อเราจำกัดพื้นที่ใน System Instruction เรียบร้อยแล้ว เนื้อหาเชิงลึกที่เหลือควรถูกจัดเก็บในรูปของ Skill เพื่อเชื่อมโยงเข้าสู่ระบบแบบเฉพาะกิจ:
- Detailed Step-by-Step Workflows: ขั้นตอนการตรวจ Checklists, การรัน Test Suite เฉพาะทาง หรือขั้นตอนการแก้บั๊กเชิงลึก
- Release & Deployment Procedures: สเตปการเตรียมส่งมอบงาน และการตรวจสอบ Breaking Changes
- Incident Response & Debugging: ขั้นตอนการวิเคราะห์ Root Cause เมื่อระบบเกิด Failure ในวงกว้าง
- Domain-Specific Tasks: สคริปต์การทำ Performance Load Testing (เช่น k6), การตั้งค่า Database Migration หรือขั้นตอนการเขียน E2E Test
เจาะลึก Token Budget: ผลกระทบต่อ Runtime และ Sub-agents
การแยก System Instruction ออกจาก Skill ไม่ได้ทำเพื่อความเป็นระเบียบของไฟล์เท่านั้น แต่ส่งผลโดยตรงต่อการคำนวณ Token ในระบบ เนื่องจากกลไกการโต้ตอบของ AI จะนับข้อมูลเป็นรอบๆ ที่เรียกว่า Turn (ส่ง 1 ครั้ง + ตอบ 1 ครั้ง) ซึ่งสะสมรวมกันเป็น Session
System Instruction จะถูกนับเป็น Persistent Token Overhead หรือ Fixed Cost ที่จ่ายซ้ำทุก Turn หากเขียนไว้หนาถึง 2,000 Tokens เมื่อคุยกันเพียง 10 Turns ค่าใช้จ่ายจะพุ่งไปถึง 20,000 Tokens ทันที ในทางกลับกัน Skill ใช้หลักการ Dynamic & Lazy Loading คือโหลดเข้า Context เฉพาะ Turn ที่ถูกเรียกใช้งาน แล้วเคลียร์ออกเมื่อจบงาน ช่วยตัดภาระ Token ส่วนเกินได้อย่างชะงัด
เมื่อโครงสร้างนี้ถูกส่งต่อไปยัง Sub-agents (เช่น Backend, Frontend, Tester) จะเกิดประโยชน์ 2 ต่อทันที:
- รักษาความแม่นยำของ Lead Agent: Lead Agent ไม่ต้องแบกรับคู่มือโค้ดดิ้งเชิงลึก ทำให้ Context ไม่เต็มเร็ว และคงระดับความแม่นยำในการวางแผนและแจกจ่ายงาน (Orchestration Accuracy) ได้ดีที่สุด
- สร้าง Lean Context ให้ Sub-agents: Sub-agent ฝ่าย Backend จะรับเฉพาะ Skill ที่เกี่ยวกับ NestJS หรือ Database Migration โดยไม่ต้องรับรู้ Skill ของ Tester ส่งผลให้ประมวลผลได้ตรงจุด รวดเร็ว และประหยัด Token Budget รวมของทั้งระบบได้อย่างมหาศาล
Dev Takeaway: วาง Core Loop และ Safety Guardrails ไว้ใน System Instruction เพื่อให้ Agent คุมจังหวะและขอบเขตงานได้มั่นคง แล้วเปลี่ยน Workflows เชิงลึกทั้งหมดให้เป็น Skills แบบ Lazy Load วิธีนี้ช่วยบล็อกปัญหา Token Bloat ลดต้นทุน และทำให้ Runtime ของเอเจนต์ตอบสนองได้รวดเร็วขึ้น
No comments:
Post a Comment