Signal #32：Coding Agent 正在接手研发流程的推进

9 月 30 日，Kiro 团队在发布 Workflows 时，讲述了他们此前使用 Coding Agent 的经历。

让 Agent 实现一项修改，接着提醒它做代码评审，再要求它处理评审意见。如果中间拆成多个会话，还需要有人记住任务进展，把前一步的结果交给下一步。

这也是许多工程师使用 Coding Agent 时熟悉的场景。

代码可以交给 Agent 生成，但写完之后呢？谁提醒它开始评审？评审发现问题后，谁负责继续修改？如果测试没有通过，或者 CI 一直没有结束，任务又该怎样推进？

当这些事情需要工程师反复提醒，Agent 能承担的工作就会受到持续监督成本的限制。

10 月 1 日，GitHub 也公开预览了 Dynamic Workflows，支持使用代码定义执行步骤、Agent 调用、结果交接和人工检查点。

两次发布指向一个值得关注的变化：Coding Agent 正在将研发步骤之间的衔接交给专门的执行机制。

工程师可以定义一套流程，让系统根据执行结果安排后续工作，在需要人工判断时暂停，并将跑通的流程保存下来，供后续任务复用。

假设我们要给订单详情页增加取消功能。业务规则已经确认，希望 Agent 完成编码、代码评审、问题修改和最终验证。

我们很容易写出这样的要求：

实现后进行评审，发现问题就修改，再重新评审，最多尝试三轮。

但要让这套流程持续执行，还需要解决几个问题：

如果这些事情都需要 Agent 在对话里自行安排，执行效果就依赖于它能否持续记住并遵守之前的约定。

工作流可以把这些约定变成明确的执行规则。

例如，实现步骤交付代码改动和验证记录；评审步骤读取这些材料，输出通过结果或者待修改问题；存在问题就进入下一轮修改；达到尝试上限仍未通过，系统停止执行，并把未解决的问题交给工程师。

Agent 负责理解需求、生成代码和分析问题，工作流执行系统负责记录进度、传递结果，以及决定下一步是否可以开始。

Kiro 官方提供的 feature-pipeline 就展示了类似的机制。

它将需求分析、设计、评审、实现和验证组织成一套执行计划。设计评审与代码评审分别最多循环三轮，如果仍未获得批准，就停止当前流程。最后的验证还会重新对照最初的需求。

其中，每个步骤运行在独立的 Agent 会话中，前一步通过明确的输出或文件向后一步交接材料。Kiro 的运行系统负责按照计划推进，也允许工程师暂停、调整和继续执行。

GitHub 采用了另一种实现方式：通过程序代码定义步骤、条件、并行任务和结果传递，再调用 Agent 处理需要分析和判断的部分。

两者的实现方式有所不同，但共同点很清楚：任务的推进规则可以由执行系统管理，不再完全依赖模型在一次对话中记住所有安排。

熟悉 Skill 的读者可能会有一个疑问：这些流程写进 Skill，不也可以执行吗？

确实可以。

Agent Skills 规范允许 Skill 包含操作说明、参考资料和可执行脚本。一套研发方法完全可以封装成 Skill，甚至通过脚本实现步骤调度、条件判断和状态管理。

因此，关键要看具体的执行机制。

如果 Skill 主要提供步骤说明，Agent 需要读取说明并自行安排执行。如果背后有工作流执行系统，步骤顺序、交接和停止条件就可以直接交给系统管理。

两者也可以配合使用。例如，工作流在代码评审阶段调用团队已有的评审 Skill，或者通过 Skill 启动一套工作流。

这里还有一个容易忽略的问题：工作流可以保证按约定触发评审，却无法天然保证评审质量。即便使用独立会话或多个 Agent，能否发现真正的问题，仍取决于评审材料、工具和判断依据。

如果一次任务需要运行十几个小时，甚至持续到第二天，问题会更复杂。

小红书技术团队在《小红书推荐系统的 Agentic 发布：跨昼夜任务 Harness 实践》中，分享了一个真实的生产案例。

他们的一次推荐系统发布，需要覆盖十多个部署组、数千个 Pod，平均持续十多个小时。完成灰度发布后，还需要等待次日真实流量积累足够样本，才能判断是否继续放量。

团队最初已经将发布知识、操作步骤和异常处置整理成近 20 万字的 SKILL。

但实际执行中，仍然发生了一次事故：模型遗漏了参数，让本应灰度发布的版本直接推向全部部署组。

这个问题很有代表性。

Agent 知道“必须灰度”，却没有在一次具体的平台调用中正确执行这项约束。

继续补充操作说明，无法保证下一次调用一定不会发生类似问题。生产发布还需要解决状态持久化、外部操作查证、中断恢复和风险约束。

小红书团队后续构建了一套长程任务 Harness，将执行责任交给专门的系统。

其中，有两个设计尤其值得关注。

第一，任务状态独立于 Agent 会话。

一次发布的参数、执行进度、平台结果和已经确认的决策，都保存在独立任务中。

当流程需要等待几个小时，执行系统可以保存当前进度和下一次检查时间。即使会话结束、进程重启，新的执行实例也可以读取任务状态，从已经确认的位置继续。

系统依靠持久化的任务记录判断进展，无须依赖模型记住此前发生的全部事情。

第二，外部操作需要查证实际效果。

例如，发布平台返回成功，不代表预期的部署范围一定已经生效。

如果系统在调用成功后、记录结果前发生中断，恢复时直接重试，可能造成重复操作；直接当作成功，又可能跳过尚未完成的工作。

小红书的方案会记录待执行动作及其稳定标识，在结果不明确时查询平台实际状态，再决定后续动作。

同时，发布范围、步骤约束和通过条件由流程模板及执行引擎控制。Agent 可以分析异常、提出调整方案，但影响执行任务的变更需要经过相应确认。

这套设计让任务能够跨越会话和执行实例持续推进，也使关键约束不必完全依赖模型每次都作出正确判断。

回到日常研发，同样会遇到类似的问题。

CI 尚未结束时，任务需要保留等待状态；检查失败后，失败信息应该进入下一轮分析；执行中断之后，哪些结果能够沿用，哪些步骤必须重新运行，也应该有明确依据。

当然，开发工作流和生产发布系统对可靠性的要求不同。小红书案例中的发布约束、状态恢复与外部效果查证，都依赖专门的工程实现，不能直接视为 GitHub、Kiro 已经完整提供的能力。

但这个案例提醒我们：流程能够连续运行，只解决了一部分问题。要让它可靠推进，还必须知道任务停在哪里、已经发生了什么，以及外部操作是否真正生效。

当 Coding Agent 可以连续推进更多研发步骤，工程师需要思考的一个问题是：什么结果才能证明当前步骤已经完成，可以进入下一步？

回到前面的订单取消功能。

“代码已生成”“代码评审通过”“功能验证完成”，是三个不同的状态。

即使代码可以正常运行，也还需要回答：

这些问题应该在需求和方案阶段得到明确，并进入后续实现与验证。

如果检查只确认按钮已经出现、接口能够调用，工作流就算顺利执行完所有步骤，也可能遗漏业务问题。

执行系统负责让检查发生，检查什么、以什么结果作为通过依据，仍然需要工程判断。

这也为团队实践提供了一个比较明确的起点。

可以先选择一类经常重复的研发任务，把每一步需要的材料、预期产物、通过条件、停止条件以及人工确认点整理出来，形成可执行的工作流。

随后在真实任务中观察：哪些交接经常遗漏，哪些评审未能发现问题，任务为什么中断，工程师又在哪些地方需要反复介入。

这些运行记录可以进一步用于修改流程、补充工具和完善验证规则。

一套流程跑通之后，还可以保存下来供其他任务使用。但每次需求的业务规则、影响范围和验收依据，都需要结合实际情况更新。

也没有必要将所有工作都组织成复杂工作流。简单的问题修复和局部修改，直接使用 Coding Agent 对话可能更经济。涉及多次交接、重复检查、并行工作或长时间等待的任务，才更值得投入专门的流程建设。

流程编排已经发展了很多年。本期真正值得关注的，是这类执行机制正在进入 Coding Agent 的 IDE、CLI 等产品入口。 Kiro 已提供需要主动开启的 Workflows，GitHub 的 Dynamic Workflows 在发布时仍处于公开预览阶段。

工程师开始能够在日常开发工具中，组织和检查一套持续推进的研发过程。

Coding Agent 正在接手越来越多的研发工作，Workflow 进一步解决了这些工作怎样衔接、怎样按规则推进的问题。

但能够连续执行，还不能等同于可靠交付。

系统需要知道任务进行到了哪里、哪些结果已经确认、什么情况下必须停止，以及哪些决定需要交还给工程师。

接下来值得投入的，是将团队已有的研发经验沉淀为可执行、可验证、可复用的流程，并在真实任务中不断检验和改进。