利益关系披露：DragonAI 运营 AI 产品经理课程。本文是第一方编辑设计框架，不是统一行业标准、安全认证或项目结果保证；权限、隐私、合规和高影响用途仍需由相应责任人审核。
30 秒答案：先限制能做什么，再设计怎样做
AI Agent 产品经理的核心工作，不是把普通功能改名为“智能体”，也不是默认采用多智能体。先确认用户任务是否同时包含不确定信息、多步骤决策，以及工具调用或外部状态操作；若固定规则或普通工作流已经足够，就保留更简单的方案。确需 Agent 时，再把目标、工具、身份、权限、确认点、停止条件和评测写成可验证的行为合同。
可以下载 AI Agent 产品规格与上线门禁 JSON，逐项记录设计状态。下面七步中的任何“通过”都必须连接真实测试和负责人；文中的例子只解释字段，不代表生产验证。
| 决策 | 产品经理必须回答 | 最低证据 |
|---|---|---|
| 是否需要 Agent | 为什么规则、搜索或确定性工作流不够？ | 同一任务的替代方案比较 |
| 任务边界 | Agent 可以完成哪些目标，明确排除什么？ | 任务卡、非目标、失败成本 |
| 工具与身份 | 能读写哪些系统，以谁的身份、对哪些对象？ | 工具白名单、权限矩阵 |
| 人工控制 | 哪些动作执行前必须确认，谁能批准？ | 确认策略、撤销与申诉路径 |
| 循环控制 | 何时重试、暂停、降级或停止？ | 步数、时间、费用和失败上限 |
| 评测门禁 | 怎样证明任务完成且没有越权或重复执行？ | 固定任务集、逐步轨迹、阻断项 |
| 运行责任 | 谁监测、处置、回滚和复审？ | 日志、告警、责任人、变更记录 |
一、先判断任务是否真的需要 Agent
OpenAI 的 Agent 构建指南把适合 Agent 的情形概括为：决策复杂且难以维护为规则、依赖非结构化信息，或需要模型完成多步骤工作；否则确定性方案可能已经足够。产品经理应把候选方案至少分成四档：人工或现有流程、规则与传统自动化、带模型的固定工作流、能自主选择步骤和工具的 Agent。
比较时使用同一批任务，不要用简单任务测试规则、再用复杂任务展示 Agent。记录每种方案的任务完成、严重错误、人工时间、端到端延迟、单任务成本和可恢复性。若固定工作流达到目标，停止增加自治程度本身就是有效产品决定。
二、把模糊目标写成任务边界
“帮我处理报销”不是可验收目标。更完整的任务卡要说明：用户是谁、触发条件是什么、输入来自哪里、完成状态是什么、哪些步骤允许自动执行、哪些结果只能形成草稿、哪些对象和用途禁止处理。
例如，一个内部报销助手可以读取当前用户上传的票据、提取字段并生成待提交草稿，但不得更改收款账户、绕过费用政策或替别人批准。若缺少费用类型、票据冲突或政策不可用，应停止并说明缺什么，而不是自行补全关键事实。
这一步与 AI 产品 PRD 的行为合同相连，但 Agent 还要额外描述每次行动造成的外部状态变化。只写最终回答，不足以验收一个会操作系统的产品。
三、工具权限按“身份—对象—动作—参数”定义
一个工具名称不能代表完整权限。“可访问日历”需要继续拆成：以谁的身份、读取还是写入、可操作谁的日历、允许哪些字段、时间范围多大、能否邀请外部人员。Microsoft 的 Agent 授权指导强调最小权限，并区分代表已登录用户的委托权限和无用户在场时的应用权限。
每个工具至少记录：
- 身份与授权来源；
- 允许的对象、动作和参数范围；
- 只读、可逆写入或不可逆写入；
- 敏感数据的输入、输出和保留限制；
- 重复调用是否安全，以及用于防止重复执行的键；
- 调用失败、部分成功和超时后的补偿动作。
不要把密钥放进提示词、公开日志或用户可见上下文。工具返回的网页、邮件和文档也不能自动当作可信指令；它们可能含有错误内容或提示注入。权限控制、内容隔离、确认和监测需要分层工作，不能依赖一句系统提示。
四、人工确认要放在产生影响之前
Anthropic 的可信 Agent 实践将工具动作分成可始终允许、需批准和阻止，并指出用户应能在执行过程中介入。对产品设计而言，确认点应靠近真正的状态变化，而不是在任务开始时用一个宽泛的“同意”覆盖后续所有动作。
通常应重点审查：外发消息、付款或退款、删除、权限和账户修改、不可逆提交、对第三方产生影响的操作，以及对象、金额、收件人或依据不明确的动作。确认界面应展示将执行的动作、目标对象、关键参数、依据和可逆性；确认人必须拥有相应权限。
人工确认也不是万能护栏。连续弹窗会让人机械点击，因此可按风险合并为计划级确认，同时保留在关键动作前暂停和随时中止的能力。对于高影响领域，还需独立的领域、隐私、安全或合规责任人，而不是把产品经理的确认当作全部审批。
五、为 Agent 循环设定停止条件
Agent 常以“计划—行动—观察—调整”循环工作。没有停止条件时，错误可能变成重复调用、费用累积、状态反复修改或不断偏离原目标。规格中至少固定：
- 最大步骤、运行时间、调用次数和费用预算；
- 同一失败允许重试几次，以及重试前必须改变什么；
- 哪些工具错误、权限拒绝或输入缺失立即转人工；
- 目标已完成如何判定，如何避免重复执行；
- 用户取消、范围改变或出现高风险信号时怎样停止；
- 部分成功后如何保存状态、补偿或回滚。
“模型认为完成”不能是唯一完成条件。应尽量用外部可核验状态，例如草稿已生成但未发送、指定记录已更新一次、返回的对象 ID 与请求一致，或审批状态仍为待确认。
六、评测既看结果，也看行动轨迹
普通问答评测只看最终文本，可能漏掉 Agent 在中间步骤访问了错误对象、使用了过大权限、重复写入或先产生影响后再道歉。固定任务集应覆盖正常、缺信息、工具失败、权限拒绝、冲突输入、提示注入、重复请求、超预算、用户取消和部分成功。
每个样例保存任务版本、模型与提示版本、计划、工具名称、参数摘要、授权身份、工具结果、状态变化、人工确认、最终结果、费用、延迟和失败类型。至少分开判断：
- 任务结果：用户目标是否在允许范围内完成；
- 行动正确性：工具、对象、参数和顺序是否正确；
- 权限安全：是否发生越权、敏感信息泄露或绕过确认；
- 循环可靠性：是否重复执行、失控重试或错误结束；
- 恢复能力：失败时能否停止、说明、接管、补偿或回滚；
- 用户控制：用户能否理解计划、确认影响、取消和纠错。
越权写入、错误付款、未经确认的外发、敏感数据泄露、无法停止或无法回滚等高风险失败应独立阻断，不能被总体完成率平均掉。可用 AI 产品评测集模板 保存逐条证据。
七、从受限发布进入持续复审
首次发布应缩小用户、工具、数据和可执行动作范围，并保留确定性流程或人工路径。上线记录要写明版本、范围、审批人、运行负责人、告警、暂停开关、回滚步骤和复审日期。发布后联合观察任务结果、人工接管、拒绝、越权尝试、重复动作、成本、延迟和用户纠错，而不是只看调用量。
NIST 的生成式 AI 风险框架把治理、测量、第三方依赖、监测和事件处理放在整个生命周期。模型、提示、工具、权限、数据源、用户范围或用途发生变化时，应触发对应切片复测；新增一个高权限工具不能沿用旧版本的发布结论。
多智能体不是默认升级路线
多智能体可以把研究、执行或复核拆给不同角色，但也增加上下文传递、授权继承、重复动作、冲突决定和故障归因问题。只有在子任务边界稳定、责任和权限可隔离、单 Agent 基线已保存，并且测试证明拆分有必要时才采用。
验收多智能体时还需保存委派原因、发送给子 Agent 的输入、子 Agent 可用工具、返回证据、合并规则和最终责任人。子 Agent 的数量、对话长度或“协作感”都不是产品价值证据。
使用边界
本文和 JSON 是产品规格框架，不是安全保证、法律意见或生产审批。具体权限、确认、日志和保留要求取决于用途、行业、地区和系统影响。真实产品应由有权的数据、隐私、安全、合规、领域和运营责任人共同决定；没有相应证据时，状态应保留为 missing 或 pending，不能补写为已验证。