یادداشتهایی از ساخت سیستمهای ایجنت
هارنسهای ارزیابی، الگوهای ارکستراسیون، طراحی حافظه و شکستهای پشت آنها — نوشتهشده در حالی که جزئیات هنوز تازه است.

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

زمینه مشترک یک مسئله سازگاری است، نه یک مسئله ذخیرهسازی
گرافهای دانش به سیستمهای چندعاملی حالت مشترک صریح میدهند، اما کار واقعی تصمیمگیری درباره این است که کدام عامل مجاز به نوشتن کدام یال است و نوشتنهای متعارض چگونه حلوفصل میشوند.

تبانی میان ایجنتها یک نقص پروتکلی است، نه یک نقص پرامپتی
وقتی ایجنتها هماهنگ میشوند تا یک قاعده مشترک را نقض کنند، شکست در رابطی است که به آنها اجازه میدهد بدون داور، وضعیت را مبادله کنند؛ پس باید در لایه پروتکل بسته شود.

ارکستراتور یک دیسپچر است: چرا ازدحامهای ایجنت روی صفبندی شکست میخورند، نه روی استدلال
بیشتر شکستهای چند-ایجنی که به استدلال مدل نسبت داده میشوند، شکستهای زمانبندی هستند. fan-out بیکران، نبود backpressure و نبود admission control یک ازدحام را به طوفان retry تبدیل میکند.

ارکستراسیون ایجنت به زمانبند نیاز دارد، نه ناظر
یک ناظر واحد، ازدحام را سریالیزه میکند و گلوگاه واقعی را پنهان میسازد: کنترل پذیرش، صفبندی و پیشدستی. با ایجنتها مثل پردازشها رفتار کنید تا حالتهای شکست قابل مشاهده شوند.

دستکاری میان ایجنتها یک مسئله پروتکلی است
وقتی یک ایجنت میتواند با یک ادعای تأییدنشده برنامه ایجنت دیگر را تغییر دهد، نقص در پروتکل است، نه در مدل. برچسبهای منشأ، تأیید مستقل و سقف بازادعا آن را مهار میکنند.

اقتصاد واحد یک اجرای agent: حسابداری هزینه برای سیستمهای چندمرحلهای
قیمتگذاری توکن پنهان میکند که هزینهٔ agent در واقع کجا میرود. هزینه به ازای هر وظیفهٔ موفق، که بر اساس نقش و tool call اندازهگیری میشود، همان عددی است که تیمها میتوانند بر اساس آن اقدام کنند.

الگوی رئیسدفتر: چه زمانی باید agentها را هماهنگ کرد و چه زمانی فقط باید یک اسکریپت نوشت
هماهنگسازی چند-agent تنها زمانی به صرفه است که زیرکارها به context متفاوت، ابزارهای متفاوت یا راستیآزمایی مستقل نیاز داشته باشند. در غیر این صورت، این کار یک فراخوانی تابع کندتر است.