وقتی Anthropic در اواخر سال ۲۰۲۴ راهنمای Building Effective Agents را منتشر کرد، کاری انجام داد که در این صنعت نادر است: به مهندسان یک واژگان مشترک داد. به جای یک مانیفست دیگر درباره هوش مصنوعی عمومی (AGI)، این راهنما شش الگوی روشن برای ساختاردهی به سیستمهای LLM ارائه کرد. یک سال و نیم بعد، در سال ۲۰۲۶، چشمانداز به طرز رادیکالی متفاوت به نظر میرسد. Model Context Protocol به یک استاندارد جهانی تبدیل شده است. Claude قابلیتهای جدیدی به دست آورده است. اکثر سازمانها اکنون حداقل یک عامل (agent) در مرحله تولید دارند. با این پیشزمینه، منصفانه است که بپرسیم آیا آن شش الگو هنوز اهمیت دارند یا اینکه باید در کنار وزنهای مدل سال گذشته، در آرشیو خاک بخورند.
من برای یافتن پاسخ، تمام شش الگو را در یک مخزن جانبی (side repository) در برابر یک مدل محلی آزمایش کردم. پاسخ مثبت است. آنها هنوز پابرجا هستند. اما نه به این دلیل که قوانین تغییرناپذیری هستند؛ بلکه به این دلیل که هجده ماه تجربه عملی در مرحله تولید، منطق اصلی این چارچوب را تأیید کرده است.
آنچه این چارچوب واقعاً به ما داد
به خاطر سپردن این شش الگو بسیار ارزشمند است: Prompt Chaining، Routing، Parallelization، Evaluator-Optimizer، Orchestrator-Workers و Autonomous Agents. مورد آخر اساساً یک حلقه است که در آن مدل برنامهریزی میکند، عمل میکند، مشاهده میکند و تا زمانی که شرطی برقرار شود، این روند را تکرار میکند.
بسیاری از مهندسان پیش از انتشار این راهنما، در حال زنجیرهسازی پرامپتها (chaining prompts) یا واگذاری وظایف به رشتههای پردازشی (worker threads) بودند. آنچه Anthropic ارائه کرد، یک طبقهبندی (taxonomy) بود. آنچه برای یک نفر «عامل» (agent) بود، برای دیگری «گردش کار» (workflow) و برای نفر سوم «فراخوانی ابزار چندمرحلهای» (multi-step tool call) محسوب میشد. این راهنما آن آشفتگی را در دستهبندیهایی با مرزهای مشخص مرتب کرد. این کار باعث شد بتوان درباره سبک و سیاقها (trade-offs) بحث کرد بدون اینکه سوءتفاهم پیش بیاید. در حوزهای که در هیاهوی تبلیغاتی غرق شده است، زبان دقیق و شفاف نوعی زیرساخت محسوب میشود.
صنعت بر روی این الگوها بنا شد، نه در اطراف آنها
تا سال ۲۰۲۶، این دستهبندیها در نحوه طراحی سیستمها توسط تیمها نهادینه شدهاند. Anthropic همچنان آنها را در دورههای آکادمی خود آموزش میدهد. مقالات پژوهشی و وبلاگهای مهندسی هنوز از همین شش دسته برای توصیف معماریهای جدید استفاده میکنند. چنین ماندگاریای برای رشتهای که هر فصل پشته تکنولوژی (stack) خود را بازسازی میکند، غیرمعمول است.
دلیل آن ساده است. صنعت این چارچوب را جایگزین نکرد، بلکه بر روی آن بنا کرد. ابزارهای جدید مانند MCP و استانداردهای جدیدتر Agent Skills مانند زیرساختهای پایه (plumbing) عمل میکنند. آنها اتصال یک مدل به پایگاه داده، ارائه یک ابزار یا مدیریت وضعیت (state) را آسانتر میکنند، اما منطقِ «چه زمانی به جای یک هماهنگکننده (orchestrator) از یک مسیریاب (router) استفاده کنیم» را تغییر نمیدهند. یک لوله بهتر، نقشه ساختمان را بازنویسی نمیکند.
دادههای تولید در سال ۲۰۲۶ این موضوع را تأیید میکنند. رایجترین الگوی استقرار، همچنان یک فراخوانیِ استفاده از ابزارِ واحد است که با بازبینی انسانی همراه شده است. دومین الگوی رایج، یک گردش کار چندمرحلهای است که دقیقاً یک مرحله تحویل کار به انسان دارد. هر دوی اینها فرزندان مستقیم Prompt Chaining و Routing هستند. حلقههای کاملاً خودمختار در سیستمهای زنده همچنان یک استثنا هستند، نه یک قاعده.
خویشتنداری در بازار پیروز شد
بهترین توصیه راهنمای اصلی، همان توصیهای بود که در سال ۲۰۲۴ بیش از همه نادیده گرفته شد: از سادهترین الگویی که کار را راه میاندازد استفاده کنید. اگر یک مسیر از پیش تعیینشده (hardcoded) میتواند کار را انجام دهد، یک عامل کاملاً خودمختار را مستقر نکنید.
بازار بالاخره این موضوع را درونی کرده است. بیشتر پروژههای آزمایشی (pilots) عاملها هنوز شکست میخورند و دلیل شکست آنها همان دلیل قابل پیشبینی است: تیمها لایه به لایه انتزاع (abstraction) روی هم میچینند تا جایی که دیگر هیچکس نمیتواند مرز تصمیمگیری را ردیابی کند. وقتی سیستم دچار انحراف میشود، عیبیابی (debugging) به باستانشناسی تبدیل میشود. شرکتهایی که در مرحله تولید موفق بودهاند، همانهایی هستند که خویشتنداری نشان دادهاند. آنها به طور پیشفرض از استفاده تکمرحلهای از ابزار استفاده کردند. آنها تنها زمانی یک لایه مسیریابی (routing) اضافه کردند که ثابت شد پرامپت واحد، بیثبات است. آنها با خودمختاری به عنوان یک مسئولیت (liability) برخورد کردند که باید توجیه شود، نه به عنوان ویژگیای که باید جشن گرفت.
این استدلالی علیه جاهطلبی نیست، بلکه استدلالی به نفع ترکیببندی (composition) است. الگوها زمانی بهترین عملکرد را دارند که آنها را آگاهانه با هم ترکیب کنید، نه اینکه به طور واکنشی به سراغ پیچیدهترین گزینه در منو بروید.
جایی که درزها شروع به نشت میکنند
این چارچوب یک درمان همهجانبه نیست. محدودیتهای سختی وجود دارد که به محض خروج از مرحله نمونه اولیه (prototype) خود را نشان میدهند.
For high-frequency, low-cost tasks, deterministic code still wins. An LLM should not be normalizing a CSV column when pandas can do it in milliseconds without hallucinating. Avoid autonomous loops if you cannot define a crisp evaluation goal. Without a clear stopping condition, the model will iterate until it invents a reason to stop. For high-stakes decisions that require external grounding, do not rely solely on the model’s internal knowledge. And watch for bottlenecks in data retrieval. Any pattern that depends on vector search or external APIs can choke if your database is slow or your context window is clogged with irrelevant chunks.
These are not hypothetical edge cases. They are the constraints that separate a working demo from a system that survives the weekend.
A Rigid Check and a Wrong Failure
I learned the practical value of this framework while building my test repository. I was implementing the Evaluator-Optimizer pattern. My evaluator started as a hardcoded regex that scanned the model’s output for specific keywords. The model returned a correct, well-reasoned answer that happened to use synonyms instead of the exact words I was hunting. The evaluator flagged it as a failure.
The model was right. My check was too rigid.
Fixing it required more than expanding a word list. I switched the evaluator itself to an LLM-based judgment. That cost extra tokens and a few more milliseconds, but it restored the evaluation to the right level of abstraction. The pattern itself was sound. I had simply chosen the wrong implementation for the task. That is exactly the kind of mistake the framework is meant to prevent. Some evaluations need code. Others need a model. Knowing which is which is the whole point.
How to Use Them Now
Treat these six patterns as a starting point, not absolute law. Begin with a single prompt. If quality is inconsistent across input types, add a routing layer to send different requests to specialized prompts. If you need multiple independent perspectives before making a call, use Parallelization. If the task is large and divisible, try Orchestrator-Workers. Only reach for the full autonomous loop when the problem space is too wide to pre-map and when you have a reliable