จะเกิดอะไรขึ้นเมื่อคุณวางแผนโปรเจกต์ใหญ่โดยไม่มีใครเป็นคนดูแล? สแต็กซอฟต์แวร์ส่วนใหญ่มักจะสมมติว่าต้องมี orchestrator เพียงหนึ่งเดียว โดยมีหนึ่งโปรเซสที่ถือครองสถานะ (state) จัดคิวงาน และแจกจ่ายงาน หากตัวประสานงานนี้รีสตาร์ท เวิร์กโฟลว์ทั้งหมดก็จะสะดุด แต่โปรเจกต์ใหม่นี้พลิกสมมติฐานนั้นโดยสิ้นเชิง มันแสดงให้เห็นว่าฝูง AI agents สามารถย่อยเป้าหมายอย่าง "วางแผนเที่ยวญี่ปุ่นสองสัปดาห์" ให้กลายเป็นแผนผังงาน (task tree) ที่สมบูรณ์ได้อย่างไร โดยที่ไม่มีโหนดใดโหนดหนึ่งถือครองแผนการทั้งหมดไว้ในเวลาใดเวลาหนึ่งเลย

ทำไมต้องสร้างระบบที่ไม่มีผู้นำ?

ตัววางแผนแบบรวมศูนย์ (Centralized planners) นั้นเข้าใจง่าย คุณส่งคำขอไปยังเซิร์ฟเวอร์ เซิร์ฟเวอร์จะแบ่งงาน และคนทำงานจะรายงานผลกลับมา ปัญหาก็คือเซิร์ฟเวอร์จะกลายเป็นคอขวดทั้งในเชิงการประมวลผล (cognitive) และทางกายภาพ (physical) เพราะมันเป็นเจ้าของความจริงเพียงหนึ่งเดียว

ในระบบแบบกระจายศูนย์ (distributed setup) ความจริงจะกลายเป็นภาพที่ใช้ร่วมกัน ซึ่งเครือข่ายจะบรรลุข้อสรุปร่วมกันผ่านการสื่อสารแบบ gossip การนำ Python มาปรับใช้ในครั้งนี้ได้เชื่อมโยงสองแนวคิดที่แตกต่างกันเข้าด้วยกัน อย่างแรกคือลูปการปรับปรุงแบบวนซ้ำ (iterative refinement loop): เอเจนต์ตัวหนึ่งเขียนข้อเสนอ อีกตัวให้คะแนน และตัวที่สามช่วยขัดเกลา อย่างที่สองคือเลเยอร์เครือข่ายแบบ peer-to-peer ที่สร้างบน libp2p ซึ่งช่วยให้เอเจนต์ค้นหากันและกันได้โดยอัตโนมัติโดยไม่ต้องมีทะเบียนกลางหรือ load balancer ผลลัพธ์ที่ได้คือคลัสเตอร์ที่สมาชิกสามารถปรากฏตัว เสนอแผน ลงคะแนน และดำเนินการได้ โดยไม่ต้องมีใครทำหน้าที่เป็นผู้อำนวยเพลง (orchestra conductor)

บทบาททั้งสี่

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

  • Decomposer (ตัวย่อยงาน): เอเจนต์นี้จะรับเป้าหมายระดับสูงสุดและเสนอการแบ่งออกเป็นเป้าหมายย่อย (subgoals) เนื่องจากระบบรัน decomposers หลายตัวพร้อมกัน คุณอาจได้รับแนวทางที่แตกต่างกันถึงสามแบบสำหรับทริปญี่ปุ่นทริปเดียวกัน แบบแรกอาจแบ่งตามภูมิศาสตร์ เช่น โตเกียว, เกียวโต, โอซาก้า แบบที่สองอาจแบ่งตามกิจกรรม เช่น การเดินทาง, ที่พัก, อาหาร, การท่องเที่ยว และแบบที่สามอาจแบ่งตามลำดับวัน โดยเครือข่ายจะพิจารณาทุกแนวทางที่เสนอมา

  • Scorer (ตัวให้คะแนน): เอเจนต์เหล่านี้ทำหน้าที่เหมือนคณะบรรณาธิการ พวกเขาจะตรวจสอบการแบ่งงานที่ถูกเสนอและให้คะแนน คะแนนจะสะท้อนว่าเป้าหมายย่อยนั้นมีความชัดเจนพอ ไม่ซ้อนทับกัน และครอบคลุมเนื้อหาทั้งหมดหรือไม่ ที่สำคัญกว่านั้นคือ scorer จะตัดสินว่าข้อเสนอนั้นดีพอที่จะยอมรับหรือไม่ หากไม่ได้รับการอนุมัติ การแบ่งงานนั้นก็จะค้างคาอยู่ในสภาวะไม่ชัดเจน

  • Executor (ตัวดำเนินการ): เมื่อแผนผังงานไปถึงโหนดปลายใบ (leaf nodes) ที่มีขนาดเล็กพอที่จะลงมือทำได้ executors จะแข่งกันเพื่อจองงานนั้น พวกเขาไม่รอการอนุญาตจากคิวกลาง แต่จะใช้โปรโตคอลการประทับเวลา (timestamp protocol) เพื่อตัดสินว่าใครจะได้สิทธิ์ในงานนั้น ผู้ชนะจะรันงานผ่านการเรียกใช้ local LLM และประกาศผลลัพธ์ออกไป

  • Observer (ผู้สังเกตการณ์): นี่คือผู้ที่คอยสังเกตการณ์อยู่ห่างๆ ที่ทุกเครือข่ายต้องการ มันจะคอยฟังการสื่อสารแบบ gossip อย่างเงียบๆ เพื่อสร้างแผนผังต้นไม้ขึ้นมาใหม่จากการพูดคุย และพิมพ์ภาพรวมที่อ่านง่ายออกมา เนื่องจากมันไม่เคยพูดเลย มันจึงพิสูจน์ประเด็นสำคัญที่ว่า: ใครก็ตามที่เข้าร่วมระบบในภายหลังสามารถเข้าใจแผนการทั้งหมดได้เพียงแค่จากการแอบฟัง

Gossip ในฐานะแหล่งที่มาของความจริง

เลเยอร์ libp2p จะจัดการเรื่องการค้นหาและการส่งข้อความ เอเจนต์จะหากันเจอผ่านฟีเจอร์ peer discovery ที่มีมาให้ในโปรโตคอล จากนั้นจึงประกาศข้อความไปยังหัวข้อ (topic) ที่ใช้ร่วมกัน โดยไม่มีฐานข้อมูลหลักหรือ Redis cache ที่เก็บแผนการที่เป็นมาตรฐานไว้

สมาชิกแต่ละคนจะเก็บสำเนาของแผนผังต้นไม้ไว้เป็นของตัวเองและอัปเดตตามข้อมูล gossip ที่ได้รับ เมื่อ decomposer ประกาศข้อเสนอ โหนดอื่นๆ ทุกตัวจะได้รับข้อเสนอนั้น ตรวจสอบรูปแบบ และเพิ่มกิ่งก้านนั้นลงในแผนผังต้นไม้ในเครื่องของตน เมื่อ scorers ลงคะแนน ผลคะแนนก็จะถูกส่งต่อออกไปในลักษณะเดียวกัน หากมี executors สองตัวประกาศอ้างสิทธิ์ในงานเดียวกันที่ขัดแย้งกัน โปรโตคอลการประทับเวลาจะแก้ไขการชนกันของข้อมูลนี้ โดยเครือข่ายจะยอมรับการอ้างสิทธิ์ที่เกิดขึ้นก่อนและตัดการอ้างสิทธิ์ที่มาทีหลังทิ้งไป

เมื่อเวลาผ่านไป แผนผังต้นไม้จะเติบโตลงมาจากเป้าหมายเดิมผ่านชั้นของเป้าหมายย่อยที่ได้รับการยอมรับ จนกระทั่งกลายเป็นงานขนาดเล็กที่จัดการได้ง่าย กระบวนการนี้คล้ายกับการที่ blockchain บรรลุฉันทามติ (consensus) เพียงแต่ข้อมูลที่ส่งคือแผนการเดินทางหรือข้อกำหนดซอฟต์แวร์ แทนที่จะเป็นบัญชีรายชื่อเหรียญ

การลงคะแนนและการแข่งขันเพื่อดำเนินการ

ระบอบประชาธิปไตยนั้นมีราคาที่ต้องจ่าย และระบบนี้ก็จ่ายด้วยความหน่วง (latency) การแบ่งงานจะชนะได้ก็ต่อเมื่อมี scorers จำนวนมากพอที่เห็นพ้องกัน เกณฑ์ดังกล่าวอาจเป็นเพียงเสียงข้างมากธรรมดาหรือโควตัม (quorum) ที่เข้มงวดกว่า ขึ้นอยู่กับการกำหนดค่าคลัสเตอร์ของคุณ เนื่องจาก decomposers ไม่หยุดที่จะเสนอแผน เครือข่ายจึงมักจะประเมินแผนผังที่แข่งขันกันหลายแบบพร้อมกัน ในที่สุด เมื่อแผนใดแผนหนึ่งได้รับคะแนนครบตามกำหนด เป้าหมายย่อยของแผนนั้นจะเปลี่ยนสถานะจากร่าง (draft) เป็นที่ยอมรับ (accepted)

Executors ช่วยเพิ่มอีกชั้นของการประสานงาน เนื่องจากงานต่างๆ เป็นสาธารณะบน gossip channel ทำให้ executor หลายตัวอาจพยายามคว้า leaf node ที่น่าสนใจตัวเดียวกัน โปรโตคอลการประทับเวลา (timestamp protocol) จะทำหน้าที่เป็นตัวตัดสินกรณีเสมอ (tiebreaker) โดยแต่ละการอ้างสิทธิ์จะมาพร้อมกับ monotonic timestamp และเครือข่ายจะยอมรับรายการที่เกิดขึ้นเร็วที่สุด ผู้ที่แพ้เพียงแค่ขยับไปทำงานถัดไปที่ว่างอยู่ แม้จะดูเรียบง่าย แต่วิธีนี้ช่วยหลีกเลี่ยงความจำเป็นในการใช้ centralized scheduler เพื่อล็อกแถวข้อมูลในฐานข้อมูล

ความยืดหยุ่นที่ถูกออกแบบมา

สถาปัตยกรรมนี้จะพิสูจน์ความคุ้มค่าเมื่อเกิดความผิดพลาด หาก decomposer ตัวหนึ่งหยุดทำงานหลังจากเสนอ subgoals ไปได้เพียงครึ่งเดียว decomposer ที่เหลืออยู่จะยังคงเสนอการแบ่งงาน (splits) ต่อไป แผนงานจะไม่หยุดชะงักเพื่อรอการเกิดใหม่ (respawn) หาก scorer หลุดออกจากเครือข่าย ผู้ลงคะแนน (voters) ที่เหลือก็ยังสามารถบรรลุ quorum ได้ ตราบใดที่คุณกำหนดขนาดของคลัสเตอร์ไว้อย่างเหมาะสม

ข้อดีที่แท้จริงคือการเข้าร่วมภายหลัง (late joins) เอเจนต์ (agent) ตัวใหม่ที่เริ่มทำงาน (boot up) ในช่วงกลางของกระบวนการ ไม่จำเป็นต้องใช้ snapshot หรือ