Anthropic发布了一本关于围绕编码代理重组软件生命周期的操作手册。它的前提是传统的SDLC是在编写代码是缓慢的部分时设计的，代理使这个部分变得快速，而约束则转移到了周围的阶段。该框架有六个阶段，每个阶段都会提交下一个阶段可以读取的工件。计划生成intent.md，设计将其转化为spec.md，构建在编辑任何代码之前生成plan.md，部署将审核政策放入REVIEW.md。它比大多数过程文档更具体，但也遗漏了一个重要细节，这决定了剩余过程是否实际有效，即代理的代码在自我检查时运行的环境。阶段4：代理检查自己的工作阶段4是反馈循环，在工程师看到之前代理会检查自己的工作。操作手册要求您给它一些检查依据，无论是测试、构建还是屏幕截图差异。它告诉您在修复期间使用一个钩子阻止编辑测试文件，以防止代理通过编辑测试将红色测试变为绿色。对于UI工作，它建议通过MCP将浏览器或截图工具接入系统。然后，它超越了大多数组织的做法，要求您将编码代理自己的配置视为软件：在CI中运行的evals，每当其中任何一个更改时重新测试CLAUDE.md、技能和钩子，将每个生产事件转变为一个永久评估。阶段4要求您在任何事情开始之前准备好一套测试和一个可以通过一个命令在本地运行的构建。这个前提条件是操作手册停止的地方，而您的基础设施开始的地方。它告诉您代理需要可运行的测试。它并没有说明这些测试应该针对什么运行，而对于一个与十多个其他服务（加上数据库、队列、第三方API等）交互的服务而言，这几乎是大多数现实世界软件的问题。为什么验证是困难的部分如果测试在代理的机器上针对这些十多个服务的虚假副本运行，那么测试通过仅告诉您代码在虚假副本上有效。它是否能在集群中的真正服务上工作则是另一个问题。运行这些相同测试的开发人员大致知道应该相信它们多少。他们知道虚假账单服务是一年前编写的，而真正的服务在两个月前更改了身份验证头。他们知道虚假搜索端点总是返回相同的三个结果，而真正的服务则是分页的。他们知道虚假集合中的任何内容从未对他们进行速率限制或超时。代理对此一无所知。它看到测试通过并报告工作完成。这不是操作手册中的缺陷，而是它所能涵盖的边界。其他每个阶段都在代码库中的文件上工作，Anthropic可以在这些上面具体说明，因为Claude Code是他们的。服务、数据库、队列、消息代理和代码交互的其他所有内容都是您的。没有模型供应商能够告诉您这些是什么样子，因此操作手册告诉您要有一个检查，并在此停止。Anthropic对操作手册的采用图。箭头表示优先采用这个，顶部行是您可以无前提条件开始的地方。反馈循环位于该行中。代理从未看到正在运行的系统查看工件链持有的内容：intent.md、spec.md、plan.md、CLAUDE.md、技能、REVIEW.md。每个文档记录了一个人所做的决定和写下的内容。没有任何内容让代理查看当前生产（或暂存）中的正在运行的系统。不是您调用时上游服务返回的内容，不是排队的内容，也不是暂存数据库的模式今天实际上是什么，这可能比代理正在工作的分支滞后几个迁移。CLAUDE.md告诉代理组织的决定，而不是实际在运行的内容。mirrord的作用是什么mirrord允许代理的代码在您的暂存集群中的真实服务上运行，而不是在其机器上的虚假服务。代码依然在本地或在CI运行器或沙盒中运行。改变的是它周围的所有东西：过程读取与集群中代替该服务的服务相同的环境变量和机密，它的出站调用通过集群的网络发出，集群内部的流量可以路由到它。我们为开发人员构建了这个，主要用于通过消除部署和等待周期来缩短他们的反馈循环。代理能从中获得更多，因为开发人员仍然可以判断一组虚假数据变得多么过时，但代理不能。针对集群中的服务运行检查意味着没人需要作出该判断。这在检查之前也有帮助。相同的连接让代理看到API实际上返回的内容，以及队列上实际上包含的消息，而不是依靠文档。从一个集群运行多个代理操作手册建议在同一个集群中运行多个Claude Code会话。