从"急诊分诊"看 AI Agent 的超时治理

引子：最认真的评审员，总是迟到

想象你组建了一个专家评审团：功能专家、安全专家、性能分析师、优化顾问，以及一位”现实检验者”——他的任务是不看任何人的脸色，亲自跑一遍整个系统来验证所有结论。

这位现实检验者确实厉害，他能发现别人发现不了的问题，但他有个毛病：每次都最后一个交卷，有时甚至直接缺席。

这正是我们在对抗式解题法（Adversarial Evaluation）系统中遇到的真实困境。五个判别者并行评审同一份交付物，其他四位在 2-3 分钟内给出详细报告，而现实检验者（Reality Checker）动不动跑 10 分钟然后超时。

第一步：诊断——为什么只有他迟到？

判别者	SKILL.md 动作指令数	含端到端验证
现实检验者	44个	是（启动服务、curl 测试）
功能审查者	23个	否
安全审查者	7个	否
性能基准师	4个	否
优化师	3个	否

差距一眼可见：现实检验者的动作指令数是其他判别者的 2-11 倍。

原因在它的工作流设计上——它不仅仅做静态代码分析，还要求：

启动 Web 服务，用 curl 做端到端验证
交叉比对 ROADMAP 的每条收敛标准
对比 OpenAPI 文档与实际路由的一致性
验证前端的请求体字段与后端解构是否匹配

每一项都是实打实的系统调用，加起来轻松吃掉 300-500 秒。而子代理的超时上限只有 600 秒——一旦遇到大项目，它几乎必然超时。

问题本质：我们对所有评审者用了”一刀切”的超时限制，但没有区分它们的任务复杂度。这就好比要求急诊医生、门诊医生和体检医生在同样的时间内完成检查。

第二步：思路——急诊分诊台的启示

医院的急诊科有一个关键角色叫分诊台。病人进来先不直接去诊室，而是由分诊护士快速评估：是危重病人（红色）直接进抢救室？还是普通急诊（黄色）排队？或者只是轻微不适（绿色）可以去普通门诊？

这个机制解决了什么？不让有限的急诊资源浪费在不该它处理的事情上。

回到我们的场景：现实检验者之所以慢，是因为它总把自己当成”Full 级别”的全面审计，哪怕被审查的项目只是一个没有 Web 界面的后端工具库。

解决方案就是给 AI Agent 加一个范围预检（Scope Pre-check）——相当于急诊分诊台。

第三步：落地——给 AI Agent 装上”分诊台”

范围预检是一个轻量步骤，在进入重型验证之前快速完成。它只做四件事：

1. 检查项目类型：有 Web 路由吗？
   → 无：跳过所有 Web 端到端验证
   → 有：标记为 Web 服务项目

2. 检查可运行入口：有 main 函数或 --demo 参数吗？
   → 无：跳过集成演示运行

3. 检查 ROADMAP 文件存在吗？
   → 无：跳过 ROADMAP 交叉验证

4. 检查有前端代码/API 文档吗？
   → 无：跳过文档一致性验证

基于以上结果，判定检查级别：

级别	条件	耗时	做什么
Light	后端库/工具，无 Web 组件	30-90s	静态分析 + 轻量验证
Standard	Web 服务，单层架构	90-180s	全量但可选择跳过耗时项
Full	全栈项目，含前端+API+文档	180-480s+	完整工作流，重型验证委派后台

关键代码逻辑：

# 范围预检 — AI 分诊台
def scope_precheck(project_path):
    findings = {}
    
    # 1. 检查项目类型
    has_web = grep_search(project_path, 
        "app.get|app.post|router|uvicorn|fastapi|express")
    findings["has_web_service"] = bool(has_web)
    
    # 2. 检查可运行入口
    has_entry = grep_search(project_path, 
        "def main|__main__|--demo|npm start")
    findings["has_runnable_entry"] = bool(has_entry)
    
    # 3. 检查 ROADMAP
    findings["has_roadmap"] = os.path.exists(
        f"{project_path}/ROADMAP.md")
    
    # 4. 计算检查级别
    if not findings["has_web_service"]:
        return "Light"
    elif findings["has_web_service"] and not has_frontend(project_path):
        return "Standard"
    else:
        return "Full"

第四步：架构演进——重型验证的委派模式

即使是 Full 级别的项目，我们也不希望现实检验者把自己跑死。解决方案是 委派模式（Delegation Pattern）：

时间线 (0s → 600s 超时限制)
│
├── 0-10s   范围预检 + 主张提取
├── 10-90s  轻量验证（静态分析） ← 主进程在此完成
│
├── 90s     判定 Full 级别 → 派出后台子代理做重型验证
│           主进程整理已有结果
│
├── 90-120s 主进程完成评审草稿
│
├── 120-480s 后台子代理运行（并行）：
│             ├── 端到端 curl 测试
│             ├── ROADMAP 交叉验证
│             └── 文档一致性检查
│
├── 480s    后台结果送达 → 合并 → 输出完整评审
│
└── 600s    超时红线（此时评审已输出，安全 ✅）