\n\n本文探讨了 Claude 等编程智能体在云原生开发中的核心挑战，强调了“验证循环”的重要性。智能体仅生成代码是不够的，必须在隔离且真实的云环境中进行端到端验证，才能真正提升开发效率。
译自：Why Claude needs a real environment to validate cloud-native code
作者：Arjun Iyer
Claude Code 的构建者 Boris Cherny 最近在 X 上分享了在 Opus 4.7 发布后如何充分利用它的心得。他将最重要的建议留在了最后：
“确保 Claude 有办法验证其工作。这一直是将 Claude 产出提升 2-3 倍的方法，而在 4.7 版本中，这一点比以往任何时候都更加重要。”
这一观察描述了一种正逐渐成为使用编程智能体开发软件的标准模式。对于具有有限依赖项的单个本地代码库，这种模式很容易实现。
但在拓扑结构复杂的云原生应用中，实现这一点要困难得多。弥合这一差距，是让编程智能体成为团队加速器，还是让其成为将团队埋没在评审队列和手动验证中的累赘的关键区别。
编程智能体中涌现的模式
Boris 的建议反映了整个行业正在涌现的一种模式。在过去的六个月里，每个主流的编程智能体都发布了基础设施，其明确目的就是让智能体在交付工作之前能够自检。
OpenAI 的 Codex 在一个隔离的云容器中进行循环迭代，编辑代码、运行检查，并根据团队 AGENTS.md 文件中指定的命令验证其更改。验证循环本身就是产品，而非一项附属功能。
“验证循环本身就是产品，而非一项附属功能。”
GitHub Copilot 编程智能体运行在一个临时的 GitHub Actions 环境中，该环境会自动对每项任务执行仓库的测试、Linter、CodeQL 和秘密扫描。如果任何环节失败，Copilot 会尝试在标记任务为待评审之前进行修复。Cursor 的云端智能体运行在具有 Shell 和浏览器访问权限的沙箱虚拟机中，因此智能体可以端到端地练习其更改，并生成截图、视频和日志作为其测试证据。
Claude Code 将相同的形态作为可组合的原语暴露出来。Stop hooks 可以防止团队在测试通过之前完成任务。子智能体（Subagents）可以运行专用的验证传递，在不修改工作的情况下检查工作。验证循环是团队组装出来的，但其构建块是明确且得到良好支持的。
这种趋同并非巧合。每个构建编程智能体的团队都发现了同一个问题：一个只编写看似合理的代码而不进行检查的模型，会将整个正确性问题推回给开发者。生产力的提升会消失在评审开销中。
一个能够验证自己工作的编程智能体运作方式则完全不同。它在任务上进行迭代，捕捉自己的错误，并交付一些开发者可以合理信任的东西。这就是有用的智能体工作所在，也是目前每个主流智能体供应商都在押注的方向。
云原生系统让循环变得更难
所有这些都假设智能体可以在一个镜像生产环境的真实环境中运行更改。在现代云原生架构中，这一假设很快就会瓦解。
智能体更改的代码很少孤立地失败。它失败在“缝隙”处。服务调用其他服务。异步事件通过消息总线触发。一个服务中的模式更改会级联影响到它的消费者。一个新的中间件请求头会破坏三跳之外的调用者。
“智能体更改的代码很少孤立地失败。它失败在缝隙处。”
编写更改的智能体无法通过模拟的集成测试捕捉到这些。Mock（模拟）只会返回智能体要求它返回的任何内容。
分布式系统中的真实验证意味着在真实环境中运行更改，并观察实际请求流经它时会发生什么。全程端到端。真实的依赖。真实的流量模式。
任何不达标的做法都会将问题推回给开发者。更多的评审轮次。更多的迭代周期。破坏的暂存环境（Staging environments）会拖慢其他开发者和智能体的速度。偶尔还会有 Bug 混入生产环境。
真实的反馈，无需复制整个堆栈
云原生团队需要的是一个反馈循环，让他们的智能体能够看到更改的实际行为。不是针对 Mock。不是针对生产环境的简化近似。而是针对真实的服务、真实的数据路径和真实的流量模式，足够接近生产环境，以便智能体最可能引起的集成失败也是它最容易捕捉到的集成失败。
这个循环必须同时满足三个约束。
它必须是真实的。智能体正试图验证跨越服务边界的更改，因此它需要一个存在这些边界且行为与生产环境一致的环境。否则，智能体最终验证的将是一个与其实际代码发布时运行的环境不匹配的系统版本。
它必须是隔离的。多个智能体和多个开发者将并发地练习更改，通常是在系统的重叠部分。如果一个智能体的测试运行破坏了所有人的环境，那么虽然该智能体的循环关闭了，但却为团队其他成员开启了一个更大的问题。智能体的验证工作不能变成人类的协调问题。
它必须能够随着智能体实际工作的方式扩展。运行编程智能体的团队不会一次只运行一个任务。它会并行运行许多任务，每个任务在不同的分支上，每个任务都需要自己的真实验证场所。如果一个模式要求为每个智能体复制整个应用堆栈，那么在团队认真对待吞吐量的那一刻，无论是从成本还是从建立每个堆栈所需的时钟时间来看，该模式都会崩溃。
环境对智能体来说必须感觉像生产环境，不干扰其他使用它的人，并且足够经济高效，以便团队可以根据正在运行的智能体数量运行相同数量的环境。
智能体需要知道如何使用环境
为智能体提供真实环境是必要的，但仅凭这一点并不能闭合循环。一个拥有类生产系统访问权限但没有使用指南的智能体，表现就像一个第一天被扔进陌生代码库的新工程师。权限在那里，但关于如何使用它的判断力却不在。
这种判断力由两部分组成。一是团队的运维知识：当代码路径更改时需要练习哪些上游调用者，哪些下游依赖项实际上会影响结果，如何辨别请求失败是由评审中的更改引起的，还是由三台服务之外的抖动引起的。另一部分是对环境内部工具的熟练程度：如何路由流量进行测试，如何跨服务检查状态，哪些命令可用，如何读取环境暴露的日志。通用的测试知识无法涵盖这两者。
智能体技能（Agent skills）是这两者的载体。技能捕捉了特定系统中的更改应如何验证和调试，以及如何驱动环境提供的特定工具来完成这些工作。它是团队的制度性知识，加上环境的操作手册，在授予访问权限的同时交给了智能体。
这所实现的是最重要的事情：一个能像团队资深工程师一样验证自己工作的智能体。不仅是运行测试，还要用正确的工具练习正确的路径，解读正确的信号，并以一种反映系统实际行为的方式识别出错误。
技能和环境必须配套交付。没有技能的环境给了智能体访问权限但没有判断力。没有环境的技能给了智能体判断力但没有行动对象。任何单独一项都会使循环处于开启状态。
内环是下一次飞跃所在
使用编程智能体的云原生团队的下一次突破不是更聪明的模型，而是一个智能体可以在其内环（inner loop）中工作的真实环境，以及熟练使用它的上下文。
随着时间的推移，更有趣的是，一旦智能体参与进来，内环和外环（outer loop）之间的界限就开始溶解。当 CI（持续集成）中的测试失败时，智能体的自然下一步不是呈现失败并等待人类。而是将相同的更改放回内环环境中，用真实的依赖项重现失败，调试它，并推送修复程序。外环的信号变成了内环的启动条件。
反之亦然。智能体在内环中运行一次的临时验证通常值得在任务完成后保留下来。通过将其编码到外环中，它变成了团队常备回归测试套件的一部分。内环的一次性实验变成了外环的持久守卫。
这两个方向都依赖于相同的基础：一个智能体可以从任一循环触达的真实环境，以及熟练使用它的上下文。这就是我们在 Signadot 努力构建的方向，让验证周期在信号到达的任何地方都能保持连续。
这种反馈循环是将智能体从快速代码生成器转变为开发者可以信任的协作伙伴的关键。能够在这两个循环中闭合反馈路径的团队，将是那些获得编程智能体真正红利的团队，而其余的人则会被埋没在他们的评审队列中。端 工智能
