سوییچ به معماری محلی؛ راهکار کاهش تأخیر در چرخه‌های تکرار عامل‌های هوش مصنوعی

اگر یک عامل هوش مصنوعی برای تکمیل یک وظیفه بین ۱۰ تا ۲۰ بار در یک حلقه تکرار شود، حتی یک تأخیر ۲۰۰ میلی‌ثانیه‌ای در هر فراخوانی، به ۲ تا ۴ ثانیه زمان تلف‌شده تبدیل می‌شود. این «کشندگی REST» باعث می‌شود عامل‌ها فارغ از قدرت مدل زیربنایی، کند و ناکارآمد به نظر برسند.

طبق گزارشی که در ۲۲ ژوئیه ۲۰۲۶ توسط dev.to منتشر شد، اکثر عامل‌های فعلی در یک چرخه تکراری گرفتارند: تصمیم به فراخوانی ابزار، ساخت یک بسته JSON، ارسال آن روی پروتکل HTTP و انتظار برای پاسخ از راه دور. این فرآیند یعنی عامل در هر گام باید با تحلیل DNS، دست‌دهی TLS و محدودیت‌های نرخ درخواست (Rate Limiting) دست‌وپنجه نرم کند. همان‌طور که در تحلیل قبلی ما درباره‌ی چالش‌های مدل‌های محلی در نظارت بر زیرساخت‌ها اشاره کردیم، اکنون لایه انتقال داده به اصلی‌ترین نقطه اصطکاک در جریان‌های کاری عامل‌محور تبدیل شده است. این ناکارآمدی در پیاده‌سازی‌ها دیده می‌شود؛ به‌طوری که برخی گزارش‌ها حاکی از آن است که ۷۱٪ از عامل‌های سازمانی فعلاً تنها پوششی برای چت‌بات‌ها هستند و هنوز به پتانسیل کامل خود نرسیده‌اند.

در یک چیدمان متداول REST، حلقهٔ اجرای عامل مدام توسط سربارهای زیرساختیe قطع می‌شود. هر بار فراخوانی ابزار، عامل را مجبور می‌کند با حالت‌های شکست احتمالی مثل مشکلات Connection Pooling یا انقضای توکن‌ها مواجه شود. این‌ها مسائلی نیستند که یک مدل استدلالی (Reasoning Model) — شبیه شطرنج‌بازی که چند حرکت جلوتر را می‌بیند تا بهترین مسیر را انتخاب کند — بخواهد حل کند، اما هزینه‌ای است که در هر گام پرداخت می‌شود.

وقتی یک عامل ۱۰ تا ۲۰ بار در یک حلقه می‌چرخد، این سربارها ضرب در تعداد تکرار شده و تأخیر را به‌صورت تصاعدی افزایش می‌دهند. این وضعیت را تبدیل به شکافی عمیق بین «مسیر ایده‌آل» و واقعیت می‌کند؛ جایی که تلاش‌های مجدد (Retries) و خطاهای ۴۲۹ تجربه کاربری را بیش از پیش تخریب می‌کنند.

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

جزئیات این معماری محلی-محور (Local-First) به شرح زیر است:

• آداپتور محلی (Local Adapter): یک فرآیند نظارت‌شده که ورودی و خروجی را به صورت JSON مدیریت می‌کند و بک‌‌اند راه دور را برای عامل انتزاع می‌کند.
• ارتباط IPC: استفاده از ارتباط بین-فرآیندی (Inter-Process Communication) به جای پشتهٔ HTTP که نیاز به DNS یا دست‌دهی TLS در هر فراخوانی را حذف می‌کند.
• مدیریت اتصالات: آداپتور اتصالات گرم (Warm Connections) را با بک‌‌اندها حفظ می‌کند، در حالی که عامل بدون وضعیت (Stateless) باقی می‌ماند. احراز هویت فقط یک بار در شروع کار انجام می‌شود.
• رابط ساده شده: عامل پیام را می‌فرستد و آداپتور آن را به صورت هم‌گام یا ناهم‌گام پردازش کرده و نتیجه را با همان فرمت بازمی‌گرداند.

پروتکل Pilot Protocol نمونه‌ای پیشرو در این معماری است. فروشگاه اپلیکیشن آن به عامل‌ها اجازه می‌دهد ابزارهایی مثل AEGIS برای امنیت زمان اجرا، cosift برای جست‌وجوی مبنی-سازی شده و plainweb برای استخراج صفحات را نصب کنند. این ابزارها به صورت سرویس‌های IPC محلی اجرا می‌شوند و عامل می‌تواند متدهای خاص را با فرمت <app>.<method> '{...}' فراخوانی کند، بدون اینکه نیاز باشد URL بسازد یا عملیات fetch انجام دهد.

در جریان‌های کاری که عامل ۵ تا ۱۵ بار در هر تسک ابزار فراخوانی می‌کند (مثلاً توالی جست‌وجو، پرس‌وجو، بازیابی، تحلیل و نوشتن)، این صرفه‌جویی‌ها جزئی نیستند. در روش REST، هر تکرار یک «راه‌اندازی سرد» (Cold Start) برای ابزار است، اما در روش آداپتور محلی، فرآیند بین فراخوانی‌ها زنده می‌ماند.

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

فراتر از سرعت، این مدل امنیت را نیز تغییر می‌دهد. در مدل REST، عامل معمولاً یک توکن Bearer حمل می‌کند که دسترسی به کل سطح API را می‌دهد و در صورت نشت، کل سیستم در معرض خطر است. در معماری آداپتور محلی، دسترسی‌ها در زمان نصب محدود (Scoped) می‌شوند. آداپتور اعتبارنامه‌ها را نگه می‌دارد و عامل فقط متدهایی را می‌بیند که صراحتاً به او اجازه داده شده است. یک عامل هک‌شده نمی‌تواند ابزارهایی را فراخوانی کند که دسترسی به آن‌ها را ندارد، چون اصلاً اعتبارنامه‌های بک‌‌اند را در اختیار ندارد. در این راستا، رویکردهای پیشرفته‌تری نظیر استفاده از «دفاع هدف متحرک» در کلاسترهای عامل‌محور برای مقابله با تزریق پرامپت نیز برای ارتقای لایه‌های امنیتی مورد توجه قرار گرفته‌اند.

Pilot Protocol این امنیت را با استفاده از مجوزهای محدود به دامنه و امضای Ed25519 تقویت کرده است تا مطمئن شود هیچ «اتوریته محیطی» (Ambient Authority) وجود ندارد.

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

با این حال برای توسعه‌دهندگانی که عامل‌ها را در محیط‌های کنترل‌شده مثل کانتینرها، ماشین‌های مجازی یا لپ‌تاپ‌ها اجرا می‌کنند، این معامله به‌صرفه است. کاهش زمان انتقال داده یعنی زمان بیشتر برای استدلال. وقتی صحبت از ۵ تا ۱۵ فراخوانی ابزار در هر تسک باشد، جایگزینی REST با IPC محلی، مرز بین یک تجربه کاربری شکسته و یک زنجیره ابزار سریع است.

گام بعدی شما

• اگر روی عامل‌های خودکار کار می‌کنید، معماری IPC را برای ابزارهای پرتکرار جایگزین REST کنید.
• پروتکل Pilot Protocol را برای مدیریت متمرکز دسترسی‌های ابزاری بررسی کنید.
• تأخیر (Latency) هر یک از گام‌های حلقهٔ عامل خود را اندازه‌گیری کنید تا نقاط گلوگاهی را شناسایی نمایید.

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