子 Agent
CurdX Flow 内置 9 位专家子 Agent。每位职责单一、独立上下文运行，由协调命令自动调用。你不会直接喊它们——但理解它们的分工能帮你写出更好的目标、审更好的产物。
为什么用专家子 Agent
多 Agent 框架常见做法是把多个通用 Agent 叠加在同一个对话上，结果是 token 消耗多、等待时间长、出问题难排查。
flow 的取舍不一样：每个阶段一个专家，每次都是新上下文。 子 Agent 只拿它需要的输入（目标、前置产物、相关 skills），产出唯一一份产物，然后退出。没有多 Agent 编排沙拉。
子 Agent 流水线
九位子 Agent
阶段负责人
这五位负责一个完整阶段，产出唯一一份核心产物。
| 子 Agent | 阶段 | 产物 |
|---|---|---|
| research-analyst | 研究 | research.md |
| product-manager | 需求 | requirements.md |
| architect-reviewer | 设计 | design.md |
| task-planner | 任务 | tasks.md |
| spec-executor | 执行 | 代码、测试、提交 |
辅助 Agent
这四位在质量门禁和 epic 拆分时支撑流水线。
| 子 Agent | 角色 |
|---|---|
spec-reviewer | 只读评审者，按类型规则验证产物，输出 REVIEW_PASS 或 REVIEW_FAIL。 |
qa-engineer | 在质量门禁运行验证命令，输出 VERIFICATION_PASS 或 VERIFICATION_FAIL。 |
refactor-specialist | 执行揭示规约漂移后逐节更新规约文件。/curdx-flow:refactor 调用它。 |
triage-analyst | 把大功能拆成依赖明确的多个规约（epic 图）。/curdx-flow:triage 调用它。 |
心智模型
把流水线想成一个小团队：
- 研究分析师 读所有材料、写出简报。
- 产品经理 把简报转成可测试需求。
- 架构师 决定如何实现需求。
- 任务规划师 把设计拆成带验证门禁的清单。
- 执行器 跑清单、提交代码。
辅助 Agent 是质量与流程——评审、验证、当现实出现时重塑规约。
常用工作流
一次完整规约走查
text
/curdx-flow:start # 访谈 + research-analyst（并行团队）
/curdx-flow:requirements # product-manager
/curdx-flow:design # architect-reviewer
/curdx-flow:tasks # task-planner
/curdx-flow:implement # spec-executor（自治循环，每个 VERIFY 门禁由 qa-engineer 把关）执行后发现规约要改
text
/curdx-flow:cancel # 暂停循环
/curdx-flow:refactor # refactor-specialist 走 requirements → design → tasks
/curdx-flow:implement # 恢复单个规约装不下的大功能
text
/curdx-flow:triage # triage-analyst 产出 epic.md 和子规约
/curdx-flow:start # 正常推进第一个子规约进阶建议
- 用自然语言描述结果，协调器自会选对子 Agent。
- 子 Agent 输出令人失望，问题通常在上游。研究差 → 需求差 → 设计差。
- 用
/curdx-flow:refactor而不是手改产物，辅助refactor-specialist会一致地走完整链。 - 任务保持细粒度。
spec-executor最高兴的状态是每个任务对应一个可验证改动。