任务生成出来之后，还要过几道关。看起来合理的任务，实际跑起来可能直接失败。

EntBench-Agent 的第四层是门控系统。

这一层我觉得非常重要。因为 LLM 生成的任务草稿，第一版大概率会有各种小问题。

有的问题是格式问题。

有的问题是工具范围问题。

有的问题是实体关系问题。

还有的问题更隐蔽：任务文字看起来合理，但真实工具链跑一遍之后，最终数据库状态达成失败。

所以系统加了两类 gate：

规则门控
可解性门控

1. 规则门控先查静态问题

规则门控主要检查 task draft 本身是否合理。

它会看这些东西：

JSON 结构是否完整
stage 字段是否齐全
required_tools 是否来自 allowed_tools
forbidden_tools 是否被避开
fill_blanks 是否有 expected
state_checks 是否指向真实表和字段
stage 依赖关系是否合理
实体 ID 是否来自 seed

这一步很像编译器里的静态检查。

比如一个 task draft 里写：

required_tools: ["delete_document"]

但 seed 里把 delete_document 放在 forbidden tools 里，那这个任务就要被拦住。

再比如 state check 写了一个数据库里缺失的字段：

PermissionRequest.status_code = approved

但真实字段叫 status，这个检查就会失败。

这种问题靠人工看很容易漏，靠规则检查更稳。

2. compiler 后还有补充检查

task draft 通过初步检查之后，会进入 compiler。

compiler 会做一些补全和转换：

根据 seed 和数据库补全 expected
构造 DatabasePatch
生成 cross-stage checks
生成 task.md
生成 task.py

这里还会做第二轮检查。

比如某个 fill_blank 的 expected 为空，但 seed 和数据库里可以推断出 request_id，compiler 就能补上。

再比如 task.py 需要在任务开始前确保某个 permission request 处于 pending，compiler 会生成数据库初始化 patch。

这一步的目标是让任务初始状态稳定。

如果任务开始前数据库状态飘了，后面评测就会变得很混乱。

3. 可解性门控：真的跑一遍工具链

规则门控能检查格式和静态关系，但它还没验证任务是否真的能被执行。

所以系统还需要可解性门控。

这一步会根据任务要求，把工具链真实跑一遍，然后检查：

工具是否能正常调用
参数是否能从前面阶段得到
读任务的 fill_blank 是否能回答
写任务的 state_check 是否能达成
跨阶段 ID 是否保持一致
最终 evaluator 是否通过

我觉得这一步非常像给题目做“试做”。

出题之后，系统自己先把题跑一遍。

跑通了，这个任务才进入 benchmark。

跑崩了，就进入修复或过滤。

4. 一个权限审批任务怎么被检查

还是拿文档权限审批举例。

任务目标是：

找到 pending edit request
审批这个 request
确认 requester 获得 edit 权限

规则门控会检查：

request_id 是否来自 seed
document_id 是否来自 seed
approve_permission_request 是否在 allowed_tools
reject_permission_request 是否出现在危险列表
state_checks 是否检查 PermissionRequest 和 DocumentPermission

可解性门控会真实执行：

list_permission_requests
get_document
approve_permission_request
list_document_permissions

然后检查数据库：

PermissionRequest(req000123).status = approved
DocumentPermission(doc000456, user031).permission = edit

如果 request 状态更新了，但 permission 记录没生成，那就是部分写入成功，任务评测会失败。

这种失败靠看任务文本很难发现，必须跑工具链。

5. 失败后怎么处理

PDF 里提到两种处理方式。

第一种是 gate repair。

系统把失败日志反馈给 LLM，让它修复 task_draft.json，然后重新编译和验证。

比如工具范围错了、评测字段写错了、stage 依赖写漏了，都可以尝试修。

第二种是过滤。

多轮修复之后仍然失败的任务，直接从样本集中移出。

这听起来有点浪费，但我觉得很必要。benchmark 最怕混入无解任务。无解任务会让 Agent 背锅，也会污染后面的失败分析。

6. 错误分类

门控失败还会形成错误分类。

常见类型包括：

格式错误
工具范围错误
实体关系错误
状态检查错误
可解性失败
跨阶段一致性失败

这些错误分类后面可以接到第六部分的失败分析体系。

也就是说，门控除了筛样本，也在收集系统哪里容易出错。

比如某一类 motif 经常可解性失败，说明 seed 采样或工具筛选有问题。

某一类 state_check 经常失败，说明 compiler 或 evaluator 设计要回头看。

7. 这一层的小结

我觉得门控系统是 EntBench-Agent 从“任务生成器”变成“benchmark 合成系统”的关键。

任务生成只是第一步。

真正能进入 benchmark 的任务，需要通过：

结构检查
实体检查
工具检查
编译检查
真实执行检查
评测检查

这一层把“看起来像任务”变成“真的能评测的任务”。