多个 Agent 一起干一件事：任务怎么拆、结果怎么合
最后更新：2026-10-25
Aiglade 是一个 Windows 桌面软件，把 Claude Code、Codex CLI、Hermes、OpenClaw 等多个 AI 装进一个中文窗口，带中文向导，装上就能用，不用会编程。它是 Electron 形态的桌面应用，是使用这些 AI 的唯一控制台，没有网页版。本文讲多个 Agent 一起干一件事时，任务怎么拆、结果怎么合，以及人在哪里把关。
任务是怎么拆的？
任务拆开的第一步，是使用者用中文把一件事交代出来，而不是先把事情拆成给每个 Agent 的指令。使用者不需要写代码，也不需要说明技术实现方式，只要用中文讲清楚任务本身，任务就会进入分派与排队。窗口内的 Agent 包括 Claude Code、Codex CLI、Hermes、OpenClaw，它们都集中在同一个窗口内，使用者不需要逐一了解它们的区别，也不需要先学习它们各自的用法。
拆的含义，是分工而不是把界面拆开。分派解决的是任务交给谁的问题，排队解决的是任务按什么顺序处理的问题。两者结合起来，多个 Agent 的工作就有了可预期的次序，使用者也可以在界面里看到任务当前处在分派还是排队阶段。拆之前使用者要讲清楚的，是事情本身、相关的背景和想要的结果，不需要讲技术路线，也不需要指定任务应该由哪一种技术方式完成。讲不清楚的地方，窗口会在确认点停下来问，而不是凭猜测继续推进，这也是拆这一步里人把关的起点。关于产品的基本介绍，可以参考Aiglade 官网关于页。对于其中个别工具的官方说明，可以参考Claude Code 官方文档和Codex 官方文档。
拆开的任务按什么顺序跑？
拆开的任务按排队顺序跑，而不是无序地同时堆积。当多个任务同时存在时，界面里的排队关系让每个任务的进展都可以单独追踪，不会因为任务数量增多就失去线索。使用者不需要凭借记忆去还原某个任务交给了谁，也不需要在不同位置反复核对。任务、分派结果与排队状态都属于同一个管理界面里的信息，使用者在查看时可以直接对应到具体的任务上。
唯一控制台的含义，是任务的管理入口只有一个，使用者在需要确认任务状态时不需要在多个位置之间来回寻找。桌面应用的形态也决定了任务的管理与本机的记录处在同一侧，界面、任务与记录之间的对应关系更加直接。窗口本身是协作的载体，内置 Agent 的任务在这里汇聚，管理的动作也在这里完成。分派与排队在留痕里也有对应：审计表里的分派记录对应任务交给谁，状态变更记录对应任务走到哪一步，查记录时可以按这两类线索对应回具体的任务，而不是凭印象还原分派结果。
结果是怎么合的？
结果合拢的方式，是回到同一个窗口、同一项任务名下，而不是由某个自动机制合成一份新结果。拆开的任务各自推进之后，进展与结果都对应回当初交代的那一项任务，使用者在同一个窗口里看到的是同一项任务的不同侧面，而不是几份互不相干的输出。合拢的依据有三条：同一窗口、同一任务、两处留痕对得上。
第一处留痕是状态变更：daemon 内部统一走审计写入，落审计表，action 取值包含创建、分派、心跳、状态变更、挂确认、解决、归档，这是库里的记录。第二处留痕是会话：各 CLI 的会话记录落在本机磁盘，这是本地的。两处各答各的问题，审计表不回答会话内容，会话文件也不回答状态变更的全貌。两处对得上，任务线索才完整；对不上，就说明合拢这一步还没有完成，不能先宣布已经合好了。查法也有先后：先看审计表里的状态变更线索，再看本机磁盘上的会话文件，两处对得上，任务线索才完整。只看一处，容易把会话内容当成状态变更，或者把状态变更当成会话内容。确认卡是合拢前最后的人工关口：触发 gate 的操作没有经过确认，合拢就不算完成，进展再多也只是未确认的进展。
人在拆与合的哪一步把关？
人在触发 gate 的那一步把关。任务进行中遇到触发 gate 的操作时，操作不会直接执行，而是先停下来等用户确认。人在界面上看到的是一张确认卡，两个动作：批准或拒绝。审批是对象相等判定，不是关键词匹配；gate 带有超时时间，超时不等于默认批准。确认发生在执行之前，而不是事后补记。
确认只针对当次触发 gate 的操作，不改变任务本身的目标，也不给其他操作附加审批条件。使用者参与的是自己能看懂的决定，而不是自己看不懂的技术细节。确认之后任务继续进行，确认之前任务保持等待，这种状态本身也是中文界面上可以直接看到的内容。这种中文文档和中文界面的做法在国内平台也很常见，例如阿里云百炼文档和智谱开放平台文档都以中文提供说明，读者可以对照理解不同平台在文档说明方式上的区别。
中断之后，拆开的任务怎么办？
中断之后，拆开的任务按有条件续跑处理，不是全部自动续上。daemon 崩溃或重启后，孤儿任务会被标成 resumable，并保留 checkpoint；续跑是手动发起的，读 checkpoint 后任务从 resumable 回到 running，再注入历史重跑。使用者回来之后，可以从记录里了解任务做到哪一步，再决定接下来如何处理。
边界同样明确：只有带 checkpoint 且状态为 resumable 的任务能续跑，不是任何任务都能从断点恢复。其它状态的任务不能续跑，会返回 409；search runtime 不支持续跑。继续的起点是 checkpoint，而不是任务的开始处。拆开的任务各自的中断状态不同，能续的按 checkpoint 续，不能续的按 409 处理，两类结果不混成一句都可以续跑。
这样拆合，边界在哪里？
这样拆合的边界有三条。第一条，不承诺所有操作都要审批，只有触发 gate 的操作会停下来等用户确认，本文不对其他操作的确认情况作出断言。第二条，不承诺所有任务都能续跑，只有带 checkpoint 的 resumable 任务能手动续跑，search runtime 不支持。第三条，不承诺自动合成一份结果，合拢的意思是进展与结果回到同一窗口、同一项任务名下，并由两处留痕印证，而不是由某个未说明的机制替使用者写好结论。
三条边界和拆合过程放在一起，才是多个 Agent 一起干一件事的完整说法。拆是分派与排队，合是同一窗口、同一任务、两处留痕对得上，把关是触发 gate 时的确认卡，续跑是带 checkpoint 的 resumable 任务手动续跑。每一项的说明都只包含各自核对过的行为，不互相借用对方的实现方式。完整链条按顺序走一遍就是：使用者用中文交代一件事，任务进入分派与排队，按排队顺序推进，触发 gate 的操作停下来等确认卡，进展与结果回到同一窗口、同一项任务名下，由审计表与会话文件两处留痕印证，中断后只有带 checkpoint 的 resumable 任务能手动续跑。链条上任何一环对不上，都先按那一环的边界处理，而不是把整条链说成已经走通。对照阅读时，微软 Learn 文档提供了另一种平台的中文说明写法，但本文对 Aiglade 的说明仍以分派排队、确认卡与两处留痕为准。