---
title: Perplexity 首次公开了内部 Skill 设计指南
author: xiaojianke（进化 AI 实验室）
date: 2026-05-19
source: https://mp.weixin.qq.com/s/gf9QQRId0HYeo92Cp0BPnw
rating: 8.5
confidence: 8.5
review_value: 72.25
review_confidence: true
tags: [agent, Skill, Perplexity, prompt-engineering, evaluation, hub-and-spoke]
abstract: Perplexity 内部 Skill 设计指南首次公开——Skill 是目录/格式/可调用/渐进式四维体系；描述是"Load when..."路由触发器；Gotchas 负面案例积累是最高价值工作；每个 Skill 都是一份"税"。
sha256: 32ed7ff921881448cc7aa22d04b829aa7ba99c2a4f6928bcb9eed8552ee4819a
---
---
# Perplexity 首次公开了内部 Skill 设计指南
> 进化 AI 实验室 | 2026-05-19 | 安徽
帕斯卡的名言："我之所以把这篇写得更长，是因为我没有闲暇时间把它缩短。"——现在成了 Perplexity 开发者的核心准则。
Perplexity 认为，开发高质量 Agent Skill 所需的直觉和实践方法，与构建传统软件完全不同。在 Perplexity 内部，工程师们提交的 Skill 代码经常会被打回重写，因为许多在编写传统代码时非常有用的模式，在创建 Skill 时反而成了错误的范式。
## 什么是 Skill？
当你编写一个 Skill 时，不是在编写普通的软件，而是在为模型及其运行环境构建「语境」（Context）。
在 Perplexity 的体系中，一个 Skill 包含四个维度：
### Skill 是一个目录
Skill 不仅仅是一个单独的 SKILL.md 文件。在很多情况下，一个 Skill 包含多个文件：
```
skill-name/
├── SKILL.md           # 前置元数据和指令
├── scripts/           # Agent 运行的代码（而不是让它现场发明代码）
├── references/        # 厚重的参考文档，根据条件加载
├── assets/            # 模板、架构和数据
└── config.json        # 用户首次运行时的设置
```
这种「枢纽与辐辏」（hub-and-spoke）模式能让 Skill 保持非常聚焦且精炼。
假设一个 Skill 需要涵盖 300 个主题，你可以将其归纳为 20 个领域。让模型先锁定 20 个领域中的一个，再从该领域下的 15 个主题中做选择，难度会大幅降低。
### Skill 是一种格式
Skill 本身就是一种格式。核心的根文件 SKILL.md 必须同时具备名称（name）和描述（description）。
名称要求：
- 必须全部小写
- 不能有空格
- 可以使用连字符
描述部分是「路由触发器」（routing trigger）：描述并不是为了记录 Skill 做了什么的内部文档，它其实是写给模型的指令，告诉模型在什么时候加载这个 Skill。
所以，描述里写的是「Load when...」（当……时加载），而不是「This Skill does...」。
在前置元数据（frontmatter）中，还有两个重要字段：
- `depends:`：允许你创建层级化的 Skill 依赖关系
- `metadata:`：用于评审和评估
### Skill 是可调用的
智能体会在运行时加载 Skill。Computer 中的加载过程：
1. 系统调用 `load_skill(name="...")`
2. 系统将 Skill 目录复制到隔离的执行沙箱中
3. 系统根据 `depends:` 标签，递归地自动加载所有依赖项
4. 系统剥离前置元数据，智能体最终只能看到正文内容和附加文件
### Skill 是渐进式的
在 Computer 中，上下文成本分为三个阶段：
**第一层：索引（每个 Skill ~100 tokens）**
Computer 会为每一个可用的 Skill 构建一个包含名称和描述的索引。模型通过查看这些 Skill 名称和描述，来决定是否要调用 `load_skill()`。进入这个索引的门槛非常高——每一位用户在每一次会话中，都要为这个索引支付成本。
**第二层：正文（理想不超过 5,000 tokens）**
加载后引入完整 SKILL.md 正文。每一句话都要有意义，一旦加载了某个 Skill，后续对话都要一直承担这份成本。很多对话会同时加载 3 到 5 个不同的 Skill，成本会成倍增加。
**第三层：运行时脚本（0 到 20,000 tokens）**
这里是存放无限制的条件分支逻辑的地方。智能体只有在真正需要时才会使用它们，准入门槛最低。
## 你什么时候需要 Skill？
### 需要 Skill 的情况
- **纠正错误或不一致**：当 Agent 在没有特殊语境的情况下会出错，或者需要在多次运行中保持极高的一致性
- **特定的知识或流程**：知识是耐用的，但不在模型的训练数据中（比如企业特定的工作流）
- **审美品味**：比如设计相关的 Skill，Henry Modisett 对网页和 PDF 的字体、感觉有非常独特的品味，这些判断力是模型无法仅从训练数据中学到的
### 不需要 Skill 的情况
- **模型已知的任务**：比如写一连串 Git 命令，这对人类是好文档，但对模型来说是差 Skill
- **系统提示词的重复**：没必要把全局上下文里已有的内容再写一遍
- **变化太快的信息**：如果某些信息的变化速度超过了维护速度，就不该写进 Skill
## 每一个 Skill 都是一份「税」
Perplexity 建议开发者对 Skill 中的每一句话进行测试：
> 如果没有这条指令，Agent 会出错吗？
如果答案是否定的，那这句话就不该存在。因为每一个 Skill 都是一份「税」，每个会话、每个用户都在为此支付 token 成本。
写一个短小的 Skill 是很难的，如果你 5 分钟就写完了一个 Skill 并提交申请，那它多半是不合格的。
早期的研究也表明，如果你想用大模型来自动生成 Skill，效果通常很差。
## 如何构建一个 Skill
### 第 0 步：编写评测（Evals）
先写评测，再写内容。你可以从真实的用户查询、已知的失败案例、或者是容易与邻近领域混淆的情况中寻找素材。
**负面案例（即告诉模型什么时候「不该」加载）往往比正面案例更有力量。**
### 第 1 步：写好描述（Description）
这是 Skill 中最难写的一行。它不是说明文档，而是「触发开关」：
- 必须以「Load when...」（当……时加载）开头
- 目标在 50 个单词以内
- 描述用户的意图，而不是总结工作流程
### 第 2 步：编写正文（Body）
给 AI 写工作流和给同事写文档完全不同：
- **跳过显而易见的事**：不要写具体的命令序列（比如 `git log`、`git checkout`）
- **给出原则而非死板命令**：比如写「将提交樱桃拾取（cherry-pick）到干净的分支上，保留意图并解决冲突」，AI 会完成得更好
- **专注于「坑」（Gotchas）**：这是信号量最高的内容。随着 Agent 不断犯错，这里的负面例子会自然增长
### 第 3 步：利用层级结构
当涉及脚本、参考资料或特定工具时，请充分利用 Skill 的层级结构：
- 对于任何具有条件性或分支逻辑的内容，请将其从主 Skill 文件中拆分出来，放入子文件夹
- 多层级结构也可以用于处理极其复杂的 Skill
### 第 4 步：迭代
在分支上进行多轮迭代。先在没有该 Skill 的主分支上运行，构建核心查询集，并运行大量评测。描述中微小的词语变化可能会对路由产生巨大的影响，请在进入第 5 步之前完成这些工作。
### 第 5 步：发布
正式发布。
## 如何维护一个 Skill
### 「坑」（Gotchas）的飞轮效应
Skill 应该是「只增不减」的。随着时间推移，Gotchas 部分积累的价值最高：
- 智能体在某处失败了：增加一个 Gotcha
- 智能体错误加载了该 Skill：收紧描述并增加负面评测案例
- 智能体在该加载时没加载：增加关键词和正面评测案例
- 系统提示词发生了变化：检查是否存在冲突或重复
在内部测试或生产环境中发现单个失败案例并增加一个注意事项是很简单的。这是一个负面示例，它并没有改变显式的指导，但它能让模型知道：这里有一个已知的坑。随着你从 80/20 进步到 99.9% 甚至 99.99% 的成功率，这个 Gotcha 列表会自然增长。
**你应该把大部分内容追加到 Gotchas 部分，而不是增加更长的指令或修改描述。**
### 评测套件（Eval Suites）
- **加载与文件读取评测**：检查加载 Skill 的准确率和召回率，以及是否有「禁区」检查
- **渐进式加载评测**：检查智能体是否正确读取了附件文件
- **端到端任务评测**：运行完整的智能体循环，并使用 LLM 作为裁判，根据定义良好的标准进行评分
在不同模型上运行这些评测至关重要。Computer 支持多种模型（GPT、Claude Opus、Claude Sonnet）。你需要在不同的模型上运行评测，以确保行为一致。
## 核心要点
1. **先写评测，再写 Skill**：包含负面示例，以及防止相邻领域技能误加载的限制
2. **描述是最难的部分**：以「Load when...」开头的每一句话都在消耗注意力成本
3. **「坑」（Gotchas）是极高价值的内容**：从小处开始，随着智能体犯错而不断丰富
4. **警惕「超距作用」**：添加一个新 Skill 很容易破坏原有的 Skill 表现，即便你没有碰过旧的代码
---
**相关链接**：[Designing, Refining, and Maintaining Agent Skills at Perplexity](https://research.perplexity.ai/articles/designing-refining-and-maintaining-agent-skills-at-perplexity)