1. PRD与Agent能力边界的关系
本章从产品需求视角切入,厘清PRD在Agent开发中的定位,以及“能力边界”这一核心概念的本质含义。通过打通PRD与能力边界的映射关系,为后续章节的需求拆解、方案表达、指标验证建立统一的思维框架。
1.1 PRD在Agent开发中的重新定位
产品需求文档(PRD)在传统软件中主要负责“功能描述”,但在Agent类产品中,它的角色发生了本质变化。Agent的核心不是功能列表,而是行为规则 + 边界约束——PRD必须从“做什么”延伸到“能做什么、不能做什么、什么条件下做什么”。
传统PRD 与 Agent PRD 的关键差异:
| 维度 | 传统PRD | Agent PRD |
|---|---|---|
| 需求表达 | 功能列表 + 业务流程 | 行为规则 + 边界约束 + 决策条件 |
| 验收标准 | 功能是否按预期实现 | 行为是否在边界内、是否触发越权 |
| 变更影响 | 功能增减、排期调整 | 边界漂移、安全风险、回退策略 |
| 用户视角 | 用户操作流程 | 用户与Agent的对话/交互协议 |
Agent PRD 的核心价值:在开发之前,就把“Agent不能做什么”和“Agent在什么情况下必须停止”写清楚,而不是等上线后通过事故来发现边界漏洞。
1.2 Agent能力边界的四个维度
Agent能力边界是指一个Agent系统在功能、交互、决策、数据四个维度上被允许或不允许执行的操作集合。边界模糊是Agent项目失败的首要原因——要么Agent“越权”做了不该做的事,要么被过度约束导致无法交付价值。
| 维度 | 定义 | 边界不清的典型风险 |
|---|---|---|
| 功能边界 | Agent能调用哪些API、执行哪些操作、操作触发条件 | 越权调用、非预期操作、资源滥用 |
| 交互边界 | Agent使用什么语气、能否拒绝、能否引导话题 | 话术违规、用户投诉、品牌声誉受损 |
| 决策边界 | Agent能自主做哪些判断、哪些必须转人工 | 错误决策、资金损失、法律风险 |
| 数据边界 | Agent能读取/写入哪些数据、数据留存策略 | 隐私泄漏、数据滥用、合规处罚 |
常见误区:很多团队只定义了“功能边界”(能做什么),忽略了交互、决策、数据三个维度,导致Agent上线后出现“能回答问题但态度恶劣”“能查询数据但泄露了用户隐私”等边界事故。
1.3 PRD定义Agent边界的结合路径
PRD与Agent能力边界的结合不是单向的文档填写,而是从用户场景出发,逐层拆解、约束、验证的闭环过程。下面这张映射框架展示了从业务输入到边界输出的完整链路:
映射框架中的每一条箭头都代表一次需求→边界的转化动作。PRD中的每个需求条目,必须能够对应到功能、交互、决策、数据四个维度中的至少一个,否则该需求就是“边界未定义”状态,不允许进入开发。
1.4 实战映射:以智能客服Agent为例
下面通过一个智能客服Agent的典型需求片段,展示PRD需求如何具体映射到Agent能力边界的各个维度:
| PRD需求(用户故事) | 对应边界维度 | 边界定义(约束规则) |
|---|---|---|
| 用户查询订单物流状态 | 功能边界 | 仅允许调用「订单查询API」,禁止写入或修改 |
| 用户表达不满情绪 | 交互边界 | 必须使用安抚话术模板,禁止反问或推诿 |
| 用户申请退款 | 决策边界 | 金额≤100元自动审批,否则转人工 |
| 用户询问其他用户信息 | 数据边界 | 拒绝提供,仅返回“无法查询他人数据” |
关键要点:每一条PRD需求在写入文档时,必须同步回答三个问题:
① 这个需求落在哪个边界维度?
② 这个维度的具体约束规则是什么?
③ 如何验证Agent没有违反这个约束?
① 这个需求落在哪个边界维度?
② 这个维度的具体约束规则是什么?
③ 如何验证Agent没有违反这个约束?
1.5 本章小结
- PRD在Agent开发中从“功能描述”升级为“行为规则+边界约束”,是定义Agent能力边界的核心工具。
- Agent能力边界包含四个维度:功能、交互、决策、数据,缺一不可。
- PRD与Agent边界的结合路径:用户场景 → 需求收集 → PRD拆解 → 边界映射 → 验收标准。
- 每个PRD需求必须映射到至少一个边界维度,否则视为边界未定义,不能进入开发。
课后自检:打开你当前负责的Agent产品PRD,逐条检查每个需求是否回答了“Agent能做什么/不能做什么/在什么条件下做”。如果某条需求只有功能描述没有边界约束,它就是一条“危险需求”。