Skip to main content

Claude Code 与多智能体研究系统

一句话：前面两家都在拼命强调「子 Agent 之间绝不通信」，Anthropic 这边偏偏给子 Agent 开了三层嵌套和横向发消息——同一个问题，第三种答案。

一、材料清单​

材料硬度备注
How we built our multi-agent research system（2025-06-13）✅ 官方一手唯一公开了 token 成本量化数据的
Claude Code 子智能体官方文档✅ 官方一手配置项非常完整
anthropics/claude-agent-sdk-python 7,928★✅ 官方开源2026-08-18 仍在更新
anthropics/claude-agent-sdk-typescript 1,705★✅ 官方开源同上
VILA-Lab/Dive-into-Claude-Code 2,062★⚠️ 社区分析2026-08-16 更新，还活着
Yuyz0112/claude-code-reverse 2,428★⚠️ 社区逆向最后 push 2025-08-26，已停更一年，结论对应的是很老的版本

关于逆向仓库：cli.js 反混淆这条路上的仓库大多已经停更或被转手（memaxo/claude_code_re 现在跳转到一个 4 star 的账号）。Anthropic 对这类仓库有过 takedown 记录。好在官方文档和 SDK 的信息量已经远超逆向能挖到的，本文以官方材料为主，逆向仓库只作为「历史版本参考」列出。

二、Anthropic 的 orchestrator-worker：唯一公开了成本数字的​

官方博客里最有价值的是三组数字：

指标数值
Agent 相比普通聊天的 token 消耗约 4 倍
多 Agent 相比普通聊天的 token 消耗约 15 倍
并行子 Agent 带来的研究耗时下降最多 90%
token 用量对评测效果方差的解释力80%

最后一条最狠：在他们的研究评测里，光「烧了多少 token」这一个变量就解释了 80% 的效果差异。

这句话把多 Agent 的价值讲得很朴素——它之所以效果好，很大程度上不是因为「协作涌现出了智能」，而是因为并行让你在可接受的墙钟时间内烧掉了 15 倍的 token。

所以判据也就清楚了：

当任务的价值足够高，高到值得付 15 倍 token 的时候，多 Agent 才划算。

内部研究、竞品调研、大规模信息搜集这类任务符合；日常问答不符合。

架构本身​

官方强调的几条经验：

  1. 教会 orchestrator 怎么派活是重中之重。任务描述要足够自包含，否则子 Agent 之间会做重复劳动、或者集体漏掉某块。
  2. 子 Agent 互相不知道对方存在，也无法在任务中途协调——这是并行的前提。
  3. 评测用 LLM-as-judge 打分卡（准确性、引用、完整性），不规定它必须走哪条路径。
  4. 「最后一公里往往占了旅程的大部分」——从 demo 到生产的可靠性工程量远超预期。

第 1 条值得展开：多 Agent 系统里，prompt 工程的重心从「怎么让模型干好活」转移到了「怎么让模型把活分好」。 分活分不好，后面并行得再快也是白烧钱。

三、Claude Code 的子智能体：本专题里配置项最多的​

Claude Code 的子智能体是 Markdown 文件 + YAML frontmatter，按优先级从五个位置加载：

位置作用域优先级
托管设置（managed settings）全组织1（最高）
--agents CLI 参数当前会话2
.claude/agents/当前项目，可提交进版本库3
~/.claude/agents/个人全局4
插件的 agents/启用该插件处5

一个最小的子智能体长这样：

.claude/agents/code-reviewer.md
name: code-reviewer
description: Reviews code for quality and best practices
tools: Read, Glob, Grep
model: sonnet

You are a code reviewer. When invoked, analyze the code and provide
specific, actionable feedback on quality, security, and best practices.

对照 Kimi CLI 的 YAML 工种定义，结构惊人地像：都是「name + description + 工具白名单 + 模型 + 一段 system prompt」。区别在于 Kimi 的工种是内建在包里的，Claude Code 的可以放进项目仓库跟着代码走。

可选字段：这张表本身就是一份设计清单​

字段作用
tools工具白名单（省略则继承）
disallowedTools工具黑名单
modelsonnet / opus / haiku / fable / 完整 ID / inherit
permissionModedefault / acceptEdits / auto / dontAsk / bypassPermissions / plan
maxTurns最大轮数上限
skills启动时预加载的技能
mcpServers限定给这个子智能体的 MCP server
hooks生命周期钩子（PreToolUse / PostToolUse / Stop）
memory持久记忆作用域：user / project / local
background强制后台运行
effort覆盖会话的努力等级
isolation设成 worktree 就给它一个独立的 git worktree
initialPrompt作为主 Agent 运行时自动提交的第一轮

三个字段值得单拎出来：

mcpServers —— 对照 Kimi CLI 写死的 mcp_configs=[]：Kimi 是一刀切禁止子 Agent 用 MCP，Claude Code 是按子智能体粒度配。后者更灵活，代价是配错了就会重现 Kimi 想避免的那些问题（加载慢、工具描述撑爆上下文）。

isolation: worktree —— 给子智能体一个独立 git worktree，是介于「同进程上下文隔离」和「Manus 一台 VM」之间的一档隔离粒度。多个子智能体同时改代码互不冲突，成本远低于起虚拟机。这是本专题里我认为最巧妙的一个隔离设计。

memory —— 子智能体可以有跨会话的持久记忆。这比 Kimi CLI 的 resume 又往前一步：resume 是复活一个具体实例，memory 是让这个工种积累经验。

上下文隔离：明确列出了「带什么」和「不带什么」​

官方文档写得很清楚，一个非 fork 的子智能体启动时，全新上下文里只有：

  • 委派任务的那条消息
  • CLAUDE.md（Explore / Plan 这两个内建的除外）
  • git 状态快照
  • 预加载的 skills
  • 兄弟 Agent 名册（给 SendMessage 用）

没有：对话历史、之前的 skill 调用、已经读过的文件。

对照 Manus 官方的说法「fresh context for every item」，两家在「子 Agent 必须拿全新上下文」这点上完全一致。差别在最后一条——兄弟 Agent 名册。

四、两个例外：这里跟前两家彻底分道扬镳​

4.1 子智能体可以嵌套，默认三层​

子智能体可以 spawn 自己的子智能体，深度上限可配，默认为主对话之下 3 层。到达上限时 Agent 工具会被撤走。用 CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH 控制。

对比一下 Kimi CLI 那一行硬编码：

if self._runtime.role != "root":
    return ToolError(message="Subagents cannot launch other subagents.", ...)

Kimi 是布尔判断，只有 root 能派；Claude Code 是深度计数器，到 3 才停。

而且失效方式也不一样：Kimi 是「调了返回错误」，Claude Code 是**「到了深度就把 Agent 工具从工具列表里撤掉」**——模型压根看不到这个工具，不会浪费一次调用去撞墙。后者对模型更友好，但实现上要动态改工具列表，跟 Manus 的「Mask, Don't Remove」 是有张力的。

还有一个 Kimi 没有的控制粒度：

tools: Agent(worker, researcher), Read, Bash

Agent(type1, type2) 可以限定这个子智能体只能派哪几个工种。 不是「能不能派」的开关，是「能派谁」的白名单。有了这个，就能画出受控的层级图——比如 lead 只能派 researcher，researcher 只能派 fetcher，天然形成流水线。

4.2 兄弟之间可以发消息​

启动上下文里那条「兄弟 Agent 名册（for SendMessage）」意味着：Claude Code 的子智能体之间是可以直接通信的。

这是本专题里独一份。回顾前面：

  • Manus 官方原话："Sub-agents never talk to each other."
  • Anthropic 研究系统的博客里：子 Agent 互相不知道对方存在
  • Kimi CLI：代码层面没有任何子 Agent 间通信机制

有意思的是，Anthropic 自己的研究系统博客说子 Agent 互不知晓，但 Claude Code 产品里给了 SendMessage。 这不矛盾——研究任务是「一堆独立的只读检索」，隔离是收益；写代码任务是「一堆有依赖的写操作」，隔离反而会让两个子智能体改同一个文件打起来。

任务形态决定架构，同一家公司在不同产品里给出不同答案，这本身就是最好的证据。 这条线在 08 里是主线。

4.3 fork 模式：反着来的那个​

普通子智能体拿全新上下文，fork 子智能体继承整个对话历史和 system prompt。

这是「上下文隔离」的反面：有些任务恰恰需要知道前面发生的一切，重新交代一遍成本比继承还高。提供 fork 这个逃生舱，说明纯隔离模型在实践中不够用。

五、五维打分​

对照 01 的五个维度：

维度Claude Code 的答案
D1 隔离单位独立上下文窗口；可选 isolation: worktree 升级到独立 git 工作树
D2 通信拓扑星型 + 可选横向 SendMessage，本专题唯一支持兄弟通信的
D3 结果回收只有最终结果回主对话；中间输出不上浮
D4 递归深度默认 3 层，可配；到达上限撤走 Agent 工具；可用 Agent(...) 限定可派工种
D5 生命周期支持 background、memory 跨会话持久记忆、fork 继承历史

一句话总结：配置项最丰富、约束最松的一家。它不替你选架构，而是把星型、树形、带通信的图都做成了可配置项，代价是你得自己想清楚要哪个。

六、三家横着比​

ManusKimi CLIClaude Code
隔离单位一台 VM一个 context.jsonl上下文窗口 / git worktree
递归未公开（推测单层）硬禁止默认 3 层
兄弟通信明确禁止无机制SendMessage
子 Agent 有角色无，都是完整实例三个内建工种用户自定义 + 三个内建
子 Agent 用 MCP——一刀切禁止按 Agent 配
跨会话记忆未公开实例可 resume工种可有 memory
定义放哪系统内建包内 YAML项目仓库里的 Markdown

能看出一条清晰的谱系：从 Manus（最刚性、最贵、最彻底隔离）到 Kimi CLI（中等刚性、单层、彻底隔离）到 Claude Code（最柔性、可递归、可通信）。

刚性换的是可预测性和成本可控，柔性换的是任务适应面。没有哪一端是「更先进」的——它们服务的任务分布不一样。

七、参考​