图中界面、人物和记录为流程示意，不对应真实客户、真实工单或实际运行数据。

人工接管率降低，不一定说明 Agent 更好用了。系统可能解决了更多问题，也可能少报了应该转交的风险；接管率上升也未必是退步，可能只是新增了明确的权限边界。指标必须能解释接管为什么发生、交给谁、之后发生了什么。

先把人工接管定义为工作流事件：自动化流程因为规则、证据缺口、执行失败或明确请求，把任务责任移交给人工角色。模型说“建议转人工”只是候选判断，进入队列、有人认领与完成处理是后续不同状态。

先记录从触发到处理的链路

最小事件链可以包含触发接管、进入队列、认领、首次人工处理和结果确认。每个事件保留任务标识、时间、角色和状态。触发原因还需要规则或模型版本，方便解释版本变化后的指标差异。

时间应尽量来自服务端，不能用模型生成的文字时间戳。对于异步队列，发生时间与采集时间可以分别记录，避免消息延迟被算成人工等待。重复投递的事件按稳定标识去重，不把一次接管累计多次。

原因要能指导改进

原因可以从实际流程出发：权限边界、证据不足、用户要求、业务例外、工具失败、输出校验失败。允许记录一个主要原因和必要的辅助原因，但分类说明应固定版本。

“模型不确定”太宽。它可能是缺字段、知识未覆盖、工具不可用，也可能是分类本身困难。保留直接证据或受控引用，后续审核才能知道应该补知识、修工具，还是维持人工处理。

规则强制接管与模型自主建议接管也应分开。前者体现既定边界，后者需要检查建议是否合理。不能把符合安全边界的正常交接全部算成自动化失败，否则团队会被指标推向取消必要控制。

交接材料的质量值得单独测量

接管事件发生，并不表示人工能继续工作。可以记录证据包是否包含原始目标、已执行动作、工具结果、未决项和下一责任范围。这里检查的是材料是否真实可用，不是附件数量。

摘要中出现“已检查”时，应能回到实际查询事件；只有计划没有执行的步骤，不能作为已完成工作交接。工具失败也应保留，否则人工会在缺少上下文时重复排查。

可以让接管人标记是否需要补问基础信息、是否重复查询以及材料中的关键错误。这些反馈帮助衡量自动化有没有节省人工时间，但不要让模型自评交接包完整，就当作真实人工收益。

计算之前明确分母

接管率可以定义为发生接管的唯一任务数除以进入该自动化范围的唯一任务数。需要明确统计窗口、任务入口和排除项。一个任务多次接管，在任务级比率里只计一次；多次流转可以作为独立过程指标分析。

等待时长也要写清起止点。例如从进入队列到认领，与从触发到首次有效处理，回答的是不同问题。仅有认领事件不等于已经开始有效处理，不应拿它替代响应质量。

一个示意事件如下：

{
  "task_id": "task-42",
  "handoff_id": "handoff-42-1",
  "event": "queued",
  "reason": "evidence_missing",
  "policy_version": "handoff-v2",
  "evidence_package_ref": "package-42"
}

真实系统还需遵循权限和数据保留规则。报表只保留必要维度，审核原文通过受控引用完成，不把敏感内容复制进分析表。

低接管率需要和漏接管一起看

抽样检查没有接管的任务，尤其是工具失败、权限变更和证据冲突的任务，判断是否存在应该转交却继续自动处理的情况。只审核已经接管的样本，无法发现漏接管。

接管后的结果也有多种：人工完成、等待用户、转其他团队、确认无需操作。不能把所有进入人工队列的任务都算成人工解决，更不能默认人工处理就代表首轮分类错误。

上线评估可以按原因、渠道、任务类型和版本切分，再结合交接材料质量与任务结果判断改进方向。人工接管不是自动化的耻辱标签，它是责任转换。把这次转换记录完整，团队才能知道哪些问题适合继续自动化，哪些边界应该保留。