وقتی یک پروژه بزرگ را بدون هیچ مسئول یا رهبری برنامه‌ریزی می‌کنید، چه اتفاقی می‌افتد؟ اکثر پشته‌های نرم‌افزاری (software stacks) یک هماهنگ‌کننده (orchestrator) واحد را فرض می‌کنند. یک فرآیند، وضعیت (state) را نگه می‌دارد، کارها را در صف قرار می‌دهد و وظایف را توزیع می‌کند. اگر آن هماهنگ‌کننده دوباره راه‌اندازی شود، کل جریان کاری دچار اختلال می‌شود. یک پروژه جدید این فرض را کاملاً دگرگون می‌کند. این پروژه نشان می‌دهد که چگونه دسته‌ای از عامل‌های هوش مصنوعی (AI agents) می‌توانند هدفی مانند «برنامه‌ریزی یک سفر دو هفته‌ای به ژاپن» را به یک درخت کامل از وظایف تجزیه کنند، بدون اینکه در هیچ لحظه‌ای، یک گره (node) واحد کل برنامه را در اختیار داشته باشد.

چرا یک سیستم بدون رهبر بسازیم؟

استدلال درباره برنامه‌ریزان متمرکز آسان است. شما درخواستی را به یک سرور می‌فرستید، سرور کار را تقسیم می‌کند و کارگران گزارش را بازمی‌گردانند. مشکل اینجاست که سرور به یک گلوگاه (bottleneck) شناختی و فیزیکی تبدیل می‌شود؛ چرا که حقیقت تنها در اختیار اوست.

در یک ساختار توزیع‌شده، حقیقت به تصویری مشترک تبدیل می‌شود که شبکه از طریق پروتکل شایعه‌پردازی (gossip) بر سر آن به توافق می‌رسد. این پیاده‌سازی خاص در Python، دو مفهوم متمایز را به هم متصل می‌کند. اولی یک حلقه اصلاح تکرارشونده است: یک عامل پیشنهادی را می‌نویسد، دیگری به آن امتیاز می‌دهد و سومی آن را صیقل می‌دهد. دومی یک لایه شبکه همتا-به-همتا (peer-to-peer) مبتنی بر libp2p است که به عامل‌ها اجازه می‌دهد بدون نیاز به یک دفتر ثبت (registry) یا متعادل‌کننده بار (load balancer)، به‌طور خودکار یکدیگر را پیدا کنند. نتیجه، خوشه‌ای است که در آن همتاها ظاهر می‌شوند، پیشنهاد می‌دهند، رای می‌دهند و اجرا می‌کنند، بدون اینکه کسی نقش رهبر ارکستر را ایفا کند.

چهار نقش اصلی

سیستم به هر شرکت‌کننده یکی از چهار شخصیت را اختصاص می‌دهد. نیازی به چهار ماشین فیزیکی نیست؛ آن‌ها می‌توانند در یک لپ‌تاپ در کنار هم باشند یا در یک شبکه خانگی پخش شوند. نقش‌ها عبارتند از:

  • تجزیه‌کننده (Decomposer). این عامل هدف سطح بالا را دریافت کرده و پیشنهاد تقسیم آن به زیرهدف‌ها را می‌دهد. از آنجایی که سیستم چندین تجزیه‌کننده را به‌صورت موازی اجرا می‌کند، ممکن است برای یک سفر مشابه به ژاپن، سه دستورالعمل متفاوت دریافت کنید. یکی می‌تواند سفر را بر اساس جغرافیا تقسیم کند: توکیو، کیوتو، اوساکا. دیگری ممکن است بر اساس فعالیت تقسیم کند: حمل‌ونقل، اقامت، غذا و گشت‌وگذار. سومی می‌تواند بر اساس روزبندی انجام شود. شبکه همه آن‌ها را بررسی می‌کند.

  • امتیازدهنده (Scorer). این عامل‌ها مانند هیئت تحریریه عمل می‌کنند. آن‌ها تقسیم‌بندی پیشنهادی را بررسی کرده و به آن امتیاز می‌دهند. امتیاز نشان می‌دهد که آیا زیرهدف‌ها به اندازه کافی ملموس، بدون هم‌پوشانی و از نظر مجموع کامل هستند یا خیر. مهم‌تر از آن، امتیازدهنده تصمیم می‌گیرد که آیا یک پیشنهاد برای پذیرش مناسب است یا خیر. بدون تایید او، تقسیم‌بندی در حالت تعلیق باقی می‌ماند.

  • اجراکننده (Executor). زمانی که درخت به گره‌های برگ (leaf nodes) به اندازه کافی کوچک برای اجرا رسید، اجراکننده‌ها برای تصاحب آن‌ها با هم رقابت می‌کنند. آن‌ها منتظر اجازه از یک صف مرکزی نمی‌مانند؛ در عوض، از یک پروتکل برچسب زمانی (timestamp protocol) استفاده می‌کنند تا مشخص شود چه کسی حق انجام یک وظیفه را دارد. برنده، کار را از طریق یک فراخوانی LLM محلی انجام داده و نتیجه را منتشر می‌کند.

  • ناظر (Observer). این همان عضو گوشه‌گیر است که هر شبکه‌ای به آن نیاز دارد. او بی‌صدا به شایعه‌ها گوش می‌دهد، درخت برنامه را از میان گفتگوها بازسازی می‌کند و یک نمای کلی (snapshot) خوانا چاپ می‌کند. از آنجایی که او هرگز صحبت نمی‌کند، نکته مهمی را ثابت می‌کند: هر کسی که دیرتر به شبکه ملحق شود، می‌تواند کل برنامه را فقط با شنیدن گفتگوها متوجه شود.

پروتکل شایعه‌پردازی (Gossip) به عنوان منبع حقیقت

لایه libp2p وظیفه کشف و پیام‌رسانی را بر عهده دارد. عامل‌ها از طریق قابلیت کشف همتا (peer discovery) داخلی پروتکل، یکدیگر را پیدا کرده و سپس پیام‌ها را در یک موضوع (topic) مشترک منتشر می‌کنند. هیچ پایگاه داده مرجعی یا حافظه پنهان Redis که برنامه اصلی را نگه دارد، وجود ندارد.

هر همتا نسخه خودش از درخت برنامه را نگه می‌دارد و آن را بر اساس شایعه‌هایی که می‌شنود به‌روز می‌کند. وقتی یک تجزیه‌کننده پیشنهادی را منتشر می‌کند، تمام گره‌های دیگر آن را دریافت کرده، قالب آن را اعتبارسنجی می‌کنند و آن شاخه را به درخت محلی خود اضافه می‌کنند. وقتی امتیازدهنده‌ها رای می‌دهند، شمارش آرا نیز به همین ترتیب منتشر می‌شود. اگر دو اجراکننده ادعاهای متناقضی برای یک وظیفه یکسان داشته باشند، پروتکل برچسب زمانی برخورد را حل می‌کند. شبکه بر سر ادعای زودتر توافق کرده و ادعای دیرتر را نادیده می‌گیرد.

با گذشت زمان، درخت از هدف اصلی و از طریق لایه‌های زیرهدف‌های پذیرفته‌شده به سمت پایین رشد می‌کند تا به وظایف بسیار کوچک و قابل اجرا برسد. این فرآیند شبیه به رسیدن یک بلاک‌چین به اجماع (consensus) است، با این تفاوت که محتوای آن به جای دفتر کل سکه‌ها، یک برنامه سفر یا مشخصات نرم‌افزار است.

رای‌گیری و رقابت برای اجرا

دموکراسی هزینه‌بر است و این سیستم این هزینه را با تأخیر (latency) پرداخت می‌کند. یک تقسیم‌بندی تنها زمانی پیروز می‌شود که تعداد کافی از امتیازدهنده‌ها با آن موافق باشند. بسته به نحوه پیکربندی خوشه، این آستانه می‌تواند یک اکثریت ساده یا یک حد نصاب (quorum) سخت‌گیرانه‌تر باشد. تجزیه‌کننده‌ها به پیشنهاد دادن متوقف نمی‌شوند، بنابراین شبکه اغلب چندین درخت رقیب را به‌طور همزمان ارزیابی می‌کند. در نهایت، یکی از آن‌ها به تعداد آرای لازم می‌رسد و زیرهدف‌هایش از مرحله پیش‌نویس به مرحله پذیرفته‌شده ارتقا می‌یابند.

Executors add another layer of coordination. Because tasks are public on the gossip channel, multiple executors might try to grab the same attractive leaf node. The timestamp protocol acts as a tiebreaker. Each claim carries a monotonic timestamp, and the network honors the earliest one. The loser simply moves on to the next available task. This is crude, but it avoids the need for a centralized scheduler locking rows in a database.

Resilience by Design

The architecture earns its keep when things break. If a decomposer crashes after proposing half the subgoals, the surviving decomposers continue offering splits. The plan does not stall waiting for a respawn. If a scorer drops off the network, the remaining voters can still reach quorum as long as you sized the cluster appropriately.

The real payoff is late joins. A new agent that boots up halfway through does not need a snapshot or a