تصور کنید یک عامل هوش مصنوعی در مرحله دهم از یک عملیات پیچیده اشتباه میکند و شما مجبورید تمام مراحل قبلی را دوباره اجرا کنید و هزینه استنتاج را دوبار بپردازید. این کابوسِ رایج توسعهدهندگان اکنون با یک اسکریپت ۲۰۵ خطی پایتون به پایان رسیده است. در حالی که اکثر جریانهای کاری عاملهای هوش مصنوعی همچنان مانند «جعبههای سیاه» مبهم هستند، اکنون میتوان سه عامل را وادار کرد تا درباره یک موضوع بحث کنند، در حالی که یک ردپای بازرسی کامل و قابل بازگشت (Reversible Audit Trail) وجود دارد. با ترکیب Agno و Shepherd، توسعهدهندگان میتوانند سرانجام تولید یک خروجی هوش مصنوعی را از مرحله اعمال آن به سیستم جدا کنند.
اکثر دموهای عامل (Agent) — شبیه دستیارهای دیجیتالی که میتوانند بهطور مستقل هدف را دنبال کنند — با چاپ متن در کنسول تمام میشوند. اما در محیط تولید واقعی، عاملها حالتهای نامرئی میسازند، فایلها را ویرایش میکنند و ابزارها را فراخوانی میکنند که به محض خروج از پردازش، ناپدید میشوند. اگر یک عامل در مرحله دهم اشتباه کند، شما معمولاً باید از مرحله اول شروع کنید، هزینه هر فراخوانی مدل را دوباره بپردازید و امیدوار باشید که خروجیهای غیرقطعی (Non-deterministic)، همان موفقیتهای اولیه را تکرار کنند.
همانطور که در تحلیل قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، کنترل دقیق بر خروجی مدلها برای جلوگیری از خرابی سیستمهای عملیاتی حیاتی است. اینجاست که Shepherd (پروژهای که در سال ۲۰۲۶ در دانشگاه استنفورد توسعه یافت) وارد عمل میشود تا این شکاف را پر کند. این ابزار اجراها را بهصورت ردپاهای پایدار و شبیه به Git ضبط میکند. بهجای اجرای فوری، Shepherd یک «پیشنهاد» (Proposal) ایجاد میکند؛ خروجیای که در کنار فایلهای شما نگه داشته میشود و یک انسان باید آن را بررسی و تأیید (Settle) کند تا روی سیستم اعمال شود.
در این میان، Agno لایه ارکستراسیون یا همان سازماندهی عملیات را فراهم میکند. Agno یک API واحد برای بیش از ۳۰ ارائهدهنده مدل ارائه میدهد و دارای حالتهای صریح برای مدیریت تیمها، حافظه (Memory)، دانش (Knowledge) و کتابخانهای شامل بیش از ۱۰۰ ابزار است. ترکیب این دو، انعطافپذیری Agno را با شبکه ایمنی Shepherd پیوند میزند.
برای نمایش این قابلیت، یک سامانه «دادگاه» طراحی شده است که در آن سه عامل بر اساس یک موضوع خاص (مثلاً «دورکاری بهتر از حضوری است») با یکدیگر تعامل میکنند:
- عامل موافق (Pro): استدلالهای موافق را مینویسد و در فایل
pro_argument.txtذخیره میکند. - عامل مخالف (Con): استدلالهای مخالف را در
con_argument.txtثبت میکند. - عامل داور (Judge): هر دو استدلال را میخواند و حکم نهایی را در
verdict.txtمینویسد تا برنده را مشخص کند.
در یک اجرای نمونه، عامل موافق (با تمرکز بر انعطافپذیری و تعادل میان کار و زندگی) ۱۸۹۴ کاراکتر و عامل مخالف (با تمرکز بر همکاری و تعاملات خودجوش) ۱۸۴۹ کاراکتر تولید کردند. در نهایت، داور با تحلیل هر دو متن، حکمی ۳۸۴۳ کاراکتری نوشت و عامل موافق را برنده اعلام کرد.
بر اساس مستندات فنی این پروژه، پیادهسازی این سیستم بر سه تصمیم کلیدی برای تضمین پایداری و انعطافپذیری استوار است:
اول، الگوی provider:model_id برای جلوگیری از سختکد کردن مدلها استفاده شده است. برای مثال با رشته openai:gpt-4o-mini درخواست به کلاس درست هدایت میشود. یک تابع به نام make_agent این رشته را تجزیه میکند تا درخواست را به کلاس مدل صحیح (مانند OpenAIChat یا Ollama یا LMStudio) هدایت کند. این یعنی کاربر میتواند بهسادگی مدل هر عامل را از طریق خط فرمان (CLI) تغییر دهد؛ مثلاً تخصیص openai:gpt-4o برای موافق، ollama:llama3.2 برای مخالف و openai:gpt-4o-mini برای داور.
دوم، انتقال بستر متنی (Context) بهصورت فایلمحور انجام میشود. برای جلوگیری از خطاهای رایج «عدم توانایی در خواندن فایل» (جایی که عاملها با ابزارهای خواندن فایل مشکل دارند)، متن کامل استدلال هر دو طرف مستقیماً در پرامپت عامل داور قرار میگیرد. در این پرامپت از جداکنندههای بصری (مانند "="*40) استفاده شده تا متنهای موافق و مخالف بهطور واضح از هم تفکیک شوند.
سوم، ثبت تکالیف بهصورت Idempotent است. نسخه v0.2.1 ابزار Shepherd از یک قفل «خواندن پس از نوشتن» (Read-after-write lock) استفاده میکند. این کار مانع از ثبت یک تکلیف در حالی میشود که دنیای اجرای قبلی هنوز فعال است. در پیادهسازی، از یک بلوک try/except در هنگام فراخوانی workspace.tasks.register_source(...) استفاده شده تا اگر تکلیفی از قبل وجود داشت، اسکریپت بدون کرش کردن به کار خود ادامه دهد.
تمایز اصلی Shepherd در فرآیند تأیید (Settlement) است. پس از پایان بحث عاملها، خروجی در یک حالت «نگهداریشده» باقی میماند؛ یعنی تولید شده اما هنوز بر روی سیستم فایل واقعی اعمال نشده است. توسعهدهنده از طریق دستورات خط فرمان کنترل کامل دارد:
- دستور
shepherd run show run-2a4c8ca6355f: برای بازرسی یک اجرای خاص. - دستور
shepherd run trace run-2a4c8ca6355f --events: برای مشاهده ردپای رویدادها. - دستور
shepherd run select run-2a4c8ca6355f: برای علامتگذاری اجرا به عنوان پذیرفتهشده و ایجاد یک رکورد تغییرناپذیر. - دستور
shepherd run discard run-2a4c8ca6355f: برای رد کردن اجرا و در واقع بازگرداندن (Rollback) تغییرات.
این معناشناسی «یکبار مصرف» (Consume-once) مانع از بروز مشکل اعمال دوبارۀ خروجیها میشود.
البته این سیستم در مراحل اولیه است و نقاط ضعفی دارد. قفلهای فضای کاری (Workspace locks) میتوانند باعث شوند اجراهای قدیمی، عملیاتهای جدید را مسدود کنند. همچنین، بدنه تکالیف در یک زیربرنامه (Subprocess) فایل موقت اجرا میشود، به این معنی که متغیرهای محیطی (مانند کلیدهای API) بهطور خودکار منتقل نمیشوند. این متغیرها باید به عنوان استدلالهای تابع ارسال شده و در داخل بدنه از طریق os.environ تنظیم شوند.
محدودیتهای دیگر عبارتند از:
- جایگذاری (Placement): در حال حاضر نوشتن فایلها مستقیماً روی دیسک انجام میشود. رهگیری واقعی تغییرات به عنوان یک «مجموعه تغییرات» (Changeset) نیازمند
placement='jail'(استفاده از macOS Seatbelt) است که در این دمو استفاده نشد. - جزئیات ردپا (Trace Granularity): ردپای اجرا، رویدادهای چرخه عمر را نشان میدهد اما دید کافی نسبت به تک تک مدل-فراخوانیها (Model Calls) ندارد. این ابزارسنجی عمیقتر در حال حاضر در نقشه راه (Roadmap) Shepherd قرار دارد.
در مقابل، بخش Agno در این ادغام بسیار صیقلخورده است و APIهای تمیز Agent.run() و الگوهای پیشبینیپذیر برای مسیریابی مدلها را ارائه میدهد.
این ادغام، فرض قدیمی درباره خطی و شکننده بودن گردشهای کاری عاملمحور (Agentic) را تغییر میدهد. با معرفی مرحله «پیشنهاد»، اتوماسیون از حالت «بفرست و فراموش کن» به یک خط لوله قابل تایید تبدیل میشود. این موضوع بهخصوص در محیطهای حساس که یک ویرایش اشتباه در کد (ناشی از توهم یا Hallucination) میتواند کل سیستم تولید را متوقف کند، حیاتی است.
برای برنامهنویس، هزینه شکست کاهش مییابد. دیگر لازم نیست کل زنجیره تفکر (Chain-of-Thought) — شبیه وقتی شاگرد ریاضی پای تخته بلند بلند فکر میکند تا به جواب برسد — را برای اصلاح یک اشتباه در مرحله آخر دوباره بخرید. توانایی «رد کردن» (Discard) یک اجرای خاص در حالی که ردپای آن برای تحلیل حفظ شده، عیبیابی عاملها را به یک مسئله کنترل نسخه (Version Control) تبدیل کرده است، نه یک بازی حدس و خطا با پرامپتها.
گامهای توسعه در آینده
توسعهدهندگان میتوانند این سیستم (که در آدرس courtroom.agi/debate_demo.py موجود است) را از سه مسیر گسترش دهند:
سطح ساده: پیادهسازی احکام ساختاریافته از طریق
output_modelدر Agno با استفاده از شمای Pydantic یا جایگزینی تابعopen()با ابزارهایFileToolsدر Agno.سطح متوسط: ایجاد یک بحث چند مرحلهای که در آن موافق و مخالف به استدلالهای یکدیگر پاسخ دهند (Rebuttal)، یا افزودن یک عامل چهارم به نام «مخاطبان» برای شبیهسازی واکنشها.
سطح پیشرفته: استفاده از
placement='jail'برای رهگیری نوشتن در سطح سیستمعامل یا ساخت یک «عامل ناظر» (Supervisor meta-agent) که ردپاهای Shepherd را مانیتور کرده و بهطور خودکار دستورshepherd run discardرا برای مراحل اشتباه صادر کند.اگر از Agno استفاده میکنید، سعی کنید خروجیهای حساس را بهجای اعمال مستقیم، در یک لایه تأیید قرار دهید.
برای پروژههای عملیاتی، بررسی کنید که آیا مدلهای کوچکتر (مانند Llama 3.2) در نقشههای ارکستراسیون شما به اندازه مدلهای بزرگ کارآمد هستند یا خیر.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو