别再只说"子Agent"了，Agent 之间的关系远比你想的复杂

上午跟人聊多 Agent 系统，对方说："让一个 Agent 拆解任务，分给几个子 Agent 去执行就行了。"

我总觉得哪里不对，问了几个问题：

"被调用的就一定是子 Agent 吗？" 

"子 Agent 一定是临时的吗？不能让它记住上次交互的内容吗？" 

"一个 Agent 同时被三个 Agent 调用，它有三个爸爸 Agent 吗？" 

对方也愣住了。

后来越聊越觉得，"子 Agent"这个概念被大多数人用得太随意了，好像谁调用谁，谁就是谁的子 Agent。但仔细一追问，就会发现很多问题。

于是我认真研究了一下。这一研究，发现 Agent 之间的关系，远不是一个"主-子"就能概括的。

今天把研究的结论分享出来。

· · ·

一、先搞清楚：到底什么才算"子 Agent"

大多数人对子 Agent 的理解是这样的：A 调用了 B，B 就是 A 的子 Agent。 听起来好像没毛病，但经不起追问。

你用 Python 调了一个天气查询的接口，天气接口是你的"子"吗？显然不是，它有自己独立的存在意义，谁都能调它，它不会因为你不用了就消失。

那什么才是真正的"子 Agent"？我梳理下来，至少要同时满足三个条件：

第一，目标从属。 子 Agent 的目标不是自己定的，而是从父 Agent 的目标中拆解、派生出来的。父 Agent 说"你去查一下竞品价格"，子 Agent 才有了"查竞品价格"这个目标。没有父 Agent 的指令，它没有理由独立去做这件事。

第二，控制权不对称。 父 Agent 能分配任务、能叫停、能决定接不接受结果。反过来不行，子 Agent 不能给父 Agent 派活。

第三，生命周期依附。 子 Agent 的存在是因为父 Agent 需要它。父 Agent 不需要了，它的使命就结束了。至于是不是真的被销毁，那是持久化层面的事——可以存着下次再用——但它存在的"原因"依附于父 Agent。

缺了任何一条，就不该叫"子 Agent"。

那个被你调用的翻译服务？它有自己独立的目标（提供翻译能力），控制权不属于你（你只是发了个请求），它的生命周期也不依赖你（你不用了它还在服务别人）。三条一条都不满足：它不是你的"子"，它是一个独立的服务，你只是它的一个调用者而已。

想清楚这个，我突然意识到一个很重要的事：

"被调用"只是一种交互方式，不是一种从属关系。就像你打电话给外卖小哥，外卖小哥不是你的"下属"。

· · ·

二、Agent 之间的关系，是一张图，不是一棵树

当我们只有"父-子"这个概念的时候，多 Agent 系统在脑子里自然就是一棵树：最上面一个总控 Agent，下面分几个子 Agent，子 Agent 下面可能还有孙 Agent。

但真实世界里的 Agent 协作，远不是树能描述的。

你想想这些场景：

甲方和外包：甲方给了目标，外包全权执行，甲方不管过程只要结果。这像父子吗？有点像，但外包有自己的专业判断和执行自由度，不是"指哪打哪"。

同事讨论：两个 Agent 地位平等，互相辩论，谁也指挥不了谁，最后协商出一个结论。这压根没有"父"和"子"。

工厂流水线：翻译 Agent 做完交给校对 Agent，校对做完交给排版 Agent。每个 Agent 只看上游产物，不存在谁指挥谁的问题。

GAN 里的生成器和判别器：两个 Agent 目标完全对立，互相博弈。你说谁是谁的子？

如果硬要用"父-子"来描述这些关系，就像用"夫妻关系"来描述所有的人际关系一样，概念太窄了，不匹配。

Agent 之间的关系是一张图（graph），不是一棵树（tree）。"子 Agent"只是图中一种特定的边。

回到开头那个问题：一个 Agent 同时被三个 Agent 调用，它不是有三个爸爸，而是它本来就是图中的一个共享节点，谁都能连过来。硬要用"父子"来描述，才会觉得别扭。

那问题来了：到底有哪些种类的关系？能不能穷举？

· · ·

三、两个核心维度，一张矩阵，推导出所有可能

这是本文最核心的部分。

如果只是拍脑袋列举，"有父子、有协作、有对抗……"，你永远不知道自己列全了没有。我想要的是一种能推导的方法，而不是靠经验去凑。

研究下来，我发现任意两个 Agent 之间的关系，最关键的两个维度是：

维度一：控制对称性。 A 和 B 之间，是一方能指挥另一方（不对称），还是双方地位平等（对称）？

维度二：目标关系。 A 和 B 的目标是什么关系？大致分四种：

目标派生：B 的目标是从 A 的目标分解出来的

目标共享：A 和 B 朝着同一个大目标努力

目标独立：各干各的，互不相干

目标冲突：A 想赢 B，B 想赢 A

把这两个维度交叉，就得到一个 2 × 4 = 8 个格子的矩阵。

但并不是 8 个格子都能填。有两个组合逻辑上就不成立：

❌ 控制对称 + 目标派生。 "派生"意味着有一个源头：B 的目标是从 A 分解来的。但如果两者地位对称，到底目标从谁那里派生？无法回答。这个组合逻辑自相矛盾。

❌ 控制不对称 + 目标冲突。 如果 A 能控制 B，但两者目标对立，会发生什么？要么 A 强行覆盖 B 的目标（变成了"目标派生"），要么 B 反抗脱离控制（变成了"控制对称"的博弈）。这个组合无法稳定存在，会自动退化到其他格子里去。

排除掉这 2 个不可能的组合，剩下 6 个格子。 再在每个格子内部，根据通信方式、生命周期等次要维度做进一步细分，最终一共能推导出 10 种基本关系类型。

不是我碰巧发现了 10 种，是逻辑上只能有这 10 种。

· · ·

四、10 种 Agent 关系，一次看全

下面按矩阵的 6 个有效格子来介绍。每种关系我给一句定义、一个生活类比、一个 Agent 场景。

🔷 格子一：控制不对称 + 目标派生

这是最经典的"上下级"区域，但内部还能根据控制力度的强弱，细分出三种：

① 父子控制型

一句话：指哪打哪，用完就收。

生活类比：军队里的上下级。命令就是命令，不讨论。

Agent 场景：项目经理 Agent 把"写单元测试"任务分配给测试 Agent，测试 Agent 不能拒绝、不能自己改目标，做完即销毁。这是控制最强、耦合最紧的关系。

② 委托型

一句话：只管结果，不管过程。

生活类比：甲方和外包公司。需求给你了，怎么做是你的事，我只看交付。

Agent 场景：规划 Agent 把"订一张下周三北京到上海的机票"委托给旅行 Agent。旅行 Agent 自己决定查哪个平台、比哪个价格，全权处理，最后只把结果交回来。

③ 监督评估型

一句话：我不替你做，但你做完我要审。

生活类比：代码 review。你写代码，我提修改意见，你自己改。我有指导权，但你是执行主体。

Agent 场景：代码审查 Agent 检查编码 Agent 的产出，指出潜在问题，编码 Agent 据此修正。有反馈回路，但执行者保持自主性。

🔷 格子二：控制不对称 + 目标共享

④ 教练指导型

一句话：我教你，但我不替你做决定。

生活类比：健身教练和学员。目标一致（都想让你变强），但教练不替你举铁，只是建议和纠偏。

Agent 场景：一个经验丰富的 Agent 辅导新手 Agent 处理客服问题。目标共享，但能力不对称，教练 Agent 提供建议，不直接接管。

🔷 格子三：控制对称 + 目标共享

这是"平等合作"区域，内部能分出三种，区别在于合作的方式不同：

⑤ 对等协作型

一句话：面对面讨论，谁也指挥不了谁。

生活类比：圆桌会议。每个人都有发言权，通过讨论达成共识。

Agent 场景：辩论系统中，正方 Agent 和反方 Agent 互相交锋，最终由第三方综合出结论。

⑥ 黑板共享型

一句话：不直接对话，各自往公告板上写东西。

生活类比：学术研讨会的海报展示。每个研究者把自己的发现贴出来，别人路过看到觉得有用就参考，不用面对面交流。

Agent 场景：多个分析 Agent 读写同一个共享工作区，各自贡献分析结论。没有直接通信，通过共享状态间接协作。

⑦ 流水线型

一句话：上一道工序做完，自然流到下一道。

生活类比：工厂产线。原材料进去，每个工位做自己那道工序，产品一步步成型。

Agent 场景：原始文本 → 翻译 Agent → 校对 Agent → 排版 Agent。每个 Agent 只看上游产物，不回溯，不协商，按顺序接力。

🔷 格子四：控制不对称 + 目标独立

⑧ 工具服务型

一句话：你调我，但我不属于你。

生活类比：公共图书馆。谁都能来借书，图书馆不"属于"任何一个读者。

Agent 场景：一个翻译 Agent 作为公共服务存在，任何 Agent 都能调用它。它有自己独立的存在意义，不依附于任何调用者。这是最容易被误认为"子 Agent"的类型，只要记住"被调用 ≠ 从属"就好。

🔷 格子五：控制对称 + 目标独立

⑨ 松耦合型

一句话：各过各的日子，偶尔收到对方的消息。

生活类比：你关注的公众号推送了一条消息。你和作者互不认识，你自己决定看不看、做不做反应。

Agent 场景：监控 Agent 发现系统异常后广播一个事件，日志 Agent、告警 Agent、自愈 Agent 各自决定是否响应。它们之间互不知道彼此的存在，只通过事件总线松散连接。

🔷 格子六：控制对称 + 目标冲突

⑩ 竞争对抗型

一句话：我赢了就意味着你输了，但这种对抗本身在创造价值。

生活类比：拳击比赛。两个选手目标对立，但正是这种对抗让比赛有意义。

Agent 场景：GAN 中的生成器和判别器，或者红蓝队安全攻防测试。两个 Agent 你攻我守，正是这种对立推动双方不断进步。

· · ·

五、一个被大多数人忽略的问题：子 Agent 一定是临时的吗？

聊到这里，再回头解决开头的第二个问题：子 Agent 一定是用完就扔的吗？

答案是：不一定。

"子"描述的是关系：谁的目标从谁那里来、谁能指挥谁。

"持久"描述的是生命周期：做完任务之后还在不在，有没有记忆。

这两个维度是正交的。你完全可以有一个持久的子 Agent，它只被父 Agent 调用，但它有自己的记忆存储，每次被调起时加载之前的状态。比如一个专门负责客户沟通的子 Agent，它记住了跟每个客户的历史对话，下次被调起时能接着聊，不用从头来。

之所以很多人以为"子 Agent = 临时的"，是因为大部分框架的默认实现确实是按需创建、用完销毁，这样最简单、开销最小。但这是实现层面的默认选择，不是概念层面的限制。

· · ·

最后，记住三句话就够了

如果只记三句话：

第一句： "子 Agent"有严格的定义，目标从属、控制不对称、生命周期依附，三者缺一不可。别再把所有"被调用"的 Agent 都叫子 Agent 了。

第二句： Agent 之间的关系是一张图，不是一棵树。两个核心维度（控制对称性 × 目标关系）形成矩阵，排除 2 个不可能的组合后，共 10 种基本关系。

第三句： "子"描述关系，"持久"描述生命周期，两者正交。子 Agent 完全可以有记忆、可以持久化。

下次你再说"子 Agent"的时候，不妨先想想：它真的满足那三个条件吗？还是说，它其实只是一个恰好被你调用了的独立服务？

这个区分看似学术，但它会从根本上影响你设计多 Agent 系统时的架构决策，该销毁的销毁，该持久的持久，该平等协作的别硬塞成上下级。

认清关系，才能设计好关系。

我建了一个AI学习研究群，目前几十来人，都是在真正动手搞AI的人。如果你也在自己跑模型、写代码、做项目，欢迎点赞关注转发一键三连，然后加我微信，备注写清"你在做的AI方向"，聊得来的话我拉你进群。纯围观的和小白就不加了，群里大家都在真搞。