一套真正有用的多 Agent 编程工作流，并不是先尽可能多开几个 Agent Session，而是先定义一个明确结果，再沿着清楚的所有权边界拆分任务，最后判断哪些工作可以安全并行。
最实用的原则是：互不依赖的调查和编辑可以并行；涉及同一份合同、文件或唯一事实来源的决定与修改应该串行。每一项产出都要能被检查，并在最终接受结果前保留一个人工 Review Gate（审查关口）。
Agent.Space 可以把多个 Agent Session、已保存文件、Queue 与 Preview 放进同一个云端 Workspace。共同环境让协调过程更容易看清，但不会自动分配任务、为每个 Session 创建私有分支，也不会自动合并冲突；整个工作流仍然需要一位明确负责人。
什么时候值得使用多个 Coding Agent？
当一项工作确实包含可以分开的子任务时，多个 Agent 才会带来价值。例如：
- 分别梳理代码库中两个互不依赖的区域；
- 一个 Session 实现边界明确的改动，另一个准备测试用例；
- 先完成实现，再交给独立 Session 做 Review；
- 分别产出不同材料，最后在一个已经约定的接口处汇合；
- 在不同时修改同一文件的前提下，并行调查几种可能原因。
如果下一步仍取决于一个尚未决定的问题，多项任务都必须改同一组文件，或者根本没人能审查合并后的结果，那么增加并发只会把一项不确定工作变成多项不确定工作。
目标不是追求最大并行度，而是在不失去范围、证据和当前项目状态控制权的前提下，更快得到可以被接受的结果。
一套五阶段多 Agent 编程工作流
无论参与者是 Codex、Claude Code、OpenCode、其他受支持的 harness，还是人与 Agent 的组合，都可以按下面的顺序推进。
1. 定义结果与验收关口
先把结果写成 Reviewer 能检查的形式。“优化登录”过于宽泛；“拒绝过期重置 Token，保留有效 Token 的现有行为，并通过指定回归测试”才有清楚的终点。
分配任务前，先记录四件事：
- 预期结果；
- 哪些内容明确不在本次范围内；
- 用哪条命令、哪个 Preview、哪份 Diff 或产物证明完成；
- 最终由谁决定是否接受结果。
这份共享 Brief 能防止不同 Session 各自发明一套任务定义。
2. 按产出和写入边界拆分工作
每个工作项都应该产出一个可以识别的材料，例如代码改动、测试、调查记录、Review 报告或选型对比。除了主题，还要为它规定写入边界。
例如：
“负责后端”不是有效边界。一个明确模块、一组具体文件或只读职责，会更容易协调。
3. 分配所有权并决定执行顺序
每个工作项只能有一位 Owner。其他 Agent 可以提供建议或 Review，但当前编辑边界必须由一位参与者负责。
然后标记依赖关系：
- **并行：**产出彼此独立，不会修改同一份事实来源。
- **串行：**前一项结果必须先被接受，下一项才能开始。
- **并行调查、串行决策：**多个 Session 可以同时研究，但实现前由一个人统一选定方向。
如果两项任务都可能改变同一个接口或共享文件，就默认串行；除非你确实准备了隔离分支和明确的合并方案。
4. 执行任务并留下证据
Agent 的解释不等于项目状态。应要求每位 Owner 把可检查的证据与文件一起留下：
- 实际修改或检查了哪些文件；
- 运行了哪些命令和测试，包括失败结果；
- 如果是视觉产出，留下可用的 Preview；
- 哪些假设影响了实现；
- 已知风险与建议的下一步。
在 Agent.Space 中，同一 Workspace 的不同 Session 可以并行运行；忙碌 Session 收到的后续输入会显示在 Queue 中。但这些 Session 面对的是一份当前文件状态。一个 Session 不会悄悄继承另一个 Session 的对话或私有推理，所以关键决定必须写进共享材料，不能只留在隐含上下文里。
5. Review、对齐并验收
只有每项独立产出与证据都准备好后，才把它们汇总。Review Gate 应检查：
- 每项结果是否符合最初的验收条件；
- 合并后的改动是否互相矛盾；
- 并行期间是否有关键假设发生变化；
- 最终测试是否覆盖整合后的当前状态，而不只是各自的局部结果；
- Diff 中是否混入无关改动或不必要的复杂度。
完成对齐后，再运行一次相关验证。另一个 Session 修改项目之前通过的测试，不能证明现在的状态仍然通过。
示例：Codex 实现、Claude Code Review、OpenCode 修复
假设团队需要修复一个结算金额错误，并增加回归测试。
- 一位成员先写清失败场景、预期金额、不做哪些重构，以及必须通过的测试命令。
- 一个 Codex Session 负责边界明确的实现与测试文件。
- Patch 和测试证据保存后，再启动独立 Claude Code Session，根据原始需求和当前 Diff 做以读取为主的 Review。
- 如果 Review 找到一处具体问题，就把该发现、当前文件和窄范围修复边界交给 OpenCode Session。
- 最后由人检查完整 Diff，并运行全部验收项，再决定是否合并或发布。
这套流程使用了三个 Agent harness，但在状态相互依赖的地方仍然是串行的。第二和第三个 Session 可以检查已保存项目文件和明确交接材料，却不会继承实现者的隐藏推理。换一个 harness 的价值在于让 Reviewer 拿到证据和一个全新职责，而不是预设某个 harness 永远更好。
如果还没决定由哪个 harness 负责实现或 Review，可以用 Codex 与 Claude Code 工作流对比做判断框架，而不是把它理解成永久排名。
判断哪些工作应该并行
只有后续对齐成本较低时，才适合并行执行。
当协调说明比它能避免的冲突更短时，并行才真正划算。
把文件所有权与版本控制当作两层控制
Workspace 为团队提供一个看得见的共同工作位置；版本控制负责历史、对比、回退与合并边界。两者解决的问题不同。
在一份共享文件树中：
- 给每位正在写入的参与者划分不重叠范围；
- 不要假设每个 Session 都有私有副本；
- 共享合同变化时先暂停相关工作；
- 接受下一项写入任务前，先检查当前 Diff；
- 两种方案必须独立修改同一批文件时，使用仓库分支或相互隔离的副本。
Agent.Space 不会把多 Session 协作包装成自动 Commit、Merge 或 Rebase。如果项目需要这些保证，仍要主动使用自己的版本控制流程。
Agent 工作完成后若要由另一位成员继续，可以采用一套围绕共享文件、证据和角色的团队交接流程。高风险仓库在扩大并发前，还应先建立清楚的 Workspace 隔离、权限与密钥边界。
预算的不只是 Agent 额度，还有 Review 注意力
每增加一个 Agent，就会增加一批需要有人理解的材料。Review 成本也属于工作流成本。
开始前先定义停止条件：
- 调查能够指出相关路径并支持决策时就停止；
- 验收条件通过时停止实现，不要顺手“优化”所有相邻文件；
- 两个 Session 开始碰同一份合同时，停止并行；
- 需求、数据边界、安全假设或架构方向发生变化时，停止并请求人类决定。
边界清楚的多 Agent 工作流，可能比一个无限扩张的单 Agent 任务消耗更少，因为每位参与者只做一件明确的事。糟糕的工作流则会复制大量猜测性改动，再花更多时间对齐。
从最小可复现工作流开始
第一次运行时，先选一个边界明确的真实任务，并且最多安排两项活跃职责：
- 写清结果、排除项与验收检查；
- 分配一项实现边界；
- 候选结果稳定后，再分配一次独立 Review；
- 保存 Diff、测试输出、Preview、决定与未解决风险；
- 由一位成员接受或拒绝整套结果。
这套串行流程稳定后，再增加并行实现。成功的标准不是同时开了多少 Agent，而是另一位成员能否检查当前状态、理解它为什么可以接受，并且不用重建项目就能继续。
如果你希望把受支持的 Agent Session、已保存文件、Preview 和团队上下文放在同一个 Workspace，可以使用 Agent.Space。从一个真实任务开始，明确每项所有权，只在边界仍然清楚时增加并行度。