Agent频繁跑偏？问题可能出在System Prompt上。本文从PM视角剖析常见错误，提出五维结构化设计框架，将业务规则转化为模型语言，从根源上提升Agent稳定性，让产品经理真正掌控AI行为边界。

你有没有遇到过这种场景：

Agent运行了5步，突然开始做一件你完全没让它做的事。或者明明你在需求文档里写了“只处理已确认订单”，它却把草稿单也一起改了。

开发说：模型问题。

测试说：边界没覆盖。

PM说：……我也不知道哪里出了问题。

其实，很多时候根源在System Prompt写错了。

System Prompt不是备注，是Agent的神经系统

很多PM把System Prompt当成“给模型的使用说明”——写几句“你是一个客服助手，请礼貌回答用户问题”就交差了。

这在简单对话场景里勉强够用。但在Agent场景下，这种写法会让整个系统不稳定。

原因在于：Agent不是一问一答，它是多步骤自主决策。每一步，模型都在用System Prompt里的信息判断：

1. 我该不该执行这个动作？
2. 这个情况符合任务定义吗？
3. 出现意外时，我该停下来还是继续？

System Prompt写得模糊，Agent就会“自由发挥”。而“自由发挥”在生产系统里，几乎等于Bug。

PM最常犯的3个System Prompt错误

错误一：只写身份，不写边界

反例：

你是一个数据分析助手，帮助用户分析业务数据。

问题：Agent不知道它能用哪些工具、不能碰哪些数据、遇到权限不足时该怎么办。

正例：

你是数据分析助手，只处理用户明确上传的CSV文件。

禁止主动访问数据库或外部API。

如果用户要求分析你没有权限的数据，说明原因并请用户上传文件。

错误二：用自然语言描述流程，而不是结构化约束

反例：

先理解用户需求，然后查询相关数据，最后生成报告。

模型会把这当成“参考流程”，遇到分支情况就自己判断。

正例：

执行顺序（必须严格遵守）：

1. 确认用户请求类型（分析/查询/导出）

2. 如果是分析：调用 analyze_data 工具

3. 如果是查询：调用 query_records 工具，参数必须包含 date_range

4. 生成回复前，检查结果是否为空

5. 如果结果为空，返回“未找到数据”，不要自行推断

错误三：没有写”异常行为”的处理规则

Agent在生产环境里一定会遇到你没预料到的情况。如果System Prompt里没有异常处理指引，模型会“猜”——而猜错的代价可能很大。

好的System Prompt需要明确：

• 遇到模糊指令怎么办（询问还是拒绝）
• 遇到工具调用失败怎么办（重试还是上报）
• 遇到超出职责范围的请求怎么办（明确拒绝还是转交）

5个维度，写出稳定的Agent System Prompt

我把System Prompt的结构拆成5个维度，每个维度各司其职：

维度1：角色定义（Role）

不只是“你是什么”，而是“你的职责边界在哪里”。

你是XX公司的订单处理Agent。

你的职责范围：处理状态为“已支付”的订单的退款申请。

超出范围的请求（如修改商品、更改地址）一律回复“请联系人工客服”。

关键点： 职责边界要比功能描述更重要。

维度2：工具使用规则（Tool Policy）

明确每个工具的使用条件和禁止场景。

可用工具：

query_order(order_id)：查询订单信息，仅用于核实状态

submit_refund(order_id, amount)：提交退款，仅当订单状态为”已支付”时调用

notify_user(message)：发送通知，每次退款操作后必须调用

禁止：

不得在未查询订单的情况下直接调用 submit_refund

不得连续调用 submit_refund 超过1次（防止重复退款）

维度3：决策优先级（Decision Priority）

当多个规则冲突时，告诉Agent哪个优先。

优先级（从高到低）：

1. 安全规则：禁止任何可能导致金额错误的操作

2. 用户指令：按用户明确说明的金额退款

3. 系统默认：如用户未指定，按订单原始金额退款

没有优先级，Agent遇到冲突就会随机选——这是线上事故的高发点。

维度4：输出格式（Output Format）

Agent的输出不只是给用户看的，很多时候还要被下游系统解析。格式乱了，整个流水线就断了。

每次操作完成后，必须返回JSON格式：

{

“action”: “refund_submitted” | “request_rejected” | “clarification_needed”，

“order_id”: “&lt；订单号>”，

“amount”: &lt；退款金额，数字>，

“reason”: “&lt；简短说明，≤50字>”

}

禁止在JSON外添加任何额外文字。

维度5：停止条件（Stop Condition）

这是最容易被忽略的一个维度，也是最重要的安全阀。

在以下情况下，立即停止执行并返回 “action”: “halt”：

-退款金额超过订单金额的110%

-同一订单在24小时内已有退款记录

-用户提供的订单号与查询结果不符

明确的停止条件，是防止Agent“一路跑偏到底”的最后一道防线。

一个真实的对比案例

某电商团队做了一个“退款自动处理Agent”，上线第一周出现了3起重复退款事故。

排查发现，System Prompt里写的是：

处理用户的退款请求，查询订单，确认后提交退款，通知用户。

改成结构化版本（包含工具使用规则+停止条件）后，重复退款归零。

Prompt改动≈0行代码，解决的是系统架构层面的稳定性问题。

PM在System Prompt设计中的真正价值

开发工程师写System Prompt，往往关注“能不能跑通”；PM关注的应该是“会不会出错”。

这两个视角的差距，就是PM在Agent项目中最核心的价值所在。

具体来说，PM需要：

1. 提前穷举异常场景

正常流程开发可以搞定，异常场景是PM的责任。退款金额为0怎么办？用户输入的订单号格式错了怎么办？这些边界情况必须在System Prompt里给出明确指引。

2. 把业务规则翻译成约束语言

“不能重复退款”是业务规则，翻译成System Prompt就是“同一订单在24小时内已有退款记录时停止执行”。这个翻译过程，技术同学很难独立完成。

3. 版本化管理System Prompt

System Prompt是产品逻辑，应该像代码一样做版本管理。每次修改要有记录，A/B测试要有数据，回滚要有预案。

最后一句话

Agent跑偏，80%不是模型的问题，是Prompt设计的问题。

而Prompt设计，本质上是产品设计——把业务逻辑、边界约束、异常处理转化成模型能理解的语言。

这件事，PM比任何人都有资格做好。