← Harness Engineering Handbook
LEVEL 3 · ขยายระบบ
Subagents & Orchestration — แตกงานให้หลาย agent
งานใหญ่ชิ้นเดียวอย่าง "อัปเกรด framework ทั้ง repo" — ถ้าให้ agent เดียวลุย สิ่งที่ตายก่อนไม่ใช่ความฉลาด แต่คือ context: แค่สำรวจว่ามีอะไรต้องแก้บ้างก็กินไปครึ่งโต๊ะแล้ว (บทที่ 3) · ทางออกของ harness ยุคนี้: จ้างลูกมือ — แตกงานให้ subagent ที่มี loop และ context ของตัวเอง
10.1 ทำไมต้องแตก — สองเหตุผล ไม่ใช่เหตุผลเดียว
- context isolation (เหตุผลหลักที่คนมองข้าม) — งานค้น/สำรวจที่เวิ่นเว้อ อ่าน 40 ไฟล์ ลองผิด 6 รอบ ทั้งหมดเกิดใน context ของลูก แล้วส่งกลับมาแค่ข้อสรุป 10 บรรทัด · โต๊ะของ agent หลักสะอาด เก็บไว้คิดเรื่องใหญ่
- ทำขนานได้ — งานที่อิสระต่อกัน 4 ชิ้น ปล่อยลูก 4 ตัวรันพร้อมกัน เวลารวมเท่างานที่ช้าสุด ไม่ใช่ผลบวกของทุกงาน
10.2 รูปแบบที่เจอบ่อย
- orchestrator–worker — ตัวหลักถือแผนและประกอบผล ลูกรับงานชิ้นเดียวจบ · ท่ามาตรฐานของงานใหญ่
- pipeline — ต่อแถว: ผลของตัวหนึ่งเป็นวัตถุดิบของตัวถัดไป (ค้น → ร่าง → ตรวจ) · แต่ละขั้นได้ context สะอาดเฉพาะเรื่องของตัว
- fan-out / verify — กระจายงานเดียวกันให้หลายลูกทำจากคนละมุม (ไล่หาบั๊กด้วย 5 มุมมอง) แล้วมีตัวตรวจ/รวมผล · ญาติทางความคิดกับ pass@k ที่จะเจอในบทที่ 11
10.3 การส่งงาน = เขียน prompt ให้คนที่ไม่เห็นบทสนทนาเรา
กับดักอันดับหนึ่งของมือใหม่: สั่งลูกว่า "แก้ไฟล์ที่คุยกันเมื่อกี้" — ลูกเกิดมาพร้อมโต๊ะเปล่า ไม่เห็นบทสนทนาของเรา ไม่รู้ว่า "เมื่อกี้" คืออะไร · brief ที่ดีจึงต้องครบในตัว: เป้าหมาย + บริบทที่จำเป็น (path, ข้อจำกัด) + นิยามว่าเสร็จคืออะไร + รูปแบบคำตอบที่ต้องการ — ทักษะเดียวกับการมอบงานให้ junior ที่เพิ่งเข้าทีมวันแรก และเป็นทักษะ prompt จากเล่ม #07 กลับมาในสเกลใหม่
10.4 ต้นทุนที่โบรชัวร์ไม่บอก
- ช่องสื่อสารแคบมาก — ลูกตอบกลับได้แค่ข้อความสรุป: รายละเอียดที่ไม่ถูกเขียนลงสรุป = หายตลอดกาล · ถ้าตัวหลักต้องรู้ลึก ต้องสั่งให้ลูก "รายงานสิ่งนี้กลับมาด้วย" ตั้งแต่ใน brief
- งานที่แชร์ state ไม่เหมาะ — สองลูกแก้ไฟล์เดียวกัน หรือการตัดสินใจถี่ ๆ ที่ต้องเห็นพร้อมกัน → ค่าประสานงานแพงกว่าตัวงาน ทำเองในตัวเดียวเร็วกว่า
- overhead ต่อหัว — ลูกทุกตัวจ่าย system prompt + สำรวจของตัวเองใหม่ · งานเล็ก ๆ ไม่คุ้มค่าแรกเข้า
กฎตัดสินใจสั้น ๆ: แตกเมื่องานสรุปกลับได้สั้นและทำอิสระได้จริง — แตกเพื่อ isolate ความรก ไม่ใช่แตกเพราะสถาปัตยกรรมดูเท่
10.5 ข้ามรั้ว: เมื่อ "ลูก" ไม่ได้อยู่บ้านเดียวกัน
ทั้งบทนี้พูดถึงการแตกงานแบบที่ลูกทุกตัวอยู่ในบ้านเดียวกัน — harness เดียวกัน โปรเสสเดียวกัน เรียกผ่าน tool ภายใน · คำถามที่ตามมาคือ agent ของทีมพี่ต้องคุยกับ agent ของบริษัทคู่ค้า ที่รันคนละเครื่อง คนละ vendor คนละ harness ล่ะ — นี่คือช่องว่างที่โปรโตคอลชื่อ A2A (Agent2Agent) เข้ามาแก้ Google เปิดตัวปี 2025 แล้วโอนให้ Linux Foundation ดูแลเป็นมาตรฐานกลาง มีทั้ง AWS, Microsoft, Salesforce, SAP ร่วมพัฒนา
กรอบคิดที่ทั้ง Google และ Anthropic ใช้ตรงกัน: MCP ต่อ agent เข้ากับเครื่องมือ/ข้อมูล (แนวตั้ง — ภายในองค์กรเดียว, บทที่ 4.5) ส่วน A2A ต่อ agent เข้ากับ agent อื่น (แนวนอน — ข้ามองค์กร/ข้าม vendor) — สองมาตรฐานเสริมกัน ไม่ใช่คู่แข่ง กลไกคือ formalize สิ่งที่บทนี้สอนไปแล้วให้ใช้ข้ามองค์กรได้: แทนเขียน prompt บอกงานตรง ๆ แบบข้อ 10.3 ฝั่งหนึ่งอ่าน "Agent Card" ของอีกฝั่งก่อน — เอกสารที่บอกว่ามันทำอะไรได้บ้าง คุยผ่านช่องไหน ยืนยันตัวตนแบบไหน — แล้วค่อยส่งงานให้ ติดตามสถานะผ่านวงจร submitted → working → เสร็จ/พัง/ถูกยกเลิก คล้าย FIG 10.1 แต่ "ลูก" ที่ว่าอาจไม่เคยรู้จักกันมาก่อนเลย
ความต่างที่สำคัญกว่าคำว่า "tool กับ agent": ฝั่งตรงข้ามของ A2A มีโมเดลของตัวเอง ตัดสินใจเอง ไม่ใช่ฟังก์ชันที่รอรับคำสั่ง งานจึงเป็นบทสนทนาหลายจังหวะ ถามกลับระหว่างทางได้ — ต่างจากเรียก MCP tool ที่เป็น request-response ครั้งเดียวจบ กับดักที่คนพลาดบ่อย: เอา agent อิสระไปห่อเป็น MCP tool ธรรมดา แล้วเจอปัญหาจ่าย token สองต่อและตอบคำถามกลางทางไม่ได้ — เพราะเลือกโปรโตคอลผิดชั้น
ความจริงที่ควรรู้ก่อนตื่นเต้นตามกระแส: การใช้งานจริงยังกระจุกอยู่ในองค์กรใหญ่ที่ต้องเชื่อม agent ข้ามบริษัทจริง ๆ (supply chain, การเงิน, ประกันภัย) ส่วนงานทั่วไปที่ต่อ agent ภายในองค์กรเดียวกัน MCP + subagent แบบที่บทนี้สอนยังตอบโจทย์เกือบทั้งหมด — เส้นตัดสินใจง่าย ๆ คือถามว่ามี "องค์กรอื่น" หรือ trust boundary ข้ามจริงไหม ถ้าไม่มี ก็ไม่ต้องแตะ A2A · และเพราะอีกฝั่งมีโมเดลของตัวเอง ภัยใหม่ที่มากับมันคือ agent ปลอมอวดความสามารถที่ไม่มีจริงใน Agent Card เพื่อหลอกให้ถูกเลือก — ญาติสายตรงของ prompt injection ที่บทที่ 6 สอนไว้: ยิ่งเปิดคุยกับใครก็ได้ ยิ่งต้องมีกำแพงชั้นแข็งรับไว้เท่านั้น
✅ สรุปบทที่ 10 — แตกงานด้วยสองเหตุผล: context isolation (ความรกตายในลูก ส่งกลับแค่สรุป) + ทำขนาน · รูปแบบ: orchestrator–worker, pipeline, fan-out/verify · การส่งงานคือเขียน prompt ให้คนไม่เห็นบทสนทนา — ต้องครบในตัว: เป้าหมาย บริบท นิยามเสร็จ รูปแบบคำตอบ · ข้อจำกัดใหญ่: ช่องสื่อสารแคบ งานแชร์ state ละเอียดไม่เหมาะ มี overhead ต่อหัว — แตกเมื่อสรุปได้สั้นและอิสระจริงเท่านั้น · ข้ามรั้วองค์กร/vendor ใช้ A2A แทน subagent ภายใน — คนละเครื่องมือ แต่หลักคิดเดียวกัน: บรีฟให้ครบ ต้องรู้ว่าอีกฝั่งทำอะไรได้ก่อนส่งงาน และระวังฝั่งตรงข้ามที่มีโมเดลของตัวเอง ไม่ใช่แค่ฟังก์ชัน