编码代理流水线为何把九成任务交给脚本

把 AI 编程流水线做得更可靠，未必需要让 Agent 接管更多环节。Oizom 团队在 Envizom 的开发流水线中，把大约 90% 的流程交给普通脚本，只让 Agent 负责单张工单里的工程实现。这是他们试过让 Agent 承担更多操作后，主动收缩出来的边界。

这套做法值得看的地方，是怎样把代码生成接进团队工作流：每张工单有独立环境，开发者通过工单反馈，脚本负责合并、部署和回滚，人负责验收。效率来自整条流水线的配合，不能只看模型写代码有多快。

Agent 负责实现，脚本负责推进流程

开发者用自然语言写好需求，把工单拖到 Approved，编排器就会为它准备一套独立环境：每个仓库都有以工单命名的分支，还有独立的 backend、drivers、simulator、frontend、开发数据库副本，以及按需签发 HTTPS 证书的私有预览地址。

Agent 在这套环境里完成工程工作，只通过工单讨论串与开发者沟通。完成后，它贴出预览链接，把工单移到 QAQC。开发者测试，再决定退回修改还是继续推进。

原文用下面这段流程图说明职责划分：

Approved ──► [scripts] provision stack ──► [agent] engineering work ──► QAQC
                                                    ▲                    │
                                                    └── feedback ────────┤
                                                                         ▼
Completed ◄── [scripts] commit, merge, PR, CI, deploy, health ◄── Git Push
     │                         │
     │                         └── unhealthy: roll back images, revert merges
     ▼
 stack torn down

要看的是包含 Git Push 的那一行：工单进入这个状态之后，就没有 Agent 参与了。提交、合并、PR、CI、部署和健康检查由脚本推进。

作者说编排器会执行八个步骤，但提供的原文没有完整列出这八步，不能据此补出执行细节。可以确认的是：如果更新后的 VM 不健康，编排器会恢复之前的镜像、撤销合并，并在工单里说明情况；健康则进入 Completed，通知开发者，随后销毁工单环境。

为什么把操作步骤从 Agent 手里收回来

他们最初让 Agent 承担过更多操作。作者给出的反馈很直接：更慢、更贵，而且在最需要稳定重复的任务上表现更差。

合并、部署、回滚的价值，恰恰在于每次遵守相同规则。让 Agent 临场判断合并策略，会增加执行方式的变数；把策略写进脚本，则能固定输入、步骤和失败处理。

流程越需要每次一致，越适合交给经过测试的脚本。

作者强调，脚本部分具有确定性，也经过测试。出了问题，可以读日志、定位并修复。这种可排查性对团队很实际：部署失败时，大家需要知道哪个步骤出了错，而不是重新理解一次 Agent 当时的决策。

不过，原文没有提供耗时、费用或失败率的对照数据。「更慢、更贵、更差」是他们团队的实践判断，不能直接推成所有团队都成立的量化结论。大约 90% 也没有说明按代码量、步骤数还是其他口径计算，更适合看作职责分配的描述。

独立环境让 Agent 能改代码，也能准备测试数据

作者演示的是设备页面上的摄像头布局调整。Agent 完成第一版并给出预览后，作者在工单里追加要求：超过 4 个摄像头时支持横向滚动，并在该设备上准备 8 个测试摄像头。

Agent 接着完成了界面修改和测试数据创建，延续了此前的上下文。

这个例子里，隔离环境起了关键作用。数据库是工单自己的副本，测试数据不会写进其他工单使用的数据。多张工单因此可以并行推进：一张停在 QAQC 一周，也不妨碍另外三张交付。

同时，他们保留了两个人工边界。其一，QA 由开发者完成，开发者打开预览并决定是否放行。其二，这条流水线只到 dev 环境，自动合并、回滚和 VM 更新都限定在这里；生产环境走另一条路径，由人决策，节奏也更慢。

原文展示的是开发环境自动化，不能直接当成生产自动发布方案。

我的判断

我赞同把重复操作固化为脚本，把需求理解和代码实现留给 Agent。相比让 Agent 一路操作到部署，这种分工更容易把失败收敛到具体步骤；相比单独让 Agent 生成代码，它又补上了预览、反馈和交付的连接。

但可迁移的部分有前提。每张工单都能获得完整服务和数据库副本，需要已有的环境自动化能力，也会带来资源和维护成本。原文没有说明数据库复制耗时、环境成本，以及多工单修改同一处代码时怎样处理冲突。

人工 QA 也不能理解为测试已经充分。文中确认开发者会验收预览，但没有交代自动测试覆盖范围、CI 放行条件和健康检查标准。这些细节会直接影响脚本能否安全推进。

因此，我更愿意借鉴它的职责边界，而不是照搬「90%」这个比例。对已经有 CI/CD 的团队，先把现有流程接成可靠闭环，往往比重建整套工单环境更可行。

能拿来做什么

• 先梳理日常 AI 编程中的重复操作，把创建分支、运行检查、生成预览和发起 PR 等固定步骤写成脚本，让 Agent 调用明确入口。
• 给前端页面修改配上可访问的预览和隔离测试数据。验收横向滚动这类需求时，明确提供超过 4 项、共 8 项的数据条件，比只描述布局更方便检查。
• 把需求补充和返工意见留在同一张工单里，让 Agent 能接续上下文，也让开发者能追溯验收要求。
• 接入自动合并和回滚前，先明确它们作用于哪个环境，并保留人工验收节点；原文能够支持的实践范围是 dev。