Phase 16: Multi-Agent & Swarms

مقیاس تولید صف ها، نقاط بازرسی، دوام

مقیاس بندی سیستم های چند عامل به هزاران اجرا همزمان نیاز داردdurable execution صف های کار و نقاط بازرسی، بنابراین هر کارگر می تواند هر کار را پس از هر تصادف، به شرط اینکه مدیریت اجاره، اثرات جانبی بی فایده و تکرار تعیین کننده در محل باشد، بازرسی را پس از هر تصادف ادامه دهد. زمان اجرا LangGraph نمونه مرجع است: آن را می نویسد یک نقطه بازرسی پس از هر مرحله فوق العاده با کلید توسط thread_id(بعد از پیش فرض) ؛ کارگر تصادف می کند اجاره را آزاد کند و کارگر دیگر ادامه می دهد.MegaAgent(arXiv:2408.09955) یک صف تولید کننده- مصرف کننده را با سه حالت (Idle / Processing / Response) و هماهنگی دو لایه (تکنیک در داخل گروه + تکنیک در میان گروه) اجرا کرد. Fiber/asyncدر جریان LLM، رشته ها 99 درصد از زمان منتظر توکن ها هستند، فیبر ها به طور همکاری در I/O تولید می کنند.FastAPI + Postgres + nothing elseتا زمانی که بار ثابت کند که خلاف است معماری های ساده از انتظار می رود. این درس یک دفترچه چک پوند پایدار، یک صف کار در هر عامل با انتقال حالت، یک نمایش async vs thread را ایجاد می کند و قاعده عملی " شروع ساده " را ایجاد می کند.

Type: Learn + Build

Languages: Python (stdlib, asyncio, sqlite3), TypeScript

Prerequisites: Phase 16 · 09 (Parallel Swarm Networks), Phase 16 · 13 (Shared Memory)

Time: ~75 minutes

مشکل

یک نمونه ی سیستم چند عامل روی یک لپ تاپ با سه عامل در یک حلقه ی رویداد حافظه کار می کند.

  • بعضی اوقات ماموران ساعت ها کار می کنند (تحقیق طولانی، منتظر بودن انسان در چرخه).
  • کارکن ها کارشون رو خراب ميکنن، بازشوري حالت رو از دست ميده
  • بار ذروه 10 برابر متوسط است؛ شما نیاز به مقیاس افقی دارید.
  • کاربران به صورت هر عامل پرداخت می کنند؛ برای شارژ کردن به معنای یک بار نیاز دارید.

در حال حاضر، این دو گزینه در زیر زیر زیر زیر هستند.

  1. یک موتور جریان کار با نقاط بازرسی (زمان کاری، زمان اجرا LangGraph).
  2. یک خط خط پیام با یک فروشگاه دولتی (Postgres + SQS / RabbitMQ).
  3. چارچوب های مدل بازیگر (تولید کننده و مصرف کننده هر نماینده میگا آژانس)
  4. FastAPI + Postgres (دلیل بیدی) به دست رول شده است.

این درس یک نوع کوچک از هر یک از آنها را می سازد.

مفهوم

اجرا پایدار، الگوی

یک موتور اجرا پایدار حالت کامل برنامه را پس از هر "خطای" (سپر مرحله، به زبان لانگ گراف) حفظ می کند. در هنگام تصادف:

code
worker crashes mid-step
  -> lease timeout
  -> another worker picks up the thread_id
  -> resumes from last checkpoint
  -> no duplicate side effects

الزامات برای این کار:

  • Serializable state.تمام حالت مامور بايد دوام پيدا کنه.
  • Deterministic resume.با توجه به همان حالت و ورودی، عامل همان اقدامات را تولید می کند (یا برای تماس های LLM به یک Oracle تعیین کننده خارجی منتقل می شود).
  • Idempotent side effects.تماس های خارجی (دعوات ابزار، پرداخت ها) باید بی اختیار باشند یا از کلید تخفیف استفاده کنند.

LangGraph پس از هر مرحله فوق العاده یک نقطه چک می نویسد؛ Temporal پس از هر فعالیت می نویسد؛ Restate از ژورنال های منبع رویداد استفاده می کند. هر سه الگوی مشابه را اجرا می کنند.

زمان اجرا هر مرحله

زمان اجرا لانگ گراف نمونه کار است: هر عامل دارای یک thread_idدر ادامه، زمان اجرا از آخرین نقطه بازرسی، نه از نو باز می شود. ماموران می توانند interrupt()وقتی که واردات می شود، هر کارگر می تواند دوباره واردات کند.

این طرح تولید مرجع در آوریل 2026 است.

صف هر مامور ميگا اژانس

arXiv:2408.09955 یک آزمایش مقیاس را توصیف می کند: هزاران عامل همزمان در یک خوشه. معماری:

code
agent i:
  state ∈ {Idle, Processing, Response}
  in_queue   <- messages addressed to agent i
  out_queue  -> replies + side effects

coordinators:
  intra-group chat  (agents in the same group)
  inter-group admin chat  (high-level routing)

هماهنگی دو لایه اجازه می دهد که مکالمه بین گروه به شدت اتفاق بیفتد در حالی که بین گروه ها کمیاب باقی می ماند - الگوی مورد استفاده برای حفظ خطی هزینه در هزاران عامل.

هم وقت سازی در مقابل رشته در هر شغل

تماس های LLM با I / O بسته هستند. یک رشته منتظر توکن بعدی 99% از زمان بیکار است. هر رشته هزینه ~ 1MB RAM است؛ در 10,000 تماس همزمان، که فقط برای استیک ها 10GB است.

فیبر (Python asyncio، برو روتین ها ، زنگtokio) در I / O همکاری می کنند. همان 10،000 تماس به راحتی در فرآیند قرار می گیرد. در مقیاس LLM-agent، async یک بهینه سازی نیست آن معماری است.

استثنا: پردازش بعد از پردازش با CPU (بند، ترفند های توکن) هنوز نیاز به رشته ها یا فرآیندهای دارد. لایه I / O خود را از لایه CPU خود جدا کنید.

نقطه مقابل بدي

"سوالینگ آژانتک نرم افزار" (اشپریت بیدی، 2026) استدلال می کند که اکثر تیم ها قبل از اندازه گیری بار بیش از حد مهندسی می شوند.

  • فاستاپي + پس از درجه
  • هر اجرا اجنتی یک ردیف است؛ حالت به روز شده در محل با مواقعی خوش بینانه.
  • شغل های پس زمینه از طریق pg_notifyیا یک کارگر ساده سلاری.
  • دوباره در کد درخواست تلاش کنید

برای بار کمتر از 100 عامل همزمان در وظایف قابل مدیریت، این اغلب تنها چیزی است که شما نیاز دارید. هنگامی که آن را اندازه گیری شکست.

قانون: زمانی که به یک مشکل مشخص رسید که معماری های ساده نمی توانند آن را حل کنند، چارچوب های اجرای پایدار را اتخاذ کنید. پذیرش زودرس زمان را در مراسم هایی می سوزاند که نتیجه نمی دهند.

دقیقاً یک بار

برای اجرای اجنتی با هزینه، شما نیاز به "حداقل یک بار موثر" (حداقل یک بار تحویل + مصرف کننده بی اختیار) دارید.

  • Dedup key per run.اينو در هر تماس اثر جانبي شامل کن
  • Outbox pattern.اثرات جانبی ابتدا به یک جدول نوشته می شود، سپس یک فرآیند جداگانه آنها را اجرا می کند. هر دو مرحله بی قدرت هستند.
  • Compensating transactions.وقتی یک اثر جانبی موفق شود اما نوشته ردیابیش شکست خورده باشد، تعویض را برنامه ریزی کنید.

این الگوهای مهندسی پایگاه داده هستند، نه LLM خاص. مالیات LLM فقط این است که تماس های LLM کند هستند؛ همه چیز دیگر سیستم های توزیع شده استاندارد است.

استفاده از کمان کمان

سیستم تحقیقاتی چند عامل Anthropic از "توسعه های قوس قزح" استفاده می کند: چندین نسخه از زمان اجرا عامل به طور همزمان اجرا می شود بنابراین عوامل طولانی مدت در هر انتشار کد مجبور نیستند کشته شوند. نسخه های جدید کاناری در یک قطعه ترافیک؛ نسخه های قدیمی را وقتی که عوامل آنها تمام می شوند بازنشسته می کنند.

این استاندارد برای سیستم های طولانی مدت است؛ تطبیق 2026 این است که عوامل می توانند ساعت ها زندگی کنند، بنابراین چرخه های نشریات باید متناسب باشند.

فهرست چک تولید کنونی

  • حالت پایدار (چیک پوائنت ها، عکس های فوری یا آواو باکس + نوار قابل بازی).
  • عوارض جانبي بي اثر
  • لایه I/O Async برای تماس های LLM
  • حداقل یک بار تحویل با دادوپ.
  • استفاده از قوس قزح/کاندار برای بار کاری پرحال
  • قابل مشاهده بودن: ردیابی هر عامل، حسابرسی فوق العاده، شمارش مجدد.

آن را بسازید

code/main.pyابزار:

  • CheckpointStore ثبت نقطه بازرسی با پشتیبانی از SQLite با کلید های Thread-ID. هر مرحله فوق العاده یک ردیف را اضافه می کند.
  • run_with_checkpoint(agent, thread_id) یک تصادف در نیمه کار را شبیه سازی می کند؛ یک کارگر دوم از آخرین نقطه بازرسی شروع می کند.
  • AgentQueue هر عامل ماشین حالت بیکار / پردازش / پاسخ با یک صف کار کوچک.
  • demo_async_vs_threads() 500 "دعوات LLM" همزمان را از طریق asyncio و از طریق رشته ها اجرا می کند؛ گزارشات ساعت دیواری و حافظه اوج (تقریباً).

راه رفتن:

code
python3 code/main.py
npx tsx code/main.ts

خروجی انتظار می رود: بازخورد نقطه بازرسی پس از تصادف شبیه سازی موفق می شود؛ نسخه async 500 تماس همزمان را در < 1s اداره می کند؛ نسخه موضوع چند ثانیه طول می کشد و از هر واحد همزمان از حافظه به مراتب بیشتر استفاده می کند.

ازش استفاده کن

outputs/skill-scaling-advisor.mdدر مورد انتخاب اجرای پایدار توصیه می کند: FastAPI + Postgres، زمان اجرا LangGraph، Temporal یا سفارشی. با توجه به بار، نیاز به حفظ حالت و فرکانس انتشار.

-باده

سخت کردن تولید کنونیک:

  • Start simple (Bedi's rule).FastAPI + Postgres تا زمانی که اندازه گیریش شکست خورده باشد.
  • Instrument everything before optimizing.هر دوچرخه طولاني، هر مرحله زمان، دوباره امتحان کردن، دسته بندی شکست
  • Outbox pattern for side effects.مخصوصا پرداخت ها و تماس های API خارجی
  • Rainbow deploys.هرگز در طی پرواز، اجنتی رو که در طی عملیات ها میره نکش
  • Adopt durable-execution engines (Temporal / LangGraph / Restate) whenشما مشکلات خاصی را پیدا می کنید: منتظرانی یک ساعت انسان در حلق، هماهنگی بین مناطق، سیاست های پیچیده بازتجربه/عوض.
  • Async for the I/O layer.فقط برای پردازش بعد از پردازش با پردازنده.

تمرینات

  1. فرار کنcode/main.py. کار ادامه ی پوائنتی را تایید کنید. تفاوت هم زمانی در میان رشته ها را اندازه گیری کنید.
  2. اجرای یکoutboxجدول: هر تماس ابزار ابتدا به جعبه خارج می نویسد، سپس یک برنامه / کار جداگانه اجرا می شود. با اجرا کردن تماس ابزار دو بار، بی اختیار بودن را تأیید کنید.
  3. شبیه سازی یکrainbow deploy: دو نسخه همزمان در زمان اجرا؛ نصف threads جدید را به هر یک هدایت کنید؛ تایید کنید که threads در پرواز در نسخه قدیمی قطع نشده است.
  4. سند زمان اجرا LangGraph را بخوانید (در زیر لینک شده). مشخص کنید که کدام ویژگی های زمان اجرا طولانی ترین زمان را برای تکرار در یک نسخه FastAPI + Postgres دستی انجام می دهد. آیا این یک دلیل برای اتخاذ است، یا می توانید آن را تعویق کنید؟
  5. میگاآجنت (arXiv:2408.09955) بخش 3 را بخوانید. هماهنگی دو لایه (در داخل گروه + میان گروه admin chat) صریح است. طرح کنید که چگونه می توانید این را به یک خط خط خط پیام با دو خانواده خط خط خط نقشه بزنید.

اصطلاحات کلیدی

TermWhat people sayWhat it actually means
Durable execution"Persist the program state"Engine writes state after each super-step; crash recovery is deterministic.
Super-step"Transactional boundary"Unit of work between checkpoints. LangGraph term.
thread_id"Agent run identifier"Key that binds checkpoints and resume logic.
Idempotency"Safe to retry"Repeating a side effect produces the same result as one attempt.
Outbox pattern"Decouple side effects"Write intent to a table; a separate executor performs and marks done.
At-least-once delivery"Possible duplicates"Message queue semantics; dedup key makes consumer effective-once.
Rainbow deploy"Overlapping versions"Multiple runtime versions concurrent during long-running workloads.
Async fiber"Cooperative yielding"User-mode concurrency; cheap compared to threads for I/O-bound loads.
Checkpoint"State snapshot"Serialized state at a super-step boundary; key for resume.

خواندن بیشتر

This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.

Browse the complete course catalog or open this lesson on GitHub.