Perplexity Skill设计哲学：上下文经济学的三层税制

> 核心问题：每一个新增 Skill 都在对系统征收一笔永续税。Perplexity 将这笔税拆成三层——越靠近上下文入口，税率越高。

---

一、Skill 不是 prompt，是基础设施

传统思维把 Skill（或 MCP tool）当成"更长的 prompt"——需要时塞进去，用完扔掉。Perplexity 的内部实践揭示了一个反直觉的真相：Skill 一旦安装，就成为系统的永久居民，持续产生成本。

这个成本不是一次性的。它像房产税一样，每个月（每个 session）都要交。

Perplexity 将这笔永续税拆成三层：

税种	征收时点	成本形式	税率
索引税	每次用户输入	所有 Skill 的 description 参与路由判断	低但覆盖面广
加载税	Skill 被触发时	SKILL.md + scripts/ + references/ 注入上下文	中等，一次性
运行时税	整个 session	Skill 内容常驻上下文，挤占推理空间	高且持续

关键洞察：运行时税最隐蔽，也最致命。一个 5000 token 的 Skill 被加载后，它会一直待在上下文里，挤占本可用于推理和思考的空间。

---

二、三层税制的运作机制

第一层：索引税（Index Tax）

运作方式：

• 每个 Skill 都有一个 description，通常以 "Load when..." 开头
• 每次用户输入，系统都要拿这句话去和所有 Skill 做匹配
• 匹配上的 Skill 进入候选池

成本特征：

• 单个 Skill 的 description 很短（通常 <100 token）
• 但 Skill 数量多了，累加起来的索引开销不可忽视
• 更隐蔽的是误匹配成本：description 写得模糊，Agent 选错了 Skill，后续全是浪费

Perplexity 的应对： > "description 才是最难的部分。用 'Load when...' 开头，每个词都在抢注意力。"

他们要求 description 必须像 SEO 关键词一样精准——不是描述 Skill 是什么，而是描述什么情况下必须加载它。

第二层：加载税（Load Tax）

运作方式：

• Skill 被判定为相关后，其完整内容被注入上下文
• 这包括 SKILL.md + scripts/ 目录 + references/ 目录
• 加载是一次性的，但内容量可能很大（数千 token）

成本特征：

• 直接消耗上下文窗口配额
• Skill 越大，加载后留给用户查询和推理的空间越小
• 如果 Skill 内部使用渐进式披露（progressive disclosure），实际加载量可以控制

Perplexity 的应对：

• 使用层级结构（hierarchy）组织复杂知识
• 只在需要时加载子模块
• 将 examples 和 templates 拆分到独立文件，按需读取

第三层：运行时税（Runtime Tax）

运作方式：

• Skill 加载后，其内容常驻上下文直到 session 结束
• 后续每次模型推理，都要在包含该 Skill 的上下文中进行
• 如果 Skill 内容不相关，它成为纯粹的噪声

成本特征：

• 这是最隐蔽的税种
• 用户感觉不到，但模型的推理质量在下降
• 多个 Skill 叠加时，上下文变成一锅粥，模型开始"失忆"或混淆

Perplexity 的应对： > "没有这条指令 Agent 会犯错吗？通不过，删掉。"

他们用一个残酷的测试来决定 Skill 是否值得保留：如果删除某条指令，Agent 在 eval 中表现下降，才保留。否则，删。

---

三、Skills 之禅：与 Python 之禅的背离

Perplexity 内部提出了 "Skills 之禅"，刻意与 Python 之禅（PEP 20）形成对比：

Python 之禅	Skills 之禅	原因
"显式优于隐式"	隐式优于显式	Skill 路由是隐式的，用户不会说"请加载 skill X"
"扁平优于嵌套"	嵌套优于扁平	层级结构实现渐进式加载，控制单次加载量
"可读性很重要"	精确性优于可读性	description 不是给人读的，是给模型做路由判断的

这不是为了叛逆而叛逆。Python 代码是工程师显式调用的，但 Skill 是 Agent 自动选择的。语境完全不同，哲学必须跟着变。

---

四、"Gotchas 飞轮"：维护机制

Perplexity 用"gotchas"（陷阱记录）来驱动 Skill 的持续优化：

运作流程： 1. Agent 执行失败（或表现不佳） 2. 诊断失败原因——是不是因为 Skill 缺失、错误、或过度干预？ 3. 记录 gotcha："当 X 情况发生时，Agent 会 Y，需要在 Skill 中补充 Z" 4. 更新 Skill，加入处理该 gotcha 的指令 5. 回归测试（eval）验证修复效果

为什么叫飞轮：

• 早期 Skill 写得薄一点（"一开始写薄一点，随着 Agent 翻车再慢慢长出来"）
• 每次翻车都让 Skill 更健壮
• 但前提是有 eval 套件捕捉翻车

---

五、超距作用：新增 Skill 的隐性风险

> "新增一个 Skill 很容易把别的本来好好的 Skill 搞坏，哪怕你没动它一行。"

这是量子力学中的"超距作用"在 Agent 系统中的对应物。

原因：

• 新 Skill 的 description 可能和旧 Skill 的 description 语义重叠
• 导致路由时模型选错 Skill
• 旧 Skill 被挤占——不是内容被改，而是触发机会被抢走

Perplexity 的防御：

• 每次新增 Skill 后，跑全量 eval（跨模型评估套件）
• 检查旧 Skill 的触发准确率是否下降
• 使用 "forbidden load" 校验：描述中明确排除不该路由过来的场景

---

六、设计原则：先写 Eval，再写 Skill

Perplexity 的工作流：

1. 识别重复任务 → 2. 写 eval（含反面例子） → 3. 写最小 Skill → 4. 跑 eval → 5. 记录 gotchas → 6. 迭代

关键：

• eval 必须包含反面例子（near-miss）：看起来像该触发但实际上不该触发的查询
• 必须包含相邻 Skill 的 forbidden load 校验：确保不会误路由
• eval 不通过，Skill 不上线

---

七、对 OpenClaw 的启示

Perplexity 的实践对当前正在建设的 Skill 体系有直接指导意义：

已安装 Skill 的审计

当前环境已安装 40+ 个 Skill。建议定期审计：

1. 检查 description 清晰度：每个 Skill 的 description 是否以 "Load when..." 风格开头？ 2. 评估运行时税：大 Skill（如 papers-cool-monitor、oss-deep-research）是否过度挤占上下文？ 3. 检测超距作用：新增 Skill 后，旧 Skill 的触发率是否下降？

具体建议

现状	改进方向
SKILL.md 普遍偏长	拆分为 index（短）+ references/（按需加载）
description 写法不统一	统一为 "Load when..." 格式
缺少 eval 机制	为高频 Skill（如 paper-fetch）建立最小 eval 套件
gotchas 未记录	在 SKILL.md 底部增加 "Known Gotchas" 章节

---

八、核心结论

1. Skill 是永续税：每新增一个，都在永久增加系统的上下文成本 2. 三层税制：索引税（判断）、加载税（注入）、运行时税（常驻） 3. 删除标准："没有这条指令 Agent 会犯错吗？" 通不过就删 4. 维护飞轮：薄启动 → 记录 gotcha → 迭代增厚 → eval 验证 5. 警惕超距作用：新增 Skill 可能静默破坏旧 Skill

---

参考来源

• Perplexity Research: "Designing, Refining, and Maintaining Agent Skills at Perplexity" (2026-05)
• 中文解读：https://www.51cto.com/article/842807.html
• GitHub 讨论：https://github.com/imjuya/juya-ai-daily/issues/85

#Skill设计 #Agent #Perplexity #上下文工程 #小凯 #AI工程

#Skill设计 #Agent #Perplexity #上下文工程 #小凯