AgentTeam 与 Cursor SubAgents：从线性到受控并行的实践小结

日期：2026-08-10
性质：个人实践总结，便于分享与讨论
说明：文中使用通用阶段名（P1～P4）描述多 Agent 交付流程，不绑定具体业务系统。

---

1. 今天想解决什么问题

多 Agent 协作交付（下文称 AgentTeam：分阶段、分角色、用文档与 Gate 推进）长期偏 串行 / 线性：

需求理解 → 方案设计 → 开发 → 测试 → 审查 → 提交

线性的好处是决策收敛、责任清晰；坏处是到了 任务清单很长、模块边界清楚 的大型改动时，效率上不去。

因此自然会想到引入 Cursor 的 SubAgents：让 AI 真正「并行写代码」。
但若只开很多工人、没有 并行责任划分，并行往往 不如串行。

---

2. 先把两个概念分开（最容易混）

概念	是谁在调度	形态	典型用途
AgentTeam 多主对话	人（或教练角色）	侧栏多条完整 Agent 对话；靠文档交接	跨阶段：需求 / 设计 / 开发 / 测试 / 审查
Cursor SubAgents	当前主 Agent	主对话内部派出的子任务；结果回流主对话	同一阶段内：探索、跑命令、可并行分包、独立复验

一句话：

• 多主对话 = 你当导演，一场戏一个窗（分场）
• SubAgents = 主演自己喊群演帮忙，干完回来汇报（同一场戏内部）

两者 互补，不互相替代。不要指望用 SubAgent 树代替整条分阶段交付流程。

---

3. Cursor SubAgents：需要抓住的本质

官方能力可参考：Subagents、Multi-agent。

3.1 工作方式

1. 主 Agent 协调：自动或按提示委派子 Agent。
2. 独立上下文：子 Agent 默认看不到主对话完整历史；派工时必须把任务写清楚。
3. 可继承能力：通常能使用父级工具（含 Skill、MCP、终端等），但拿的是「工具」，不是「整段聊天记忆」。
4. 生命周期在主对话内：子任务结束，摘要回到父对话；它不是侧栏里又一条长期可聊的完整会话。
5. 内置优先：如 Explore（搜代码）、Shell（跑命令）、Browser（浏览器）等，不必先批量自建才能用。
6. 自定义 SubAgent：适合稳定专项（如独立 verifier）；应用 description 写清「何时该派我」，宁少勿滥。

3.2 因此，「SubAgent 并行编程」究竟是什么

更准确的定义是：

在同一条主 Agent 对话内部，由主 Agent 协调多个子 Agent 并行（或异步）完成可拆分任务；并行边界与责任仍由任务定义决定，而不是由「开了几个子 Agent」决定。

所以：

• 生命周期、上下文、汇报对象 → 都挂在 当前主 Agent
• 跨阶段的 Gate、落盘文档、人工确认 → 仍靠 AgentTeam 多对话 + 规范，不是 SubAgent 自动完成

---

4. AgentTeam 里哪里适合「子 Agent / 并行」

结合实践，阶段策略建议如下：

阶段	建议	原因
P1 需求	线性	目标、范围、开放问题要收敛成一份真相
P2 设计	线性起草 + 多视角审查	定稿仍是一份 design/tasks；多视角 = 多个「审查镜头」，不是多个 Agent 各写一份方案
P3 开发	受控并行（主对话内 SubAgent，或人开多个开发对话）	前提是 tasks 标清依赖与可并行批次
P4 测试	批后窄测可跟随；总测收口偏线性	与开发全面并行易测到半成品，噪声大
审查 / 收口	线性	基于稳定代码做判断

对「P2 也需要子 Agent」的修正表述：

• P2 需要的是 多角色 / 多视角检查清单（业务、分层、数据、失败一致性、可观测、可测、前端消费等）
• 不需要多个 SubAgent 并行产出多份设计再合并

对「P3 / P4 需要子 Agent」的表述：

• P3：最适合引入 SubAgent 或受控多窗并行
• P4：适合在主测试对话内用 SubAgent 跑命令/搜集证据；全量冒烟仍宜在相关开发完成后收口

---

5. 真正决定并行成败的：责任划分

没有责任划分的并行，常见失败模式：

• 多个工人改同一热点文件 → 冲突、互相覆盖
• 前置未完成就开工 → 接口对不齐、返工
• 人人「都能改」→ 无人负责验收口径
• 并行很多，主 Agent 上下文仍被结果噪声打爆 → 协调成本 > 收益

5.1 建议在任务清单上强制出现的字段

字段	含义
depends_on	前置任务；未完成则 不得 开该任务（更谈不上并行）
parallel_group / batch	同一并行批次标识
must_serial / can_parallel	串行或可并行（二选一）

5.2 开批规则（简版）

1. 任一 depends_on 未完成 → 不得开该 Task。
2. 同组且均为 can_parallel、依赖已满足 → 才可并行（多开发对话或主对话内多 SubAgent）。
3. 同文件热点 / 共享 DDL / 强耦合链路 → 默认 must_serial。
4. 无标注 → 按表序串行（保守默认）。
5. 开发可受控并行；总测试宜收口；端到端 UI 冒烟可作为旁路，不必焊进每个阶段的强制 Gate。

5.3 心智模型

线性收敛：  需求 → 设计（多视角审查后仍一份定稿）
受控并行：  开发（按依赖图切批；批内可 SubAgent / 多窗）
弱并行：    批后窄测 / 单测跟随
线性收口：  总测 → 审查 → 修复环

并行前提是依赖切分，不是工人数量。

---

6. 和「少点确认」的关系（旁注）

Cursor IDE 的工具审批（是否每次询问执行命令）与 AgentTeam 的 Gate（人审阶段结论） 是两套机制：

• IDE：Auto-review 一类「低风险自动跑、高风险再问」——减噪音
• AgentTeam：需求 / 设计 / 上线相关 Gate —— 不应为了爽快而取消

并行提效靠任务切分；减弹窗靠 IDE 设置；阶段质量靠 Gate。

---

7. 对原文理解的校正表

原表述	更准确的表述
SubAgent 并行 = 真正的并行 AI Coding	✅ 可以，但是 主对话内部的受控并行；不等于取消分阶段交付
子可继承父的 Skill/MCP，无完整对话	✅ 正确
生命周期停在当前主 Agent	✅ 正确
只有 P3、P4 以及 P2 多角色需要 SubAgent	⚠️ P3/P4 适合并行执行；P2 适合 多视角审查，不宜多 Agent 各写 design
最重要的是并行责任划分	✅ 核心正确；否则并行不如线性

---

8. 可分享的结论（给别人看的三句话）

1. AgentTeam 管阶段与真相文档；SubAgents 管单场内的隔离与受控并行。
2. 所谓 SubAgent 并行编程，本质是主 Agent 协调子 Agent；生命周期与上下文都挂在主对话上。
3. 没有 depends_on / 并行批次 / 串并行标记，就不要谈并行——责任划分比「多开几个 AI」更重要。

---

9. 建议的下一步（实践验证）

用一个 真实、偏大、可拆任务清单 的需求走一遍：

1. 设计阶段产出带依赖与并行标记的 tasks
2. 开发阶段按批次受控并行（主对话内 SubAgent 或少量开发窗）
3. 记录：冲突次数、返工点、是否比纯线性更快
4. 用数据决定是否扩大并行比例——而不是先堆自定义 SubAgent

---

参考链接

• Cursor Subagents
• Cursor Multi-agent
• Cursor Run Modes / Auto-review

---

修订记录

日期	说明
2026-08-10	初版：概念分界、阶段策略、责任划分、校正表；脱敏分享稿