Awesome Study Agent

Appearance

2026-05-04
6199
23.1m

Skills 的认知科学基础 ​

从心理学和认知科学的视角理解 Skills 存在的根本原因：为什么 LLM 需要策略护栏，以及 Skills 如何从根本上改变 Agent 的推理模式 | 预计阅读时间：30 分钟

一、引言 ​

基础模块中我们提到"LLM 存在局限"——同样的任务，不同时间执行可能得到不同结果；同样的工具集合，Agent 可能选择不同的调用顺序。这个现象在工程上被称为"不稳定"，但从认知科学的角度看，它揭示了一个更深层的问题：LLM 缺乏内化的任务执行策略。

人类的专业能力来源于两个核心机制：程序性记忆（procedural memory）和认知架构（cognitive architecture）。一位资深工程师审查代码时，不会每次都从头思考"我应该先看什么再看什么"——TA 已经形成了稳定的策略：先扫安全漏洞，再看逻辑错误，最后检查代码风格。这个策略是内化的、稳定的、可迁移的。

LLM 恰恰缺少这个内化机制。它的每一次推理都是从零开始的概率生成，没有"经验积累"的概念。因此，相同的任务输入，在不同上下文状态、不同温度参数甚至不同 Token 排列下，可能产生截然不同的执行路径。这就是 Skills 要解决的核心问题：为 LLM 提供外化的策略记忆。

本章将从认知科学的视角，系统分析 Skills 存在的理论基础，包括策略漂移的形式化分析、现有范式的局限性、推理护栏的工程实现，以及 Token 经济模型的经济学解释。

二、策略漂移问题 ​

2.1 策略漂移的形式化定义 ​

策略漂移（Policy Drift）是指 LLM 在相同或语义等价的输入下，因缺乏固定策略而产生输出不一致的现象。我们可以从形式化角度定义这一概念。

令 $T$ 为一个目标任务，$I$ 为任务输入，$M$ 为 LLM 模型，$\theta$ 为模型参数，$C$ 为上下文状态（包括系统提示、历史消息、工具选择偏好等）。LLM 在时刻 $t$ 的输出 $O_t$ 可表示为：

$$O_t = M_{\theta}(I, C_t, \tau_t)$$

其中 $\tau_t$ 时刻的温度等随机性参数。策略漂移的度量定义为在不同时刻 $t_1, t_2$ 输出 $O_{t_1}$ 与 $O_{t_2}$ 之间的"策略距离"：

$$D(P_{t_1}, P_{t_2}) = \sum_{i} w_i \cdot d_i(\pi_{t_1}^{(i)}, \pi_{t_2}^{(i)})$$

其中 $\pi_t^{(i)}$ 是第 $i$ 个策略维度（如工具选择顺序、决策分支、错误处理路径），$w_i$ 是维度权重，$d_i$ 是维度距离函数。

当无 Skills 介入时，LLM 的策略由系统提示 + 即时推理共同决定：

  1. 系统提示提供宏观方向，但不约束执行策略
  2. 即时推理依赖 Token 概率分布，对上下文噪声敏感
  3. 随机性参数（如温度）引入不可控的探索

2.2 无 Skills 时的工具选择方差 ​

考虑一个典型的"代码审查"场景，Agent 面临以下工具选择：

python
AVAILABLE_TOOLS = {
    "git_diff":     "获取文件的变更内容",
    "search_code":  "在代码库中搜索模式",
    "run_linter":   "运行代码风格检查",
    "ast_parser":   "解析代码的抽象语法树",
    "read_file":    "读取指定文件内容",
    "list_files":   "列出目录中的文件",
}

在没有 Skill 约束的情况下，LLM 对同一 PR 审查请求的不同执行路径如下表所示：

执行轮次第一步第二步第三步第四步路径评价
第 1 次list_filesgit_diffread_filerun_linter合理：先了解变更范围，再审查细节
第 2 次read_fileread_filegit_diffsearch_code冗余：重复读取文件，未优先使用 diff
第 3 次run_linterast_parsersearch_code—顺序错误：还没看变更就先跑 lint
第 4 次git_diffsearch_coderead_fileast_parser合理但不同：与第 1 次路径不一致

这 4 次执行中，仅有 2 次采用合理策略，且没有一次采用完全相同的工具调用序列。方差来源包括：

  • 上下文稀释：模型在长上下文交互中逐渐丢失对任务目标的聚焦
  • Token 概率波动：不同字词的 Token 化变异导致策略偏好偏移
  • 推理路径分叉：早期决策影响后续选择，一次"绕路"可能引发连锁反应

2.3 有 Skills 时的输出一致性 ​

引入 Skills 后，策略被显式编码为可执行规范。Agent 不再"猜测"执行路径，而是遵循预定义的策略序列。我们比较有无 Skill 时同一个"代码审查"任务在 10 次执行中的策略一致性：

无 Skills 时的策略路径分布：
   路径 A (最优)   ████████░░ 40%
   路径 B (次优)   ██████░░░░ 30%
   路径 C (绕路)   ████░░░░░░ 20%
   路径 D (错误)   ██░░░░░░░░ 10%

有 Skills 时的策略路径分布：
   路径 A (最优)   ████████████████████ 100%
   路径 B (次优)   
   路径 C (绕路)   
   路径 D (错误)

这种对比展示了 Skills 的核心价值：将 LLM 的"自由发挥"转变为"策略遵循"，从根本上消除策略漂移。

2.4 一个具体的策略漂移案例 ​

下面用一个更具体的例子来说明策略漂移的实际影响。

场景：Agent 被要求"审查这个 PR，重点关注安全问题"。

无 Skill 时的表现：

第一次执行时，Agent 调用 git_diff 获取变更列表，识别到用户输入未做转义处理，立刻标记为 XSS 漏洞，然后检查了文件中其他 SQL 查询的拼接方式，最后生成结构良好的审查报告。整个过程 23 个步骤，效果优秀。

第二次执行时，Agent 先调用 list_files 查看目录结构，然后逐一阅读每个文件（即使没有变更），读完后开始 search_code 搜索已知脆弱模式，结果搜索返回了大量无关结果，Agent 花费 5 步来过滤。最终识别到 XSS 漏洞时已用了 41 步，效率下降 78%。

第三次执行时，Agent 直接从 run_linter 开始，得到数百行 lint 警告后试图逐一分析，在分析到第 3 个文件时上下文窗口接近饱和，Agent 被迫放弃安全审查，输出一份以代码风格为主的报告。

有 Skill 时的表现：

无论是第 1 次还是第 100 次执行，Agent 的策略始终是：

  1. git_diff 获取变更文件列表和 diff 内容
  2. 对每个变更文件：按"输入验证 > 认证授权 > 数据存储 > 输出编码"的优先级进行安全检查
  3. 汇总发现，按严重程度分级输出报告

所有执行的步骤数稳定在 18-22 步之间，策略一致性 100%。

策略漂移的代价

策略漂移不仅仅是"每次结果不一样"的问题。在工程实践中，它意味着不可调试、不可复现、不可测试。如果同一个 bug 在 Agent 第 1 次审查时被发现了、第 2 次却被遗漏了，你无法确定问题出在哪里。

三、三种范式的局限 ​

3.1 Few-shot 范式的认知负荷 ​

Few-shot 通过在提示中嵌入示例来引导 LLM 行为，这是当前最常用的引导方式之一。但从认知科学角度，Few-shot 存在根本性局限。

示例即认知负荷。每个示例都占据上下文窗口中的 Token，且 LLM 需要同时在"理解示例"和"执行任务"两个认知层次上工作。认知负荷理论（Cognitive Load Theory）指出，当工作记忆被外来负荷（extraneous load）占据时，核心任务的处理质量会下降。

在 Few-shot 场景中：

同一任务在不同 Few-shot 长度下的性能对比：

3-shot 示例:
    Token 消耗: ~500 tokens
    任务性能: ████████░░ 80%
    稳定性:   ████░░░░░░ 40%

5-shot 示例:
    Token 消耗: ~900 tokens
    任务性能: █████████░ 85%
    稳定性:   █████░░░░░ 50%

10-shot 示例:
    Token 消耗: ~2000 tokens
    任务性能: █████████░ 88%
    稳定性:   ██████░░░░ 55%

可见，增加示例数量并不能线性提升稳定性和性能，因为示例越多，LLM 需要处理的上下文噪声也越多。这是一种边际收益递减的模式。

可复用性为零。Few-shot 示例与任务绑定，无法跨任务复用。每个任务的 Few-shot 都是独立的，不存在"策略积累"的机制。如果需要让 Agent 同时具备代码审查、SQL 优化、日志分析三种能力，需要为每个任务单独准备示例，Token 消耗累加。

3.2 CoT 的非确定性困境 ​

思维链（Chain-of-Thought）通过鼓励 LLM 展示推理过程来提升复杂任务的完成质量。然而，CoT 的"思考"过程本身就是一个概率生成过程。

CoT 的不确定性来源：

不确定性层次表现来源
推理路径同一问题可能走不同的推理路径Token 概率分布
中途分叉推理过程中被非关键细节带偏注意力分散
结论收敛不同路径可能得到不同结论推理质量差异

CoT 的这种特质与工程化的需求存在根本矛盾。工程系统要求可预测、可复现、可测试，而 CoT 天然带有探索性和随机性。

更关键的是，CoT 难以"固化经验"。一位 DevOps 工程师处理线上事故时，TA 的经验会形成固定的排查路径："先看监控指标 -> 再看应用日志 -> 检查数据库连接 -> 分析慢查询"。这个路径是对事故处理经验的总结和固化。CoT 无法直接编码这种经验——它只能通过"推理出正确的路径"来间接实现，每次推理都可能偏离最优路径。

3.3 Tool-use 缺少编排策略 ​

Tool-use 能力使 LLM 能够调用外部工具，但它只解决了"Agent 能做什么"的问题，没有解决"Agent 应该怎么做"的问题。

一个典型的无策略 Tool-use 调用序列：

json
// 用户：分析一下生产环境的异常日志
{
  "tool": "search_logs",
  "params": { "pattern": "error", "time_range": "last_1h" }
}
// LLM 得到大量日志条目
{
  "tool": "read_file",
  "params": { "path": "/var/log/app.log", "lines": 500 }
}
// LLM 被无关条目淹没
{
  "tool": "search_logs",
  "params": { "pattern": "OOM|OutOfMemory", "time_range": "last_1h" }
}
// LLM 开始发现 OOM 问题...

这个过程缺乏明确的编排策略。Agent 是根据即时推理来选择工具的，而非遵循一个预定义的调查路径。结果可能是：

  • 遗漏关键线索（因为 agent 不知道应该按什么优先级搜索）
  • 做了大量无用调用（因为没有明确的跳过条件）
  • 上下文被无关信息填充（因为没有限制搜索范围）

Skills 的解决方式是将策略显式化：

yaml
# Skill 中定义的策略路径
instructions: |
  生产环境异常分析策略：
  1. 先查系统级指标（CPU/内存/磁盘），定位资源层问题
  2. 再查应用日志，聚焦 ERROR/FATAL 级别
  3. 如果发现 OOM，执行堆转储分析子流程
  4. 如果发现连接超时，执行网络拓扑检查子流程
  5. 汇总所有发现，生成根因分析报告

这个策略一旦定义，Agent 每次都按此路径执行，不会"忘记"步骤，不会"偏离"优先级。

3.4 三种范式 vs Skills 的维度对比 ​

维度Few-shotCoTTool-useSkills
Token 消耗每次加载示例，线性增长推理过程消耗大量 Token调用过程消耗 Token一次性加载，后续增量使用
稳定性低（受示例排列影响）中（推理路径不固定）低（工具选择随机）高（策略预定义）
可复用性差（示例绑定任务）差（推理不可提取）中（工具可复用）高（策略可复用）
可测试性差（难以自动化验证）差（结果难以预测）中（工具输出可测）高（输入输出契约）
可编排性无无弱强（DAG 调度）

Skills 并不是要完全替代这三种范式——实际上 Skills 内部可以嵌入 CoT 指令，也可以引用 Few-shot 示例。Skills 提供了策略层的抽象，将三种范式从"混在一起的无序使用"提升为"在策略框架下的有序组合"。

四、Skills 推理护栏的工程实现 ​

4.1 确定性优先的设计原则 ​

Skills 推理护栏的核心设计原则是确定性优先。这不是说 Agent 的行为 100% 确定——LLM 本质上是概率模型，绝对的确定性是无法实现的。而是在"策略层面"追求确定性：Agent 遵循预定义策略的能力应该是确定的。

这个原则可以形式化为约束优化问题。给定任务 $T$ 和策略 $\pi$，希望 Agent 的输出 $O$ 满足：

$$P(O \models \pi | T, \text{Skill}_\pi) \to 1$$

即：给定 Skill 中定义的策略 $\pi$，Agent 的输出符合该策略的概率趋近于 1。

这与"无 Skill 的 Agent"形成对比。无 Skill 时，Agent 的策略是隐式的、从系统提示 + 训练数据中推断出来的概率分布：

$$P(\pi_{\text{agent}} | T) \sim \text{Softmax}(\text{score}(\pi_{\text{agent}}))$$

策略 $\pi_{\text{agent}}$ 可能在不同的上下文中变化，因为没有显式的约束机制。

4.2 从概率推理到确定性策略的转换 ​

如何将一个概率推理过程转变为确定性策略遵循？Skills 采用三层护栏架构：

推理控制的三层架构：

┌────────────────────────────────────┐
│          第一层：系统提示            │
│  全局行为约束、安全边界、角色定义     │
│  影响范围：所有任务、所有 Agent       │
├────────────────────────────────────┤
│          第二层：SKILL.md            │
│  任务级策略定义、工具编排方式          │
│  影响范围：特定场景的任务              │
├────────────────────────────────────┤
│          第三层：运行时校验            │
│  输出 Schema 验证、策略合规检查       │
│  影响范围：单个执行实例                │
└────────────────────────────────────┘

第一层：系统提示。在系统提示层面定义宏观行为约束。这包括 Agent 的角色定位、基本原则、安全边界。系统提示的约束最为广泛但粒度最粗——它告诉 Agent"你应该怎么做人"，而不是"你应该怎么做代码审查"。

第二层：SKILL.md。这是策略的核心载体。SKILL.md 中定义了具体的执行策略、工具依赖、输出规范。它是在系统提示的基础上，为特定任务定制的策略说明书。

第三层：运行时校验。在执行过程中实时检查 Agent 的行为是否符合 Skill 规范。如果 Agent 调用了未声明的工具，或者输出不符合预定义的 Schema，运行时校验可以触发告警或自动纠正。

4.3 护栏是边界而非束缚 ​

一个重要的问题是：确定性策略是否会牺牲 LLM 的灵活性？答案是不会，前提是正确理解护栏的定位。

护栏是"边界"而非"束缚"。它定义的是"不能做什么"和"应该按什么顺序做"，而不是"每一步必须怎么做"。在策略框架内，LLM 仍然有充分的自由度：

  • 工具参数自由：策略规定"在步骤 2 调用 search_code"，但搜索什么关键词、搜索范围如何，由 LLM 根据实际任务自行决定
  • 分支自由：策略可以定义条件分支，如"如果发现 OOM 则执行子流程 A，否则跳过"
  • 异常处理自由：当预定义策略无法覆盖异常情况时，LLM 可以在策略边界内自主决策
yaml
# 策略边界内的自由
instructions: |
  代码审查策略：
  [约束] 步骤 1：必须调用 git_diff 获取变更内容
  [约束] 步骤 2：必须逐个文件审查，审查顺序按变更大小降序
  [自由] 在每个文件的审查中，你自行判断优先级（安全 > 逻辑 > 性能 > 风格）
  [约束] 步骤 3：必须输出结构化报告（summary + findings + suggestions）
  [自由] 对于不确定的发现，标注为 "需人工复核" 并解释原因

在这个例子中，步骤 1/2/3 是约束（存在最优顺序），"每个文件审查内部"是自由（依赖 LLM 判断）。约束确保整体路径一致，自由保留 LLM 的推理优势。

护栏的类比

可以把护栏看作"导航路线"而不是"轨道"。导航告诉你应该走哪条路，但遇到封路时你可以在导航的框架内自主绕行。轨道则是完全固定死的，没有任何变通空间。Skills 提供的是导航，不是轨道。

五、Token 经济模型 ​

5.1 显式策略 vs 隐式推理的 Token 成本 ​

理解 Skills 的经济价值，需要从 Token 消耗的角度对比"显式策略"和"隐式推理"两种模式。

隐式推理模式（无 Skills）：Agent 每次执行任务时，需要：

  1. 从系统提示中推断任务边界（~200-500 tokens）
  2. 根据上下文判断选择哪些工具（~100-300 tokens/步）
  3. 通过多次"试错"找到合适的执行路径（~3-10 步额外消耗）
  4. 处理因策略漂移导致的上下文膨胀（~500-2000 tokens）

显式策略模式（有 Skills）：Agent 首次加载 Skill 时：

  1. 一次性加载 SKILL.md 的策略定义（~500-1000 tokens）
  2. 按策略步骤顺序执行，减少试错（~0 额外步骤）
  3. 后续复用策略时仅需增量加载（~100-300 tokens）
首次使用的 Token 消耗对比：

隐式推理:   ████████████████████████████████  3500-6000 tokens
显式策略:   ██████████████░░░░░░░░░░░░░░░░  1500-2500 tokens
节省比例:   ~55-60%

重复使用的 Token 消耗对比（第 5 次）：

隐式推理:   ████████████████████████████████  3500-6000 tokens（无变化）
显式策略:   ██████░░░░░░░░░░░░░░░░░░░░░░░░  700-1200 tokens（大幅下降）
节省比例:   ~78-83%

5.2 Skills 的投资回报率 ​

分析 Skills 的 Token ROI，需要考虑以下因素：

投资（首次使用成本）：

  • 编写 SKILL.md 的一次性投入（不计入 Token 成本）
  • 首次加载 SKILL.md 的 Token 消耗

回报（重复使用收益）：

  • 每次执行节省的 Token 数量
  • 每次执行节省的步骤数（间接减少 Token 消耗）
  • 减少的错误重试（避免的额外 Token）
长期 ROI 计算（10 次执行的累积 Token）：

无 Skills:
  每次 4500 tokens × 10 次 = 45,000 tokens

有 Skills:
  第 1 次: 2000 tokens（含 Skill 加载）
  第 2-10 次: 900 tokens/次 × 9 次 = 8100 tokens
  总计: 10,100 tokens

10 次 ROI: (45,000 - 10,100) / 45,000 = 77.6%
100 次 ROI: (450,000 - 10,100 + 900*90) / 450,000 = ... ≈ 85%

随着使用次数的增加，Skills 的边际成本快速趋近于 0，而每次收益保持稳定。这就是 Skills 的规模经济效应。

5.3 渐进式披露的经济学原理 ​

渐进式披露（Progressive Disclosure）是 Skills 的另一个关键机制。它并不是一次性加载所有 Skill 内容，而是根据任务需求逐步加载。

yaml
# 渐进式披露的三级加载
level: 1  # 基础信息 - 总是加载
---
name: code_review
version: 1.2.0
description: "审查 PR 代码变更"
tools:
  - git_diff
  - read_file

---
level: 2  # 策略细节 - 基础加载后按需加载
---
instructions: |
  步骤 1: git_diff 获取变更内容
  步骤 2: 逐一审查变更文件
  步骤 3: 输出结构化报告

---
level: 3  # 高级配置 - 仅当需要时加载
---
advanced:
  custom_rules:
    - "对于 Python 代码，检查类型注解是否完整"
    - "对于 JavaScript 代码，检查 async/await 是否正确使用"

渐进式披露的 Token 节省分析：

假设一个 Skills 系统中有 10 个 Skill，每个 Skill 完整大小为 1200 tokens：

策略总加载 Token有效 Token浪费节省率
全量加载12,0001,200（仅 1 个 Skill 需要）10,8000%
懒加载一次一个1,2001,200090%
渐进式三级450（Level 1）+ 400（Level 2）850092.9%
渐进式+缓存450（首次）+ 100（后续增量）850（首次）/ 550（后续）093-96%

渐进式披露节省 78% Token 的示例计算：

场景：10 个 Skills 系统，每个 Skill 包含 3 个披露级别

全量加载：
  10 Skills × 1200 tokens/Skill = 12,000 tokens

无渐进式的触发加载：
  平均每次激活 1.5 个 Skill
  1.5 × 1200 = 1,800 tokens

渐进式三级披露：
  Level 1（基础信息）：~450 tokens（所有 10 个的概要）
  Level 2（策略细节）：~400 tokens（激活的 1.5 个 Skill）
  Level 3（高级配置）：~300 tokens（非常用，仅少数场景）
  
  总计：450 + 400 + 很少用到 Level 3 = ~850 tokens

节省比例：(1,800 - 850) / 1,800 = 52.7%（vs 无渐进的触发加载）
节省比例：(12,000 - 850) / 12,000 = 92.9%（vs 全量加载）

根据实际使用模式，Level 3 仅在 ~1/3 的场景中被需要：
  实际成本 ≈ 450 + 400 + 0.33 × 300 = 949 tokens

相比"总是全量加载"的基线，节省率 = (12,000 - 949)/12,000 ≈ 92%

即便考虑到偶尔的 Level 3 使用，80% 以上的 Token 节省是保守估计。

渐进式披露的认知科学解释

渐进式披露与人类的"工作记忆"机制不谋而合。人脑的工作记忆容量有限（7±2 个组块），一次接收过量的信息会导致认知超载。LLM 虽然工作记忆容量远大于人类，但 Token 消耗直接影响成本。渐进式披露相当于给 LLM 提供了"刚好够用"的信息，避免认知浪费。

5.4 Token 经济模型的实践启示 ​

Token 经济模型的工程启示：

  1. Skills 的初始投资不可忽略：首次使用需要加载完整策略文件，对于单一任务场景，Skills 的 Token 优势不明显。但只要有重复使用，ROI 会快速提升。

  2. 策略粒度影响 Token 效率：一个 Skill 越专注（范围越窄），策略部分越短，加载效率越高。将一个大 Skill 拆分为多个小 Skill 可以提升渐进式披露的效率。

  3. 描述质量决定隐性成本：一个写得模糊的 Skill 可能导致 LLM 执行时产生额外的推理 Token 消耗。清晰的策略描述本身就是一种"Token 压缩"——用最少的 Token 传递最完整的策略意图。

思考题 ​

检验你的理解

  1. 策略漂移在工程实践中会造成哪些具体危害？如果要对一个 Agent 系统的策略漂移程度进行量化评估，你会设计什么样的指标？

  2. 假设你需要让一个 Agent 完成"用户反馈分类与响应"任务，要求每次执行的一致性达到 95% 以上。如果不使用 Skills，你有哪些替代方案？这些方案在 Token 消耗、稳定性、可维护性三个维度上分别有什么缺陷？

  3. "护栏是边界而非束缚"这一观点在工程实现中如何落地？当一个 Agent 在执行 Skill 策略时遇到了策略无法覆盖的异常情况，应该如何处理？请设计一个异常退出的机制。

  4. 渐进式披露的三级加载策略在大型 Skills 系统中至关重要。有一个场景：Agent 需要同时加载 3 个相互关联的 Skill。如果每个 Skill 有 3 级披露，如何设计加载顺序才能最大程度减少 Token 消耗？请给出你的加载策略。

本章小结 ​

  • ✅ 策略漂移是 LLM 缺乏内化执行策略导致的表现，形式化定义为不同时刻输出的策略距离函数
  • ✅ 无 Skills 时，Agent 的工具选择和执行路径高度不确定，导致不可调试、不可复现、不可测试
  • ✅ Few-shot 存在认知负荷问题和边际收益递减，CoT 的推理路径不固定，Tool-use 缺少编排策略
  • ✅ Skills 在 Token 消耗、稳定性、可复用性三个维度上均优于三种范式的无序混合
  • ✅ 推理护栏采用三层架构（系统提示 -> SKILL.md -> 运行时校验），平衡确定性与灵活性
  • ✅ 渐进式披露机制在 10 个 Skills 场景下可节省约 78% 的 Token 消耗
  • ✅ Skills 的 Token ROI 随使用次数呈规模经济效应，重复使用场景下节省可达 80% 以上

参考资料 ​

最近更新

基于 MIT LICENSE 许可发布

Copyright © 2026-present Awesome Study Agent