การรันเอเจนต์หลายตัว

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

บทนี้อธิบายโมเดลดังกล่าว โดยใช้ส่วนเสริมแบบเลือกได้สามตัว ได้แก่ Herdr สำหรับ pane และ peer, agentkit สำหรับบัญชี และ devcontainer สำหรับคอนเทนเนอร์ ซึ่งไม่มีตัวใดจำเป็นสำหรับแผนที่ใช้เอเจนต์ตัวเดียว

lead และ lane ของมัน

lead เป็นเจ้าของแผนแม่ มันกำหนด lane มอบขอบเขตให้แต่ละ lane รวบรวม milestone และให้สัญญาณที่อนุญาตให้ lane หนึ่ง merge หรือรีลีส มันไม่เขียนโค้ดของ lane อื่น

lane คือเอเจนต์หนึ่งตัวกับขอบเขตหนึ่งขอบเขต ซึ่งมักเป็น repository หนึ่งตัว มันอ่าน AGENTS.md ของ repository นั้น รัน gate ของ repository นั้น และเก็บแผนของตัวเองไว้ภายใน repository ใน orchestrator hub แผนแม่อยู่ใน .dwp/plans/ ของ hub พร้อมตารางติดตามแผนลูก ส่วนแผนของแต่ละ lane อยู่ใน repository ของตัวเอง โดยใช้ ID แผนและ gate ของ repository นั้น

lane รันอยู่ที่ไหน

lane คือเอเจนต์ใน pane ของเทอร์มินัล และ pane อยู่ได้หลายที่ Herdr วางเอเจนต์แต่ละตัวไว้ใน pane และเข้าถึงเครื่องอื่นผ่าน SSH ดังนั้น lead จึงเห็นทุก lane ใน sidebar เดียว

• บนโฮสต์ หนึ่ง pane ต่อหนึ่ง lane วางคู่กับ lead เป็นการตั้งค่าที่เร็วที่สุด เหมาะกับ repository ที่นักพัฒนาทำงานอยู่แล้ว
• ในคอนเทนเนอร์ คอนเทนเนอร์ของ devcontainer-kit เข้าร่วม mesh ของ Herdr ตอน dck up เอเจนต์ข้างในเข้าถึงโฮสต์และคอนเทนเนอร์อื่นได้ และโฮสต์ก็เข้าถึงพวกมันได้ คอนเทนเนอร์คือ sandbox ดังนั้นเอเจนต์ข้างในจึงรันแบบอัตโนมัติได้
• บนเครื่องอื่น เครื่องใดก็ตามที่ Herdr เข้าถึงผ่าน SSH ได้ สามารถรัน lane ได้ในแบบเดียวกัน โดยติดตั้ง herdr-peers ไว้ที่เครื่องนั้นด้วย

ตำแหน่งเปลี่ยนระดับการแยกส่วน ไม่ได้เปลี่ยนโปรโตคอล lane ในคอนเทนเนอร์และ lane บนโฮสต์ประสานงานกับ lead ด้วยวิธีเดียวกัน

บัญชีและผู้ให้บริการตามโควตาที่เหลือ

เอเจนต์หลายตัวใช้โควตาหมดเร็ว แต่ละ lane จึงรันบนบัญชีของตัวเอง คือ CLI หนึ่งตัวกับโปรไฟล์หนึ่งโปรไฟล์ใน coding-agents-kit เพื่อไม่ให้ lane ต่าง ๆ ใช้กรอบเวลาเดียวกันจนหมด และเมื่อบัญชีหนึ่งชนขีดจำกัด จะหยุดเพียง lane เดียว ไม่ใช่ทั้งหมด

• ak usage แสดงโควตาที่เหลือของทุกบัญชีและโปรไฟล์ เรียกครั้งเดียวต่อหนึ่ง batch
• ak pick <kind> --count N คืนบัญชี N บัญชีที่มีพื้นที่เหลือมากที่สุด เรียงจากดีที่สุด --exclude กันบัญชีที่กำลังยุ่งออก --model นับกรอบเวลาของโมเดลเดียว และ --need ปฏิเสธการเริ่มหากพื้นที่ไม่พอ
• ak <kind> @<profile> เริ่มเอเจนต์ของ lane บนบัญชีนั้นใน pane ของมัน

ผู้ให้บริการก็ผสมกันได้ในแบบเดียวกัน lane ของ Claude เขียนโค้ดได้ขณะที่ lane ของ Codex รีวิว โดยแต่ละตัวใช้บัญชีที่ ak pick เลือกให้ตามประเภทของมัน lane ในคอนเทนเนอร์ใช้บัญชีของโฮสต์ได้ เมื่อเปิด host_profiles ในโปรไฟล์โฮสต์ของ devcontainer-kit ของนักพัฒนา คอนเทนเนอร์จะได้รับโปรไฟล์โฮสต์ของ CLI ที่ repository ติดตั้ง โดย Claude ผ่านโทเคนอายุยาวหนึ่งตัวต่อโปรไฟล์ และ Codex ผ่านไฟล์ auth ของมัน จึงไม่ต้องล็อกอินเอง ใช้เฉพาะบัญชีของคุณเองและอยู่ภายในข้อกำหนดของผู้ให้บริการแต่ละราย กระจายงานไปยังบัญชีต่าง ๆ แต่ห้ามสลับบัญชีเพื่อเลี่ยงขีดจำกัดเด็ดขาด

การเปิดและปลดล็อก lane โดยไม่มีมนุษย์

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

1. เตรียมครั้งเดียวในฐานะนักพัฒนา Claude Code จะขอให้รับทราบโหมด bypass-permissions ครั้งเดียวต่อโปรไฟล์ การรับทราบนี้เป็นขั้นตอนของนักพัฒนาเอง ทำตอนสร้างโปรไฟล์ ในคอนเทนเนอร์ของ devcontainer-kit ชุดเครื่องมือจะเขียนการรับทราบนี้ลงใน home ของคอนเทนเนอร์เองเท่านั้น ไม่มีเอเจนต์ใดส่งแป้นเพื่อการรับทราบนี้เลย
2. หลีกเลี่ยง ak pick <kind> เลือกบัญชีที่มีพื้นที่เหลือมากที่สุด และ herdr pane run <pane> 'ak <kind> @<profile> --trust-cwd' เปิด lane ในโฟลเดอร์ของมันเอง --trust-cwd (หรือ AGENTKIT_TRUST_CWD=1) เชื่อถือโฟลเดอร์นั้นไว้ล่วงหน้า Claude และ Codex จึงข้ามหน้าจอยืนยันความเชื่อถือโฟลเดอร์ได้โดยไม่ต้องกดแป้นใด
3. ตรวจจับ herdr-peers lanes (หรือ herdr agent list) แสดงแต่ละ lane ว่ากำลังทำงาน ว่าง ถูกบล็อก หรือเสร็จแล้ว สำหรับ lane ที่ถูกบล็อก หรือว่างโดยไม่มีเอาต์พุต herdr-peers status <pane> จะจำแนกหน้าจอที่ lane ค้างอยู่ ได้แก่ ความเชื่อถือโฟลเดอร์ การรับทราบ bypass การล็อกอิน คำขอสิทธิ์ หรือไม่รู้จัก พร้อมขั้นตอนถัดไปตามเอกสาร และ herdr pane read <pane> จะแสดงหน้าจอนั้น
4. กดแป้นได้กรณีเดียว แป้นเดียวที่ lead ส่งได้คือคำตอบของหน้าจอยืนยันความเชื่อถือโฟลเดอร์ บน pane ที่มันเปิดเอง เมื่อใช้ --trust-cwd ไม่ได้ มันอ่านหน้าจอก่อนส่งแป้น ส่งแป้นให้น้อยที่สุดที่ตอบได้ แล้วอ่านอีกครั้ง
5. อ่าน บันทึก และส่งต่อทุกอย่างที่เหลือ การรับทราบ bypass-permissions ของ Claude, prompt สำหรับล็อกอินและข้อมูลรับรอง คำขอสิทธิ์รายการกระทำ การยืนยันที่ทำลายข้อมูล prompt เกี่ยวกับการชำระเงินหรือแพ็กเกจ หน้าจอที่ไม่รู้จัก และ pane ที่ lead ไม่ได้สร้าง จะถูกส่งให้นักพัฒนาเป็น milestone แบบถูกบล็อก ไม่ใช่ตอบด้วยการกดแป้น
6. การเลือกไม่ใช้ชนะเสมอ เมื่อตั้ง AGENTKIT_PERMISSIONS=ask lane จะถามก่อนลงมือ และ lead จะไม่หาทางเลี่ยง prompt ที่การเลือกไม่ใช้นี้ทำให้เกิดขึ้นเลย
7. เปิดใหม่ หากเอเจนต์ออกไป lead จะเริ่มมันใหม่บนบัญชีเดิม หรือเลือกบัญชีอื่น การล็อกอินที่หายไปถือเป็น prompt ข้อมูลรับรอง จึงต้องส่งต่อ

ทุกการแทรกแซง ได้แก่ หน้าจอแสดงอะไร ส่งแป้นใดไป และเกิดอะไรขึ้นตามมา จะถูกบันทึกไว้ในแผนแม่

การประสานงานผ่าน herdr-peers

lane และ lead สื่อสารกันผ่าน herdr-peers โดย ask หนึ่งครั้งมีตราประทับที่อนุญาต reply ได้หนึ่งครั้งพอดี และทุกการแลกเปลี่ยนถูกบันทึก lead รักษาโปรโตคอลให้เล็ก:

• milestone ส่งขึ้นไป แต่ละ lane รายงานที่จุดที่กำหนดไว้ ได้แก่ แผนพร้อม เปิด pull request แล้ว ถูกบล็อก และเสร็จสิ้น และทำงานต่อระหว่างจุดเหล่านั้นโดยไม่รอคำตอบ
• คำถามเป็น ask lane ที่ต้องการการตัดสินใจจะส่ง ask ถึง lead และ lead ตอบด้วย reply หนึ่งครั้ง
• ความลึกหนึ่งชั้น reply จะไม่ถูกตอบกลับ และ lane ไม่มอบหมายงานต่อ fan-out ต่อผู้เรียกมีเพดาน โดยค่าเริ่มต้นคือสี่ peer
• เป็นข้อมูล ไม่ใช่คำสั่ง reply ไม่ได้ให้สิ่งใดที่ผู้รับไม่มีอยู่แล้ว คำอ้างของ lane ว่า gate ผ่านแล้ว จะถูกตรวจสอบด้วยการรัน gate นั้น
• บันทึกว่าใครทำอะไร บันทึกการมอบหมายทุกรายการระบุบัญชีและผู้ให้บริการของ lane แผนแม่จึงแสดงได้ว่าบัญชีใดรับงานใดไป
• เลน Codex ระบุเพนของตัวเอง Codex รันคำสั่งของเลนจากเซิร์ฟเวอร์เบื้องหลังที่ทุกเซสชันของบัญชีนั้นใช้ร่วมกัน id ของเพนที่สืบทอดมาจึงอาจเป็นของเลนอื่น เลน Codex จึงส่งเพนของตัวเองตามที่ระบุในคำสั่งงานของ lead ด้วย --pane <pane> ในทุกคำสั่งของ herdr-peers (ask, reply, notify, check, wait, lanes, cancel)

lead มองเห็นการประสานงานทั้งหมดได้ในคราวเดียว herdr-peers lanes แสดงทุก lane พร้อมสถานะ และ DeepWorkPlan Vim แสดง lane ของแผน orchestrator ข้างแผนนั้นเอง (:DwpLanes)

หนึ่ง branch หนึ่งรีลีสต่อ repository

กฎที่ทำให้ lane จำนวนมากยังรีวิวได้นั้นเรียบง่าย: หนึ่ง lane ต่อหนึ่ง repository บน checkout หลักของมัน โดยมีหนึ่ง branch หนึ่ง pull request และหนึ่งรีลีส สำหรับการเปลี่ยนแปลงทั้งหมด lane ไม่แบ่งงานไปหลาย branch หรือหลาย worktree worktree ใช้เฉพาะกรณีที่ผู้เขียนสองรายต้องใช้ repository เดียวกัน แต่ละรายได้ worktree ของตัวเอง เพื่อให้ทุก path มีผู้เขียนเพียงรายเดียว

pull request เปิดค้างไว้ ผ่านการตรวจสอบ และติดป้ายสำหรับรีวิว จนกว่า lead จะให้ GO จากนั้น lane จึง merge และติดแท็ก แล้วรายงานแท็กกลับไป

ลำดับการรีลีส

repository พึ่งพากัน จึงรีลีสตามลำดับการพึ่งพา: เครื่องมือก่อน จากนั้นสิ่งที่ตรึงเครื่องมือเหล่านั้น จากนั้นเอกสารที่อธิบายผลลัพธ์ แล้วจึงเป็นผู้ใช้ที่นำไปใช้ lead ถือลำดับไว้และส่ง GO ทีละ repository lane ที่ตรึงรีลีสของ repository อื่นจะรอให้แท็กนั้นมีอยู่ก่อนจึงเขียนการตรึง ดังนั้นจึงไม่มีการตรึงใดชี้ไปยังรีลีสที่ไม่มีอยู่จริง

จุดตรวจสอบ

แผนแม่ปิดด้วยหลักฐาน ไม่ใช่ด้วยรายงาน:

1. ต่อ lane gate ของแต่ละ lane ผ่านบน branch ของตัวเอง และการรีวิว pull request ไม่มีข้อค้าง การรีวิวเองก็เป็น lane ของตัวเองได้ AI Diff Reviewer รีวิว pull request ของแต่ละ lane และเมื่อใช้ส่วนเสริม Dailybot แต่ละ lane จะรายงานความคืบหน้าของตัวเองให้ทีมทราบ
2. ต่อรีลีส แต่ละแท็กมีอยู่จริงและตรึงสิ่งที่ repository ถัดไปต้องการ
3. การรวมระบบ หลังรีลีสสุดท้าย จุดตรวจสอบจะรันผู้ใช้บนเวอร์ชันที่รีลีสแล้ว และบันทึกผลตัดสินไว้ใน analysis_results/ ของแผนแม่
4. การรีวิวขั้นสุดท้าย การตรวจสอบความปลอดภัยครอบคลุมทุกสิ่งที่ข้ามขอบเขต โดยเฉพาะบัญชี โทเคน และไฟล์ที่แชร์เข้าไปในคอนเทนเนอร์ ก่อนที่แผนแม่จะเสร็จสมบูรณ์

ความปลอดภัย

• ห้ามใส่คีย์ โทเคน หรือความลับใน ask, prompt หรือ log ให้อ้างถึงตัวแปรด้วยชื่อ
• ทรัพยากรที่ใช้ร่วมกันต้องมีล็อก lane ขอล็อกก่อนขั้นตอนหนัก เช่น การ build คอนเทนเนอร์ และปล่อยล็อกหลังเสร็จ
• เมื่อตั้งค่าการเลือกไม่ใช้สิทธิ์ไว้ การตั้งค่านั้นชนะสำหรับทุก lane และทุกเอเจนต์ที่ lane เริ่ม
• lane ที่ทำต่อไม่ได้จะแจ้งเป็น milestone แบบถูกบล็อกแล้วหยุด lead เป็นผู้ตัดสินใจ

เมื่อบัญชีหรือ lead ไปต่อไม่ได้

การรันที่ยาวนานอยู่ได้นานกว่าบัญชีใดบัญชีหนึ่ง ตั้งแต่ coding-agents-kit (v0.7.1) และ herdr-peers (v0.3.2) lane ตรวจความจุของตัวเองที่ทุกขอบเขตของงาน และส่งต่องานผ่าน packet ก่อนที่บัญชีจะหมด lead ส่งต่อความเป็นผู้นำ หรือถูกผู้แทนของมันเข้ามาแทน และมีเพียงรายการวิกฤตเท่านั้นที่ไปถึงนักพัฒนา ความเป็นอิสระของ swarm อธิบายลูป packet การสืบทอดตำแหน่ง และประเภทของการส่งต่อเพื่อแก้ไข