Skills的容量上限在哪里？2026单Skills组合还是多Agent好？｜UCB最新

在文章开始前，请您先打开Claude code，输入/skill，检查一下您的Claude code有多少个skills？是20个？50个？还是已经突破了100个？自从Anthropic推广Agent Skills以来，我们都爱上了这种“即插即用”的模块化体验。它把臃肿的多智能体编排（MAS）变成了一组优雅的Markdown文件调用，让API账单和延迟同时暴跌了50%以上。

看起来我们已经找到了Agent开发的圣杯。只要给一个Agent挂载上几十甚至上百个Skill，好像它就能包打天下。

但事实并非如此，Anthropic文档鼓励大家创建各种Skills，但没有明确说如果在 .claude/skills/ 里放了200个Skills会发生什么。

就像CPU有缓存未命中一样，LLM的技能检索也存在物理极限。来自UBC、Vector Institute和CIFAR的最新论文模拟了这个场景，并发现了“Agent Skills的扩容墙”。这项研究用数据证明，随着技能库规模的线性增长，Agent的清醒程度会经历一次非线性的“相变”，并据此总结了6条用于开发的黄金法则。

这篇文章将带您深入剖析这项研究，揭示单体智能体的“认知极限”，并为您在2026年构建稳健的Agent系统提供一套基于科学的避坑指南。

范式转移：从“协作”到“编译”

在Agent Skills普及之前，解决复杂问题的主流方法还是多智能体系统（MAS）。但近半年来，行业发生了从MAS到SAS（单智能体）的迁移。

多智能体的隐形成本

过去，为了解决复杂推理任务，业界倾向于使用多智能体系统。比如一个编码任务，可能需要：

• Coder Agent：负责写代码。
• Reviewer Agent：负责审查代码。
• Manager Agent：负责协调两者。

这种架构虽然有效，但存在显著的计算开销：

• 上下文冗余：每个智能体都需要重复读取任务背景。
• 通信延迟：智能体之间的“对话”本质上是多次网络往返。
• Token消耗：自然语言的交互往往啰嗦且昂贵。

能力编译（Capability Compilation）

论文提出了一种名为“编译”的视角。研究者认为，多智能体系统可以被“编译”成一个等价的单体系统。

在这个过程中，原本独立的“智能体角色”被内化为单体智能体的一个技能（Skill）。

一个标准的技能包含三个要素：

惊人的效率提升

研究者在GSM8K（数学）、HumanEval（代码）和HotpotQA（问答）三个基准上进行了对比实验。结果显示，经过编译后的单体智能体在保持准确率（甚至提升 +0.7%）的同时，实现了效率的飞跃：

• Token消耗减少：平均降低53.7%。在HotpotQA任务中，降幅甚至达到58.4%。
• 延迟降低：平均速度提升49.5%。
• API调用次数：从原本的3-4次交互减少为1次调用。

这意味着，在小规模场景下，用Skills取代Multi-Agents是绝对正确的工程选择。

编译的“硬边界”与不可行区域

尽管将多智能体系统（MAS）编译为单体技能（SAS）能带来显著的效率红利，但研究者强调，这种转换并非总是数学上可行的。论文提出了“可编译性”（Compilability）的严格定义：只有当编译后的单体系统能产生与原多智能体系统完全一致的输出分布时，编译才是合法的。

为了判断您的系统是否适合“降维打击”，研究者给出了三个充分且必要的判定条件（Proposition 3.1）。只要违反其中任何一条，就必须保留多智能体架构，否则会导致功能失效：

• 条件一：可序列化通信（Serializable Communication）
• 定义：智能体之间的交互必须能被拓扑排序。这意味着交互流程必须是线性的（如流水线A B C）或循环的（如迭代优化），不能存在真正的并行冲突。
• 原理：单体智能体的思维链（Chain of Thought）本质上是串行的。如果您的业务逻辑依赖于多个智能体在同一时刻独立思考并产生分歧，单体模型无法在同一个上下文中同时模拟“向左走”和“向右走”。
• 条件二：共享历史（Shared History）
• 定义：所有角色的输出只能依赖于全局可见的历史记录，不能有“私有状态”。
• 原理：单智能体（简称SAS）架构下，所有技能共享同一个Context Window。如果原系统要求Agent A拥有Agent B绝对不可见的秘密信息（Private Information），编译会导致信息泄漏或逻辑崩塌。
• 条件三：同构骨干（Homogeneous Backbone）
• 定义：所有原始智能体必须使用相同的底层模型（或能力相当的模型）。
• 原理：如果您的“绘图Agent”必须用Stable Diffusion，而“写作Agent”用Claude，那么就不能把它们简单的合并成一个LLM调用。

典型的不可编译反例：

基于上述边界，研究者明确指出以下三类架构不可使用Skills替代：

1. 辩论与对抗网络（Debate / Adversarial）：例如一个“红方”和一个“蓝方”进行辩论。因为双方持有对立的目标函数，且往往需要独立采样来模拟真实的对抗，强行“左右互搏”会导致模型产生幻觉或逻辑坍塌。
2. 并行采样（Parallel Sampling）：例如“Best-of-N”采样，需要独立的随机性来生成多样化样本，单体流式输出无法模拟这种独立性。
3. 非完全信息博弈（Private Information Games）：例如狼人杀。在这类场景中，每个智能体必须隐藏自己的手牌或身份。单体智能体的全局上下文会破坏游戏的根本假设（即信息不对称）。

如果您在用CC或者Codex做开发，绝大多数企业业务流程（审批、ETL、文档生成）都满足上述条件，因此都可以“降本增效”转为Skills。但如果您在做博弈模拟或隐私计算，请保留多智能体架构。

缩放定律：智能体的“认知过载”

既然单体智能体如此高效，我们是否可以无限制地向其中添加技能？比如将整个公司的500个业务流程都写成Skill丢给Claude？

论文给出的答案是否定的。研究者发现，大语言模型（LLM）在选择技能时，表现出了与人类高度相似的有界理性（Bounded Rationality）。

准确率的“相变”现象

研究者构建了包含5到200个技能的合成库进行压力测试。实验结果揭示了一个非线性的“相变”模式：

溯源：AI的“拟人化”认知缺陷

为什么单纯增加技能数量会让AI变笨？为了解释这一现象，研究者没有生造新的AI术语，而是从人类认知心理学的故纸堆中找出了两个经典理论。他们发现，LLM在面对海量选项时的表现，像极了超负荷运转的人类大脑。

这一发现给所有Agent开发者敲响了警钟：智能体不是无限的容器，它的注意力带宽是有物理边界的。

深度归因：是什么杀死了准确率？

如果仅仅是数量多，模型为什么会选错？研究者进一步剖析了导致崩溃的根本原因。

语义混淆（Semantic Confusability）

实验表明，技能之间的相似度比技能的总数更致命。

研究者设计了一组对照实验：

• 无竞争者：库里的技能各不相同（如“写邮件”和“算加法”）。即使有20个技能，准确率依然是100%。
• 高混淆度：引入语义相似的“竞争者”（Competitor）。例如，基础技能是“计算总和（Calculate Sum）”，竞争者是“计算合计（Compute Total）”。
• 结果：仅仅引入1个竞争者，准确率就下降7-30%；引入2个竞争者，准确率暴跌17-63%。

策略复杂度的“迷思”

一个反直觉的发现是：技能的具体执行指令（Policy）长短，并不影响选择准确率。

研究者测试了三种复杂度的指令：

• 简单：一句话指令（约30 tokens）。
• 中等：分步骤指令（约100 tokens）。
• 复杂：包含异常处理、格式要求的长指令（约300 tokens）。

结果显示，这三条曲线几乎重合。这表明，模型在选择阶段（Level）主要依赖技能的描述符（Descriptor），而不会被加载进来的长篇大论的执行细节（Level）挤占认知带宽。

对开发者的启示：您可以在 SKILL.md 的正文里尽情编写详细的Prompt，这不会降低模型“找到”这个技能的能力；但请务必精简和优化YAML头部的 description。

解决方案：回归人类智慧的“分层路由”

认知科学根基：从组块到排除法

为什么人类能管理成千上万个概念而不崩溃？论文引用了两个关键心理学理论：

• 组块理论（Chunking Theory, Chase & Simon 1973）：国际象棋大师不是记忆32个棋子的位置，而是记忆7个左右的“棋局组块”。
• 按属性排除模型（Elimination-by-Aspects, Tversky 1972）：面对海量选择，人类不是并行比较所有选项，而是分阶段排除，先排除不相关的属性（比如“不买贵的”），再在剩余选项中细选。

两种路由策略：朴素vs抗混淆

论文并没有止步于理论，而是设计了两种具体的工程实现：

1.朴素领域分层（Naive Domain Hierarchy）

• 逻辑：按照功能领域进行物理切割。
• 实现：第一层Router仅选择“数学域”、“写作域”或“编码域”；第二层再加载该域下的具体技能。这类似于我们整理电脑文件夹的方式。

2.抗混淆分层（Confusability-Aware Hierarchy） 

• 痛点：简单的领域分类无法解决语义冲突。比如 search_user 和 find_person 可能被分到同一个文件夹，导致第二步选择依然困难。
• 逻辑：主动将“长得像”的技能关在一起。
• 实现：
• Stage 1（粗粒度路由）：选择一个语义簇（Cluster）。此时，选项之间必须是语义正交的（例如“数据操作” vs “邮件发送”），确保第一步准确率极高。
• Stage 2（细粒度消歧）：在选定的簇内进行“决战”。虽然簇内的技能（如 calculate_sum vs compute_total）高度混淆，但因为选项数量极少（通常<5个），模型可以集中注意力进行精细的语义比对。

突破极限的效果

实验数据证明了这种“分而治之”策略的威力：

给2026年开发者的实战指南

这套指南是基于研究者在实验中发现的“认知缩放定律”和“混淆度效应”总结出来的工程最佳实践，对于 2026 年正在构建复杂 Agent 的开发者来说含金量极高。如果您正在使用的Agent Skills或类似架构开发应用，以下建议至关重要：

1.监控技能库规模 (Monitor Library Size)

2.最小化语义混淆 (Minimize Confusability)

• 核心建议：在向库中添加任何新技能之前，先进行“语义审计”。
• 具体操作：不要堆砌功能重复的技能。如果新技能与现有技能的相似度过高，不要直接添加，而应该合并它们，或者重写描述以确保它们在语义空间中是互斥的。记住，哪怕只有少数几个高度相似的“竞争者”技能，也会导致准确率暴跌。

3.大规模时采用分层架构 (Adopt Hierarchy at Scale)

4.投资于描述符优化 (Invest in Descriptors)

• 核心建议：既然实验证明执行策略（Policy）的长短不影响选择，那么优化的重心应全部放在**描述符（Descriptor）上。
• 具体操作：投入精力去撰写、打磨那些独特、具体、区分度高的技能描述。描述符是模型进行检索的唯一线索，它的质量直接决定了选择的成败。

5.为任务匹配模型 (Match Model to Task)

• 核心建议：不要为了省钱一味使用弱模型，特别是当技能库很大或很混淆时。
• 具体操作：实验表明，更强的模型（如 GPT-4o）具有更强的抗混淆能力。如果您的应用场景天然包含大量相似技能或规模庞大，升级模型本身就能直接带来准确率的收益。

6.考虑替代架构 (Consider Alternative Architectures)

• 核心建议：单体智能体不是万能的。
• 具体操作：对于超大规模的技能集，如果分层路由也难以招架，这表明您可能已经触碰了单体架构的物理极限。此时应考虑回退到带有专用路由器的多智能体架构（Multi-Agent Architectures），因为它们可能比臃肿的单体系统更具扩展性。

写在最后

这篇论文实质上是一篇 《Agent Skills架构扩容指南》。好消息是它证实了 Anthropic 提倡的 "Context efficiency" 和 "On-demand loading"是真实有效的，能大幅降低企业成本。坏消息是它警告我们，模型的“选择注意力”是有上限的（约 50-100 个）。如果你给Claude code配了200个Skills，Claude可能会看着那一堆 YAML description 发呆，然后开始乱选，或者该用的时候不用。随着2025下半年Skills的爆发，现在大家的库里肯定装满了Skills。这项研究说明现在的任务不是写更多Skills，而是重构 (Refactoring)，按照论文提出的分层路由原则，整理那些扁平的文件夹，避免模型陷入“选择困难症”是最佳行动方向。

文章来自于“AI修猫Prompt”，作者 “AI修猫Prompt”。