«استقلالِ محدود»؛ شرط لازم برای خروج عامل‌های هوش مصنوعی از محیط دمو

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

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

به نقل از راهنمای معماری منتشر شده در dev.to در ۱۵ اوت ۲۰۲۶، شکاف میان نمونهٔ اولیه و سامانهٔ قابل‌اعتماد با شش الگوی معماری پر می‌شود. این الگوها مکانیسم‌های ایمنی را از پرامپت — که به راحتی دور زده می‌شود — به کد برنامه منتقل می‌کنند. برای درک این الگوها، ابتدا باید عامل (Agent) را تعریف کنیم: سامانه‌ای که در آن مدل تصمیم می‌گیرد اقدام بعدی چه باشد — کدام ابزار، با چه آرگومان‌هایی و اینکه آیا باید ادامه دهد یا خیر — به جای اینکه صرفاً یک خط لوله (Pipeline) ثابت را اجرا کند. همین قدرت تصمیم‌گیری است که منبع هم‌زمان ارزش و ریسک است.

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

الگوی ۱: حلقهٔ محدود (Bounded Loop)

هر حلقهٔ عامل‌محور — یعنی چرخهٔ ابتدایی مشاهده، تصمیم، اجرا و تکرار — باید در یک بودجهٔ چندمحوره محصور شود تا از فرآیندهای «فراری» (Runaway) جلوگیری شود. یک سامانهٔ عملیاتی باید کلاس LoopBudget را پیاده کند که موارد زیر را ردیابی کند:

• حداکثر گام‌ها (Max Steps): یک توقف سخت برای تعداد اقدامات در هر تسک. اکثر کلاس‌های تسک مفید در ۵ تا ۱۵ گام به نتیجه می‌رسند؛ اگر عاملی به طور منظم به ۴۰ گام نیاز دارد، شما با یک مشکل در تجزیه (Decomposition) تسک روبرو هستید.
• حداکثر توکن‌ها (Max Tokens): سقف هزینه برای هر تسک جهت کنترل هزینه‌ها (مثلاً ۱۵۰,۰۰۰ توکن — تکه‌های کوچکی از متن که مدل تکه‌تکه می‌خورد).
• زمان واقعی (Wall Clock Time): یک مهلت زمانی (مثلاً ۳۰۰ ثانیه) برای اطمینان از اینکه عامل بیش از حد صبر کاربر را می‌آزماید.
• حداکثر خطاهای ابزار (Max Tool Errors): محدودیت در شکست‌های متوالی (مثلاً ۳ بار) پیش از آنکه عامل تسلیم شود.
• تشخیص تکرار (Repeat Detection): مکانیسمی برای کشتن فرآیند اگر عامل همان اقدام شکست‌خورده را با آرگومان‌های کاملاً یکسان تکرار کند (حداکثر تکرار: ۲).

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

الگوی ۲: اسکلت‌های جریان‌کاری (Workflow Skeletons)

عامل‌های کاملاً باز — که فقط یک حلقه دارند، به همه ابزارها دسترسی دارند و باید «خودشان راه را پیدا کنند» — بیشترین میزان انعطاف‌پذیری و در عین حال بیشترین میزان تغییرپذیری (Variance) را دارند. نقطهٔ بهینه در تولید، استفاده از یک اسکلت جریان‌کاری قطعی است که در آن فقط مراحل خاصی عامل‌محور هستند.

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

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

الگوی ۳: سطوح دسترسی ابزارها (Tool Authorization Tiers)

دادن یک جعبه‌ابزار یکپارچه و بدون تفکیک به یک مدل احتمالی، یک خطای استراتژیک است. ابزارها باید بر اساس پیامدشان دسته‌بندی شوند و این دسترسی توسط اجراکننده (Executor) اعمال شود، نه پرامپت:

• سطح ۰ (مشاهده - Observe): خواندن، جست‌وجو، واکشی و لیست کردن. دسترسی آزاد؛ بدترین حالت، هدر رفتن بودجه است.
• سطح ۱ (برگشت‌پذیر - Reversible): پیش‌نویس، مرحله‌بندی، کامنت گذاشتن یا ایجاد در محیط Sandbox. در داخل حلقه در دسترس هستند و اشتباهات آن‌ها قابل بازگشت است.
• سطح ۲ (پیامددار - Consequential): ارسال، ادغام (Merge)، استقرار در محیط Staging یا تغییر وضعیت مشترک. این‌ها نیاز به بررسی پیش‌شرط‌های قطعی (قوانین اعتبارسنجی، تأیید وضعیت) پیش از اجرا دارند.
• سطح ۳ (برگشت‌ناپذیر - Irreversible): پرداخت‌ها، حذف داده‌ها، استقرار در محیط Production یا ارتباطات خارجی در مقیاس بالا. این‌ها نیاز به گیت انسانی دارند یا کلاً از دنیای عامل حذف می‌شوند.

نکته حیاتی این است که این لایه‌بندی در «اجراکننده ابزار» (Tool Executor) قرار دارد. پرامپتی که می‌گوید «لطفاً مراقب باش» فقط یک آرزوست؛ اما اجراکننده‌ای که فراخوانی‌های سطح ۲ را به دلیل عدم تأیید پیش‌شرط‌ها رد می‌کند، یک کنترل واقعی است. علاوه بر این، آرگومان‌ها باید بر اساس صلاحیت درخواست‌کننده اعتبارسنجی شوند، نه صلاحیت عامل. عاملی که برای کاربر X عمل می‌کند، باید اعتبارنامه‌های محدود شده برای آن تسک را به ارث ببرد، نه اینکه یک «توکن خدای‌گونه» (God-token) داشته باشد. این همان مهندسی اصل «حداقل دسترسی» (Least-privilege) است. این موضوع ضروری است زیرا هر عاملی که محتوای خارجی (صفحات وب، ایمیل‌ها) را بخواند، در نهایت با تزریق پرامپت مواجه خواهد شد؛ سیستم لایه‌بندی باعث می‌شود چنین اتفاقی به جای یک حادثه امنیتی، تبدیل به یک اتفاق ساده شود.

الگوی ۴: نقطهٔ بازرسی و ازسرگیری (Checkpoint and Resume)

تسک‌های عملیاتی اغلب دقایق یا ساعت‌ها طول می‌کشند، با ابزارهای ناپایدار مواجه می‌شوند و توسط انسان‌ها متوقف می‌گردند. برای بقا، عامل‌ها باید وضعیت تسک خود — شامل برنامه، گام‌های تکمیل شده، نتایج ابزارها و قصد جاری — را در هر مرز گام در یک ذخیره‌ساز بادوام (Durable Store) ثبت کنند.

این کار باعث می‌شود حلقه بدون وضعیت (Stateless) و قابل ازسرگیری شود که نتایج آن عبارت است از:

• تاب‌آوری (Resilience): اختلالات ارائه‌دهنده مدل تبدیل به توقف‌های موقت می‌شوند، نه شکست کل تسک.
• قابلیت حسابرسی (Auditability): بازسازی دقیق آنچه عامل در لحظه تصمیم‌گیری می‌دانست، که برای تحلیل‌های پس از حادثه (Postmortems) و تیم‌های انطباق حیاتی است.
• گیت‌های ناهمگام (Asynchronous Gates): تایید انسانی تبدیل به یک وضعیت انتظار در نقطه بازرسی می‌شود؛ عامل متوقف می‌شود و تسک ساعت‌ها بعد با زمینه (Context) دست‌نخورده ازسر گرفته می‌شود.
• عیب‌یابی (Debugging): مقایسه نقاط بازرسی (مثلاً «بین گام ۶ و ۷، برنامه از X به Y تغییر کرد») باعث می‌شود رفتارهای نادرست بهتر از متن‌های خام ردیابی شوند.

استفاده از چارچوب‌های اجرای بادوام (مانند Temporal) در اینجا بسیار مناسب است، زیرا یک عامل در واقع یک جریان‌کاری است که گام بعدی آن در زمان اجرا انتخاب می‌شود. تیم‌هایی که این زیرساخت را دارند باید از آن استفاده کنند تا دوباره چرخِ مکانیسم نقاط بازرسی را در کد برنامه اختراع نکنند.

الگوی ۵: حلقهٔ منتقد (The Critic Loop)

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

با این حال، منتقدها باید با احتیاط استفاده شوند به دلیل دو نکته:
۱. راستی‌آزمایی (Verifiability): منتقدها جایی جواب می‌دهند که بررسی راحت‌تر از انجام باشد. در تسک‌های قضاوت باز (مثلاً «آیا این تحلیل بصیرت‌بخش است؟»)، نتیجه «تئاتر منتقد» است؛ جایی که دو مدل با اطمینان کامل، خطاهای همبسته یکسانی را تایید می‌کنند. تا حد امکان از اعتبارسنج‌های قطعی استفاده کنید چون ارزان‌تر و قابل‌اعتمادتر هستند.
۲. سقف تکرار (Iteration Caps): حلقه را به یک دور محدود کنید. چرخه «تولید-نقد-اصلاح» در یک تکرار همگرا می‌شود؛ تکرارهای بیشتر اغلب منجر به نوسان می‌شود، جایی که اصلاح جدید، اصلاحات قبلی را خراب می‌کند و این فقط باعث مصرف توکن‌ها می‌شود. خود-اصلاحی‌های چند مرحله‌ای که در دموها دیده می‌شود، عمدتاً سوزاندن توکن است.

الگوی ۶: گیت‌های انسانی (Human Gates)

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

• گیت در پیامد، نه در گام: تایید یک مجموعه اقدام پیشنهادی کامل («این ۳ ایمیل را بفرست و این ۲ تیکت را ثبت کن») بهتر از ۵ تایید ریز و متوالی است. این کار هم از بازدهی سیستم و هم از کیفیت توجه بازبین محافظت می‌کند.
• خروجی‌های تفاضلی (Diff-Shaped Artifacts): انسان‌ها وقتی ببینند «چه چیزی تغییر می‌کند» (گیرندگان، مبالغ، وضعیت قبل و بعد) بهتر تایید می‌کنند، نه وقتی با کوهی از استدلال‌های مدل مواجه شوند. نمای نمایش را مانند یک Code Review طراحی کنید.
• استقلال تدریجی (Graduated Autonomy): گیت‌ها را بر اساس اعتماد لایه‌بندی کنید. عامل‌های جدید همه چیز در سطح ۲ به بالا را گیت دارند. با انباشت عملکرد، دایره تایید خودکار برای اقدامات کم‌ریسک گسترش می‌یابد و توسط نمونه‌برداری‌های نظارتی مانیتور می‌شود.
• مدیریت SLA: تاییدهای در صف باید دارای SLA، یادآورها و مسیرهای ارجاع باشند، وگرنه بازدهی سیستم به بازه زمانی توجه یک بازبین حواس‌پرت محدود می‌شود.

ضدالگوها: تالار شهر دمو-افزارها

برخی ساختارها پیش‌بینی‌کننده شکست در تولید هستند:

• سرمایه‌های خود-تفویضی (The Self-Delegating Swarm): عامل‌هایی که عامل‌های دیگر می‌سازند. این کار هر حالت شکست را در تعداد عامل‌ها ضرب می‌کند و سربار هماهنگی را افزایش می‌دهد. جایگزین حرفه‌ای آن، یک اسکلت جریان‌کاری با مراحل موازی است.
• حلقهٔ زمینهٔ خدای‌گونه (The God-Context Loop): اضافه کردن هر مشاهده به یک پنجره متنی در حال رشد تا جایی که مدل در تاریخچه خودش غرق شود. راه حل، وضعیت ثبت شده در نقاط بازرسی همراه با حافظه خلاصه شده است.
• ایمنی مبتنی بر پرامپت (Prompt-Enforced Safety): هر جمله‌ای که با «به مدل دستور داده شده که...» شروع شود و به عنوان یک کنترل ارائه شود. این یک مکانیسم ایمنی نیست، بلکه یک آرزوست.
• متریک دمو (The Demo Metric): گزارش اینکه «تسک را در تست‌های ما به پایان رساند» بدون ذکر مخرج کسر. عامل‌های عملیاتی به نرخ تکمیل (Completion Rate)، نرخ مداخله (Intervention Rate) و هزینه به ازای هر تسک تکمیل شده بر روی ترافیک واقعی نیاز دارند.

نمونهٔ مرجع: عامل عملیات پشتیبانی

یک عامل حل مشکل حساب کاربری را تصور کنید تا ببینید این الگوها چگونه ترکیب می‌شوند:

• اسکلت: چهار مرحله (تریاژ $
  ightarrow$ بررسی $
  ightarrow$ پیشنهاد $
  ightarrow$ اجرا) که هر کدام تحت یک LoopBudget هستند.
• سطوح: مرحله بررسی دسترسی سطح ۰ می‌گیرد؛ پیشنهاد یک پیش‌نویس سطح ۱ می‌سازد؛ اجرا از اعتبارنامه‌های محدود شده سطح ۲ استفاده می‌کند و بازپرداخت‌ها و بستن حساب‌ها پشت یک گیت انسانی سطح ۳ قرار می‌گیرند که به صورت Diff نمایش داده می‌شوند.
• وضعیت: ثبت نقاط بازرسی در هر مرز در یک ذخیره‌ساز بادوام؛ گیت‌های انسانی نقاط بازرسی متوقف شده با SLA چهار ساعته هستند.
• اعتبارسنجی: یک دور نقد برای بررسی پیشنهاد در برابر وضعیت حساب قبل از رسیدن به گیت انسانی.
• تله‌متری: ارسال نرخ تکمیل، نرخ مداخله، هزینه به ازای هر حل مشکل و توزیع تعداد گام‌ها.

تحلیل: مهندسی محدودیت

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

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

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

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

این الگوها مستقیماً در مورد عامل‌های کدنویسی صدق می‌کنند، که بهترین سناریو برای این معماری هستند. در کدنویسی، اعتبارسنجی ارزان است (کامپایل، تست، لینت)، محیط Sandbox به طور ساختاری یک محیط سطح ۱ فراهم می‌کند و PR به عنوان یک گیت انسانی در قالب Diff عمل می‌کند. به همین دلیل است که کدنویسی حوزه‌ای است که عامل‌ها امروز واقعاً در آن جواب می‌دهند.

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