从串行审批到并行协作：一次 Router + 3 Worker 开发工作流
上一篇《AI 编码工作流的设计》里，我介绍了项目中使用的 dev-workflow：先还原背景，再制定方案，经过人工确认后编码，最后由独立 Agent 审查，并依据实际证据交付。
这套流程帮助我把需求、方案、实现和验证连接起来，也让 AI 的每一步有了可以核对的依据。使用一段时间后，另一个问题逐渐变得明显：当模型已经能处理多数常规需求时，严格串行的阶段安排会让人和 AI 花不少时间等待。
于是，我开始设计新的工作流：dev-workflow-router。由 Router 统一接收需求和反馈，再交给三个 Worker 分别完成背景与方案、编码、审查与验证，在保留人工决策权的前提下，让能够提前进行的工作尽早开始以提高效率。
下面记录这套设计的出发点、实现方式和仍然存在的短板。
一、现有工作流的问题
1. 有了质量约束，还需要关注交付效率
原来的 dev-workflow 大致按下面的顺序推进：
text
背景分析 → #0 背景确认
→ 技术方案 → #1 方案确认
→ 编码实现 → #2 实现验证与放行
→ 独立审查 → 证据验证 → 文档与交付这条链路中的每个环节都有作用。背景分析帮助确认真正要实现的目标；方案让状态归属、模块边界和兼容策略在编码前可见；独立审查提供另一种判断视角；验证则要求完成结论有证据支撑。
这些约束能提高需求被正确实现的概率，也便于发现和追踪偏差。
效率问题主要来自阶段之间的等待：背景尚未确认，方案不能正式展开；方案尚未确认，编码不能开始。即使后续大概率会接受当前分析，执行者也必须停下来等一次交互。
当需求涉及新的状态模型、复杂业务取舍或跨模块调整时，这样的等待很有价值。但对于目标清楚、已有结构稳定的任务，部分实现和准备工作其实已经可以开始了。
2. 大多数确认没有改变方向，抢跑值得尝试
按我目前在项目中的使用经验粗略估计，真正需要我在背景分析或出技术方案环节做调整的任务，大约占 10%～20%；更多时候，我阅读 AI 的分析后，只需要说确认让AI继续即可。
这个观察足以提出一个值得验证的假设：在目标和边界已经比较明确的任务里，允许 Coder 提前做一部分实现，可能减少整体等待时间。
随着模型能力提升，熟悉项目封装、读取相关代码后完成常规实现，已经是可以交给 AI 承担的工作。前置分析仍然重要，但可以进一步区分：哪些结论必须确认后才能行动，哪些工作能够在显式假设下先做。
3. 主 Agent 承担过多职责，容易成为等待点
原流程中，主 Agent 通常连续承担背景分析、方案设计、编码、验证和汇总，独立 Reviewer 在审查阶段介入。
这种安排便于保持上下文连续，但主 Agent 也会逐渐积累大量实现细节。如果它正执行耗时工具调用，或者深入某条调用链，处理新的用户反馈就可能受到影响。
与此同时，Reviewer 往往要等到正式审查时才开始建立上下文。需求、项目规范、相关模块关系等准备工作，都集中到了后半程。
这些工作可以重新分配：主会话保持对外沟通与调度，执行细节进入各自的 Worker，Reviewer 则提前准备稳定信息。
4. 小反馈的成本应该与影响范围相称
开发过程中经常出现这样的反馈：
把刚才的 3 分钟改成 5 分钟。
如果每条消息都触发一轮完整背景分析和方案设计，流程成本就会超过修改本身。
原有 dev-workflow 已经要求当前任务的反馈延续原阶段，不重新初始化流程。新的设计进一步细化了分派方式：由 Router 判断这条反馈改变了什么，直接交给需要处理它的角色。
明确的局部调整直接实施；影响不清楚的调整先做局部分析；改变目标或架构的调整，再交人工确认相应取舍。
二、Super-agent 的结构和启发
这次设计受到 DeepSeek 团队《Super-agent 设计探索：迈向更自主的 Agent 系统》的启发。原文讨论了 Router 与 Worker 分层、事件驱动、异步交互、上下文组织，以及持久运行所需的状态与环境管理。
其中，Router 维护全局交互和任务协调，Worker 在隔离的上下文中执行具体工作；耗时任务通过异步方式推进，关联信息按需要进入上下文。这些设计把一部分会话管理和任务跟进工作交回系统，也把人的注意力作为需要节省的资源。原文
1. 把对外交互和具体执行分开
对我最直接的启发，是把"与人沟通、知道工作进行到哪里"和"深入代码完成任务"分开。
人工工程师只需要持续面对 Router：提出需求、补充背景、修改要求、确认取舍、提供测试结果。具体由哪个 Worker 调查、实现或审查，由 Router 组织。
这样可以减少人工记忆和切换执行上下文的负担，也让新的反馈有一个统一入口。
2. 允许有边界的提前行动
原文讨论了根据环境信号提前尝试的投机执行思路：先投入计算，结果有价值再采用。这为 Coder 抢跑提供了一个思考角度。原文第 3.4 节
在我的开发场景里，用户已经明确提出任务，提前行动的范围也可以限定在当前项目和候选文件内。Coder 可以先形成自己的判断并做有限实现，之后再接受已确认方案的约束。
前提是这部分工作能够被调整或舍弃，且没有跨过尚未明确的技术路线、外部契约或授权边界。
3. 区分多任务调度与单任务内部协作
Super-agent 文章关注跨会话、多任务和持续运行；这次实现主要处理一个开发任务内部的角色协作。
两者处于不同层级。未来，一个更上层的任务 Router 可以调度多个开发任务，每个任务内部再运行自己的分析、编码和审查流程。当前没有必要一次实现全部层级，先验证单任务中的分工和交接是否有效，就已经有不少工作要做。
三、dev-workflow-router 的实现
1. 一个 Router，三个职责明确的 Worker
整体分工如下：
| 角色 | 核心职责 | 主要产物 |
|---|---|---|
| Router | 接收消息、判断任务归属、分派工作、维护阶段与批准、汇总交付 | 任务状态、交接信息、最终报告 |
| Worker 1：Analyst / Planner | 背景分析、技术方案、验收标准、局部影响分析 | 背景说明、方案、验证契约 |
| Worker 2：Coder | 五行骨架、有限抢跑、实现、局部调整、全部返修、最后文档维护 | 实际 diff、静态检查、实现说明 |
| Worker 3：Reviewer | 提前准备上下文、独立审查、增量复核、验收与证据核对 | 审查报告、验证报告、待人工清单 |
Router 仍然需要做轻量判断，例如一条消息属于哪个任务、是否改变当前要求、应该唤醒谁。但完整调用链调查、技术方案设计和业务实现，都交给对应 Worker。
背景分析与 Planner 放在同一个 Worker 中，是因为两者关联紧密。背景确认后，它可以继续使用已有事实制定方案，减少重复建立上下文的成本。
Coder 保留自己的实现上下文，并负责全部返修。Reviewer 专注判断和复核，不直接接管源码修改。所有人工交互由 Router 统一呈现，Worker 不各自向用户开启审批。
2. 收到第一条需求后，尽早开始三类工作
目标清楚时，Router 尽早启动三个 Worker：
- Analyst 开始恢复背景、核对目标与保留规则。
- Coder 读取原始需求和必要代码，写五行骨架，进行有限实现。
- Reviewer 读取稳定规范、已有需求和相关模块关系，准备后续审查。
这里的"并行"有明确边界。Planner 仍然等待背景 gate；Reviewer 的正式审查仍然等待实现 gate。提前开始的是已经能够独立推进的工作。
Reviewer 完成准备后即可返回等待状态，后续有新契约或审查任务时再继续，不需要为了保持三个角色"忙碌"而反复读取相同内容。
对于已经选用实验流程、但关键结构尚未确定的任务，可以使用 plan-first 模式：Coder 先做只读准备，方案确认后再实现。
3. 五行骨架：把 Coder 的初始判断留下来
Coder 如果也完整重复一遍背景调查和方案设计，并行的收益就会被重复劳动吃掉。因此，它的前置产出采用"五行骨架"：
- 状态归属。
- 重试或异常处理所在层级。
- 候选改动文件。
- 错误语义。
- 可观察的验收现象。
例如，给已有设备页增加闲置提醒时，可以这样记录。以下文件名只用于示意：
text
1. 状态归属：沿用页面现有 ViewModel 的提醒事件，UI 只负责展示。
2. 异常层级：定时任务沿用页面会话，离开页面时停止。
3. 改动文件：DeviceViewModel.kt、DeviceRoute.kt。
4. 错误语义：重新计时或页面退出后，旧任务不再触发提醒。
5. 验收判据：持续无操作达到 3 分钟时，当前页面出现提醒。这些判断如果尚未核实，就明确标成假设；不涉及的项目可以直接说明不涉及。
五行限制的是产出长度和前置决策面。实现所依赖的接口、生命周期和共享约束，仍然必须查证。不能为了写得快，就跳过会改变做法的关键事实。
骨架的价值在于：Coder 在深入实现之前留下自己的结构判断，后面可以与 Planner 的方案比较。它是否能够减少返工，还需要实际任务验证，不预设一个固定收益率。
Coder 与 Planner 的分歧越小，收益是否越大？
在任务规模、实现难度和工具环境相近，且有足够工作可以重叠的前提下，两者在关键技术决策上的分歧越小，抢跑收益通常越容易保留。
原因很直接：如果 Coder 提前实现的状态归属、模块边界和错误语义，与最终确认的方案基本一致，这部分代码就能继续使用。需要重新解释、等待裁决、推翻实现和复核的工作越少，提前开工省下的时间就越容易转化为最终交付收益。
可以用一个近似的成本关系帮助理解：
text
相对串行流程的净时间收益
≈ 分析与编码重叠省下的时间
− 并行增加的启动与协调开销
− 决策分歧带来的额外对齐和返工时间这里更值得记录的是分歧的影响。函数命名上的几处不同，可能很快就能统一；状态归属上的一处分歧，却可能改变整条实现路径。同样的分歧，开工早期发现与大量代码完成后发现，返工成本也不同。
因此，目标清楚、项目封装稳定、关键决策容易收敛的任务，更适合尝试抢跑。五行骨架与 #0/#1 的及时同步，就是为了尽早暴露并处理这些差异。
不过，双方一致仍然需要正确性证据。两个 Agent 可能共同忽略同一条约束，也可能一起作出错误判断。不能为了降低"分歧数"，让 Coder 照抄方案或压下有事实依据的异议；独立审查和运行验证继续保留。
4. 三道 gate 保留，确认结果分次同步
我保留了原流程中的三个主要人工放行点：
| Gate | 确认对象 | 通过后的动作 |
|---|---|---|
| #0 背景确认 | 场景、目标、当前行为依据、必须保留的边界 | 立即同步目标和边界，Analyst 继续制定方案 |
| #1 方案确认 | 技术决策、实现范围、验收标准、验证方式、骨架分歧 | Coder 对齐已确认方案，Reviewer 更新准备材料 |
| #2 实现验证 | 当前版本的实现、静态结果、人工测试与待验证项 | 人工放行后进入正式独立审查 |
其中有两个重要时序。
第一，背景确认后立即同步目标和边界。这样，Coder 可以尽早纠正"理解错目标"的偏差。
第二，骨架与方案的差异必须在 #1 之前形成。人工看到方案时，应当同时看到 Coder 的不同判断和事实依据，才能完成裁决。如果方案批准后才比较差异，这个 gate 就缺少一部分输入。
在前两道 gate 等待期间，Coder 可以继续推进获准的、暂定边界内的工作。用户选择这个实验流程，授权的是这种可调整的提前实现；背景和技术方案仍然要分别确认。
5. 实现完成后，先试机，再正式审查
Coder 完成本轮实现后，先交付必要的静态检查结果，以及一张可以直接操作的人工验证清单：
| 前置条件 | 操作 | 预期现象 | 对应 AC | 为什么需要人工验证 |
|---|---|---|---|---|
| 进入设备页并保持前台 | 持续不操作，等待提醒时间到达 | 只出现一次提醒 | AC1 | 需要观察真实计时和页面行为 |
| 提醒计时中 | 离开设备页 | 之后不再出现该页面提醒 | AC2 | 需要核对真实页面生命周期 |
人工工程师可以在 #2 构建、运行并完成真机验证，确认后再交 Reviewer 正式审查。这延续了原流程中的实现放行顺序。
如果人工明确要求先进入审查、尚未完成真机测试，也可以记录这次放行，但运行项必须保留为未测。进入下一阶段本身不构成运行通过的证据。
Reviewer 后续要求返修时，已有人工结果只对当时的实现有效。改变了哪些行为，就重新核对哪些行为；未受影响的结果说明依据后复用，避免每次重测全部路径。
6. "3 分钟改成 5 分钟"直接交 Coder
后续反馈不应该默认经过一遍完整分析。Router 先判断本次消息的意图和影响：
| 反馈类型 | 处理方式 |
|---|---|
| 询问进度或解释实现 | Router 根据已有事实回答，必要时向对应 Worker 取信息 |
| 明确的局部修改 | 直接交 Coder，更新受影响实现和验收预期 |
| 影响范围不清楚 | Analyst 只分析该点的影响与必要取舍 |
| 改变目标、状态归属或模块边界 | 提交局部方案差异，由人工确认改变部分 |
| 当前实现的测试失败或遗漏 | 在本任务内返修，按阶段交 Reviewer 复核 |
例如，当前已经明确讨论的是闲置提醒时长，用户提出：
把 3 分钟改成 5 分钟。
这条指令本身已经确认了该次局部调整。Router 可以直接告诉 Coder：修改提醒时长，检查相关展示和单位，同步受影响 AC，保留其他已确认规则。
无需重填五行骨架，也无需让 Analyst 重写整份方案。
如果 Coder 查到这个值同时参与其他超时约束，就把额外影响报回来，再做针对性分析。分派深度由实际影响决定，不能只凭"改一个数字"判断风险。
小反馈进入同一任务的增量记录。基础方案与当前有效增量共同构成最新契约，Analyst 可以在下次需要工作或收尾时合并相关条目，避免每次参数修改都唤醒它重新调查。
7. 复用上下文，同时保留独立判断
Reviewer 可以复用已经核实的需求、接口事实、调用关系和工程规范，这部分信息重复找一遍通常没有额外价值。
需要避免的是把实现者的探索过程和成功自评直接带入审查上下文。Reviewer 应当根据已确认契约、实际 diff 和必要调用上下文，自行作出判断。
因此，交接时重点传递目标、事实、来源、约束、文件位置和当前版本，完整探索历史留在各自上下文中，必要时再按引用回查。
共享工作区还带来一个实际问题：Analyst 正在调查原行为时，Coder 可能已经开始修改相同文件。
为此，Coder 第一次编辑目标文件前，需要保存修改前内容或"不存在"的标记。Analyst 分析原始行为时优先使用这些内容，避免把抢跑后的实现当作原有事实。这个捕获只覆盖相关文件，不复制整个仓库。
8. 所有权和版本必须明确
如果让三个 Worker 同时修改一份台账，即使各自只负责某几列，也可能发生覆盖。因此，任务产物按所有者拆开：
text
.workflow-router/<task-id>/
├── task.json Router：状态、版本、批准、增量、计数
├── background.md Analyst：背景与证据
├── plan.md Analyst：方案、决策与 AC
├── coder.md Coder：骨架、差异、实现和静态检查
├── review.md Reviewer：独立审查与复核
├── verification.md Reviewer：验收与证据
├── delivery.md Router：最终交付报告
├── baseline/ 相关文件的修改前内容
└── snapshots/ 内容快照记录源码、资源、项目配置和正式文档由 Coder 统一写入。其他角色提出问题或变更要求，通过 Router 协调，不直接改对方文件。
有效需求发生变化时，Router 增加版本号，只通知受影响的 Worker。旧版本产物到达后，先判断适用范围，不能直接覆盖最新要求。
实现快照则根据声明的写入文件和相关输入计算内容摘要，区分同一分支、同一提交之后的不同本地实现，也覆盖新增、删除文件及相关外部输入。范围声明和实际 diff 仍然需要核对，快照不会自动知道所有业务依赖。
正式审查期间暂停 Coder 的源码写入。确需调整时，先协调受影响的审查，再固定新快照，交原 Reviewer 增量复核。
9. 审查、验证和收尾仍然完整
Reviewer 同时检查两个方向：需求是否正确落实，工程实现是否可靠。问题按性质分为三类：
- ① 需求或 AC 未满足：交 Coder 修正。
- ② 工程缺陷，例如竞态、资源泄漏、错误语义不完整：交 Coder 修正。
- ③ 实现与方案发生有事实依据的结构性分歧：通过 Router 交人工裁决。
问题分类与严重程度分开记录。Reviewer 可以质疑方案，但不能自行改写方案；Coder 也不能通过修改验收标准来迎合现有代码。没有发现新问题可以是合理结果，不设置"每轮必须发现几条"的指标。
审查之后，验证报告保留四层内容：静态检查、逐条 AC、人工验证清单、边界情况分析。静态阅读、已有日志和人工真机结果分别注明来源，未测项保持待验证状态。
在我的 Android 项目里，AI 默认不主动编译项目、不新增测试用例，使用静态检查、现有证据和人工验证清单；只有明确授权后才执行相应构建或测试。这是项目的执行约束，其他项目可以按自己的验证契约安排。
审查与验证分别累计失败次数，达到三次暂停。人工可以给出指导再试一轮、明确接受已知风险跳过，或者终止。返修和更换 Worker 都不能把计数清零，跳过也不能写成通过。
代码与相关验证稳定后，再集中维护需求 HTML、相关专题文档、截图、变更记录和导航。最后由 Router 汇总审查、验证、文档结果与待办，交付一个可以继续追踪的状态。
四、展望
1. Worker 可以逐步与具体 Harness 解耦
当前三个 Worker 都由 单一Harness（例如Codex） 的委派能力调度。下一步值得实验的是：保留 Router 与角色契约，把某个 Worker 交给其他 Harness 或模型执行以提升更快的效率。
例如，Coder 是否可以交给 DSH？对于实现路径清楚的任务，能否使用响应更快的Harnesss或模型？Analyst 和 Reviewer 是否仍然保留在当前环境？
这需要先定义稳定的交接内容：任务 ID、当前版本、目标与边界、允许修改的文件、必要来源、验收标准、返回的 diff、静态检查和未验证项。
如果目标 Harness 提供可靠的启动、续工、中断和结果返回能力，就可以进一步验证这种组合。不同环境还需要解决工作区访问、基线一致性、权限边界和迟到结果处理，不能仅靠把同一段提示词复制过去。
更快的模型是否划算，也要看端到端结果：首轮编码快了一些，如果增加更多返修和人工解释，整体收益可能更差，所以更快的模型也必须聪明。
2. 随着模型能力变化，重新评估角色与 gate
当前需要显式拆开的职责，未来可能由一个模型更稳定地完成；今天必须人工介入的部分，也可能逐步具备更可靠的检查依据。
角色数量和阶段安排都可以调整。更值得保留的是目标、修改范围、重大取舍和证据边界，让模型能力提升后省下来的时间真正反映在交付中。
任何 gate 的压缩或自动化，都应有实际使用证据和明确授权，不能仅因为模型更新就推定可以省略。
3. 从聊天反馈走向任务事件
目前主要由用户消息推动流程。未来还可以接入构建结果、审查完成、测试反馈和外部依赖恢复等事件，由 Router 判断下一步应该交给谁。
这需要额外的适配和运行机制，当前尚未考虑和实现。即使将来具备了，也应该控制通知频率：有结果、需要决策或需要接管时再提示用户，避免把后台每一步都变成新的注意力负担。
五、dev-workflow-router 的短板
1. 抽象问题仍然更适合方案先行
如果需求本身还在探索，或者必须先决定状态模型、模块边界、数据归属，Coder 的初始骨架很容易与 Planner 拉开较大距离。
这类任务中，提前实现的可保留部分可能很少，对齐成本却很高。开工前已经知道这些条件时，应该优先选择原有 dev-workflow，先把背景和方案确认清楚。
2. Token 消耗通常会增加
多个 Worker 需要各自建立上下文，还会产生派工、交接、状态更新和复核开销。即使能够复用事实，也不能假设重复读取没有成本。
实际增加多少，要看任务大小、上下文裁剪、工具调用和所在环境的计费方式。目前没有足够数据给出固定倍数。
因此，投入更多计算能否换来更少的人类等待，需要逐类任务衡量。对于很小的改动，启动多个角色的开销可能就已经超过实现本身。
3. 少量大返工可能抵消多数任务的收益
10%～20% 的人工调整比例只说明调整发生得是否频繁，没有反映每次调整的成本。人工认可 Planner 的方案，也不能直接推出 Coder 的抢跑实现与这份方案一致，两种差异需要分别观察。
如果需要干预的恰好是结构性决策，Coder 可能已经完成了大量不再适用的实现。五行骨架能够提供比较基线，却无法保证初始判断正确。
这要求我们持续收窄抢跑边界，观察哪些任务适合提前做、哪些任务应该等待，而不能只根据平均确认率决定策略。
4. 并发协作增加了一致性成本
源码可能在变化，旧版本结果可能迟到，消息送达也不等于执行者已经停止。文件所有权、修改前基线和版本快照，都需要付出额外管理成本。
当前"只读 Reviewer""唯一源码写入者"首先是角色约束，并不等于操作系统已经提供独立沙箱。实际权限和隔离能力仍然取决于宿主环境。
同样，独立上下文可以减少沿用作者推导的影响，但相同模型仍可能共享盲点。关键路径需要结合代码、客观检查和真实运行证据核对。
5. 人工先试机的顺序可能带来重复验证
这次实现保留了 #2 先人工验证、再正式审查的顺序。这样，Reviewer 能获得人工反馈，但如果它随后要求改变行为，就可能需要再次试机。
通过快照和受影响范围可以减少重复测试，仍然无法完全消除这部分成本。未来是否调整顺序，要结合项目的审查发现率、构建成本和设备验证成本判断。
六、总结
原有 dev-workflow 建立了背景、方案、实现、审查和验证之间的责任链。这次实验保留这些责任，把能够独立推进的工作交给不同 Worker，并让 Router 统一处理人工交互和后续反馈。
Coder 可以在有限范围内提前实现，Analyst 持续收敛目标与技术方案，Reviewer 提前准备并独立核查结果。明确的小调整直接进入实现，新的事实和重大取舍则交给适合的角色处理。
这套设计希望减少两种成本：AI 因串行阶段而产生的等待，以及人工为推动流程而付出的持续注意力。为此投入的额外计算和一致性管理，最终是否值得，需要真实任务回答。
当前新的工作流skill为实验阶段，但方向上应该没有大的问题。