Cloudflare想把SDLC變成Agent工廠
Cloudflare提出 Agent Development Lifecycle（ADLC），想解決 AI 寫程式變快後，測試、部署與維護仍卡在人工作業的問題。核心不是再塞一個 coding agent，而是把 Workflows、@cloudflare/ci、Artifacts、預覽環境、Browser Run、Agent Traces 與權限系統串成軟體工廠。Agent可從事件出發，自動建置、測試、部署、追查錯誤，甚至派出 subagent 修正問題；不過「取代 SDLC」目前比較像方向宣言，既有開發階段並沒有真的消失。
現實應用
最適合的是 repo 數量多、服務標準化程度高的平台團隊，以及需要大量處理依賴更新、測試失敗、issue 分流和例行部署的開源維護者。每個 Agent可取得獨立 preview、執行 headless browser，並用 production telemetry 重播問題，不必共用一套 staging。SRE、DevOps 與資安團隊也用得上，因為 Agent Traces可記錄模型呼叫、工具執行及 token 消耗，而 Agent Access Model則以短效、任務綁定憑證和 Trust Ratchet逐步收窄權限。
期望評估
我認為低標是把 ADLC當成更有彈性的 CI/CD：自動安裝依賴、平行跑 lint、typecheck與測試，失敗時重試或留下完整 trace，至少減少人工顧 pipeline。高標則是從 bug report或 production error開始，由 Agent自行重現、修改、驗證、漸進部署，再依線上資料持續改善。但我不會預期近期就能無人值守；長尾錯誤、成本控制與跨使用者權限仍需要人工治理。
商業策略分析
我猜 GitHub Actions、GitLab CI、CircleCI及傳統 APM工具都會感受到壓力，因為 Cloudflare不是單賣 Agent，而是把程式儲存、執行環境、CI、瀏覽器測試、observability與存取控制包成一套。商業意義是把 Workers從部署平台往完整工程控制平面推進，也會提高平台黏著度。值得做概念驗證，尤其本來就在 Cloudflare上的團隊；若是多雲或法遵要求高，則要先評估 vendor lock-in、稽核完整性與失控時的停機機制。
實作細節
官方做法是讓 Artifacts repo的 push事件觸發 Workflow，再用 @cloudflare/ci定義 runner、依賴快取、測試、建置與部署步驟。環境需設定 Artifacts、Containers／Durable Objects、Workflows及 R2 bindings，observability可選配。失敗步驟能設定 retry、backoff與 timeout，未通過就停止部署。已知限制是整套工具仍屬早期拼裝階段；Cloudflare也承認元件尚待進一步整合，而 Agent Access Model目前未完整解決多人共享情境下的資料權限傳遞。