Cloudflare提出“Agent开发生命周期”：软件工厂正在重写软件交付流程
Cloudflare 在 2026 年提出“Agent开发生命周期”（ADLC），并发布一套工具（@cloudflare/ci、本地 OpenTelemetry 追踪、Cloudflare Agents 与 Agent Traces），旨在把生成式 Agent 从代码生成器推进为参与测试、部署与维护的软件交付执行者，同时强调可靠性、权限与审计的必要性。该方案把 CI/CD 转为可编排的 Workflow、在本地复现与追踪错误，并通过统一追踪记录模型、工具与审批行为，但其安全性与实际效果仍需在不同企业环境中逐步验证。
Cloudflare 在 2026 年提出“Agent开发生命周期”（ADLC），并发布一套工具（@cloudflare/ci、本地 OpenTelemetry 追踪、Cloudflare Agents 与 Agent Traces），旨在把生成式 Agent 从代码生成器推进为参与测试、部署与维护的软件交付执行者，同时强调可靠性、权限与审计的必要性。该方案把 CI/CD 转为可编排的 Workflow、在本地复现与追踪错误，并通过统一追踪记录模型、工具与审批行为，但其安全性与实际效果仍需在不同企业环境中逐步验证。
Cloudflare于2026年8月4日发布文章，提出用“Agent开发生命周期”（Agent Development Lifecycle，ADLC）补充、甚至在长期取代传统的软件开发生命周期（SDLC）。公司同时公布了一组围绕这一方向的基础设施工具，包括新的@cloudflare/ci、本地开发环境中的OpenTelemetry追踪，以及Cloudflare Agents和Agent Traces。
这并不意味着软件开发已经进入完全自治阶段。Cloudflare的发布更接近一项平台方向和产品组合：它试图把Agent从“生成代码”的局部工具，推进为能够参与测试、部署、维护和问题修复的软件工程执行者。但在生产环境中，可靠性、成本、权限和安全边界仍需要开发团队逐项验证。
从SDLC到ADLC，Cloudflare改变了什么
传统SDLC通常被概括为计划、设计、实现、测试、部署、维护和退役。Cloudflare认为，生成式AI已经让其中原本最慢、最昂贵的“实现”环节显著提速，结果却是其他环节面临新的瓶颈：代码和Pull Request增长更快，测试、审查、部署以及生产故障处理的压力随之上升。
Cloudflare在官方文章《The Agent Development Lifecycle has arrived on Cloudflare》中说，企业目前常把Agent限制在SDLC的某一个阶段，例如写代码，却仍由人负责验证、合并、部署和处理线上问题。ADLC的设想则是把更多环节组织成一个由Workflow、Agent、浏览器和运行时工具共同驱动的动态流程。
这也解释了“软件工厂”这一说法的含义：输入可以是生产错误、客户报告的缺陷或新功能想法，系统再自动完成分析、修改、验证、发布和后续维护。Cloudflare并没有宣称人类已经退出流程，而是认为人类应更多参与设计、判断和客户沟通，把重复性的执行工作交给可以被观察和约束的Agent。
@cloudflare/ci把CI/CD变成可编排Workflow
Cloudflare公布的@cloudflare/ci建立在Cloudflare Workflows之上。开发者可以通过代码定义依赖安装、Lint、测试、类型检查、构建和部署等步骤，并让相互独立的任务并行执行。与传统的线性CI/CD脚本相比，Workflow可以保存状态、自动重试失败步骤，并持续运行数分钟、数小时甚至数周。
更重要的是，Workflow可以动态生成新的步骤，调用Agent或再启动其他Workflow。这使它不再只是一个按顺序执行命令的流水线，而可以根据测试结果、日志、追踪信息或用户审批决定下一步行动。例如，Agent可以先重现故障，再查询日志和追踪记录，修改代码，重新运行测试，并在逐步部署过程中观察生产指标。
Cloudflare为软件工厂列出了几项基础要求：操作必须能够通过API完成，预览环境需要具备可扩展性，问题应当能够重现，变化应当是原子化、可观察且可回滚的，同时还需要明确的权限和审批机制。换言之，Agent要进入生产流程，关键不只是“能不能写出补丁”，而是能否在每个动作之后留下足够证据，并在失败时停止或恢复。
本地追踪让Agent先在部署前发现问题
Cloudflare还宣布，Wrangler和Cloudflare Vite插件现在可以在本地开发过程中自动捕获OpenTelemetry追踪。开发者不需要额外安装SDK或手动编写观测代码，Agent就可以通过Local Explorer API查询本地Worker的追踪和日志。
在Cloudflare关于本地追踪的说明中，公司举了一个订单接口返回500的例子：Agent重现问题后，可以看到KV读取成功，但D1写入因为缺少数据库字段而失败，消息队列因此没有被调用。随后，Agent检查本地数据库结构、应用迁移，再次发送请求并查询新的追踪结果，以确认修复是否生效。
这个机制的价值在于减少“加日志—重新部署—再次猜测”的循环。它也让本地环境与生产环境使用相近的观测模型。不过，追踪只能帮助系统理解发生了什么，并不能自动证明修复方案符合业务逻辑；Agent仍可能误判根因，或在修复一个错误时引入另一个错误。
Agent Traces记录模型、工具和审批行为
Cloudflare Agents的首个重点是观测。按照Cloudflare Agents官方介绍，Agent Traces会把模型调用、工具执行、Token使用、审批事件和受支持的子Agent调用放在同一条追踪中，并与Workers的基础设施事件关联起来。
开发者可以通过Session Replay查看一次会话中记录的消息、工具调用和结果，也可以通过Trace瀑布图检查每个操作花费的时间。一个Agent调用子Agent、子Agent再调用模型和数据库的过程，能够在同一条链路中呈现出来。这有助于回答一些传统应用监控难以回答的问题：时间究竟耗费在模型、工具还是基础设施上？Agent是否在重试循环中浪费Token？它是否在审批前暂停？子Agent的结果如何影响最终响应？
但Cloudflare也提示，Trace并不是对会话的完整、无损记录，较长的消息、推理内容、工具参数和结果可能受到跨度大小限制而被截断。与此同时，消息和工具载荷可能包含个人信息、凭据或商业机密，企业必须谨慎配置记录范围。追踪在测试阶段免费，Cloudflare表示自2026年10月1日起将纳入Workers Observability的定价体系，免费层每天包含20万事件，付费层每月包含2000万事件，超出部分按每百万事件0.60美元计费。
软件工厂的安全问题不会由平台自动解决
Cloudflare提出ADLC的背景，是Agent正在获得更长的运行时间、更广的工具权限和更复杂的任务链。对于软件工厂而言，风险不只来自错误代码，也来自错误的权限、错误的部署时机、提示注入、敏感数据泄露和难以回滚的外部副作用。
Cloudflare同一周发布的Cloudflare OS相关报道已经把Gatekeeper、能力型权限、观察记录和人工审批放在企业Agent运行时的核心位置。这些设计与ADLC形成互补：前者试图限制Agent能够看到和调用什么，后者则试图把开发、发布和维护过程组织成可追踪的自动化流程。
在更底层的执行环境上，Cloudflare此前推出的Kitesurf云端浏览器也体现了类似思路：为Agent提供更轻量的浏览能力，同时承认它在复杂渲染、长时间会话和反机器人挑战等场景下还不能取代Chromium。平台能力的增加，并不等于风险已经消失，而是要求开发者把隔离、审批和审计纳入产品设计。
这场竞争也不只发生在基础设施厂商之间。Meta近期发布的Muse Code编程Agent同样强调多Agent并行、隔离工作树、本地事件日志和持续验证。不同产品的共同变化是，评价编程Agent的标准正在从“生成代码的速度”转向“能否在长任务中保持目标、正确处理失败并遵守权限边界”。
ADLC仍是一项需要验证的行业假设
Cloudflare的主张是，面对Agent带来的代码产量和交付速度，沿用为人类团队设计的线性SDLC已经不够。它希望通过Workflows、Artifacts、预览URL、功能开关、渐进式部署、日志和Agent Traces，为软件工厂提供一套可组合的基础设施。
目前可以确认的是，Cloudflare已经公开了一组产品和开发工具，并将其连接为一套面向Agent的开发、部署和维护方法。尚不能据此确认，软件工厂在不同企业的真实代码库、合规要求和生产系统中，能够达到怎样的成功率、成本水平和安全性。
对于开发团队而言，更稳妥的做法仍是把ADLC视为一种需要逐步引入的工程模式：先在低风险、可回滚的任务中使用Agent，再通过追踪、测试、审批和渐进式部署积累证据。只有当系统能够稳定地处理失败、解释决策并限制权限时，Agent才可能从代码助手成为真正的软件交付参与者。
来源：
不错过任何一条 AI 大事
订阅 AIFlux 早报，每天 3 分钟看懂产业动态。
