Agent 产品思维框架
一张从用户 Job 到商业价值的完整拆解清单。
一句话理解：Agent 产品思维是一条从“用户要完成什么 Job”一路推到“这门生意算不算得过账”的因果链，中间每一环——流程、能力、控制、可靠性、体验、运营——都要回答清楚，并在三个决策闸门前决定继续、收缩还是放弃。
学完前面所有模块，你掌握了大量零件：Context、RAG、工具、MCP、Skill、Workflow、Harness、Memory、执行环境、权限、验证、Evals、可观测性、UX。零件越多，越容易出现一种情况：讨论需求时每个人都在谈自己熟悉的那一块，没有人按顺序把事情想完整。
这一课不引入新概念，而是给你一张 完整的拆解清单：拿到任何业务场景，按顺序过一遍，就能得到“要不要做、做成什么样、怎么证明值得”的结论。它是 PRD 背后的思考顺序，也是评审会上的提问地图。
一张图：七层因果链
箭头的方向很重要：上层决定下层。不先定 Job，就无法判断该接哪些工具；不先想清验证方式，就不该放开自主性。很多项目的问题是从第③层开始想（“我们先接个 MCP 吧”），结果上下两头都悬空。
完整拆解清单
① 价值层
- 用户是谁？一天遇到几次？现在怎么解决？
- 触发条件是什么：人发起、事件触发还是定时？
- 完成标准能否被系统确认？
- 明确不做什么？
- 当前的人工耗时、成本、错误率基线是多少？
- 是否满足跨系统、多步骤、需要判断、最终要执行四个条件？
参见「找 Job，而不是找 Agent」「什么时候值得做 Agent」。
② 流程层
- 至少观察过几位专家、几个真实案例？
- 每一步的信息来源与判断依据是否记录下来？
- 例外路径有哪些？出现比例多少？
- 哪一步最耗时？哪一步最容易出错？
- 专家如何确认“真的处理好了”？
参见「拆解人工流程」。
③ 能力层
- 每一步属于 Reasoning、Skill、Tool 还是 Workflow？理由是什么？
- 工具是否面向任务、读写分离、返回精简？
- 模型每一步需要看到什么上下文？什么绝对不能给它看？
- 企业知识从哪里来、谁负责更新、如何引用？
- 需要记住什么：任务状态还是长期记忆？
- 通过 API、浏览器、电脑操作还是沙箱执行？
- 真的需要多 Agent 吗？为什么一个 Agent 加多个 Skill 做不到？
参见「步骤归类」「上下文五问」「什么时候需要多 Agent」。
④ 控制层
- 每一类动作的风险等级是什么？
- 哪些自动执行、哪些需确认、哪些禁止？
- Agent 以谁的身份、用什么凭据运行？数据范围如何隔离？
- 业务硬规则是否由程序强制执行，而不是只写在 Prompt 里？
- 外部文本（邮件、网页、备注）进入上下文时，如何防注入？
- 不可逆动作有没有预演、延迟执行或回滚？
⑤ 可靠性层
- 每个动作执行后如何验证？是否读回系统状态？
- 失败分几类？每类如何重试、降级、升级？
- 最多跑多少步、花多少钱就停？
- 评测集是否来自真实案例，覆盖典型、边界与对抗样本？
- 上线门槛是什么？是否包含“越权动作为 0”？
⑥ 体验层
- 用户能否看到目标、计划与当前进度？
- 结论是否附带可点击核对的证据？
- 审批时用户能否看到影响范围，能否修改后执行、中途接管？
- 交付物是聊天回复，还是可编辑、可流转的产物？
- 长任务是否支持后台运行与完成通知？
- 失败或部分完成时，用户是否知道已完成什么、还缺什么？
⑦ 运营与商业层
- 单任务成本与延迟的预算是多少？超出时怎么办？
- 每次运行是否有完整 Trace，出问题能否回答“它为什么这么做”？
- 线上失败案例如何回流到评测集？
- 定价方式与结果能否客观判定是否匹配？
- 成功率门槛是多少？当前离门槛有多远？
- 除省人力外，时效、覆盖、一致性价值如何测量？
三个决策闸门
清单不是填完就结束。在三个位置，要明确做出“继续 / 收缩 / 放弃”的决定：
| 闸门 | 位置 | 核心问题 | 不通过时怎么办 |
|---|---|---|---|
| 闸门 1：值不值得 | ①② 之后 | Job 是否具体、高频、有基线？是否真的需要 Agent？ | 改做 Workflow、Copilot 或普通功能；或缩小 Job |
| 闸门 2：能不能可靠 | ④⑤ 之后 | 高风险动作能否被验证、审批、回滚？评测成功率是否可能达标？ | 降低自主性（只诊断不执行）；补验证与回滚能力；缩小任务切片 |
| 闸门 3：算不算得过账 | ⑦ 之后 | 真实成功率下，单任务总成本是否显著低于人工？ | 优化审阅与返工成本；只处理高成功率子类；调整定价 |
闸门的价值在于 允许收缩。多数成功的 Agent 产品不是一步到位的，而是先以“只读诊断 + 人工执行”上线，积累评测数据与信任后，再逐步放开低风险写入，最后才考虑更高自主性。
这条“先收缩、再放开”的路径可以画成三级台阶：
用清单快速过一遍订单售后案例
| 层 | 订单售后处理 Agent 的结论 |
|---|---|
| ① 价值 | 售后专员定位“退款未完成”原因并推进退款；人工 40 分钟/单，每天约 200 单（示例假设） |
| ② 流程 | 专家先看退款卡点日志；四类主因（支付未到账、退货未签收、政策不符、流程卡单）；跨月失效的优惠券、活动商品的特殊规则是主要例外 |
| ③ 能力 | 8 个只读工具 + 4 个写入工具；3 个 Skill；单 Agent + 确定性写入层；按需加载政策条款 |
| ④ 控制 | 查询与低风险修正自动；退款金额、政策例外只生成审批单；打款禁止；独立服务账号 |
| ⑤ 可靠性 | 写入后读回；证据 ID 程序核验；15 步上限；250 张案例评测集，分类准确率 ≥ 90% 才上线 |
| ⑥ 体验 | 任务页展示查询进度与证据；审批卡片包含影响金额与回滚方式；失败时输出部分结论 |
| ⑦ 运营与商业 | 单任务成本预算 0.5 元；成功率门槛约 54%；完整 Trace 保留 180 天；时效价值以退款到账天数衡量 |
| 闸门结论 | 通过闸门 1；闸门 2 决定第一版不开放“优惠分摊重算”，先观察两周；闸门 3 以真实成功率复核 |
一张表就能让业务、研发、法务、财务在同一个框架下讨论，而不是各说各话。
常见误区
- “框架是写文档用的。” 它更重要的用途是评审会上的提问顺序：先问 Job，再问流程，最后才问用什么模型。
- “每一层都必须做到满分才能上线。” 闸门的意义就是允许以更低自主性、更小范围先上线，用真实数据推动下一步。
- “商业层最后再算。” 成功率门槛决定了评测集的上线标准，应在设计阶段就粗算一遍，上线后再用真实数据校准。
产品经理检查清单
把本课的七层清单当作评审模板使用，并额外确认：
- 讨论是否从第①层开始，而不是从技术方案开始？
- 三个闸门是否都有明确的结论与负责人？
- 每个“不通过”是否有收缩方案，而不是只有“放弃”？
- 清单中的每一项是否能在 PRD 里找到对应章节（参见「Agent PRD」）？
练习
选一个与订单售后无关的场景（例如“SEO 流量下滑诊断 Agent”或“销售周报 Agent”），用 60 分钟：
- 按七层清单逐层写出结论，每层 3–5 行。
- 在三个闸门处分别写下“继续 / 收缩 / 放弃”的判断与理由。
- 写一段 200 字以内的第一版上线方案：自主性到哪一级、处理哪些子类、成功率门槛多少。
延伸阅读
- Building Effective AI Agents（Anthropic）：从简单方案开始、只在必要时增加复杂度的原则。
- Measuring AI agent autonomy in practice（Anthropic）：关于 Agent 在真实使用中自主程度的研究，可作为设计自主性等级时的参考。
下一步
框架需要反复练习才能内化。下一个模块「产品拆解」会用同一套问题拆解主流 Agent 产品，第一课从「Claude Code」开始。