本文探讨了在Agent环境中，如何通过建立三层评估体系（任务完成、业务价值、用户信任）来确保产品成功而非仅仅完成任务。这一体系帮助PM从简单的完成率提升到更全面的采纳率和信任度，从而避免‘跑通了但没人用’的问题。
--91likeyou---
很多团队上线Agent之后，第一个问题不是”用户喜不喜欢”，而是——它到底做对了没有？
这个问题比听起来难得多。
Agent跑完了，日志是绿色的，没有报错。但用户投诉说结果不对。开发说“模型输出就是这样”，业务说“反正没达到预期”，PM夹在中间，不知道该怎么定义“对”。
这就是Agent评估的核心困境：传统软件的测试逻辑在Agent面前基本失效。
传统测试为什么失效？
传统软件的测试逻辑是确定性的：输入A，期望输出B，一致就过，不一致就失败。
Agent不一样。同样的输入，每次输出可能都不同。Agent可能走了不同的推理路径，调用了不同的工具组合，最终得到了“语义上正确但字面上不同”的结果。你很难用一个assert语句判断它对不对。
更复杂的是，Agent的“正确”有多个层次：
- 它有没有按预期完成操作？（任务层）
- 它的输出有没有推动业务目标？（业务层）
- 用户有没有信任并采纳它的结果？（信任层）
这三层是独立的。任务层通过≠业务层有价值，业务层有价值≠用户层会信任。
PM如果只盯着任务层，就会做出“Agent跑通了但没人用”的产品。
第一层：任务评估——Agent做完了吗？
这是最基础的一层，也是大多数团队唯一在做的一层。
核心指标：
- 完成率：Agent是否执行完了整个任务流程，没有中途崩溃或放弃
- 步骤准确率：Agent执行的每一步是否符合预期路径（尤其是工具调用顺序）
- 幻觉率：Agent是否编造了不存在的信息、URL、数据
PM的关注点：
不要只看成功/失败的二元结果。要看失败在哪一步。
一个典型的Agent任务可能有8个步骤，Agent在第7步失败。如果你只记录“任务失败”，你永远不知道问题出在哪。正确的做法是对每个节点打标，形成“失败热力图”——哪个节点失败频率最高，那里就是需要优先优化的地方。
一个容易忽视的指标：重试率。
Agent失败了，它会重试吗？重试几次才成功？重试率高说明系统不稳定，即使最终成功，用户体验和成本都在悄悄劣化。
第二层：业务评估——Agent做对了吗？
任务完成只是手段，业务结果才是目的。
这一层很多PM做不好，原因是把任务指标当成了业务指标。
举个例子：你的Agent负责帮用户写营销文案。任务指标是“生成成功率”，但业务指标应该是“用户采纳率”——用户有没有实际用这篇文案，有没有修改后发布，有没有带来点击转化。
3个核心业务指标框架：
1. 采纳率（Adoption Rate）
Agent给出了结果，用户有没有直接使用？有没有大幅修改后才使用？大幅修改意味着Agent的输出和用户真实需求之间有偏差，即使任务“完成”了，业务价值也打折扣。
参考阈值：如果采纳率低于60%，基本说明Agent的输出质量有系统性问题，需要重新审视提示词设计或工具配置。
2. 人工干预率（Human Intervention Rate）
在有人机协作节点的流程中，有多少任务需要人工介入修改或推翻？
这个指标直接反映Agent的“可信度”。如果50%的任务需要人工修正，这个Agent实际上是在给人工审核员制造工作量，而不是减少它。
3. 下游影响指标（Downstream Impact）
Agent的输出对后续业务流程的影响——客服Agent解决了问题，用户还会再来投诉吗？数据分析Agent给出了建议，决策者有没有按它的建议行动？
这一层是最难量化的，但也是最能证明Agent价值的。PM需要主动设计好埋点，把Agent的输出和下游行为串联起来。
第三层：信任评估——用户相信Agent吗？
这是最容易被忽视、但长期来看最重要的一层。
Agent产品和普通工具产品有一个根本区别：用户对Agent的信任是动态的，而且是累积性的。
用户用了几次Agent，发现它偶尔会说错，他就会开始对所有结果都怀疑。一旦信任崩了，用户会绕开Agent，或者把Agent的每个输出都人工验证一遍——这时候效率增益就归零了。
如何量化信任？
1. 重复使用率（Return Rate）
用户用了一次Agent之后，有没有再用？如果用户用了一次就不用了，大概率是信任出了问题，不是功能出了问题。
2. 确认行为分析
在Agent给出建议之后，用户有没有去独立验证？比如Agent推荐了一个供应商，用户有没有立刻去搜索这个供应商的评价？
如果用户总是在Agent给完结果后立刻去外部验证，说明他们对Agent的信任度很低，Agent只是一个“触发他们思考”的工具，而不是“可以依赖的判断者”。
3. 用户反馈颗粒度
“这个结果不对”和“这个结果不够准确”是两种完全不同的反馈。前者是信任危机，后者是质量优化。PM要建立足够细颗粒度的反馈收集机制，区分这两类信号。
把3层评估落地：PM的操作建议
第一步：给每个Agent定义评估矩阵
不同Agent的评估侧重不同。一个内部效率工具，任务层权重更高；一个面向C端用户的推荐Agent，信任层权重更高。在上线前就定义好这三层各自的核心指标和合格阈值。
第二步：设计评估闭环，而不只是监控面板
很多团队有监控，没有闭环。指标跌了，没有人知道该怎么处理，也没有人去追溯原因。PM需要把“指标异常→归因分析→优化措施→效果验证”做成标准流程，而不是事后救火。
第三步：用「黄金数据集」做基准测试
挑选100-200个有代表性的真实案例，人工标注正确答案，形成黄金数据集。每次迭代之后，用这个数据集跑一遍，看三层指标有没有退化。
这是防止“这次优化修好了A问题但破坏了B能力”的最有效方法。
第四步：区分「能力问题」和「设计问题」
评估结果差，原因可能是两类：一是模型能力本身的限制（换模型或微调可以解决），二是产品设计问题（任务拆分不合理、提示词设计有歧义、工具配置有缺陷）。
PM需要有能力区分这两类原因。把设计问题甩给“模型不够好”，是Agent产品最常见的甩锅陷阱。
一个现实提醒
评估体系不是一次性建好就完事的。
Agent的能力在进化，用户的预期在升高，业务场景在变化。三个月前的评估标准，三个月后可能已经过时。
好的PM会把评估体系本身也纳入迭代计划——定期review评估指标是否还有效，是否需要加新维度，是否有新的数据可以利用。
Agent做完了任务，不等于Agent做对了事。做对了事，不等于用户信任它。
这三层差距，就是Agent产品经理存在的价值。
题图来自 Unsplash，基于CC0协议
🔥 热词：#agentmanager · #agentpath