多智能体协作调研报告
调研时间：2026-05-19 作者：lijq
一、背景：为什么需要多智能体？
单 Agent 的天花板
在多 Agent 协作成为行业热词之前，AI 工具的形态大多是「超级助理」——你问它答，单线交互。写文案可以，做分析可以，但面对「从 0 到 1 做一个产品」这类真正复杂的商业问题，单 Agent 力不从心。
原因不是 AI 不够聪明，而是复杂任务从来不是一个人能搞定的。一个 App 上线，需要产品经理写 PRD、架构师出技术方案、工程师并行写代码、QA 跑测试——5 个专业角色、串行并行交织的工作流，拿一个通用 AI 从第一步问到第五步，来回拉扯，信息断裂。
纳米 AI 给出了一组直白的数据：单个 Agent 成功率达到 90% 时，5 个 Agent 协作的整体成功率会降到 50% 以下。多步骤工作流里的错误率，是以指数方式复合叠加的。 每步 95% 的可靠性，跑 20 步，成功率仅剩约 30%。
所以，多 Agent 的本质问题不是”要不要协作”，而是如何让多 Agent 协作 1+1 大于 2，而不是小于 1。
需要多 Agent 的三个核心原因
综合 Anthropic、LangChain 等官方文档，多 Agent 的核心价值体现在三点：
- 上下文管理：按任务分发知识，避免单窗口塞满无关内容，子 Agent 各自探索，只把摘要汇回主线
- 并行化：独立子任务并发执行，总耗时约等于最长子任务的时长
- 专业分工：各 Agent 各司其职，像真实团队一样协同，质量高于单 Agent 全包
二、什么是多 Agent 系统？
基础定义
Anthropic 的定义：
“A multi-agent system consists of multiple agents (LLMs autonomously using tools in a loop) working together.”
单个 Agent 的本质是：工具在循环中的调用（tools in a loop）。模型接收 prompt，选择工具，执行，根据结果决定下一步，反复迭代直到完成任务。多 Agent 系统就是多个这样的循环相互协作。
Workflow vs Agent：两种形态
Anthropic 将 Agentic 系统分为两层：
| 类型 | 定义 | 控制方式 |
|---|---|---|
| Workflow（工作流） | LLM 与工具由预定义代码路径编排 | 确定性、可预测 |
| Agent（智能体） | LLM 动态决定流程与工具使用 | 自主、灵活 |
生产中最常见的是混合形态：「编排器（Orchestrator）+ 多个子 Agent（Worker）」。编排器负责任务拆解与分发，Worker 负责执行，结果汇回编排器综合。
智能体发展分级
参考纳米 AI 在 2025 年夏天 的行业分级框架（类比自动驾驶）：
| 等级 | 形态 | 代表 |
|---|---|---|
| L1 | 聊天助手/工具 | 早期 ChatGPT/GPTs |
| L2 | 低代码工作流工具 | Dify，需人工搭建流程 |
| L3 | 具备推理能力的专家智能体 | 早期 Manus、Genspark，各垂直领域专家 |
| L4 | 多智能体蜂群协作 | 纳米 AI 多智能体蜂群，群体智慧完成复杂任务 |
| L5（预测） | Agent-Create-Agent | 可创建智能体的超级智能体（现在也已经实现了） |
三、协作模式全景
Anthropic 归纳的五种基础模式
| 模式 | 机制 | 典型场景 |
|---|---|---|
| Prompt Chaining（管道） | 上一步输出作为下一步输入 | 大纲→全文；文案→翻译 |
| Routing（路由） | 分类输入后导向专门处理 | 客服分流；简单问题用轻量模型 |
| Parallelization（并行） | 多子任务同时运行，或同一任务多次运行投票 | 并行调研；多审核员评分 |
| Orchestrator-Workers | 中央 LLM 动态拆任务、委派 Worker、汇总 | 多文件编码；多源调研 |
| Evaluator-Optimizer | 生成↔评估循环 | 文学翻译；代码评审迭代 |
各大框架的模式实现
| 模式 | 代表框架 |
|---|---|
| Orchestrator-Worker | Anthropic Research、LangChain |
| Pipeline / Sequential | CrewAI sequential |
| Routing | LangChain Router |
| Parallel / Fan-out-Fan-in | OpenAI parallel agents |
| Evaluator-Optimizer | AutoGen Reflection（primary + critic） |
| Handoff / Swarm | AutoGen Swarm、LangChain Handoffs |
| Hierarchical | CrewAI hierarchical |
| Peer Agent Teams | Anthropic Agent teams（Claude Code） |
Anthropic 官方的三个核心原则
- 保持设计简单：先直连 LLM API，仅在复杂度被证明有价值时才上多 Agent
- 透明展示规划步骤
- 精心设计 Agent-Computer Interface（ACI）：工具文档与测试与人机界面同等重要
四、多 agent 和==子 agent ==的区别
什么是 subagent
Subagent 就是「子智能体」，可以理解为被主 Agent 召唤出来干活的助手。
用一个比喻来说：主 Agent 是项目经理，subagent 是它临时派出去执行具体任务的专员。项目经理不亲自去查资料、跑代码，而是把具体活儿分派给不同的专员去做，专员做完把结果汇报回来。
核心特点：
- 每个 subagent 都运行在独立的上下文窗口里，互相不干扰
- 只负责完成分配给它的那一个子任务，完成后把结果返回给主 Agent
- 主 Agent 收到所有 subagent 的汇报后，再综合给出最终结果
为什么需要 subagent？
- 上下文隔离：主对话窗口不会被大量中间信息塞满，每个 subagent 只带走它需要的信息
- 并行：多个 subagent 可以同时运行，比如同时调研 A、B、C 三个模块，总耗时等于最慢那个
- 专业化：不同 subagent 可以配置不同的工具、模型、权限
举个例子： 你让 Cursor 做一个功能，主 Agent 可能同时派出：
- Explore subagent 去搜索代码库
- Bash subagent 去跑测试命令
- Browser subagent 去截图验证 UI
三个并行跑完，主 Agent 拿到三份结果再做决策。
简单说：主 Agent = 指挥官，subagent = 被派去执行具体任务的临时工。
subagent 和 multi-agent 的关系
这两个概念其实是包含关系，subagent 是多智能体协作的一种实现方式，但不是全部。
核心区别：主从 vs 对等
Subagent 是「主从」关系：
- 永远有一个主 Agent 在指挥
- Subagent 没有自主意志，只执行分配的子任务
- 做完就结束，结果汇报给主 Agent，自己消失
- 主 Agent 是唯一的决策中心
多智能体协作（广义）还包含「对等」关系：
- 多个 Agent 可以互相对话、互相质疑、互相协商
- 没有单一的指挥官，或者说指挥官本身也是 Agent
- Agent 之间可以持续存在，跨任务保留记忆和角色
用调研的案例来对照
| 产品 | 模式 | 说明 |
|---|---|---|
| Cursor Subagent | 主从 | 主 Agent 派 Explore/Bash/Browser 出去，做完回来汇报 |
| Claude Code Subagent | 主从 | Agent tool 派子 Agent，子 Agent 不能再派子 Agent |
| WorkBuddy | 偏主从 | 主 Agent WorkBuddy 指挥，团队成员在后台执行 |
| Qoder 专家团 | 偏主从 | Team Lead 指挥，专家各自独立上下文执行 |
| Accio Work 群聊模式 | 偏对等 | Agent 之间可以互相 @，成员可以直接回复用户，不必经过 TL |
| 三省六部 AI 圆桌 | 真正对等 | 7 个 Agent 互相质疑、辩论，没有中心指挥官 |
| Claude Code Agent Teams | 对等（实验中） | Teammates 可以互发消息，有共享任务板 |
一句话总结
Subagent = 多智能体协作的最基础形式（主从派发）
多智能体协作 = 包含主从 + 对等 + 各种混合模式
以 Accio 为例
- 直接发送消息 — 消息默认发给 TL；TL 分析后决定如何处理
- @ 特定 Agent — 使用
@Agent名称直接指派给某位成员 - @ 所有人 — TL 和所有成员都会响应
- 点击成员头像 — 查看该 Agent 的执行进度和状态，了解每位成员正在做什么
TL（团队负责人）——团队协调者
TL 是团队的核心角色，职责包括：
- 任务分析 — 收到用户消息后，决定自行处理还是委派给成员
- 任务分配 — 在不同模式下通过调用任务派送工具或
@{agent_id}激活成员并分配具体任务 - 结果汇总 — 收集成员的输出并整合成最终回复
- 团队管理 — 可在运行时邀请或移除团队成员，甚至动态创建新 Agent
TL 专属能力：
| 能力 | 说明 |
|---|---|
| 邀请成员 | 将新 Agent 加入当前团队 |
| 移除成员 | 将 Agent 从当前团队移除 |
| 创建 Agent | 在运行时动态创建新的专业 Agent |
| 发送消息 | 直接向指定 Agent 发送消息并等待回复 |
成员（Member）——专业执行者
成员是团队中的专业角色，每位成员应有明确的角色描述。特点：
- 被 @ 时激活 — 只在群聊模式下被 TL 或其他 Agent @ 时才响应
- 专注本职角色 — 根据角色描述处理分配的任务
- 协作反馈 — 完成后在群聊中汇报结果，其他成员可见
- 同伴协作 — 成员之间可以互相寻求帮助
工具继承： 团队中每个 Agent 继承创建时所选模板的工具集。例如，基于 Coder 模板的 Agent 拥有终端和浏览器工具；基于 Reviewer 模板的 Agent 拥有只读工具。TL 在模板工具集的基础上，额外获得团队管理工具（邀请/移除成员等）。关于工具详情，请参阅 Agent 能力指南。
SubAgent——后台任务执行者
每个 Agent（TL 或成员）都可以启动 SubAgent 来处理后台子任务。SubAgent 适合并行或独立执行的场景。
| SubAgent 类型 | 适用场景 |
|---|---|
| explore | 代码搜索和文件分析 |
| bash | 命令执行和脚本运行 |
| browser | 网页交互和自动化 |
| general | 通用任务（继承父 Agent 的大部分工具） |
SubAgent 与成员的对比：
| 维度 | 成员 | SubAgent |
|---|---|---|
| 可见性 | 在群聊中；所有消息可见 | 不在群聊中；独立 Session |
| 激活方式 | 被分配任务或 @ 时激活 | 由父 Agent 通过工具调用创建 |
| 生命周期 | 持久存在 | 任务完成后结束 |
| 能力 | 完整 Agent 能力 | 工具集受限；不能创建子任务 |
五、360 纳米 AI
核心定位：多智能体蜂群
纳米 AI 以「多智能体蜂群」为核心卖点，将其定义为 L4 级智能体。不同于强调「多智能体协同」的其他平台，纳米 AI 的差异化在于：
- 团队规模更大：单次任务可调用数十个专家智能体
- 智能体间可共享记忆，解决协同困境
- 支持自定义 DIY 团队内部的智能体储备
整个蜂群架构由三部分组成：
- 360 智能体工厂：超级人才市场，5 万+ 智能体可按需组团
- 多智能体蜂群引擎：支持异步并行运行、多层嵌套、灵活拉群
- 多智能体蜂群协作空间：多智能体协作时共享「记忆」，实现任务规划、协同执行、自我迭代
工作流架构
类似于 coze、dify、bisheng，各种工作流节点
手动创建团队
和清小搭类似，手动创建团队成员。执行任务的过程中是能明确看到某个智能体在做什么的，跟清小搭类似。
执行过程中可以明确看到某个智能体在做什么——全程透明可编辑，包括风格选择、BGM 选择、文案修改，都可以人为干预随时修改，更像一个人机协作的空间。
「一句话生成大片」案例
典型蜂群应用：用一句话生成 10 分钟 AI 视频大片。
任务触发后，系统自动「拉群」，调用：超级配音演员、智能绘图专家、高级摄像师、高级剪辑师、影视后期专家等多个专家智能体，完成创意策划→分镜设计→画面生成→配音配乐→剪辑合成的全流程。
- Token 消耗：1437 万+（业内普遍上限 100 万的 14 倍）
- 蜂群整体成功率：95.4%
- 单个智能体单步成功率：99.97%（千万级用户规模下）
技术保障
- 自研 360 智脑 72B 模型，100 步成功率 98.2%，接近 Claude 3.7 的 99%，千 Token 成本低 80%
- 自研 MCP Infrastructure 和 Agent Infrastructure
- 自研轻量级云端虚拟机，1 秒快速启动
- 智能体自我修复、自我反思的容错机制
总结
周鸿祎的评价很好地概括了这个产品的设计哲学：
单个智能体再强，也只是「器」的层面。通过协作框架，将不同能力的「器」有机组合，形成一个能解决复杂问题的「道」，这才是系统架构的魅力。
六、腾讯 WorkBuddy
背景
WorkBuddy 是腾讯自研的 AI 原生办公智能体平台。从 2026 年 3 月 9 日正式上线，到 60 天后登顶国内 PC 端 AI 原生办公智能体月访问量第一。
核心定位
推荐用户：个体创业者、自由职业者、小微团队负责人 能力描述：召唤你的 AI 专家团，覆盖运营、设计、财务、法务、开发等核心岗位，多专家并行协作，从策略到交付全程自主完成
核心机制：不是一个 AI 回答所有问题，而是有团长、有分工、有协作的多 Agent 团队。用自然语言描述需求，团长自动将任务拆解为子任务，分配给最合适的团员并行执行，最后汇总整合交付完整结果。
专家团组成
WorkBuddy 目前上线 24 个专家团、160 位 AI 角色，覆盖完整职能链。其中 9 个 OPC（一人公司）专属团，按公司部门逻辑排列：
- 产研部——软件工坊，6 人团队，完整软件生命周期
- 市场部——内容创作专家团 + 全域内容分发专家团，10 人
- 市场部（SEO）——SEO 内容营销团队，7 人
- 销售变现——内容变现商业化 + 社媒互动增长，10 人
- 财务部——财税合规专家团，6 人
- 法务部——中文法律咨询团，6 人
- BI/数据——智数分析专家团，6 人
交互设计特点
- 由一个主智能体 WorkBuddy 主导对话，团队成员的具体工作是弱化的，需要在侧边展开才能看到
- 侧边可以看到每个阶段的产物，以及每个专家的人设、调用的工具、执行的命令等
任务执行结束后，团队会被删除。
快速切换不同的专家团队
与其他产品的设计差异
WorkBuddy 的 UI 设计倾向于简化用户感知：用户只需与主 Agent 对话，团队成员在后台并行运转，侧边栏作为可选的透明度窗口。这降低了使用门槛，但也相应减少了用户对协作过程的直接参与感。
七、阿里 Qoder 专家团
核心定位：多智能体协同编程
Qoder 是阿里推出的 AI Coding 工具，其「专家团模式（Experts Mode）」是多 Agent 协作在编程领域的典型落地。
核心思路：组建一支赛博工程团队——有 Team Lead（指挥官）、前端工程师、后端工程师、测试工程师、代码评审员等不同角色，各司其职，并行推进。
动态生成 Agent，没有预设角色
与 WorkBuddy 的预设专家团不同，Qoder 没有默认的专家团列表，没有预设的「角色」，每次根据不同的任务生成专属专家。
每个专家都是一个 agent.md 文件，根据任务的不同而动态生成。
这种设计的好处是灵活适配任务，不局限于预设角色边界；代价是每次冷启动，缺乏跨任务的角色积累。
实测：16 分钟搭建个人博客
任务输入：从 0 开始做一个个人博客
执行流程：
- Team Lead 自动解析需求，拆解为 8 个子任务
- 通用工程师 Nick 负责安装依赖、搭建项目结构
- 后端工程师 Jimmy 初始化数据库
- 5 位工程师分别负责前端、中间件、后端 API（出现多人同时推进的并行情况）
- 测试工程师 Chris 完整流程验证（打开浏览器，登录，测试增删改查）
- 代码评审员 Mark 找到多个漏洞并按严重程度分级
- 并行修复漏洞
结果：16 分钟内完成，具有完整增删改查逻辑的个人博客。
关键能力
- 开发者可随时介入流程，提出问题或改变需求
- 发现两个任务互相没有依赖关系时，系统自动并行处理
- 专家各自在独立的上下文中工作，互相协同，应对更多交互轮次
- 工程知识引擎：整合代码文件、提交历史、RepoWiki、记忆，优化深度理解上下文
- Qoder 内部基准测试：专家团模式代码质量得分较自身智能体模式提升 67%，领先 Claude Code Agent Teams 16%
行业意义
Qoder 的出现标志着 AI Coding 从「Vibe Coding（氛围编程）」走向了「多智能体协同编程」时代。AI IDE 也从组织代码，转向组织智能体。
八、阿里国际站 Accio Work
产品背景
Accio Work 是阿里国际站推出的桌面端 AI Agent 平台，本来定位是跨境电商，但因为多 Agent 协同体验做得好，无需邀请码且有免费额度，被大量用户拿来做各种多 Agent 协同实验——三省六部制、AI 圆桌、斗地主等。
双模式设计：调度模式 vs 群聊模式
Accio Work 团队支持两种协作模式：
调度模式（Dispatch Mode）：
- 消息默认发给 TL（Team Lead）
- TL 分析后调用任务派送工具，对团队成员分配任务
- 侧重过程管控，经 TL 分发与汇总
- 适合需要统一入口汇总结论的场景
群聊模式（Group Chat Mode）：
- 用户可以 @ 特定 Agent 直接激活
- TL 和成员之间可多向互动
- 适合需要多角色互相讨论的复杂决策任务
核心架构
**TL（团队负责人）**职责：
- 任务分析：收到消息后，决定自行处理还是委派给成员
- 任务分配：通过任务派送工具或 @ 激活成员
- 结果汇总：收集成员输出，整合最终回复
- 团队管理：可在运行时动态创建新 Agent、邀请或移除成员
SubAgent 机制：
- 每个 Agent（TL 或成员）都可以启动 SubAgent 处理后台子任务
- 类型包括：explore（代码/文件分析）、bash（命令执行）、browser（网页自动化）、general（通用）
- SubAgent 不在群聊中，独立 Session，任务完成后结束
Agent 核心设计：
每个 Agent 有独立的 agent-core 目录，包含 SOUL.md（人格）、IDENTITY.md（身份）、MEMORY.md（长期记忆）、USER.md（用户档案）等文件，构建跨会话的持久个体。
自我进化机制：
- 自动检测值得保存的内容，写入记忆文件
- 重复任务会被固化为可复用技能
/dream命令整理短期记忆、日记与长期记忆
「三省六部制」多 Agent 实验
用 Accio Work 复刻了唐朝三省六部制，构建了一套多 Agent OPC（一人公司）协同方案：
三省六部架构：
- 中书省（中书令）：起草方案，出创意
- 门下省（门下侍中）：审议把关，挑毛病
- 尚书省（尚书令）：综合审议结果，拆任务分派六部
- 六部（吏户礼兵刑工）：各司其职，并行执行
实测结果（开发「心流码字器」产品）：
- 中书令出了 3 个差异化方案
- 门下侍中严格审议，打回一个方案，并提出 3 个跨方案共性问题
- 尚书令综合决断后，将任务分配给六部并行评估
- 兵部扫了 30+ 竞品，发现市场时间窗口约 6 周
- 礼部给产品起名「墨沉」，回答了用户为什么主动晒截图
- 刑部做合规评估：必须注册个体工商户，字体要用免费商用字体
- 户部做财务模型，工部出技术架构，吏部出人力规划
- 全程 40 分钟，输出 12 份交付文件
AI 圆桌实验（群聊模式的另一种玩法）： 7 个 Agent 圆桌，6 个顶级模型（Opus 4.6、GPT-5.4、Kimi K2.5、Qwen3 Max、Gemini 3.1 Pro、Minimax M2.5）+ 1 个主持，5 轮流程（独立分析→交叉质疑→回应修正→共识收集→意见领袖撰写最终报告），跑了 10 场议题。
这种多视角的并行思考，才是 AI 对 OPC 最大的赋能——每个 Agent 只站在自己的角度深度思考，通过流程汇聚成整体决策。
Agent Team vs SubAgent 对比
| 维度 | Agent Team | SubAgent |
|---|---|---|
| 协作模式 | 像团队协作，持续存在 | 像临时委托的子任务 |
| 生命周期 | 持续存在，支持群聊 | 短暂，任务完成后结束 |
| 用户感知 | 用户可见，可参与讨论 | 通常对用户无感知 |
| 适用场景 | 多角色协同复杂项目 | 父 Agent 内部并行化 |
最佳实践建议（来自官方文档）
- 为每个 Agent 撰写清晰的角色描述（直接影响 TL 分配质量）
- 团队规模：2–3 人适合专项任务，4–5 人适合完整工作流，避免超过 7 人（协调成本过高）
- 先以单 Agent 或「TL + 1-2 名成员」验证流程，再逐步扩展
- 可重复的专项动作沉淀为 Skills，不要全塞进 Agent Prompt
九、开发者工具中的多 Agent：Cursor 与 Claude Code
Cursor 的子 Agent 体系
Agent 模式基础
Cursor Agent 由三个组件构成：Instructions（系统提示 + Rules）+ Tools（文件编辑、代码库搜索、终端执行等）+ Model。支持四种模式（Shift+Tab 切换）：
| 模式 | 适用场景 | 能否改文件 |
|---|---|---|
| Agent | 构建功能、重构、修 bug | 是 |
| Ask | 理解代码、探索架构（只读） | 否 |
| Plan | 复杂功能，先审计划再实现 | 批准后是 |
| Debug | 难复现、需运行时证据的 bug | 是 |
Subagents（2026-01-22，版本 2.4 首发）
主 Agent 通过 Task tool 委派子 Agent。子 Agent 运行在各自独立的上下文窗口，完成后返回最终消息给父 Agent。
三个内置子 Agent：
- Explore：搜索/分析代码库（更快模型，可并行多次搜索）
- Bash：执行一系列 shell 命令
- Browser：通过 MCP 控制浏览器
嵌套子 Agent（Cursor 2.5+）：子 Agent 可再启动 child subagents，形成树状协作结构。
多 Agent 并行能力时间线：
- 2026-01-22（v2.4）：Subagents 正式发布
- 2026-03-05：Cursor Automations，事件触发的始终在线 Agent
- 2026-04-02（Cursor 3）：Agents Window，agent-first 界面，支持本地/云端/SSH 并行
- 2026-04-24（v3.2）：
/multitask，用 async subagents 并行处理请求 - 2026-05-07（v3.3）：Build in Parallel，识别计划中独立部分并行执行
- 2026-05-13（v3.4）：多 repo 云环境，fleet of parallelized agents
Cloud Agents（原 Background Agents）：在云端 VM 中独立运行，可通过 Web、Slack、GitHub、Linear、API 触发，不依赖本机在线。
Claude Code 的子 Agent 体系
核心工作方式
三阶段 Agentic 循环：Gather context（收集上下文）→ Take action（执行）→ Verify results（验证），可交织、可循环。
Agent 工具（原 Task tool，v2.1.63 改名）
“The Agent tool spawns a subagent in a separate context window. The subagent works through its task autonomously, then returns a single text result to the parent conversation.”
关键特性：
- 子 Agent 无父对话历史，仅通过 prompt 注入上下文
- 调用 Agent 工具本身不需逐次批准，子 Agent 内部工具仍走权限规则
- 子 Agent 不能再 spawn 子 Agent（“Subagents cannot spawn other subagents”）
内置子 Agent：
- Explore（Haiku 模型，只读）：代码库搜索与分析
- Plan（只读）：调研后出计划
- general-purpose（全工具）：多步任务
并行方式对比：
| 方式 | 并行形态 |
|---|---|
| Subagents | 单会话内委派，结果回传 |
| Agent view | 多独立会话后台运行，统一监控 |
| Agent teams | 多实例 + 共享任务列表 + 互发消息（实验功能） |
| Git worktrees | 多会话文件隔离 |
| /batch | 5–30 个 worktree 隔离子 Agent，各开 PR |
Agent Teams（实验功能）
与 Subagents 的核心区别：子 Agent 只向主 Agent 汇报；Agent Teams 中 Teammates 可以直接互发消息，拥有共享任务板。
启用方式：CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
十、横向对比
产品形态对比
| 维度 | 纳米 AI | WorkBuddy | Qoder | Accio Work |
|---|---|---|---|---|
| 定位 | 通用多任务蜂群 | OPC 办公虚拟公司 | AI Coding 专家团 | 跨境电商 Agent |
| 角色来源 | 预设 + 自定义 DIY | 24 个预设专家团 | 按任务动态生成 | 预设模板 + 自定义 |
| 协调模式 | 蜂群引擎自动协调 | 主 Agent 主导 | Team Lead 指挥 | TL 调度 / 群聊双模式 |
| 过程可见性 | 全程透明，可干预 | 侧边展开查看 | 可随时介入 | 群聊中可见，侧边详情 |
| 任务结束 | 团队保留 | 团队解散 | 任务完成后自动 | 团队持续存在 |
| 记忆机制 | 智能体间共享记忆 | 无 | 工程知识引擎 | 独立长期记忆 + 跨会话 |
| SubAgent | 支持多层嵌套 | 无明确描述 | 独立上下文协同 | 支持（explore/bash/browser/general） |
开发者工具对比
| 维度 | Cursor Subagents | Claude Code Subagents |
|---|---|---|
| 子 Agent 嵌套 | 2.5+ 支持树状嵌套 | 不支持，只能链式委派 |
| 并行 | Task tool 多调用并行 | Agent tool 多调用并行 |
| 后台运行 | foreground/background 可选 | foreground/background 可选 |
| 内置子 Agent | Explore、Bash、Browser | Explore、Plan、general-purpose |
| 跨会话协作 | Agents Window + Cloud Agents | Agent teams（实验功能） |
| 自动化触发 | Automations（Slack、GitHub 等） | 无（需手动或 API） |
十一、思考与总结
当前行业的核心分歧
多智能体产品的设计上，存在一个根本性的取舍：
简化用户感知 vs 保留用户控制权
- WorkBuddy 更偏向「黑箱」风格——用户只需下指令，团队自动运转，过程弱化
- Accio Work、Qoder 更偏向「透明协作」——用户可以介入，可以 @ 特定成员，可以看到每个 Agent 在做什么
没有绝对的对错，背后是不同用户心智的选择。对于专业用户，透明度和可控性更重要；对于普通用户，黑箱式的「一句话交付」体验更友好。
多智能体还没有解决的问题
- 可靠性：错误指数级复合叠加依然是核心挑战。纳米 AI 99.97% 的单步成功率来自大量基础设施投入，普通团队难以复制
- 上下文工程：多 Agent 共享上下文会导致信息膨胀；隔离上下文又容易信息断层。这是当前所有产品都在权衡的核心工程问题
- 协调成本：团队越大，协调开销越高。Accio Work 官方建议不超过 7 人，Anthropic 建议先验证再扩展
- Agent 间的真正沟通：大多数产品的 Agent 之间还是「主从」关系，真正的对等 Agent 通信（Peer-to-Peer）仍是实验功能
十二、参考资料
产品案例
- 纳米 AI 蜂群：智能体迈入L4时代！纳米AI多智能体蜂群，可创作史上最长10分钟AI视频
- 腾讯 WorkBuddy：60天，腾讯，掀起一场组织”革命”
- 阿里 Qoder：1段话喊来13个”程序员”，阿里Qoder新模式让我躺着当CTO
- Accio Work：我用1400年前的三省六部制，搞了一套很酷的多Agent协同方案
- Accio Work 官方文档：帮助中心 | Agent 团队指南
官方文档
- Anthropic: Building effective agents
- Anthropic: How we built our multi-agent research system
- Claude Code: Sub-agents
- Cursor: Subagents
- Cursor: Cloud Agents
- Cursor: Changelog 2.4 - Subagents
十三、更早一些的产品调研-2025.08
metaGPT x MGX
不是一个简单的 AI 助手，而是一个完整的 AI 开发团队，包含产品经理、架构师、工程师和数据分析师等多个角色。
-
Mike（团队领导）：统筹全局，管理团队协作
-
Emma（产品经理）：负责需求分析和产品规划
-
Bob（架构师）：设计系统架构和技术方案
-
Alex（工程师）：负责具体代码实现
-
David（数据分析师）：处理数据分析相关工作