任务完成率指标变绿，而用户却在默默受苦

你的智能体仪表盘显示任务完成率为 94%。领导层很满意。路线图获得了资金支持。然而，支持工单却在不断增加，核心用户变得沉默寡言，而那个负责观察追踪记录（traces）的工程师则一直在嘀咕情况不对劲。这两件事同时都是事实：智能体确实在完成任务；但它也为了完成一个两步就能搞定的工作，耗费了 12 分钟和 4000 个 token，反复回溯了三次，并要求用户确认一个它本可以从第一条消息中推断出来的实情。

任务完成率是一个隐藏了分布情况的二元指标。“智能体完成了任务”并不能告诉你它达成目标所走的路径，而路径才是用户实际体验的核心。完成率仪表盘在结构上无法察觉到一个缓慢、昂贵且令人恼火的智能体。它会一直保持绿色，直到用户流失。

这并不是一个可以通过更好的提示词来修补的测量差距，而是你选择测量什么而导致的“范畴错误”。完成率是最容易衡量的指标，但却是人们付费买单中最微不足道的部分。

完成是终态，而非轨迹

当团队第一次为智能体建立测量体系时，他们会问一个显而易见的问题：它完成任务了吗？这个问题会产生一个干净的数字，而干净的数字很容易放到演示幻灯片上。问题在于，智能体是通过一系列决策达到终态的，而终态会抹除这一系列过程。

两次运行都以“任务完成”结束。运行 A：智能体读取请求，调用一个工具，在 8 秒内返回答案。运行 B：智能体调用搜索工具，进行总结，再次搜索相同信息，问用户一个澄清问题，得到答案后却将其忽略，第三次调用搜索工具，并在 90 秒后返回相同的最终答案。你的完成率指标对这两者的评分完全相同。但你的用户不会。

研究智能体系统的学者对运行 B 有一个称呼：静默失败（silent failure）—— 即通过错误或浪费的过程产生正确的输出。输出通过了检查，但过程已经腐烂。因为你只对输出评分，这种腐烂会在数千次运行中隐形地累积。

解决办法是对“轨迹”评分，而不只是对终态评分。轨迹是智能体在通往“完成”的过程中产生的推理步骤、工具调用和用户交互的有序列表。它已经完整地存在于你的追踪记录中了，你只是还没有对它进行评分。

洞察完成率所不能及的四个指标

如果完成率是错误的数字，那么正确的数字是什么？这里有四个指标，每个指标都针对一类二元指标无法检测到的“痛苦”。

步骤效率，按任务类别编制预算。 并不是每个任务的成本都应该一样。“查询订单状态”的任务自然只需要一两步。而“协调三个系统并起草摘要”的任务可能需要 15 步。因此，你不需要设置一个全局的步骤上限，而是为每个任务类别设置预算，并标记出超出预算的运行。一个本该 2 步完成的工作用了 14 步，即使它“成功”了，也是一个缺陷。如果没有按类别的预算，这 14 步的运行就会隐藏在平均值中；有了它，该运行在越线的那一刻就会被标记出来。

路径质量。 单靠步骤计数是粗放的 —— 14 个高效的步骤与 14 个折腾的步骤完全不同。路径质量对轨迹的“形状”进行评分：回溯（智能体撤销或反驳早先的决策）、冗余工具调用（使用几乎相同的参数调用同一个工具）以及死循环（搜索-总结-搜索的循环，这表明停止准则较弱）。有用的是：大部分内容仅从追踪结构本身就可以计算出来，不需要 LLM 评判员。循环就是循环，重复调用就是重复调用。你可以用确定性代码检测这两者。

用户成本（User effort）。 这是团队最常忽略的指标，也是最接近用户流失的指标。它计算人类为了让智能体保持在正轨上而不得不介入的次数：智能体要求的澄清、用户发布的纠正、重试、重新措辞。一个能完成每项任务但每项任务都要让用户费心的智能体，拥有极高的完成率，却是一个极烂的产品。客户体验研究多年来一直指出，努力程度比满意度更能预测忠诚度 —— 只是智能体世界尚未将“用户成本”接入其仪表盘。

基于轨迹评分的评估分片（Eval slices）。 你的离线评估套件不应只检查最终答案。添加对路径进行断言的分片：“此类任务必须在 ≤ N 步内完成”，“此轨迹不得包含对定价工具的冗余调用”，“智能体不得询问输入中已存在的值”。这些将路径质量从你在事后复盘中注意到的事情，转变为会导致构建失败的事情。

组织裂缝：基于“盲目”数字的资金投入

这就是测量问题转化为组织问题的地方。领导层根据他们能看到的指标来拨发资金。如果唯一可见的指标是完成率，那么每个投资决策 —— 人员配置、模型预算、迁移决策 —— 都是根据一个在结构上对成本、延迟和摩擦感“失明”的数字做出的。

智能体团队知道智能体很慢且昂贵，因为他们观察追踪记录。但在季度评估中，“追踪记录感觉很糟”无法对抗那个 94% 且在持续攀升的核心数字。这种裂缝并非源于恶意或无能，而是因为衡量质量的团队和分配预算的团队看的是不同的产物，而这些产物中只有一个出现在了幻灯片上。

随着智能体变得更加自主，情况会变得更糟。Anthropic 对实践中智能体自主性的分析发现，在 2025 年底到 2026 年初之间，第 99.9 百分位的轮次持续时间几乎翻了一番，从不到 25 分钟增加到超过 45 分钟。更长的自主运行意味着每次完成包含更多的轨迹 —— 更多的回溯空间、更多的 token 消耗、更多惹恼不再关注过程的用户机会。完成率指标没有变化，但每次完成的隐性成本却增加了。一个仅根据完成率投入资金的团队，每个季度都在增加其暴露在某种失败模式下的风险，而这种模式正是他们的仪表盘设计时所忽略的。

还有一个更隐蔽的陷阱。完成率在“增加痛苦”的方向上是可被刷分的。一个询问更多澄清问题的智能体将正确完成更多任务 —— 同时也给用户带来了更多的负担。如果你过度优化可见指标，就会主动削弱不可见指标。数字上升的同时，产品其实在变烂。

在信任数字之前，先量化执行路径

务实的做法并非抛弃完成率。它是一个真实的信号 —— 一个未能完成任务的智能体比一个完成得不好的智能体更糟。关键在于不能让完成率成为孤立的指标。

一个可行的架构（借鉴自成熟团队对 智能体评估 的分层方式）分为三个层级。结果（Outcome）： 任务是否完成，最终答案是否正确。轨迹（Trajectory）： 路径的效率和形态如何 —— 步骤预算、路径质量、循环检测。精力与成本（Effort and cost）： 人力和钱包付出了多少 —— 干预次数、Token 消耗、端到端延迟。只有当这三个层级都显示为绿色时，一次运行才算“良好”。结果为绿但轨迹为红的情况，正是你试图捕捉的隐性失败。

实现这一目标的三个具体步骤：

• 在展示完成率的同一页幻灯片上，放一个非完成类的指标。 选一个 —— 用户干预次数是杠杆率最高的 —— 并赋予其同等的地位。重点不在于指标本身，而在于强制将关于预算的讨论建立在非二元逻辑之上。
• 在你的评估套件中加入轨迹断言（trajectory assertions）。 从确定性的指标开始：每类任务的最大步骤数、零冗余调用、不询问已知输入。这些指标的计算成本几乎为零，且一旦失败会引发明确警报。
• 定期复盘执行轨迹（traces），而不仅仅是分数。 每周对已完成的运行进行采样并阅读其路径。一个本该 2 步完成的任务却用了 14 步，人类在 10 秒内就能一眼看穿，但在你所有的聚合数据中却是不可见的。

完成率回答的是一个极低的标准：智能体放弃了吗？至于它是否 优秀 —— 快速、廉价、低摩擦、直接 —— 则完全取决于路径。如果你的仪表盘看不见路径，你的仪表盘就看不见你的产品。智能体正变得越来越自主，运行轨迹也越来越长，这意味着“完成”与“优秀”之间的差距每个季度都在拉大。现在就开始衡量轨迹，趁着你需要手动阅读的轨迹数量还处于可控范围内。