环境即代码：可复现性是反馈可靠的前提

前面三层反馈（静态分析、CI/CD、可观测性）都有一个隐含的前提：Agent 运行代码的环境是可预测的。如果同样的代码在 Agent A 的环境里能跑、在 Agent B 的环境里报错，所有反馈信号都失去了意义，因为你无法区分是代码的问题还是环境的问题。

这个问题在人类开发中就存在，"在我机器上是好的"是一个经典笑话。但在多 Agent 并行的场景下，它被放大了一个数量级。五个 Agent 同时工作，每个 Agent 的运行环境如果有细微差异（依赖版本不同、环境变量缺失、系统库不一致），产生的问题排列组合会让调试变得极其困难。

Infrastructure as Code 的核心价值在这个场景下变得清晰：它让环境变成了一个可版本控制、可复现、可审查的工件。Dockerfile、Terraform 配置、docker-compose 定义，这些文件和业务代码一起存在于仓库中，Agent 可以读取、理解和修改它们。

对 Agent 驱动的开发来说，IaC 有几个具体的作用。

可复现性保证了反馈的一致性。当 CI 在一个明确定义的容器中运行测试，测试结果反映的是代码本身的状态，而非某台机器上偶然的环境配置。Agent 收到一个测试失败的信号时，它可以确信这个失败是代码引起的，不需要怀疑环境。

环境隔离支撑了 Agent 的并行工作。每个 Agent 在独立的容器中运行，互不干扰。一个 Agent 安装了实验性的依赖不会影响另一个 Agent 的构建。这和前面讨论的 git 分支隔离是同一个原则在不同层面的体现：代码层面用分支隔离，环境层面用容器隔离。

环境变更变得可审查。当一个 Agent 修改了 Dockerfile 或 Terraform 文件，这个变更会出现在代码审查中，和业务代码的变更一起被评估。环境的修改不再是运维人员在服务器上手动执行的黑箱操作，而是一个有 diff、有审查、有回滚能力的正常代码变更。

还有一个实践层面的考量。很多团队的 Agent 工作流已经演化到在 Docker 容器中以无头模式运行 Agent CLI，跳过交互式权限确认，通过文件系统进行进程间通信。这种模式天然要求环境定义是代码化的：你无法手动配置每一个容器的环境，必须通过声明式的配置文件来定义。IaC 在这里不是一个"最佳实践"建议，而是 Agent 规模化运行的硬性前提。

但要注意 demo 和生产之间的鸿沟。在本地的 Docker 环境里一切正常，不代表在真实的生产环境里也能工作。外部系统的行为不受你控制：银行接口的超时策略、第三方 API 的限流规则、网络分区下的故障模式。分布式计算的八大谬误在 Agent 时代依然适用。IaC 解决的是"你能控制的环境"的可复现性问题，对于"你不能控制的外部依赖"，你仍然需要在可观测性和容错设计上下功夫。