企业任务能否真实，第一步看数据库世界是否站得住。
EntBench-Agent 的第一层是企业数据库世界。
这部分看起来像是准备数据，但我觉得它其实是整个系统的地基。后面所有任务、工具调用、评测、错误分析，都要落到这个数据库世界里。
如果数据库世界很假，后面生成的任务就会变成空中楼阁。
1. 先定义企业有哪些业务域
PDF 里把企业数据库拆成几个典型业务域：
组织 / 用户
HR
文档
权限
会议
项目
日程每个业务域下面都有一组表。
组织域里有：
Department
User
Employee文档域里有：
Document
DocumentVersion
DocumentPermission
DocumentShare
DocumentDownload
PermissionRequest会议域里有：
MeetingRoom
RoomBooking
Meeting
MeetingAttendee
MeetingMinutes项目域里有：
Project
ProjectMember
Task日程域里有：
Schedule
Event
Todo
Reminder这套表设计的重点在于，它覆盖了企业 Agent 最常见的工作流。
文档会被创建、分享、下载、申请权限。
会议会有会议室、参会人、纪要、分享。
项目会有成员、任务、进度、相关文档。
日程会有事件、待办和提醒。
这些东西组合起来，才会出现真正的企业任务。
2. 数据生成要有业务关系
最朴素的数据生成方式是随机造记录。
比如随机造 100 个用户，随机造 500 个文档，随机给一些人分配权限。
但这种做法很容易生成一堆彼此关系很弱的数据。后面要抽任务时，就会发现图里很多边连接很弱。
所以 EntBench-Agent 采用的是业务场景包。
每个场景包对应一类真实企业工作流，比如：
document_collab_pack
meeting_coordination_pack
project_delivery_pack
cross_domain_pack
HR 场景包这些 pack 的作用是按照业务逻辑生成跨表记录。
以 document_collab_pack 为例，它会先选择一个 uploader 创建文档，然后自动生成：
Document
DocumentVersion
DocumentPermission
DocumentShare
DocumentDownload
PermissionRequest也就是说，一篇文档从出生开始就带着业务链：
用户上传文档
↓
文档产生版本
↓
文档被分享
↓
接收人获得权限
↓
有人下载文档
↓
有人发起权限申请这样生成出来的数据天然就适合后面构造任务。
比如我们可以很自然地问：
找到某个用户收到的文档分享。
审批某个文档权限申请。
查看某个文档的版本变化。
确认某个用户是否下载过文档。这些任务都能落回真实数据。
3. 跨业务域关系很关键
单个业务域内部的任务比较容易。
比如查询文档、更新任务状态、创建提醒，这些都相对直接。
真正有企业味道的任务通常跨域。
比如：
项目任务快到期了，需要开会协调。
会议纪要需要分享给项目成员。
某个项目文档需要给新成员授权。
员工入职任务需要创建日程提醒。
请假审批影响后续会议安排。PDF 里提到的 cross_domain_pack 就是为这种任务准备的。它会把项目、文档权限请求、会议、待办、提醒连接起来。
我觉得这一步很重要。
如果企业数据库里每个业务域都像孤岛，后面生成的任务就会很单薄。真正的企业 Agent 需要处理的是“一个事情牵出另一件事”的链条。
比如一个权限审批任务，后面可能牵出项目任务和会议纪要。一个会议协调任务，后面可能牵出文档分享和日程提醒。
4. 数据质量校验
数据生成完还要校验。
这里主要看几类问题：
外键关系是否存在
时间顺序是否合理
项目和会议人数分布是否正常
可查询样本是否足够
可操作样本是否足够这一步很像给数据库做体检。
比如会议结束时间早于开始时间，这种数据会污染任务。
比如一个项目里没有成员，项目任务就很难合理分配。
比如文档分享记录存在，但接收人的权限缺失，后面任务就会出现断链。
所以这个阶段除了“造数据”，更像是在造一个可运行的企业模拟环境。
5. 这一层对后面有什么影响
后面所有模块都依赖这一层。
seed 采样要从企业关系图里抽实体和关系。
LLM 生成任务时要引用真实 entity id。
compiler 要根据 seed 构造数据库初始补丁。
evaluator 要检查数据库最终状态。
失败分析也要根据真实表字段判断错误。
所以企业数据库世界一旦质量差，后面每一层都会跟着抖。
这也是我觉得这个项目第一层最值得写的原因。它把 benchmark 的起点从“写题目”提前到了“造一个能跑业务的公司”。
