Agent Product 101｜09｜Product Metrics：衡量任务结果

Agent Product 的指标不能只看模型命中率或消息数，而要衡量任务是否被正确接收、推进、恢复、交付并被用户接受。

核心结论

Agent Product 的指标体系不能停留在 DAU、消息数、token、模型准确率或点赞率。Agent 的产品价值来自“任务是否完成”，所以指标要覆盖任务被提出、被理解、被执行、被恢复、被交付、被验收的完整链路。

对产品经理来说，这一章的关键收益是：你会把 Agent 指标从“用户有没有聊”升级为“用户有没有把真实工作交给 Agent，并持续愿意委托”。这能帮助团队避免一个常见陷阱：产品看起来很热闹，消息很多，但用户并没有完成更多任务。

一个更适合 Agent 产品的指标框架：

层级	关注问题	典型指标
Adoption	用户是否开始委托任务？	任务创建数、首次成功任务、活跃委托用户
Understanding	Agent 是否正确理解任务？	澄清率、需求修改率、理解错误率
Execution	任务是否被推进？	启动率、完成率、平均耗时、阻塞率
Control	用户是否在正确节点参与？	授权通过率、审批耗时、接管率
Recovery	失败能否被挽回？	重试成功率、回滚率、失败恢复时间
Outcome	结果是否被接受？	验收率、发布率、PR merge 率、客户问题解决率
Economics	单位价值是否健康？	每成功任务成本、人工节省时间、返工成本

从真实产品看 Product Metrics

v0、Replit Agent、Lovable 的核心指标不应只是生成次数，而应关注用户是否从 prompt 走到可预览项目、是否继续迭代、是否发布、是否回来修改。对 app builder 来说，“生成了一个页面”只是中间过程，“用户完成可用产品/原型”才是结果。

Claude Code、Cursor、Codex、GitHub Copilot coding agent 的指标不能只看代码行数或建议接受率。更有意义的是：issue 是否被解决、PR 是否被创建并合并、测试是否通过、review 修改量是否下降、开发者是否愿意把更复杂的任务交给 Agent。

Slack 中的 Agent 应关注协作结果：thread 是否被总结并产生决策、workflow 是否被推进、人工等待时间是否减少、通知是否有效而不过载。

Copilot Studio、Agentforce 的企业 Agent 则要连接业务指标：工单解决时间、销售跟进质量、流程自动化成功率、合规审计通过率、人工升级比例。企业不会长期为“AI 使用量”付费，而会为流程结果和成本改善付费。

产品模型：从漏斗到闭环

1. 委托漏斗：用户是否敢交任务？

Agent 产品的第一层不是聊天活跃，而是委托意愿。PM 应区分“随便问问”和“交付真实任务”。一个用户每天问十个问题，未必比一个用户每周让 Agent 完成一次关键任务更有价值。

漏斗阶段	关键问题	指标示例
发现能力	用户是否知道 Agent 能做什么？	入口点击率、模板使用率、示例转化率
创建任务	用户是否愿意提交真实需求？	任务创建率、brief 完成率
授权/补材料	用户是否愿意提供必要上下文？	授权通过率、材料补充率
启动执行	Agent 是否真正开始工作？	启动率、排队放弃率
交付验收	用户是否接受结果？	验收率、修改后验收率
复用委托	用户是否再次使用？	重复任务率、复杂任务占比

2. 任务质量：结果是否真的有用？

任务完成率容易被虚高：Agent 说“完成了”不等于用户接受。PM 应把完成拆成系统完成、用户验收、业务生效三个层次。

完成层次	含义	示例
系统完成	Agent 产出了某个结果	生成文档、创建 PR、更新字段
用户验收	用户认为结果可用	接受草稿、批准发布、merge PR
业务生效	结果带来真实变化	客服解决、销售推进、部署上线

3. 控制质量：人机协作是否高效？

Agent 产品不是越自动越好。PM 需要衡量控制点是否放对：该自动的是否自动了，该确认的是否确认了，该升级的是否升级了。

指标	好信号	坏信号
授权通过率	用户理解并愿意授权	权限请求太宽或时机不对
审批耗时	高风险动作被及时处理	审批文案不清或通知失败
接管率	用户能在需要时接管	Agent 频繁跑偏或控制点太少
取消率	用户及时止损	任务理解差、进度不可见
回滚率	系统支持恢复	高风险动作质量不稳定

4. 失败质量：失败是否可学习？

Agent 产品一定会失败。指标不应只统计失败率，还要记录失败原因、用户是否恢复、恢复后是否成功、失败样本是否进入评估集。

产品判断表：不同 Agent 的北极星指标

Agent 类型	不建议作为北极星	更好的北极星候选
写作/办公 Agent	消息数、生成字数	被采用的草稿数、节省编辑时间
Coding Agent	代码行数、建议次数	解决 issue 数、PR merge 率、测试通过率
App Builder	生成页面数	发布项目数、可用原型完成率、迭代留存
客服 Agent	回复量	一次解决率、升级减少、客户满意度
销售 Agent	自动触达数	有效跟进率、商机推进率、CRM 质量
企业流程 Agent	workflow run 数	流程完成率、人工耗时下降、合规通过率

反例与误区

误区一：用聊天产品指标衡量 Agent

消息数高可能意味着用户困惑、Agent 反复澄清或任务失败。Agent 的目标是完成任务，不是让用户多聊天。

误区二：只看模型指标

模型评测分数提升不一定带来产品结果提升。权限、上下文、工具、工作流、信任体验都会影响最终任务成功。

误区三：只统计 happy path

如果指标只看成功任务，会看不到权限不足、用户放弃、审批卡住、失败不可恢复等关键问题。PM 必须把放弃、阻塞、重试、回滚纳入漏斗。

误区四：忽略单位经济

Agent 可能完成任务，但成本过高：模型调用、工具执行、人工审核、失败返工都要算进来。尤其在企业场景，单位成功任务成本决定产品能否规模化。

设计原则

1. 以任务为最小指标单位

把一次 Agent 工作抽象成 task/job/workspace，而不是 message。只有这样，才能衡量从创建到验收的完整链路。

2. 区分“完成”和“被接受”

系统完成率用于看执行稳定性，用户验收率用于看产品价值，业务生效率用于看商业结果。三者不能混为一谈。

3. 把人类控制点纳入指标

授权、审批、接管、修改、拒绝不是噪音，而是 Agent 产品的核心交互。它们能告诉 PM 信任机制是否有效。

4. 让失败原因可分类

至少要区分：理解错误、上下文不足、权限不足、工具失败、外部系统失败、用户中途改变、结果质量差、风险过高。没有分类，就无法改进。

PM 检查清单

当前北极星指标是否代表真实任务结果，而不是使用热闹程度？
是否有 task/job/workspace 级别的数据模型来串联完整漏斗？
是否区分系统完成、用户验收和业务生效？
是否能看到用户在哪一步放弃：创建、授权、等待、审查还是发布？
是否记录失败原因，并能回流到评估和产品改进？
是否衡量权限、审批、通知、接管等控制点的效率？
是否计算每个成功任务的模型、工具和人工成本？
是否能按用户类型、任务类型、风险等级拆分指标？

小结

Product Metrics 的本质是把 Agent 的价值从“生成了多少内容”转成“完成了多少真实任务”。PM 要建立从委托、执行、控制、恢复到验收的指标闭环，才能知道 Agent 是否真的进入用户工作流。

下一篇进入 Evaluation：指标告诉我们线上发生了什么，评估系统则帮助团队在发布前和发布后判断能力是否可靠。