全景与对照总表
前置：知道 Agent 大致是怎么回事，看得懂 Python 或 TypeScript。不需要用过下面任何一个产品。
你自己写一个 Agent，跑通了。然后你想让它同时干几件事 —— 一个去查资料，一个去写代码，最后有人把结果合起来。
于是三个问题冒出来，教程里通常一笔带过，但它们恰恰决定了这套东西上线之后是能用还是天天出事：
- 这几个 Agent 各自看到的上下文，是分开的还是共享的？
- 其中一个跑歪了，谁负责发现？
- 它们之间传的是完整对话，还是只传一句结论？
已经把这件事做成产品、并且真的在赚钱的团队，都必须给出自己的答案。这个专题就是去他们的源码里，把答案一条一条读出来。
一、先分清两层
Agent 框架横向对比 那个专题回答的是「我该用 LangGraph 还是 CrewAI」。这个专题回答的是另一个问题：这些产品内部究竟怎么实现的，它们自己用不用那些框架。
实测结论（本专题第 02–06 篇逐一验证）：
| 产品 | Agent 循环实现方式 | 用现成框架？ |
|---|---|---|
| Kimi CLI | 自研 52,049 行 Python | ❌ |
| Manus | 自研（事件流 + 三个外置模块） | ❌ |
| Claude Code | 自研 | ❌ |
| DeerFlow | LangGraph 运行时 + LangChain 1.x 中间件 | ✅ |
| Suna | 包 OpenCode，自己只做运行时 | 部分 |
「大厂都自研」是个流传较广但不准确的说法。 真正的差异不在用不用框架，而在框架之上补了什么——DeerFlow 补了 40+ 个中间件，Suna 补了整套沙箱与成本刹车。
二、为什么值得拆
MAST（UC Berkeley） 实测 7 个开源多智能体框架、1,642 条执行轨迹，失败率 41%–86.7%，且明确结论：
大部分失败源于组织设计，而非单个 Agent 的能力限制。
换更强的模型救不了。而生产产品的源码里，恰好写满了针对这些失效模式的对策——01 那篇 把 14 个失效模式和五个产品的源码对策做了逐条映射。
三、拆解对象与材料硬度
拆源码最怕拿二手解读当一手事实，所以先标清每个对象的材料来源。
| 档位 | 证据强度 | 拆解对象 |
|---|---|---|
| A | 官方源码，可逐行核对 | Kimi CLI ｜ DeerFlow ｜ Suna ｜ OpenHands ｜ Mini-Agent ｜ JoyAgent |
| B | 无源码，有官方工程博客 / 官方文档 | Manus ｜ Claude Code ｜ Devin ｜ Grok Bot |
| C | 模型侧技术报 告 | Kimi K2 / K2.5 ｜ MiniMax M2（对应「编排下沉进模型」这条线） |
3.1 A 档：官方源码
| 对象 | 仓库 | Star | 协议 | 关键路径 |
|---|---|---|---|---|
| Kimi CLI | MoonshotAI/kimi-cli | 11,218 | Apache-2.0 | src/kimi_cli/subagents/ |
| 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（523 行） |
| JoyAgent（京东） | jd-opensource/joyagent-jdgenie | 11,872 | — | ⚠️ 停更于 2026-02-12 |
3.2 B 档：官方博客 + 泄露物
| 对象 | 一手材料 | 硬度 |
|---|---|---|
| Manus | 官方博客《Context Engineering for AI Agents》、官方 Wide Research 页 | ✅ 官方 |
x1xhlol/system-prompts-and-models-of-ai-tools（142,905★）里的 tools.json 18.5KB、Modules.txt 12KB、Agent loop.txt | ⚠️ 社区泄露 | |
| Claude Code | 官方子智能体文档、官方多智能体研究系统博客、开源 Agent SDK（7,928★） | ✅ 官方 |
| Devin | Cognition 官方《Don't Build Multi-Agents》 | ✅ 官方 |
| Grok Bot（xAI） | 官方产品文档 14 页、官方 API 文档、xai-org/xai-sdk-python（559★） | ✅ 官方 |
xai-org/grok-prompts（4,382★）里 @grok 机器人的完整提示词 | ⚠️ 官方开源但停更于 2025-11-17 |
泄露物只能证明「有哪些零件」，不能证明「为什么这么设计」——后者一律以官方博客为准。需绕过鉴权才能获取的内容不在引用范围内。
四、九个参数的横向对照
| Kimi CLI | Manus | Claude Code | DeerFlow | Suna | |
|---|---|---|---|---|---|
| 一个子 Agent = | 一个 context.jsonl | 一台虚拟机 | 上下文窗口 / git worktree | LangGraph 分支 | 一个沙箱容器 |
| 子 Agent 间通信 | 无 | 官方明确禁止 | SendMessage | 无 | 无 |
| 能否再派子 Agent | 硬禁止（三重） | 未公开 | 默认 3 层 | 默认禁止 | 继承 OpenCode |
| 结果回传 | 仅末条消息 <200 字强制重写 | 主 Agent 综合 | 仅最终结果 | 确定性截断 2000 字 （明确不用 LLM） | 由 OpenCode 负责 |
| 并发上限 | 未硬编码 | 上百 | 未公开 | 3 | 沙箱数决定 |
| 步数上限 | 1000 / 轮 | 官方均值 ~50 | maxTurns 可配 | 150 / 60 | 由 OpenCode 决定 |
| 子 Agent 用 MCP | 一刀切禁止 | —— | 按 Agent 粒度配 | 有路由中间件 | 继承 |
| 实例可复活 | resume=agent_id | 未公开 | memory 跨会话 | checkpointer 续跑 | 温 fork |
| 成本刹车 | 步数 + 1h 超时 | KV-cache 优化 | —— | 单轮 100–200 万 token 预算 | 重复回答 3 次即中止 |
五个产品在「隔离粒度 × 并发能力」上的位置：
三条横着看才显现的规律：
① 隔离越重，并发越高。 虚拟机（Manus）上百路，同进程（DeerFlow）只有 3 路。轻量隔离共享进程资源，天花板由进程决定；重隔离往外扩就是加机器。
② 禁止递归是多数派。 四家有 明确表态的里三家禁止，唯一放开的 Claude Code 也带深度计数器和到顶撤工具。
③ 结果回收有两个相反的病。 Kimi 治「太短」（LLM 重写），DeerFlow 治「太长」（确定性截断）。理想实现两头都做——这是本专题最直接可复用的一条。
④ 有一家反着走。 Grok Bot 让所有 Bot 共用同一台云计算机——隔离单位从「一个 Agent 一台机器」退到「一个用户一台机器」。换回来的是零成本交接和本专题最强的持久化，代价是官方文档自己写明的那句：Do not use separate Bots as a security boundary.
五、篇目
| # | 内容 | 主要材料 |
|---|---|---|
| 01 | MAST 14 个失效模式 × 五家产品对策映射，附三拓扑分类法、四协议对比 | 学术综述 |
| 02 | Kimi CLI：唯一完整开源的一线子 Agent 调度实现 | 官方 Python 源码 |
| 03 | Manus：长任务的六条上下文工程原则 + 一子 Agent 一虚拟机 | 官方博客 + 泄露物 |
| 04 | Claude Code：唯一支持递归与横向通信的一家，15× token 代价数据 | 官方文档 + 博客 |
| 05 | DeerFlow：40+ 中间件构成的生产防线，三层限流 | 官方 Python 源码 |
| 06 | Suna：沙箱、冷启动、出网管控，含两条线上事故复盘 | 官方 TS 源码 |
| 07 | 对照组：523 行的最小基线 / shell 语法树安全分析 / Java 阶段式 | 官方源码 |
| 08 | 结论：Cognition 反对 vs Anthropic 支持，判据与决策树 | 官方博客 |
| 09 | Grok：共享一台计算机的 Bot 团队；以及编排下沉成一个模型 ID 之后失去了什么 | 官方文档 + 官方 SDK |
按需求选起点：
| 你的目的 | 路径 |
|---|---|
| 快速建立全局认知 | 01 → 08 |
| 动手实现一套子 Agent 委派 | 02 → 01 对策表 |
| 做长任务 / 通用 Agent 产品 | 03 → 06 |
| 已有 Agent 要上生产 | 05 → 06 |
| 判断该不该上多 Agent | 08 |
| 想直接买现成的多 Agent 编排 | 09 第七节——先看清楚代价 |