我以为我懂Prompt，直到看了Perplexity这份内部手册

最近，Perplexity的一份内部手册在开发者圈子里悄悄流传。

这份名为"Agent Skills"的文档，是Perplexity用来训练内部团队如何设计AI Agent的指导手册。它不是一份面向公众的PR材料，所以没有刻意讨好任何人。也正因为如此，它在第一页就说了一句让很多"Prompt老手"不舒服的话：

"你在对话式AI上积累的大部分直觉，在Agent系统中不仅无效，甚至有害。"

我第一次读到这句话的时候，坐在椅子上愣了大概十秒钟。

我写Prompt也有一两年了，从Zero-shot到Few-shot，从Chain-of-Thought到Self-consistency，自以为摸出了一套方法论。但这句话让我意识到，我可能一直在用"说服一个人"的思维，去"设计一个系统"。

这两件事，根本不是一回事。

本文不是手册的全文翻译，也不是资讯搬运。我只拆其中最反常识的3个设计原则——那些会让有经验的Prompt工程师皱眉头的部分。如果你是小白，恭喜你，你没有坏习惯，反而是优势。

---

原则一：别告诉Agent怎么做，告诉它什么时候停

普通Prompt工程师的直觉：步骤写得越详细，AI执行得越准确。

这个直觉在单轮对话里是对的。但在Agent场景里，它会让你的系统变成一个停不下来的失控机器。

手册里有一段话我反复读了好几遍：

"执行逻辑是AI自己的事，终止条件是你必须设计的事。一个没有明确停止信号的Agent，会在任务完成之后继续'优化'，直到它把结果搞坏为止。"

来看一个具体对比。假设任务是：从一批网页里提取竞品价格信息，整理成表格。

Prompt写法（传统思维）： 
请按以下步骤操作：

1. 访问以下URL列表


2. 找到每个页面上的价格信息


3. 提取产品名称、价格、货币单位


4. 整理成Markdown表格


5. 如果某个页面没有价格，标注"N/A"


6. 最后检查表格格式是否整齐
Agent Skills写法（系统思维）： 
任务目标：从URL列表提取价格数据


终止条件（满足任一即停止）：


  • 所有URL均已处理（成功或失败均记录）
    • 

  • 连续3次网络请求失败
    • 

  • 运行时间超过120秒
    • 

  • 提取到的数据行数超过500行
    • 



输出格式：{产品名, 价格, 货币, 来源URL, 状态}


状态枚举：success | not_found | access_denied | parse_error



不要做的事：


  • 不要尝试"猜测"缺失的价格
    • 

  • 不要重试已经标注access_denied的URL
    • 

  • 不要在输出之后继续"优化"格式
    •

你看到差异了吗？

Prompt写法在描述"怎么做"，Agent写法在定义"边界"。前者假设AI是一个执行指令的工人，后者把AI当作一个需要被约束的自主系统。

步骤越详细，Agent越容易在步骤之间的缝隙里"自由发挥"。而终止条件，才是防止它失控的真正护栏。

💡 一行总结：给Agent写说明书，不如给它画围栏。

---

原则二：上下文不是越长越好，是越干净越好

这是手册里我觉得最被低估的洞察，也是最容易被忽视的工程问题。

Prompt工程的常见建议是"多给信息"——背景、约束、例子、格式要求，全部塞进去，越详细越好。这个建议在单轮对话里成立，但在Agent的多步执行链路里，它会制造一个叫做"上下文污染"的问题。

手册里的原话是：

"Agent在执行过程中产生的中间状态、错误信息、工具调用日志，如果不加过滤地累积在Context Window里，会让模型在后续步骤里越来越'分心'。我们内部把这个现象叫做Context Drift。"

想象一个Agent在执行一个10步的数据处理任务。到第5步的时候，它已经在上下文里积累了：

  • 第1步的原始输入（有用）
  • 第2步的中间结果（部分有用）
  • 第3步的工具调用失败日志（已无用）
  • 第4步的重试记录（已无用）
  • 第5步之前的所有思考过程（大部分无用）

这堆东西全部压在模型的注意力上，它在执行第6步的时候，质量会显著下降——不是因为任务变难了，而是因为它需要从一堆噪音里找到真正有用的信号。

判断"上下文已经脏了"的3个信号：

1. 模型开始重复之前步骤已经完成的工作——它迷失了，不知道自己在哪里

2. 输出开始出现与当前步骤无关的内容——之前的错误信息在"污染"当前输出

3. 相同指令的执行质量在第N步明显低于第1步——这是Context Drift的典型症状

上下文裁剪策略（可直接复用）： 
每个执行步骤结束后，只保留以下内容传入下一步：

✅ 最终目标（不变）


✅ 当前步骤的输出结果（压缩版）


✅ 已完成步骤的状态摘要（一行）


✅ 当前步骤的失败原因（如有）



主动丢弃：


❌ 中间思考过程


❌ 工具调用的原始日志


❌ 已经被覆盖的中间状态


❌ 重试记录（只保留最终结果）

这个策略的本质是：把Agent的"工作记忆"和"长期记忆"分开管理，而不是让它们混在一个越来越长的对话历史里。

💡 一行总结：上下文是Agent的工作台，你要定期清桌子，不是一直往上堆东西。

---

💡 想直接动手验证这些原则？

文中的对比案例都可以在 [api.884819.xyz](https://api.884819.xyz) 上直接跑——支持调用 GPT、Claude、Deepseek 等主流模型API，你可以把"Prompt写法"和"Agent写法"的两个版本分别测试，亲眼看输出质量的差距。

对于想认真学Agent开发的读者，自己跑一遍比看十遍文章管用。新用户注册即送体验token，国产模型（Deepseek/千问等）完全免费，没有月租，注册即用。

---

原则三：失败路径比成功路径更值得设计

这是手册里篇幅最长的章节，也是最让我坐立不安的部分。

普通Prompt工程师（包括一年前的我）花90%的精力在写"让AI做对"的指令。我们反复调试，直到Happy Path跑通，然后就觉得大功告成了。

但手册里有一句话直接戳穿了这个幻觉：

"一个只在理想条件下工作的Agent，不是一个Agent，是一个演示。真实环境里，API会超时，网页会返回403，数据会有脏字段，用户输入会完全超出预期。一个不知道如何优雅失败的Agent，是一个危险的Agent。"

"危险"这个词用得很重。因为Agent不像单轮对话——它会在真实环境里自主执行多个步骤，如果中途出错但没有失败处理机制，它会继续往下走，把错误一路带到最终输出，甚至触发一些不可逆的操作（比如发送了一封格式错误的邮件，或者删除了不该删的文件）。

Agent失败路径设计的决策树： 
任务执行

│


├── 成功 → 输出结果，记录状态，清理上下文


│


└── 失败


│


├── 可重试的失败（网络超时、限流）


│       │


│       ├── 重试次数 < 3 → 等待后重试


│       └── 重试次数 ≥ 3 → 降级处理


│


├── 不可重试的失败（权限不足、数据格式错误）


│       │


│       └── 立即停止当前子任务


│               │


│               ├── 有回退方案 → 执行回退


│               └── 无回退方案 → 标记失败，继续其他子任务


│


└── 不确定的失败（输出无法验证、置信度低）


│


└── 不要猜测，主动暴露不确定性


│


├── 有人工介入机制 → 请求确认


└── 无人工介入机制 → 标注"低置信度"后输出

最后一个分支是手册里我觉得最有价值的洞察：不确定的时候，Agent必须说"我不确定"，而不是给出一个听起来自信的错误答案。

手册里把这个能力叫做"Uncertainty Expression"，并且明确说：

"一个会表达不确定性的Agent，比一个永远自信的Agent更可信。前者让你知道哪里需要人工介入，后者让你在不知情的情况下信任了一个错误。"
具体怎么设计失败路径？以下是可以直接复用的模板： 
失败处理规范：


1. 每个工具调用必须有明确的成功/失败判断标准


示例：HTTP状态码200-299为成功，其他为失败



2. 失败分类必须在Prompt里预先定义


- RETRY: 可重试，等待{n}秒后重试，最多{m}次


- SKIP: 跳过当前项，继续处理下一项


- ABORT: 终止整个任务，返回已完成部分


- ESCALATE: 标记需要人工处理



3. 不确定性输出格式


{


"result": "...",


"confidence": "high|medium|low",


"uncertainty_reason": "...",  // confidence非high时必填


"requires_human_review": true/false


}



4. 禁止的行为


- 不要在失败后继续执行依赖该结果的步骤


- 不要用"可能""也许"掩盖真实的失败


- 不要在没有回退方案时强行给出一个"差不多"的结果
💡 一行总结：Happy Path是你的期望，Failure Path才是你的产品。

---

收尾：放弃控制幻觉，才是真正的掌控

把这三个原则放在一起，你会发现它们指向同一个认知转变：

Prompt是你在控制AI。Agent是你在约束一个会自主行动的系统。

写Prompt的时候，你是导演，AI是演员，你说什么它演什么。这种关系让你有一种清晰的控制感——我说了，它就做了。

但Agent不是这样工作的。你设计的是规则、边界、终止条件、失败处理机制——然后你放手，让它在真实环境里自主运行。你无法预测它会遇到什么，但你可以设计它遇到任何情况时的行为准则。

这不是技术问题，是设计哲学问题。

就像城市规划师不会告诉每辆车怎么开，但他设计了红绿灯、单行道、限速标志。车辆在这个系统里自主行驶，但不会失控——因为约束设计得足够好。

从Prompt工程师到Agent设计师，这个转变的本质是：放弃对每一个步骤的控制幻觉，换取对整个系统行为的真正掌控。

如果你想迈出第一步，我的建议很具体：

1. 找一个你现在正在用的Prompt，问自己："这个任务的终止条件是什么？" 如果你答不上来，说明它还不是Agent思维。

2. 把你下一个Agent项目的失败路径先于成功路径写出来。

3. 在 [api.884819.xyz](https://api.884819.xyz) 上跑一次"Prompt写法 vs Agent写法"的对比实验，用同一个模型，看输出质量的差距。

思维模型的升级，从来不是读完一篇文章就发生的。但有时候，一篇文章可以让你意识到自己一直坐在错误的椅子上。

希望今天这篇，是那个让你站起来的时刻。

---

「下一篇我想聊一个更底层的问题：

当Agent开始能够调用Agent——也就是Multi-Agent架构真正普及之后，"谁来写Prompt"这个问题本身就消失了。

那时候，今天我们讨论的所有技巧——终止条件、上下文裁剪、失败路径——会变成历史，还是会变成地基？

这个问题，我自己也还没有答案。」

---

本文由8848AI原创，转载请注明出处。关注8848AI，带你从零开始学AI。

#AI Agent #Prompt工程 #Agent开发 #人工智能 #8848AI #AI学习 #大模型 #Agent设计