最近 Indigo Talk 请到了 UBC Trusted and Efficient AI Lab 的李霄霄教授，聊了一场信息密度极高的对话，覆盖了 Agent 的学术定义、单智能体 vs 多智能体的效率对比、AI 的认知瓶颈，以及一些对搭建 Agent 非常实用的设计思路。下面是我从中提炼出来的关键信息。

Agent 这个词，1995 年就被定义好了

2025 年满大街都是 Agent，但大部分其实只是套了个壳的 Workflow。

李霄霄引用了 Peter Norvig 和 Stuart Russell 1995 年经典教科书《Artificial Intelligence: A Modern Approach》里的定义：Agent 是一个能感知环境、根据环境自主决策、以最大化目标的系统。三十年了，这个定义的核心没变过。

Anthropic 给出了一个很清晰的区分方式：Workflow 是大模型和工具在既定路线下交互的系统，路径是写死的；Agent 则具备自主 Planning 能力，不仅能使用工具，甚至能创造工具。

说白了，能不能自己拆任务、自己做计划、做完还能回头反省——这才是 Agent 和 Chatbot 的分界线。Indigo 提到他体感最强的是 Claude 在 Planning 方面的能力，不只理解你说什么，还能抓住你的意图做出计划，遇到问题会退回来修改方案。用他的话说，已经有了「一点元认知能力」。

单个 Agent 挂技能，比一群 Agent 协作更好用？

这是李霄霄团队近期最有意思的一项研究，论文标题就很直白：「When Single-Agent with Skills Replace Multi-Agent Systems and When They Fail」。

结论是：在串行任务中，单 Agent 加适当技能，往往比多 Agent 协作更快更好。

原因和人类组织的问题一模一样。多人协作必然有沟通损耗，如果一个人能力范围内就能搞定，省掉沟通环节反而效率更高。李霄霄用做菜打比方——一个人既会切菜又会炒菜，自己从头做到尾可能比两人流水线更快，因为上下文是连贯的。

多 Agent 还有两个隐性成本：一是 Token 消耗，Agent 之间每次对话都在烧钱；二是错误累积，串联架构里一个 Agent 出错，下游全部跟着翻车。

但这不是说多 Agent 没用。两种场景下它不可替代：

  • 角色必须分离的任务。比如 Anthropic 演示过 16 个 Agent 分工合作完成 C 编译器并重新编译 Linux 内核。写代码的人和审代码的人必须分开——一个 Agent 没法在同一个上下文里既当裁判又当选手，记忆空间无法隔离。
  • 可以并行分片的任务。Indigo 用 Claude Code 时发现，AI 会自己判断是否启动 Sub Agent，把任务切成五片同时处理。关键是它会动态决定什么时候分包、什么时候自己干。

对搭 Agent 的人来说，实操建议很明确：别上来就搞多 Agent 编排，先评估任务是串行还是并行。串行任务用单 Agent 加技能就够了，省钱省事还更稳。

20-30 个 Skill 是一个 Agent 的甜蜜点

李霄霄从认知心理学找到了一个有趣的类比框架。人类有个经典实验叫 Hick's Law：给受试者一排灯，灯亮按对应按钮，灯越多反应越慢、准确率越差。本质是人类工作记忆容量有限，超过阈值整个认知系统就崩溃。

AI 逃不过类似的命运。实验数据显示，给一个 Agent 配备的 Skill 数量到 20-30 个时性能最优，再往上加，性能饱和甚至下降。

上下文窗口就是 AI 的「工作记忆」。Context 太长，AI 也会 Lost in the Middle——中间的信息被遗忘。这跟内存有物理上限是一个道理。

所以搭 Agent 时别贪多。与其给一个 Agent 塞 50 个工具，不如精选 20 个最核心的，剩下的通过任务路由分给专门的 Agent 处理。

AI 不需要照搬人类的组织架构

当前大部分多 Agent 框架的设计思路是模仿人类公司：有个 Manager Agent 分配任务，下面一堆 Worker Agent 执行。李霄霄对此持保留态度。

他提了一个更有想象力的方向：Swarm Learning。鸟群没有 Leader，单只鸟智能很有限，但群体飞行时能形成极其高效的组织。蚂蚁也一样，没有指挥官，靠简单的职能分工和涌现式的协作就能表现出惊人的集体智能。

未来的多 Agent 系统也许不需要中央调度员，而是通过去中心化的协作机制，各 Agent 自发形成高效组织。这个方向目前学术界在探索，工程实践上还没有成熟方案，但值得关注。

Confidence Score：让 AI 输出更安全的设计思路

对搭建面向专业场景 Agent 的人来说，这个设计模式很值得借鉴。

医疗领域的做法是：AI 输出时自动高亮置信度低的关键词，链接到相关文献，强制要求人工核实后才能进入下一步。不是简单提示「AI 可能出错」，而是在产品层面嵌入验证机制。

核心是 Confidence Score。AI 本质是概率模型，每个输出都有置信度。如果某个判断的置信度只有 0.2（满分 1.0），就应该被高亮提醒用户审查。这套逻辑不只适用于医疗，任何需要准确性的 Agent 应用都可以用。

外骨骼隐喻：别让 Agent 把你的脑子练废了

Anthropic 最近发布研究显示，长期用 Claude Code 的开发者编程能力出现了不同程度的退化。Indigo 的比喻很到位：穿上外骨骼举重轻轻松松，但你一块肌肉都没练到，时间长了肌肉必然萎缩。

这对独立开发者尤其重要。用 AI 提效没问题，但核心能力要刻意保持。就像自动驾驶用多了开车技术会退步一样，偶尔得关掉 Copilot 自己写写代码。

90-90 法则：对 Agent 能力保持清醒

最后一个值得记住的提醒。软件工程有个 90-90 法则：90% 的代码花了 90% 的时间完成，但剩下 10% 也需要 90% 的时间。

AI 的发展大概率遵循同样的规律。自动驾驶就是前车之鉴——几年前所有人都觉得 L5 马上就来了，但从 L2 到 L5 的跨越远比想象中困难。

搭 Agent 的时候也是一样：让它完成 80% 的工作不难，但最后那 20% 的边界情况和可靠性问题，可能要花十倍的精力去处理。别被 Demo 里的完美表现骗了，真正的工程化落地永远比演示难一个数量级。