Skip to main content

拆解方法与五个对照维度

一句话：读 Agent 源码不要从 main() 开始读，从「谁在调 LLM」和「谁在 spawn 子 Agent」这两个点往外扩。

一、四个入口点定位法​

一个通用 Agent 产品动辄五万行起步（Kimi CLI 实测 src/ 下 52,049 行 Python）。顺着读一定读不完。真正决定架构的只有四个位置，全都能用 grep 直接定位。

入口 1 · 主循环在哪​

找「把消息发给模型、拿回工具调用、执行、再发回去」这个 while。

grep -rn "while True" --include=*.py src/ | head

关键词：run_loop、step、turn、agent_loop、run_soul。

要读出来的东西：一轮里允许几个工具调用（一个还是多个并行）、最大步数在哪截断、截断之后怎么处理。

入口 2 · 工具是怎么注册的​

grep -rn "tools:" --include=*.yaml --include=*.json . | head
grep -rn "register_tool\|add_tool\|toolset" --include=*.py src/ | head

要读出来的东西：工具列表是静态写死的还是运行时动态拼的。这一条直接决定了它能不能吃到 KV-cache——Manus 那篇 会讲为什么动态改工具列表是性能自杀。

入口 3 · 上下文存在哪​

grep -rn "class Context\|history\|checkpoint\|store" --include=*.py src/ | head -20

要读出来的东西：历史是纯内存、落文件、还是进数据库。落盘的话，子 Agent 的历史和主 Agent 的历史是不是同一个文件——这一个问题就能定死它的隔离模型。

入口 4 · 子 Agent 从哪 spawn​

这是本专题最关心的一处。

grep -rn "subagent\|sub_agent\|spawn\|delegate\|Task(" --include=*.py src/ | head -20

要读出来的东西：spawn 出来的是一个协程、一个进程，还是一台虚拟机。以及——spawn 的那段代码里，有没有一行在检查「我自己是不是已经是子 Agent 了」。有，就是单层；没有，就是可递归。

二、五个对照维度​

拆完四个入口点之后，用下面五个维度记结论。这五个维度是本专题每篇文章末尾都会填的同一张表。

D1 · 隔离单位​

「一个子 Agent」这四个字，在不同产品里指的东西差了三个数量级：

隔离粒度代表一个子 Agent 的成本崩了会怎样
一台虚拟机Manus Wide Research秒级启动 + 独立计费只死一台，主流程不受影响
一个进程 / 容器Suna sandbox server百毫秒级进程级隔离，文件系统独立
一个上下文窗口Anthropic Research、Kimi CLI一次 API 调用的开销异常被 catch 成一条错误消息回传
一个函数调用大部分框架的 "agent as tool"几乎为零异常会往上冒，可能炸掉主循环

粒度越粗，隔离越彻底，成本越高。没有免费的隔离。

D2 · 通信拓扑​

子 Agent 之间能不能直接说话，是多智能体系统里分歧最大的一个设计选择：

  • 星型：Manus Wide Research、Anthropic Research、Kimi CLI 都是这个。理由完全一致——防止上下文污染。
  • 共享空间：Kimi K2.6 的 Agent Swarm 走这条路，代价是要处理冲突。
  • 单线程：Cognition 的立场，见 08。

D3 · 结果回收​

子 Agent 跑完了，父 Agent 能看到多少？这一维度上有一个几乎所有产品都会踩的坑：子 Agent 会偷懒，只回一句「我干完了」。

Kimi CLI 的处理办法是在代码里写死一个字数下限，不够就打回去重写——02 里会贴这段。这是个很小但极其务实的工程细节。

D4 · 递归深度​

子 Agent 能不能再开子 Agent？

  • 硬禁止：Kimi CLI 在 AgentTool.__call__ 第一行就 if self._runtime.role != "root" 直接返回错误
  • 允许但收敛：靠 prompt 约束，不靠代码
  • 完全放开：容易指数爆炸，生产上罕见

放开递归听起来更强大，实际上是账单和延迟的双重灾难。目前生产级产品里，绝大多数选择单层。

D5 · 生命周期​

一个子 Agent 是「用完即弃」还是「能存下来下次接着用」？

模式说明代表
一次性跑完销毁，历史丢弃大部分框架
可 resume实例带 ID 存盘，后续可以 resume=agent_id 继续Kimi CLI
后台常驻spawn 后立刻返回控制权，完成时回调通知Kimi CLI、DeerFlow

「可 resume 的子 Agent」是个稀有设计。它意味着子 Agent 不再是无状态函数，而是有身份的长期实体。

三、每篇文章的固定结构​

为了能横着比，02 到 07 都按同一套骨架写：

  1. 这是什么、拿的哪份代码（版本号 + commit 时间，可复现）
  2. 目录地图：五万行里哪二十个文件是关键
  3. 主循环逐行
  4. 子 Agent 编排逐行（本专题重点）
  5. 上下文与状态
  6. 踩过的坑：代码里那些「一看就是被线上问题逼出来的」补丁
  7. 五维打分表

第 6 条是我认为最值钱的部分。框架文档告诉你它设计得多优雅，源码里的补丁告诉你它真实世界里碎在哪。

四、复现说明​

本专题所有代码引用都可以自己拉下来核对：

git clone --depth 1 https://github.com/MoonshotAI/kimi-cli.git
git clone --depth 1 https://github.com/bytedance/deer-flow.git
git clone --depth 1 https://github.com/kortix-ai/suna.git

拉取时间 2026-08-19。Kimi CLI 对应 pyproject.toml 里 version = "1.49.0"，DeerFlow 对应 version = "2.1.0"。这个领域迭代极快，你看到时行号大概率已经飘了，以文件名和函数名定位，别以行号定位。