ความเป็นอิสระของ swarm

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

ความล้มเหลวที่บทนี้ตอบนั้นเป็นรูปธรรม: lead ที่โควตาหมดกลางแผนทำให้ทุก lane ติดค้าง และไม่มีอะไรขยับจนกว่าจะมีคนเปิดเซสชันใหม่ ด้วยกฎด้านล่าง แผนจะเดินหน้าต่อไปภายในการอนุญาตที่นักพัฒนาให้ไว้แล้ว

กฎหกข้อกำหนดรูปแบบของทุกอย่างในบทนี้:

1. หนึ่งหน้าที่ต่อหนึ่งผลิตภัณฑ์ coding-agents-kit (ak) รู้เรื่องบัญชีและความจุ herdr-peers รู้เรื่องข้อความ pane และใครเป็น lead ส่วนแพ็ก Deep Work Plan รู้เรื่องวิธีการ: เมื่อใดควรส่งต่องาน ผู้สืบทอดต้องการอะไร และอะไรควรส่งต่อเพื่อแก้ไข แต่ละตัวยังคงเป็นแบบเลือกใช้ หากไม่มีพวกมัน กฎเดียวกันยังคงใช้อยู่ โดยนักพัฒนาเป็นผู้ส่งต่อข้อความและเปิดเอเจนต์ใหม่
2. หน่วยของความต่อเนื่องคือแผน ไม่ใช่เอเจนต์ ทุก handoff และทุกการสืบทอดตำแหน่งคือการ resume ตามปกติบวกกับ packet ขนาดเล็กที่บรรจุสิ่งที่ journal ไม่ได้บันทึก นั่นคือเจตนาที่กำลังดำเนินอยู่
3. เชิงรุกดีกว่าเชิงรับ เอเจนต์ตรวจพื้นที่เหลือของตัวเองที่ขอบเขตของงาน และส่งต่องานขณะที่ยังเขียน packet ที่ดีได้ การตอบสนองหลังชนขีดจำกัดยังคงเป็นตาข่ายนิรภัย
4. ความเป็นอิสระไม่เคยขยายอำนาจ handoff การสืบทอดตำแหน่ง การเปิดเอเจนต์ และการจัดตารางงาน ทำงานภายในการอนุญาตของแผน ไม่มีเอเจนต์ใดตอบหน้าจอสิทธิ์ bypass การล็อกอิน ความยินยอม หรือการชำระเงิน และงานย้ายไปมาเฉพาะในบรรดาบัญชีที่นักพัฒนาประกาศไว้
5. ความต่อเนื่องไม่เคยลดมาตรฐาน ผู้สืบทอดได้รับ gate ชุดเดียวกัน packet ไม่ปิดเกณฑ์ใด ไม่ผ่อน gate ใด และไม่ข้ามการรีวิวใด
6. ต้นทุนต่ำตั้งแต่ในโครงสร้าง ความจุถูกอ่านจาก cache ที่ขอบเขตของงาน ไม่เคยอ่านในลูปหรือตามตัวจับเวลา notice ทางเดียวแทนที่คำถามที่ไม่ต้องการคำตอบ และ packet มีขนาดเล็ก

บทบาท

• lead ต้องพร้อมทำงานเสมอ orchestrator ที่ lane ต้องรอมนุษย์ส่งต่อข้อความจะหยุดชะงัก lead ไม่หยุด swarm เพื่อคำถามที่มันตัดสินใจเองได้
• หนึ่งผู้ดำเนินการต่อหนึ่งแผน แผนหรือแผนลูกหนึ่งแผนมีเอเจนต์ดำเนินการเพียงตัวเดียวในแต่ละช่วงเวลา เอเจนต์ตัวที่สองบนแผนเดียวกันคือข้อผิดพลาดด้านการประสานงานที่ lead ต้องแก้
• อำนาจมาจากแผน ไม่ใช่จาก peer lane อ่านการอนุญาตของแผนด้วยตัวเอง การอนุมัติที่เอเจนต์อื่นส่งต่อมาไม่ได้เพิ่มสิ่งใดที่ lane ไม่มีอยู่แล้ว
• lead หลายตัว ทำงานใน workspace เดียวกันได้ โดยแต่ละตัวนำแผนที่ต่างกัน บัญชีหนึ่งถูกถือโดย lane เดียวในแต่ละช่วงเวลาผ่าน lease ของ ak lead สองตัวจึงไม่มีทางวางผู้เขียนสองรายไว้บนบัญชี Codex เดียวกัน
• หลายอินสแตนซ์ของประเภทเดียวกัน — pane ของ Grok สามตัว pane ของ Codex สี่ตัวบนโปรไฟล์เดียวหรือหลายโปรไฟล์ — คือ lane ธรรมดา อินสแตนซ์บนโปรไฟล์เดียวกันใช้ความจุของโปรไฟล์นั้นร่วมกัน

ทุก lane มีแผน อย่างน้อยเป็นแผน Lite ใน repository ของตัวเอง และแผนนั้นคือสิ่งแรกที่ผู้สืบทอดอ่าน ทุก lane รายงานต่อ lead ด้วยคำศัพท์ที่ตายตัว — plan ready, PR open <url>, blocked <class> <what it needs>, handoff <packet path>, done — และปิดท้ายแต่ละข้อความด้วยบรรทัดความจุหนึ่งบรรทัด เช่น capacity=ok 64% @work1 lead จึงแทบไม่ต้องอ่านโควตาเอง

ลูปความจุ

เอเจนต์ตรวจพื้นที่เหลือของตัวเองก่อนเริ่มแต่ละงาน หลัง gate หรือขั้นตอนใดที่ใช้เวลานานกว่า 20 นาที ทุกครั้งที่ CLI แสดงคำเตือนขีดจำกัดการใช้งาน และก่อนยอมรับ handoff หรือความเป็นผู้นำ การตรวจคือ ak capacity --self --json จาก coding-agents-kit v1.0.1 ซึ่ง helper ของแพ็กแปลงเป็นการตัดสินใจ:

• เกณฑ์ เป็นของชุดเครื่องมือ: ค่าเริ่มต้นคือต่ำที่ 25 % และวิกฤตที่ 10 % ของสัดส่วนที่ว่างในกรอบเวลาที่เป็นตัวกำหนด (binding window) ปรับได้ด้วย AGENTKIT_CAPACITY_LOW และ AGENTKIT_CAPACITY_CRITICAL ค่าที่อ่านได้มาจาก cache ที่เก็บไว้ 300 วินาที การตรวจทุกขอบเขตของงานจึงมีต้นทุนเพียงการเรียกผู้ให้บริการไม่กี่ครั้งต่อชั่วโมง
• ฮิสเทอรีซิส เมื่อเขียน packet แล้ว handoff จะดำเนินจนเสร็จ เอเจนต์ไม่กลับไปทำงานนั้นต่อหลังบัญชีฟื้นตัว ผู้สืบทอดเป็นเจ้าของงานนั้น และบัญชีที่ฟื้นตัวก็เพียงกลับเข้าสู่ pool
• แรงกดดันของบริบทก็นับด้วย เมื่อบริบทของเอเจนต์ถึงเกณฑ์บริบทใหม่ของสัญญา (ค่าเริ่มต้น 60 %) จะตามมาด้วย packet และ handoff แบบเดียวกัน
• ลดระดับอย่างซื่อตรง หากไม่มีชุดเครื่องมือ ใช้ชุดเครื่องมือรุ่นเก่า หรืออยู่นอกการเปิดด้วย ak ความจุจะถูกรายงานเป็น unknown ไม่เคยเป็น ok

pool เป็นของนักพัฒนา แผนบันทึกบัญชีที่นักพัฒนาประกาศไว้สำหรับงาน เอเจนต์ไม่สร้างบัญชี ไม่ต่ออายุการล็อกอิน ไม่ใช้สิทธิ์รีเซ็ตของ Codex และไม่ใช้บัญชีนอก pool และทำงานภายในข้อกำหนดของผู้ให้บริการแต่ละราย การย้ายงานก่อนถึงขีดจำกัดภายใน pool คือการจัดตารางงาน การสลับบัญชีเพื่อเลี่ยงขีดจำกัดไม่ได้รับอนุญาตเด็ดขาด สำหรับแต่ละงานที่พร้อม lead เลือกบัญชีอันดับดีที่สุดจาก ak pick --owner <lead> จองให้กับที่อยู่ของ lane นั้นเองด้วย ak lease ไม่มอบบัญชีของ lead เองให้ lane ใดเลย (ทั้งสองจะถึงระดับ critical พร้อมกัน) เลือกบัญชีที่รู้ความจุสำหรับงานยาวและผู้ให้บริการอื่นสำหรับ reviewer และมีผู้แทนไว้เสมอ เมื่อไม่มีบัญชีใดใน pool ที่มีพื้นที่เหลือ และไม่มีบัญชีใดรีเซ็ตภายในกรอบเวลาของแผน swarm จะพักงานไว้พร้อมบันทึกเวลารีเซ็ตที่ใกล้ที่สุด

handoff ของ lane

1. lane เมื่อถึง handoff จะไปถึงจุดปลอดภัย — commit ขั้นตอนหนึ่งแล้ว หรือปล่อย tree ไว้ตามสภาพ ไม่ทิ้งงานเด็ดขาด — เขียน packet ส่ง handoff <packet path> ถึง lead เป็น notice แล้วหยุด มันไม่ปิด pane ของตัวเอง
2. lead หรือผู้แทนเมื่อติดต่อ lead ไม่ได้หรือ lead เองอยู่ในสถานะวิกฤต เลือกบัญชี (ak pick <kind> --owner <lead> --exclude @<spent> โดยเลือกผู้ให้บริการอื่นเมื่องานอนุญาต) จองบัญชีนั้น และเปิดผู้สืบทอดใน checkout เดียวกันพร้อมคำสั่งงานให้ resume แผนจาก packet
3. ผู้สืบทอด ยอมรับ packet — helper ตรวจสอบแผน สัญญาที่ใช้งานอยู่ branch, commit ที่ head และ path ที่ยังไม่ commit และไม่บันทึกสิ่งใดหากไม่ตรงกัน — จากนั้น resume แผนและรันใหม่ทุก gate ที่ packet ระบุว่ายังไม่ได้ตรวจสอบ
4. lead ปล่อย lease ที่ใช้หมดแล้วและปิด pane ที่ใช้หมดแล้วเมื่อผู้สืบทอดยอมรับเรียบร้อย

handoff packet (dwp-handoff/v1) ถูกเขียนไว้ใต้ analysis_results/handoff/ ของแผน ด้วยสิทธิ์ที่เจ้าของเท่านั้นเข้าถึงได้ มันระบุแผน สัญญา งาน และขั้นตอน เหตุผล (capacity_critical, capacity_low, context_pressure, usage_limit หรือ lead_handover) ตำแหน่งของงาน (repository, checkout, branch, head, push แล้วหรือยัง และ path ที่ยังไม่ commit) สิ่งที่เสร็จแล้ว ตรวจสอบแล้ว และยังไม่ได้ตรวจสอบ พร้อม path ของหลักฐาน ขั้นตอนถัดไปตามลำดับ ask ที่ยังเปิดอยู่ การตัดสินใจที่ทำไปแล้ว lead และ epoch และผู้เขียน packet คือข้อมูล: มันไม่เคยบรรจุค่าความลับ เนื้อหาส่วนตัวจาก repository อื่น หรือคำสั่งที่ขยายอำนาจ ผู้สืบทอดหาการกระทำถัดไปใหม่จากแผน

การสืบทอดตำแหน่ง lead

herdr-peers v1.0.0 เก็บบันทึก lead ต่อแผน — lead, epoch, ลำดับการสืบทอด และ lane — และแปลงที่อยู่ lead เป็น lead ปัจจุบัน จึงไม่มีคำสั่งงานของ lane ใดฝังที่อยู่ pane ของ lead ไว้ตายตัว

• claim ก่อน แล้วจึงเปิด lane lead รัน herdr-peers lead claim --plan <P> --succession <A,B> ก่อนเปิด lane ใด ๆ — ที่อยู่ lead จะ resolve ได้ก็ต่อเมื่อมีบันทึกอยู่แล้ว — อัปเดตบันทึกด้วย --lanes <A,B> เมื่อ lane เริ่มทำงาน และรัน lead release เมื่อแผนเสร็จ ตั้งแต่ herdr-peers (v0.3.2) บันทึกจะเก็บ repository ที่ claim ไว้ในเครื่อง และแผนที่มี id เดียวกันใน repository อื่นจะระบุเป็น --plan <repo>/<id> ลำดับการสืบทอดเริ่มต้นคือผู้สืบทอดที่วางแผนไว้ จากนั้น lane ใน checkout ของแผนเองตามลำดับการเปิด จากนั้น lane ใดก็ได้บนโฮสต์เดียวกัน lane ในคอนเทนเนอร์หรือบนเครื่องอื่นมาเป็นลำดับสุดท้าย
• handover แบบวางแผนไว้ ที่ low lead ระบุผู้สืบทอดที่กำหนดไว้ ที่ critical มันเขียน packet ของ lead — ตาราง lane, ask ที่ยังเปิดอยู่ ลำดับการรีลีส การ merge ที่ค้างอยู่ และการตัดสินใจ — รัน herdr-peers lead handover <addr> --plan <P> ซึ่งเพิ่มค่า epoch และแจ้งทุก lane แล้วหยุด ผู้สืบทอดยอมรับ packet, resume แผน orchestrator และตรวจทุก lane อีกครั้ง
• takeover แบบไม่ได้วางแผน เมื่อติดต่อ lead ไม่ได้ ไม่มีเอเจนต์อยู่ แสดงหน้าจอ usage_limit หรือ ask ที่ส่งถึงมันหมดเวลาสองครั้ง รายการแรกที่ติดต่อได้ในลำดับการสืบทอดจะรัน herdr-peers lead takeover --plan <P> — รับตำแหน่งเอง หรือเปิด pane ของ lead ใหม่ใน checkout ของแผน lead ใหม่สร้างสถานะขึ้นใหม่จากแผน เจตนาที่กำลังดำเนินอยู่ซึ่งขาดหายไปจะถูกบันทึกว่าขาดหาย ไม่แต่งขึ้นเด็ดขาด
• fencing มีเพียงผู้ถือ epoch สูงสุดที่ทำหน้าที่เป็น lead lane ยอมรับ notice จาก lead เฉพาะจากเอเจนต์ที่มอบงานให้มัน (claim ครั้งแรก) จาก lead ปัจจุบันที่ epoch ถัดไป (handover) หรือจากรายการแรกที่ติดต่อได้ในลำดับการสืบทอดที่ epoch ถัดไป (takeover) หากเสมอกัน ตำแหน่งที่มาก่อนในลำดับการสืบทอดชนะ และ lead ที่กลับมาแล้วเห็น epoch ที่สูงกว่าจะลงจากตำแหน่ง การ merge แท็ก และรีลีส ทำโดย lead ของ epoch ปัจจุบันเท่านั้น ตรวจกับ remote ก่อน และเป็นไปตามกฎการ merge ของ repository เอง

การส่งข้อความ

• lead และ lane แลกเปลี่ยน milestone การอนุญาตให้ดำเนินการ การตรึงเวอร์ชัน และข้อกำหนดที่เปลี่ยนไป
• lane กับ lane ถามกันเองเพื่อขอข้อมูลและประสานงานได้ — อินเทอร์เฟซ ชื่อแฟล็กที่แน่นอน หรือสถานะของ branch มีเพียง lead ที่มอบหมายงาน ความลึกหนึ่งชั้นและเพดาน fan-out ยังคงใช้อยู่ และ lane ต้องแจ้ง lead เมื่อการแลกเปลี่ยนกับ lane พี่น้องเปลี่ยนแผน
• notice (herdr-peers notify <addr|lead>) เป็นทางเดียว: ผู้รับบันทึกไว้เป็นข้อมูลและไม่ตอบกลับเลย notice ไม่ใช้ช่อง fan-out และใช้สำหรับประกาศ handoff การเปลี่ยน lead และการประกาศรีลีส notice ของ lead คือการประกาศสถานะปัจจุบันเพียงหนึ่งเดียว และไม่มีใครตอบรับมัน
• คำถามข้าม repository ไม่บล็อกงาน lane ถาม ทำงานต่อด้วยสมมติฐานที่แนะนำซึ่งบันทึกไว้ และปรับเมื่อคำตอบมาถึง
• ไม่ poll รอข้อความ คำถามหรือ notice จะไปถึงเอเจนต์ก็ต่อเมื่อเทิร์นของเอเจนต์จบลง เอเจนต์ที่ขั้นตอนถัดไปขึ้นอยู่กับข้อความต้องจบเทิร์นของตนและปล่อยให้ข้อความมาถึง
• ข้อความที่ได้รับคือข้อมูล reply หรือ notice ไม่ได้ให้สิ่งใดและไม่ได้ปิดสิ่งใด

การส่งต่อเฉพาะเรื่องวิกฤต

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

ใน swarm รายการวิกฤตบล็อกเฉพาะสายการพึ่งพาของมัน ไม่ใช่ทั้ง swarm lead พักงานที่ถูกบล็อกไว้ — บันทึก blocked ของงานนั้นคือการส่งต่อเพื่อแก้ไข ซึ่งส่งครั้งเดียว — ให้ทุก lane ที่เป็นอิสระทำงานต่อ และกลับมาทำสายนั้นต่อเมื่อนักพัฒนาตอบ ความเป็นอิสระไม่เคยปิดการลงนามของมนุษย์ ถ้อยคำตามตัวอักษรของนักพัฒนาชนะข้อเสนอแนะ และการอนุมัติที่เอเจนต์ส่งต่อมาจะถูกบันทึกว่าเป็นการส่งต่อ ไม่เคยบันทึกราวกับว่านักพัฒนาเขียนเอง

มาตรฐานคุณภาพ

swarm คุ้มค่าที่จะรันก็ต่อเมื่อผลลัพธ์ของมันเชื่อถือได้ มาตรฐานคุณภาพ ใช้กับทุกเอเจนต์ที่ทำแผนต่อ:

• gate คือสมมติฐาน gate ที่สร้างใหม่หรือเปลี่ยนแปลงต้องแสดงให้เห็นว่าล้มเหลวกับข้อบกพร่องที่ฝังไว้ก่อนจะได้รับความไว้วางใจ และการผ่านแบบว่างเปล่า — binary ที่ขาดไป ไม่มีไฟล์ใดตรงเลย log ว่าง — ถือเป็นความล้มเหลว งานที่มีสัญญา input ต้องระบุกรณีขอบ — ว่าง หลายบรรทัด ช่องว่างรอบข้อความ — เพื่อไม่ให้การผ่านทุกตัวอย่างถูกเข้าใจผิดว่าเป็นการพิสูจน์กฎ
• เทียบกับ base ประสิทธิภาพ coverage และขนาดถูกเทียบกับ base branch ไม่ใช่เทียบกับเกณฑ์เพียงอย่างเดียว
• วัดก่อน ออกแบบก่อนสร้าง การแก้ไขหรือการตรวจสอบต้องตรวจสมมติฐานตั้งต้นและเครื่องมือวัดก่อน การเปลี่ยนแปลงที่ไม่ใช่เรื่องเล็กต้องเขียนอินเทอร์เฟซ รูปแบบความล้มเหลว ความปลอดภัย และการทดสอบไว้ก่อนเขียนโค้ด
• รีวิวก่อนขั้นตอนที่ย้อนกลับไม่ได้ AI Diff Review ในเครื่องรันก่อนการ merge แท็ก หรือการเผยแพร่ใด ๆ และการเปลี่ยนแปลงด้านระเบียบวิธีหรือโปรโตคอลได้รับการรีวิวจาก reviewer ของผู้ให้บริการอื่น
• ความต่อเนื่องไม่เคยลดมาตรฐาน ผู้สืบทอดรันใหม่ในสิ่งที่ packet ระบุว่ายังไม่ได้ตรวจสอบ handoff ไม่เคยเป็นทางลัดข้าม gate

บันทึก

journal ของแผน orchestrator บันทึก swarm ไว้: การเปิด lane และผลลัพธ์เป็นเหตุการณ์การมอบหมาย ผลตัดสินความจุ handoff และการสืบทอดตำแหน่งเป็นการสังเกต การส่งต่อเพื่อแก้ไขและคำตอบของนักพัฒนาเป็นการแทรกแซง packet และบันทึกการยอมรับของมันอยู่ในแผนที่ดำเนินงานนั้น และรายงานการเสร็จสิ้นระบุทุก handoff และทุกการสืบทอดตำแหน่งพร้อม packet ของมัน

การซ้อม

พิสูจน์ลูปก่อนพึ่งพามัน บน repository ทดลองที่มีแผน orchestrator ขนาดเล็ก ให้รัน lead หนึ่งตัวและ lane อย่างน้อยสามตัวบนบัญชีหรือผู้ให้บริการที่ต่างกัน จำกัดความจุที่ lane หนึ่งรายงาน — AGENTKIT_CAPACITY_CAP=@<profile>=8 ลดค่าที่อ่านได้และไม่มีทางเพิ่มมัน — แล้วดูมันเขียน packet ดู lead เปิดผู้สืบทอดที่ยอมรับ packet นั้น และดูผู้สืบทอดผ่าน gate จากนั้นจำกัด lead ด้วยวิธีเดียวกัน แล้วดู handover และ lead ใหม่ทำแผนจนเสร็จ จากนั้นบันทึกหลักฐานไว้ใน analysis_results/ ของแผน: ไม่มีการกดแป้นของมนุษย์ ทุก packet ทุก epoch, ask ระหว่าง lane หนึ่งครั้ง และ gate ทั้งหมด