注意力机制是什么?为什么OpenClaw用太多Skill会「分心」?

你有没有想过一个问题：AI 是怎么决定「该看哪里」的？

从「耳背」到「耳聪目明」

想象一个场景：你在嘈杂的咖啡厅里和朋友聊天。周围有人在打电话、咖啡机在轰鸣、背景音乐在循环播放——但你可以忽略所有噪音，只专注于朋友说的每一句话。

这就是注意力——人类大脑最强大的过滤机制之一。

那 AI 呢？

早期的 AI 模型有个巨大的痛点：它不会「挑重点」。无论是翻译一句话、理解一段文本，它会「一视同仁」地看待所有信息。就像一个人竖着耳朵想听清咖啡厅里所有人的所有对话——结果就是什么都听不清楚。

直到 2017 年，Google 的论文《Attention Is All You Need》带来了 Transformer 架构，提出了注意力机制（Attention Mechanism）——从此，AI 学会了「集中注意力」。

⚠️ 先说清楚：「两个注意力」不是一回事

很多人会把「注意力机制」当成一个笼统的概念来聊，但实际上在 AI Agent 的上下文里，它出现在两个完全不同的层级上：

关键点：这两层的数学公式完全一样（缩放点积自注意力），但一个是神经网络内部的「思考方式」，一个是你喂给模型的内容质量——后者才是我们真正能动手优化的地方。

下面先讲清楚底层机制，再说上层应用。

注意力机制到底是个啥？

一句话解释

注意力机制 = 让模型学会「该看哪里」

具体来说，当 AI 处理输入序列中的某个元素时，它会计算这个元素跟序列中所有其他元素的「关联度」，然后根据关联度加权汇总。

核心公式

Attention(Q, K, V) = softmax(Q × K^T / √d) × V

它的运作逻辑非常直观：

• Q（Query）：相当于「我想找什么」
• K（Key）：相当于「我有什么信息」
• V（Value）：相当于「信息本身」
• softmax：把关联度归一化为权重（0~1 之间，总和为 1）

模型用 Q 去匹配所有 K，算出关联分数，然后用 softmax 转成权重，最后用权重对 V 做加权求和——注意力就这么完成了。

多头注意力：不止一双眼睛

大模型用的是多头注意力（Multi-Head Attention）——不是只关注一个维度，而是用多组 Q/K/V 从不同角度同时打分。

这意味着：少量冗余 Skill 会被部分注意力头自动过滤。比如一个头在关注「用户问的是不是搜索类问题」，另一个头在关注「有没有匹配的关键词」，第三个头在关注「文本长度是否异常」——多头协作下，少量无关 Skill 对整体决策的影响其实有限。

但极端冗余时，再多头也会集体失效——就像一个团队，如果 80% 的会议内容跟你的工作无关，那不管分了多少个讨论组，整体效率都会被拖垮。

为什么 RNN 做不到？

在 Transformer 之前，主流模型是 RNN（循环神经网络）。它的结构是逐时序串行的：

词1 → 词2 → 词3 → … → 词N

这意味着信息必须沿着时间步逐级传递，梯度随距离衰减——既没法并行训练，又难以建立远距离词语关联。

Transformer 的注意力机制一次性看到所有词，彻底解决了这两个问题——这也是 GPT、Claude 等大模型能训练出来的根本原因。

回到现实：OpenClaw 的 Skill 系统

聊完注意力机制，我们来看看 OpenClaw。

OpenClaw 有一个强大的 Skill 系统——你可以给 AI 安装各种「技能包」。但这里有个关键的区别，很多人的理解是错的：

❌ 常见误区

「OpenClaw 每次发消息，会把所有 Skill 的名字和完整说明全部塞进上下文窗口。」

这不是 OpenClaw 的默认行为。

✅ 实际机制：三级渐进式披露（Progressive Disclosure）

OpenClaw 原生采用分层加载策略，不会一次性灌入全量详情：

第一级（常驻上下文 — 仅元数据名片）
  仅注入：技能名 + 一句话极简描述
  每个 Skill 仅 20~30 Token
  50 个 Skill 常驻约 1,000~1,500 Token
  └─ 例：「web_search」← 搜索网页

第二级（按需加载正文）
  只有当模型判定「要调用这个 Skill」时，
  才把 SKILL.md 的详细说明临时载入上下文

第三级（参考文档延迟加载）
  配套的参考资料、代码示例等，
  只有在调用执行后才读取，不进初始 Prompt

以 50 个 Skill 为例：一级名片只占 1,000~1,500 Token，对现代大模型（128K 上下文）来说几乎可以忽略。只有把全部 SKILL.md 详情写进系统提示词——这才是错误配置，不是原生设计缺陷。

关于 FlashAttention

这里补充一个容易混淆的概念：FlashAttention 是显存访问优化，它加速了稠密注意力的计算过程，但不改变「所有 Token 两两计算」的稠密逻辑。它不等于稀疏注意力，不减少计算量。

稠密注意力 vs 稀疏注意力

不同大模型的注意力实现有差异：

多数商用闭源大模型的默认基座是稠密全局注意力，不是稀疏注意力。所以：

• 基础版模型 → 所有 Skill 名片 Token 都参与全量注意力运算
• 长上下文版本 → 内置滑动窗口优化，局部窗口外的 Token 免于全量计算

这一差异意味着：在基础版模型下，冗余 Skill 的算力损耗更明显。

三种「分心」方式

🎯 决策噪音

假设你给 AI 配置了 100 个 Skill，每个名片 2030 Token，加起来约 2,0003,000 Token。AI 每次推理都要在这几千 Token 上做注意力运算——哪怕最后全都打了低分，算力已经被消耗了。

但关键的分界点在于正确配置 vs 错误配置：

【正确配置】三级加载 + 精简名片 + 分类路由
  → 200~300 个 Skill 也几乎不分心
  → 一级名片总 Token 约 4,000~9,000，大模型轻松处理

【错误配置】全量 SKILL.md 详情塞进系统提示词
  → 哪怕只有 10 个 Skill，每个详情几千 Token
  → 总 Token 轻松超过 50,000+，注意力必然爆炸

📊 行业实证参考：arXiv:2603.29919《SkillReducer》论文实测，绝大多数开源 Skill 的描述文本中，约 60% 是非有效、无动作的冗余内容（论文原文释义：单条 Skill 自身描述 60% 为冗余文本）。当这类冗余内容在整体输入中占比过高时，注意力才会被显著稀释。

📉 上下文被稀释

注意力计算有一个无法回避的特性：所有输入 Token 都必须参与 QK 点积、softmax 打分，再加权 V——即使某个 Token 的最终权重趋近于 0，全序列打分的矩阵运算开销已经产生。

这意味着：只要进了上下文，就得被算一遍。

好钢要用在刀刃上——把 Token 省下来给核心推理，而不是浪费在扫描几十个不相关的 Skill 名片上。

🤔 选择困难

有时候多个 Skill 看起来都能解决同一个问题。AI 可能会陷入「选择困难症」：

• 用 web_search 还是 web_fetch？
• 用 image_generate 还是 video_generate？

多加一个 Skill = 多一个决策分支。分支过多时，注意力被分散，决策质量确实可能下降。

一个类比：瑞士军刀综合征

想象你要开一个罐头：

• 一把锋利的开罐器 → 直接解决问题 ✅
• 一把 50 功能的瑞士军刀 → 先翻找半天，找到那个小小的开罐功能，可能还不好使 ❌

但注意——瑞士军刀不是越多越乱，而是需要分类收纳。

如果你把 50 个功能都摊在桌面上乱糟糟堆在一起，确实会分心。但如果把它们整理好：

• 开罐区 → 开罐器
• 切割区 → 主刀、小刀
• 螺丝区 → 各型号螺丝刀

分类收纳 + 分层加载的情况下，200~300 个 Skill 也不会分心。真正的问题永远是：「全部详情一次性灌入上下文」。

如何优化？给 OpenClaw 做「注意力管理」

1️⃣ 标签路由（技能过滤）

分两种情况讨论：

【原生能力 — 单技能触发关键词】
每个 Skill 可以配置 trigger_phrases，当用户输入匹配时，该 Skill 优先激活。这是框架自带的基础能力。

【插件扩展 — 批量分类路由】
如果需要「按标签全局前置过滤」（如用户问搜索类问题→只载入搜索类技能），需要加装社区插件（如 Skill Quick Index / Auto Router），并非原生自带。

推荐做法：先用原生 trigger_phrases 管好高频技能，量大了再用插件做批量路由。

2️⃣ 精简描述标准化

统一格式，避免冗余背景介绍：

❌ 坏例子：「这个 Skill 可以用来搜索互联网上的各种信息，返回格式为……」
✅ 好例子：「搜索网页。」

对标 SkillReducer 工业级压缩规范：每个 Skill 元数据控制在 30 Token 以内。

3️⃣ 三级加载优化（原生能力）

4️⃣ 定期清理 + 技能拆分

除了常规的「弃用删除」和「重复合并」，还有一条容易被忽略的优化：

技能拆分： 一个大 Skill 拆成多个细分小技能，避免单条描述过长。

比如一个「数据处理」大 Skill，拆成「Excel 读取」「CSV 分析」「图表生成」三个独立 Skill，每个的元数据更短、匹配更精准，反而降低了单次输入的 Token 占用。

横向对比：OpenAI Function Calling 更容易「分心」

了解完 OpenClaw 的三级渐进披露设计后，把它和主流的替代方案做个对比，你会更清楚这个设计的价值：

为什么 Function Calling 更容易分心？ 因为 OpenAI 要求把所有 Function 的完整 JSON Schema（名称、描述、参数结构、枚举值）一次性全部塞入 messages 的 tools 字段，没有分层加载机制。Assistants API 虽然缓存了工具定义，但底层推理时全量工具描述依然参与注意力运算。

市面上也有第三方工具对 Function Calling 做预处理筛选工具子集，但不属于 OpenAI 原生能力。

对比之下，OpenClaw 的三级渐进式披露就是针对这个问题做的设计优化——把「不分心」作为设计目标，而不是事后补救。

总结

注意力是稀缺资源，无论是对于人类，还是对于 AI。

大模型的底层注意力机制是一个非常优雅的数学设计——它让 AI 学会了「动态聚焦」。但再好的聚焦能力，也架不住你往它面前堆满无关信息。

与其说是「注意力不够强」，不如说是「信息过载太严重」。

这也是为什么 System 2 Thinking（慢思考）的核心之一就是先过滤，再思考——先把无关噪音去掉，再把宝贵的注意力留给真正重要的事情。

而 OpenClaw 的三级渐进式披露设计，本质上就是在做这件事：把正确的信息，在正确的时机，以正确的方式交给 AI。

本文由 OpenClaw 研习社出品，带你用好 OpenClaw，用好 AI。 📮 关注我们，获取更多 AI 工具使用技巧。