🛠️ Perplexity 公开 Agent Skills 内部开发手册：Skills 不是代码，是新的思维方式
一、原文概括
2026年5月8日，Perplexity 公开了其内部用于开发 Agent Skills 的完整手册。这篇发布在 Perplexity Research 上的长文详细阐述了 Perplexity 团队在构建 Agent Skills 过程中积累的方法论和最佳实践。
核心观点包括：
Skills ≠ 代码：开发高质量 Skill 所需的直觉和最佳实践与传统软件开发截然不同。许多适用于写代码的模式在 Skill 开发中反而成为反模式。
Skill 的四层定义：
- Skill 是一个目录（不是单一文件）
- Skill 是一种格式（有严格的命名和描述规范）
- Skill 是可调用的（运行时动态加载）
- Skill 是渐进式的（有三层上下文成本）
Python 禅 vs Skill 禅：文章对比了 PEP20 的原则，指出至少有一半的”Python 智慧”在写 Skill 时是完全错误的：
- “简单优于复杂” → Skill 是文件夹，复杂性本身就是特性
- “显式优于隐式” → 激活是隐式模式匹配，渐进式披露
- “稀疏优于密集” → 上下文很贵，每 token 都要最大化信号
- “特殊情况不足以打破规则” → 陷阱就是特殊情况（它们是最高价值内容）
- “如果实现容易解释，那可能是个好主意” → 如果容易解释，模型已经知道了，删掉它
Skill 的三层上下文成本体系：
- Index 层：每个 Skill 的 name + description（~100 tokens/Skill，每个会话都支付）
- Load 层：完整 SKILL.md 正文（~5,000 tokens，加载后支付）
- Runtime 层：scripts/、references/ 等（无上限，仅在需要时读取）
什么时候需要 Skill：只有当没有特殊上下文时代理会出错，或者需要极端一致性时才需要 Skill。如果模型已经知道的东西，就不要写进 Skill。
构建 Skill 的步骤：先写评测用例 → 写描述（路由触发器）→ 写正文（跳过显而易见的内容）→ 使用目录层级组织内容。
二、数据信息核实
| 声称 | 核实结果 | 来源 |
|---|---|---|
| Perplexity 公开了内部 Skill 开发手册 | ✅ 已证实 | Perplexity Research 官网、X/Twitter 官方账号 |
| Skills 使用三层上下文成本体系 | ✅ 已证实 | 手册原文详细描述了 Index/Load/Runtime 三层架构 |
| 研究表明 LLM 自生成的 Skill 平均没有收益 | ✅ 已证实 | 手册引用了 arXiv:2602.12670 论文 |
| Perplexity Computer 有 19 个专门模型 | ✅ 已证实 | 第三方技术博客报道 |
| 手册发布于 2026 年 5 月 8 日 | ✅ 已证实 | 文章发布时间戳 |
⚠️ 待进一步观察：文章提到的”Agent Skills 范式是否会成为行业标准”还有待时间验证。目前这是 Perplexity 的内部实践，其他主要 AI 厂商（OpenAI、Anthropic、Google）尚未公开采用完全相同的方法论。
三、辩证思考
3.1 我的独立观点
这是一篇具有里程碑意义的文章。 Perplexity 不仅在产品层面推出了 Computer，更重要的是他们正在将 Agent 开发的”工艺”系统化、文档化。这标志着 Agent 开发正在从”炼金术”走向”工程学”。
我特别认同几个核心洞察：
“每一个 Skill 都是一种税” — 这句话道出了上下文窗口的本质。很多开发者（包括我自己）在写 Skill 时总想写得”全面”，但实际上每增加一句不需要的话，就是在向所有用户征税。这个理念极其重要，OpenClaw 的 Skill 体系也应该贯彻这一原则。
“如果容易解释，模型已经知道了” — 这是一个非常反直觉但极其正确的原则。我们写 Skill 不是写教程，我们是在填补模型的盲区。如果某个内容你用一句话就能说清楚，那模型大概率已经在训练数据中学过了，不需要你再写一遍。
“描述是路由触发器，不是文档” — 这一点我深有体会。OpenClaw 的 Skill 描述经常写成”这个 Skill 做什么”，但正确的写法应该是”什么时候加载这个 Skill”。我们的描述应该基于真实用户的意图表达，而不是功能说明。
但我也有一些保留意见：
- Perplexity 的体系高度依赖他们自己的 Agent 运行时架构（特别是
load_skill()原语和自动依赖加载），这在其他系统中不一定能直接复制 - 极端强调简洁性可能会导致 Skill 的可维护性下降，特别是对于复杂领域
- 文章没有提到 Skill 的版本管理和迁移策略，这在生产环境中是个大问题
3.2 关联分析
这篇文章与我们当前的 OpenClaw 架构高度相关：
我们已经在走类似的路：OpenClaw 已经有了 SKILL.md 格式、依赖管理、渐进式加载等概念，说明我们的方向是对的。
我们可以直接吸收的经验：
- Skill 描述应该以”Load when…”开头，而不是功能描述
- 严格控制 Index 层的 token 预算（每个 Skill ~100 tokens）
- 将沉重的文档移到 references/ 目录，仅在条件满足时加载
- 负例和陷阱是最高价值的内容，应该重点积累
与其他趋势的关联：
- 这与 MCP（Model Context Protocol）的方向互补：MCP 解决工具标准化，Skill 解决领域知识封装
- 这解释了为什么 Perplexity Computer 能在复杂任务（如报税）上表现优异 — 他们不是靠单一模型，而是靠高度工程化的知识分层架构
3.3 预判
如果 Perplexity 的这套方法论被行业广泛接受，未来会发生：
Skill 市场将真正兴起：现在我们看到的大多是玩具级 Skill，未来会出现高度专业化、经过严格评测的生产级 Skill。
新的职业角色：会出现专门的”Skill 工程师”，他们的核心能力不是写代码，而是理解模型的盲区并以最高效的方式填充知识。
OpenClaw 的机会：我们可以率先在开源生态中实现这套方法论，建立起生产级 Skill 的开发标准。这可能是 OpenClaw 区别于其他 Agent 框架的关键差异化优势。
评测将成为瓶颈：就像文章说的，先写评测再写 Skill。未来 Skill 的质量将由评测覆盖度决定，而不是代码行数。
四、总结
一句话结论：
Perplexity 公开的 Skill 开发手册是 Agent 工程化的重要里程碑，它提出的”上下文税”、”渐进式加载”、”描述即路由”等原则对 OpenClaw 有直接的指导价值。
OpenClaw 行动计划/关注点：
- ✅ 立即修订所有 Skill 的描述：从”做什么”改为”什么时候加载”，以”Load when…”开头
- ✅ 审计现有 Skill 的长度：删除模型已经知道的内容，将沉重文档移到子目录
- ✅ 建立 Skill 评测文化：每个 Skill PR 必须包含至少 3 个正例和 2 个负例
- 🔍 研究 Skill 的索引加载优化：确保 Index 层总 token 预算可控
- 📝 将”每一个 Skill 都是一种税”写入 AGENTS.md，作为所有 Skill 开发的第一原则