从串行审批到并行协作：一次 Router + 3 Worker 开发工作流
上一篇《AI 编码工作流的设计》里，我介绍了项目中使用的 dev-workflow：先还原背景，再制定方案，经过人工确认后编码，最后由独立 Agent 审查，并依据实际证据交付。
这套流程帮助我把需求、方案、实现和验证连接起来，也让 AI 的每一步有了可以核对的依据。使用一段时间后，另一个问题逐渐变得明显：当模型已经能处理多数常规需求时，严格串行的阶段安排会让人和 AI 花不少时间等待。
于是，我开始设计新的工作流：dev-workflow-router。由 Router 统一接收需求和反馈，再交给三个 Worker 分别完成背景与方案、编码、审查与验证，在保留人工决策权的前提下，让能够提前进行的工作尽早开始以提高效率。
下面记录这套设计的出发点、实现方式和仍然存在的短板。
一、现有工作流的问题
1. 有了质量约束，还需要关注交付效率
原来的 dev-workflow 大致按下面的顺序推进：
背景分析 → #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
整体分工如下：
flowchart TD
H["人工工程师"] <-->|"需求、反馈、确认、验收"| R["Router"]
R <-->|"背景、方案、局部影响分析"| P["Worker 1: Analyst / Planner"]
R <-->|"实现、调整、返修"| C["Worker 2: Coder"]
R <-->|"准备、审查、验证"| V["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 如果也完整重复一遍背景调查和方案设计，并行的收益就会被重复劳动吃掉。因此，它的前置产出采用“五行骨架”：
- 状态归属。
- 重试或异常处理所在层级。
- 候选改动文件。
- 错误语义。
- 可观察的验收现象。
例如，给已有设备页增加闲置提醒时，可以这样记录。以下文件名只用于示意：
1. 状态归属：沿用页面现有 ViewModel 的提醒事件，UI 只负责展示。
2. 异常层级：定时任务沿用页面会话，离开页面时停止。
3. 改动文件：DeviceViewModel.kt、DeviceRoute.kt。
4. 错误语义：重新计时或页面退出后，旧任务不再触发提醒。
5. 验收判据：持续无操作达到 3 分钟时，当前页面出现提醒。
这些判断如果尚未核实，就明确标成假设；不涉及的项目可以直接说明不涉及。
五行限制的是产出长度和前置决策面。实现所依赖的接口、生命周期和共享约束，仍然必须查证。不能为了写得快，就跳过会改变做法的关键事实。
骨架的价值在于：Coder 在深入实现之前留下自己的结构判断，后面可以与 Planner 的方案比较。它是否能够减少返工，还需要实际任务验证，不预设一个固定收益率。
Coder 与 Planner 的分歧越小，收益是否越大？
在任务规模、实现难度和工具环境相近，且有足够工作可以重叠的前提下，两者在关键技术决策上的分歧越小，抢跑收益通常越容易保留。
原因很直接：如果 Coder 提前实现的状态归属、模块边界和错误语义，与最终确认的方案基本一致，这部分代码就能继续使用。需要重新解释、等待裁决、推翻实现和复核的工作越少，提前开工省下的时间就越容易转化为最终交付收益。
可以用一个近似的成本关系帮助理解：
相对串行流程的净时间收益
≈ 分析与编码重叠省下的时间
− 并行增加的启动与协调开销
− 决策分歧带来的额外对齐和返工时间
这里更值得记录的是分歧的影响。函数命名上的几处不同，可能很快就能统一；状态归属上的一处分歧，却可能改变整条实现路径。同样的分歧，开工早期发现与大量代码完成后发现，返工成本也不同。
因此，目标清楚、项目封装稳定、关键决策容易收敛的任务，更适合尝试抢跑。五行骨架与 #0/#1 的及时同步，就是为了尽早暴露并处理这些差异。
不过，双方一致仍然需要正确性证据。两个 Agent 可能共同忽略同一条约束，也可能一起作出错误判断。不能为了降低“分歧数”，让 Coder 照抄方案或压下有事实依据的异议；独立审查和运行验证继续保留。
4. 三道 gate 保留，确认结果分次同步
我保留了原流程中的三个主要人工放行点：
其中有两个重要时序。
第一，背景确认后立即同步目标和边界。这样，Coder 可以尽早纠正“理解错目标”的偏差。
第二，骨架与方案的差异必须在 #1 之前形成。人工看到方案时，应当同时看到 Coder 的不同判断和事实依据，才能完成裁决。如果方案批准后才比较差异，这个 gate 就缺少一部分输入。
在前两道 gate 等待期间，Coder 可以继续推进获准的、暂定边界内的工作。用户选择这个实验流程，授权的是这种可调整的提前实现；背景和技术方案仍然要分别确认。
5. 实现完成后，先试机，再正式审查
Coder 完成本轮实现后，先交付必要的静态检查结果，以及一张可以直接操作的人工验证清单：
人工工程师可以在 #2 构建、运行并完成真机验证，确认后再交 Reviewer 正式审查。这延续了原流程中的实现放行顺序。
如果人工明确要求先进入审查、尚未完成真机测试，也可以记录这次放行，但运行项必须保留为未测。进入下一阶段本身不构成运行通过的证据。
Reviewer 后续要求返修时，已有人工结果只对当时的实现有效。改变了哪些行为，就重新核对哪些行为；未受影响的结果说明依据后复用，避免每次重测全部路径。
6. “3 分钟改成 5 分钟”直接交 Coder
后续反馈不应该默认经过一遍完整分析。Router 先判断本次消息的意图和影响：
例如，当前已经明确讨论的是闲置提醒时长，用户提出：
把 3 分钟改成 5 分钟。
这条指令本身已经确认了该次局部调整。Router 可以直接告诉 Coder：修改提醒时长，检查相关展示和单位，同步受影响 AC，保留其他已确认规则。
无需重填五行骨架，也无需让 Analyst 重写整份方案。
如果 Coder 查到这个值同时参与其他超时约束，就把额外影响报回来，再做针对性分析。分派深度由实际影响决定，不能只凭“改一个数字”判断风险。
小反馈进入同一任务的增量记录。基础方案与当前有效增量共同构成最新契约，Analyst 可以在下次需要工作或收尾时合并相关条目，避免每次参数修改都唤醒它重新调查。
7. 复用上下文，同时保留独立判断
Reviewer 可以复用已经核实的需求、接口事实、调用关系和工程规范，这部分信息重复找一遍通常没有额外价值。
需要避免的是把实现者的探索过程和成功自评直接带入审查上下文。Reviewer 应当根据已确认契约、实际 diff 和必要调用上下文，自行作出判断。
因此，交接时重点传递目标、事实、来源、约束、文件位置和当前版本，完整探索历史留在各自上下文中，必要时再按引用回查。
共享工作区还带来一个实际问题：Analyst 正在调查原行为时，Coder 可能已经开始修改相同文件。
为此，Coder 第一次编辑目标文件前，需要保存修改前内容或“不存在”的标记。Analyst 分析原始行为时优先使用这些内容，避免把抢跑后的实现当作原有事实。这个捕获只覆盖相关文件，不复制整个仓库。
8. 所有权和版本必须明确
如果让三个 Worker 同时修改一份台账，即使各自只负责某几列，也可能发生覆盖。因此，任务产物按所有者拆开：
.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为实验阶段，但方向上应该没有大的问题。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
From Serial Approval to Parallel Collaboration: One Router + 3 Worker Development workflow
In the previous article, " Design of the AI code workflow ", I presented the dev-workflow used in the project: returning to the background, then developing the program, encoded after human confirmation, and finally reviewed by independent Agent and delivered on the basis of actual evidence.
This process helps me to connect needs, programs, realization and validation, and gives AI a basis for checking each step. Another problem became apparent after some time of use: when models were already able to handle most of the conventional needs, a strict sequenced phase would take time to wait with AI.
So I started designing a new workflow:dev-workflow-router. Reconciling demand and feedback with Router, with three workers each completing background and programme, coding, review and validation, allowing for early commencement of work that could be done earlier, while retaining manual decision-making power.
The starting point for the design, the way in which it was achieved and the fact that it still existed are recorded below.
Question of the existing workflow
1. Quality constraints also require attention to delivery efficiency
The old dev-workworkwork moves more or less in the following order:
Background analysis #0 Background confirmation
Technical programme #1 Programme confirmation
Encoding achieves #2 Validation and Release
Independent review, evidence validation, documentation and delivery
Every link in this chain works. Background analysis helps to identify what is really being achieved; programmes allow for the attribution of status, modular boundaries and compatibility strategies to be visible before coding; independent reviews provide another perspective of judgement; and validation requires evidence to support the conclusion.
These constraints increase the probability that demand will be correctly achieved and facilitate the detection and tracking of deviations.
Efficiency issues arise mainly from inter-stage waiting: background has not been confirmed, programmes cannot be formally launched, programmes have not been confirmed and codes cannot begin. Even if the follow-up rate would be subject to current analysis, the implementer would have to stop and wait for an interaction.
This waiting is valuable when needs involve new state models, complex business trade-offs or cross-module adjustments. However, partial realization and preparation for a well-targeted and structurally stable mandate can begin.
2. Most confirmed that they had not changed direction and that it was worth trying.
Based on my current experience with the project, a rough estimate of what really needs to be done in terms of my background analysis or technical programme, which is about 10-20%; more often, when I read the AI analysis, I just have to say that I want to let AI continue.
This observation is sufficient to provide a testimonial hypothesis: In missions where objectives and boundaries are more clearly defined, Coder is allowed to do so in part in advance, possibly reducing overall waiting time.
With enhanced modelling capacity, familiarization with project encapsulation, reading of relevant codes, and completion of routine implementation, it is already possible to delegate to AI. Pre-analysis remains important, but can be further distinguished: What conclusions must be identified before action can be taken, and what can be done first under the obvious assumption.
3. Lord Agent takes too much responsibility and can easily become a waiter Points
In the original process, the main Agent usually carries on a continuous background analysis, programme design, coding, validation and aggregation, with independent Reviewer intervening at the review stage.
This arrangement facilitates the continuity of context, but the master Agent will also gradually accumulate substantial realization details. If it is implementing time-consuming tool call, or deep into a call chain, processing new user feedback may be affected.
At the same time, Reviewer often waits for a formal review to begin the establishment of context. The preparation of needs, project specifications, related modular relationships, etc., was concentrated in the latter half of the process.
This work can be redistributed: the main session will maintain external communication and movement, the execution details will enter the respective worker, and the Reviewer will be prepared to stabilize the information in advance.
4. The cost of small feedback should be commensurate with the scope of impact
This is often the case in the development process:
Change the last three minutes to five minutes.
If every message triggers a full set of background analysis and programme design, the process cost exceeds the modification itself.
The original dev-workflow already requires that feedback from the current task be extended without re-initiating the process. The new design further refines the way it is distributed: Router judges what this feedback has changed and gives it directly to the role that needs to be addressed.
Clear local adjustments are implemented directly; adjustments with unclear impact are analysed locally; adjustments to objectives or structures are changed before human confirmation is given the corresponding trade-off.
II. Structure and inspiration of Super-agent
The design was inspired by the DeepSeek team's Super-Agent Design Exploration: Towards a more autonomous Agent system. The original text discusses Router and Worker layers, event-driven, heterogeneity, context, and state and environmental management required for sustainable operation.
Of these, Router maintains global interactivity and task coordination, and Wocker carries out specific tasks in the isolated context; time-consuming tasks are carried out in a step-by-step manner, with associated information entering context as required. These designs turn back part of the session management and task follow-up system and also focus on people as resources that need to be saved. Original
1. Separate external interaction and implementation
The most direct inspiration for me is the separation of “communicating with people, knowing where work is going” and “in-depth code completion”.
The manual engineers need only face Router on an ongoing basis: demand, background supplements, modification requirements, confirmation of trade-offs, and test results. By which Worker investigates, realizes or reviews, organized by Router.
This would reduce the burden of manual memory and switchover for the implementation of context, and would provide a single entry point for new feedback.
2. Allowing advance movement with borders
The idea of speculative implementation based on an advance attempt at environmental signals was discussed in the original text: input into the calculations, the results were valuable and then used. This gives Coder a think-and-think perspective to rob. Original Section 3.4
In my development scene, the user has clearly identified the tasks, and the scope for early action can also be limited to current projects and candidate documents. Coder can form his own judgement and make limited realization before being bound by the confirmed programme.
This is provided that this part of the work can be adjusted or abandoned and that it does not cross undefined technical routes, external contracts or authorized borders.
3. Distinguishing multi-task movement from single-task internal collaboration
The Super-Agent article focused on cross-conferences, multitasks and running on a continuous basis; this led to a role collaboration that dealt primarily with a development mission.
The two are at different levels. In the future, a more senior task, Router, can deploy multiple development tasks and re-run its own analysis, coding and review processes within each mission. Much remains to be done to verify the effectiveness of the division of labour and the handover in the single task without the need to achieve all levels at once.
III. IMPLEMENTATION OF dev-workflow-router
1. One Router, three well-defined worker
The overall division of labour is as follows:
flowchart TD
H ["Advanced Engineer"] < ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
"R" background, program, local impact analysis" P["Worker 1: Analyst / Planner"
["Worker 2: Code"]
R---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Router still needs to make light judgements about, for example, what task a message is, whether to change current demands and who should be awakened. However, the complete call chain survey, technical programme design and operational realization are delegated to the corresponding Worker.
Background analysis and Planner are in the same worker because they are closely linked. Following confirmation of the background, it could continue to use existing factual programming to reduce the cost of re-establishing context.
Coder retains his own realization context and is responsible for all repairs. Reviewer focuses on judgement and review and does not take over the source code modification directly. All manual interactions are presented uniformly by Router, and Worker does not separately open approvals to users.
2. Start three types of work as early as possible upon receipt of Article 1 needs
When the target is clear, Router starts three workers as soon as possible:
- Analyst began to restore the background, check the object and the reservation rule.
- Coder reads the original requirements and the necessary codes, writes the five-line skeletons and performs limited realization.
- Reviewer to read stable norms, existing needs and related modular relationships and prepare for follow-up review.
The “parallel” here has clear boundaries. Planner is still waiting for background gate; Reviewer's formal review is still waiting for date. What started earlier was work that had been able to move forward independently.
Reviewer is ready to return to the status of waiting and continues after a new contract or review mission, without having to read the same content repeatedly in order to keep the three roles “working”.
For tasks that have been selected for the experimental process but for which the key structure has not yet been defined, the plan-first model can be used: Coder is prepared for reading-only, the program is confirmed before it is achieved.
3. Five-line skeleton: leave Coder 's initial judgment behind
If Coder also repeats the background survey and programme design in its entirety, the parallel proceeds will be eaten by repeated efforts. Thus, its pre-products are “five-line skeletons”:
- State belongs.
- retry or the level of unusual treatment.
- Candidate change document.
- Wrong semantics.
- Observable acceptance check.
This can be done, for example, by adding idle alarms to existing device pages. The following filenames are used only for indicative purposes:
1. Attribution: Following the existing ViewModel alert on the page, UI is responsible for displaying only.
Anomalous level: A time job follows a page session and stops when leaving the page.
3. Change documents: DeviceViewModel.kt, DeviceRoute.kt.
Error semantics: The old task no longer triggers the alarm after a time count or page exit.
5. acceptance check: Reminders appear on the current page after 3 minutes of continuous inoperable.
If not yet verified, these judgements are clearly presented as assumptions; projects not covered can be directly accounted for.
The five-line limitation is on output length and pre-decision-making. The implementation of the interfaces, life cycles and shared constraints on which it depends must still be verified. The key facts that change practice cannot be bypassed to write fast.
The value of the skeleton is that Coder left his own structural judgement before going deep, then compared to Planner's program. Whether it could reduce back-to-work would also require actual mission validation without a fixed rate of return.
Is the greater the difference between Coder and Planner?
The smaller the differences between the two in key technical decision-making, the easier to retain the proceeds, given the scale of the task, the difficulty of achieving it and the proximity of the tool environment and the overlap of sufficient work.
The reason is straightforward: this part of the code can continue to be used if Coder achieves early attribution of status, modular boundaries and incorrect semantics, which are generally consistent with the eventually confirmed program. The fewer work needs to be done to reinterpret, wait for a decision, reverse realization and review, the easier it will be to begin work sooner and more easily to translate into the final delivery of proceeds.
A similar cost relationship can help to understand:
Net time gain relative to serial processes
Analysis and coding overlap save time
- Additional start-up and coordination costs in parallel
- Additional alignment and back-to-work times resulting from differences in decision-making
What is more worth recording here is the impact of differences. The difference in the name of the function may quickly unite; a difference in the attribution of status may change the entire path of achievement. The same differences, with early detection of work and the completion of a large number of codes, reveal that the back-to-work costs are different.
As a result, well-targeted, project envelopes are stable, key decision-making tasks are easy to absorb and are better suited to try to run. The timely synchronization of the five-line skeleton with #0/#1 is intended to expose and address these differences as soon as possible.
However, there is still a need for evidence of correctness, consistent with the parties. The two Agents may jointly ignore the same constraints or make a miscalculation together. In order to reduce the number of “disagreements”, Coder could not copy the programme or press down factual objections; independent review and operational validation would remain.
4. Three slots are reserved, confirmation results are synchronized
I retained three main manual release points in the original process:
There are two important time lines.
First, the objectives and borders are synchronized as soon as the background is confirmed. Thus, Coder can correct the bias of “understanding the wrong target” as soon as possible.
Second, the difference between the skeleton and the program must be formed before #1. When the programme is seen manually, it should be accompanied by a different judgement and factual basis from Coder to complete the award. If you compare the difference after the program is approved, this gate is missing a part of the input.
During the first two Gates waiting periods, Coder could continue work within the approved and provisional borders. Users choose this experimental process with the authorization of this adjustable advance; background and technical options are still subject to separate confirmation.
5. Once achieved, test before formal review
After completion of this round, Coder delivers the necessary static check results and a manual validation list that can be operated directly:
Artificial engineers can build, run and complete real machine validation at #2 and then submit the Reviewer formal review. This continues the sequence of release achieved in the original process.
This release may also be recorded if the manual explicitly requires access to the review and the real machine test has not been completed, provided that the operating item is kept as undetermined. Moving to the next stage does not in itself constitute evidence of operational passage.
At the time of the subsequent request of Reviewer, manual results had been valid only for what had been achieved at that time. The behaviour that has been changed is re-checked; the unaffected result indicates a re-use of the basis to avoid a full re-examination of the path at a time.
“3 minutes to 5 minutes” direct delivery
Follow-up feedback should not implicitly undergo a full analysis. Router first judged the intentions and implications of this message:
For example, what has been clearly discussed at this point is the length of the idle reminder period, where users suggest that:
Change 3 minutes to 5 minutes.
This partial adjustment has been confirmed by the Directive itself. Router can tell Coder directly: modify the alarm time, check the relevant displays and units, synchronize the affected AC, and keep other confirmed rules.
There is no need for a refill of five skeletons or for Analyst to rewrite the entire project.
If Coder finds out that this value is also involved in other timeout constraints, he returns the additional effects and then makes a targeted analysis. The depth of assignment is determined by the actual impact, and risk cannot be judged solely by a “change to a number”.
Small feedback entered the incremental record of the same task. The basic program, together with the current effective increment, constitutes the most up-to-date contract, and Analyst can consolidate the entries at the next time it needs to work or close, so that each parameter modification does not awaken it to resurvey.
7. Reuse context while retaining independent judgement
Reviewer can revert to verified needs, interface facts, call relationships and engineering specifications, a part of which is often of no added value.
What needs to be avoided is that the process of the realization and the successful self-assessment are brought directly into the review of context. Reviewer should make its own judgement on the basis of the confirmed contract, actual diff and the required context call.
Thus, at the time of the handover, emphasis is placed on the transmission of the objectives, facts, sources, constraints, location and current version of the document, and the complete history of exploration is left in their respective contexts, which are re-referenced as necessary.
The shared workspace also poses a practical problem: when Analyst is investigating the original act, Coder may have begun to modify the same document.
For this reason, Coder needs to save the pre-modification content or the " non-existent " tag before first editing the target file. Analyst gives priority to the use of these elements in its analysis of the original act and avoids treating post-run realization as a pre-existing fact. This capture covers only relevant documents and does not copy the entire warehouse.
8. Ownership and version need to be clear
If three Walkers change one account at the same time, even if each is responsible for only a few columns, it can happen. The mission product is therefore divided by owner:
.workflow-router/<task-id>/
Ideas - task.json Router: Status, version, approval, increment, count
- Background.md Analyst: Background and evidence
– plan.md Analyst: Programs, Decision Making and AC
Ideas - coder.md Coder: skeleton, difference, realization and static check
— review.md Reviewer: independent review and review
Ideas-verification.md Reviewer: acceptance check and evidence
Ideas -- final.md Router: Final delivery report
Ideas - Baseline/ Before Changes to Related Documents
└ - snapshots/ content snapshot
The source code, resources, project configuration and official document are integrated into the Coder. Other players ask questions or change requests and do not change documents directly through Router coordination.
When a valid demand changes, Router adds a version number to notify only Worker affected. Once the old version has arrived, the scope of application is judged and the latest requirements cannot be directly covered.
Accomplishing snapshots is calculated on the basis of the written document of the declaration and the relevant input summary, distinguishing between the same branch, different local realizations after the same submission, and also covering new, deleted files and related external inputs. The scope statement and the actual diff still need to be reconciled and the snapshot does not automatically know all business dependencies.
The Code Code for Coder was suspended during the official review. When adjustments are required, the impact reviews are coordinated and new snapshots are fixed and the original Reviewer incremental reviews are submitted.
9. Review, validation and closure remain complete
Reviewer also checks two directions: whether the needs are correctly met and whether the work is reliable. The questions are divided into three categories by nature:
-1 Needs or AC not met: submit Coder amendment.
- 2 Project defects such as competition, leakage of resources, incomplete synonyms: refer to Coder amendment.
- 3 Structural differences between realization and the programme on the basis of facts: manual adjudication through Router.
The classification of problems is recorded separately from the severity. Reviewer can question the scheme, but cannot rewrite it; Coder cannot adapt the existing code by modifying acceptance criteria. No new problems were identified that could reasonably result in the absence of “a few to be found per round” indicators.
Following the review, four layers of the validation report were retained: static checks, article-by-article AC, manual validation lists, and boundary situation analysis. Static readings, logs already available and artificially authentication results are given, respectively, and untested items remain to be verified.
In my Android project, AI defaults not to compile the project on its own initiative, to add examples of testing, to use static checks, available evidence and manual validation lists; construction or testing is performed only after a clear authorization. This is a constraint on the implementation of the project, and other projects may be subject to their own contractual arrangements for certification.
The cumulative number of failures of review and certification was three times suspended. Manuals can give guidance for another round, explicitly accept known risks to skip or terminate. Neither the back-up nor the replacement of the Worker count is complete, and skipping cannot be written.
Once the code is stabilized with the relevant authentication, the need for HTML, relevant thematic documents, screenshots, change records and navigation is centralized. Finally, Router consolidates the review, validation, document results and to-do to deliver a state that can be followed up.
IV. Outlook
1. Worker can gradually decompose with specific Harness
Currently, all three workers are being moved by a single Harness (e.g. Codex) delegated capacity. next step is worth experimenting with: keeping Router and the role contract and handing over a worker to another Harness or model to improve efficiency.
For example, can Coder give it to DSH? Can more responsive Harnesss or models be used to achieve tasks with clear paths? Is Analyst and Reviewer still in the current environment?
This requires the first definition of a stable intersection: mission ID, current version, target and boundary, document permitting modification, necessary sources, acceptance criteria, returned diff, static check and unverified entry.
This combination can be further validated if the target Harness provides reliable start-up, renewal, interruption and return capability. Different environments also need to address work-zone visits, baseline consistency, permission boundaries and late outcome processing, and not simply copying the same paragraph prompt.
The cost-effectiveness of a faster model also depends on the end-to-end result: the first-round code is faster, the overall return may be worse if more repairs and manual explanations are added, so the faster model must also be smart.
2. Reassess role and date as model capacity changes
There is a need for visible detached responsibilities, which may be done more steadily in the future by a model; those parts of the world that have to be physically involved today may also gradually have a more reliable basis for inspection.
The number of roles and stage arrangements can be adjusted. What is more worth retaining are objectives, scope modifications, major trade-offs and evidentiary boundaries, so that the time saved by enhanced modelling capacity is truly reflected in delivery.
Any gase compression or automation should be supported by evidence of actual use and clear authorization and should not be presumed to be omitted simply because the model is updated.
3. From chat feedback to mission events
The process is currently largely driven by user messages. Future events such as construction results, review completion, test feedback and recovery of external dependence can also be accessed, and Router will judge to whom next step should be handed over.
This requires additional adaptation and operational mechanisms that have not yet been considered and realized. Even if they are available in the future, the frequency of notification should be controlled: to alert users when there is a result, a decision is needed or a takeover is required, and to avoid turning every step of the back office into a new burden of attention.
V, Dev-workflow-router
1. The abstract is still more appropriate for programme priorities
If the demand itself is still being explored, or if the status model, the modular boundary, and the data attribution must be determined first, Coder ' s initial skeleton can easily be pulled away from Planner.
In such missions, the retention component may be minimal and the cost of alignment is high. When these conditions are known before work starts, preference should be given to the original dev-workflow, with clear background and programme.
Token consumption usually increases
Multiple Workers are required to establish context each, which will also result in assignment, handover, status update and review costs. Even if the facts could be repeated, it could not be assumed that repeated reading would be cost-neutral.
The actual increase depends on the size of the mission, the cut of context, the billing of tool call and the environment. There is currently insufficient data to give a fixed multiple.
Therefore, the ability to invest in more calculations in less human waiting needs to be measured on a task-by-mission basis. For minor changes, the cost of starting multiple roles may have exceeded realization itself.
3. Small returns may offset the benefits of most missions
The ratio of manual adjustments of 10 to 20 per cent only indicates whether the adjustment is frequent and does not reflect the cost of each adjustment. The manual approval of Planner's program and the direct roll-out of Coder's run-off are not consistent with this program, and the two differences need to be observed separately.
Coder may have achieved a significant amount of non-applicability if the intervention was just a structural decision. Five-line skeletons provide a comparative baseline but do not guarantee that the initial judgement is correct.
This requires us to continue to narrow our borders and to observe which tasks are suitable for earlier and which tasks should wait, rather than deciding on strategies based solely on average recognition rates.
Consistency increases the cost of coherence
The source code may change, the results of the old version may be late and delivery of the message does not mean that the implementer has ceased. Document ownership, pre-modification baseline and version snapshots require additional administrative costs.
The current "Read-only Reviewer" "sole source writer" is first and foremost a role constraint and does not mean that the operating system already provides independent sandboxes. The actual permission and isolation capacity still depend on the host environment.
Similarly, independent context can reduce the influence of the use of the author's extrapolation, but the same model may still share blind spots. Key pathways require a combination of codes, objective checks and true running evidence checks.
The sequence of artificial first-testers may lead to double validation
This time, the sequence #2 was retained for manual validation and formal review. In this way, Reviewer receives manual feedback, but if it subsequently requests a change of behaviour, it may need to be tested again.
Through snapshots and impact ranges, duplication of tests can be reduced and this part of the cost cannot be completely eliminated. Whether or not to reorder in the future should be judged in the light of the project ' s finding rate, construction costs and equipment validation costs.
Summary
The old dev-workflow establishes a chain of responsibility between context, programme, realization, review and certification. The experiment retains these responsibilities, entrusts work that can be carried out independently to different working groups, and allows Router to process manual interaction and follow-up feedback in a unified manner.
Coder can be achieved in advance on a limited scale, Analyst's objective and technical programme, Reviewer's pre-prepared and independently verified results. Clear minor adjustments go directly into reality, while new facts and major trade-offs are left to the right players.
The design seeks to reduce two types of costs: AI ' s waiting period as a result of the symbiosis phase, and the sustained attention paid to manual process facilitation. real task is required to answer whether the additional computing and consistency management input for this purpose is ultimately worth it.
The current pilot phase of the new workflowskill should have no major problems of direction.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.