企业工具调用更像一条条历史工作流路径。

EntBench-Agent 最后一个模块是工具图检索。

我觉得这是这个项目里最有创新感的一块。

前面几层做了任务合成、真实评测、失败分析。到这里,系统开始把成功运行过的工具链沉淀成图,然后用图来增强后续工具检索。

1. 背景问题

企业 Agent 的工具选择很容易漏前置和后置工具。

比如用户说:

Approve that document access request.

语义最强的工具是:

approve_permission_request

但真实工具链一般需要:

list_permission_requests
  -> approve_permission_request
  -> list_document_permissions

这里 list_permission_requests 是前置工具。

list_document_permissions 是后置验证工具。

普通语义检索很容易抓住中间动作,漏掉前后环节。

所以工具检索需要利用历史工作流经验。

2. 当前 baseline

PDF 里提到当前真实 Agent 的工具选择流程在 progressive_daily_agent.py 里。

它采用的是渐进式工具暴露:

Stage 1:领域选择
Stage 2:工具选择
Stage 3:工具执行

先让模型选业务域,比如 document、meeting、project、schedule、hr、permission。

然后暴露当前领域工具和 system 工具。

最后再暴露 selected_tools 的完整参数 schema,进入真实工具调用。

这个 baseline 已经比一次性暴露 107 个工具更稳。

但它主要依赖领域过滤和 LLM 选择,还没把历史成功工具链显式建模进去。

工具图检索就是在这个基础上继续往前走。

3. Path Mining:从成功日志里挖路径

系统真实跑 Agent 之后,会留下 task_logs

每个 stage 里都有 tool_calls_detail

Path Mining 会做几件事:

读取每个 stage 的 tool_calls_detail
抽取 observed_tool_path
扫描历史 task_logs
保留 passed stage 的工具路径
按 stage 聚合多个成功路径
统计路径长度、出现次数、来源日志
选择 shortest_solvable_path
计算 path_efficiency_score

这一步非常有意思。

系统从真实成功运行中发现可解路径,避免人工写死唯一 gold tool chain。

同一个任务可能有多条可行路径。

比如有的 Agent 先查文档再查权限,有的 Agent 先查权限请求再查文档。最终状态达成后,这些路径都可以作为成功经验。

Path Mining 会把这些经验保存下来。

4. 从路径到工具历史图

有了成功路径之后,就可以建工具历史图。

图里的节点是工具:

query_documents
get_document
list_permission_requests
approve_permission_request
list_document_permissions

边是工具调用顺序:

query_documents -> get_document
list_permission_requests -> approve_permission_request
approve_permission_request -> list_document_permissions

边权重来自成功日志里的出现频率。

如果一条边在成功任务里反复出现,它的权重就高。

这张图表达的是:企业工作流里哪些工具经常一起出现,以及它们通常按什么顺序出现。

这和语义相似差别很大。

语义相似看的是工具描述的接近程度。

历史图看的是成功任务里工具如何协作。

5. 双图检索:历史图 + 语义图

PDF 里提出双图检索。

第一张图是历史调用图。

它来自真实 Agent 成功日志,优势是能补全前置工具、后续工具和跨域桥接工具。

第二张图是语义相似图。

它来自工具名称、描述、参数 schema 的语义相似度。

比如:

list_document_permissions
check_document_permission

这两个工具语义接近,即使历史里共现很少,也可以通过语义图连起来。

最后两张图融合。

历史图负责工作流经验。

语义图负责语义泛化。

我觉得这个设计很适合企业工具冷启动。

老工具可以从历史成功路径里学习。

新工具可以先靠语义图接入。

6. 在线检索:语义 seed + PPR 扩散

在线面对一个新请求时,工具图检索可以这样跑:

用户请求
  ↓
语义检索召回 seed tools
  ↓
把 seed tools 作为 PPR 起点
  ↓
在融合工具图上扩散
  ↓
输出 Top-k 工具候选
  ↓
交给 Agent 规划和执行

比如用户请求:

approve that document access request

语义 seed 可能是:

approve_permission_request

PPR 在历史图上扩散后,会补出:

list_permission_requests
list_document_permissions
check_document_permission
get_document
query_users

这样工具候选就从单点动作变成了完整工作流相关工具集合。

7. 这个模块的创新点

我觉得这里有几个创新点。

第一,从成功任务日志里自动挖可解工具路径。

第二,把工具调用轨迹建成历史图,显式建模企业任务里的稳定工具链模式。

第三,用语义 seed 和 PPR 图传播补全前置、后续和跨域桥接工具。

第四,支持多条成功路径,让 benchmark 可以比较工具链效率。

第五,形成闭环:

Agent 评测产生日志
日志沉淀工具图
工具图增强后续工具检索
更好的工具检索带来更好的 Agent 执行

这就是我觉得它比普通工具检索更有意思的地方。

它把过去成功任务里的执行经验显式变成了图结构。

8. 小结

工具图检索把 EntBench-Agent 的前面几层全部串起来了。

数据库和工具库提供动作空间。

任务合成提供 benchmark。

真实 Agent 评测产生轨迹。

Path Mining 从轨迹里挖成功路径。

工具图把成功路径沉淀成检索先验。

最后 PPR 扩散把这些先验用到新任务里。

这一层让系统从“评测 Agent”走向“用评测数据增强 Agent”。