AIClaw 缩短审批等待，超时仍需确认

AI 审批也会拖慢编程代理：执行一次工具操作，可能先等模型审查，再等人确认，最后才开始运行。AIClaw v3.7.22 在 10 月 23 日发布的改动，是把模型审查的等待预算从 30 秒压到 8 秒，并让部分操作跳过没有必要的模型请求。

这次调整值得看的，是它如何拆分规则判断、模型审查和人工确认。不过，Default 模式同时放宽了文件工具的写入权限，评估升级时要把这笔权限账单独算清。

八秒限制的是审查，整项任务能快多少还不知道

v3.7.22 给单次模型审查设置了 8 秒截止时间，上一版 v3.7.21 是 30 秒。同时，输出上限从 512 tokens 降到 128 tokens，并请求关闭思考模式。

下面这段节选展示了三个设置如何进入审查请求：

reviewCtx, cancel := context.WithTimeout(ctx, approvalReviewTimeout)
defer cancel()
response, err := client.Stream(reviewCtx, llm.Request{
    Model: model.Model,
    MaxTokens: 128,
    DisableThinking: true,
    // Separate system instructions and the operation to assess.
}, nil)

要看的是 context.WithTimeout：它约束这一轮审查请求。MaxTokens: 128 则对应一个很小的输出目标，模型只需要返回包含 decision 字段的 JSON，值只能是 allow 或 ask，不需要再写一份任务答案。

实际请求包含两条消息：审查器的系统指令，以及描述近期可见用户请求和拟执行操作的 JSON。审查器没有工具，职责就是判断这次操作能否放行。

超时会转入人工确认，不会自动获得权限。

8 秒不包含人的响应时间，也不包含命令执行时间。一项任务还可能触发多次独立审查。因此，预算减少 22 秒只能说明这一阶段的等待上限变小，不能写成「整个任务平均快了 22 秒」。

关闭思考也有适用范围。审查仍使用当前会话模型，没有偷偷切换到小模型。客户端只对已识别的 DashScope 端点和受支持模型发送 enable_thinking=false；对已识别的原生 DeepSeek 端点及受支持模型发送 thinking.type=disabled，同时移除冲突的 reasoning-effort 值。

未知网关和已识别的仅支持思考的模型名称保持原样，普通对话请求也不受影响。接入 OpenAI-compatible 服务的人可以借鉴这个边界：接口兼容不代表供应商扩展参数通用。

规则已经要求找人，就别再问一次模型

授权路径先看操作的影响和当前审批策略。可信的只读工具不需要模型审查；已有风险规则明确要求人工确认的命令，则直接找人。

测试覆盖的例子包括 git push、sudo 命令，以及通过 curl 发送数据的请求。这些操作既然已经命中人工确认条件，再调用一次模型，通常只会多一道等待。

但没有命中规则，也不等于获得许可。Default 模式下，不熟悉的命令仍要经过独立审查。这些基于字符串的规则负责分流，不能当作完整的 Shell 安全解析器。

模型返回结果的解析也很保守。重复键、额外字段、JSON 后面附带内容、未知决策、工具调用，以及未完成的响应，都不能转成批准。审查出错后直接回退到人工确认，不重试模型请求；如果原操作已经取消，就不再弹出新的确认。

这里有个值得拿走的工程原则：把模型的职责压到足够窄，再用程序检查输出。模型负责给出有限选择，程序负责决定哪些结果有效、异常走哪条路。

等待时间拆开了，文件权限也变了

过去一个工具步骤里混着多种等待，用户看到「很慢」，却难判断慢在哪里。现在内核会分别为模型审查和人工确认发送开始、完成通知，并携带开始时间与耗时。

桌面端按通知 ID 更新原来的记录，完成时不会再插入一行；步骤组件把时间显示在标题旁。这样就能区分模型审了多久、人在确认界面停了多久。

外层工具计时仍然包含授权和执行工作。不能把工具总耗时直接解释为命令运行时间，也不能把里面的审查耗时再重复相加。

另一项变化需要单独评估：桌面模式改为 Default、Strict 和 Allow all；Default 下，文件工具可以在工作区外写入而不经过审查，没有设置工作区时也适用。受保护的凭据路径仍被阻止，Strict 则保留文件写入确认。

Default 的文件写入改动扩大了权限范围。

它没有把任意 Shell 命令变成文件工具，也没有移除命令原有的沙箱限制。同一个路径，文件工具可以写，不代表 Shell 命令也能绕过审查或沙箱写进去。

我的判断

我认同把确定性规则放在模型前面，也认同给模型审查设置明确预算。审批属于工具执行的关键路径，重复判断和漫长等待都会放大交互成本。相比所有操作都先问模型，这种分流更容易解释，也更容易定位问题。

不过，8 秒是否合适，原文没有生产环境对照数据。作者从 v3.7.22 标签导出的代码中，使用 Go race detector 重跑了 8 个重点测试函数，全部通过。测试覆盖超时后单次回退、严格解析、风险命令分流、文件权限，以及关闭思考的参数不会泄漏到普通对话等行为。

这些证据能支持实现按预期运行。测试使用临时文件和受控 HTTP、模型响应，不能证明真实模型的平均延迟，也不能证明风险分类普遍准确。发布说明还报告了 290 项渲染器相关测试和 184 项 UI 检查，但作者没有重跑整个桌面测试套件。

原文也没有给出关闭思考前后的误放行率、转人工比例或总体完成耗时，所以「能提升多少体验」仍需实测。这个取舍有清晰逻辑，但效果还不能替作者背书。

相比始终人工确认，它减少了部分交互；相比直接放行，它保留了模型失败后的人工兜底。至于 Default 放宽文件写入，便利性成立，是否适合团队还取决于目录边界和确认要求。审批变快与权限变宽应分别评估。

能拿来做什么

• 如果你在做 Node 工具代理或 AI 编程助手，可以先把只读操作、明确要求人工确认的操作和待审查操作分流，再决定是否调用模型，避免重复判断。
• 给审批模型定义最小输出协议，严格解析 allow、ask，并明确超时、格式错误和请求取消的处理路径。不要把模型没答完当成默认同意。
• 在代理界面或运行日志里分别记录模型审查、人工等待和工具执行时间，再用真实请求统计耗时与转人工比例，判断瓶颈究竟在哪里。
• 升级 AIClaw 时，检查 Default 对工作区外文件写入的行为；如果团队需要逐次确认文件写入，就选择 Strict，并分别核对文件工具权限和 Shell 沙箱限制。