喜欢对技术刨根问底，却总是被打退，晕，再上，屡败屡战

注定要与程序打交道，毫无疑问我喜欢编程，而且适合

导航

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

Posted on 2026-08-10 13:47  Carmack  阅读(36)  评论(0)    收藏  举报

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 的区别是理解整个并行执行架构的关键：

维度 主 Agent 子 Agent
创建方式 系统启动时创建 运行时通过 agent 工具动态创建
上下文范围 完整的会话上下文，包含所有历史记录 独立的上下文窗口，仅包含分配的 prompt 和继承的必要信息
工具集 完整的工具集，包括 agent 创建、task 管理等元工具 受限的工具集，取决于创建时指定的 subagent_type 和配置
权限 完整的用户级权限 继承自主 Agent 但可能有额外限制
生命周期 与 session 生命周期一致 任务完成后销毁，或达到超时后终止
结果返回 直接返回给用户 摘要形式返回给主 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 最适合以下场景：

场景 分解方式 Swarm 优势
代码审查 每个子 Agent 审查一个文件 N 个文件同时审查，总耗时 = max(各文件审查耗时)
技术方案研究 每个子 Agent 研究一种方案 同一时间探索多个方向，避免串行研究的上下文惯性
多仓库操作 每个子 Agent 操作一个仓库 独立的代码上下文，避免混淆不同仓库的信息
大规模重构 每个子 Agent 负责一个模块的重构 模块间独立的实现决策，失败隔离

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 从创建到销毁经历以下阶段：

阶段 状态 说明
初始化 initializing 验证任务参数，创建子 Agent 实例，注入上下文
运行中 running 各子 Agent 并行执行，主 Agent 等待完成
汇总中 aggregating 收集结果，主 Agent 进行汇总分析
完成 completed / partial_failure 向用户输出汇总结果
中断 aborted 用户取消或系统错误导致 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 典型场景

场景 典型耗时 后台化的收益
大型项目构建 2-10 分钟 用户可以继续讨论代码逻辑，回头检查构建结果
测试套件运行 1-30 分钟 测试在后台跑，Agent 可以同时分析代码
数据处理 / ETL 数分钟到数小时 启动后台处理，定期检查进度
模型训练 / 微调 数小时 启动训练任务，随时检查 loss 和 checkpoint

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

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

维度 前台工具调用 后台任务
执行模式 同步阻塞：Agent 必须等待工具返回 异步非阻塞：Agent 创建任务后立即继续
结果获取 工具返回值直接进入上下文 通过 task_output 主动拉取
生命周期 与单次工具调用绑定 独立生命周期，可跨多轮对话
失败处理 错误立即反馈，Agent 可以立即修正 错误在下次查询时发现，处理延迟
状态可见性 高：Agent 实时看到进度 低：需要主动查询任务状态

选择前台还是后台的关键问题是：​结果是否影响 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 负责管理所有后台进程的完整生命周期：

生命周期事件 BackgroundManager 的操作
进程创建 注册进程信息，分配 task_id，记录 cwd 和环境变量
进程运行 启用流式输出捕捉，维护 stdout/stderr 缓冲区
进程退出 记录 exitCode，计算耗时，生成完成通知
进程终止 发送终止信号，等待宽限期，必要时强制终止
进程清理 释放缓冲区内存，从 activeTasks 中移除
Agent 退出 检查是否有残留的后台进程，记录警告日志

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 创建新的定时任务 「每天早上 9 点，生成今日待办摘要」
cron_delete 删除已有的定时任务 删除 ID 为 xxx 的 cron 任务
cron_list 列出所有当前活跃的定时任务 查看当前配置了哪些自动化任务

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 标准来表达调度规则，支持以下常见的调度模式：

场景 RRULE 表达式
每天早上 9:00 FREQ=DAILY;BYHOUR=9;BYMINUTE=0
每周一和周五下午 5:00 FREQ=WEEKLY;BYDAY=MO,FR;BYHOUR=17
每月 1 日零点 FREQ=MONTHLY;BYMONTHDAY=1;BYHOUR=0
每小时的第 30 分钟 FREQ=HOURLY;BYMINUTE=30
每年 3 月 15 日 FREQ=YEARLY;BYMONTH=3;BYMONTHDAY=15

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

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

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

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

10. 三种并发模式的对比

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

10.1 横向对比表

维度 单 Agent（同步） Swarm（并行子 Agent） 后台任务（异步）
执行单元 单个 Agent 实例 多个独立子 Agent 独立的长时间运行进程
上下文 单一共享上下文 各子 Agent 有独立上下文 独立上下文，与主 Agent 隔离
适用任务 有明确依赖顺序的串行任务 多个互不依赖的独立子任务 耗时长、结果可延迟消费的操作
隔离程度 无隔离，所有信息共享 高隔离，子 Agent 间不通信 完全隔离，主 Agent 通过缓冲获取结果
结果获取方式 执行中实时获得 所有子 Agent 完成后汇总 通过 task_output 主动拉取，非阻塞
失败影响 单点失败，整个流程中断 单个子 Agent 失败不影响其他 任务独立失败，主流程不受影响
资源消耗 最低，单个 LLM 会话 较高，N 个 LLM 会话并行 中，进程 + 缓冲区，LLM 按需查询
典型耗时 秒到分钟级 分钟级（并行加速） 分钟到小时级
用户交互 实时交互，可随时干预 Swarm 期间用户等待，完成后展示汇总 用户可继续对话，回头查看结果
最佳场景 「帮我改这个 bug」「解释这段代码」 「审查所有 auth 模块文件」「研究 3 个技术方案」 「跑一下全量测试」「构建项目」「训练模型」

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 是这条路径上的两个关键里程碑。