Perplexity 案例

Perplexity Research 在 2026 年 5 月 1 日发布了 Designing, refining, and maintaining agent skills at Perplexity。这篇文章不是 Agent Skills 规范，而是 Perplexity 在 agent 产品 Computer 中维护 Skills 的生产经验。

放在本章里，它的价值不是提供另一套规范，而是展示：当一个团队真的维护一组生产 Skills 时，问题会从“怎么写一份 SKILL.md”变成“怎么管理路由、上下文成本、评估和长期维护”。

核心判断

Perplexity 的核心判断很直接：写 Skill 不是写传统软件，而是在给模型和执行环境构建上下文。

这会反转很多工程直觉：

  • 对代码来说，显式通常更好；对 Skill 来说，触发依赖隐式匹配，所以 description 比长说明更关键。
  • 对文档来说，解释完整通常更好；对 Skill 来说，模型已经知道的内容应该删掉。
  • 对普通系统来说，特殊情况是例外；对 Skill 来说，gotchas 往往是最高价值内容。
  • 对上下文来说，每个 token 都有成本；短不是风格选择，而是运行时约束。

这条判断和本章 编写指南 的官方原则一致：Skill 应该补模型缺少的任务上下文，而不是重复模型已经会的通用知识。

三层成本模型

Perplexity Computer 把 Skill 成本分成三层。

三层上下文成本 (Three-tier context cost) 宽度对应付费频率；单次成本随宽度收窄而上升 Index 层 所有可见 skill 的 name + description ~100 tok / skill 每个 session、每个用户、永远在付 Load 层 完整 SKILL.md body ~5,000 tok 每次 load_skill 付一次，留到 compaction Runtime 层 scripts / references / assets / sub-skills 无上限 仅当显式打开文件时 Computer 报告的稳态：每个 thread 加载 3–5 个 skill

层级加载什么Perplexity 的经验值设计含义
Index每个非隐藏 Skill 的 name + description约 100 tokens / Skill每个 session 都付费，必须极短且高信号
Load完整 SKILL.md body理想上不超过约 5,000 tokens一旦加载，会占用到下一次 compaction 边界
Runtimescripts/、references/、assets/、子 Skill、格式文件无固定上限真正按需读取，适合放重型材料

这些数字是 Perplexity Computer 的实现经验，不是规范限制。但它们说明了一个通用事实：description 的成本最贵，因为它常驻；SKILL.md 次之，因为加载后会持续占用上下文；只有 runtime 层最接近按需成本。

所以 Perplexity 对 Skill 的要求很苛刻：每句话都要回答一个问题，少了它 agent 会不会做错？如果不会，就删掉。

什么时候值得写 Skill

Perplexity 的判断标准可以压缩成三类。

适合写成 Skill：

  • agent 在没有专门上下文时会失败，或跨运行表现不稳定。
  • 需要的是稳定但训练数据里缺失的知识，例如企业内部流程、产品后训练截止后出现的信息、团队品味或判断标准。
  • 任务行为无法用一句 prompt 稳定改变。

不适合写成 Skill：

  • 模型本来就会，例如常见 git 命令序列。
  • 属于多数请求都需要的全局规则，这类内容应该进 system prompt 或 harness policy。
  • 内容变化快于维护节奏。过期 Skill 会让 agent 自信地走错路。

这也是为什么 Perplexity 强调“Every Skill is a tax”：Skill 不是越多越好。每新增一个 Skill，都会增加常驻 index 成本，也可能影响已有 Skill 的路由边界。

构建流程

Perplexity 给出的构建顺序是 eval-first。

  1. 先写 eval
    用真实生产 query、已知失败案例、相邻但不该触发的负样本组成测试集。负样本尤其重要，因为 Skill 最大的失败模式之一是误触发。

  2. 先调 description
    description 是路由触发器，不是内部文档。Perplexity 建议用接近真实用户语言的 Load when ... 句式，而不是写“这个 Skill 做什么”。例如 PR monitoring 的触发语要覆盖用户真实说法，如“watch CI”“make sure this lands”。

  3. 再写 body
    body 不应该列出模型已经会的命令序列。更好的写法是告诉模型目标、边界、失败处理和 gotchas。条件性或重型内容下沉到资源文件。

  4. 使用目录层次
    scripts/ 放 deterministic 逻辑，references/ 放条件性重文档，assets/ 放模板和 schema，必要时用配置文件保存首次运行设置。

  5. 在 branch 上迭代并一起提交 eval
    description 中一个小词变化都可能改变路由。Perplexity 建议把完整 eval set 和 Skill 改动作为同一个 changeset 评审。

税法 Skill 的教训

文章中最值得保留的案例是美国税法 Skill。

Perplexity 曾把 Internal Revenue Code 的 1,945 个 section 放进一个单层目录，结果表现比不加载 Skill 更差。原因不是模型没有知识，而是入口结构太差：让模型从上千条材料里直接定位，路由问题本身就变得不可控。

后来的改法是把内容整理成多层结构：先进入大类，再进入 topic cluster，最后进入具体条款，并补充快速参考和搜索工具。

这个案例说明：当参考资料很密集时，Skill 的核心工作不是“把资料都放进去”，而是设计模型能走得动的索引结构。

1,945 节税法 skill：扁平 vs 层级 Perplexity Computer 重构前后对比 扁平 — 单一目录 1,945 所有 IRC 条款，全在一个文件夹 无内部索引、无搜索工具 结果 表现比"完全不加载这个 skill"还差 层级 — 三级结构 L1 — 约 20 个大类 (categories) L2 — 每类约 15 个 topic cluster L3 — 具体条款内容 结果 每深一层，路由可靠性明显提升

维护方式

Perplexity 维护 Skill 的核心机制是 gotchas 和 eval。

Gotchas 飞轮 生产观察追加到 SKILL.md，SKILL.md 又喂给下一轮生产 生产观察 (production observations) ① 生产中 agent 出错 ↓ 追加一条 gotcha ② 加载了错误的 skill ↓ 收紧 description， 加一条负 eval ③ 该加载的 skill 未加载 ↓ 补关键词， 加一条正 eval ④ System prompt 变更 ↓ 审查重复 / 抢夺 SKILL.md 只增不改的累积器 喂给下一轮 稳态：SKILL.md 缓慢增长，累积的是负向知识

常见维护动作：

  • agent 在生产中踩坑：追加 gotcha。
  • 错误 Skill 被加载：收紧 description，补负样本。
  • 应该加载但没加载：补触发词，补正样本。
  • system prompt 改了：检查是否和已有 Skill 重复或争抢路由。

Perplexity 还强调 eval 不能只看单个 Skill。新增一个 Skill 可能让旧 Skill 误触发或不再触发，这种“远程副作用”只有 catalog-wide eval 才能发现。

他们提到的 eval 类型包括：

  • Skill 加载的 precision / recall，以及 forbidden-load 负样本。
  • progressive loading：body 要求读取附件时，agent 是否真的读取。
  • 端到端任务完成：完整 agent loop 后用 rubric 评分。
  • 多模型测试：不同模型家族对同一 Skill 的触发和遵循可能不同。

可以迁移的三条经验

  1. Skill catalog 是路由系统，不只是知识库。
    description 的边界会影响整个目录，不只是当前 Skill。

  2. 最有价值的内容通常是负向知识。
    gotchas、反例、边界条件比通用教程更值得占用上下文。

  3. eval 要先于 Skill，也要覆盖目录级回归。
    只验证“这个 Skill 能不能工作”还不够，还要验证“它会不会破坏别的 Skill”。

参考

这页有帮助吗？
在 GitHub 编辑