Perplexity：每一个 Skill 都是一项税

原文作者：Perplexity Research 

原文标题：Designing, Refining, and Maintaining Agent Skills at Perplexity 

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

01 每一个 Skill 都要交上下文税

你写了个 Skill 放进 Agent。

你觉得是在帮它长本事。

但实际上，你刚刚向每一个用户、每一次会话，加了一笔长期都要付的税。

这个结论来自 Perplexity 团队。

他们的 Computer 系统在生产环境里维护着大量 Skill——从通用工具，到金融、法律、健康这些垂直领域能力，每个 Skill 都需要经过评测、真实查询和失败案例反复打磨。

02 三层税：索引、加载、运行时

为什么说 Skill 是税？

答案藏在它的加载机制里。

一次 Skill 加载拆成了三层。

每一层，都是一道税。

第一层，索引。

Agent 会话开始时，系统会把所有 Skill 的 name 和 description 放进上下文。

一个 Skill 约 100 个 token。

几十上百个 Skill 一叠加，每个用户、每个会话还什么都没干，就已经先付了几千甚至上万 token。

这有点像人头税——不管用不用，先交了。

而且上下文是一张很贵的工作台。

你放上去的每样东西，都在挤占别的东西的位置。

description 写太宽，模型容易误触发。

写太窄，模型又可能错过调用。

每多一个 Skill，就多一个路由分叉。

索引层贵的不仅仅是 token，还有模型注意力和路由准确度。

第二层，加载。

模型判断某个 Skill 用得上，就会把整个 body 拉进上下文。

理想情况下，body 不超过 5000 个 token。

这时候 Skill 正式进入 Agent 的工作记忆。

接下来做计划、执行、判断、修正，都会受它影响。

人类看文档，可以扫过去、跳过去。

模型不行。

只要内容进了上下文，它就会把每一个字当信号来处理。

一个 Skill 写太长了、写太泛了、写得像说明书——它不是在旁边安静待着，它会污染整个任务空间。

模型可能带着错误的重点往下走，挤掉真正有用的信息，也让其他 Skill 更难被正确调用。

第三层，运行时。

长篇参考文档、模板、脚本、特殊案例——这些可能有用，但每次都直接加载太贵了。

所以更适合放在附件里，等模型真正需要读取时再付成本。

三层合在一起——索引、body、附件——越早进上下文，税率越高。

索引最贵，所有会话都要看。

body 次之，加载后会跟着任务走一段时间，直到上下文压缩或任务边界出现。

附件最便宜，用到才读。

03 模型需要路径，不需要资料山

这也解释了为什么给模型更多资料，不一定会让它更强。

Perplexity 的税务 Skill，早期把 1945 个税法章节全塞进一个文件，结果比不加载还差。

后来重构成三层嵌套——先定位大的领域，再进入更细的主题——还配了快速参考指南，帮模型更快定位。

效果反过来：

模型做税务任务的表现，超过了只用通用工具。

模型需要的不是一座资料山。它需要的是一条在正确时刻找到正确资料的路径。

04 什么样的 Skill 值得交税

三层税讲完了。

既然是税，下一个问题就是：

什么样的 Skill 值得交这笔钱？

本质上，这是上下文经济学——你写的每一行字，都在向所有用户、所有会话收取成本。

值不值？全看这一行字能不能帮模型做一个它自己做不好的判断。

四种情况值得写。

第一，模型缺了这段上下文就会稳定做错，如公司内部流程、产品专用规范、业务特有标准。

第二，需要跨任务保持高度一致，如品牌语气、输出格式、审核红线。

第三，包含组织自己的判断和品味。

Perplexity 的设计负责人 Henry Modisett 写过几个设计相关 Skill，里面会指定用什么字体、避免什么字体，以及这些选择带来的感受。

审美和偏好，模型可以有通用能力，但不一定有你的标准。

第四，模型反复踩坑的地方。

Perplexity 管这叫 gotchas——提醒模型这里有坑、这个场景别这么做、这个条件下换一种处理方式。

这些失败边界，往往是整个 Skill 里最有价值的内容。

到了这一步，Perplexity 给出了最核心的建议。

你写 Skill 的每一行字，都得先过这关：

“如果没有这条指令，Agent 会犯错吗？”

通不过，删掉。

不管写得多好。

Pascal 在 1657 年说过：

我之所以把这封信写得更长，只是因为没有时间把它写得更短。

写一个短的 Skill，远远难过写一个长的。

05 什么内容不该写成 Skill

那反过来，什么不值得写成 Skill？

模型本来就会的东西。

Git 命令、通用写作技巧——这可能是好文档，但往往是烂 Skill。

模型在训练数据里大概率已经见过很多遍了，再写一遍就是噪音。

一句系统提示词就能稳定解决的事，也不需要 Skill。

变化比维护还快的东西，也不适合写进 Skill。

比如频繁变动的 MCP 端点。

Skill 一过期，就会从知识变成误导。

Agent 带着旧地图走新地形，根源就是上下文漂移。

三个问题帮你判断：

这是模型稳定缺失的能力吗？

长期有效吗？

值得每次加载都付成本吗？

前面讲的这些规则——索引按人头收税、加载不能有废话、只写模型不知道的、不写它本来就会的——你发现没有，每一条都在跟你写代码的直觉对着干。

06 Python 之禅在 Skill 里要反过来读

Perplexity 发现，Python 之禅那几句金科玉律，到了 Skill 这里，全翻了过来。

一共五条。

第一条，简单胜过复杂。

写代码的时候，逻辑越平越好，一个文件能搞定，就别建目录。

但 Skill 正好相反——复杂度本身就是功能。

因为不同内容税率不一样。

你把所有东西平铺在一个文件里，模型就不知道什么重要、什么按需看。

前面那个税务例子——1,945 个 section 平铺在一个结构里，比不加载还差——就是在说这件事。

结构就是功能。

第二条，显式胜过隐式。

代码里，一切调用都得写清楚，不写就不会执行。

但 Skill 的激活，靠的是隐式模式匹配。

模型自己根据语义判断该不该加载，不是你在代码里写死一个 if。

所以 description 才那么难写——它不是功能说明，是路由触发器。

差一个词，模型可能就误判了。

第三条，稀疏胜过稠密。

Python 这句话的意思，是写代码别挤在一起——多分行、多留白、逻辑拆开，用空间换可读性。跟字数多少没关系。

但在 Skill 里，你没有这个本钱。

索引层 100 个 token 一个 Skill，body 层 5000 个 token 一加载就占住上下文。

多一句废话，就多交一份税。

你必须反过来——把每个 token 的信息密度压到极致，一行废话的空间都不能给。

第四条，特殊情况不足以打破规则。

写代码的时候，特殊情况就当特殊情况处理，别把主逻辑搞复杂。

但 Perplexity 说，gotchas——那些“这里有个坑”“这个场景别这么干”——恰好是整个 Skill 里价值最高的内容之一。

模型最容易在这些边界上翻车。

你把这些写清楚，比写一堆正向流程更管用。

第五条，好实现应该容易解释。

如果你写的东西三两句话就能说清楚，模型可能早就知道了。

删掉。

Skill 该写的，是模型没有这段上下文就会犯错的地方。常识不用写。

五条反转，指向同一件事：

代码写给运行时，精确调用的成本很低。

Skill 写给模型，注意力才是最贵的资源。

07 好 Skill 是压缩资产

Perplexity 把 Skill 叫税，不是说少写 Skill。

正好相反——正因为设计成本高，才说明它重要。

一个差的 Skill 是上下文债务，重复常识、污染注意、制造误触发。

一个好的 Skill 是压缩资产——让 Agent 在正确时间看到正确信息，把团队的判断、边界和经验变成可复用的结构。

Agent 系统的竞争，正在从谁接了更多工具，进入下一个阶段：

谁更懂得管理上下文。

这篇文章讲了为什么 Skill 是一种税。

一条 Skill 怎么设计、怎么压缩、怎么评估、怎么维护。