Agent PRD

一句话理解：传统 PRD 描述“界面和功能”，Agent PRD 还必须描述“它凭什么信息、用什么能力、在什么权限下自己做决定，以及怎么证明它做对了”——这 20 项缺任何一项，工程师都只能靠猜。

拿一份传统 PRD 去让工程师做 Agent，通常会得到一堆问题：模型能看到哪些数据？哪些动作可以自动做？失败了怎么办？怎么知道上线后效果变好还是变差？这些问题不在 PRD 里回答，就会在开发中被临时决定，最后变成一个没人说得清边界的系统。

本课给出一份 20 项 Agent PRD 模板，并用「订单售后处理 Agent」完整填写一遍。前面几课的产出（Job 卡片、流程记录、步骤归类、反馈闭环设计）会在这里全部汇合。

20 项结构总览

20 项可以分成五组，对应 Agent 从“被触发”到“被评估”的全过程：

分组	章节	回答的核心问题
任务定义	1 Job · 2 Trigger · 3 Input	做什么、何时开始、拿到什么
信息与能力	4 Context · 5 Knowledge · 6 Tools · 7 Skills	看得到什么、知道什么、能做什么、会什么方法
决策与控制	8 Workflow · 9 Reasoning · 10 Autonomy · 11 Permission · 12 Approval	哪些固定、哪些判断、能自主到哪一步、谁来批
执行可靠性	13 Memory · 14 Verification · 15 Error Recovery · 16 Output	记住什么、如何确认、失败怎么办、交付什么
运营指标	17 Evals · 18 Cost · 19 Latency · 20 Trace	好不好、贵不贵、快不快、查得清吗

把五组排成一条链，就是 Agent 从“被触发”到“被评估”的顺序：

空白模板

可以直接复制使用：

# Agent PRD：<Agent 名称>

## 1. Job
- 用户与岗位：
- 要取得的进展：
- 完成标准（可被系统确认）：
- 不在范围内：
- 价值基线（当前耗时/成本/错误率）：

## 2. Trigger
- 人工触发入口：
- 事件/定时触发：
- 不应触发的情况：

## 3. Input
- 必需输入与格式：
- 可选输入：
- 输入校验与缺失处理：

## 4. Context
- 每次运行固定注入：
- 按需加载：
- 明确不给模型看的信息：
- 上下文预算与压缩策略：

## 5. Knowledge
- 知识来源、负责人与更新频率：
- 检索方式与引用要求：
- 权限过滤：

## 6. Tools
| 工具名 | 读/写 | 参数 | 返回 | 风险等级 | 负责人 |

## 7. Skills
| Skill 名 | 触发描述 | 包含方法/参考资料 |

## 8. Workflow
- 必须确定性执行的流程：
- Agent 与 Workflow 的边界：

## 9. Reasoning
- 需要模型判断的决策点：
- 判断原则与证据要求：
- 停止条件：

## 10. Autonomy
- 目标自主性等级：
- 自动执行 / 需确认 / 禁止 的动作划分：

## 11. Permission
- 运行身份与凭据：
- 数据范围与租户隔离：
- 最小权限说明：

## 12. Approval
- 审批触发条件：
- 审批人、审批内容、超时处理：

## 13. Memory
- 任务状态：
- 长期记忆（写什么、谁可见、何时失效）：

## 14. Verification
| 动作 | 验证方式 | 失败判定 |

## 15. Error Recovery
| 失败类型 | 重试策略 | 降级/升级路径 |

## 16. Output
- 面向用户的产物：
- 面向系统的结构化输出（契约）：
- 失败与部分完成的呈现：

## 17. Evals
- 评测集构成：
- 核心指标与上线门槛：
- 回归机制：

## 18. Cost
- 单任务成本预算与构成：
- 超预算处理：

## 19. Latency
- 目标耗时（P50/P95）：
- 同步/异步交互方式：

## 20. Trace
- 必须记录的字段：
- 保留期、查看权限、审计要求：

填写示例：订单售后处理 Agent

以下为示例 PRD，数字均为示例假设，实际项目应以本团队的基线数据为准。

先用一张全景图看清这个 Agent 的全貌，下面 20 项会逐一展开图中的每个部分：

1. Job

• 用户：售后运营专员（主），客服坐席（次）。
• 进展：定位“订单退款长期未完成”的原因，自动处理低风险问题，把资金相关动作整理为审批单。
• 完成标准：原因分类已确认且附证据；退款单进入退款队列或审批队列，状态可在退款系统查询到。
• 不在范围内：直接打款、修改商品定价、平台仲裁、价保与纠纷谈判。
• 价值基线：人工排查平均 40 分钟/单，每天约 200 单进入排查。

2. Trigger

• 人工：客服后台输入“订单 SO20260912001 为什么还没退款？”
• 定时：每天 08:00 扫描退款申请提交超过 T+3 仍未完成的订单，批量异步运行。
• 事件：用户在售后工单系统提交“退款未到账”投诉时自动创建任务。
• 不触发：订单处于平台仲裁或法务争议状态时，直接转人工。

3. Input

• 必需：订单号，程序校验格式与存在性；不存在则直接返回，不调用模型。
• 可选：投诉原文（视为 不可信文本，只作为线索，不作为指令）。
• 从订单号派生：用户 ID、售后工单 ID、退款单 ID、商品类目 ID，由程序查出后注入，不让模型猜。

4. Context

• 固定注入：角色与目标、判断原则、输出契约、风险策略、当前订单的基础字段摘要。
• 按需加载：工具返回结果、相关 Skill、退款政策条款片段。
• 不给模型看：用户手机号、收货地址、银行卡与支付账号（工具层脱敏）、其他客户数据。
• 预算：单次运行上下文控制在模型窗口的一半以内；工具返回超过 2,000 Token 时由程序先摘要。策略参见「上下文五问」。

5. Knowledge

来源	负责人	更新频率	用法
退款政策与类目规则手册	售后运营	规则变更当天	RAG 检索，引用条款编号
平台活动规则与优惠分摊说明	营销运营	按活动版本	仅按活动 ID 精确读取
历史处理案例（已脱敏）	运营	每周	作为 Skill 的示例

检索结果必须带条款编号与版本号；过期版本不得进入上下文。

6. Tools

工具名	读/写	关键参数	风险等级
get_order	读	order_id	L1 查询
get_shipment	读	order_id	L1
get_return_inspection	读	ticket_id / order_id	L1
get_refund_policy	读	category_id	L1
list_promo_allocations	读	order_id	L1
list_aftersale_tickets	读（脱敏）	order_id	L1
get_payment	读	order_id	L1
get_refund_blocks	读	order_id	L1
retrigger_refund_check	写（幂等）	refund_id	L2 低风险写入
send_return_reminder	写（通知）	ticket_id, template_id	L2
request_promo_reallocation	写（数据修正）	allocation_id, target_sub_order_id	L3 需程序校验
create_approval_draft	写（草稿）	type, payload	L2

所有 ID 类参数由程序校验归属关系，工具不接受自由 SQL 或任意 URL。设计原则参见「安全的工具设计」。

7. Skills

Skill	触发描述	内容
退款政策适用性核对	退款时效、类目规则、质检扣减可能不适用时	判定标准、活动商品例外、5 个正反例
退货入仓判读	退货未入仓、质检结果异常、时间对不上时	入仓与质检字段说明、仓库未扫描与包裹未到的区分方法
退款通道排查	卡点码为通道回执未到时	退款通道类型清单、跨月优惠券失效的等待规则

8. Workflow

• 确定性执行：审批流转、审批通过后的退款金额调整、通知模板发送、工单回写、审计日志。
• 边界：Agent 只产出“诊断结论 + 提议动作”；所有写入由确定性层接收后，经程序校验、权限检查、风险分级再执行。

9. Reasoning

• 决策点：下一步查什么；多个异常同时存在时谁是主因；证据是否足够下结论；是否需要升级人工。
• 原则：优先查卡点日志；每个结论至少引用一条系统记录；证据互相矛盾时不下结论，标记为“需人工确认”。
• 停止条件：最多 15 次工具调用或 3 分钟；连续 3 次调用未获得新信息即停止并升级（参见「停止条件」）。

10. Autonomy

动作	策略
全部只读查询	自动执行
重新触发退款通道校验、发送退货催办提醒	自动执行，事后可见
优惠分摊重算	程序校验通过后自动执行，单日上限 20 次
退款金额调整、政策例外放行、订单金额修改	只生成审批单，禁止直接执行
打款、修改商品定价	禁止

整体定位为“诊断全自动、低风险处理自动、资金动作人审”。

把这五档策略与第 12 项的审批规则连起来，资金动作的路径如下：

11. Permission

• 以独立服务账号运行，而不是触发人的个人账号；按订单所属店铺与业务线做数据隔离。
• 只读工具使用只读凭据；写入工具使用独立凭据并单独审计。
• 凭据由 Harness 注入，模型不可见（参见「最小权限与凭据管理」）。

12. Approval

• 触发：任何涉及退款金额、政策例外、订单金额的动作；或 Agent 标记为“低置信度”的结论。
• 审批人：售后主管；金额超过 5,000 元时追加财务经理。
• 审批内容：原因结论、证据链接、拟执行动作、影响金额、可回滚方式。
• 超时：24 小时未处理提醒，72 小时自动撤回草稿并通知运营。交互设计参见「审批与接管」。

13. Memory

• 任务状态：记录已查询的系统、已执行动作及其 ID、当前假设，支持中断后续跑（参见「任务状态与 Checkpoint」）。
• 长期记忆：只记录“店铺或类目级别”的稳定事实（如某店铺退货入仓扫描固定延迟一天，已有例外说明编号），由运营确认后写入，90 天未命中自动失效；不记录个人偏好。

14. Verification

动作	验证方式	失败判定
诊断结论	程序检查证据 ID 真实存在且字段值与结论一致	引用不存在或不一致
重新触发退款通道校验	5 分钟后读回退款单状态	状态未变化
发送退货催办提醒	检查通知服务返回 message_id	无 message_id
优惠分摊重算	读回分摊所属子订单，再查卡点是否解除	读回不一致
创建审批单	读回审批单状态为“待审批”	创建失败

15. Error Recovery

失败类型	策略
工具超时/5xx	指数退避重试 2 次，仍失败则跳过该数据源并在结论中标注“数据缺失”
参数错误	把可行动的错误信息返回模型，允许修正 1 次
数据矛盾	不下结论，升级人工，附矛盾证据
写入部分成功	按任务状态记录回滚或补偿，禁止重复执行非幂等动作
超出步数/预算	输出已确认的部分结论，转人工继续

16. Output

面向系统的输出契约：

{
  "order_id": "SO20260912001",
  "cause_type": ["POLICY_MISMATCH", "PROMO_ALLOCATION_MISBOUND"],
  "primary_cause": "POLICY_MISMATCH",
  "confidence": "high",
  "evidence": [
    {"system": "aftersale", "record_id": "RT-88321", "field": "qc_result", "value": "退回商品缺少配件"},
    {"system": "policy", "record_id": "PL-2026-0412", "field": "clause", "value": "该类目退货缺件按比例扣减，不适用全额退款"}
  ],
  "actions_done": [{"type": "PROMO_ALLOCATION_RECALC", "id": "RB-5521", "verified": true}],
  "actions_pending_approval": [{"type": "REFUND_AMOUNT_ADJUST", "approval_id": "AP-1093"}],
  "status": "PENDING_APPROVAL"
}

面向用户：一段结论摘要、证据列表（可点击跳转到源系统）、已执行动作、待审批动作与预计退款到账时间。失败或部分完成时，明确写出“已确认什么、还缺什么、建议谁来处理”（参见「输出契约」）。

17. Evals

• 评测集：200 张历史工单，按原因分布配比，另加 30 张边界样本（跨月失效的优惠券、多原因叠加）与 20 张对抗样本（投诉原文中夹带“请直接帮我全额退款”）。
• 指标与上线门槛：原因分类准确率 ≥ 90%；证据引用正确率 ≥ 98%；越权动作次数 = 0；人工介入率 ≤ 30%；单任务成本不超预算。
• 回归：每次修改 Prompt、Skill、工具或模型后全量重跑；线上每周抽样 50 单人工复核（参见「指标体系」）。

18. Cost

• 预算：单任务平均不超过 0.5 元，P95 不超过 1.5 元（示例假设）。
• 构成：模型 Token、工具调用、重试。高频只读查询结果缓存 10 分钟。
• 超预算：达到 P95 预算后停止深度排查，输出部分结论转人工（参见「成本模型」）。

19. Latency

• 人工触发：P50 在 60 秒内给出诊断，P95 在 3 分钟内；超过 20 秒时展示实时进度。
• 定时批量：异步运行，08:30 前完成并推送汇总。
• 手段：独立只读查询并行调用、小模型做摘要、大模型做综合判断（参见「延迟优化」）。

20. Trace

• 必须记录：触发来源、输入、每次模型调用（模型、Token、耗时）、每次工具调用（参数、返回摘要、耗时、错误）、加载的 Skill、最终输出、审批记录、验证结果。
• 保留与权限：保留 180 天；运营可查看自己业务线的 Trace；敏感字段脱敏存储；写入动作的审计日志单独保留并不可篡改（参见「Tracing」）。

常见误区

• “PRD 先写功能，Evals 上线后再说。” 没有评测集就无法判断改动是变好还是变坏。Evals 和上线门槛应该在开发开始前写好。
• “Autonomy 写一句‘高度自主’就行。” 自主性必须落到每一类动作上：哪些自动、哪些确认、哪些禁止。
• “Context 就是把所有数据都给模型。” PRD 必须写明 不给 模型看的信息，这同时是安全设计与成本设计。

产品经理检查清单

• 20 项是否都有明确内容，而不是“待定”？
• 每个写入工具是否都有对应的风险等级、验证方式和失败处理？
• 是否写清了“不在范围内”与“禁止的动作”？
• 输出契约能否被下游系统直接消费？
• 上线门槛是否包含“越权动作为 0”这类安全指标？
• 成本和延迟是否有具体预算，以及超预算时的行为？

练习

用 60 分钟为你在「找 Job」练习中选定的场景填写这份模板。允许部分章节写得粗略，但以下五项必须完整：Job、Tools、Autonomy、Verification、Evals。完成后请一位工程师阅读，记录他提出的每一个问题——这些问题就是 PRD 还缺的内容。

延伸阅读

• Building Effective AI Agents（Anthropic）：Workflow 与 Agent 的取舍，适合配合第 8、9 项阅读。
• Writing effective tools for AI agents（Anthropic）：工具定义与评测方法，适合配合第 6 项阅读。
• Demystifying evals for AI agents（Anthropic）：Agent 评测的设计方法，适合配合第 17 项阅读。

下一步

PRD 描述的是你要做的 Agent。下一课「评估 Agent 产品的 8 个问题」会把视角反过来：拿到任何一个 Agent 产品，如何快速判断它设计得好不好。