企业工具调用更像一条条历史工作流路径。
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”。