秒到分钟级反馈：CI/CD 作为反馈通道

Linter 能在毫秒内拦截语法和类型问题，但它无法回答更深层的问题：代码能不能构建成功？模块之间的依赖有没有断裂？集成测试是否通过？这些问题需要实际运行构建和测试流程，反馈延迟从毫秒上升到秒和分钟。

CI/CD 流水线在传统开发中的角色是部署工具：代码写完，走流水线，部署到环境。在 Agent 驱动的开发中，它的核心角色发生了转变：流水线首先是一个反馈通道，其次才是部署工具。Agent 每次提交代码后，流水线告诉它：构建成功还是失败？哪些测试挂了？集成点有没有断裂？这些信号决定了 Agent 的下一步动作。

这意味着流水线的设计优先级要调整。传统流水线追求的是完整性和安全性：跑完所有测试、通过所有检查、经过审批才能部署。Agent 驱动的流水线追求的首先是速度：Agent 需要在最短时间内知道自己的代码有没有问题。如果一次完整的 CI 要跑 40 分钟，Agent 在这 40 分钟里要么空等，要么基于未验证的假设继续写代码。两种情况都不理想。

解决方案不是降低 CI 的覆盖范围，而是分层。第一层是快速反馈层：只跑与本次变更直接相关的构建和测试，几十秒内返回结果。第二层是完整验证层：跑全量测试和集成检查，可以异步进行。Agent 拿到第一层的快速反馈继续工作，第二层的结果出来后如果有问题再中断和修复。

在多 Agent 并行的场景下，CI 的设计还有一个关键要求：可追溯性。当三个 Agent 同时在三个分支上工作，CI 的结果必须能清楚地关联到具体的 Agent 和具体的任务。"构建失败"不够，需要"Agent B 在任务 #42 中修改了 payments/handler.go，导致集成测试 TestPaymentFlow 失败"。没有这种粒度的可追溯性，你面对的就是一堆无法定位的红色标记。

集成频率也需要提高。传统团队可能一天集成一次。多 Agent 并行时，每个 Agent 完成一个原子任务就应该触发集成。偏差的修复成本和它的存活时间成正比：两个 Agent 各自跑了一天再集成，发现的冲突可能需要回退一天的工作量。每小时集成一次，最坏情况只回退一小时。

流水线的稳定性同样关键。如果 CI 存在 flaky test（随机失败的测试），Agent 无法区分"我的代码有问题"和"CI 本身不稳定"。对人类来说，flaky test 是小烦恼，重跑一次就好。对 Agent 来说，flaky test 是错误信号：它可能花大量 token 去"修复"一个根本不存在的问题，或者反过来，学会忽略测试失败，因为"上次也是这样，重跑就好了"。消除 flaky test 不是锦上添花，是平台可靠性的底线。

CI 作为反馈通道会不会太慢了？

通过 CI 流水线意味着 Agents 需要依赖外部服务才能完成验证和反馈的工作。这个链条的延长，势必影响 Agents 的迭代效率。传统开发中 CI 流水线是可靠，可复制集成环境的代名词。在 Agents 为开发主力的前提下。CI 流水线需要进行必要的左移。能够让 Agents 在各自的 WorkTree 上就能够完成从构建，到单元测试和合约测试，再到集成测试。也就是说，Agent 需要一个为它设计，为它服务的验证环境。

考虑到有些集成环境比较复杂，集成环境的构建本身可能是跨项目的。例如有专门的 IaC 项目负责启动虚机；有平台部署项目负责启动中间件。这就需要有专职的 Platform Engineering Agent 来掌握集成环境相关的 repo，skills 和业务知识。由 Platform Engineering Agent 根据发起测试的研发 Agent 的修改范围，创建最恰当的集成测试环境（含构建）。使得测试发生在 Agent 本身工作流程中的一个环节而不依赖于外部集成服务。这种模式也能够天然的缩短 CI 的反馈周期。