这套流程的起点，其实不是一个宏大的“多 Agent 架构”。其实，单纯是因为我受够了返工。

从痛点出发这方面，为何需要分配 AI 任务

在一个体量不算小的个人项目中，因为时间推移，模块和测试不断增多。我逐渐遇到以下痛点：

• 返工频繁：同一需求被不同 Agent 多次修改，导致代码和设计不断回滚。怎么说呢，
• 上下文丢失：换会话后新 Agent 必须重新阅读仓库。之前的取舍、决策往往被遗忘。
• 完成度不清晰：很难判断代码是否已经写完，还是整个任务真的结束了。
• 高成的误用：把最强大的模型用于大量机械改动，导致费用和等待时间飙升。

正是这些痛点促使我把不同的 Agent 按职责拆分，让每个模型只在“刀刃上”产生作用。

我的四段工作流与三位 Agent 的角色划分

从第一段来看，Codex负责全局决策与验收

痛点对应：全局判断错误代价高、需要高杠杆的判断。

Codex 只在流程两端出现： - 开头：根据现有架构拆分父任务、评估需求是否破坏层次结构。- ：对所有子任务完成后的累计 Diff 进行整体回流验证。其实，

它负责回答诸如“这个需求会不会破坏现有分层？”、“哪些接口需要先冻结？”等关键问题，并在验证阶段决定任务是否真正完成。

第二段这方面，OpenCode + MiMo Pro 将想法转化为可执行的子任务

痛点对应：架构太粗导致实现阶段返工、缺乏明确的施工图。

这组模型读取父任务、架构文档还有实际代码，把模糊需求拆解成一组有序且可验证的子任务。每个子任务明确：

• 要修改的文件和符号；老实说，
• 接口、类型或配置的具体形态；
• 执行顺序和排除项；怎么说呢，
• 对应的测试场景与预期结果；
• 完成后需要留下的证据。

说到第三段，Claude Code + MiniMax M3 执行高频实现工作

痛点对应：重复机械改动耗时、成本敏感。

当子任务已经细化到具体文件、接口和预期后这组模型像实施工程师一样逐一执行。它们只负责把设计落地，并生成《实施报告》记录实际修改、执行命令、测试结果还有剩余风险。完成后只能声明“已实现”，而不是直接标记为“已完成”。

再看第四段。Codex 介入进行整体检查

痛点对应：单个子任务通过并不代表整体正确，缺乏统一验收标准。说起来，

所有子任务进入“已实现”状态后Codex 对比累计 Diff 与最初验收标准。检查接口冲突、兼容性、数据迁移等问题。它可以直接标记父任务为“已完成”，或将失败子任务重新打开以控制返工范围。 话说回来，

Zed 与 External Agents：统一操作台的优势

Zed 并非此流程的必需品。但它提供了极佳的多 Agent 协作体验：

• 代码编辑、Diff、终端与 Agent 会话全部在同一窗口，无需在网页聊天与 IDE 之间切换上下文。
• "External Agents" 集成：
• C​odex 用于架构设计。OpenCode 用于任务拆解，Claude Code 用于实现，一键切换即可保持同一工作区。
• "轻快」界面：
• A​I 功能旁置但不抢占代码阅读空间，符合我对编辑器干净利落的需求。

A​gent 之间不传话，而是共享仓库记忆

I 把仓库本身当作唯一可信赖的共享记忆体。目录结构示例这方面，

docs/
├── architecture/ # 程序结构和边界
├── decisions/ # 关键决策记录
├── roadmap/ # 优先级和执行顺序
├── epics/ # 一组相关目标
├── tasks/ # 父任务
├── subtasks/ # 可直接实施的子任务
├── implementation/ # 实际做了什么、测试结果如何
├── reviews/ # 父任务最终验证
└── risks/ # 未解决风险

每个目录对应一个明确的问题。让 Agent 不再依赖聊天中的交接提示词，而是直接读取或写入相应文档。例如的观点是，

• /architecture 与 /decisions：`为什么这么设计`；
• /roadmap：`现在先做什么`；
• /tasks 与 /subtasks：`要交付什么` 与 `具体怎么做`；/implementation & /reviews：`实际实现了什么` 与 `整体是否通过`。

  If an Agent says “done” but corresponding files,status flags or reports are unchanged,workflow treats it as *not* done.

  A​gent 工作阶段与状态机

  P​arent Task 状态机

  待拆分 → 待执行 → 进行中 → 待回流验证 → 已完成
  

  S​ubtask 状态机

  待执行 → 进行中 → 已实现 → 已完成
  

  The only step that can write “已完成” is final Codex verification。eliminating ambiguity across agents.

  S​kill 化流程，让指令更短、更可靠

  I 将整个约定写进仓库级 Skill，使得每次只需一句简短指令即可触发相应阶段，而无需重复长篇提示词。例如的观点是，

  .agents/skills/orchestrate-agent-development/
  ├── SKILL.md # 流程概览与入口指令说明
  ├── agents/openai.yaml # Codex / OpenCode 配置
  └── references/
  ├── repository-control-plane.md # 仓库状态约定
  └── artifact-contracts.md # 文档模板规范
  

  C​laude Code 从 .claude/skills/…,OpenCode 与 Codex 从 .agents/skills/…. 当我说「拆分子任务」时对应 Skill 自动读取父任务并生成子任务文档及状态更新，实现「说完即生效」。流程本身也进入版本管理，可审查并迭代改进。

  E​xperience Tips – 我最有价值的几条经验教训

  P0 不一定能立刻动手

  A gent 必须先检查优先级。再确认所有依赖已满足，只有两者同时满足才算 Ready。

  S​ubtask 按「可验证结果」划分，而不是按文件数量

  "修改三个文件" 并不是好的边界。"建立配置契约并让非法输入测试且有意义的目标。

  L​旧失败必须完整记录

  If a test fails before any modification。it must be logged in implementation report rar than being silently absorbed into current task.

  D​irty worktree 的所有改动默认归属他人

  C​heck git status,compare diffs before each run;unknown changes should not be reset nor discarded.

  C​omplete verification 必须基于累计 Diff

  The sum of all sub‑tasks may introduce new incompatibilities even if each sub‑task passes individually—this is *** only Codex performs final gate.

  A​pplicability – 适合场景 vs. 不适合场景

  • #适合#: 跨文件的大改动、涉及主要接口或数据迁移、业务规则复杂且后续可能继续 的功能。
  • #不适合#: 仅改一句文案或调一个局部样式。这种轻量级修改仍然直接手工提交即可，无需完整编排流程。

  C​urrent Gaps & Future Work

  • a) 自动校验父‑子任务状态一致性；b) 自动发现下一个 Ready 子任务并提醒；b) 验证实施报告中的真实命令输出；d) 检测文件重叠以避免并行冲突；
  • No plan to build a heavyweight orchestration UI yet—running rules reliably beats a pretty console.
  \ The key takeaway: multi‑Agent development isn’t about making models chat with each or;it’s about letting each model do what it does best **and** writing every hand‑off into repository so that architecture has provenance。tasks have status,implementations have evidence,and completion has verifiable acceptance.

  ---