Agent 不只交付结果，也开始交付过程

Coding Agent 最吸引人的地方，是它能够边理解、边行动。它进入代码仓库，查找相关文件，分析已有实现，决定下一步该做什么；修改代码后运行测试，再根据错误继续调整。对于范围明确的小任务，这套模式已经相当有效。我们告诉 Agent 要解决什么问题，它在代码、工具和测试之间不断循环，最终交付一个可以工作的结果。

但当任务持续数小时、跨越多个阶段，甚至需要多个 Agent 并行工作时，人最终拿到的通常只有代码差异和测试结果。中间的计划、判断与执行状态，仍然散落在会话、工具结果和运行日志中。我们可以审查 Agent 最后做出了什么，却很难还原它为什么选择这条路径、已经执行到哪里，以及任务中断后应该从哪里继续。

当 Agent 开始承担更长、更复杂的工作，“怎么完成任务”也需要成为正式交付物。

今天使用 Coding Agent，一个常见做法是先让它分析需求、查找相关代码，再列出一份实施计划。人确认方向后，Agent 开始执行。从表面上看，计划和执行已经分开，但这份计划通常仍然依附于当前会话。它可能只是几段自然语言，用来帮助当前的人和 Agent 建立短期共识；真正开始执行后，原有计划又会不断混入新的对话、工具结果、测试错误和临时判断。

任务较短时，这种混合不会造成太大问题。任务一旦变长，会话便很难继续充当可靠的任务状态。聊天记录能够告诉我们 Agent 说过什么，却不容易准确表达哪些步骤已经完成、哪些中间结果可以复用，以及失败后应该从哪里继续。一次上下文压缩、一次任务重启，或者换一个 Agent 接手，都可能需要重新读取代码、理解目标和规划执行顺序。

人也很难在执行前看清完整范围。很多时候，要等 Agent 已经修改了大量文件，才能从最终差异中发现：它对任务边界的理解从一开始就出现了偏差。多个 Agent 同时运行时，任务依赖、文件冲突、中间产物、资源预算、失败重试和退出条件，也需要由会话之外的系统统一管理。

边理解边执行依然适合探索未知问题，但它很难独自支撑长周期、可恢复、可治理的软件生产。

最近，一些 Agent 产品、框架和研究正在出现相似变化：模型先生成一份独立的可执行计划，再由外部执行系统推进后续任务。

这里的计划已经不只是“Agent 准备怎么做”的文字说明。它会进一步表达执行步骤、任务依赖、验证规则、重试方式和人工审批节点，让会话中的动态判断变成一份可以被软件系统直接处理的执行描述。

Blake Crosley（前 ZipRecruiter 产品设计副总裁，现为独立设计师与开发者）在文章 《Agents Want to Compile》 中，将这种变化概括为 Agent 开始“编译”：模型负责理解模糊目标并生成计划，外部 Runtime（运行时执行系统）则负责调度、执行、恢复和审计。

这里的“编译”是一个有边界的类比。它并非把自然语言直接转换成机器指令，而是把一个充满不确定性的任务，逐步转换成更加明确的执行产物：

更值得关注的是，计划在系统中的地位发生了变化。

过去，计划主要服务于当前会话中的沟通；现在，它可以独立保存、接受审查、记录状态、在中断后恢复，也可以被纳入权限、预算和风险控制。环境或任务发生变化时，系统还可以重新生成计划，并比较前后版本之间的差异。

对话记录描述 Agent 曾经做过什么，可执行计划则定义系统接下来准备做什么。当计划从会话中独立出来，它便不再只是 Agent 给人的解释，而开始成为连接模型、人和执行系统的中间层。

显式计划首先改变的是 Review 发生的位置。过去，人通常在 Agent 完成任务以后审查代码。如果方向错误、范围过大或者技术路径不合适，往往已经产生了大量修改；即便最终没有合并，这些执行成本也已经发生。

当计划成为独立产物后，一部分 Review 可以向前移动。在正式执行前，人和系统便可以检查它准备修改哪些模块、任务之间有什么依赖、会调用哪些工具、哪些操作具有较高风险，以及每个阶段如何验证、什么情况下必须停止并询问人。

计划审查无法取代代码审查，Agent 在具体实现中仍然可能写出错误代码，也可能遇到计划之外的问题。但它可以更早发现范围偏差、错误依赖和高风险操作。与其在 Agent 修改几百个文件后才发现方向错了，不如在执行开始前先看清它准备走哪条路线。

计划显式化也让长任务恢复成为可能。系统可以记录哪些步骤已经完成、哪些中间产物已经生成，出现故障后从检查点继续，而不必让 Agent 重新理解整个任务。权限和资源治理同样会变得更清晰：如果所有行为都由 Agent 在运行时即时决定，系统通常只能在单次工具调用发生时进行拦截；显式计划则提供了更高层的检查点，可以提前判断任务是否会访问敏感数据、写入生产环境、超出修改范围，或者突破时间与 Token 预算。

Agent 的执行过程由此开始具备可审查、可恢复和可治理的属性。

这种方向已经出现在不同研究中。LLMCompiler 让模型先生成工具调用计划，再由执行系统根据依赖推进任务；PlanCompiler 进一步使用类型和结构约束检查计划；Compiled AI 则让模型只参与生成阶段，运行时执行已经生成并验证过的程序。三者面向的任务和目标并不相同，却都在尝试把模型的动态判断转换成可检查、可执行的中间产物。

这也与 Agent Behavior Engineering 指向同一方向：Agent 的行为开始从运行时难以看见的内部过程，变成可以被定义、记录和治理的软件对象。可执行计划让这种治理进一步落到一次具体任务中——系统可以提前看到 Agent 准备做什么，并在关键节点介入。

“计划可以执行”很容易带来一个误解：后续工作是否会完全摆脱模型，变成一套固定流程？对于规则稳定、重复频率高的任务，这种方式确实可行。固定格式的数据处理、文档转换和标准化检查，可以在前期生成程序，后续按照普通软件的方式重复运行。

软件研发通常没有这么简单。Coding Agent 在执行过程中仍然需要面对真实代码、编译错误、测试失败、依赖变化和预料之外的实现细节，许多局部问题无法在计划生成阶段全部预知。

更现实的系统形态是：

Runtime 负责管理当前执行阶段、任务状态、工具权限、资源预算、失败重试和人工门禁；Agent 则在具体步骤中继续理解代码、生成实现、调用工具并解决局部问题。

例如，一份计划可以规定：先定位受影响的接口和页面，再修改适配层与状态处理，随后运行单元测试和端到端测试；测试失败后允许自动修复两轮，仍未通过则停止执行并输出问题报告。Runtime 可以稳定地管理这些阶段和退出规则，但 Agent 如何修改某段具体代码、如何修复某个测试错误，仍然需要根据现场信息动态判断。

显式计划不会消除 Agent 的智能，它只是在 Agent 外面增加了一层更稳定的执行结构。 动态判断依然存在，只是发生在更加清晰的边界之内。

把计划变成工程资产，并不意味着所有任务都应该提前规划完整。计划越明确，其中冻结的判断也越多；如果前期理解发生偏差，系统可能会高效地把错误方向执行到底。

探索性任务尤其如此。进入一个陌生代码库时，真正的问题可能尚未暴露；面对从未出现过的错误时，寻找原因本身就是任务；产品体验、架构取舍和设计审美，也很难提前转换成固定步骤。在这些场景中，Agent 边理解边行动的能力仍然不可替代，过早生成一份完整计划，容易把尚未验证的假设包装成看起来可靠的流程。

《Agents Want to Compile》中有一个很有启发性的边界判断：首次执行更接近研究，重复执行更接近构建。

未知任务需要保留更大的探索空间。当任务形态、约束和验证方式逐渐稳定后，已经跑通的过程才适合沉淀为可复用资产。代码迁移、依赖升级、批量修改、测试补全、安全扫描和发布检查，通常具有较强的重复性，也更容易建立外部验证信号；涉及大量业务歧义、全新架构或产品判断的任务，则需要更长时间保留动态探索，并在关键节点引入人类决策。

计划的价值，是沉淀已经收敛的判断，而不是提前冻结仍然未知的问题。

现阶段更现实的研发自动化路径，可能包含三个彼此衔接的部分：

前面负责澄清目标与边界、找到必要上下文，并形成一份可以审查的执行计划；中间负责调用通用 Agent 完成具体工作，同时管理状态、权限、预算、重试和人工接管；后面通过测试、接口契约、端到端路径和人工验收判断任务是否真正完成，避免让执行 Agent 同时担任自己的裁判。

这种形态利用了一个正在逐渐成立的现实：

接下来的关键，不只在于继续提高 Agent 的执行能力。模型执行前后的工程系统，也将决定这些能力能否稳定进入真实生产。过去，Agent 的主要交付物是结果；现在，它还需要交付一套可以被人和系统共同理解、审查、执行和验证的过程。

当“怎么做”也成为正式产物，Agent 才会从一次性的智能执行者，逐步进入可靠的软件生产体系。