工具库的价值在于，它让数据库世界真的能被 Agent 操作。

有了企业数据库世界之后，还需要一套工具库。

这一步很关键。因为 Agent 看到的世界来自工具暴露出来的能力。

EntBench-Agent 里定义了 107 个企业工具，覆盖 system、HR、document、permission、meeting、project、schedule 等类别。

我觉得这套工具库有两个价值。

第一，它把数据库读写能力包装成企业 Agent 能调用的 API。

第二，它给后面的任务合成和工具检索提供了明确的动作空间。

1. 工具要和业务表一一对应

工具库和数据库世界是配套的。

文档域有 Document、DocumentVersion、DocumentPermission、DocumentShare 等表，所以工具里自然会出现：

create_document
get_document
update_document
query_documents
create_document_version
list_document_versions
grant_document_permission
revoke_document_permission
create_document_share
download_document
list_document_downloads

权限域有 PermissionRequest，所以工具里会有：

request_document_permission
list_permission_requests
approve_permission_request
reject_permission_request
get_user_permission_summary

会议域有会议室、预订、会议、参会人、纪要，所以工具会覆盖：

list_rooms
book_room
check_room_availability
create_meeting
list_meetings
add_meeting_attendee
create_meeting_minutes
share_meeting_minutes
grant_meeting_permission

项目域和日程域也一样，会有项目创建、成员管理、任务更新、事件创建、待办完成、提醒创建这些能力。

这说明工具有明确的业务来源。

它们是数据库世界的操作接口。

2. 工具设计要有企业味

企业工具和普通 CRUD 工具有区别。

如果只提供：

select_table
update_table
insert_table
delete_table

那 Agent 虽然能操作数据库，但任务语义会很弱。

企业 Agent 需要的是业务动作：

审批权限请求
预订会议室
创建会议纪要
分享会议纪要
更新任务完成度
创建入职提醒
查询用户权限汇总

这些工具名本身就带着业务语义。

后面做任务合成时，LLM 可以根据 seed 里的目标状态选择合适工具。

后面做工具检索时，也可以根据工具名称、描述、参数 schema 构建语义图。

所以工具设计本身会影响 benchmark 的质量。

3. 工具数量多之后，选择工具就是一个问题

107 个工具听起来还好，但对 Agent 来说已经很容易混。

比如文档权限相关工具就有：

grant_document_permission
revoke_document_permission
check_document_permission
request_document_permission
list_permission_requests
approve_permission_request
reject_permission_request
get_user_permission_summary

这些工具名字都很接近，但语义和使用时机差别很大。

比如 request_document_permission 是发起申请。

approve_permission_request 是审批已有申请。

grant_document_permission 是直接授予权限。

如果 Agent 把它们混起来，任务就会跑偏。

这也是后面工具图检索要做的事情：根据历史成功轨迹，学习这些工具之间的稳定调用关系。

4. 工具链比单个工具更重要

企业任务经常需要工具链。

比如审批文档权限请求：

list_permission_requests
  ↓
get_document
  ↓
approve_permission_request
  ↓
list_document_permissions

这个链条里，每个工具都有位置。

list_permission_requests 找到 request_id。

get_document 确认文档信息。

approve_permission_request 执行写操作。

list_document_permissions 验证最终权限。

单看用户请求，语义最强的工具是 approve_permission_request。但完整任务需要前置查询和后置验证。

所以我觉得 EntBench-Agent 的工具库设计，重点在工具之间天然会组成工作流。

5. 工具 metadata 的作用

PDF 里提到工具 metadata，比如领域、描述、参数。

这部分后面会被多处使用：

任务 seed 阶段：根据业务域和实体类型筛候选工具
LLM prompt 阶段：告诉模型当前可用工具
Agent 运行阶段：渐进式暴露工具参数
语义图阶段：根据工具描述和参数构建相似关系
失败分析阶段：判断缺失工具、错误工具、危险工具

也就是说，工具 metadata 是系统运行的一部分。

一个工具如果 metadata 写得模糊，后面 LLM 选工具时就容易混。

一个工具如果参数 schema 设计得模糊，后面真实执行时就容易错。

6. 这一层的小结

工具库这一层解决的是：企业数据库世界如何被 Agent 操作。

数据库提供状态。

工具提供动作。

工具 metadata 提供语义。

工具链提供工作流经验。

后面任务合成、真实评测、失败分析、工具图检索，全部要围绕这套工具库展开。

所以这 107 个工具更像 EntBench-Agent 里的动作空间。