Agent Product 101｜10｜Evaluation：评估真实产品表现

Evaluation 在 Agent Product 中不是单次离线 benchmark，而是围绕真实任务、工具调用、人工审核、失败恢复和业务结果建立持续评估系统。

核心结论

Evaluation 在 Agent Product 中不是“跑一个模型 benchmark”，而是持续判断 Agent 是否能在真实产品语境中可靠完成任务。评估对象不只有模型回答，还包括任务理解、工具调用、权限请求、状态推进、人工协作、失败恢复和最终业务结果。

对产品经理来说，这一章的关键收益是：你会把 Evaluation 从工程团队的离线测试，转化为产品迭代的质量系统。没有评估，Agent 产品只能靠感觉上线；有了评估，团队才能知道一次模型升级、prompt 调整、工具改造或权限策略变化，到底让产品变好还是变坏。

Agent 评估要从“答案对不对”扩展到“任务有没有被正确完成”：

评估对象	要回答的问题	例子
任务理解	Agent 是否理解目标、范围、约束？	是否把“只改文案”误解成“重做页面”
计划质量	计划是否合理、可执行、风险可控？	是否先读文档再改代码
工具使用	工具是否选对、参数是否合理、结果是否验证？	是否在写入 CRM 前查对客户
权限与控制	是否在正确节点请求授权或审批？	是否在发送邮件前暂停确认
产物质量	输出是否满足验收标准？	PR 是否通过测试，报告是否可用
恢复能力	失败后是否能解释、重试、回滚？	工具失败后是否保留进度
业务结果	是否带来真实价值？	工单是否解决，商机是否推进

从真实产品看 Evaluation

Claude Code、Cursor、Codex、GitHub Copilot coding agent 的评估不能只看“生成代码是否看起来合理”。更完整的评估应包括：是否理解 issue、是否选择正确文件、是否修改最小范围、是否通过测试、是否产生可 review 的 diff、是否避免引入安全或性能问题。

Replit Agent、v0、Lovable 的评估要关注可用性：生成的应用是否能运行、页面是否符合用户意图、预览是否正常、修改是否保留原有设计、发布前是否有明确确认。

Copilot Studio、Agentforce 的企业 Agent 评估要进入业务流程：是否遵守角色权限、是否正确使用连接器、是否更新了正确对象、是否触发了正确审批、是否留下审计记录。

Slack 中的 Agent 评估还要考虑多人协作：总结是否遗漏关键决策、通知是否打扰过多、workflow 是否推进到正确负责人、团队成员是否能理解 Agent 的动作。

产品模型：三层评估体系

1. 离线评估：发布前的基本质量门槛

离线评估用于在上线前验证常见任务、边界场景和高风险样本。它适合回答：“新版本是否在已知问题上退步？”

PM 要参与定义评估集，而不是只交给工程。评估集应来自真实用户任务、失败案例、高价值场景和风险场景。

样本类型	为什么重要	示例
高频任务	影响大多数用户体验	总结会议、写邮件、修小 bug
高价值任务	直接影响付费和留存	生成可发布页面、完成销售跟进
高风险任务	错误成本高	发送客户邮件、部署生产、删除数据
历史失败样本	防止重复犯错	曾经误读需求、越权访问、工具调用失败
边界样本	检查鲁棒性	信息不足、指令冲突、外部系统异常

2. 人工审核：把判断标准产品化

很多 Agent 任务没有简单的标准答案，需要人类评价。PM 应把“好结果”的标准写清楚，避免 reviewer 只凭感觉打分。

人工审核不一定要求全量人工。可以对高风险任务、低置信任务、新功能任务、抽样任务进行 review。关键是把审核结果结构化：哪里错、为什么错、影响多大、是否可恢复。

审核维度	低分表现	高分表现
目标匹配	答非所问或过度发挥	紧扣目标和约束
事实/证据	编造来源或无法追溯	引用清晰，可验证
行动正确性	调错工具、改错对象	工具选择正确，影响范围清楚
风险控制	未请求必要确认	在高风险节点暂停并解释
可交付性	结果仍需大量返工	可直接采用或少量修改
可恢复性	失败后无下一步	提供重试、补充、回滚路径

3. 线上评估：用真实行为校准质量

离线评估无法覆盖所有真实场景。线上评估要结合产品指标、用户反馈、人工抽检和失败样本回流。它适合回答：“真实用户是否接受结果？失败发生在哪里？哪些场景需要优先改？”

产品判断表：该用哪种评估方式？

场景	推荐评估方式	原因
模型或 prompt 小改动	离线回归评估	快速发现已知任务退步
新工具上线	工具调用评估 + 人工审核	需要验证选择、参数和副作用
高风险动作开放自动化	红队样本 + 审批链路测试	必须验证越权、误操作和恢复
企业客户定制 Agent	业务样本评估 + 客户 SME 审核	判断标准依赖行业和流程
长期任务系统	端到端任务评估	需要覆盖排队、恢复、通知、验收
线上质量波动	抽样 review + 指标分解	找到具体失败环节

反例与误区

误区一：只用通用 benchmark 判断产品质量

通用 benchmark 能反映模型能力，但不能代表你的产品任务。用户不会因为模型在公开评测上得分高，就接受一个改错客户记录或无法回滚的 Agent。

误区二：只评估最终回答

Agent 产品的失败可能发生在中间：误解任务、拿错上下文、请求过宽权限、调用错工具、没有等待审批。只看最终回答，会漏掉真正需要改的产品环节。

误区三：把人工评分做成主观投票

如果没有明确 rubric，同一个结果不同 reviewer 可能给出完全不同判断。PM 需要把验收标准、风险等级和错误类型定义清楚。

误区四：评估集长期不更新

Agent 产品上线后会出现新的任务、新的失败、新的用户群体。评估集如果不从线上样本回流，很快就会和真实产品脱节。

设计原则

1. 用真实任务定义评估，而不是用模型能力倒推产品

先问用户要完成什么任务，再定义成功标准。不要因为某个模型擅长某类回答，就把它包装成产品价值。

2. 评估完整链路，而不是单点输出

端到端评估应覆盖：输入理解、上下文选择、工具动作、权限控制、状态推进、产物质量、用户验收和失败恢复。

3. 把失败分类变成改进入口

每个失败样本都应标注类型：理解错误、上下文不足、工具失败、权限策略问题、产品控制点缺失、模型质量问题、外部系统问题。不同失败需要不同团队解决。

4. 评估要服务发布决策

Evaluation 不是为了生成报告，而是为了决定：能不能上线、上线到哪些用户、哪些能力需要灰度、哪些场景必须人工审核、哪些指标需要重点观察。

5. 线上样本要回流到离线评估

高频失败、重大事故、用户拒绝的结果、人工接管样本，都应该进入评估集。这样产品每次迭代都会减少已知错误，而不是反复踩坑。

PM 检查清单

是否有基于真实用户任务的评估集，而不只是通用 benchmark？
评估样本是否覆盖高频、高价值、高风险、历史失败和边界场景？
是否定义了清晰的人工审核 rubric？
是否评估工具调用、权限请求、状态推进和恢复路径？
每次模型、prompt、工具或产品策略变化前，是否有回归评估？
线上失败样本是否能回流到评估集？
评估结果是否能支持发布、灰度、回滚和人工审核策略？
是否能区分模型问题、产品设计问题、工具问题和数据问题？

小结

Evaluation 的本质是让 Agent 产品有持续质量系统。PM 不需要亲自实现评测平台，但必须定义真实任务、成功标准、错误分类和发布门槛。只有这样，Agent 产品才能从“看起来能用”走向“可持续可靠”。

下一篇进入 Observability：评估需要样本和证据，而生产环境中的证据来自 trace、state、log、audit 和用户行为。