智能体、专家、插件:一次把 Agent 平台的概念对齐

同一句「这个平台有几个智能体」，在三个产品里问出来的答案经常互相打架。不是谁错了，是他们站在不同的层上回答。

我最近在三个平台里问同一个问题：你们这儿有几个智能体？

三个答案都成立。摆在一起就没法比较了。

专家算不算智能体？专家团是一个更聪明的智能体，还是一层组织？插件凭什么叫插件，不叫「工具型智能体」？

名字换了三轮，讨论就变成了各说各话。

问题不在命名，在层。

我们习惯把智能体、专家、插件、专家团摆在同一条横线上比较大小，可它们其实分属三个不同的层：什么东西存在、它承担什么职能、由谁来编排。

层次一错，结论必然拧。所以这一篇不急着对名字，先把三层拆开。

01

先分三层

把三个层摆出来，各自问一句话：

▪实体层：平台里有什么。用户能看见、能点、能配的对象。

▪职能层：它在链路里干什么。负责调度，还是负责执行。

▪调度模式：谁编排，编排逻辑放在哪里。

这三层是正交的。正交的意思是：同一个对象，在三层里各有一个坐标，互不影响。

拿「专家」举例。在实体层，它是一个角色包，一个可安装的分发单元；在职能层，它可能当调度者，也可能当执行者，取决于它站在这条链路的哪个位置；在调度模式这一层，它自己通常不持有编排逻辑，编排在平台组件手里。

图 1｜一个对象，三个坐标

于是那个老问题有了一个奇怪的答案：「专家到底是不是智能体」——在实体层，是；在职能层，取决于它在链路里的位置。

把三层压成一层，就会问出这种没有答案的问题。

02

实体层：四类东西，一条判据

平台里能看见的东西，其实只有四类。

判据只有一条：是否拥有目标解释权。

差别在「谁来决定怎么算」。前者只回答「怎么算」，后者要自己决定「怎么算」。

图 2｜一条判据，切开两类东西

由此得到三个常被搞混的结论。

第一，专家和伙伴是同一个东西。

它们是角色型智能体的封装形态——在智能体之上加了领域方法论、角色边界、可安装的分发包。WorkBuddy 叫专家，豆包工作叫伙伴，架构同构，纯命名差异。

它不是与智能体并列的第四类实体。

第二，专家团不是「更聪明的智能体」。

它是「一组智能体 + 一个调度器」的打包。团长通常不是成员之一，而是平台在会话启动时注入的编排者。

把专家团当成一个能力更强的智能体，是把容器层当成了实体层。

图 3｜谁在实体层，谁在容器层

第三，纯工具插件不是智能体。这条要单独说。

插件是能力，智能体是决策者。把插件叫成「工具型智能体」是常见误用：自主性不在工具那一侧，而在调用工具的那一侧。

插件没有目标、没有决策循环、没有独立上下文，只有入参与返回值。它只被调用，不被委派。

更严格一点说，纯工具插件连「执行者」都不完整——它只覆盖执行者职能里的一个切片，也就是单次工具调用。它没有「这一步怎么做」的选择权，只有「我被怎么调」的接口。

03

职能层：调度者与执行者

职能只有两个。互斥，但不排他于实体。

调度者职能，回答「下一步谁来做」：把目标拆成可分派的任务、选执行者并注入上下文、验收回报后决定继续还是终止、维护全局状态。

执行者职能，回答「这一步怎么做」：在给定任务与上下文内选工具和步骤、产出成果物、回报状态与依据，但不改变链路结构。

判据压缩成一句：

能改写「参与者列表」的是调度者，只能在给定位置内产出的是执行者。

这里有个容易忽略的推论：职能是链路里的位置，不是实体的固有属性。

同一个智能体，在 A 位是调度者，在 B 位就是执行者。所以「这个智能体是不是调度者」本身问错了——要问「它在这条链路里站哪个位置」。

图 4｜同一个智能体，换个位置就换个职能

还有一类东西两个职能都不占：规则。规则不产出成果物、不持有状态、没有执行权，它是输入侧的约束。这点后面还会用到。

04

调度模式：调度逻辑住在哪

按「调度逻辑的宿主」来分，有四种。

关键区分是：「有没有团长」和「团长是不是一个实体」，是两个独立问题。

WorkBuddy 和豆包工作属于第一类。团长是平台对象，用户看不见、改不了，只能以「专家团」「小队」的整体去用。

TRAE 属于第二类。团长是一个真实存在、可被寻址的内置智能体，但它的委派协议——按什么匹配、上下文怎么隔离、结果怎么回传——由平台封装，不用手写路由逻辑。

图 5｜宿主不同，可靠性来源就不同

这两类带来的行为差异很实际：前者的团长是黑盒，链路可观测但不可改；后者的主智能体露出一半，你可以用规则和提示词影响它的判断，但判断本身仍由模型给出，可靠性低于平台硬编码。

规则不在这张表里。

规则是把「何时该调用谁」「改动前先说明范围」这类编排意图，从提示词里剥离成可版本化的配置。它影响模型对调度的判断，但不执行分派。

规则决定「该怎么想」，主智能体决定「下一步谁做」。

这也是很多人找不到「调度能力承载」的原因——它在实体内，不在配置里。

05

回流链路：A → B → A → C

多 Agent 协作的典型形态不是网状，而是串行回流：A 拆解任务派给 B，B 的成果回流到 A，A 处理后再派给 C。

图 6｜串行回流，A 每个回流点都要加工一次

A 在每个回流点做三件事，缺一不可：

▪验收：成果物是否达标

▪转译：把 B 的产出变成 C 需要的 schema、粒度、口径

▪记账：更新任务状态与后续分派依据

回流点不是转发，是加工。

这解释了为什么 A 必须是调度者，而不能是路由器——路由器只搬东西，不判断东西能不能用。

真正的难点在传递：B 的成果怎么到 C 手上。三条路。

第一条，共享会话上下文。

所有参与者读写同一份消息流，B 的产出对 C 天然可见。零集成成本，隐式推理链也保留下来了——「为什么这么写」不会丢。

代价是上下文线性膨胀、注意力被中间过程稀释、并发写会覆盖、不可审计也不可复现。

第二条，外部持久化引用。

成果物落盘到外部存储，上下文只传引用：URI 加摘要、schema、版本。开销恒定、可审计、可回滚、能被非 Agent 消费（人、脚本、下游系统都能读）。

代价是要定义交接契约，有序列化成本，而且推理链不在引用里。

第三条，隔离上下文 + 摘要回传。

子智能体拿一个独立上下文窗口，执行完只把结论回传，中间推理不入主会话。TRAE 的 Subagent 就是这类——官方说法是「中间推理和执行过程不会污染主智能体的对话历史」。

它省事、开销恒定、信息不混杂，但代价最锋利：过程不可审。A 只拿到结论，拿不到论证，回流点第一件事「验收」就失去了抓手。

图 7｜三条路，三种代价

所以默认解是混合：控制面走共享上下文（目标、约束、验收标准、任务状态），数据面走引用传递（大成果物、二进制、结构化数据集）。

如果平台已经强制隔离上下文，那摘要里必须补足验收所需的证据，否则整条链路退化成「信则灵」。

四种反模式，都是同一个错误的不同变体：大成果物直接进下一个人的窗口、只给文件路径不给验收标准、回流点不做验收、只回摘要不附证据。

06

三个平台对齐

把上面的坐标逐个填进去，三家的差异立刻收敛。

WorkBuddy。角色型智能体是「专家」，团队单元是「专家团」，团长由平台内置，成员不直连。工具走插件和连接器，是 MCP 层的纯工具。调度属于运行时组件编排。

豆包工作。结构完全同构，只是把「专家」叫「伙伴」、把「专家团」叫「小队」。

新版 TRAE。这家最值得单独讲，因为它有两个模式，能力不一样。

IDE 模式面向单项目的深度编码与精细调试：有终端、调试、插件入口、VS Code 扩展、多文件分屏。在这一模式下，智能体是一等公民——输入框里 @ 就能选、能创建、能管理、能分享导入。内置的主智能体是「Agent」，它按 subagent 的 description 字段匹配，自动把任务委派给对应的子智能体，子智能体在自己的上下文窗口里跑完，把结论回传。

Agent 模式面向从想法拆解到交付的全局推进：多项目并行、多任务并行、定时任务、SSH 远程、云端接管，产物统一归档。在这个模式下，没有可选的智能体入口——你面对的是一条任务，任务本身就是执行实例。

这不是能力缺失，是编排对象不同。IDE 模式编排角色（这件事该由谁来做），Agent 模式编排任务（哪几件事同时做）。

图 8｜一个编排角色，一个编排任务

混着讲就会得出矛盾结论：一边说「Agent 模式没有智能体」，一边说「官方说可调度多个 Agent」。

两者说的不是同一层编排——用户能感知到的「多智能体」只在任务编排侧，代码层面的智能体互调只在角色编排侧。

至于插件，在两个模式里都是能力层，与智能体分属两类实体：插件用 / 调用，智能体用 @ 调用，两套入口对应两种东西。

智能体可以分享、可以一键导入，插件可以上架市场，分发形态趋同，但实体不合并。判据不在「怎么装进来」，而在「装进来之后是否持有目标与决策循环」。

07

对照总表

· · ·

回到最开始那个问题。三个平台给的答案都对，只是它们各自站在不同的层上回答。

而无论调度者是谁，串行回流链路的成败，都取决于在共享会话、外部引用、隔离回传之间做出显式取舍——共享可审但会膨胀，引用可控但要契约，隔离省事却让过程不可复核。

想清楚这几层，比追下一个模型版本重要得多。

如果这篇帮你把概念对上了，欢迎转给正在选平台的同事。