Perplexity内部工程文档揭示的5个Agent Skills设计反直觉原则,第3个最容易被忽略

大家好，我是苍一，一个干了13年的后端开发，正在探索AI编程，从产品到开发的全生命周期最佳实践，如果您感兴趣，欢迎关注👇，看我如何自我革命。

技能文档不是写给模型看的说明书

Perplexity最近公开了一篇内部工程文档，详细阐述了Agent Skills库的设计思路、迭代方法和维护策略。结论几乎条条反直觉，但仔细推敲后又觉得理所当然。

文档开篇借用了《Python之禅》的哲学，但这些原则在编写技能时并不成立。Perplexity的工程团队直接指出：如果一段描述很容易写出来，说明模型早就掌握了这些知识，写它只是在浪费上下文空间。

大多数开发者的本能是把技能写成操作手册。罗列命令、详述步骤、标注注意事项。问题在于这些内容模型本身就会，写了没有增量价值，反而稀释掉真正重要的信息，挤占有限的上下文窗口。

意图优于指令：用目标描述替代步骤清单

用一个代码合并的场景来对比。传统写法列出具体git命令序列：先log找提交，再checkout主分支，建新分支，cherry-pick。Perplexity推荐的做法是用自然语言描述意图：把指定提交移到一个干净的分支上，冲突时保留原始意图，实在合不进去就说明原因。

后者看起来更模糊，但模型实际表现反而更好。过于具体的指令序列会在出错时让模型陷入僵局。而意图式描述把决策权交还给模型，让它根据实际情况灵活调整路径。

上下文的三层成本结构

1️⃣ 索引层：每次对话都在付的固定成本

每个技能的名称和描述，无论用户问了什么，都占用上下文空间。Perplexity给每个技能的预算约100个token。乘以技能数量、用户规模和每日对话次数，累积开销非常可观。

2️⃣ 正文层：压缩前的核心负载

技能主体内容理想情况下控制在5000 token以内。一次对话通常同时加载三到五个技能，成本叠加后相当可观。正文里的冗余描述不仅浪费自身空间，还会压缩其他技能的可用余地。

3️⃣ 运行层：按需加载的附属资源

脚本文件、参考文档、输出模板等，只有在模型真正需要时才被读取。这一层原则上没有上限，因为都是按需加载。

描述是路由触发器，不是功能说明

技能的描述字段承担路由触发的功能。模型根据这段文字决定是否加载该技能。Perplexity的格式要求：以”当某情况发生时加载”开头，控制在50词以内，用用户实际会说的话来写。

功能式描述：”监控代码合并请求的状态，支持查看进度和审查结果。”触发式描述：”当用户想确保某个合并请求顺利落地、或者担心流水线挂掉时加载。”

前者描述技能能力，后者描述用户行为。模型在路由时匹配的是用户输入中的关键词及其密度，覆盖的表述方式越多，技能被正确触发的概率越高。

经验和品味是模型学不到的

Perplexity的设计负责人为设计类技能撰写了详细的字体规范，包括使用哪些字体、避免哪些字体，以及每种字体带来的视觉感受。这个”感受”是审美判断，不是知识条目。

模型可以准确描述Helvetica字体的历史和参数，但无法判断这个字体在特定场景下是否显得廉价。技能的最大价值不在于教模型做它已经会的事，而在于把人类大脑中那些模糊但准确的判断，转化为模型可用的上下文。

反面案例比正面规则更有效

在技能维护方面，Perplexity提出了明确的迭代原则：只增不改，主要往反面案例区域追加内容。每次模型出错就追加一条反面案例，不要修改描述，不要新增规则。

反面案例直接标记已知的死路，在有限上下文中传递的信息密度比正面规则更高。

此外还有一个容易被忽略的副作用：新增技能可能导致已有技能表现下降。索引层的描述在争夺模型注意力，两个描述相近的技能会产生干扰。因此每次新增技能后都需要回归测试。

最后回到根本判断标准：如果模型在没有这个技能的情况下也能做对，那这个技能就不需要存在。