August 4, 2026 — چرخه عمر توسعه Agent یا Agent Development Lifecycle حالا در Cloudflare عرضه شده و بحث جدیدی را در میان تیم‌های DevOps و SRE برانگیخته است 🤖

مدیران مهندسی سال‌ها تلاش کردند تا چندین برنامه‌نویس بتوانند همزمان و منظم روی یک کدبیس مشترک کار کنند. این کار ریشه در مدل‌های قدیمی مانند Systems Development Lifecycle (RAND, 1975) دارد که امروز معمولاً با عنوان Software Development Lifecycle یا SDLC شناخته می‌شود و مراحل زیر را تعریف می‌کند: Plan, Design, Implement, Test, Deploy, Maintain, Retire.

ورود AI وضعیت را تغییر داده است: بخشی که همیشه کند و پرهزینه بود — یعنی Implement — الآن سریع و ارزان شده است. این سرعت پیاده‌سازی، فشار زیادی به سایر مراحل SDLC وارد کرده؛ از نگهدارنده‌های open-source که با هزاران pull request و issue بمباران می‌شوند تا مهندسان تولید که مجبورند با افزایش ناگهانی نرخ تحویل نرم‌افزار، پایداری را حفظ کنند. نتیجه: افزایش toil، صفحات هشدار بیشتر و ریسک واقعی برای Reliability و Customer Experience 🔧.

پاسخ معقول — که شاید در نگاه اول پارادوکسیکال به نظر برسد — این است که به Agents مسئولیت‌های بیشتری بدهیم، اما با چارچوب و کنترل مناسب. واقعیت این است که بسیاری از شرکت‌ها الان عملاً اجازه می‌دهند یک agent کد بنویسد، منتظر شوند دیگران آن را validate، merge و deploy کنند و حتی انتظار داشته باشند کسی دیگر pager را در production نگه دارد؛ چیزی که ما هرگز برای یک مهندس واقعی نمی‌پذیریم.

برای تیم‌های DevOps و SRE توصیه‌های عملی‌تر این است که یک Agent Development Lifecycle تعریف کنید که دقیقاً مثل SDLC، مراحل و مسئولیت‌ها را مشخص کند اما متناسب با خصیصه‌های agents باشد. محورهایی که باید پوشش داده شوند شامل موارد زیر است:

– تعریف دقیق اختیارها و محدوده‌های توانایی agent (least privilege، RBAC).
– طراحی تست‌های خودکار برای behavior و safety (unit prompts, integration tests, adversarial tests).
– پیاده‌سازی پیپ‌لاین CI/CD برای agents: review، automated tests، canary deploys و rollout strategies.
– مانیتورینگ و observability: metrics، traces و structured logs مخصوص تعاملات agent و ابزارها/APIهایی که صدا می‌زند.
– کنترل هزینه و rate limiting برای تماس‌های مدل و سرویس‌های خارجی؛ تعیین quotas و circuit breakers.
– امنیت و auditability: audit logs، change history، signing و provenance برای اقدامات agent.
– runbooks و on-call: تعریف واضح چه موقع انسان باید وارد عمل شود و چگونه incidentها triage شوند.
– بازنشستگی و نسخه‌گذاری: policy برای deprecate و retire کردن agentها و data retention.

به طور خاص، از منظر SRE باید روی این‌ها متمرکز شد: سطح سرویس (SLO/SLI) برای خروجی‌هایی که agent تولید می‌کند، تست‌های end-to-end که شامل flowsی که agent راه می‌اندازد شوند، و تمرین‌های Chaos/Failure Injection روی agentها تا ببینیم هنگام نارسایی یا رفتار غیرمنتظره چه اتفاقی می‌افتد. همچنین لازم است که pipelineهای observability طوری طراحی شوند که بتوان منشأ خطا را به راحتی به یک agent یا یک prompt خاص ردیابی کرد.

در عمل، معنی این‌ها این است که قبل از اینکه به agents «اجازه بدهیم همه کارها را انجام دهند»، باید ابزارها و فرایندهایی بسازیم که تضمین دهند رفتار آنها قابل پیش‌بینی، امن و قابل بازیابی است. این شامل automated approvals، scoped credentials، synthetic testing، و alerting دقیق برای تغییرات غیرعادی در رفتار agentها می‌شود.

خلاصه اینکه: agents می‌توانند بار انسانی تیم‌ها را کم کنند و سرعت توسعه را حفظ کنند، اما این فقط زمانی درست است که ما lifecycle مخصوص به آنها را طراحی کنیم — شامل governance، testing، observability، و مسئولیت‌پذیری. اگر این موارد رعایت شود، می‌توانیم از مزایای AI بهره ببریم بدون اینکه Reliability و امنیت را به خطر بیندازیم 🙂.