多智能体群：何时使用，何时跳过

"各子任务能在互不知情的情况下完成吗？"

如果能 → 群组是候选方案。如果不能 → 单智能体。

通过检验的例子（子智能体运作良好）：

• "分别审计这 5 个微服务的安全问题。"每次审计相互独立，最后汇总结果。
• "读取这 12 个文件，逐一总结各自的功能。"逐文件摘要不需要相互参照。
• "为这个功能尝试三种不同的架构，返回最佳方案。"独立尝试，最终择优。
• "评审这个 PR（一个智能体），独立于写这个 PR 的智能体。"对抗性配对。

未通过检验的例子（单智能体更优）：

• "将这个代码库重构为 TypeScript strict 模式。"每个文件的改动都依赖于前面文件中确立的类型模式。
• "调试这个失败的测试。"调试是一系列推理链，每一步都建立在上一步之上。
• "写一篇关于 X 的教程。"第一段制约着第二段，顺序思考本身就是核心工作。

当你想着"我先启动一个智能体做规划，再启动另一个执行"时——停一下。规划者的上下文恰恰是执行者所需要的；单独启动执行者意味着要把所有内容重新喂一遍。带有"先规划后执行"提示的单智能体，通常优于两个串行智能体，因为交接过程中不会丢失任何上下文。

每种模式都有其特定的胜出理由

模式一：并行独立工作。N 个任务互不依赖，最终汇总结果。典型案例："并行审计这 5 个服务。"五个子智能体同时运行；总耗时约等于最长的单次审计，而非所有审计之和。token 成本随 N 线性增长，但你在为真实工作付费，而非为协调开销买单。

模式二：多角度探索。"为这个功能尝试三种实现方案。"每个子智能体单独尝试一种方案。父智能体读取三个结果并择优（或综合）。当你否则会过早押注某一方案时最为有效；并行探索能捕捉到那种"方案二明显更好，但你可能根本不会去写它"的情况。

模式三：对抗性评审。一个智能体产出内容；另一个拥有干净上下文的智能体进行评审。评审者缺乏上下文恰恰是优势：它能发现作者自我合理化掉的问题。经典形式是"写作智能体 + 编辑智能体"，但同样适用于代码（提出者 + 批评者）和设计（设计师 + 质疑者）。最少两个智能体；更多评审者通常帮助不大。

模式四：带有独立阶段的长周期计划。某些工作流存在真正不需要共享工作状态的阶段——"研究这个主题"，然后"用研究成果起草文档"，然后"格式化并检查文档"。每个阶段的输出是下一阶段的输入；中间过程不需要保留。串行的子智能体序列（每个仅接收上一个的最终输出）能保持上下文预算低廉，让每个阶段专注于自身任务。

启动子智能体的代价超过收益的场景

反模式一：为小任务启动子智能体。如果一个任务用 5–10 句提示就能描述清楚，父智能体不到一分钟就能完成，那么启动子智能体的准备开销（重新解释上下文、重新加载工具）就超过了实际工作量。阈值：只为那些需要独立上下文窗口、或需要几分钟计算时间的任务启动子智能体。

反模式二：为了编排而编排。启动一个"管理者"子智能体，其唯一工作是启动其他子智能体。这个管理者没有父智能体不具备的任何能力；它只是增加了一个消耗 token 的中间环节。如果父智能体能决定要启动哪些子智能体，就应该由父智能体直接启动。

反模式三：本该是一次对话的串行子智能体链。"智能体 A 读取文件，智能体 B 分析 A 读到的内容，智能体 C 写出修复。"如果 A 对文件的理解正是 B 和 C 所需要的，那么每次交接都在付出重新解释的代价。让单个智能体读取文件后在对话中依次完成 A→B→C 更优。经验法则：如果各阶段之间的自然数据流就是前一阶段所知道的一切，那么这些阶段就应该是同一个智能体。

让子智能体的任务清晰明确，不要让它自己去猜边界

子智能体对父智能体的推理过程一无所知。父智能体传递的内容就是它们能得到的全部。父提示中常见的两个错误：

• 描述不足。"审计这个服务"让子智能体自己决定看什么——安全、性能、架构、命名？五个子智能体审计五个服务时，可能每个对"审计"的理解都不同，产出的报告无法横向对比。要明确范围："专门审计这个服务中的 SQL 注入模式。查找到达数据库层的未经清理的输入；每个发现报告 file:line 及建议的修复方案。"
• 过度解释。把父智能体的全部上下文都塞进子智能体的提示，会让群组模式失去意义。子智能体现在的上下文膨胀程度和父智能体一样。只传递子智能体真正需要的内容。

一个好的父提示读起来应该像一份独立的 bug 报告：足够完成工作的上下文，没有父智能体为何决定委托的叙事背景。

Explore、Plan、并行 Task、自定义子智能体

LingCode 将上述模式作为具体工具提供：

• Explore 子智能体——快速只读搜索，用于"查找 / 统计 / 定位"类工作。成本低，上下文独立，返回摘录。当答案是"哪些文件提到了 X"或"Y 的结构是什么"时使用。不能用于代码编辑——它无法写入。
• Plan 子智能体——为复杂任务设计实现策略。返回包含关键文件识别的分步计划。用作模式四（长周期）的"规划阶段"。
• 通用子智能体——拥有所有工具的完整智能体循环。用于真正的并行工作：为 N 个独立任务启动 N 个这样的子智能体。
• 自定义子智能体通过 .claude/agents/——定义你自己的受限工具集。适用于重复性专项任务（"SQL 注入审计员"）。参见 编写子智能体。

模式与工具对照：

• 并行独立（模式一）→ 在单条消息中启动多个 Explore 或通用子智能体。
• 多角度探索（模式二）→ 多个通用子智能体，每个提示中包含不同的方案方向。
• 对抗性评审（模式三）→ 主智能体产出，自定义"评审者"子智能体批评。
• 长周期（模式四）→ 串行 Explore → Plan → 通用子智能体链。

N 个智能体都返回了，然后呢？

群组的输出是 N 个部分答案。将它们合并本身也是一项任务——也是群组方案最常退化为比单智能体更差的结果的地方。三种应对方法：

• 拼接。如果每个子智能体的输出是独立的（例如逐文件摘要），直接堆叠成最终报告。成本最低；当没有需要协调的重叠内容时最有效。
• 投票或择优。如果子智能体探索了 N 种方案（模式二），父智能体读取所有 N 个并择优（或融合最强部分）。父智能体的判断就是整合本身。
• 整合通道。将所有 N 个输出反馈给父智能体（或专门的整合子智能体），配合提示如："以下是对同一代码库的五份独立报告。找出在 ≥3 份报告中出现的发现——这些是高置信度问题。找出看起来重要的独特发现——这些需要二次审查。"

如果整合确实很难——子智能体产出了相互重叠、矛盾、难以调和的内容——这往往是任务实际上没有通过第一步"独立子任务"检验的信号。重新考虑单智能体是否会给出更清晰的答案。

三个真实 LingCode 任务的评分

任务："为这 8 个没有测试覆盖的模块添加测试。"每个模块的测试套件相互独立，模块之间不共享被测代码。模式一。启动 8 个通用子智能体，每个对应一个模块，并行执行。总耗时约等于最长的单个测试套件。成本约等于对单个模块运行单智能体的 8 倍。值得。

任务："将这个 50 个文件的代码库从 JavaScript 重构为 TypeScript。"每个文件的类型声明都依赖于其他文件的导入/导出；早期确立的类型定义制约着后续文件。单智能体。群组模式会让每个子智能体重新推导同一套类型模型，导致各文件的类型定义不一致。在上下文中保留类型映射的顺序智能体更优。

任务："调查这个生产环境崩溃。"调试是推理性的；每一条新证据都会引导下一步。单智能体。启动"日志读取器"、"堆栈追踪器"和"git 归责器"会产生三个局部视图，父智能体需要加以调和——而单智能体在读取这些材料时本可在拥有完整上下文的情况下自然完成这项工作。

任务："写一个营销落地页；让一个智能体起草，另一个评审其清晰度。"对抗性评审受益于干净的上下文。模式三。作者起草；评审者在未看到头脑风暴过程的情况下评审；作者根据评审意见修改。两个智能体，串行而非并行。