AI Agent Skill 设计深度解读：Anthropic 与 Perplexity 的工程实践

两篇来自 Anthropic（Claude Code 团队）和 Perplexity（Agent 团队）的技术文章，揭示了 AI Agent「技能」（Skill）系统设计的核心理念与工程实践。本文对两篇文章进行交叉解读，提炼出可落地的设计原则。

什么是 Skill？重新理解 Agent 技能

两篇文章最核心的共识是：Skill 不是一个 Markdown 文件，而是一个目录。

my-skill/
├── SKILL.md          # 前置元数据 + 指令正文
├── scripts/          # 可执行脚本（确定性逻辑）
├── references/       # 重型文档（按需加载）
├── assets/           # 模板、Schema
└── config.json       # 首次运行配置

这个认知纠偏相当重要。许多开发者默认「给 Agent 写提示词」就是写一段 Markdown，但实际上，一个高质量 Skill 是一个微型软件包——它有入口描述、运行时脚本、参考资料和配置管理。

Anthropic 内部的九大 Skill 类别

Anthropic 在编目数百个 Skill 后，归纳出九个聚类：

库/API 参考 — 将私有 API 知识注入模型（如 billing-lib、sandbox-proxy）
产品验证 — 内部质量提升最显著的类型（Playwright 测试、tmux 驱动）
数据获取与分析 — 赋予模型数据自助能力（funnel-query、grafana）
业务流程自动化 — 将重复仪式性工作编码（standup-post、weekly-recap）
代码脚手架/模板 — 消除样板代码编写时间（new-migration、create-app）
代码质量与审查 — 统一团队标准（adversarial-review、code-style）
CI/CD 与部署 — 降低发布认知负荷（babysit-pr、cherry-pick-prod）
运维 Runbook — 从被动灭火转向主动排查（症状 → 诊断 → 报告）
基础设施运维 — 跨系统协调操作（dependency-management）

类别 2（产品验证）被明确标注为「内部影响最大的 Skill 类型」。这说明 Agent 的核心瓶颈不是写代码，而是验证代码是否真正工作。

Skill 设计的四大核心原则

税收测试：只写模型会犯错的内容

Perplexity 提出了一个简洁有力的检验标准——税收测试（Tax Test）：对 Skill 中的每一句话，问自己「如果没有这条指令，Agent 会做错吗？」如果答案是「不会」，就删掉它。

LLM 已经知道怎么用 git、怎么写 Python、怎么调 REST API，不需要再教。你只需要补充那些「模型确实会犯错」的地方。Anthropic 的表述更直接：重述 Claude 的默认行为，只会增加上下文窗口成本，不会带来任何收益。

Gotchas 是 Skill 中价值最高的内容

两篇文章不约而同地强调：Skill 最重要的部分是 Gotchas（陷阱与注意事项）。

典型示例：「注意：服务 A 中字段名为 @request_id，但在服务 B 中同一字段叫 trace_id。」

Gotchas 价值最高的原因有三：它们编码了团队的真实失败经验；是模型无法从代码中推断的信息；信噪比极高，每个 token 都承载关键信息。

Perplexity 进一步提出了 Gotchas 飞轮：Agent 犯错 → 追加 Gotcha → 重跑 Eval → 验证修复 → 合入。Skill 是「追加为主」的——合入后的变更主要应该是添加 Gotchas，而不是重写描述或扩展指令。

Description 是路由触发器，不是文档摘要

Skill 的 description 字段不是给人类看的说明，而是供模型做路由决策的触发条件。

Perplexity 的最佳实践：以「Load when...」开头；不超过 50 个词；描述用户意图而非工作流程；使用用户真实会说的词（比如「babysit」而不是「monitor CI pipeline」）。

措辞上的细微差异会产生显著的路由效果差异，且可能溢出影响其他 Skill 的触发优先级。

渐进式披露：三层上下文成本模型

Perplexity 给出了清晰的三层加载架构：

索引层 — name + description，约 100 tokens/Skill，每次会话加载
加载层 — 完整 SKILL.md 正文，约 5,000 tokens，调用时加载
运行层 — scripts、references、assets，无上限，按需读取

这个设计解决了一个核心矛盾：你希望模型知道尽可能多 Skill 的存在（索引廉价），但又不想为每个 Skill 付出完整的上下文成本（加载昂贵）。

什么时候需要（或不需要）Skill

适合构建 Skill 的场景：

模型在缺乏特定上下文时会犯错（内部 API 约定、字段映射、部署流程）
行为必须高度一致（代码风格、审查标准、安全检查）
知识持久但不在训练数据中（私有库文档、内部工具用法）
涉及品味判断（Perplexity 的设计 Skill 由设计主管编写，编码了字体、色彩、间距等审美偏好）

不需要 Skill 的场景：

模型已经掌握的通用工作流（标准 git 操作、常见编程模式）
与 system prompt 重复的内容
底层内容的变化速度快于你维护 Skill 的频率

一个重要警告： Perplexity 引用了一篇 arXiv 论文的结论——「自生成 Skill 平均不提供任何收益」。Skill 的价值来源于人类的领域知识和失败经验，而不是让 AI 自己总结「该怎么做」。

Skill 的生命周期管理

Eval-First：先写评估，再写 Skill

Perplexity 的流程是严格的 Eval-First：

从真实用户查询、已知失败和「邻域混淆」案例中收集评估用例
负例比正例更重要——不该触发的场景和不该执行的行为
Eval 套件需覆盖：Skill 加载精确度/召回率、渐进加载行为、端到端任务完成（含 LLM Judge 评分）、跨模型一致性

有机分发：让价值自己说话

Anthropic 内部没有集中式 Skill 审批流程。路径是：作者上传到 sandbox → Slack 分享 → 积累口碑 → 提 PR 进入 marketplace。这种「先证明价值再正式化」的模式，有效降低了创作门槛。

警惕远距离作用（Action at Distance）

Perplexity 特别提醒：新增一个 Skill 可能会静默降低已有 Skill 的表现。原因在于 description 之间存在注意力竞争——新 Skill 的描述若与旧 Skill 有词汇重叠，可能抢占路由优先级。因此每次变更都需要配合 eval 套件验证。

Skill 构建的实操建议

不要铁路化（Don't Railroad）：避免写过度规定步骤的指令序列（「运行 git checkout → 运行 git cherry-pick → ...」），而应给出意图加约束（「cherry-pick 到一个干净分支，解决冲突时保留原始意图」）。给模型信息和灵活度，让它根据具体情况自行调整。

存脚本，生成代码：将确定性逻辑放在 scripts/ 目录，让模型组合现有脚本而不是从零重建。这可以避免模型每次拼凑 SQL 查询或 API 调用时反复引入错误。

帮模型记住：使用持久化数据目录（如 ${CLAUDE_PLUGIN_DATA}），让 Skill 在其中维护追加式日志、JSON 状态文件或 SQLite 数据库，实现真正的跨会话记忆。

层级结构管理复杂性：Perplexity 分享了一个典型实验——美国税法 Skill 有 1,945 个 IRC 条款，平铺在单个文件中时表现反而比不加载 Skill 还差；改为三层目录嵌套后效果显著提升。信息过载对模型的伤害，往往比信息缺失更大。

度量与迭代

Anthropic 方案：使用 PreToolUse hook 记录 Skill 调用日志，识别高频使用的 Skill（证明价值）和触发率低的 Skill（需优化 description）。

Perplexity 方案：多维度 Eval 框架——精确度（不该触发时是否误触发）、召回率（该触发时是否遗漏）、禁止加载检查（邻域隔离是否有效）、跨模型一致性（GPT vs Claude Opus vs Claude Sonnet 的行为差异）。

两大实践者横向对比

维度	Anthropic (Claude Code)	Perplexity (Computer)
核心定位	开发者工具增强	多领域通用 Agent
分发模式	仓库内嵌 + Marketplace	运行时按需加载
触发方式	`/skill-name` 或模型自动匹配	`load_skill()` + 依赖递归
质量保证	使用量追踪 + 有机口碑	Eval-First + 跨模型测试
维护哲学	「从几行字开始，慢慢生长」	「追加 Gotchas 飞轮」
Token 管理	渐进式披露 via references/	三层成本模型
依赖管理	非内建，通过名称引用	`depends:` 前置元数据递归加载

一个正在成形的新工程学科

这两篇文章共同指向一个正在浮现的领域——Agent Knowledge Engineering（Agent 知识工程）。它与传统 Prompt Engineering 有本质区别：

	Prompt Engineering	Agent Skill Engineering
粒度	单次对话	跨会话持久化
关注点	输出格式与质量	路由、加载、维护
度量	输出评分	触发精确度/召回率
维护	一次性编写	持续飞轮迭代
核心资产	提示词文本	目录结构 + 脚本 + Gotchas

正如 Anthropic 的 Thariq Shihipar 所说：「最好的 Skill 始于几行字和一个 Gotcha，然后随着模型遇到新的边界情况不断生长。」

未来的 AI 工程师，不只是写 prompt 的人，更是设计、维护和度量「Agent 知识资产」的人。Skill，正是这种知识资产的标准载体。