Agent 失败之后，最有价值的是知道它错在工具、参数、事实、写状态还是回答。

EntBench-Agent 的第六层是失败原因标注和训练数据反馈。

我觉得这一层很值得写，因为它把 benchmark 的评测结果继续往前推进了一步。

普通 benchmark 往往给一个 pass / fail。

EntBench-Agent 这里更关心失败原因。

因为只有知道失败原因，后面才能把失败轨迹转成 hard negative、参数修复样本和自我纠错样本。

1. 当前的轻量失败标注

系统已经能从评测结果里打一些基础标签。

比如：

TOOL_MISSING_REQUIRED
TOOL_FORBIDDEN_CALLED
READ_MISSING_FACT
READ_WRONG_FACT
WRITE_NO_EFFECT
WRITE_WRONG_TARGET
WRITE_WRONG_VALUE
CONTEXT_LOSS

这些标签可以直接从日志字段和 evaluator 结果里得到。

比如 required tool 漏了，就打 TOOL_MISSING_REQUIRED。

比如 fill_blank 期望是 doc000456，Agent 回答了 doc000789，就打 READ_WRONG_FACT。

比如 state_check 期望一条记录，但实际 count 为 0，就打 WRITE_NO_EFFECT。

这类标签虽然比较粗，但已经能把失败拆开。

2. 为什么粗粒度标签还要继续细分

企业 Agent 的失败经常发生在多个层面。

比如同样是权限审批失败，原因可能差别很大：

Agent 选工具时漏掉 approve_permission_request
Agent 找到了 request，但第二阶段用了错的 request_id
Agent 审批成功，但权限记录没生成
Agent 工具都调对了，最终回答写错 request_id

这些都叫失败，但修复方式差别很大。

所以后续需要更细的错误体系。

PDF 里把错误拆成几个层级：

工具选择错误
参数生成错误
读事实错误
写任务错误
回答生成错误

我觉得这个拆法很合理，因为它对应了 Agent 执行链路上的各个位置。

3. 工具选择错误

工具选择错误发生在 selected_tools 阶段。

常见标签包括：

TOOL_MISSING_REQUIRED
TOOL_FORBIDDEN_CALLED
TOOL_WRONG_DOMAIN
TOOL_REDUNDANT_NOISY
TOOL_ORDER_RISK

比如任务要求审批权限，Agent 选择了：

list_permission_requests
get_document

但漏掉：

approve_permission_request

这就是缺失关键工具。

这种失败适合作为工具检索 hard negative。

正样本是：

list_permission_requests
approve_permission_request

负样本可以包含：

get_document

模型以后看到类似任务，就要更重视审批工具。

4. 参数生成错误

参数错误发生在工具选对之后。

比如 Stage 1 查到了：

request_id = req000123

Stage 2 用户说：

Approve that request.

Agent 调用：

approve_permission_request(request_id="req000789")

工具没选错，但参数用了另一个 request。

这类错误可以标成：

PARAM_WRONG_ENTITY_ID
CONTEXT_LOSS

它适合构造成参数修复样本：

{
  "conversation_context": "Stage 1 found request_id=req000123",
  "user_query": "Approve that request.",
  "wrong_call": {
    "tool": "approve_permission_request",
    "arguments": {
      "request_id": "req000789"
    }
  },
  "target_fix": {
    "tool": "approve_permission_request",
    "arguments": {
      "request_id": "req000123"
    }
  }
}

这个数据对训练 repair policy 很有用。

5. 读事实错误和写状态错误

读事实错误主要看 fill_blanks。

常见情况：

没找到事实
找错事实
找到了错误实体
实体对了但字段错
目标描述本身有歧义

比如工具返回：

document_id = doc000456
title = Partner Ops Launch Checklist

Agent 回答：

document_id = doc000789

这就是读错事实。

写状态错误主要看 state_checks。

比如期望：

PermissionRequest(req000123).status = approved
DocumentPermission(doc000456, user031).permission = edit

实际结果：

PermissionRequest 状态变成 approved
DocumentPermission 记录缺失

这就是部分写入成功。

它比简单失败更有信息量，因为我们知道写操作完成了一半。

6. 回答生成错误

还有一类错误发生在最终回答。

工具调用可能都对，数据库状态也对，但 Agent 的自然语言回答漏掉关键事实，或者把工具结果写错。

比如工具返回：

request_id = req000123

Agent 回答：

The pending request is req000789.

这类错误可以标成：

RESPONSE_WRONG_FACT
RESPONSE_MISSING_FACT
RESPONSE_HALLUCINATION
RESPONSE_FORMAT_ERROR

它提醒我们：评测 Agent 时，工具执行和最终回答都要看。

7. 成功和失败数据怎么用

成功轨迹可以变成正样本。

比如：

用户请求：Approve the pending edit request.
成功工具链：
list_permission_requests -> approve_permission_request -> list_document_permissions

这个可以训练工具召回模型，也可以训练工具链规划模型。

失败轨迹可以变成 hard negative。

比如：

用户请求：Approve the pending edit request.
错误工具链：
list_permission_requests -> get_document
失败原因：
TOOL_MISSING_REQUIRED

这就能告诉模型：类似任务里 get_document 可能有辅助价值，但审批工具才是关键动作。

失败轨迹还可以变成诊断数据：

{
  "failure_label": "READ_WRONG_FACT",
  "expected": "doc000456",
  "actual": "doc000789",
  "target_diagnosis": "The agent selected a similar but wrong document.",
  "target_repair": "Use the permission request's document_id before answering."
}

8. 三层标注方案

PDF 里提到一个三层标注方案。

第一层是规则高置信标注。

直接根据日志字段判断，稳定、成本低。

第二层是 LLM 辅助诊断。

把失败 stage 的结构化证据交给 LLM，让它判断更细原因，并给修复建议。

第三层是人工抽样校验。

每类标签抽 20 到 50 个样本，检查标签准确性，估计噪声率，再反过来修规则和 prompt。

我觉得这个方案很实际。全量人工标注太贵，全靠 LLM 又容易飘，三层结合比较稳。

9. 小结

失败分析这层把 benchmark 的输出变成训练信号。

成功数据告诉我们怎样的工具链能跑通。

失败数据告诉我们哪里容易错，以及应该怎么修。

这样 EntBench-Agent 除了评测 Agent，也在持续积累改进 Agent 的材料。