۳ لایهٔ کلیدی در مدیریت حلقهٔ اجرای عامل‌های هوش مصنوعی

اگر در حال طراحی یک عامل هوشمند هستید، اشتباه در انتخاب لایه‌ی مدیریت وضعیت (State) می‌تواند منجر به فاجعه‌ای چون دسترسی بدون محدودیت ابزارهای ناشناس به سیستم‌عامل شود. تصمیم درباره اینکه چه کسی «حلقهٔ اجرا» (Execution Loop) را در اختیار دارد، دیگر یک ترجیح شخصی نیست، بلکه یک تصمیم حیاتی در معماری سیستم است. جابه‌جایی این مسئولیت‌ها ریسک‌های سیستماتیکی ایجاد می‌کند؛ از دست دادن وضعیت جلسه در هنگام کرش کردن سیستم گرفته تا اعطای دسترسی‌های غیرمحدود به ابزارهای غیرقابل اعتماد.

این تفکیک معماری در حالی رخ می‌دهد که صنعت از چت‌بات‌های ساده به سمت عامل‌های خودمختاری حرکت می‌کند که قادر به مدیریت کدهای میلیونی هستند. همان‌طور که در تحلیل قبلی ما درباره‌ی چارچوب «شناسایی عامل» (Know-Your-Agent) شرکت‌های ویزا و مسترکارت اشاره کردیم، تمرکز پیشین بر لایه‌ی هویت و پرداخت بود؛ اما اکنون چالش فنی به لایه‌ی زمان اجرا (Runtime) منتقل شده است: اینکه یک عامل چگونه بدون شکست، وظایف را اجرا کند. سؤال مرکزی برای معماران این است: کدام لایه مالک حلقهٔ اجرا، وضعیت، انتقال ابزار، مجوزها و بازیابی است؟

هارنس عامل: زمان اجرای سخت‌گیرانه

یک هارنس عامل (Agent Harness) در واقع سیستم اجرایی است که یک مدل را در بر می‌گیرد تا یک عامل کاربردی بسازد. هارنس‌ها بسیار «سخت‌گیر» (Opinionated) هستند و یک حلقهٔ اجرای ثابت، مدل دسترسی و یک محیط ایزوله (Sandbox) را به عنوان یک واحد یکپارچه ارائه می‌دهند تا مدل خام را به یک عامل آماده برای محیط تولید تبدیل کنند.

به نقل از پست ۱۹ اوت ۲۰۲۶، پلتفرم Codex شرکت OpenAI از هارنس برای مدیریت وضعیت گفتگو، استریم اجرا و اعمال سیاست‌های تأیید استفاده می‌کند. به همین ترتیب، Claude Code شرکت Anthropic از یک هارنس عامل‌محور برای مدیریت زمینه و اجرای ابزارها بهره می‌برد. SDK عامل کلود دقیقاً همان ابزارها، حلقهٔ اجرا و مدیریت زمینه‌ای را در اختیار توسعه‌دهنده قرار می‌دهد که در Claude Code به کار رفته است.

در یک هارنس، شما اجازه بازنویسی حلقهٔ اجرا را ندارید. برای مثال، Claude Agent SDK یک چرخهٔ سخت‌گیرانه پنج‌مرحله‌ای را دنبال می‌کند: دریافت پرامپت، ارزیابی و پاسخ، اجرای ابزارها، تکرار و در نهایت بازگرداندن نتیجه. هر چرخه کامل، یک «نوبت» (Turn) محسوب می‌شود. این حلقه تنها زمانی پایان می‌یابد که مدل پاسخی بدون فراخوانی ابزار تولید کند. اگرچه قلاب‌ها (Hooks) می‌توانند فراخوانی ابزارها را رهگیری یا مسدود کنند، اما هستهٔ حلقه ثابت می‌ماند. هارنس Codex شرکت OpenAI نیز حلقهٔ خود را از طریق app-server در دسترس قرار می‌دهد؛ یک پروتکل کلاینت مستند که در آن برنامه‌ها رشته‌ها (Threads) را ایجاد کرده، نوبت‌ها را شروع می‌کنند و درخواست‌های تأیید را مدیریت می‌کنند.

فریم‌ورک عامل: کتابخانه ترکیب‌پذیر

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

نمونه‌های بارز این لایه شامل LangGraph، OpenAI Agents SDK و Microsoft Agent Framework است که مورد اخیر در آوریل ۲۰۲۶ به نسخه ۱.۰ GA رسید. در این مدل، شما قطعات را دریافت می‌کنید اما باید شرایط پایان، جابه‌جایی بین عامل‌ها (Handoffs) و سقف تعداد دفعات اجرا (Turn Caps) را پیکربندی کنید.

در LangGraph، حلقهٔ اجرا توسط گرافی که شما رسم می‌کنید تعریف می‌شود؛ گره‌ها، یال‌ها و مسیریابی‌های شرطی هستند که جریان کنترل را دیکته می‌کنند. در OpenAI Agents SDK، حلقه در خروجی نهایی متوقف می‌شود اما در صورت جابه‌جایی (Handoff) دوباره اجرا می‌گردد. در اینجا مدیریت محدودیت‌ها با توسعه‌دهنده است؛ برای مثال عبور از max_turns خطای MaxTurnsExceeded را ایجاد می‌کند و فعال شدن یک تلهٔ حفاظتی، خطای GuardrailTripwireTriggered را برمی‌انگیزد.

MCP: پروتکل بی‌وضعیت انتقال داده

پروتکل زمینهٔ مدل (Model Context Protocol یا MCP) یک زمان اجرا نیست، بلکه یک پروتکل انتقال (Wire Protocol) است. MCP استاندارد می‌کند که چگونه یک برنامه (میزبان) قابلیت‌های ارائه شده توسط سرورها را شناسایی و فراخوانی کند. این پروتکل مالک قرارداد بین عامل و ابزارهاست، اما هیچ حلقهٔ اجرا یا وضعیتی را مدیریت نمی‌کند. برای بهینه‌سازی این تعاملات، تفکیک مهارت‌های عامل از سرورهای MCP راهکاری کلیدی برای مدیریت بهینه پنجرهٔ زمینه ارائه می‌دهد.

بر اساس مستندات بنیاد Linux Foundation، از دسامبر ۲۰۲۵، بنیاد هوش مصنوعی عامل‌محور (Agentic AI Foundation) مدیریت MCP را در کنار پروژه‌هایی چون goose، AGENTS.md و A2A بر عهده گرفته است. نکته کلیدی این است که در مشخصات ۲۸ جولای ۲۰۲۶، هستهٔ این پروتکل «بی‌وضعیت» (Stateless) شد. تبادلات initialize/initialized و هدر Mcp-Session-Id بازنشسته شدند و هر درخواست اکنون به صورت مستقل با نسخه پروتکل و قابلیت‌های کلاینت در بخش _meta منتقل می‌شود.

پروتکل MCP سه جزء اولیه در سمت سرور تعریف می‌کند:

• ابزارها (Tools): توابعی که مدل اجرا می‌کند.
• منابع (Resources): داده‌ها و زمینه (Context).
• پرامپت‌ها (Prompts): گردش‌کارهای قالب‌بندی شده.

انتقال داده‌ها از طریق JSON-RPC 2.0 روی stdio یا HTTP قابل استریم انجام می‌شود. بازبینی ۲۸ جولای ۲۰۲۶، استفاده از هدرهای Mcp-Method و Mcp-Name را در درخواست‌های HTTP اجباری کرد تا گیت‌وی‌ها و محدودکننده‌های نرخ (Rate Limiters) بتوانند ترافیک را بدون تجزیهٔ بدنه (Body) مسیریابی کنند. همچنین پاسخ‌های tools/list با استفاده از ttlMs و cacheScope قابل کش (Cacheable) شدند و انتقال قدیمی HTTP+SSE با یک مهلت ۱۲ ماهه بازنشسته شد.

ماتریس مالکیت لایه‌ها

برای درک دقیق این شکاف، باید ببینیم چه کسی رفتار را تعریف و اجرا می‌کند و چه کسی صرفاً یک قلاب (Hook) ارائه می‌دهد:

• حلقهٔ اجرا: هارنس مالک یک حلقهٔ ثابت و صنعتی با محدودیت نوبت و فشرده‌سازی است؛ فریم‌ورک اسکلت را می‌دهد و شما پایان و جابه‌جایی‌ها را پیکربندی می‌کنید؛ MCP هیچ حلقه‌ای ندارد و فقط درخواست/پاسخ است.
• وضعیت و حافظه: هارنس مالک جلسات، بازگشت (Resume)، انشعاب (Fork) و نقاط بازرسی فایل است؛ فریم‌ورک ابزارهای ذخیره‌سازی (Checkpointers)، ذخیره‌گاه‌های جلسه و ID رشته‌ها را ارائه می‌دهد؛ MCP از ۲۸ جولای ۲۰۲۶ در سطح پروتکل کاملاً بی‌وضعیت است.
• انتقال ابزار: هارنس ابزارهای داخلی به علاوه کلاینت‌های MCP را مصرف می‌کند؛ فریم‌ورک ابزارهای تابعی به علاوه کلاینت‌های MCP را مصرف می‌کند؛ MCP مالک خودِ پروتکل انتقال (JSON-RPC) روی stdio یا HTTP است.
• دسترسی‌ها: هارنس مالک حالت‌های دسترسی، قلاب‌ها و محیط ایزوله (Sandbox) است؛ فریم‌ورک حفاظ‌ها (Guardrails)، وقفه‌ها (Interrupts) و میان‌افزارها را ارائه می‌دهد؛ MCP امنیت را به میزبان واگذار می‌کند و نمی‌تواند در سطح پروتکل آن را اجبار کند.
• بازیابی و ایزولاسیون: هارنس مالک بازگشت جلسه، بازگشت به نقاط بازرسی، سندباکس‌های OS و درخت‌های کاری (Worktrees) است؛ فریم‌ورک اجرای پایدار و بازپخش (Replay) را ارائه می‌دهد و سندباکس در آن اختیاری است؛ MCP بازیابی جزئی را از طریق افزونه Tasks برای فراخوانی‌های طولانی فراهم می‌کند.

وضعیت، حافظه و پایداری

مالکیت وضعیت تعیین می‌کند که آیا یک عامل پس از کرش کردن زنده می‌ماند یا خیر. در یک هارنس، وضعیت در طول جلسات پایدار می‌ماند. Claude Agent SDK از جلساتی پشتیبانی می‌کند که قابل بازگشت یا انشعاب (Fork) هستند. قابلیت نقاط بازرسی فایل (File Checkpointing) اجازه می‌دهد فایل‌ها به هر وضعیت قبلی بازگردانده شوند. هارنس مایکروسافت یک FileMemoryProvider برای یادداشت‌های محدودهٔ جلسه و فشرده‌سازی خودکار زمینه (Context Compaction) ارائه می‌دهد تا مصرف توکن‌ها در میان حلقه کنترل شود. کارهای پیشرفته‌تر Anthropic در زمینه هارنس‌های طولانی‌مدت، وضعیت را با استفاده از آرتیفکت‌های روی دیسک بین پنجره‌های زمینه جابه‌جا می‌کند.

فریم‌ورک‌ها ابزارهای وضعیت را ارائه می‌دهند اما سیاست پایداری را به توسعه‌دهنده می‌سپارند. در LangGraph، اجرای پایدار نیازمند اتصال یک checkpointer و ارسال ID رشته است. این فریم‌ورک سه حالت پایداری ارائه می‌دهد: exit (فقط هنگام خروج از گراف ذخیره می‌کند)، async (در طول گام بعدی می‌نویسد) و sync (قبل از هر گام می‌نویسد). انتخاب اشتباه بین این حالت‌ها می‌تواند منجر به از دست رفتن وضعیت در هنگام کرش شود.

در مقابل، MCP صراحتاً بی‌وضعیت است. راهنمای ۲۸ جولای ۲۰۲۶ تصریح می‌کند که اگر سروری به وضعیت در طول فراخوانی‌ها نیاز دارد، باید یک «دستگیره» (Handle) از طریق یک ابزار ایجاد کند و مدل آن را در درخواست بعدی به عنوان یک آرگومان بازگرداند. وضعیت، مشکل عامل است، نه پروتکل.

شکاف امنیتی و دسترسی‌ها

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

Claude Code شش حالت دسترسی را پیاده کرده است: default ،acceptEdits ،plan ،auto ،dontAsk و bypassPermissions. حالت auto فراخوانی‌ها را از طریق یک طبقه‌بندی‌کننده پس‌زمینه هدایت می‌کند، در حالی که bypassPermissions کل این لایه را نادیده می‌گیرد. قلاب‌ها اجازه می‌دهند منطق سفارشی در نقاط PreToolUse و PermissionRequest اعمال شود. هارنس Codex شرکت OpenAI نیز به طور مشابه، نوبت‌ها را متوقف می‌کند تا درخواست‌های تأیید را صادر کند که کلاینت باید به آن‌ها پاسخ دهد.

فریم‌ورک‌ها قلاب را می‌دهند، نه سیاست را. OpenAI Agents SDK از حفاظ‌های ورودی، خروجی و ابزار استفاده می‌کند. در LangGraph، از interrupt() داخل یک گره برای توقف جهت تأیید و از Command(resume=...) برای ادامه استفاده می‌شود. Microsoft Agent Framework یک میان‌افزار ToolApprovalAgent با قوانین «دیگر نپرس» اضافه می‌کند. در تمام این موارد، ساخت رابط کاربری و منطق تأیید بر عهده توسعه‌دهنده است.

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

جایی که هارنس‌ها ارزش خود را ثابت می‌کنند، در بازیابی (Recovery) است. Claude Agent SDK می‌تواند جلسات را از سر بگیرد و تغییرات فایل را به عقب برگرداند. گردش‌کارهای پویا در Claude Code دقیقاً از همان جایی که ترمینال بسته شده بود، ادامه می‌یابند.

این انضباط منجر به نتایج قابل اندازه‌گیری شده است. OpenAI در فوریه ۲۰۲۶ گزارش داد که هارنس Codex امکان تولید حدود ۱,۵۰۰ Pull Request ادغام شده را در پنج ماه در مخزنی با ۱ میلیون خط کد فراهم کرد. تیم توسعه از ۳ به ۷ مهندس افزایش یافت و هر مهندس به‌طور متوسط ۳.۵ PR در روز ثبت کرد.

علاوه بر این، طراحی هارنس مستقیماً بر بنچمارک‌ها اثر می‌گذارد. در تست ARC-AGI-3، حفظ استدلال و فشرده‌سازی زمینه، نرخ موفقیت GPT-5.6 Sol را از ۱۳.۳٪ به ۳۸.۳٪ رساند و هم‌زمان توکن‌های خروجی را ۶ برابر کاهش داد. همین مدل بسته به هارنس مورد استفاده، امتیازات بسیار متفاوتی کسب کرد.

همگرایی پشتهٔ فناوری

مرزها در حال محو شدن هستند. Microsoft Agent Framework اکنون یک لایه «هارنس عامل» ارائه می‌دهد که هر کلاینت چتی را با یک فراخوانی متد به یک هارنس کامل تبدیل می‌کند. این لایه شامل فشرده‌سازی زمینه، حافظه فایل، یک ارائه‌دهنده لیست کارهای (Todo) و حالت‌های «برنامه‌ریزی در مقابل اجرا» و همچنین زیر-عامل‌های پس‌زمینه و یک اجراکننده شل ایزوله است. مایکروسافت این لایه را جایی توصیف می‌کند که «استدلال مدل با اجرای واقعی ملاقات می‌کند».

هم‌زمان، هارنس‌ها در حال تبدیل شدن به پلتفرم هستند. OpenAI هارنس Codex را متن‌باز کرد و سه سطح دسترسی ارائه داد: codex exec برای کارهای محدود، Codex SDK برای کنترل برنامه‌نویسی شده و app-server برای جاسازی حلقه اجرا. DeepSeek نیز در ۱۳ اوت ۲۰۲۶، نسخه DeepSeek Harness v0.1 را تحت لایسنس MIT منتشر کرد و هر جزء، از جمله حلقهٔ اجرا را به صورت پلاگین در نظر گرفت. این رویکرد در تحلیل قابلیت‌های DeepSeek بررسی شده که نشان می‌دهد چگونه قابلیت‌های LLM به پلاگین‌هایی برای ساخت عامل‌های خودمختار تبدیل می‌شوند.

با این حال، MCP به عنوان زیرساخت مشترک باقی مانده است. پذیرش این پروتکل گسترده است و SDKهای تایپ‌اسکریپت و پایتون آن هر کدام از مرز ۱ میلیارد دانلود عبور کرده‌اند. در حالی که قابلیت‌هایی مانند Elicitation، درخواست‌های چند-مرحله‌ای (MRTR) و افزونه Tasks پروتکل را گسترش می‌دهند، نگهداران آن خط قرمزی کشیده‌اند: قابلیت‌های Roots، نمونه‌برداری (Sampling) و لاگ‌گذاری برای حفظ هستهٔ درخواست/پاسخ بازنشسته شده‌اند.

یک اصطلاح که با این‌ها هم‌پوشانی ندارد، A2A (Agent-to-Agent) است. در حالی که MCP یک عامل را به ابزارها متصل می‌کند، A2A یک پروتکل مجزا در بنیاد Agentic AI برای ارتباط بین دو عامل است.

خلاصه معماری

در یک پشته تولیدی مدرن، برنامه (Application) مالک قوانین کسب‌وکار، رکوردها و جریان‌های رضایت است. در لایه پایین‌تر، زمان اجرا یا یک فریم‌ورک (حلقه ترکیب‌پذیر) است یا یک هارنس (حلقه ثابت). فریم‌ورک گراف بیرونی را ارکستره می‌کند و هارنس گام‌های سنگین را در یک محیط ایزوله اجرا می‌کند. در نهایت، لایه انتقال MCP (JSON-RPC 2.0) است که به سرورهای قابلیت مانند GitHub، Figma، Supabase، Sentry یا Linear متصل می‌شود.

نمونه Relay شرکت OpenAI از همین ساختار پیروی می‌کند: برنامه مالک زمینه محصول است، در حالی که Codex app-server حلقهٔ عامل و اجرای ایزوله را فراهم می‌کند.

این رویکرد لایه‌ای از شکست «عامل یکپارچه» (Monolithic Agent) جلوگیری می‌کند. با جداسازی انتقال (MCP) از اجرا (Harness) و ارکستراسیون (Framework)، توسعه‌دهندگان می‌توانند مدل‌ها یا ابزارها را بدون بازنویسی کل ماشین وضعیت تعویض کنند. این تغییر، معیار اصلی میدان را از «هوش مدل» به «کارایی هارنس» تغییر می‌دهد. همان‌طور که در GPT-5.6 Sol دیدیم، اکنون «پوشش» (Wrapper) به اندازه «وزن‌های مدل» اهمیت دارد.

برای بهینه‌سازی پشته خود، ارزیابی کنید که آیا به کنترل جریان سفارشی نیاز دارید (فریم‌ورک) یا یک حلقهٔ ایزوله و اثبات‌شده (هارنس). صرف‌نظر از انتخاب، سطح ابزارهای خود را بر اساس MCP استاندارد کنید. هستهٔ بی‌وضعیت ۲۸ جولای ۲۰۲۶ به این معناست که یک سرور MCP راه دور اکنون یک بار کاری HTTP معمولی در پشت یک Load Balancer است. سطح ابزار را یک بار بسازید و در تمام زمان‌های اجرا (Runtimes) از آن استفاده کنید.

گام بعدی شما

• ارزیابی کنید که آیا برای پروژه خود به کنترل جریان سفارشی نیاز دارید (فریم‌ورک) یا یک حلقهٔ ایزوله و اثبات‌شده (هارنس).
• سطح ابزارهای خود را بر اساس استاندارد MCP یکپارچه کنید تا از وابستگی به یک Runtime خاص رها شوید.
• در صورت استفاده از فریم‌ورک، سیاست‌های پایداری (Durability Modes) را برای جلوگیری از دست رفتن وضعیت در هنگام کرش بررسی کنید.

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