评估 Agent 产品的 8 个问题
Job、工具、上下文、执行、决策、验证、审批与恢复。
一句话理解：评估一个 Agent 产品，不看它宣传“多智能”，而是连问 8 个问题——完成什么 Job、能调用什么工具、拿得到什么上下文、在哪里执行、如何决定下一步、如何验证、什么时候找人确认、失败如何恢复。
产品经理会在三种场合需要评估 Agent 产品：采购供应商方案、评审团队自己的设计、拆解竞品。三种场合的共同难点是——演示总是很顺利。演示里的任务是挑过的、数据是干净的、没有权限问题，也不会出错。真正决定产品能否落地的，是演示里 看不到 的部分。
本课给出 8 个问题，它们与本课程的模块一一对应，也是「产品拆解」模块统一使用的框架。
8 个问题总览
| # | 问题 | 本质在问 | 对应模块 |
|---|---|---|---|
| 1 | 它完成什么 Job？ | 价值是否具体、可验证 | 产品设计 |
| 2 | 它能调用哪些工具？ | 能作用于哪些系统，粒度与安全性如何 | 工具调用、MCP |
| 3 | 它拿得到什么上下文？ | 判断依据从哪来，是否足够、是否过量 | Context、RAG、Memory |
| 4 | 它在哪里执行？ | API、浏览器、电脑还是沙箱；本地还是云端 | 执行环境 |
| 5 | 它如何决定下一步？ | 固定流程、动态规划还是混合 | Workflow 与 Agent 模式、Harness |
| 6 | 它如何验证结果？ | 知不知道自己做成了 | 验证与错误恢复 |
| 7 | 什么时候需要人确认？ | 自主性边界与审批设计 | 权限与护栏、Agent UX |
| 8 | 失败如何恢复？ | 重试、回滚、降级与升级 | Harness、验证与错误恢复 |
逐个问题：追问什么、看什么证据
1. 它完成什么 Job？
- 追问：主要用户是谁？触发条件是什么？怎样算完成？有没有不做的事？
- 好的信号：能说出具体任务与完成标准，例如“把订单推进到退款或审批队列”。
- 危险信号：“什么都能做”“通用智能助手”，却说不出一个有基线数据的场景。
2. 它能调用哪些工具？
- 追问：工具清单是什么？哪些是读、哪些是写？参数由谁填？能不能执行任意 SQL、任意命令、任意 URL？
- 好的信号：面向任务的工具（
get_order(id)），读写分离，高风险工具单独授权。 - 危险信号：一个万能工具（
execute_sql、call_any_api），或者说不清写入能力的边界。
3. 它拿得到什么上下文？
- 追问：每次运行模型能看到什么？知识从哪里来、多久更新、有没有引用？用户权限如何影响检索结果？有没有长期记忆，用户能否查看和删除？
- 好的信号：按需加载、带引用、按权限过滤、记忆可见可控。
- 危险信号：“把所有文档都喂进去了”；无法回答“这个用户能不能看到这条数据”。
4. 它在哪里执行？
- 追问：通过 API 还是操作浏览器/桌面？代码在本地还是云端运行？有没有沙箱？网络是否受限？凭据放在哪里？
- 好的信号：优先用 API；需要执行代码时有隔离环境；凭据由系统注入而不暴露给模型（参见「三种执行方式」）。
- 危险信号：直接在生产服务器或员工电脑上以高权限运行，没有隔离。
5. 它如何决定下一步？
- 追问：流程是写死的还是模型动态决定的？有没有计划？最多跑多少步？如何防止死循环？
- 好的信号：稳定部分用 Workflow，判断部分交给 Agent；有明确的停止条件与预算。
- 危险信号：宣称“完全自主”，但说不出停止条件；或者宣称是 Agent，实际上是固定脚本。
6. 它如何验证结果？
- 追问：执行完一个动作后，它怎么确认成功？是模型自己说“已完成”，还是读回系统状态？结论有没有证据？
- 好的信号：写入后读回、代码改完跑测试、发送后检查回执 ID、结论附证据链接。
- 危险信号：“模型会自我检查”是唯一的验证手段。
7. 什么时候需要人确认？
- 追问：哪些动作会自动执行？哪些需要审批？审批时用户能看到什么？能不能修改后再执行、能不能中途接管？
- 好的信号：按风险分级的确认策略；审批界面包含证据与影响范围；支持中断与接管。
- 危险信号：只有“全部确认”与“全部自动”两个开关；审批弹窗只有“确定”按钮，没有上下文。
8. 失败如何恢复？
- 追问：工具报错怎么办？做到一半失败怎么办？能否回滚？失败时用户看到什么？有没有 Trace 可以复盘？
- 好的信号：分类处理失败、幂等与补偿设计、坦诚报告部分完成、完整 Trace。
- 危险信号：失败时仍输出“已为您成功处理”；没有运行记录。
评分表：把印象变成可比较的结论
给每个问题打 0–2 分：
| 分数 | 含义 |
|---|---|
| 0 | 没有设计，或者回答不上来 |
| 1 | 有设计，但依赖模型自觉或人工兜底，缺少机制保障 |
| 2 | 有明确机制，能给出证据（文档、演示、Trace、评测数据） |
示例：某供应商宣传的“AI 售后助手”与我们设计的「订单售后处理 Agent」对比（供应商为虚构示例）：
| 问题 | 供应商“AI 售后助手” | 得分 | 我们的订单售后处理 Agent | 得分 |
|---|---|---|---|---|
| 1 Job | “智能解答一切售后问题” | 0 | 定位退款未完成原因并推进到退款/审批队列 | 2 |
| 2 工具 | 通过数据库账号直连，模型生成 SQL | 0 | 12 个面向任务的工具，读写分离 | 2 |
| 3 上下文 | 导入全部制度文档 | 1 | 按需加载 Skill 与政策条款，带版本引用，敏感字段脱敏 | 2 |
| 4 执行 | 云端 SaaS，未说明隔离 | 1 | 独立服务账号，凭据由 Harness 注入 | 2 |
| 5 下一步 | “大模型自主规划” | 1 | Agent Loop + 确定性写入层，15 步上限 | 2 |
| 6 验证 | 无 | 0 | 写入后读回，结论证据由程序核验 | 2 |
| 7 人确认 | 所有动作都弹确认框 | 1 | 按风险分级，资金动作走审批 | 2 |
| 8 恢复 | 报错时提示“请稍后再试” | 0 | 分类重试、补偿、部分结论转人工、完整 Trace | 2 |
| 合计 | 4/16 | 16/16 |
一般经验：总分低于 8 分的产品不适合进入生产环境；任何一项在 6、7、8 上得 0 分，且涉及写入或资金动作的，应视为一票否决。
把两份评分画在同一张雷达图上，短板一目了然：
如何拿到真实答案
演示和销售材料通常只回答 1、2 两题。要回答其余问题，可以：
- 自带任务：用你自己的 10 个真实案例测试，而不是用对方准备的演示用例；其中至少放 2 个边界样本和 1 个带注入内容的样本。
- 要看 Trace：请对方展示一次完整运行记录，看每一步调用了什么、耗时多少、出错如何处理。
- 故意制造失败：断开一个数据源、给一个不存在的单号、让权限不足，观察它如何表现。
- 索取评测数据：成功率、人工介入率、单任务成本，是在什么样本上测出来的。
- 查阅官方文档：权限、数据保留、审计相关的说明应以官方文档为准，而不是以演示话术为准。
这五种方法合起来，就是把演示“水面下”的六个问题逐一捞出来：
常见误区
- “看演示效果就能判断好坏。” 演示用例经过挑选，最能暴露问题的是失败、边界与权限场景。
- “模型越强，产品越好。” 8 个问题中只有第 5 题与模型能力直接相关，其余都是 Harness 与产品设计（参见「模型与 Harness」）。
- “确认越多越安全。” 每一步都弹确认框会让用户习惯性点“确定”，反而失去保护作用。好的设计是分级确认。
产品经理检查清单
- 是否用自己的真实案例（含边界与注入样本）测试过？
- 是否看过至少一次完整的 Trace？
- 是否观察过至少一次失败场景的表现？
- 第 6、7、8 题是否都有机制级的答案，而不是“模型会注意”？
- 评分表是否由至少两人独立打分后再讨论？
练习
选一个你正在使用或考虑采购的 Agent 产品，用 45 分钟完成：
- 按 8 个问题逐条填写，并给出 0–2 分。
- 每个低于 2 分的问题，写出你要向对方追问的一句话。
- 设计 3 个“故意制造失败”的测试用例。
下一步
一个 Agent 设计得再好，也必须算得过账。下一课「商业化与 ROI」会讲定价方式、单任务成本和成功率门槛如何共同决定一个 Agent 是否值得上线。