Agent 在线评测指标：把离线分数连接到真实用户结果

离线评测回答的是“在已知样本上表现如何”，在线评测回答的是“真实用户是否因此更快、更安全地完成任务”。两者不能互相替代。离线集可能遗漏新的用户意图，线上数据又会受流量结构、产品 UI 和外部依赖影响，因此需要一套能解释差异的分层指标。

先定义用户任务成功

不要把“模型输出了一段文本”当作成功。对于查询类任务，成功可能是用户获得了正确数据并没有再次改问；对于写操作，成功是目标状态确实改变且用户确认无误；对于高风险请求，正确拒绝同样是成功。每个主要工作流都应有业务完成信号，而不是只有聊天轮数。

把用户是否继续追问、是否点击人工帮助、是否撤销操作、是否在短时间内重复提交作为辅助信号，但不要单独依赖这些代理指标。用户不追问可能是满意，也可能是放弃。关键流程仍需通过后端状态或抽样人工复核确认。

在线仪表盘至少分三层。质量层包括任务成功率、工具参数修正率、人工接管率和用户确认后的撤销率。安全层包括越权请求的正确拒绝率、需要确认的写操作覆盖率、跨租户拒绝和敏感工具调用量。成本层包括每个成功任务的 token、工具调用数、重试数和 P95 时延。

把这些指标按工具、租户类型、模型版本和内容版本切开。总体平均值常常掩盖问题：新模型也许让低风险摘要更快，却让某个导出工具的人工接管率翻倍。只有能定位到工作流，才知道该回滚模型、修工具 schema 还是调整产品引导。

发布新 Agent 版本时，从受控用户或低风险工作流开始。预先写下扩大流量和回滚门槛，例如高风险任务的错误拒绝率、重复写入事件、P95 时延和人工接管比例。出现阈值触发时自动停止扩大，而不是等用户投诉后再分析。

灰度期间保留旧版本的对照样本。相同意图在不同版本之间的差异可以通过匿名分流或离线回放补充观察。不要为了追求更快扩大流量而跳过对照，因为 Agent 的问题通常在长尾用户输入和依赖异常时才出现。

在线监控最有价值的产物不是漂亮图表，而是新增回归样本。一次异常重试、一次错误澄清、一次用户成功纠正的参数，经过脱敏后都应进入相应的离线切片。这样离线数据集会逐渐接近真实分布，线上指标也会在下一次发布前获得更好的预防。

Agent 指标体系最终服务于决策：哪类任务可以自动化，哪类必须确认，哪个版本值得扩大，哪里应该暂停。只要指标能让团队做出这些明确选择，它就比单一模型得分更接近生产价值。

在线指标依赖一致的事件语义。一次任务至少要有开始、计划生成、每次工具调用、授权决定、用户确认、最终业务状态和人工接管事件，并共享 traceId。不要仅从网页点击或模型日志推断任务是否完成，因为一个任务可能跨页面、跨 worker 和跨异步队列。

统计时区分分母。工具成功率的分母是实际工具调用数，任务成功率的分母是已开始且可判定的用户任务，确认覆盖率的分母是所有需要确认的写操作。把不可判定任务单列出来，不能悄悄从分母中删除。否则看似提升的指标，可能只是把困难任务排除在外。

对模型版本和策略版本设置最小样本量。在样本不足时显示置信区间或“观察中”，不要据少量成功就扩大流量。每个告警都要能回到具体 trace 样本，指标只是发现问题的入口，最终仍需查看实际工具轨迹和用户结果。

指标定义本身也要版本化。修改“成功任务”的判定条件时，同时展示新旧口径一段时间，避免看起来像突然改善或恶化。仪表盘应标记模型、提示词、工具 schema 和策略的发布时间点，这样趋势变化才可以和具体发布关联，而不是在周报里凭感觉解释。

对于影响用户权益的任务，定期把自动指标与人工抽样结论对照。若两者持续偏离，优先检查埋点和判定逻辑，而不是直接相信更好看的数字。可靠的在线评测首先要保证度量对象没有被错误简化。

所有阈值和例外都应写入发布记录，便于后续复盘。

上线首周安排固定负责人查看每日异常样本，并把结论同步给模型、工具和产品负责人。没有人消费的指标不会改善系统，只有能触发具体修复和回归测试的指标才值得长期采集。