Aiglade 有没有审批控制、本地留痕和任务可恢复执行：三项功能实测说明
最后更新：2026-10-25
Aiglade 是一个 Windows 桌面软件，把 Claude Code、Codex CLI、Hermes、OpenClaw 等多个 AI 装进一个中文窗口，带中文向导，装上就能用，不用会编程。它是 Windows 桌面应用，采用 Electron 作为桌面端形态，是唯一控制台，没有网页版。本文讨论的三项功能是审批控制、本地留痕和任务可恢复执行。
Aiglade 的审批控制是怎样工作的？
审批控制是指任务进入待确认状态时，服务端挂一条 gate，操作先停下来等用户确认。人在界面上看到的是一张确认卡，两个动作：批准或拒绝，处理走 POST /gates/:gateId/respond。gate 带有 gate_id、node_id、trigger_type、reason、retry、status、timeout_seconds、pending_since 这些字段。审批是对象相等判定，不是关键词匹配；gate 带有超时时间，超时不等于默认批准。确认点出现在运行时，也就是操作真正要执行之前，用户在确认点作出决定，操作才会继续推进。
gate 里的字段各有分工：gate_id 标识这次确认，node_id 标识触发确认的节点，trigger_type 说明触发类型，reason 写明为什么要停下来，retry 记录重试情况，status 记录当前状态，timeout_seconds 是超时时间，pending_since 记录挂起的开始时间。审批判定用的是对象相等，不是关键词匹配，早期按「可以/yes」前缀匹配的做法会误批准，已经修掉。超时时间到了也不等于默认批准，超时就是超时，不会因为没人点就自动放行。确认卡上的两个动作就是批准与拒绝，没有第三个选项，也不会因为界面上的其他操作而改变确认的结果。pending_since 记录的是 gate 挂起的开始时间，使用者可以从这个时间看出确认已经等了多久；timeout_seconds 到了，gate 不会自动变成批准，操作仍然停着，等使用者决定。
Aiglade 官网关于页介绍了产品的桌面形态与中文向导定位，内置的 Agent 包括 Claude Code、Codex CLI、Hermes、OpenClaw，其中 Claude Code 官方文档与 Codex 官方文档分别介绍了各自工具的官方说明，读者在理解内置 Agent 时可以以官方文档为准。
哪些操作会停下来等用户确认？
只有触发 gate 的动作要审批，不是所有操作都要审批。会停下来等用户确认的操作，是触发了 gate 的操作；没有触发 gate 的操作不在本文的讨论范围之内，本文不对其他操作的确认情况作出断言。这样的表述方式保持了说明的边界：只说明触发 gate 的操作会停下来等用户确认，不扩展到其他类型操作的确认规则。使用者在面对确认点时，只需要针对当次操作作出批准或拒绝的决定，决定本身就是操作能否继续的前提。确认点出现在运行时，而不是事后补记，确认发生在执行之前，这一点决定了审批控制在时间顺序上的位置。
确认卡出现在运行时界面上，使用者点批准，操作继续；点拒绝，操作不继续。确认只针对当次触发 gate 的操作，不改变任务本身的目标，也不给其他操作附加审批条件。没有触发 gate 的操作，本文不讨论它有没有确认，也不把它理解为需要审批。
本地留痕分哪两处？
本地留痕分两处，说清楚是哪一处，才不会把两处混成一处。第一处是状态变更留痕：daemon 内部统一走审计写入，落 sh_activity 审计表，action 取值包含 create、dispatch、heartbeat、status_change、gate、resolve、archive。这是库里的记录，不是本地明文文件。第二处是会话留痕：各 CLI 的会话记录落在本机磁盘，Claude Code 在 ~/.claude/projects/…/*.jsonl，OpenClaw 在 ~/.openclaw/agents/<agent>/sessions/。这是本地的。两处回答不同的问题：审计表回答的是状态变更留下了什么，会话记录回答的是各 CLI 会话本身留下了什么。
审计表里的 action 取值对应不同的事件：create 是创建，dispatch 是分派，heartbeat 是心跳，status_change 是状态变更，gate 是挂确认，resolve 是解决，archive 是归档。查状态变更，就是按这些 action 去审计表里查；查会话，就是按 CLI 去本机磁盘上找对应的会话文件。两处各答各的问题，审计表不回答会话内容，会话文件也不回答状态变更的全貌。审计写入是 daemon 内部统一走的，不是各 CLI 各写各的；正因为统一走一条写入，状态变更的线索才不会散落在不同的地方。
查记录时去哪里？
查状态变更，去审计表；查会话，去本机磁盘上的会话文件。两者不是互相替代的关系，审计表不等于会话文件，会话文件也不等于审计表的全部记录，使用者在回看时需要同时看到这两个位置的内容，才能形成比较完整的任务线索。回看任务时，先看审计表里的状态变更线索，再看本机磁盘上的会话文件，两处对得上，任务线索才完整。只看一处，容易把会话内容当成状态变更，或者把状态变更当成会话内容。审计在库、会话在文件，这个分法本身就是为了不把两处混成一处。对照阅读时，阿里云百炼 Model Studio 文档、智谱开放平台文档与 微软 Learn 文档提供了各自平台的相关说明，读者可以对照理解不同平台在文档说明方式上的区别，但本文对 Aiglade 的说明仍以审计表与本机会话文件为准。
任务中断后，哪些能续跑、哪些不能？
只有带 checkpoint 且状态为 resumable 的任务能续跑，不是任何任务都能从断点恢复。daemon 崩溃或重启后，孤儿任务会被标成 resumable，并保留 checkpoint；续跑是手动发起的，读 checkpoint 后任务从 resumable 回到 running，再注入历史重跑。其它状态的任务不能续跑，会返回 409；search runtime 不支持续跑。续做的讨论只包含上述条件内的续跑，不涉及中断之前如何保存进度的其他实现方式。使用者在中断之后面对的仍然是同一个任务的继续，继续的起点是 checkpoint，而不是任务的开始处。
续跑的流程是这样的：daemon 崩溃或重启后，孤儿任务先被标成 resumable，同时保留 checkpoint；使用者手动发起续跑，服务端读 checkpoint，任务从 resumable 回到 running，再由执行器注入历史重跑。状态不是 resumable 的任务走这条路会返回 409，不会悄悄续跑。search runtime 走不了这条路，它不支持续跑，本文不把它算进可恢复的范围。checkpoint_json 是续跑时读回的依据，里面留着任务中断时的进度；没有 checkpoint 的任务不在可恢复的范围里，即使状态看着像能续跑，也要先看有没有 checkpoint。
三项功能之间是什么关系？
审批控制对应执行之前，本地留痕对应执行过程的留存与可查，任务可恢复执行对应中断之后的有条件续跑，三项功能分别落在不同的环节。审批控制让触发 gate 的操作先停下来等用户在确认卡上批准或拒绝，本地留痕让状态变更进审计表、会话记录留在本机磁盘，任务可恢复执行让带 checkpoint 的 resumable 任务在 daemon 崩溃重启后手动续跑。三项功能合在一起，说明的是一条比较完整的任务线索：执行前有确认，执行过程有留存与可查，中断之后有条件续跑。每一项功能的说明都只包含各自核对过的行为，确认只说 gate 与确认卡，留痕只说审计表与本机会话文件，续跑只说 resumable 加 checkpoint 的条件，三者之间不互相借用对方的实现方式。三项功能合在一起，读者能按顺序跟完一次任务：执行前有 gate 与确认卡，执行过程有审计表与会话文件两处留痕，中断之后只有带 checkpoint 的 resumable 任务能手动续跑。每一步的边界都写清楚了：不是所有操作都要审批，不是所有日志都在一个地方，不是什么任务都能续跑。Aiglade 官网首页提供了产品的总体介绍，读者在需要了解产品定位时可以先从官网首页入手，再回到本文对照三项功能的具体行为。