تیم Anthropic با ده‌ها مجموعه فعال در صنایع مختلف برای ساخت عامل‌های مبتنی بر مدل‌های زبانی بزرگ همکاری کرده است. تجربه این پروژه‌ها نشان می‌دهد موفق‌ترین پیاده‌سازی‌ها معمولاً به‌جای چارچوب‌های پیچیده، بر الگوهای ساده، شفاف و ترکیب‌پذیر متکی هستند.یادداشت به‌روزرسانی: بخش زیادی از ابزارها و فناوری‌های معرفی‌شده در نسخه اصلی این مقاله، از دسامبر ۲۰۲۴ تاکنون تغییر کرده‌اند. برای آشنایی با رویکرد فعلی Anthropic، می‌توانید مستندات مربوط به Claude Managed Agents و Managed Agents را مطالعه کنید.

مقدمه

در یک سال گذشته، Anthropic با ده‌ها تیم در صنایع مختلف برای ساخت عامل‌های مبتنی بر مدل‌های زبانی بزرگ یا LLM Agents همکاری کرده است.در تمام این پروژه‌ها یک الگوی ثابت دیده می‌شود: موفق‌ترین پیاده‌سازی‌ها از چارچوب‌های بسیار پیچیده یا کتابخانه‌های تخصصی و سنگین استفاده نمی‌کنند؛ بلکه با مجموعه‌ای از الگوهای ساده و ترکیب‌پذیر ساخته می‌شوند.در این مقاله، تجربه‌های حاصل از همکاری با مشتریان و ساخت عامل‌های هوش مصنوعی در Anthropic را بررسی می‌کنیم و توصیه‌هایی کاربردی برای توسعه‌دهندگانی ارائه می‌دهیم که قصد دارند عامل‌هایی مؤثر، قابل‌اعتماد و قابل‌نگهداری بسازند.

عامل هوش مصنوعی چیست؟

واژه «عامل» یا Agent می‌تواند تعاریف متفاوتی داشته باشد.

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

گردش‌کارها

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

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

عامل‌ها

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

چه زمانی باید از عامل‌ها استفاده کنیم؟

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

انتخاب میان گردش‌کار و عامل

اگر افزایش پیچیدگی ضروری باشد:

گردش‌کارها برای وظایف مشخص و خوش‌تعریف، پیش‌بینی‌پذیری و ثبات بیشتری فراهم می‌کنند؛
عامل‌ها برای موقعیت‌هایی مناسب‌اند که به انعطاف‌پذیری، تصمیم‌گیری پویا و کنترل مبتنی بر مدل در مقیاس بالا نیاز دارند.

بااین‌حال، برای بسیاری از برنامه‌ها نیازی به ساخت سیستم‌های چندمرحله‌ای یا خودمختار نیست. در موارد زیادی، بهینه‌سازی یک فراخوانی ساده مدل زبانی با استفاده از بازیابی اطلاعات و مثال‌های درون‌متنی، نتیجه مطلوب را ایجاد می‌کند.

به‌طور خلاصه:

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

چه زمانی و چگونه از فریم‌ورک‌ها استفاده کنیم؟

فریم‌ورک‌های مختلفی برای ساده‌تر کردن پیاده‌سازی سیستم‌های عامل‌محور وجود دارند، از جمله:

Claude Agent SDK؛
Strands Agents SDK از شرکت AWS؛
Rivet، سازنده بصری گردش‌کارهای مبتنی بر LLM با قابلیت کشیدن و رها کردن؛
Vellum، ابزار گرافیکی دیگری برای ساخت و آزمایش گردش‌کارهای پیچیده.

این فریم‌ورک‌ها شروع کار را ساده‌تر می‌کنند؛ زیرا بسیاری از وظایف سطح پایین و تکراری را مدیریت می‌کنند، از جمله:

فراخوانی مدل‌های زبانی؛
تعریف ابزارها؛
تجزیه و تحلیل فراخوانی ابزارها؛
متصل کردن چند فراخوانی به یکدیگر؛
مدیریت جریان داده میان مراحل مختلف.

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

پیشنهاد Anthropic

بهتر است توسعه‌دهندگان کار خود را با استفاده مستقیم از API مدل‌های زبانی آغاز کنند. بسیاری از الگوهای عامل‌محور را می‌توان تنها با چند خط کد پیاده‌سازی کرد. اگر تصمیم دارید از یک فریم‌ورک استفاده کنید، باید مطمئن شوید که منطق و کدهای زیرین آن را به‌خوبی درک می‌کنید. برداشت‌های نادرست درباره اتفاقاتی که در لایه‌های داخلی فریم‌ورک رخ می‌دهد، یکی از منابع رایج خطا در پروژه‌های واقعی است. نمونه‌های پیاده‌سازی این الگوها در Cookbook آنتروپیک در دسترس‌اند.

اجزای پایه، گردش‌کارها و عامل‌ها

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

جزء پایه: مدل زبانی تقویت‌شده

جزء بنیادی سیستم‌های عامل‌محور، یک مدل زبانی است که با قابلیت‌های تکمیلی تقویت شده باشد، از جمله:

بازیابی اطلاعات؛
دسترسی به ابزارها؛
حافظه.

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

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

در پیاده‌سازی مدل زبانی تقویت‌شده باید بر دو موضوع اصلی تمرکز کرد:

قابلیت‌ها را متناسب با کاربرد مشخص خود طراحی و سفارشی کنید؛
رابطی ساده، روشن و مستندشده در اختیار مدل زبانی قرار دهید.

روش‌های مختلفی برای پیاده‌سازی این قابلیت‌ها وجود دارد. یکی از این روش‌ها استفاده از پروتکل زمینه مدل یا Model Context Protocol – MCP است. MCP به توسعه‌دهندگان اجازه می‌دهد با یک پیاده‌سازی ساده در سمت کلاینت، عامل خود را به مجموعه روبه‌رشدی از ابزارها و سرویس‌های شخص ثالث متصل کنند. در ادامه مقاله فرض می‌کنیم هر فراخوانی مدل زبانی به قابلیت‌هایی مانند بازیابی اطلاعات، ابزارها و حافظه دسترسی دارد.

گردش‌کار اول: زنجیره‌سازی پرامپت‌ها

در الگوی Prompt Chaining، یک وظیفه به مجموعه‌ای از مراحل متوالی تقسیم می‌شود. هر فراخوانی مدل زبانی، خروجی مرحله قبلی را دریافت و پردازش می‌کند. همچنین می‌توان در مراحل میانی، کنترل‌های برنامه‌نویسی‌شده‌ای با عنوان Gate یا «دروازه کنترل» اضافه کرد تا مطمئن شویم فرایند همچنان در مسیر صحیح قرار دارد.

تصویر شماره ۲: گردش‌کار زنجیره‌سازی پرامپت‌ها و دروازه کنترل میان مراحل

چه زمانی از زنجیره‌سازی پرامپت استفاده کنیم؟

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

نمونه‌های کاربرد

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

گردش‌کار دوم: مسیریابی

در الگوی Routing، ابتدا ورودی کاربر طبقه‌بندی می‌شود و سپس به یک وظیفه، پرامپت، مدل یا ابزار تخصصی هدایت می‌شود. این گردش‌کار امکان تفکیک مسئولیت‌ها و طراحی پرامپت‌های تخصصی‌تر را فراهم می‌کند. بدون مسیریابی، ممکن است بهینه‌سازی سیستم برای یک نوع ورودی، عملکرد آن را برای انواع دیگر ورودی‌ها کاهش دهد.

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

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

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

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

نمونه‌های کاربرد

مسیریابی درخواست‌های پشتیبانی

درخواست‌های مختلف خدمات مشتریان را می‌توان به فرایندهای جداگانه هدایت کرد، مانند:

پرسش‌های عمومی؛
درخواست بازپرداخت؛
پشتیبانی فنی؛
پیگیری سفارش؛
گزارش مشکل حساب کاربری.

هر دسته می‌تواند پرامپت‌ها، ابزارها و گردش‌کارهای مخصوص به خود را داشته باشد.

مسیریابی میان مدل‌های مختلف

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

پرسش‌های ساده و متداول را به مدل‌های کوچک‌تر و کم‌هزینه‌تر مانند Claude Haiku 4.5 ارسال کرد؛
پرسش‌های دشوار یا غیرمعمول را به مدل‌های توانمندتر مانند Claude Sonnet 4.5 هدایت کرد.

گردش‌کار سوم: اجرای موازی

گاهی مدل‌های زبانی می‌توانند به‌صورت هم‌زمان روی یک وظیفه کار کنند و خروجی‌های آن‌ها در پایان به‌صورت برنامه‌نویسی‌شده با یکدیگر ترکیب شوند. این الگو که Parallelization نام دارد، دو شکل اصلی دارد:

۱. بخش‌بندی

در روش Sectioning، یک وظیفه به چند زیروظیفه مستقل تقسیم می‌شود و تمام زیروظیفه‌ها به‌صورت موازی اجرا می‌شوند.

۲. رأی‌گیری

در روش Voting، یک وظیفه یکسان چند بار اجرا می‌شود تا خروجی‌های متنوعی به دست آید و بتوان براساس آن‌ها به نتیجه‌ای مطمئن‌تر رسید.

اجرای موازی با دو الگوی بخش‌بندی و رأی‌گیری

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

این گردش‌کار در دو وضعیت مؤثر است:

وقتی زیروظیفه‌ها مستقل‌اند و اجرای موازی آن‌ها باعث افزایش سرعت می‌شود؛
وقتی برای افزایش اطمینان به چند دیدگاه، ارزیابی یا تلاش مستقل نیاز داریم.

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

نمونه‌های کاربرد بخش‌بندی

اجرای هم‌زمان پاسخ‌گویی و گاردریل

یک نمونه مدل زبانی می‌تواند درخواست کاربر را پردازش کند و نمونه دیگری هم‌زمان ورودی را از نظر محتوای نامناسب یا درخواست‌های پرخطر بررسی کند. این روش معمولاً بهتر از حالتی عمل می‌کند که یک فراخوانی واحد، هم وظیفه اصلی و هم کنترل‌های ایمنی را بر عهده داشته باشد.

خودکارسازی ارزیابی مدل‌ها

در ارزیابی عملکرد مدل، هر فراخوانی می‌تواند جنبه متفاوتی را بررسی کند؛ برای مثال:

دقت پاسخ؛
مرتبط‌بودن؛
کیفیت نگارش؛
ایمنی؛
رعایت قالب؛
استنادپذیری.

نمونه‌های کاربرد رأی‌گیری

بررسی امنیتی کد

چند پرامپت یا نمونه مستقل می‌توانند یک قطعه کد را از نظر آسیب‌پذیری بررسی کنند. اگر تعدادی از آن‌ها مشکلی را گزارش دهند، کد برای بررسی بیشتر علامت‌گذاری می‌شود.

تشخیص محتوای نامناسب

چند ارزیاب می‌توانند ابعاد مختلف یک محتوا را بررسی کنند. همچنین می‌توان آستانه رأی را برای ایجاد تعادل میان مثبت کاذب و منفی کاذب تنظیم کرد.

گردش‌کار چهارم: ارکستریتور و عامل‌های اجرایی

در الگوی Orchestrator–Workers، یک مدل زبانی مرکزی نقش ارکستریتور را بر عهده دارد.

این مدل:

وظیفه اصلی را تحلیل می‌کند؛
آن را به زیروظیفه‌های مناسب تقسیم می‌کند؛
هر زیروظیفه را به یک مدل یا عامل اجرایی واگذار می‌کند؛
خروجی عامل‌های اجرایی را دریافت می‌کند؛
نتایج را با یکدیگر ترکیب می‌کند؛
پاسخ نهایی را می‌سازد.

گردش‌کار ارکستریتور و عامل‌های اجرایی

چه زمانی از این گردش‌کار استفاده کنیم؟

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

تعداد فایل‌هایی که باید تغییر کنند؛
نوع تغییرات هر فایل؛
آزمایش‌هایی که باید اجرا شوند؛
وابستگی‌هایی که باید بررسی شوند.

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

نمونه‌های کاربرد

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

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

در گردش‌کار Evaluator–Optimizer، یک مدل زبانی پاسخ را تولید می‌کند و مدل دیگری آن را ارزیابی کرده و بازخورد ارائه می‌دهد. این فرایند می‌تواند در قالب یک حلقه تکرار شود:

تولید پاسخ اولیه؛
ارزیابی پاسخ؛
ارائه بازخورد؛
اصلاح پاسخ؛
ارزیابی مجدد؛
توقف پس از رسیدن به معیارهای موردنظر.

حلقه ارزیاب و بهینه‌ساز برای اصلاح تکرارشونده خروجی

چه زمانی از این گردش‌کار استفاده کنیم؟

این الگو زمانی مؤثر است که معیارهای ارزیابی روشنی داشته باشیم و اصلاح تکرارشونده، ارزش قابل‌اندازه‌گیری ایجاد کند.

دو نشانه مهم برای مناسب‌بودن این الگو وجود دارد:

وقتی یک انسان بازخورد روشن ارائه می‌کند، پاسخ مدل به‌طور قابل‌اثبات بهتر می‌شود؛
خود مدل زبانی نیز می‌تواند همان نوع بازخورد مفید را تولید کند.

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

نمونه‌های کاربرد

ترجمه ادبی

ممکن است مدل مترجم در مرحله اول برخی ظرافت‌های زبانی یا فرهنگی را درک نکند؛ اما یک مدل ارزیاب می‌تواند نقدهایی درباره لحن، معنا، سبک و وفاداری به متن ارائه دهد.

جست‌وجوی پیچیده

برخی وظایف جست‌وجویی به چند دور جست‌وجو و تحلیل نیاز دارند. مدل ارزیاب می‌تواند مشخص کند که اطلاعات فعلی کافی است یا باید جست‌وجوهای بیشتری انجام شود.

عامل‌های هوش مصنوعی

با پیشرفت مدل‌های زبانی در قابلیت‌های کلیدی، عامل‌ها به‌تدریج وارد محیط‌های عملیاتی شده‌اند.

این قابلیت‌های کلیدی عبارت‌اند از:

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

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

اهمیت بازخورد واقعی محیط

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

نمونه‌های این بازخورد عبارت‌اند از:

نتیجه فراخوانی ابزار؛
خروجی اجرای کد؛
پاسخ API؛
نتیجه آزمایش نرم‌افزار؛
وضعیت ثبت یا تغییر داده‌ها؛
پیام خطای سیستم.

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

حداکثر تعداد تکرارها؛
حداکثر تعداد فراخوانی ابزار؛
سقف هزینه؛
محدودیت زمانی؛
تکرار چندباره یک خطای مشخص؛
نیاز به اجرای اقدامی پرخطر.

معماری عامل‌ها لزوماً پیچیده نیست

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

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

به همین دلیل، طراحی دقیق مجموعه ابزارها و مستندات آن‌ها اهمیت بسیار زیادی دارد.

ساختار و حلقه اجرای یک عامل خودمختار

چه زمانی باید از عامل‌ها استفاده کنیم؟

عامل‌ها برای مسائل باز و پیچیده‌ای مناسب‌اند که در آن‌ها:

پیش‌بینی تعداد مراحل موردنیاز دشوار یا غیرممکن است؛
نمی‌توان یک مسیر ثابت را در کد تعریف کرد؛
تصمیم‌های بعدی به نتایج مراحل قبلی وابسته‌اند؛
عامل ممکن است برای چندین نوبت فعالیت کند؛
سطح قابل‌قبولی از اعتماد به تصمیم‌گیری مدل وجود دارد.

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

بااین‌حال، ماهیت خودمختار عامل‌ها دو پیامد مهم دارد:

هزینه اجرا افزایش پیدا می‌کند؛
خطاها ممکن است در مراحل متوالی روی یکدیگر انباشته شوند.

به همین دلیل، توصیه می‌شود عامل‌ها ابتدا به‌طور گسترده در محیط‌های ایزوله و آزمایشی یا Sandbox بررسی شوند و گاردریل‌های متناسبی برای آن‌ها تعریف شود.

نمونه‌های کاربرد عامل‌ها

عامل برنامه‌نویسی

عاملی که وظایف معیار SWE-bench را حل می‌کند. این وظایف ممکن است براساس یک شرح مسئله، به بررسی و ویرایش تعداد زیادی فایل نیاز داشته باشند.

عامل استفاده از رایانه

در پیاده‌سازی مرجع Computer Use، مدل Claude از رابط یک رایانه برای انجام وظایف استفاده می‌کند.

جریان سطح‌بالای عملکرد یک عامل برنامه‌نویسی

ترکیب و سفارشی‌سازی الگوها

الگوهای معرفی‌شده دستورالعمل‌هایی قطعی و تغییرناپذیر نیستند. آن‌ها ساختارهای رایجی هستند که توسعه‌دهندگان می‌توانند متناسب با نیازهای خود تغییر داده یا با یکدیگر ترکیب کنند.

برای مثال، یک سیستم می‌تواند:

ابتدا ورودی را مسیریابی کند؛
سپس وظیفه را به چند بخش موازی تقسیم کند؛
خروجی‌ها را در اختیار یک ارکستریتور قرار دهد؛
در پایان از یک ارزیاب برای کنترل کیفیت نتیجه استفاده کند.

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

جمع‌بندی

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

سه اصل مهم در ساخت عامل‌ها

۱. طراحی عامل را ساده نگه دارید

از معماری‌های پیچیده و انتزاع‌های غیرضروری اجتناب کنید. هر جزء جدید باید یک نیاز واقعی و قابل‌اندازه‌گیری را برطرف کند.

۲. شفافیت را در اولویت قرار دهید

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

۳. رابط عامل و رایانه را با دقت طراحی کنید

رابط عامل و رایانه یا Agent–Computer Interface – ACI باید با مستندسازی دقیق و آزمایش گسترده ابزارها طراحی شود. فریم‌ورک‌ها می‌توانند شروع کار را سریع‌تر کنند؛ اما هنگام انتقال سیستم به محیط عملیاتی، نباید از کاهش لایه‌های انتزاعی و استفاده از اجزای پایه واهمه داشت.

با رعایت این اصول می‌توان عامل‌هایی ساخت که نه‌تنها توانمند باشند، بلکه ویژگی‌های زیر را نیز داشته باشند:

قابل‌اعتماد؛
قابل‌نگهداری؛
شفاف؛
قابل‌آزمایش؛
مورداعتماد کاربران.

قدردانی

این مقاله توسط Erik S. و Barry Zhang نوشته شده است.

مطالب آن بر تجربه‌های Anthropic در زمینه ساخت عامل‌ها و همچنین دیدگاه‌های ارزشمندی استوار است که مشتریان این مجموعه در اختیار تیم قرار داده‌اند.

پیوست اول: عامل‌ها در عمل

همکاری با مشتریان، دو کاربرد بسیار امیدبخش برای عامل‌های هوش مصنوعی را مشخص کرده است.

این کاربردها نشان می‌دهند عامل‌ها زمانی بیشترین ارزش را ایجاد می‌کنند که وظایف موردنظر:

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

الف) خدمات مشتریان

خدمات مشتریان، رابط آشنای چت‌بات‌ها را با قابلیت‌های پیشرفته حاصل از اتصال به ابزارها ترکیب می‌کند.

این حوزه گزینه‌ای طبیعی برای عامل‌های بازتر و انعطاف‌پذیرتر است؛ زیرا:

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

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

ب) عامل‌های برنامه‌نویسی

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

عامل‌ها در این حوزه به چند دلیل عملکرد مؤثری دارند:

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

در پیاده‌سازی Anthropic، عامل‌ها می‌توانند تنها براساس توضیحات یک Pull Request، مسائل واقعی گیت‌هاب موجود در معیار SWE-bench Verified را حل کنند. بااین‌حال، اگرچه آزمایش‌های خودکار به تأیید عملکرد فنی کمک می‌کنند، بازبینی انسانی همچنان ضروری است تا اطمینان حاصل شود راه‌حل با نیازهای گسترده‌تر سیستم و معماری پروژه سازگار است.

پیوست دوم: مهندسی پرامپت برای ابزارها

صرف‌نظر از نوع سیستم عامل‌محوری که می‌سازید، ابزارها احتمالاً یکی از مهم‌ترین اجزای آن خواهند بود. ابزارها به Claude اجازه می‌دهند با سرویس‌ها و APIهای بیرونی تعامل کند. برای این منظور، ساختار و تعریف دقیق ابزار در API مشخص می‌شود. اگر Claude تصمیم بگیرد ابزاری را فراخوانی کند، پاسخ API شامل یک بلوک Tool Use خواهد بود. تعریف و مشخصات ابزارها باید به‌اندازه پرامپت اصلی مورد توجه مهندسی پرامپت قرار گیرند.

انتخاب قالب مناسب برای ابزار

معمولاً برای تعریف یک اقدام، چند روش مختلف وجود دارد.

برای مثال، ویرایش یک فایل را می‌توان به دو شکل انجام داد:

نوشتن یک Diff؛
بازنویسی کامل فایل.

خروجی ساختاریافته نیز می‌تواند در قالب‌های مختلفی تولید شود:

کد درون Markdown؛
کد یا داده درون JSON.

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

همچنین نوشتن کد درون JSON، در مقایسه با Markdown، به Escape کردن خطوط جدید، نقل‌قول‌ها و کاراکترهای خاص نیاز دارد. این سربار قالب‌بندی احتمال بروز خطا را افزایش می‌دهد.

توصیه‌هایی برای انتخاب قالب ابزارها

۱. فضای کافی برای استدلال در اختیار مدل قرار دهید

مدل باید پیش از تولید خروجی نهایی، توکن کافی برای بررسی مسئله و برنامه‌ریزی داشته باشد تا هنگام تولید پاسخ در یک مسیر نامناسب گرفتار نشود.

۲. از قالب‌های طبیعی و آشنا استفاده کنید

قالب ابزار را تا حد ممکن به ساختارهایی نزدیک کنید که مدل به‌طور طبیعی در داده‌های متنی اینترنت مشاهده کرده است.

۳. سربار قالب‌بندی را کاهش دهید

مدل نباید مجبور باشد برای تولید خروجی:

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

طراحی رابط عامل و رایانه

یک قاعده تجربی مفید این است که ببینیم چه میزان زمان و تلاش صرف طراحی رابط انسان و رایانه یا Human–Computer Interface – HCI می‌شود. تقریباً به همان اندازه باید برای طراحی یک رابط مناسب میان عامل و رایانه یا Agent–Computer Interface – ACI زمان صرف کرد.

خود را جای مدل قرار دهید

هنگام تعریف یک ابزار از خود بپرسید:

آیا نحوه استفاده از ابزار از روی توضیحات و پارامترها روشن است؟
آیا مشخص است ابزار در چه شرایطی باید فراخوانی شود؟
آیا تفاوت آن با ابزارهای مشابه واضح است؟
آیا قالب ورودی و خروجی دقیقاً تعریف شده است؟
آیا مدل برای استفاده از آن باید بیش از حد فکر کند یا حدس بزند؟

اگر نحوه استفاده از ابزار برای یک انسان مبهم باشد، احتمالاً برای مدل نیز مبهم خواهد بود.

اجزای یک تعریف مناسب برای ابزار

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

توضیح روشن درباره کاربرد ابزار؛
نمونه استفاده؛
حالت‌های مرزی؛
الزامات قالب ورودی؛
تعریف پارامترها؛
نمونه خروجی؛
محدودیت‌ها؛
مرزبندی روشن با ابزارهای مشابه؛
توضیح خطاهای احتمالی.

تعریف ابزار را مانند یک Docstring دقیق برای یک توسعه‌دهنده تازه‌کار در تیم خود در نظر بگیرید.

این موضوع زمانی اهمیت بیشتری پیدا می‌کند که عامل به تعداد زیادی ابزار مشابه دسترسی دارد.

نام و توضیحات پارامترها را بهینه کنید

بررسی کنید که آیا می‌توان با تغییر نام پارامترها یا توضیحات آن‌ها، استفاده از ابزار را روشن‌تر کرد. برای مثال، یک پارامتر عمومی مانند path ممکن است مبهم باشد. استفاده از نامی مانند absolute_file_path به‌روشنی نشان می‌دهد که مدل باید مسیر کامل فایل را ارسال کند.

نام‌گذاری مناسب، فضای تصمیم‌گیری اشتباه را کاهش می‌دهد.

نحوه استفاده مدل از ابزارها را آزمایش کنید

تعداد زیادی ورودی نمونه را در محیط آزمایش اجرا کنید و بررسی کنید:

مدل چه ابزارهایی را انتخاب می‌کند؛
در چه شرایطی ابزار اشتباه را فراخوانی می‌کند؛
کدام پارامترها را نادرست تکمیل می‌کند؛
چه توضیحاتی را اشتباه تفسیر می‌کند؛
در کدام حالت‌های مرزی دچار مشکل می‌شود.

سپس تعریف ابزارها را براساس این مشاهدات اصلاح کنید.

ابزارها را خطاناپذیر طراحی کنید

از اصل Poka-Yoke یا خطاناپذیرسازی استفاده کنید. ورودی‌ها و آرگومان‌های ابزار را به‌گونه‌ای طراحی کنید که اشتباه‌کردن برای مدل دشوارتر شود. در جریان ساخت عامل Anthropic برای معیار SWE-bench، تیم توسعه در عمل زمان بیشتری را صرف بهینه‌سازی ابزارها کرد تا اصلاح پرامپت اصلی. برای مثال، مشخص شد مدل هنگام استفاده از ابزارهایی که مسیر نسبی فایل دریافت می‌کردند، پس از خارج‌شدن عامل از پوشه ریشه پروژه دچار اشتباه می‌شد. برای حل این مشکل، ابزار تغییر کرد تا همیشه مسیر مطلق فایل را دریافت کند. پس از اعمال این تغییر، مدل توانست بدون خطا از ابزار استفاده کند. این تجربه یک اصل مهم را نشان می‌دهد:

گاهی بهترین راه برای بهبود عملکرد عامل، نوشتن پرامپت پیچیده‌تر نیست؛ بلکه باید ابزار را به‌گونه‌ای بازطراحی کرد که امکان اشتباه را کاهش دهد.

منبع

Building effective agents