企业 Agent 评测最麻烦的地方在于：任务要像真的，数据要对得上，工具链还要跑得通。

我觉得这个项目挺有意思的，因为它刚好卡在企业 Agent 最难处理的一块：真实工作流。

项目叫 EntBench-Agent：企业工作流任务合成与工具图检索系统。从名字看，它像一个 benchmark 项目，但往细了看，它其实同时做了三件事：

  1. 造一个企业数据库世界；
  2. 基于这个世界自动合成多阶段任务；
  3. 用真实 Agent 运行日志反过来改进工具检索。

第一眼看上去，这像是“生成一些企业办公任务”。但实际做起来会发现，这里面坑很多。

企业任务和普通问答差别很大。普通问答里，用户问一个问题，模型给一个答案就结束。企业任务通常会跨用户、跨业务域、跨工具调用。比如一个文档权限审批，看起来只是“审批一下权限请求”，实际背后至少会涉及：

找到权限请求
确认请求人
确认文档
确认当前用户是否有审批权
执行审批
检查文档权限是否真的更新
给用户一个可解释的结果

这就让 benchmark 构造变得很麻烦。

1. 人工写企业任务的问题

如果全靠人手写任务，最直接的问题就是成本高。

写一个简单任务还好，比如：

查询某个文档的标题。

但一旦任务变成多阶段，就要同时保证很多东西成立：

  • 数据库里真的有这个用户；
  • 数据库里真的有这个文档；
  • 这个用户和文档之间真的有业务关系；
  • 任务初始状态是稳定的；
  • 目标状态可以通过现有工具达成；
  • evaluator 能检查最终结果；
  • 多阶段之间需要继承的 ID 和事实要对得上。

这时候手写就很容易累，而且容易写出看起来合理、实际跑起来报错的任务。

比如任务说：

请 Alice 审批 Bob 对 Partner Ops Launch Checklist 的编辑权限申请。

听起来很自然，但数据库里可能缺这个 permission request；也可能 Bob 申请的是 view 权限；也可能 Alice 身份并非 owner；也可能工具库里缺查询这个关系的工具。

所以这个项目从一开始就要解决一个核心问题：

任务要自然，也要真的可执行。

2. 企业工具很多，语义检索容易漏工具

第二个问题来自工具。

EntBench-Agent 里有 107 个企业工具，覆盖 system、HR、document、permission、meeting、project、schedule 等业务域。

这很接近真实企业 Agent 场景：工具很多，而且工具之间经常需要配合。

比如用户说：

帮我审批这个文档权限请求。

语义上最像的工具可能是：

approve_permission_request

但真正跑完整任务时，还需要前置和后置工具：

list_permission_requests
approve_permission_request
list_document_permissions

前面那个工具负责找到请求，后面那个工具负责验证写入结果。

如果工具检索阶段漏掉前置工具，Agent 可能难以找到 request_id。

如果漏掉后置验证工具，Agent 可能审批完就结束，实际权限状态却没检查。

所以这个项目后面做工具图检索，其实非常自然。企业工具本身就像工作流节点，工具之间有历史共现关系。成功运行过的工具链，可以反过来告诉我们：一个新任务大概率还需要哪些工具。

3. 这个项目的总体流水线

整个 EntBench-Agent 可以拆成一条比较清楚的流水线：

Pasted image 20260611122820
Pasted image 20260611122820

这里我觉得最重要的一点是：它把 LLM 放在合适的位置。

LLM 负责把结构化 seed 改写成自然、多阶段、有企业感的任务。

数据库、工具、编译、检查、评测这些环节都由规则程序兜住。

这就很像我们之前做 Agent 项目时反复遇到的经验：模型适合做语义和表达，确定性检查适合交给代码。

4. 为什么这个项目值得写成博客系列

这个项目值得整理的原因在于，它很完整。

它从数据源头开始控制任务可解性，再到任务生成、任务编译、门控筛选、真实执行、失败分析，最后还把成功轨迹沉淀成工具图。

也就是说，它形成了一个闭环：

生成任务
运行 Agent
记录轨迹
分析成功和失败
沉淀工具链经验
增强后续工具检索

这比单纯做一个 benchmark 更有意思。

一个 benchmark 如果只是出题和打分，它的价值停在评测。

EntBench-Agent 这里更像一个持续产生训练信号和检索先验的系统。任务运行一次，就能留下工具链、错误类型、参数问题、状态检查结果。这些东西后面都能继续用。

后面的几篇，我会按这条流水线一层一层拆。