kimi-code 深度掌握系列文章-Swarm 与后台任务：并行与异步执行（十）

1. 子 Agent 的设计理念

在单 Agent 架构中，所有的工具调用、上下文处理、决策推理都发生在同一个执行流程内。当面对多个独立子任务时——比如同时审查 5 个文件、并行研究 3 个技术方案——单 Agent 只能串行处理，效率低下且上下文越来越臃肿。子 Agent 的设计正是为了解决这个根本矛盾：将复杂任务拆解为独立执行单元，各自拥有独立的上下文和执行空间。

1.1 为什么需要子 Agent

子 Agent 的引入服务于三个核心目标：

• ​任务隔离​：每个子 Agent 只关注自己被分配的任务，不会受到其他任务中间产物的干扰。这避免了「上下文污染」——即无关信息占据上下文窗口，导致模型注意力分散。
• ​上下文隔离​：每个子 Agent 拥有独立的 LLM 会话和历史记录。主 Agent 只看到子 Agent 的最终结果摘要，而不需要在主上下文中保留所有中间推理过程。
• ​并行执行​：多个子 Agent 可以同时运行，充分利用系统资源。对于 I/O 密集型的任务（如文件读取、API 查询），并行执行可以线性缩短总耗时。

子 Agent 不是简单的「多开几个线程」。它的价值在于​每个实例都是一次完整的 Agent 推理循环​—有独立的系统提示、工具集、上下文窗口和权限边界。

1.2 子 Agent vs 主 Agent

理解子 Agent 和主 Agent 的区别是理解整个并行执行架构的关键：

1.3 子 Agent 的类型

agent-core 中定义了三种主要的子 Agent 类型，各自用于不同的场景：

• ​独立子 Agent​：通过agent工具创建的单例子 Agent。主 Agent 等待它完成后再继续。适用于需要深度分析某个文件、执行一个不紧急的独立任务时使用。
• ​Swarm 子 Agent​：通过agent_swarm工具批量创建的并行子 Agent 集合。所有子 Agent 同时启动、并行执行、各自独立。适用于同时处理多个互不依赖的子任务。
• ​后台子 Agent​：通过 BackgroundManager 创建的异步子 Agent。主 Agent 创建后不等待结果，可以继续处理其他任务，之后通过task_output获取结果。适用于长时间运行的操作。

这三种类型的本质区别在于​同步与异步、单例与批量​。独立子 Agent 是同步单例，Swarm 是同步批量，后台子 Agent 是异步单例。

2. 子 Agent 的创建与生命周期

2.1 agent 工具：创建单个子 Agent

主 Agent 通过调用agent工具来创建子 Agent。创建时需要指定以下关键参数：

• ​prompt​：子 Agent 要执行的任务描述，这是子 Agent 的「系统指令」。
• ​subagent_type​：子 Agent 的类型标签，决定工具集和能力的配置。常见类型包括Explore（代码探索）、Plan（任务规划）、GeneralPurpose（通用任务）。
• ​model​（可选）：指定子 Agent 使用的模型，可以用更轻量的模型处理简单任务以节省成本。

2.2 工具集继承和限制

子 Agent 不会自动继承主 Agent 的全部工具集。相反，agent-core 采用了一种​白名单继承策略​：

• 子 Agent 的工具集由subagent_type对应的配置决定，配置中明确定义了哪些工具对子 Agent 可见。
• 某些「元工具」——如agent本身、agent_swarm、task_list等——通常不会暴露给子 Agent，以防止子 Agent 再递归创建孙 Agent 造成不可控的膨胀。
• 文件读写、代码搜索等基础工具通常保留，因为它们是完成实际工作所必需的。

工具集的限制不仅是安全和节约的考量——更重要的是​认知负荷的控制​。子 Agent 看到的工具越少，它做出错误工具选择的概率越低。过多的工具选择会稀释模型的注意力。

2.3 上下文初始化

子 Agent 的上下文是一个全新的 LLM 会话。在初始化阶段，系统会：

1. 注入子 Agent 专用的系统提示（可能比主 Agent 更精简）
2. 注入用户指定的 prompt 作为当前任务描述
3. 可选地注入主 Agent 上下文中的关键信息（如当前工作目录、项目结构摘要）
4. 注入工具描述（仅限该子 Agent 类型允许的工具）

值得注意的是，子 Agent ​会自动获得主 Agent 的完整对话历史​。这既是上下文隔离的优势，也是一个设计权衡——子 Agent 无法参考用户之前和主 Agent 的对话，但对于大多数独立子任务来说，这恰恰是我们想要的干净上下文。

2.4 结果返回

子 Agent 完成后，其最终输出会被结构化封装并返回给主 Agent。返回的内容包括：

• 子 Agent 的最终响应文本
• 执行的工具调用列表（用于审计和调试）
• 执行状态（成功 / 失败 / 超时）
• token 消耗统计

主 Agent 拿到结果后，可以选择将其直接展示给用户，或基于多个子 Agent 的结果进行汇总分析后再输出。

// 子 Agent 创建的简化流程 interface SubagentResult { agentId: string; status: 'completed' | 'failed' | 'timeout'; output: string; // 子 Agent 的最终响应 toolCalls: ToolCall[]; // 所有工具调用记录 tokensUsed: number; // token 消耗 durationMs: number; // 执行耗时 } // 主 Agent 通过 agent 工具创建子 Agent function createSubagent(prompt: string, type: string): SubagentResult { const toolset = resolveToolsetForType(type); const systemPrompt = buildSubagentSystemPrompt(type); const agent = new Agent({ systemPrompt, prompt, tools: toolset, parentSession: currentSession }); return agent.run(); // 同步等待完成 }

3. Swarm Mode 的设计

Swarm Mode 是 agent-core 中并行执行能力的集大成者。如果说单个子 Agent 解决的是「把这个子任务摘出去做」，那么 Swarm 解决的就是「把这 N 个子任务同时摘出去并行做」。它的名字——Swarm（蜂群）——精准地传达了其设计思想：多个独立执行单元围绕一个共同目标并行工作，每个单元贡献自己的结果，最终合并为完整的输出。

3.1 Swarm = 并行启动 + 独立完成 + 结果汇总

Swarm 的核心定义由三个要素构成：

• ​并行启动​：所有子 Agent 在同一时刻被创建并启动，共享起始时间点。不存在「等第一个完成再启动第二个」的串行依赖。

• ​独立完成​：每个子 Agent 完全独立地执行自己被分配的任务。它们有自己的上下文、自己的工具调用、自己的推理过程。一个子 Agent 不知道其他子 Agent 的存在，也不关心它们的进度。

• ​结果汇总​：所有子 Agent 完成后（或失败/超时后），主 Agent 收集全部结果，进行合并、去重、结构化，最终呈现给用户。

  主 Agent（协调者） │ ┌───────────┼───────────┐ │ │ │ 子Agent 1 子Agent 2 子Agent 3 │ │ │ [任务1] [任务2] [任务3] │ │ │ 结果1 结果2 结果3 │ │ │ └───────────┼───────────┘ │ 汇总 → 用户 Swarm 架构：平行执行，互不依赖，最终汇总

3.2 典型使用场景

Swarm Mode 最适合以下场景：

3.3 Swarm 的三大优势

​并行效率​：这是 Swarm 最直观的优势。如果 5 个子任务各自需要 2 分钟串行执行，总耗时为 10 分钟；而在 Swarm 中，总耗时接近其中最慢的那个——约 2 分钟出头。对于 I/O 密集型任务，加速比接近 N。

​任务隔离​：每个子 Agent 的上下文是干净的。审查文件 A 的子 Agent 不会受文件 B 的代码风格影响，研究方案 X 的子 Agent 不会将方案 Y 的假设当作事实。这种隔离对于需要独立判断的任务至关重要。

​失败隔离​：如果某个子 Agent 失败（超时、工具调用错误等），不会影响其他子 Agent 的正常执行。Swarm 不会因为一个成员的失败而整体回滚，失败的子任务单独汇报，成功的子任务正常工作。

Swarm 的失败隔离特性在实际使用中价值巨大。想象一下：审查 10 个文件中有一个文件太大导致子 Agent 超时，如果不使用 Swarm，整个审查可能失败或阻塞；而使用 Swarm，你得到的是 9 份完整的审查结果 + 1 条超时报告，而不是什么都没有。

4. Swarm 的工作流程

4.1 Swarm 创建：agent_swarm 工具调用

Swarm 的创建通过agent_swarm工具完成。与创建单个子 Agent 不同，Swarm 需要批量的任务描述：

// agent_swarm 工具的调用签名（简化） { "tasks": [ { "prompt": "审查 src/auth/login.ts 的安全性问题", "subagent_type": "Explore" }, { "prompt": "审查 src/auth/register.ts 的安全性问题", "subagent_type": "Explore" }, { "prompt": "审查 src/auth/reset-password.ts 的安全性问题", "subagent_type": "Explore" } ], "concurrency": 3, // 最大并行数 "on_error": "continue" // 单个失败时的策略 }

关键参数解释：

• ​tasks​：任务数组，每个元素定义一个子 Agent 的 prompt 和类型。
• ​concurrency​：最大并行数。即使有 20 个任务，如果 concurrency=5，同时最多只有 5 个子 Agent 在运行。
• ​on_error​：单个子 Agent 失败时的处理策略——continue表示忽略继续，abort_all表示终止整个 Swarm。

4.2 任务分配策略

如何将复杂任务分解为适合 Swarm 的独立子任务，是使用 Swarm 的关键技巧。agent-core 中的任务分配遵循以下原则：

• ​独立性优先​：子任务之间不应有数据依赖。如果任务 B 需要任务 A 的输出才能开始，那它们不适合放在同一个 Swarm 中。
• ​粒度适中​：太细的粒度会增加调度开销和上下文初始化成本；太粗的粒度则失去了并行优势。经验法则是每个子任务应该在 30 秒到 3 分钟之间完成。
• ​对称性​：尽量让任务在规模和类型上相似。如果 1 个任务需要 10 分钟、9 个任务需要 10 秒，Swarm 的收益会大打折扣。

4.3 各子 Agent 的并行执行

在实际执行中，所有子 Agent 被同时放入执行池。agent-core 使用 Promise.all（或类似的并发原语）来管理并行执行。执行流程如下：

1.创建所有子 Agent 实例

为每个任务创建 Agent 实例，注入各自的 prompt 和工具集

2.并行启动执行

所有子 Agent 同时开始其推理循环，各自独立调用工具

3.监控执行状态

主 Agent 等待所有子 Agent 完成（或超时），记录耗时和状态

4.收集结果

收集每个子 Agent 的输出、工具调用记录和状态信息

4.4 结果汇总

所有子 Agent 完成后，主 Agent 进入结果汇` 总阶段。汇` 总不是简单的拼接——主 Agent 会：

1. 读取所有子 Agent 的结果
2. 识别共性问题或互补发现
3. 结构化输出（如按文件分组、按问题严重程度排序）
4. 标注各个子任务的执行状态（哪些成功、哪些失败）

汇` 总阶段本身也是一次 Agent 推理——主 Agent 使用其完整的上下文来分析和综合子 Agent 的发现。这也是为什么 Swarm 不是简单的「多线程」替代，而是分布式推理 + 集` 中汇总的架构。

5. Swarm 的协调机制

5.1 SwarmMode 在 Agent 中的实现

在 agent-core 中，Swarm 的实现不依赖于外部的任务队列或调度器，而是直接内建在 Agent 的工具系统中。agent_swarm作为一级工具，其处理逻辑位于 Agent 的工具处理管道中：

// Swarm 的简化实现 async function handleSwarmTool(swarmCall: SwarmToolCall): Promise<SwarmResult> { const { tasks, concurrency, on_error } = swarmCall.parameters; // 创建执行池 const semaphore = new Semaphore(concurrency); const results: SubagentResult[] = []; // 并行启动所有子 Agent const promises = tasks.map(async (task) => { await semaphore.acquire(); try { const agent = createAgentForSwarmTask(task); const result = await agent.run(); results.push(result); return result; } catch (error) { if (on_error === 'abort_all') { throw error; // 传播错误，终止 Swarm } results.push({ status: 'failed', error: error.message }); } finally { semaphore.release(); } }); // 等待所有任务完成 await Promise.allSettled(promises); // 汇总结果 return aggregateSwarmResults(results, tasks); }

5.2 子 Agent 之间的通信限制

Swarm 中的一个关键设计决策是：​子 Agent 之间默认不通信​。这不是技术限制，而是有意为之的架构选择，其理由如下：

• ​保持独立性​：如果子 Agent 可以相互通信，它们就不再是真正的独立执行单元。通信会引入依赖、等待和状态共享，破坏并行性的优势。
• ​避免复杂性爆炸​：N 个子 Agent 之间的通信链路数是 N²，如果允许随意通信，协调开销会迅速超过并行收益。
• ​清晰的失败模型​：不通信意味着不存在跨 Agent 的失败传播。一个 Agent 的崩溃不会影响其他。

如果确实需要子 Agent 之间的信息传递，正确的做法是：子 Agent 将需要传递的信息写入文件或共享存储，而其他子 Agent 在需要时主动读取——这是一种异步的、无耦合的间接通信。

5.3 Swarm 的生命周期管理

Swarm 从创建到销毁经历以下阶段：

5.4 单个子 Agent 失败对 Swarm 的影响

单个子 Agent 失败的处理由on_error策略决定：

• ​continue​（默认）：失败的子 Agent 结果被标记为failed，其他子 Agent 继续正常执行。最终汇总时包含成功和失败的结果，用户可以看到「3/4 完成，1 个超时」这样的状态。
• ​abort_all​：任何一个子 Agent 失败时，立即终止整个 Swarm。所有正在运行的子 Agent 被取消，已完成的子 Agent 结果保留。此策略适用于子任务之间有隐式依赖或用户要求全有或全无的场景。

6. 后台任务的理念

与 Swarm 的并行哲学不同，后台任务解决的是一类不同的问题：有些操作本身就耗时很长（编译、测试、大规模数据处理），如果让主 Agent 同步等待，用户会面对长时间的沉默。后台任务允许主 Agent「开个后台工作，回头再来看结果」，期间可以继续处理其他交互。

6.1 为什么需要后台任务

在主 Agent 的同步执行模型中，每一个工具调用都阻塞当前的对话流。当工具执行需要 3 分钟时，这 3 分钟内用户什么都做不了——不能发新消息，不能追问，不能调整方向。后台任务是打破这种阻塞的关键。

6.2 典型场景

6.3 后台任务 vs 前台工具调用

后台任务和前台工具调用不仅仅是「快慢」的区别，它们在执行模型上有本质差异：

选择前台还是后台的关键问题是：​结果是否影响 Agent 下一步的决策​。如果需要立即基于结果做判断——前台；如果结果可以稍后查看而不影响当前决策——后台。

7. BackgroundManager 的实现

7.1 BackgroundManager 在 Agent 中的位置

BackgroundManager 是 Agent 实例的一个内部组件，负责管理所有后台任务的生命周期。它与 ToolManager 紧密协作——当 Agent 调用task_list或task_output工具时，这些工具的处理器实际上委托给 BackgroundManager 执行。

Agent ├── ToolManager │ ├── task (前台工具) │ ├── task_list (任务管理 → BackgroundManager) │ ├── task_output (结果获取 → BackgroundManager) │ └── task_stop (任务停止 → BackgroundManager) ├── BackgroundManager │ ├── tasks: Map<TaskId, BackgroundTask> │ ├── notificationQueue: 任务完成通知 │ └── runningProcesses: 运行中的进程 └── ...

7.2 后台任务的创建

后台任务通过task_list工具创建。虽然名字叫 task_list，但它同时承担了「查看任务列表」和「创建新任务」两个职责：

// 后台任务创建的核心接口 interface BackgroundTask { id: string; // 系统生成的唯一 ID name: string; // 任务名称（用于展示和查询） command: string; // 要执行的 shell 命令 cwd?: string; // 工作目录 status: TaskStatus; // 当前状态 createdAt: Date; startedAt?: Date; completedAt?: Date; exitCode?: number; stdout: string; // 标准输出缓冲区 stderr: string; // 标准错误缓冲区 } type TaskStatus = 'pending' | 'running' | 'completed' | 'failed' | 'stopped';

7.3 任务状态跟踪

BackgroundManager 维护所有任务的状态，状态流转如下：

pending ──→ running ──→ completed │ ├──→ failed (exitCode !== 0) └──→ stopped (用户或系统终止)

• ​pending​：任务已创建但尚未启动。可能在等待资源释放或用户确认。
• ​running​：进程正在执行中。此时可以通过task_output获取部分输出。
• ​completed​：进程正常退出（exitCode = 0）。
• ​failed​：进程异常退出（exitCode != 0）。
• ​stopped​：被用户通过task_stop或系统主动终止。

7.4 任务输出获取

task_output工具允许 Agent 在任何时候查询后台任务的输出和状态：

// task_output 工具的参数 { "task_id": "abc-123-def", "block": true, // 是否阻塞等待任务完成 "timeout": 30000, // 阻塞等待的最大超时（毫秒） "filter": "error" // 可选：过滤输出（仅返回匹配行） }

当block: true时，task_output 会同步等待直到任务完成或超时。这与前台工具调用的行为类似，但区别在于——前台工具调用是 Agent 每轮推理的一部分，而task_output本身是一次独立的工具调用，Agent 可以在多个轮次中反复查询同一个任务。

7.5 任务停止

task_stop工具用于终止正在运行的后台任务。其实现涉及操作系统级别的进程管理：

• 向任务进程发送终止信号（Unix: SIGTERM，Windows: WM_CLOSE）
• 如果进程在宽限期内未退出，发送强制终止信号（SIGKILL / TerminateProcess）
• 清理进程资源（文件描述符、内存缓冲区）
• 将任务状态更新为stopped

7.6 任务通知机制

当后台任务完成或失败时，BackgroundManager 会将通知加入 notificationQueue。在下一次 Agent 推理循环开始前，系统会检查队列并将通知注入到上下文提示中：

// 任务完成后的通知注入 function injectTaskNotifications(agent: Agent): void { const notifications = agent.bgManager.drainNotifications(); for (const note of notifications) { agent.context.addSystemMessage( `[Task Notification] ${note.taskName} (${note.taskId}) ` + `has ${note.status}. Exit code: ${note.exitCode}. ` + `Output length: ${note.stdout.length} chars.` ); } }

通知机制的设计是「推送式」的——不是 Agent 主动轮询，而是 BackgroundManager 在任务完成时主动写入 Agent 的上下文中。这确保了 Agent 不会遗漏已完成的任务结果。

8. 后台进程管理

8.1 Shell 命令的后台执行

在 agent-core 的工具系统中，Shell 工具（Bash / PowerShell）支持一个特殊的run_in_background参数。启用此参数后，命令的执行模型从同步切换到异步：

• 命令通过子进程启动，工具调用立即返回一个task_id
• Agent 不等待命令完成，可以继续下一个推理步骤
• 命令的输出被流式缓冲到 BackgroundManager 的后端存储中

这种设计使得 Agent 可以在一个 turn 中启动多个并行构建、测试或其他耗时操作，然后在后续 turn 中统一检查结果。

8.2 进程生命周期管理

BackgroundManager 负责管理所有后台进程的完整生命周期：

8.3 输出缓冲和流式读取

后台进程的输出不直接写入 Agent 的上下文——那样会瞬间撑爆上下文窗口。BackgroundManager 使用输出缓冲区来存储进程的输出：

• ​缓冲区大小限制​：每个进程的输出缓冲区有上限（如 1MB），超出部分被截断。防止失控进程的无限输出撑爆内存。
• ​分页读取​：Agent 通过task_output查询时可以指定 offset 和 limit，逐页读取大型输出。
• ​过滤支持​：支持正则表达式过滤，Agent 可以只读取包含「ERROR」或「FAILED」的输出行，忽略大量正常的日志。

8.4 超时和资源限制

BackgroundManager 对后台进程施加多层次的资源限制：

• ​执行超时​：每个后台任务有一个可配置的最大执行时间（默认 10 分钟），超时后自动发送终止信号。
• ​并发限制​：同时运行的后台任务数量有上限（默认 5 个），超出部分进入 pending 队列等待。
• ​输出缓冲限制​：如上所述，防止单个进程产生过大的输出。

// BackgroundManager 核心接口 interface BackgroundManager { // 创建后台任务（由 task_list 工具触发） createTask(params: CreateTaskParams): BackgroundTask; // 列出所有任务 listTasks(filter?: TaskFilter): BackgroundTask[]; // 获取任务输出（由 task_output 工具触发） getTaskOutput(taskId: string, options?: { block?: boolean; timeout?: number; filter?: string; }): TaskOutput; // 停止任务（由 task_stop 工具触发） stopTask(taskId: string, force?: boolean): void; // 获取待处理的通知 drainNotifications(): TaskNotification[]; // 清理所有已完成/失败/停止的任务 cleanupCompleted(): void; }

9. Cron 定时任务系统

9.1 定时任务的设计目标

Cron 系统在 agent-core 中是一个轻量级的定时任务调度机制。它的设计目标与 Unix cron 类似但范围更集中：让 Agent 能够在指定的时间点或周期性地自动执行某些操作，而无需用户每次手动触发。

Cron 的典型应用场景包括：

• ​每日站会摘要​：每天早上 9:00 自动生成当日的日程和待办事项摘要
• ​定期代码检查​：每周一上午自动运行 linting 和测试，确保代码质量
• ​监控任务​：每小时检查一次关键 API 的健康状态
• ​数据同步​：每天凌晨从外部系统拉取最新数据

9.2 Cron 工具集

agent-core 提供了三个专用工具来管理 Cron 任务：

cron_create是最核心的工具，它接收以下参数：

// cron_create 的工具参数 { "prompt": "生成今日的待办事项和日程摘要，发送到飞书群", "schedule_type": "recurring", // "once" 或 "recurring" "scheduled_at": "2026-08-01T09:00", // 一次性任务的时间点 "rrule": "FREQ=DAILY;BYHOUR=9", // 循环任务的调度规则 (RFC 5545) "valid_from": "2026-08-01", // 生效起始日期 "valid_until": "2026-12-31", // 失效日期 "status": "ACTIVE" // "ACTIVE" 或 "PAUSED" }

9.3 调度表达式

Cron 系统使用 RFC 5545 RRULE 标准来表达调度规则，支持以下常见的调度模式：

9.4 Cron 任务与 Agent 生命周期的关系

Cron 任务的一个关键特性是它们​独立于单个 Agent session 的生命周期​。这意味着：

• Cron 任务在 Agent session 结束后仍然存在——它们是持久化的配置。
• 当触发时间到达时，系统会创建一个新的 Agent session 来执行 cron prompt。
• 执行结果可以通过飞书消息、邮件或其他通知渠道发送给用户。
• 如果触发时用户正在活跃对话中，cron 任务不会打断当前对话——它在独立的上下文中执行。

Cron 系统真正实现了 Agent 的「离线自治」——即使你没有打开对话窗口，Agent 也会在预定时间自动执行你设定的任务。这是从「交互式助手」到「自主工作者」的质变。

10. 三种并发模式的对比

现在我们已经覆盖了 agent-core 中所有的并发和异步执行机制。理解它们的区别和选择是实际使用中的核心技能。

10.1 横向对比表

10.2 模式选择决策树

面对一个具体的多任务场景，如何选择正确的执行模式？以下是一个简化的决策流程：

任务能否分解为独立子任务？ │ ┌──┴──┐ 是 否 │ │ │ 使用单 Agent 串行执行 │ 子任务是否互不依赖？ │ ┌──┴──┐ 是 否 │ │ │ Plan Mode：先规划依赖顺序，再串行执行 │ 单个子任务耗时 > 1 分钟？ │ ┌──┴──┐ 是 否 │ │ 后台任务 使用 Swarm 并行执行 （如构建、测试）

10.3 组合使用

三种模式不是互斥的——在实际使用中，它们经常被组合使用来完成更复杂的工作流：

• ​Swarm + 后台任务​：Swarm 中的某个子 Agent 启动后台构建任务，然后继续其分析工作。最终汇总时，Swarm 等待所有后台任务完成后一并输出。
• ​后台任务 + Cron​：Cron 在每天早上自动触发一个 Agent，该 Agent 启动后台任务来运行每日构建，构建结果通过通知发送给用户。
• ​单 Agent + 后台任务 + Swarm​：主 Agent 先启动一个后台测试运行，然后创建 Swarm 并行分析测试覆盖率，最后汇总 Swarm 结果和测试结果。

// 复合模式的简化示例 // Agent: "运行全量测试，同时审查所有变更文件的代码质量" // 步骤 1：启动后台测试 const testTask = await task_list("npm run test -- --coverage", { bg: true }); // 步骤 2：Swarm 并行审查变更文件 const reviewResults = await agent_swarm({ tasks: changedFiles.map(file => ({ prompt: `审查 ${file} 的代码质量、安全和性能`, subagent_type: "Explore" })), concurrency: 5 }); // 步骤 3：等待测试完成 const testOutput = await task_output(testTask.id, { block: true }); // 步骤 4：汇总所有结果 // 主 Agent 综合审查结果和测试结果，生成完整报告

总结

agent-core 的并行与异步执行系统由三个核心机制构成：子 Agent 架构提供了执行单元的抽象和隔离基础；Swarm Mode在此之上构建了并行批处理能力，让 N 个独立任务同时执行并按需汇总；BackgroundManager解决了长时间运行操作的异步化问题，让 Agent 的对话流不再被耗时操作阻塞。三者的结合使 kimi-code 具备了从快速交互到离线自治的完整执行能力谱系。

理解这些机制的关键在于认清它们的本质差异：子 Agent 是执行单元，解决的是「谁来做」；Swarm 是编排模式，解决的是「怎么并行做」；后台任务是时间模型，解决的是「什么时候看结果」。掌握这三个维度，你就能为每个具体场景选择最合适的执行策略。

从单 Agent 的串行交互到 Swarm 的并行分工，再到 Cron 的离线自治，agent-core 的演进清晰地展示了 AI Agent 从「对话工具」走向「自主工作者」的路径。Swarm 和 Background Manager 是这条路径上的两个关键里程碑。