做企业 Agent benchmark，难点在于让任务、数据、工具、评测和日志形成闭环。

前面几篇已经把 EntBench-Agent 的主要模块拆开讲了。

这篇做一个总结，记录一下我觉得最有价值的几个工程经验。

1. 企业 benchmark 要从数据世界开始

很多 benchmark 会从任务文本开始。

但企业 Agent 的任务背后有状态。

用户、文档、权限、会议、项目、日程这些实体之间必须有真实关系。

所以 EntBench-Agent 的第一步是先造企业数据库世界。

这一步看起来很底层，但它决定了后面的任务是否真实。

如果数据库只是一些散乱记录，后面很难抽出多阶段任务。

如果数据库里有业务场景包生成的链式关系，后面就能自然构造：

文档分享任务
权限审批任务
会议协调任务
项目交付任务
入职提醒任务
跨域协作任务

所以这个项目给我的第一个经验是：企业任务合成要先有企业世界。

2. LLM 要在受约束空间里生成任务

LLM 很适合把结构化 seed 写成自然用户请求。

但任务里的实体、关系、工具和目标状态都要提前约束好。

EntBench-Agent 通过 seed 做这件事。

seed 里有真实实体、关系证据、初始状态、目标状态和候选工具。

这样 LLM 的生成空间就变得很清楚。

它负责把这些材料变成自然、多阶段、可评测的任务。

任务真实性来自 seed。

任务可执行性来自工具库和 compiler。

任务自然性来自 LLM。

这个分工很稳。

3. 中间表示很重要

task_draft.json 是一个很好的中间表示。

它把 LLM 输出和最终 benchmark 文件隔开。

LLM 先输出结构化 draft。

规则门控检查 draft。

compiler 再生成 task.md 和 task.py。

这样既能利用 LLM 的表达能力，也能让最终任务文件保持稳定。

我觉得很多 Agent 工程都可以学习这个思路。

先让模型输出一个中间结构，再由规则程序编译成最终产物。

4. 门控比生成更重要

任务生成出来之后，真正决定质量的是 gate。

EntBench-Agent 里有：

规则门控
编译检查
数据库补丁
可解性验证
evaluator 检查
失败修复或过滤

这些东西看起来都很工程，但它们决定 benchmark 能否可信。

一个任务看起来合理，实际工具链跑崩，这种样本进入 benchmark 会很危险。

所以门控系统的价值在于：把任务从“自然文本”推进到“可执行、可评测、可复现”。

5. 真实执行日志是最有价值的数据

真实 Agent 跑完任务之后，会留下很多日志：

selected_domain
selected_tools
tool_calls_detail
agent_response
evaluation_result
state_checks
observed_tool_path

这些日志比 pass / fail 更有价值。

成功日志可以挖工具链。

失败日志可以打错误标签。

工具参数错误可以做 repair 样本。

工具漏选可以做 hard negative。

写状态失败可以暴露 evaluator 和任务设计的问题。

这说明 benchmark 除了打分，也可以成为训练数据生产器。

6. 失败分析要落到链路位置

失败原因要对应 Agent 执行链路。

EntBench-Agent 里可以拆成：

工具选择
参数生成
读事实
写状态
回答生成

这个拆法非常实用。

因为每一类错误都有各自的修复方式。

工具漏选要修工具检索。

参数错要修上下文继承或参数生成。

读事实错要修查询和实体 disambiguation。

写状态错要修工具调用或状态验证。

回答错要修 grounding 和输出格式。

这样失败分析才有工程价值。

7. 工具图检索把日志用起来

我觉得这个项目最有意思的闭环在工具图检索。

成功任务日志里有工具链。

工具链可以变成路径。

路径可以变成图。

图可以用 PPR 扩散补全工具候选。

这样系统就从历史成功经验里学习工具协作模式。

比如权限审批经常出现：

list_permission_requests
  -> approve_permission_request
  -> list_document_permissions

那么后面遇到类似请求时，即使语义检索只召回中间审批工具，图传播也能把前置查询和后置验证带出来。

这就是工具图检索的价值。

8. 这个项目的整体闭环

EntBench-Agent 最终形成了一条闭环：

企业数据库世界
  ↓
工具库
  ↓
seed 子图
  ↓
LLM 任务草稿
  ↓
compiler
  ↓
规则门控和可解性门控
  ↓
真实 Agent 评测
  ↓
成功 / 失败日志
  ↓
失败标签与训练样本
  ↓
工具历史图
  ↓
PPR 工具检索

这个闭环是我觉得最值得强调的地方。

它让 benchmark 从评测继续推进到改进 Agent。

9. 后续可以继续扩展的方向

后续我觉得可以继续往几个方向走。

第一，增加更多企业业务域。

比如财务、采购、CRM、法务、IT 工单。

第二，让业务 motif 更丰富。

目前已经有文档、会议、项目、HR、跨域协作，后面可以扩展成更复杂的多角色流程。

第三，把失败标签做成更稳定的数据集。

规则标签、LLM 辅助诊断、人工抽样校验结合起来，形成可复用的错误分析 corpus。

第四，把工具图检索真正接入在线 Agent。

语义 seed + PPR 扩散之后，工具候选质量应该能明显提升，尤其是前置工具和验证工具的召回。

第五，把 path efficiency 纳入评测。

同样完成任务，路径更短、工具更准、验证更完整的 Agent 应该得更高分。

10. 小结

EntBench-Agent 给我的最大启发是：企业 Agent benchmark 要同时看题目文本和背后的执行系统。

它要同时管：

数据关系
工具能力
任务生成
任务编译
可解性
真实执行
失败原因
工具链经验
检索增强

这些模块串起来，才会形成一个真正有用的企业工作流 benchmark。

这个项目的价值也就在这里：它把企业任务从“写几个例子”推进到了“自动合成、真实执行、日志反馈、工具检索增强”的完整系统。