Perplexity 公开内部 Agent Skills 手册

这两天 网上有条推文挺值得看。

有人 转发了 Perplexity 的官方文章，说了一句：“P「erplexity 也开始开源！直接把 agent skill 的构建规则彻底改写了。」”

这句话乍看像发布新闻。

但我看完 Perplexity 那篇**《Designing, Refining, and Maintaining Agent Skills at Perplexity》**后，反而觉得重点不在“开源”两个字。

Perplexity 公开的内容，远远超过一个文档格式，或者“怎么写一个 SKILL.md”的教程。

它公开的是 Agent 产品内部正在形成的一套工程共识：

「未来的 Agent 能力，不会只靠更强的模型或更多工具，还会越来越依赖一套被精心设计、评估、压缩和维护的“上下文资产”。」

我觉得真正值得写的是这里。

先说结论：Skill 更像给模型看的“操作系统说明书”

过去我们很容易把 Skill 理解成插件。

一个文件夹，一个 SKILL.md，里面写几段说明，再塞几个脚本。模型需要的时候读一下，然后执行任务。

这个理解不能说错，但太浅。

Perplexity 在文章开头直接把问题说透了：

❝

写 Skill 不是写普通软件，而是在为模型和它的执行环境构建上下文。

❞

这句很关键。

写普通软件时，核心问题通常是：逻辑是否正确、接口是否稳定、边界是否清楚。

但写 Skill 的核心问题变成了：

• 模型什么时候会想起它？
• 模型读完后会不会误用它？
• 哪些信息值得进入上下文？
• 哪些信息应该后置到 references、scripts、assets？
• 这个 Skill 会不会让其他 Skill 变差？

它已经超出了传统“开发插件”的范围。

更像是在设计一份模型可读的操作系统说明书，而且必须非常克制。

每个字都要花上下文成本。

Perplexity 最狠的一点：把 Skill 当成“税”来管理

Perplexity 文章里最重要的判断，是这句：

「Every Skill is a tax.」

每个 Skill 都是一种税。

这个说法准确，也有点残酷。

在 Agent 系统里，增加 Skill 并不等于线性增加收益。每增加一个 Skill，系统都要付出额外成本：路由成本、上下文成本、误触发成本、维护成本，以及它对其他 Skill 的干扰成本。

Perplexity 把这个成本拆成三层。

第一层是 「Index」。

也就是每个 Skill 的 name 和 description。这个东西最贵，因为它会在每个 session、每个用户、每次启动时提前进入账单。

所以 description 不能当说明书写。

它是路由触发器。

Perplexity 明确说，坏的 description 会描述“这个 Skill 做什么”；好的 description 会描述“用户说什么时，模型应该加载它”。

这就是为什么他们建议 description 用类似 “Load when...” 的句式。

这由产品机制决定，和文案偏好关系不大。

第二层是 「Load」。

当 Skill 被触发后，完整的 SKILL.md 会进入上下文。Perplexity 建议主体大约控制在 5000 tokens 以内。

注意，5000 tokens 不是技术上限。问题在于，一旦加载进来，后续对话都要背着它走。一个线程里加载 3 到 5 个 Skill 很常见，如果每个都写得很水，整个 Agent 的能力会被这些“热情但无用的说明”拖垮。

第三层是 「Runtime」。

也就是 scripts、references、assets、subskills 这些后置资源。这里可以更大，因为它们只有在模型真的读取时才付费。

所以 Skill 设计的本质，不是“把所有知识写进去”。

真正要决定的是：

「哪些知识值得所有人提前付费，哪些知识只应该在需要时再加载。」

这一步，才是 Agent Skills 进入工程化的地方。

为什么 Perplexity 说：用写代码的思维写 Skill 会失败？

Perplexity 文章里有一组很好玩的对照：Zen of Python vs Zen of Skills。

比如 Python 里说：Simple is better than complex。

但 Skill 的世界里，Perplexity 说：

「A Skill is a folder, not a file. Complexity is the feature.」

这句有点反直觉。

我们通常会觉得，给模型看的东西应该越简单越好。Perplexity 并不是鼓励把 Skill 写得复杂。它说的是：复杂性不能硬塞进一个 markdown 文件里，应该被组织成可导航的目录结构。

一个真正有用的 Skill，往往不止一页说明，而是一个 hub-and-spoke 结构：

• SKILL.md：只放核心判断和流程
• scripts/：放模型每次都会重复造轮子的确定性逻辑
• references/：放重型文档，只在条件触发时读取
• assets/：放模板、schema、示例文件
• config.json：放首次配置和用户偏好

很多 Agent workflow 写崩，原因也在这里。

他们会把人类文档直接复制给模型：

第一步运行这个命令，第二步运行那个命令，第三步检查日志，第四步如果失败就……

看起来很完整，实际未必有用。

但对模型来说，这通常是低质量上下文。

因为模型本来就知道怎么运行 git、怎么读文件、怎么调用 API。你再写一遍，只是在浪费它的注意力。

Perplexity 给了一个很典型的例子。

不要写：

git log 找 commit，git checkout main，新建分支，cherry-pick ……

更好的写法是：

“把这个 commit cherry-pick 到干净分支上，解决冲突时保留原意。如果不能干净落地，解释原因。”

后者才更像 Skill。

它提供的是判断和目标，避免把模型已经会的动作重新教一遍。

好 Skill 的价值，不在正例，而在 gotchas 和负例

Perplexity 反复强调一个词：「gotchas」。

也就是那些模型很容易踩坑，但人类专家知道不能这样做的地方。

我特别认同这一点。

很多团队写内部知识库时，喜欢写“正确流程”。可对 Agent 来说，只写正确流程不够。模型常常会做，只是在某些边界条件下做得“看起来合理但其实错”。

真正有价值的 Skill，往往要告诉模型这些边界：

• 这里不要用 A，虽然 A 看起来更常见。
• 这个字段名在数据库、认证服务、计费系统里叫法不同，但其实是同一个东西。
• 这个 health endpoint 只代表 Web server 活着，不代表数据库可用。
• 这个行业报告里的指标不能横向比较，因为口径不同。
• 这个设计项目不要用某个字体，因为它看起来“高级”，但和品牌气质冲突。

这些东西才是专家经验。

这些东西很难靠模型预训练自然学到。

Perplexity 还提到，他们内部有设计相关的 Skills，来自设计负责人 Henry Modisett 的判断：哪些字体能用，哪些不能用，不同字体“感觉”是什么。

它指向一个很重要的趋势：

「Skill 不只是工程知识的容器，也会成为品味、判断、经验和组织偏好的容器。」

这个范围比“工具调用”大得多。

真正困难的，是知道什么时候不该写 Skill

Perplexity 文章里还有一个非常清醒的判断：并非所有东西都值得做成 Skill。

什么时候需要 Skill？

简单说：模型没有这段特殊上下文就会做错，或者你需要它在多次运行里保持一致。

比如：

• 企业内部流程
• 训练数据里没有的持久知识
• 专家判断
• 风格偏好
• 历史失败案例
• 需要稳定复现的工作流

什么时候不需要？

也很明确。

• 模型已经知道的常规命令
• 系统提示里已经有的通用规则
• 变化太快、根本维护不过来的工具信息
• 只是为了“看起来有体系”而写的说明文档

还有个问题很容易被忽略：

「Skill 库越大，不一定越强。」

如果 description 写得不好，模型会误触发；如果 SKILL.md 太啰嗦，会占掉上下文；如果 references 组织混乱，模型会在文件树里迷路；如果内容过期，模型会更自信地犯错。

所以 Perplexity 的文章表面上在教你怎么写 Skill，实际在教你怎么治理 Skill。

Skill 库和代码库很像。

一个小团队早期可以疯狂加功能。但当系统变大，真正重要的问题会变成：加进去之后是否值得维护。

Skill 也是一样。

我觉得这件事真正指向的是：Context Engineering 正在变成独立工种

过去一年，大家都在讲 prompt engineering 后来不重要了。

这个判断只说对了一半。

如果所谓 prompt engineering 只是“帮我写得更好”“你是一个专家”这种咒语，那确实会越来越不重要。

但如果 prompt engineering 升级成 context engineering，它反而会变得更重要。

Perplexity 这篇手册其实就是 context engineering 的生产级样本。

它关心的已经不再是一句 prompt 怎么写，而是：

• 哪些上下文应该全局存在？
• 哪些上下文应该条件加载？
• 哪些知识应该变成脚本？
• 哪些知识应该变成 reference？
• description 如何降低误触发？
• eval 如何证明 Skill 真的有用？
• 执行轨迹如何反哺下一轮 Skill 修改？

问题已经不再是“会不会写提示词”。

这是信息架构、产品设计、软件工程、知识管理和评估体系混在一起的新能力。

我甚至觉得，未来成熟的 Agent 团队里，会出现几类很明确的角色：

• 「Skill Author」：把专家经验写成模型可用的上下文
• 「Skill Reviewer」：像 code review 一样 review Skill
• 「Skill Librarian」：管理 Skill 库的边界、重复、过期和依赖
• 「Eval Designer」：用真实任务和负例证明 Skill 是否真的提升表现
• 「Context Architect」：决定全局上下文、局部上下文和运行时资源怎么分层

这些岗位名字现在可能还不稳定。

但能力本身已经出现了。

为什么 Perplexity 公开这份手册很值得注意？

因为 Perplexity 发布的并不是一个“玩具标准”。

它是在把自己做 Perplexity Computer、金融、法律、健康等 Agent 能力时积累下来的内部方法论拿出来。

它和单纯开源一个格式不一样。

格式很好复制。

真正难复制的是：

• 如何判断一个 Skill 是否值得存在
• 如何写 description 才能正确触发
• 如何用 evals 先定义成功
• 如何从执行轨迹里发现浪费和误判
• 如何把复杂知识拆成可渐进加载的层级
• 如何让 Skill 质量像代码质量一样被 review

所以 有人 说它“改写构建规则”，我觉得并不夸张。

它改写的重点不在文件格式，而在开发者对 Agent 能力的想象：

以前我们以为 Agent 能力来自“模型 + 工具”。

现在看，更准确的公式可能是：

「Agent 能力 = 模型 × 工具 × 上下文结构 × 评估闭环。」

其中上下文结构以前被严重低估了。

对开发者的实际启发：别急着写 Skill，先问五个问题

如果你现在也想给自己的 Agent 写 Skills，我建议先别打开编辑器。

先问五个问题。

「第一，模型没有这个 Skill 会稳定犯错吗？」

如果不会，那它可能不需要 Skill。最多一句 prompt 就够了。

「第二，这个 Skill 的 description 能不能用用户真实说法触发？」

不要写“用于 PR 监控的高级工作流”。

要写用户会怎么说：

“帮我盯一下 CI”“确保这个 PR 能合进去”“babysit this PR”。

「第三，SKILL.md 里的每句话是否都通过了那条测试？」

也就是：没有这句话，Agent 会不会做错？

不会，就删。

「第四，哪些东西应该从 SKILL.md 里拿出去？」

重型 API 文档、错误码、模板、长清单、确定性脚本，都应该尽量放到 references、assets、scripts 里。

不要让每次加载 Skill 都背着一整本说明书。

「第五，你有没有 eval？」

没有 eval 的 Skill，很容易变成玄学。

Perplexity 甚至把 eval 放在 Step 0：先写 eval，再写 description，再写 body。

这个顺序很重要。

Skill 的目标不是“写得像一个 Skill”。它必须在真实任务里比没有 Skill 更好。

最后：Agent 时代的稀缺能力，会从“会调用工具”转向“会组织经验”

很多人现在还在把 Agent 当成自动化工具。

给它浏览器，给它 shell，给它 API，然后期待它自己搞定一切。

但 Perplexity 这篇文章提醒我们：工具只是下限。

真正决定 Agent 上限的，是它能不能在正确的时间拿到正确的经验。

经验并非越多越好。

经验需要被压缩、分层、路由、评估、维护。

这很像从“个人写脚本”走向“团队维护软件工程”。

早期大家拼的是谁能更快做出 demo。

下一阶段拼的会是：谁能把专家经验变成稳定、可复用、低污染的上下文系统。

Perplexity 公开这份内部手册，真正释放的信号是：

「Agent 产品正在从能力展示期，进入上下文工程期。」

而 Skill，就是这场转向里最早被标准化的一块拼图。

它看起来只是一个文件夹。

但如果你认真读完 Perplexity 的手册，会发现它背后其实是一套新的开发纪律：

少写常识，多写判断；少堆文档，多做分层；少相信感觉，多跑 eval；少追求“全”，多追求刚好够用。

未来 Agent 开发最反直觉的点，可能就在这里：

「最强的 Skill，往往写得不多，但非常清楚什么不该写。」

「更多 AI 前沿技术与设计灵感，欢迎关注「设计小站」公众号（ID：sjxz00），一起探索科技与设计的融合创新。」

原文：https://research.perplexity.ai/articles/designing-refining-and-maintaining-agent-skills-at-perplexity