TL;DR并行探索适合大任务的前期判断。让多个 subagent 分别研究不同方向再由主会话整合方案。并行会增加总 token 消耗但显著减少挂钟时间。关键前提任务必须能拆成相互独立的问题。问题大型改造开始前最耗时的是理解哪些模块相关、现有模式是什么、风险在哪里、测试怎么跑。一个会话串行探索会慢也容易遗漏。但串行探索有一个不容易注意到的隐性成本上下文污染累积。在主会话里连续探索 5 个模块前 3 个模块的探索细节会和后 2 个模块的实现需求混在一起。到真正开始写代码时上下文里塞满了探索阶段的只读信息留给推理和实现的空间不足。还有一个更容易忽略的问题认知疲劳。主会话在连续探索第 4 个模块时对前面 3 个模块的细节记忆已经开始模糊。它可能重复读取已经看过的文件或者遗漏和前面模块的关联。这不是模型能力的问题——任何上下文窗口都有信息密度的极限。探索的内容越多每条信息的平均注意力权重就越低。并行探索的核心思路把探索任务拆给多个独立 subagent每个 subagent 只关注一个方向在自己的上下文里完成探索。主会话只接收精炼后的结果。但并行不是银弹。它有自己的成本结构总 token 消耗更高每个 subagent 都有独立的上下文初始化开销结果整合需要额外的工作去重、合并、冲突解决而且不是所有任务都能拆成独立子任务。并行探索的前提是每个子任务之间确实没有依赖——如果子任务 A 的结果影响子任务 B 的搜索方向那就不能并行只能串行。并行派发架构基本模型主会话 ├─ 派发任务 A → Subagent Alpha独立上下文→ 返回结果 A ├─ 派发任务 B → Subagent Beta独立上下文→ 返回结果 B ├─ 派发任务 C → Subagent Gamma独立上下文→ 返回结果 C └─ 汇总 A B C → 形成完整方案主会话的角色从执行者变成编排者定义问题、拆分任务、派发代理、汇总结果。它不需要亲自读文件、搜代码——这些脏活由 subagent 在各自的上下文里完成。派发格式主会话向每个 subagent 发送明确的问题描述给 Explorer A 的任务 查找用户认证相关的所有文件。关注 1. 认证中间件的实现位置和调用方式 2. Session/Token 的存储和验证逻辑 3. 权限校验的调用链 返回文件清单、调用链图、已知模式 给 Explorer B 的任务 查找数据模型层与用户相关的所有文件。关注 1. User 模型的字段定义和关联关系 2. 用户数据的读写路径 3. 数据库 migration 历史 返回数据模型图、读写路径、最近的 schema 变更 给 Reviewer C 的任务 审查当前认证系统的安全风险。关注 1. Token 验证是否有绕过可能 2. 密码存储方式 3. Session 管理的安全性 返回风险清单按严重度排序关键每个任务描述都包含关注点和期望输出格式。这确保 subagent 返回的结果可以被主会话直接使用而不需要二次加工。真实场景权限系统改造的前期探索需求描述“给现有系统添加角色权限控制。当前只有简单的登录/未登录区分需要支持多角色、多权限。”这个改造涉及业务逻辑、数据模型、安全风险、测试覆盖四个方向。主会话同时派发四个 subagent 并行探索主会话 → Explorer A业务逻辑层 查找所有涉及权限判断的业务代码。当前系统如何区分已登录/未登录 哪些 API 有权限检查哪些没有返回文件清单和权限检查分布图。 主会话 → Explorer B数据模型层 查找用户相关的数据模型。User 表结构、关联表、数据库 migration。 返回 ER 图文字描述和最近的 schema 变更。 主会话 → Reviewer C安全风险评估 审查当前认证和授权实现的安全风险。Token 管理、Session 处理、 密码存储、权限绕过可能。返回风险清单。 主会话 → Explorer D测试覆盖现状 查找认证和权限相关的测试文件。哪些行为有测试覆盖哪些没有 测试框架和运行方式是什么返回覆盖度评估。各代理返回的典型结果Explorer A业务逻辑层### 文件清单 | 文件 | 作用 | 权限检查 | |------|------|---------| | src/middleware/auth.ts | 认证中间件 | ✓ 检查 token | | src/routes/api.ts | API 路由定义 | 部分只有 /admin 有检查 | | src/routes/user.ts | 用户路由 | 无权限检查 | | src/routes/order.ts | 订单路由 | 无权限检查 | | src/services/user.ts | 用户服务 | 无权限逻辑 | ### 现有模式 - auth.ts 导出 requireAuth 中间件 - 只有 /admin/* 路由使用了 requireAuth - 其他所有路由都没有权限检查 - 已登录判断靠 token 解析后挂到 req.user ### 发现的问题 - /api/user/:id 可以访问任意用户数据无权限检查 - /api/order 列表返回所有订单无过滤Explorer B数据模型层### User 模型 | 字段 | 类型 | 说明 | |------|------|------| | id | UUID | 主键 | | email | VARCHAR(255) | 唯一 | | password_hash | VARCHAR(255) | bcrypt | | role | VARCHAR(20) | user 或 admin | | created_at | TIMESTAMP | 创建时间 | ### 关联表 - orders: user_id - users.id一对多 - sessions: user_id - users.id一对多 ### 模式发现 - role 字段已存在但只在 /admin 路由检查 - 没有权限表permissions table - 没有角色-权限关联表role_permissions ### 最近变更 - 2024-11: 添加 role 字段只有 user 和 admin - 2024-09: 添加 sessions 表Reviewer C安全风险评估| 严重度 | 问题 | 位置 | |--------|------|------| | blocker | 任意用户数据访问 | /api/user/:id 无权限检查 | | blocker | 订单数据越权 | /api/order 无用户过滤 | | warning | Token 无刷新机制 | auth.ts 只检查过期不刷新 | | warning | Session 无并发控制 | 同一用户可无限 session | | suggestion | 密码策略弱 | 注册时无密码强度检查 |Explorer D测试覆盖现状### 测试框架 - Vitest Supertest - 运行: npx vitest ### 认证测试覆盖 | 场景 | 有测试 | 文件 | |------|:------:|------| | 登录成功 | ✓ | tests/auth.test.ts | | 登录失败错误密码| ✓ | tests/auth.test.ts | | Token 过期 | ✓ | tests/auth.test.ts | | 未登录访问受保护路由 | ✓ | tests/auth.test.ts | | 越权访问其他用户数据 | ✗ | - | | 管理员操作权限 | ✗ | - | | 角色变更 | ✗ | - | ### 覆盖度评估 - 认证流程覆盖良好4/4 基础场景 - 授权场景完全缺失0/3 关键场景 - 需要新增权限相关测试文件主会话的汇总四个 subagent 的结果汇总后主会话形成了清晰的改造方案整个探索过程并行完成。如果串行执行每个方向需要 3-5 分钟总计 12-20 分钟。并行后总挂钟时间取决于最慢的那个 subagent通常 4-6 分钟。结果整合策略信息合并多个 subagent 返回的结果可能有重叠或互补。整合策略冲突解决当两个 subagent 的发现互相矛盾时场景Explorer A 报告/api/order 有权限检查 Explorer B 报告/api/order 没有权限检查 解决步骤 1. 主会话亲自读取 /api/order 路由文件 2. 确认实际情况可能一个看了旧版本一个看了新版本 3. 以主会话的直接观察为准 原则subagent 的结果是初步发现不是最终结论。 冲突时主会话亲自验证。Token 成本对比并行 vs 串行的 token 消耗对比场景权限系统改造的 4 方向并行探索 并行模式4 个 subagent Explorer A: ~3,500 tokens独立上下文 Explorer B: ~2,800 tokens独立上下文 Reviewer C: ~2,200 tokens独立上下文 Explorer D: ~3,000 tokens独立上下文 主会话汇总: ~1,500 tokens读结果 推理 ────────────────────────── 总 token: ~13,000 tokens 挂钟时间: ~5 分钟取最慢的 主会话上下文: 只占 ~1,500 tokens结果摘要 串行模式主会话逐一探索 探索业务逻辑: ~3,500 tokens 探索数据模型: ~2,800 tokens 探索安全风险: ~2,200 tokens 探索测试覆盖: ~3,000 tokens ────────────────────────── 总 token: ~11,500 tokens 挂钟时间: ~15 分钟串行执行 主会话上下文: ~11,500 tokens全部探索细节对比结论|指标|并行|串行|差异|| — | — | — | — ||总 token|~13,000|~11,500|并行多 ~13%||挂钟时间|~5 分钟|~15 分钟|并行快 ~67%||主会话上下文占用|~1,500|~11,500|并行省 ~87%||信息遗漏风险|低多视角|高认知疲劳|并行更全面|关键洞察并行的 token 开销比串行多但主会话上下文占用大幅减少。总 token 多出的 13% 是 subagent 的独立上下文开销。但主会话只接收摘要上下文从 11,500 降到 ~1,500。这意味着主会话有更多空间用于后续的实现和推理。什么时候 token 多花是值得的当主会话的上下文空间是瓶颈时复杂任务需要大量推理并行探索的上下文节省比总 token 开销更重要。典型场景是大型改造前期探索需要读几十个文件但后续实现需要在清晰的上下文里做复杂推理。如果探索阶段把主会话上下文塞满了实现阶段的质量会显著下降。什么时候不值得当探索任务很简单只需要读 2-3 个文件并行调度的固定开销subagent 创建、上下文初始化、结果传输可能比任务本身还大。或者当后续实现很简单不需要大量推理主会话上下文压力不大节省上下文空间的收益微乎其微。还有一个隐藏的权衡结果整合的认知成本。并行探索返回多份结果主会话需要花精力理解每份结果、找出重叠和冲突、合并成统一视图。这个整合过程本身消耗注意力和上下文空间。如果并行返回的信息量很大、冲突很多整合成本可能抵消并行带来的上下文节省。故障隔离并行探索的一个重要特性一个 subagent 失败不会阻塞其他 subagent。场景4 个并行 subagent Explorer A: 正常完成 → 返回结果 Explorer B: 正常完成 → 返回结果 Reviewer C: 超时/出错 → 返回错误信息 Explorer D: 正常完成 → 返回结果 主会话收到 - A、B、D 的完整结果 - C 的错误信息 处理方式 1. 基于 A、B、D 的结果继续工作 2. 安全风险评估由主会话自行补充用已有的代码结构信息 3. 标记安全审查为待补充 不会因为 Reviewer C 失败而整个探索流程卡住。这比串行探索更健壮。串行探索中如果第三步的安全审查超时后续的测试覆盖探索也无法开始。决策矩阵并行 vs 串行 vs 主会话任务特征评估 1. 任务是否能拆成 3 个独立问题 是 → 考虑并行 否 → 串行或主会话 2. 探索结果是否会污染主会话上下文 是大量文件、长日志→ 并行 否少量文件、短输出→ 主会话 3. 探索时间是否是瓶颈 是挂钟时间 10 分钟→ 并行 否挂钟时间 3 分钟→ 主会话 4. 各子任务之间是否完全独立 是 → 并行 有依赖 → 串行 5. 探索后的实现是否需要大量主会话上下文 是复杂推理→ 并行省上下文给实现 否简单修改→ 主会话|场景|并行|串行|主会话|| — | — | — | — ||大型改造前期探索|✓| | ||多方向技术调研|✓| | ||安全 性能并行审查|✓| | ||中等需求3-5 个文件| |✓| ||有依赖的多步分析| |✓| ||小 bug fix1-2 个文件| | |✓||UI 调整需要看浏览器| | |✓||简单问题Google 就能回答| | |✓|并行 Subagent 故障隔离模式并行探索的一个核心工程优势是故障隔离——单个 subagent 失败不会阻塞整体流程。这里展开说明不同故障类型的隔离策略。故障类型及处理故障类型 1超时 症状某个 subagent 超过预设时间仍未返回 影响不影响其他 subagent 的执行 处理 - 设置每个 subagent 的超时阈值通常 5 分钟 - 超时后主会话标记该方向为待补充 - 基于已完成的其他 subagent 结果继续工作 - 后续用主会话或单独 subagent 补充缺失方向 故障类型 2权限不足 症状subagent 报告无法完成缺少 XX 工具 影响该 subagent 返回错误信息其他 subagent 不受影响 处理 - 记录权限缺失的具体情况 - 评估是否需要调整该角色的 tools 配置 - 本次用主会话补充该方向的探索 - 下次并行探索时使用更新后的配置 故障类型 3结果质量低下 症状subagent 返回了结果但明显遗漏或错误 影响不会直接阻塞流程但整合结果时需要额外验证 处理 - 主会话对低质量结果进行二次验证 - 验证方式亲自读 1-2 个关键文件确认 - 标记低质量结果的可信度 - 基于可信结果做决策低可信结果仅作参考 故障类型 4Subagent 间结果冲突 症状两个 subagent 对同一事实给出矛盾描述 影响需要主会话介入裁决 处理 - 主会话亲自验证冲突点读源文件 - 以直接观察为准subagent 结果标记为初步发现 - 分析冲突原因可能是版本差异、搜索范围不同、理解偏差 - 更新 subagent 的 system prompt 减少未来冲突故障恢复的工程实践最佳实践并行探索的容错设计 1. 冗余派发高可靠场景 对关键方向派发两个 subagent交叉验证结果 适用场景安全审计、核心模块探索 成本token 消耗翻倍但结果可靠性显著提升 判断标准该方向的探索结果如果错误会导致多大的损失 2. 降级策略资源敏感场景 并行探索中某个 subagent 失败后不重新派发 而是由主会话快速补充该方向的探索 适用场景token 预算有限、时间不紧急 成本挂钟时间增加但总 token 消耗不增加 3. 渐进式并行探索范围不确定时 先派 2 个 subagent 摸底 根据初步结果决定是否需要更多 subagent 适用场景任务范围一开始不确定 成本可能比一次性并行多花挂钟时间但避免了无效派发实战案例3 并行 Subagent 解决复杂任务场景微服务拆分的前期调研任务描述 将单体应用拆分为微服务。需要了解当前架构、 服务边界、数据依赖、API 调用链、部署配置。 这是一个典型的大型探索任务——5 个方向每个方向都需要读大量文件 方向之间相对独立。串行探索预计需要 25-40 分钟。 并行派发 5 个 subagent派发配置Subagent A路由层分析 角色Explorer 任务分析 src/routes/ 目录下所有路由定义。输出 1. 路由 → handler 映射表 2. 每个路由的中间件链 3. 路由之间的调用关系 4. 鉴权/授权分布图 预计输出~800 tokens Subagent B数据层分析 角色Explorer 任务分析 src/models/ 和 src/db/ 目录。输出 1. 所有模型定义和字段 2. 模型之间的关联关系 3. 数据库 migration 历史 4. 跨模型的查询join 操作 预计输出~1,000 tokens Subagent C服务层分析 角色Explorer 任务分析 src/services/ 目录。输出 1. 每个服务的职责描述 2. 服务之间的调用依赖 3. 共享工具函数 4. 外部 API 调用 预计输出~800 tokens Subagent D配置与部署分析 角色Explorer 任务分析部署配置文件。输出 1. Docker/容器配置 2. CI/CD 流程 3. 环境变量和配置管理 4. 监控和日志配置 预计输出~600 tokens Subagent E安全审查 角色Reviewer 任务审查当前架构的安全风险。输出 1. 认证/授权实现的安全评估 2. 数据库访问的安全性 3. API 端点的暴露面 4. 敏感数据处理方式 预计输出~800 tokens结果汇总与冲突解决5 个 subagent 并行执行耗时约 6 分钟取最慢的 汇总过程 步骤 1独立验证~2 分钟 快速扫描每个 subagent 的输出检查格式完整性 Subagent D 的输出最短~400 tokens发现部署配置很简单 Subagent E 报告了 2 个 blocker 级别的安全问题 步骤 2交叉引用~3 分钟 对比 Subagent A路由和 Subagent C服务的输出 发现 3 处路由-服务映射不一致 A 报告/api/order 由 OrderService 处理 C 报告OrderService 已废弃实际由 CheckoutService 处理 → 主会话亲自读 src/routes/order.ts 确认 → 确认 C 的发现正确OrderService 文件存在但未被引用 步骤 3构建整体视图~2 分钟 合并 5 份结果形成微服务拆分建议 - 识别出 4 个潜在的服务边界 - 标记 2 个跨服务的数据依赖需要解决 - 2 个安全 blocker 需要在拆分前修复 - 部署配置简单容器化改造难度低 总耗时~11 分钟含汇总 总 token~22,0005 个 subagent 主会话汇总 对比串行执行 预计耗时~30 分钟 预计 token~18,000省了 subagent 初始化开销 主会话上下文~18,000 tokens全部挤在一个上下文里 结论并行方案用多 ~22% 的 token换来 ~63% 的时间节省 和 ~89% 的主会话上下文节省。对于后续的复杂拆分方案设计 干净的主会话上下文比 token 节省更有价值。并行 vs 串行的详细性能数据基于多个项目的实测数据 小任务探索 5 个文件以内 并行3,800 tokens2 分钟 串行2,200 tokens3 分钟 结论不值得并行调度开销占比过高~40% 中任务探索 5-15 个文件2-3 个方向 并行8,500 tokens4 分钟 串行7,200 tokens10 分钟 结论并行划算时间节省 60%上下文节省 70% 大任务探索 15 个文件4 个方向 并行22,000 tokens11 分钟 串行18,000 tokens30 分钟 结论强烈推荐并行时间节省 63%上下文节省 89% 超大任务全项目级探索6 个方向 并行35,000 tokens15 分钟 串行28,000 tokens50 分钟 结论必须并行串行的认知疲劳会导致重大遗漏反模式简单任务的过度并行经过团队接到一个 bug 修复用户头像上传后偶尔显示旧图片。这是一个缓存问题预计改动不超过 10 行。负责的工程师决定用并行探索找到根因派发了 5 个 subagentSubagent 1: 查找头像上传相关的所有文件 Subagent 2: 查找图片缓存相关的所有代码 Subagent 3: 查找 CDN 配置和缓存策略 Subagent 4: 查找前端图片组件的实现 Subagent 5: 查找相关的历史 bug 和修复记录结果Token 消耗 5 个 subagent 各消耗 ~2,000-3,000 tokens 主会话汇总消耗 ~1,500 tokens 总计~14,000 tokens 实际根因 图片上传后CDN 缓存没有失效。 修复上传成功后调用 CDN purge API。 改动1 个文件3 行代码。 如果主会话自己处理 读上传 handler → 发现没有缓存失效逻辑 → 修复 预估~2,000 tokens5 分钟根因过度并行化。5 个 subagent 里有 3 个根本没找到有用信息CDN 配置、前端组件、历史 bug 都和根因无关。并行化是对的但不是所有任务都需要并行化。判断标准出了问题修复并行化的前提条件检查派发并行 subagent 前确认 1. 每个子任务返回的信息对其他子任务是独立的 不是不同角度搜索同一个东西 2. 预估每个子任务的输出都大于调度开销~500 tokens 3. 主会话单独处理的总时间预计 5 分钟 4. 探索范围涉及 10 个文件 不满足任意一条 → 不要并行主会话自己处理。对于这个头像 bug正确做法1. 主会话读取上传 handler 文件 2. 发现上传成功后没有调用缓存失效 3. 加上缓存失效调用 4. 跑测试确认 总耗时3 分钟 总 token~2,000 不需要任何 subagent。交叉参考• 12 - Subagents 心智模型[1]并行探索背后的核心机制——独立上下文和专门角色• 13 - 高价值角色[2]Explorer、Reviewer、Test Runner 的角色定义和组合模式• 16 - 不该用 Subagent 的场景[3]并行探索的边界——哪些任务不值得并行化• 14 - 工具权限[4]并行探索中每个 subagent 的工具权限配置引用链接[1]12 - Subagents 心智模型:12-subagents-mental-model.md[2]13 - 高价值角色:13-high-value-subagents.md[3]16 - 不该用 Subagent 的场景:16-when-not-to-use-subagents.md[4]14 - 工具权限:14-subagent-tool-permissions.md