Multi-Agent 产品源码分析
一句话：上一个专题拆的是「你拿来写 Agent 的库」，这个专题拆的是「已经在几百万人手里跑着的 Agent 产品，它内部到底怎么调度一堆子 Agent」。
数据快照 2026-08-19。所有 star 数、版本号、目录结构都是当天
gh api+git clone实测的。贴出来的每一段代码都来自当天拉下来的仓库，不是凭印象默写。
一、为什么单开这个专题
Agent 框架横向对比 那个专题回答的是「LangGraph 和 CrewAI 我该用哪个」。
但你去看 Manus、Kimi、Devin 这些真正跑在生产上的通用 Agent，会发现一个尴尬的事实：它们大部分没用那些框架。 自己写调度、自己管上下文、自己做沙箱。
所以真正值钱的问题变成了：
- 它们为什么不用现成框架？自己写多出来的那部分是什么？
- 一个主 Agent 带一堆子 Agent，子 Agent 之间到底能不能说话？
- 子 Agent 跑完了，结果怎么回到父 Agent 手里？回多少？
- 子 Agent 能不能再开子 Agent？
这四个问题，五家产品给了五个不同的答案。而且答案都在源码里写着，不用猜。
二、拆解对象：按「资料硬度」分三档
拆源码这件事，最怕的是拿二手解读当一手事实。所以先把每个对象的资料硬度标清楚。
A 档：官方真源码
| 对象 | 仓库 | Star | 协议 | 关键路径 |
|---|---|---|---|---|
| Kimi CLI | MoonshotAI/kimi-cli | 11,218 | Apache-2.0 | src/kimi_cli/subagents/ |
| Kimi Code | MoonshotAI/kimi-code | 6,903 | MIT | packages/agent-core-v2/ |
| DeerFlow（字节） | bytedance/deer-flow | 80,280 | — | backend/packages/harness/deerflow/ |
| Suna / Kortix | kortix-ai/suna | 20,115 | — | apps/kortix-sandbox-agent-server/ |
| OpenHands | OpenHands/software-agent-sdk | 1,007 | — | 主仓 84,444★ 已是 TS 应用层，内核在这个仓库 |
| Mini-Agent（MiniMax） | MiniMax-AI/Mini-Agent | 2,972 | — | mini_agent/agent.py |
B 档：泄露物 + 官方博客
| 对象 | 一手材料 | 硬度说明 |
|---|---|---|
| Manus | x1xhlol/system-prompts-and-models-of-ai-tools（142,905★）里的 Manus Agent Tools & Prompt/：Agent loop.txt 2.1KB、Modules.txt 12KB、Prompt.txt 10KB、tools.json 18.5KB | 泄露物，非官方发布 |
| 官方博客 Context Engineering for AI Agents、官方 Wide Research 页 | 官方一手 | |
| Claude Code | 官方 How we built our multi-agent research system、开源的 Claude Agent SDK（7,928★） | 官方一手 |
Yuyz0112/claude-code-reverse、memaxo/claude_code_re 对 26 万行 cli.js 的反混淆 | 社区逆向 | |
| Devin | 泄露的 Devin AI/Prompt.txt（34.7KB）、Cognition 官方 Don't Build Multi-Agents | 混合 |
关于泄露物的立场：本专题会引用这些公开流传的 prompt 和工具定义做技术分析，但会逐处标注「来源为社区泄露仓库，非官方发布」。凡是能用官方博客佐证的结论，优先引官方。不引用任何需要绕过鉴权才能拿到的内容。
三、核心结论预告：同样叫「子 Agent」，隔离边界差了三个量级
这是拆完五家之后最值得记住的一张表。它们都在做「一个主 Agent 派一堆子 Agent 干活」，但**「一个子 Agent」这个词指的东西完全不一样**：
| 一个子 Agent = | 子 Agent 之间 | 能否再开子 Agent | 结果怎么回收 | |
|---|---|---|---|---|
| Manus Wide Research | 一台独立云虚拟机 | 完全不通信 | 官方未公开 | 主 agent 收集汇总 |
| Anthropic Research | 一个独立上下文窗口 | 互相不知道对方存在 | 否 | lead agent 综合 |
| Kimi CLI | 一个独立 context 文件 + 独立工具白名单 | 不通信，但可被 resume 复活 | 代码里硬禁止 | 只回传最后一条消息 |
| Kimi Agent Swarm（K2.6） | 一个 spawn 时定死的记忆上下文 | 走「共享操作空间」 | 官方称支持 | 协调器按 skill profile 路由 |
| Devin / Cognition | —— 不拆，坚持单线程 | —— | —— | 连续上下文 + 压缩 |
注意最后一行。Cognition 是唯一公开反对多 Agent 的，而他们的产品同样跑在生产上。这不是谁对谁错的问题，是任务形态决定架构——详见 08 单 Agent 还是多 Agent。
四、篇目
| # | 标题 | 主要材料 |
|---|---|---|
| 01 | 拆解方法与五个对照维度 | 方法论，先读这篇 |
| 02 | Kimi CLI 源码逐行拆解 | 官方 Python 源码，本专题代码密度最高的一篇 |
| 03 | Manus：从泄露物还原架构 | tools.json + 官方上下文工程博客 |
| 04 | Claude Code 与 Anthropic 多智能体研究系统 | 官方博客 + Agent SDK + 社区逆向 |
| 05 | DeerFlow：字节把 LangGraph 用成了什么样 | 官方 Python 源码 |
| 06 | Suna：最接近 Manus 的开源实现 | 官方 TS 源码 |
| 07 | 对照组：OpenHands / JoyAgent / Mini-Agent | 三个不同取向的参照系 |
| 08 | 单 Agent 还是多 Agent：四家生产结论对撞 | 全专题结论 |