AI agent 正在改变软件开发的速度。代码生成可能只需要几分钟，但评审、部署、监控、修复和长期维护仍然需要完整的工程流程。当代码产出速度超过团队验证和运营能力时，真正的瓶颈就从“怎么写代码”转向了“怎么管理持续生成的代码”。
Cloudflare 介绍的 Agent Development Lifecycle，简称 ADLC，正是针对这一变化提出的开发视角：围绕 agent 的生成能力，重新组织测试、发布、运行和维护环节，并使用 Cloudflare 提供的基础能力支撑这条生命周期。
从开发速度转向交付闭环
传统开发流程通常以人为中心：开发者编写代码，提交 Pull Request，团队评审后部署到环境中，再由运维和开发者共同处理运行问题。
agent 加入后，流程变成了持续循环：
- agent 根据需求生成代码或配置。
- 自动化检查验证行为、权限和资源使用。
- agent 根据失败结果修改实现。
- 系统将候选版本部署到受控环境。
- 运行时数据反馈给开发者或 agent。
- 团队决定是否推广、回滚或继续迭代。
这个循环的核心变化，是“写出代码”不再代表任务完成。每一次生成都需要经过可验证的质量门禁，并且要留下可以追踪的版本、输入、输出和运行结果。
ADLC 需要解决哪些工程问题
让生成结果可审查
agent 生成的代码不应直接进入生产环境。团队需要检查差异、测试结果、依赖变化和权限边界。对 agent 来说，Pull Request、提交记录和自动化检查仍然是重要的协作接口，因为它们能把快速生成转化为可审计的变更。
让部署具备可控范围
候选版本可以先进入隔离环境或小范围流量，再根据错误率、延迟和业务指标决定是否继续发布。这样，agent 的速度不会直接放大成生产事故的速度。
让运行时反馈回到开发循环
部署完成后，日志、指标和异常信息不应只留给人工排查。它们可以形成下一轮调试的输入，让开发者和 agent 都能基于真实运行结果修正实现。
让维护成为持续动作
依赖升级、配置漂移、成本增长和权限变化，都会让一个最初可用的 agent 系统逐渐失控。ADLC 的价值不只是加快首次发布，也包括持续检查和维护已经上线的代码与 agent。
一个可改造的最小 ADLC 检查脚本
下面是一个不依赖 Cloudflare 特定 API 的最小示例。它假设 agent 已经把候选代码生成到当前项目中，团队希望在部署前执行静态检查、测试和变更审计。可以将这些检查接入 CI，也可以将结果作为 agent 下一轮修复的输入。
运行前准备：项目中安装 pytest，并根据实际项目调整检查命令。
#!/usr/bin/env bash
set -Eeuo pipefail
REPORT_DIR="artifacts/adlc"
mkdir -p "$REPORT_DIR"
printf '%s\n' "[1/3] Checking generated diff"
git diff --check | tee "$REPORT_DIR/diff-check.txt"
git diff --stat | tee "$REPORT_DIR/diff-stat.txt"
printf '%s\n' "[2/3] Running tests"
pytest -q 2>&1 | tee "$REPORT_DIR/tests.txt"
printf '%s\n' "[3/3] Checking required files"
for file in README.md pyproject.toml; do
if [[ ! -f "$file" ]]; then
printf 'Missing required file: %s\n' "$file" >&2
exit 1
fi
done
printf '%s\n' "ADLC gate passed; deployment can continue after human approval."
这个示例有三个关键边界：git diff --check 只负责发现明显的补丁格式问题，测试负责验证行为，人工审批仍然负责判断业务风险。真实系统还应加入依赖扫描、密钥检测、权限检查、资源限制和部署后的健康指标。
如果把脚本接入 agent 工作流，可以要求 agent 只读取 artifacts/adlc/tests.txt 和差异摘要，然后提交修复，而不是让它无限制地修改整个代码库。这样能缩小每轮反馈的范围，也便于复盘。
Cloudflare primitives 的位置
从工程设计角度看，Cloudflare 提到的 primitives 可以理解为支撑 ADLC 各个阶段的基础构件：代码和变更需要可管理，agent 需要可运行，应用需要可部署，运行过程需要可观测，外部访问还需要身份和安全控制。
落地时不应只问“哪个模型写代码更快”，还要明确以下问题：
- agent 使用哪些输入，是否保留提示词、工具调用和生成结果？
- 生成的代码在哪个隔离边界内执行？
- 哪些操作需要人工批准，哪些操作可以自动完成？
- 候选版本如何灰度发布，失败时如何回滚？
- 日志和指标如何关联到具体的 agent 运行、提交和部署版本？
- 运行成本、访问权限和数据暴露如何限制？
Cloudflare 的平台能力可以作为这些阶段的基础设施选择，但具体组件和接口应根据团队当前的部署形态、合规要求及业务负载进行验证。ADLC 首先是一种生命周期设计，其次才是平台选型。
采用前的工程清单
可以从一条窄链路开始，而不是一次性自动化所有环节：
- 为每次 agent 运行生成唯一 ID，并关联提交、构建和部署记录。
- 将测试、依赖扫描、密钥检测和权限检查设为发布门禁。
- 让 agent 在隔离环境中执行工具和生成代码。
- 先部署到测试环境或小比例流量，再扩大范围。
- 为每个版本定义回滚条件，例如错误率、延迟或成本超阈值。
- 保留人工批准点，特别是涉及数据删除、生产写入和权限升级的操作。
- 定期清理失效 agent、过期依赖和无人维护的部署。
当 agent 的产出速度持续提升，团队竞争力不再只取决于生成能力，而取决于能否快速判断、可靠发布并持续维护这些产出。Agent Development Lifecycle 的重点，就是把这种判断和控制能力变成软件交付系统的一部分。