产品经理的 Agent 入门
Agent 的适用场景
从任务路径、外部动作和失败风险出发，判断应该使用单次模型调用、Workflow、Copilot 还是 Agent。
「产品经理的 Agent 入门」之二
上一篇：Agent 的基本概念 · 系列入口 · 下一篇：Agent 的运行过程
Agent 的价值来自在不确定路径中继续推进任务，但这种灵活性会同时增加成本、延迟和错误路径。做 Agent 产品最常见的问题，不是选错模型，而是把原本可以确定完成的流程设计成自由度过高的系统。
先问四个问题
- 完成步骤会不会随输入和中间结果变化？
- 系统是否必须读取外部信息或执行真实动作？
- 任务是否需要跨多轮、跨页面或跨时间保存进度？
- 如果系统判断错了，用户能否发现、阻止和恢复？
前两个问题决定是否需要行动型智能，后两个决定需要多少状态与控制面。
四种方案：先选最简单的
| 任务特征 | 优先方案 | 例子 |
|---|---|---|
| 一次理解或生成即可 | 单次模型调用 | 摘要、分类、字段提取 |
| 步骤固定但有多个环节 | Workflow | 文档解析、账单清洗 |
| 路径变化，需要按结果选择工具 | Agent + Tools | 调研、需求澄清、代码修复 |
| 主流程固定，局部需要判断 | Workflow + Agent | 合同审阅、BRD 到 PRD |
多 Agent 不是第五种默认方案。它是一种后续组织方式，不是场景成立的起点。
用两个变量判断自由度
- Context 确定性：所需信息是否完整、结构化、可信；
- Workflow 确定性：步骤是否固定、可提前编排。
| Workflow 高确定 | Workflow 低确定 | |
|---|---|---|
| Context 高确定 | 程序、RPA、Workflow | 规划型 Agent |
| Context 低确定 | 检索增强 Workflow、Copilot | 研究型 Agent，加阶段门禁 |
Context 不确定时，先解决数据来源、检索、澄清和证据；Workflow 不确定时，重点设计计划、工具选择、停止条件和评审；两者都确定时，应减少模型的自主决策。
回到会议纪要生成 PRD
如果纪要格式统一、字段齐全、模板固定，Workflow 加少量模型节点已经足够。如果材料经常缺目标、指标和异常规则，系统必须判断缺口、动态追问并决定何时进入下一阶段，Agent 才真正提供价值。
即便使用 Agent，正式修改 PRD 版本和需求状态仍应由确定性接口和审批控制。
讨论技术前，先写清六项
在讨论框架前，先写清用户目标、输入、可执行动作、自主边界、成功标准和失败处理。如果这六项说不清，团队缺的通常不是框架，而是场景定义。
本篇小结
- 一次理解或生成能完成的任务，优先使用单次模型调用。
- 步骤固定、分支有限的任务，优先使用 Workflow。
- 只有当下一步确实依赖中间结果、路径难以提前穷举时，Agent 的动态判断才有价值。
- Context 不确定时先解决资料、检索和澄清；高风险动作无论是否使用 Agent，都要保留确定性规则和人工控制。
先用完成任务所需的最小自主性，再根据真实失败样本逐步开放能力。