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

اگر امروز یک عامل هوش مصنوعی را در محیط عملیاتی مستقر کرده‌اید، احتمالاً بخشی از خطاهای شما به دلیل «ناپایداری مدل» نیست، بلکه زیرساخت شما در حال کشتن فرآیندهای سالم است. یک پاد (Pod) در کوبرنتیز که در میانهٔ استدلال متوقف می‌شود، به‌ندرت دچار کرش شده است؛ در واقع این نتیجهٔ تنظیمات غلط یک Probe است. به نقل از گزارشی که در ۱۸ سپتامبر ۲۰۲۶ در dev.to منتشر شد، تیم‌های پلتفرم با برخورد با عامل‌های عامل‌محور (Agentic) به‌مثابه میکروسرویس‌های بدون وضعیت (Stateless)، در حال ایجاد یک حلقهٔ «شکست خاموش» هستند. در این وضعیت، زیرساخت فرآیندهایی را می‌کشد که صرفاً ۴۰ ثانیه زمان نیاز دارند تا یک ابزار را فراخوانی کنند.

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

شکل درخواست‌ها

برای درک این شکست، باید شکل درخواست‌ها را مقایسه کرد. یک میکروسرویس استاندارد مسیری خطی را دنبال می‌کند: کلاینت $\rightarrow$ سرویس $\rightarrow$ [جستجو در دیتابیس/کش] $\rightarrow$ پاسخ. این فرآیند با تأخیر محدود و یک واحد محاسباتی برای هر درخواست مشخص می‌شود.

اما درخواست یک عامل، یک زنجیره بازگشتی است: کلاینت $\rightarrow$ عامل $\rightarrow$ [استدلال] $\rightarrow$ فراخوانی ابزار ۱ $\rightarrow$ [استدلال] $\rightarrow$ فراخوانی ابزار ۲ $\rightarrow$ [استدلال] $\rightarrow$ فراخوانی ابزار N $\rightarrow$ [استدلال] $\rightarrow$ پاسخ. این ساختار باعث می‌شود مدت‌زمان پاسخ‌دهی و نیازهای محاسباتی به‌شدت متغیر باشد و به تعداد ابزارهای فراخوانی‌شده (Fan-out) و عمق استدلال بستگی داشته باشد.

تلهٔ پایش سلامت (Liveness Probe)

زیرساخت‌های سنتی فرض می‌کنند اگر فرآیندی در ۳۰ ثانیه به یک بررسی سلامت پاسخ ندهد، متوقف (Hung) شده است. اما برای یک عامل، بازهٔ ۳۰ تا ۹۰ ثانیه برای یک گام استدلالی پیچیده که شامل فراخوانی APIهای پایین‌دستی است، کاملاً طبیعی است.

به‌طور مشخص، اگر یک Probe با تنظیمات periodSeconds: 10 و failureThreshold: 3 باشد، پاد را در صورتی که /health در حدود ۳۰ ثانیه پاسخ ندهد، می‌کشد. وقتی یک Liveness Probe ساده پاد را در این بازه می‌کشد، خطا شبیه به یک نقص زیرساختی به نظر نمی‌رسد. در عوض، به شکل افزایش نرخ خطای مدل یا ناپایداری API ابزارها ظاهر می‌شود. در نتیجه، تیم‌ها هفته‌ها وقت خود را صرف تنظیم مجدد منطق تلاش مجدد (Retry) می‌کنند، در حالی که مشکل اصلی تنظیمات Probe است. این چالش‌ها در محیط‌های تست نیز تکرار می‌شوند و نشان می‌دهند که چرا استفاده از سرورهای واقعی به جای پاسخ‌های Mock برای شناسایی محدودیت‌های AI در مرحلهٔ Staging حیاتی است.

بازتعریف سلامت و آمادگی

برای حل این بحران، مهندسان باید «وجود فرآیند» را از «توانایی پذیرش کار جدید» تفکیک کنند. راهکار پیشنهادی استفاده از دو Probe مجزا است:

• پایش سلامت (Liveness Probe /health): فقط تأیید می‌کند که حلقهٔ رویداد (Event Loop) فعال است. این Probe باید از periodSeconds: 15 و timeoutSeconds: 5 با failureThreshold: 3 استفاده کند تا حدود ۴۵ ثانیه عدم پاسخ‌دهی واقعی را تحمل کند. این Probe هرگز نباید منتظر پاسخ یک فراخوانی ابزار در حال اجرا بماند.
• پایش آمادگی (Readiness Probe /ready): ظرفیت فعلی را نشان می‌دهد. با تنظیم periodSeconds: 5 و failureThreshold: 2 پادی که در میانهٔ استدلال است، می‌تواند گزارش دهد که برای کارهای جدید «آماده نیست»، بدون اینکه توسط ارکستراتور به‌عنوان یک فرآیند مرده شناسایی و حذف شود.

مشکل مقیاس‌دهی و وضعیت

مقیاس‌دهنده‌های افقی استاندارد (HPA) برای تعیین بار، CPU و حافظه را رصد می‌کنند. اما بارِ یک عامل به عمق استدلال و تعداد ابزارهای فراخوانی‌شده بستگی دارد. این باعث می‌شود HPAها به‌طور پیش‌بینی‌ناپذیری مقیاس شوند (بیش از حد یا کمتر از حد)، زیرا جهش‌های CPU به درخواست‌های پیچیده خاص گره خورده‌اند، نه لزوماً به حجم کلی ترافیک.

علاوه بر مقیاس‌دهی، مفاهیم مربوط به وضعیت و ایزولاسیون تغییر کرده‌اند:

• استقلال: در حالی که درخواست‌های میکروسرویس مستقل هستند، یک تسک عامل‌محور اغلب چندین رفت‌وبرگشت را شامل می‌شود که بستر (Context) مشترکی را حمل می‌کنند.
• ایزولاسیون: اعتبارنامه‌های ابزارها و بستر ممکن است مختص هر مستاجر (Tenant) باشد، به این معنی که مرزهای مسیریابی و ایزولاسیون باید معماری باشند، نه اتفاقی.
• تایم‌اوت‌ها: یک تایم‌اوت ۳۰ ثانیه‌ای ممکن است صرفاً به این معنا باشد که عامل هنوز در حال استدلال است. بودجه‌های تایم‌اوت باید برای هر زنجیره فراخوانی ابزار تنظیم شوند، نه برای هر درخواست کلی.

مدیریت وضعیت نیز تکامل یافته است. بازبینی جولای ۲۰۲۶ در پروتکل زمینهٔ مدل (MCP) جلسات (Sessions) در سطح پروتکل را حذف کرد. پیش از این، عامل‌ها برای حفظ انسجام گفتگو به جلسات پین‌شده و مسیریابی چسبنده (Sticky Routing) نیاز داشتند. اکنون وضعیت از طریق دستگیره‌های صریح (Explicit Handles) که به عنوان آرگومان پاس داده می‌شوند مدیریت می‌شود. این امر اجازه می‌دهد هر درخواست روی هر نمونه از سرور قرار گیرد و نیاز به ذخیره‌سازهای مشترک جلسه و راهکارهای مسیریابی چسبنده را از بین می‌برد.

دینامیک‌های عامل-به-عامل (A2A)

فراتر از استفاده از ابزارها، پروتکل A2A (Agent-to-Agent) در اوایل ۲۰۲۶ به نسخه ۱.۰ رسید. این موضوع لایه جدیدی از پیچیدگی زیرساختی را معرفی می‌کند. در حالی که MCP نحوه صحبت یک عامل با ابزارها و منابع داده را مدیریت می‌کند، A2A نحوه صحبت عامل‌ها با یکدیگر را کنترل می‌کند.

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

هزینه تنظیمات غلط

اشتباه در لایه زیرساخت به‌صورت خاموش انباشته می‌شود. یک مقیاس‌دهنده که روی سیگنال غلط تنظیم شده باشد، ممکن است به‌طور دائمی ۳۰٪ بیشتر از نیاز واقعی، کپی (Replica) اجرا کند. چون کرش شدیدی رخ نمی‌دهد، این ناکارآمدی برای تیم پلتفرم نامرئی می‌ماند.

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

گام بعدی شما

• بازبینی تنظیمات livenessProbe در فایل‌های YAML و افزایش failureThreshold برای جلوگیری از کشتن زودهنگام عامل‌ها.
• پیاده‌سازی /ready endpoint برای تفکیک وضعیت «در حال پردازش» از وضعیت «مرده».
• جایگزینی استراتژی‌های مقیاس‌دهی مبتنی بر CPU با متریک‌های سفارشی متناسب با عمق استدلال.

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