‏ایجنت‌های مدیریت‌شدهٔ Claude برای پروداکشن

این پست از تیم Applied AI آنتروپیک می‌گه چیزی که یه نمونهٔ اولیه رو از یه ایجنت واقعیِ پروداکشن جدا می‌کنه، پرامپت خوب نیست؛ زیرساخته. یه ایجنت برای اجرا توی محیط واقعی به جایی برای اجرای کدش، دسترسی امن به داده‌ها، نشست‌های قابل‌مشاهده و زیرساختی که با حجم کار بزرگ بشه نیاز داره. نویسنده‌ها می‌گن تیم‌ها معمولاً کلی وقتشون رو سر امنیت، مدیریت state و تنظیم هارنس هدر می‌دن.

مقاله یه مرور تاریخی می‌کنه: اول API ساده بود (توکن می‌دادی، توکن می‌گرفتی)، بعد Claude Code اومد که همون حلقهٔ ایجنت و مدیریت context رو داشت، و بعد Claude Agent SDK که اجازه می‌داد روی همون ماشین Claude Code ایجنت بسازی. ولی به گفتهٔ نویسنده، حتی با یه هارنس آماده هم بردن ایجنت به پروداکشن سخت بود؛ چون هاستینگ، مدیریت نشست، فایل‌سیستم، ایزوله کردن اجرا، رمزها و مشاهده‌پذیری (observability) همه باید حل می‌شدن.

نکتهٔ فنی اصلی اینه که خیلی از هارنس‌ها داخل همون کانتینری اجرا می‌شن که فایل‌سیستم توشه. این یعنی کانتینر باید اول بالا بیاد (هزینهٔ زمانی داره)، کد اجراشونده درست کنار رمزهای شماست، و وقتی کانتینر بمیره کل اجرا هم می‌میره. راه‌حل Managed Agents جدا کردن «مغز از دست‌ها»ست: هارنسی که Claude رو صدا می‌زنه جدا از سندباکسی که کد اجرا می‌شه اجرا می‌شه، و یه نشست (یه لاگ append-only از هر فراخوانی مدل، ابزار و نتیجه) این دو رو به هم وصل می‌کنه.

سرویس حول سه منبع اصلی ساخته شده: agent (پیکربندی شامل مدل، پرامپت، ابزارها و گاردریل‌ها)، environment (محیط اجرا یعنی کانتینر سندباکس، قوانین شبکه و پکیج‌های نصب‌شده) و session (هر اجرا که یه agent رو با یه environment جفت می‌کنه و سندباکس ایزولهٔ خودش رو داره). چون نشست‌ها کل تاریخچه و state رو سمت سرور نگه می‌دارن، کارهای طولانی می‌تونن مکث کنن، تمیز ادامه پیدا کنن و قدم‌به‌قدم ردگیری بشن.

نویسنده‌ها چند دلیل اصلی برای استفاده می‌شمرن. اول امنیت: رمزها کلاً بیرون سندباکس می‌مونن و توی یه vault جدا با رمزنگاری envelope ذخیره می‌شن، پس یه prompt injection نمی‌تونه توکن رو لو بده. دوم سرعت: چون Claude بلافاصله شروع به فکر می‌کنه و کانتینر موازی بالا میاد (و نشست‌هایی که ابزار اجرا نمی‌کنن اصلاً کانتینر نمی‌خوان)، طبق تست‌هاشون زمان تا اولین توکن حدود ۶۰٪ توی حالت میانه و بالای ۹۰٪ توی بدترین حالت‌ها کم شده.

سوم، نشست‌های پایدار: به جای request/response، همه‌چیز بر پایهٔ رویداده، پس آپدیت بلادرنگ می‌گیری و هر نشست رو بعداً می‌تونی از سر بگیری بدون دیتابیس یا save-point. همین دوام نشست، قابلیت‌هایی مثل Memory و Dreaming رو ممکن می‌کنه؛ Dreaming یه فرایند زمان‌بندی‌شده‌ست که نشست‌ها رو مرور می‌کنه، الگوها رو درمیاره و حافظه رو پالایش می‌کنه تا ایجنت از اشتباهات تکراری یاد بگیره. چهارم انعطاف میزبانی: می‌تونی همه‌چیز رو به ابر آنتروپیک بسپری یا با self-hosted sandbox و MCP tunnel اجرای کد و مسیر دسترسی رو داخل مرز خودت نگه داری.

مقاله می‌گه شرکت‌هایی مثل Notion، Rakuten، Sentry، Asana و Atlassian همین حالا روی Managed Agents ایجنت پروداکشن دارن؛ مثلاً Notion می‌گه یه نمونهٔ اولیه حدود دوازده ساعت کار رو به بیست دقیقه رسونده. حرف پایانی نویسنده اینه که حالا وقت تیم‌ها به جای زیرساخت، صرف چیزی می‌شه که محصولشون رو متمایز می‌کنه: مدیریت context و تخصص دامنه؛ و موقع اومدن مدل جدید، فقط مدل رو عوض می‌کنی و eval رو دوباره اجرا می‌کنی بدون دست زدن به معماری.

نکات کلیدی:

• Claude Managed Agents هم هارنس تنظیم‌شدهٔ ایجنت رو می‌ده و هم زیرساخت پروداکشن (سندباکس، نشست، رمز، مشاهده‌پذیری).
• ایدهٔ مرکزی: جدا کردن «مغز» (هارنسی که مدل رو صدا می‌زنه) از «دست‌ها» (سندباکس اجرای کد)، با یه نشست append-only که وصلشون می‌کنه.
• سه منبع اصلی: agent (پیکربندی)، environment (محیط اجرا) و session (هر اجرای ایزوله).
• رمزها بیرون سندباکس توی vault جدا با رمزنگاری envelope می‌مونن تا جلوی نشت با prompt injection گرفته بشه.
• طبق تست‌ها زمان تا اولین توکن حدود ۶۰٪ (p50) و بالای ۹۰٪ (p95) کم شده.
• گزینهٔ self-hosted sandbox و MCP tunnel اجازه می‌ده اجرای کد و دسترسی داخل مرز خودت بمونه.