الگوهای طراحی عاملی: کتابی که باعث شد در مورد «عامل (Agent) دقیقاً چیست؟» بازنگری کنم

نویسنده: Yanhua

آنتونیو گولی، مدیر مهندسی در گوگل، کتابی ۴۵۳ صفحه‌ای نوشته است که توسعه عوامل هوش مصنوعی را به ۲۱ الگوی طراحی تقسیم می‌کند.

اما این یک نقد کتاب نیست. انگیزه من برای خواندن این کتاب بسیار خاص است: من درباره مهندسی مهار (Harness Engineering) نوشته‌ام، تجربیاتم با Clawdbot را به اشتراک گذاشته‌ام و درباره هفت نقطه عطف «عوامل هوش مصنوعی جادو نیستند» که از سوزاندن توکن‌ها به سمت کاربردی شدن واقعی می‌روند، بحث کرده‌ام. پس از هر نوشته، با سوالی مواجه می‌شدم که کاملاً به آن فکر نکرده بودم: آیا منطق زیربنایی قابل استفاده مجددی پشت این چیزها وجود دارد؟

این کتاب پاسخ را به من داد و عمیق‌تر از آن چیزی بود که انتظار داشتم.

شاید اصلاً در حال نوشتن یک عامل (Agent) نباشید

سخت‌گیرانه‌ترین قضاوت کتاب در مقدمه پنهان شده است.

بیشتر «هوش مصنوعی» که مردم استفاده می‌کنند فقط سطح ۰ است: مدل زبانی خام، بدون ابزار، بدون حافظه و بدون کنش. اگر از آن بپرسید بهترین فیلم اسکار ۲۰۲۵ چیست، حدس می‌زند. کتاب به صراحت بیان می‌کند: سطح ۰ یک عامل نیست.

صعود به سطوح بالاتر، جایی است که عوامل واقعی حضور دارند:

• سطح ۱: کاربر ابزار

  عامل شروع به استفاده از ابزارها می‌کند: جستجو، APIها، پایگاه‌های داده. اما موضوع فقط «توانایی فراخوانی رابط‌ها» نیست؛ بلکه باید تشخیص دهد چه زمانی فراخوانی کند، چه چیزی را فراخوانی کند و چگونه از نتایج استفاده کند. کتاب مثال بسیار خاصی می‌زند: وقتی کاربر می‌پرسد «اخیراً چه سریال‌های جدیدی آمده است؟»، عامل متوجه می‌شود که این اطلاعات در داده‌های آموزشی نیست و به‌طور پیش‌دستانه ابزار جستجو را برای یافتن آن فراخوانی کرده و سپس نتیجه را ترکیب می‌کند. گام کلیدی «تشخیص خودکار» است. این‌طور نیست که انسان به او بگوید «برو جستجو کن»، بلکه او خودش تشخیص می‌دهد که نیاز به جستجو دارد. این توانایی قضاوت، آستانه ورود به سطح ۱ است.

• سطح ۲: متفکر استراتژیک

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

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

  در این سطح، عامل همچنین می‌تواند خودبازتابی (Self-reflection) داشته باشد. پس از تکمیل یک کار، عملکرد خود را مرور کرده، مشکلات را شناسایی کرده و به‌طور مستقل اصلاحات انجام می‌دهد. در ادامه بیشتر توضیح خواهم داد.

• سطح ۳: همکاری چندعاملی

  موضع کتاب روشن است: فکر ایجاد یک ابرعامل همه‌کاره را کنار بگذارید. رویکرد واقعاً قابل اعتماد، ساختن یک تیم است؛ مانند عامل مدیر پروژه + عامل پژوهشگر + عامل طراح + عامل کپی‌رایتر. مثال کتاب، عرضه یک محصول جدید است: یک «عامل مدیر پروژه» همه چیز را هماهنگ کرده و وظایف را به «عامل تحقیقات بازار»، «عامل طراحی محصول» و «عامل بازاریابی» محول می‌کند. کلید کار، ارتباطات است: چگونه عوامل داده‌ها را منتقل کنند، وضعیت‌ها را همگام‌سازی کنند و تعارضات را مدیریت کنند. این فصل شش نوع توپولوژی ارتباطی را از ساده‌ترین تک‌عامل تا منعطف‌ترین ترکیب سفارشی نشان می‌دهد و توضیح می‌دهد هر کدام برای چه سناریوهایی مناسب هستند.

پس از خواندن این چهار سطح، ناگهان فهمیدم چرا بسیاری می‌گویند «عامل من کاربردی نیست.» مشکل از مدل نیست؛ مشکل این است که شما با آن مثل یک چت‌بات رفتار می‌کنید و شاید حتی به سطح ۱ هم نرسیده باشد.

مهندسی زمینه: دست‌کم‌گرفته‌شده‌ترین مفهوم در کتاب

من مقاله‌ای درباره مهندسی مهار نوشتم و بحث کردم که چگونه طراحی مسیر مهم‌تر از اسب بخار موتور است. پس از خواندن این کتاب، متوجه شدم که مهندسی زمینه، نگاشت مهندسی مهار در سطح پرامپت است.

مهندسی پرامپت سنتی فقط به «چگونه پرسیدن» اهمیت می‌دهد. مهندسی زمینه در این کتاب به «چه زمینه‌ای قبل از پرسیدن در مقابل عامل قرار دارد» می‌پردازد. این شامل چهار لایه اطلاعات است:

1. لایه اول، پرامپت سیستم. تعریف می‌کند که عامل کیست، از چه لحنی استفاده کند و چه مرزهایی تعیین کند. اکثر مردم فقط همین لایه را می‌نویسند.

2. لایه دوم، داده‌های خارجی. اسناد بازیابی شده توسط RAG، مقادیر بازگشتی از فراخوانی ابزارها، داده‌های API بلادرنگ. اینجا جایی است که اکثر مردم گیر می‌کنند: می‌دانند باید داده تزریق کنند اما نمی‌دانند چگونه بدون غرق کردن مدل این کار را انجام دهند.

3. لایه سوم، داده‌های ضمنی. هویت کاربر، تاریخچه تعامل، وضعیت محیطی. چیزهایی که صراحتاً بیان نشده‌اند اما عامل باید بداند. برای مثال، اگر به عامل بگویید «کمک کن به جان ایمیل بزنم تا جلسه فردا را تایید کنم»، باید بداند جلسه فردا در تقویم شما چیست و رابطه شما با جان چگونه است.

4. لایه چهارم، حلقه بازخورد. پس از هر خروجی، عامل به‌طور خودکار کیفیت را ارزیابی کرده و استراتژی زمینه را برای دفعه بعد تنظیم می‌کند. کتاب از این به عنوان «بهینه‌سازی خودکار زمینه» یاد می‌کند و Vertex AI Prompt Optimizer گوگل یک پیاده‌سازی مهندسی از این ایده است.

وقتی این را خواندم، تجربه قبلی‌ام در «عوامل هوش مصنوعی جادو نیستند» را به یاد آوردم که گفته بودم «عامل شما به قوانین نیاز دارد، و قوانین زیاد.» با نگاه به گذشته، آن قوانین در واقع نسخه دستی مهندسی زمینه هستند که کتاب آن‌ها را نظام‌مند کرده است.

بازتاب: دو عامل واقعاً بهتر از یکی هستند

این کاربردی‌ترین الگوی کل کتاب برای من است.

هسته بازتاب ساده است: عامل پس از تکمیل کار، عملکرد خود را مرور کرده و اصلاحات انجام می‌دهد. اما روش پیاده‌سازی حیاتی است. کتاب به صراحت می‌گوید: تولیدکننده و منتقد باید از دو عامل متفاوت با پرامپت‌های سیستمی متفاوت استفاده کنند. یک شخصیت واحد که کار خودش را مرور می‌کند همیشه نقاط کور خواهد داشت. اگر همان مدل زبانی کد بنویسد و سپس کد خودش را مرور کند، به احتمال زیاد می‌گوید: «خیلی خوب است.»

کتاب یک مثال کد کامل ارائه می‌دهد.

• پرامپت تولیدکننده این است: «تو یک توسعه‌دهنده پایتون هستی، تابعی برای محاسبه فاکتوریل بنویس که موارد خاص و استثناها را مدیریت کند.»

• پرامپت منتقد این است: «تو یک مهندس ارشد سخت‌گیر هستی، کد را خط به خط مرور کن، باگ‌ها، سبک، موارد خاص از قلم افتاده و زمینه‌های بهبود را بررسی کن. اگر بی‌نقص است، خروجی CODE_IS_PERFECT بده؛ در غیر این صورت، تمام مشکلات را لیست کن.»

• سپس یک حلقه for وجود دارد: تولیدکننده کد می‌نویسد → منتقد مرور می‌کند → تولیدکننده بر اساس بازخورد تغییرات ایجاد می‌کند → منتقد دوباره مرور می‌کند → تا زمانی که منتقد بگوید CODE_IS_PERFECT یا حداکثر تعداد تکرار برسد.

به همین سادگی. اما کتاب یک مسئله هزینه را یادآوری می‌کند که به راحتی نادیده گرفته می‌شود: هر حلقه بازتاب یک فراخوانی جدید مدل زبانی است و هرچه تکرارها بیشتر شود، گران‌تر می‌شود. علاوه بر این، با گسترش تاریخچه گفتگو، پنجره زمینه با نسخه‌های قبلی و نقدها پر می‌شود و فضای استدلال قابل استفاده واقعی را کاهش می‌دهد. بنابراین، بهترین تمرین برای بازتاب این است: حداکثر تعداد تکرار معقول (کتاب از ۳ استفاده می‌کند) تعیین کنید و به محض رضایت منتقد متوقف شوید؛ به دنبال کمال نباشید.

کاربردها بسیار فراتر از نوشتن کد است. نوشتن مقاله، برنامه‌ریزی، خلاصه‌سازی اسناد، حل مسائل منطقی—همه می‌توانند از مدل تولیدکننده-منتقد استفاده کنند. کتاب هفت سناریوی کاربردی را لیست می‌کند که منطق اصلی همه آن‌ها یکی است: ابتدا تولید، سپس مرور و در نهایت اصلاح.

چندعاملی بودن همیشه با پیچیدگی بیشتر، بهتر نیست

چیزی که در فصل همکاری چندعاملی بیشتر از همه دوست داشتم، شش نمودار توپولوژی ارتباطی بود. بسیاری از مردم مستقیماً به سراغ پیچیدگی می‌روند، اما در اکثر سناریوها، سه نوع کافی است:

1. تک‌عامل (اجرای مستقل): وظایف می‌توانند به زیرمسئله‌های مستقل تقسیم شوند و هر عامل مسئول کار خود است. ساده و نگهداری آن آسان است.

2. شبکه همتا به همتا: عوامل مستقیماً با یکدیگر ارتباط برقرار می‌کنند، بدون گره کنترل مرکزی. غیرمتمرکز و مقاوم در برابر خطا؛ اگر یک عامل شکست بخورد، کل سیستم تحت تاثیر قرار نمی‌گیرد. با این حال، هزینه‌های هماهنگی بالاست و به راحتی می‌تواند آشفته شود.

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

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

تجربه من این است که بسیاری از مردم هنگام ساخت سیستم‌های چندعاملی، ۸۰ درصد وقت خود را صرف پروتکل‌های ارتباطی می‌کنند و فراموش می‌کنند سوال بنیادی‌تری بپرسند: آیا این کار واقعاً به چندین عامل نیاز دارد؟ کتاب به صراحت می‌گوید که یک تک‌عامل سطح ۲ با بازتاب اغلب کافی است. سطح ۳ برای سناریوهایی است که یک تک‌عامل واقعاً نمی‌تواند از پس آن برآید.

مدل سه‌لایه حافظه، حسی مبهم از آن داشتم اما نامی برایش نداشتم

فصل حافظه بیشترین ارتباط را با من برقرار کرد زیرا وقتی مقالات Obsidian + Claude را می‌نوشتم، دائماً در حال تامل در یک سوال بودم: حافظه عامل چگونه باید لایه‌بندی شود؟

کتاب پاسخ را ارائه می‌دهد:

1. نشست (لایه گفتگو): پنجره زمینه گفتگوی فعلی که کوتاه‌ترین حافظه است و با پایان گفتگو ناپدید می‌شود. مدل‌های با زمینه طولانی فقط این پنجره را بزرگ می‌کنند، اما اساساً هنوز موقتی است و هر استنتاج باید کل پنجره را پردازش کند که پرهزینه و کند است.

2. وضعیت (لایه وضعیت): داده‌های موقت در طول کار فعلی. برای مثال، «وظیفه فعلی چیست؟»، «چقدر پیشرفت کرده است؟»، «چه داده‌هایی در این میان تولید شده است؟». طولانی‌تر از نشست است اما با پایان کار پاک می‌شود؛ کتاب از مکانیسم وضعیت ADK گوگل به عنوان یک مثال کامل استفاده می‌کند.

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

در مقاله قبلی‌ام درباره Clawdbot، به «فایل‌های وضعیت» و «اسناد فضای کاری» اشاره کردم که در واقع تلاش‌های دستی من برای ایجاد لایه‌های وضعیت و حافظه بودند و کتاب این فرآیند را چارچوب‌بندی کرده است.

پنج فرض، که پنجمی پوچ‌ترین است

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

فرض پنجم مرا شوکه کرد: تحول چندعاملی.

شما فقط یک هدف اعلام می‌کنید، مثلاً «یک کسب‌وکار تجارت الکترونیک برای فروش قهوه ممتاز ایجاد کن.» سیستم به‌طور خودکار تصمیم می‌گیرد: ابتدا یک «عامل تحقیقات بازار» و یک «عامل برندینگ» ایجاد کند. پس از اجرای مقداری داده، تشخیص می‌دهد که عامل برندینگ دیگر مورد نیاز نیست و آن را به سه عامل جدید تقسیم می‌کند: «عامل طراحی لوگو»، «عامل ساخت وب‌سایت» و «عامل زنجیره تامین». اگر عامل ساخت وب‌سایت به یک گلوگاه تبدیل شود، سیستم به‌طور خودکار سه عامل موازی را برای کار بر روی صفحات مختلف به‌طور همزمان تکثیر می‌کند. در طول این فرآیند، سیستم به‌طور مداوم پرامپت هر عامل را بهینه‌سازی کرده و ساختار تیم را بازسازماندهی می‌کند.

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

این مرا به یاد AutoResearch کارپاتی می‌اندازد: یک program.md بنویسید، اهداف، معیارها و مرزها را تعریف کنید و «شروع» را بزنید. انسان‌ها خارج از حلقه هستند. اما این کتاب پا را فراتر می‌گذارد: حتی نحوه تشکیل و بازسازماندهی تیم عامل به عهده سیستم است. انسان‌ها فقط اعلام می‌کنند «چه می‌خواهند.»

سه اقدامی که می‌توانید بلافاصله انجام دهید

پس از اتمام این کتاب، سه اقدام فوری دارم که می‌توانم پیاده‌سازی کنم:

• اول، یک منتقد به عامل فعلی خود اضافه کنید. چه از Claude Code، CrewAI یا چارچوبی که خودتان ساخته‌اید استفاده می‌کنید، یک گام در پایان گردش کار فعلی خود اضافه کنید: از یک عامل دیگر (با پرامپت سیستمی متفاوت) بخواهید خروجی گام قبلی را مرور کند. تولید کد به علاوه بررسی کد، نوشتن مقاله به علاوه راستی‌آزمایی، برنامه‌ریزی به علاوه ارزیابی امکان‌سنجی. این یک فراخوانی مدل زبانی بیشتر اضافه می‌کند، اما بهبود کیفیت اغلب دو برابر می‌شود. مدل تولیدکننده-منتقد در کتاب آماده استفاده است.

• دوم، شروع به انجام مهندسی زمینه کنید، نه فقط مهندسی پرامپت. به فایل‌های دستوری که برای عامل نوشته‌اید نگاه کنید. اگر همه آن‌ها قوانینی درباره «چگونه باید انجام دهی» هستند و فاقد زمینه درباره «با چه محیطی در حال حاضر روبرو هستی» هستند، آن‌ها را تکمیل کنید. به عامل بگویید در حال حاضر در چه پروژه‌ای است، چه تصمیماتی قبلاً گرفته شده و ترجیحات کاربر چیست. فصل مهندسی زمینه در کتاب و AGENTS.md شما دو بیان از یک چیز هستند.

• سوم، در استفاده از چندعاملی عجله نکنید. تک‌عامل خود را به سطح ۲ برسانید: با ابزارها، بازتاب و حافظه. کتاب مکرراً تاکید می‌کند که یک تک‌عامل سطح ۲ همراه با تولیدکننده-منتقد و مهندسی زمینه می‌تواند اکثریت قریب به اتفاق سناریوهای عملی را پوشش دهد. سطح ۳ برای وظایفی است که واقعاً به تقسیم کار بین‌حوزه‌ای، چندمرحله‌ای و موازی نیاز دارند. مشکل اکثر مردم این نیست که عامل کافی ندارند، بلکه این است که یک تک‌عامل را بهینه نکرده‌اند.

این کتاب ۴۵۳ صفحه است و در سال ۲۰۲۵ توسط Springer منتشر خواهد شد. مثال‌های کد شامل LangChain/LangGraph، ADK گوگل، CrewAI و OpenAI API است. پیش‌گفتار توسط معاون هوش مصنوعی گوگل کلود نوشته شده و توصیه‌ای از مدیر ارشد اطلاعات گلدمن ساکس دارد که به طرز غیرمنتظره‌ای خوب نوشته شده است.

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

کسی نقشه را برای شما کشیده است؛ تنها کاری که باقی مانده، قدم زدن در آن است.

آیا از عوامل هوش مصنوعی برای توسعه استفاده می‌کنید؟ عامل فعلی شما در چه سطحی است؟