Perplexity 如何设计 Agent Skills：从 Prompt Engineering 到 Context Engineering

原文：
《Designing, Refining, and Maintaining Agent Skills at Perplexity》
https://research.perplexity.ai/articles/designing-refining-and-maintaining-agent-skills-at-perplexity

---

前言

Perplexity 这篇文章讨论的核心，其实不是 Prompt，而是：

如何把 Agent 的能力进行工程化管理。

他们提出了一个非常重要的概念：

Skill = 面向模型的上下文模块

它不是普通文档，也不是单纯 Prompt，而是一种：

• 可路由

• 可加载

• 可维护

• 可测试

的运行时上下文单元（Runtime Context Unit）。

---

一、什么是 Skill？

传统软件里：

• Function 是能力

• Service 是能力

而在 Agent 系统里：

Skill 才是能力载体

Perplexity 认为：

Skill 的本质是“上下文封装（Context Packaging）”。

它的目标不是给人看，而是：

给模型提供正确的运行时上下文

因此：

Skill 设计的核心问题变成了：

什么内容应该进入上下文？
什么时候进入？
以什么粒度进入？

---

二、为什么 Prompt Engineering 不够了？

传统 Prompt Engineering 的问题：

所有内容一次性塞进 System Prompt

这会导致：

• Context 膨胀

• Attention 分散

• 指令冲突

• 路由不稳定

Perplexity 提出的方向是：

Context Engineering

核心思想：

上下文应该像内存一样被管理。

---

三、Skill 的目录结构

Skill 并不是单个 markdown 文件。

典型结构：

my_skill/
├── SKILL.md
├── scripts/
├── references/
├── assets/
└── examples/

其中：

目录	作用
SKILL.md	核心规则
scripts	工具脚本
references	参考资料
assets	静态资源
examples	示例

核心思想：

重要内容不要直接进入上下文

---

四、Progressive Loading（渐进式加载）

这是全文最重要的设计。

Perplexity 将 Skill 分成三层：

---

第一层：Skill Index

只包含：

name:
description:

用于：

Skill Routing

通常 <100 tokens。

---

第二层：SKILL.md

真正加载 Skill 时：

读取核心规则。

内容包括：

• 工作流

• 约束

• gotchas

• 示例

一般控制在：

~5000 tokens

---

第三层：Heavy Assets

例如：

• references/

• examples/

• assets/

这些：

按需读取

不会一开始进入上下文。

---

五、Description 其实是 Router

Perplexity 特别强调：

Description 最重要

因为它决定什么时候加载SKILL

错误写法：

This skill helps with React UI.

正确写法：

Load when user asks for dashboard-style React admin UI.

区别在于：

错误写法	正确写法
面向人	面向路由
描述功能	描述触发条件

---

六、Skill Tree：为什么必须分层？

文章中提到：

Perplexity 曾尝试：

1945 个税法 Skill 平铺

结果：

路由效果极差

原因：

模型无法稳定从大量候选中选择。

于是改成：

Tax
 ├── Federal
 ├── State
 └── International

本质上：

分层检索

类似：

• B-Tree

• 多级召回

• 分层路由

---

七、Skill 最大价值：不是流程，而是 Gotchas

Perplexity 提出一个非常重要的观点：

模型通常知道流程，但不知道坑。

例如：

不要修改 migration 文件
先 dry-run
不要覆盖 generated code

这些：

才是 Skill 最有价值的内容

因为它们直接决定：

• 稳定性

• 安全性

• 工程正确性

---

八、Eval-Driven Development

Perplexity 强调：

Skill 开发第一步不是写 Skill

而是：

先写 Eval

主要包括：

Eval 类型	作用
Routing Eval	是否正确加载
File Read Eval	是否读取正确文件
Progressive Loading Eval	是否按需加载
End-to-End Eval	最终任务质量

原因很简单：

Agent 的问题是行为问题

而不是代码问题。

---

九、Skill Maintenance：Append-Mostly

Perplexity 认为：

Skill 是 append-mostly 的

也就是说：

维护 Skill 时：

不是频繁改规则。

而是：

持续追加失败经验

例如：

## Gotchas

- React Server Component 不支持 xxx
- Windows 环境下某 API 会失败
- 不要修改 lockfile

这其实非常像：

工程经验沉淀

---

十、我认为最重要的几个思想

1. Context 是资源

不是：

token 越多越好

而是：

注意力越聚焦越好

---

2. Description 是 Router

不是：

文档简介

而是：

Skill 触发器

---

3. Skill 更像行为补丁

它不是教模型知识。

而是：

修正模型行为

---

4. Progressive Loading 非常关键

Agent 不应该：

一次性加载全部上下文

而应该：

按需加载

---

结语

Perplexity 这篇文章最大的价值在于：

它展示了：

Agent Engineering 正在演化成一种新的软件工程

在这个体系里：

Agent 世界	传统系统类比
Context	内存
Skill	模块
Description	Router
Eval	测试
Progressive Loading	虚拟内存
Attention	CPU Cache

未来 Agent 系统的竞争力，很可能不再只是模型本身。

而是：

谁能更高效地组织上下文。