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 生命周期一致任务完成后销毁或达到超时后终止结果返回直接返回给用户摘要形式返回给主 Agent1.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 会话。在初始化阶段系统会注入子 Agent 专用的系统提示可能比主 Agent 更精简注入用户指定的 prompt 作为当前任务描述可选地注入主 Agent 上下文中的关键信息如当前工作目录、项目结构摘要注入工具描述仅限该子 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 个任务如果 concurrency5同时最多只有 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 会读取所有子 Agent 的结果识别共性问题或互补发现结构化输出如按文件分组、按问题严重程度排序标注各个子任务的执行状态哪些成功、哪些失败汇 总阶段本身也是一次 Agent 推理——主 Agent 使用其完整的上下文来分析和综合子 Agent 的发现。这也是为什么 Swarm 不是简单的「多线程」替代而是分布式推理 集 中汇总的架构。5. Swarm 的协调机制5.1 SwarmMode 在 Agent 中的实现在 agent-core 中Swarm 的实现不依赖于外部的任务队列或调度器而是直接内建在 Agent 的工具系统中。agent_swarm作为一级工具其处理逻辑位于 Agent 的工具处理管道中// Swarm 的简化实现 async function handleSwarmTool(swarmCall: SwarmToolCall): PromiseSwarmResult { 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 和 checkpoint6.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: MapTaskId, 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: SIGTERMWindows: WM_CLOSE如果进程在宽限期内未退出发送强制终止信号SIGKILL / TerminateProcess清理进程资源文件描述符、内存缓冲区将任务状态更新为stopped7.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_idAgent 不等待命令完成可以继续下一个推理步骤命令的输出被流式缓冲到 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: FREQDAILY;BYHOUR9, // 循环任务的调度规则 (RFC 5545) valid_from: 2026-08-01, // 生效起始日期 valid_until: 2026-12-31, // 失效日期 status: ACTIVE // ACTIVE 或 PAUSED }9.3 调度表达式Cron 系统使用 RFC 5545 RRULE 标准来表达调度规则支持以下常见的调度模式场景RRULE 表达式每天早上 9:00FREQDAILY;BYHOUR9;BYMINUTE0每周一和周五下午 5:00FREQWEEKLY;BYDAYMO,FR;BYHOUR17每月 1 日零点FREQMONTHLY;BYMONTHDAY1;BYHOUR0每小时的第 30 分钟FREQHOURLY;BYMINUTE30每年 3 月 15 日FREQYEARLY;BYMONTH3;BYMONTHDAY159.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 }); // 步骤 2Swarm 并行审查变更文件 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 是这条路径上的两个关键里程碑。