编码 Agent 交付流程如何设置人工验收

开发者把 ticket 拖到 Git Push 后，从提交代码到对开发 VM 进行健康检查，八个步骤会自动执行。这些步骤都没有 Agent 参与。而在它们之前，始终有一个由人完成的步骤：提出变更需求的开发者打开预览，判断结果是不是自己想要的。

我是 Panth，负责 Oizom 的软件团队，我们的平台叫 Envizom。这篇文章讲的是 Agent 流水线中这唯一一个人工步骤：它处于什么位置、检查什么，以及我们为什么刻意保留它。

开发者在 ticket 里用日常英语写下需求，然后把它拖到 Approved。我们的编排器 orch 会为这个 ticket 分配一套独立环境：每个代码仓库各有一个分支、独立的服务、一份开发数据库副本，以及一个私有预览 URL。coding Agent 就在这套环境里完成工作。

Agent 完成后，会把预览链接发到 ticket 讨论串里，再将 ticket 移到 QAQC。它的工作到这里就停下了。Agent 永远不会把自己的工作标记为完成。

Approved ──▶ agent works in the ticket's own stack
                │
                ▼
             QAQC  ◀──── feedback in the thread, ticket moved back
                │            (same agent, same context)
                │ a person tests the preview
                ▼
            Git Push ──▶ 8 scripted steps, no agent ──▶ dev VM
                                                       (rollback if unhealthy)

提出需求的开发者打开预览并测试。如果哪里不对，就在同一个讨论串里回复，再把 ticket 移回去。同一个 Agent 会带着原有上下文接手，继续处理。

在演示视频里，我要求调整设备页面上的摄像头布局。Agent 完成修改后发出了预览。我的 QA 回复是：“还要处理超过 4 个摄像头的情况，支持横向滚动，并在这台设备上配置 8 个测试摄像头。”Agent 完成了这两项工作，而且测试数据建在这个 ticket 独有的数据库副本里，因此它新增的内容不会影响其他人的数据。

这条消息既是 QA 反馈，也是新需求。它传给 Agent 的方式与最初的需求相同：写在 ticket 讨论串里。

QA 这一步，就是由人来检查：做出来的东西，是不是当初要求的东西。

如果让 Agent 给自己的工作打分，最重要的那次审核就消失了。后面的每一步都被设计成按部就班、可以重复执行的操作，没有哪一步会判断这次变更是不是做对了方向。QA 是整个流水线里唯一会问这个问题的地方，所以它也是我们唯一没有自动化的环节。

这也让记录忠实反映实际过程。最初提了什么需求、做出了什么、测试的是哪个预览、又反馈了什么，都留在同一个 ticket 讨论串里。而决定交付的，是人在这个讨论串中的操作，不是 Agent。

QA 之后的一切都交给脚本

开发者满意后，会把 ticket 拖到 Git Push。接下来，orch 会：

如果之后 VM 的健康检查未通过，orch 会将它回滚到之前的镜像，撤销合并，并在讨论串里说明发生了什么。如果健康检查通过，ticket 就会移到 Completed，开发者也会收到通知。

这里没有任何 Agent 参与。整个过程是确定性的，经过测试；出问题时，我会查看日志并修复。这就是我敢把合并和部署交给机器的原因：整条链路中唯一需要人做判断的地方，已经由人完成了。

所有这些自动化操作，包括自动合并、更新 VM 和回滚，都止步于开发环境。生产环境走另一条独立流程，由人做决定，节奏也更慢。

这同样是刻意的安排。我们不希望由自动化来决定什么能进入生产环境，也不希望把快速堆出一串功能变成目标。开发环境中的人工 QA，与生产发布时的人工决策，是两道不同的检查，我们都保留了。

我自己的审核提前了

QA 是开发者的步骤。我的审核发生在任何东西开始构建之前。我会阅读架构文档、计划和 prompt，它们能让我了解接下来大约 90% 的内容。剩下的 10%，则是检查产出并编写 QAQC 测试用例。

所以，Agent 处于两种人工把关之间：输入端是计划和 prompt，输出端是预览测试。中间的工程实现由它完成，工作环境则只为它当前的 ticket 而存在。

如果你也准备搭建这套流程

给 Agent 设置一个停下来的位置，而且这个位置不能叫“完成”。对我们来说，它是一列名为 QAQC 的状态、一个预览链接，以及一个接收回复的讨论串。让提出变更需求的人负责测试，因为只有他们才知道自己原本想要什么。然后，把这次决策之后的一切写成脚本，并让这些自动化操作止步于生产环境之前。

如果你的团队也在使用 coding Agent，由谁来决定任务已经完成：是 Agent，还是提出需求的人？

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。