多 Agent 架构封面很多人第一次做 Agent 系统时会自然地把所有事情都交给一个“超级 Agent”它负责理解需求、读代码、拆任务、改文件、跑测试、总结结果。小任务这样做没问题但任务一复杂问题会立刻冒出来上下文越来越重、决策越来越乱、并行能力上不去失败后也很难隔离责任。多 Agent 架构解决的不是“多叫几个模型”这么简单而是把一个复杂任务拆成可隔离、可并行、可回收的协作系统。以 Claude Code 这类编程 Agent 的实现思路为例真正关键的不是 Agent 数量而是三件事•谁来拆任务谁来执行•子 Agent 能看到什么、能用什么工具•结果如何可靠地回到主流程。这篇文章按工程视角拆一遍从最基础的子 Agent到 Coordinator再到 Swarm 团队以及它背后的工具过滤、上下文隔离、通知机制和 Plan 模式。一、先选模式不要一上来就 Swarm三种多 Agent 模式选择多 Agent 协作通常可以分成三种模式。第一种是子 Agent 模式。父 Agent 派生一个子 Agent让它完成一个相对独立的任务然后等待结果返回。这是最容易落地、也最稳的模式。比如“帮我阅读这几个文件并总结调用链”“帮我只改某个模块的测试”都适合用子 Agent。第二种是Coordinator 模式。它适合多步骤、强编排的任务。Coordinator 本身不直接执行具体修改而是拆分任务、派发 Worker、等待结果、综合判断。这里最重要的约束是协调器不能变成“边指挥边下场干活”的角色否则很快会把决策上下文和执行细节搅在一起。第三种是Swarm 团队模式。多个 Agent 通过命名信箱、共享任务列表或 Scratchpad 之类的机制对等协作。它适合并行度高、任务之间需要交换信息的场景但复杂度也最高。没有清晰通信协议时Swarm 很容易变成“很多 Agent 同时说话但没人真正负责”。一个实用的选择规则是•独立子任务用子 Agent•多个 Worker 并行但需要中央综合用 Coordinator•Worker 之间要持续交换信息再考虑 Swarm•不确定时从子 Agent 开始复杂度不够再升级。二、子 Agent 的核心prompt 必须自包含子 Agent 模式的入口可以理解为一个AgentTool。父 Agent 调用它时通常会传入这些参数⁠⁠⁠ { description:string, prompt:string, subagent_type?:string, model?:sonnet|opus|haiku, run_in_background?:boolean, name?:string, isolation?:worktree|remote }这里最容易被低估的是prompt。普通子 Agent 默认看不到父 Agent 的完整对话历史所以它的 prompt 必须是自包含的。不能写“继续刚才那个问题”也不能假设它知道父 Agent 已经读过哪些文件。一个合格的子 Agent prompt 至少要包含•任务目标•必要背景•涉及文件路径•允许修改的范围•输出格式•成功标准。这种“无上下文”设计看起来麻烦但它有三个好处。第一隔离性更强。子 Agent 不会被父对话里的无关信息影响。第二成本更可控。每次都共享完整历史会让 token 消耗迅速膨胀。第三并行更安全。多个子 Agent 同时运行时共享可变对话历史会带来竞态和污染。Fork 子 Agent 是一个例外它可以继承父级上下文。但从架构动机看Fork 更像是一种缓存优化。它通过复用父级已经渲染好的系统提示词和消息前缀让多个子级共享 Prompt Cache。继承上下文是结果不是唯一目的。三、AgentTool 的五阶段调用链AgentTool 调用五阶段一次子 Agent 调用并不是“new 一个 Agent 然后跑起来”这么简单。它大致会经过五个阶段。第一阶段类型解析。系统先判断这次要使用哪类 Agent。如果显式传了subagent_type就按指定类型走如果没传并且 Fork 实验开启就走 Fork 路径否则回退到默认的general-purpose。这个逻辑有个重要原则显式指定优先。不要替用户猜 Agent 类型否则调试时会非常痛苦。第二阶段工具池组装。子 Agent 的工具池不是直接继承父 Agent 的工具池而是独立构建。典型逻辑类似这样⁠⁠⁠ const workerPermissionContext { ...appState.toolPermissionContext, mode: selectedAgent.permissionMode??acceptEdits } const workerTools assembleToolPool(workerPermissionContext, appState.mcp.tools)这意味着子 Agent 可以有自己的权限模式和工具限制。父 Agent 当前能不能用某个工具并不应该直接决定子 Agent 能不能用。否则父级状态会意外泄漏到子任务里。第三阶段系统提示词构建。普通子 Agent 会基于自己的 Agent 定义生成系统提示词再追加环境信息。Fork 子 Agent 则会直接复用父级已经渲染好的系统提示词字节尽量保证请求前缀一致提升缓存命中率。第四阶段上下文创建。系统为子 Agent 创建独立的ToolUseContext。这一步决定了子 Agent 的文件读取缓存、AbortController、状态更新、查询追踪等可变状态到底是克隆、隔离还是显式共享。第五阶段执行分支。最后根据run_in_background、Agent 类型、Coordinator 模式、Fork 实验等条件决定同步执行还是异步执行。同步模式下父 Agent 等待结果异步模式下子 Agent 后台跑完成后通过通知回到主流程。四、Agent 类型不是所有 Worker 都该拿全量权限Claude Code 这类系统里Agent 类型通常分成三层。第一层是内建类型。例如类型工具集典型用途general-purpose几乎全部工具通用执行任务Explore只读搜索和阅读代码库探索Plan只读 结构化输出设计实施方案Explore Agent 的设计很典型它只负责读和搜所以不应该拥有写文件、编辑 Notebook、再派生 Agent 等能力。系统提示词里还会明确声明 READ-ONLY让模型层面也知道自己不能尝试通过 Bash 绕路写入。Plan Agent 与 Explore 类似也偏只读但它的目标不同输出一份可执行的方案。它通常会要求在结果中列出关键文件、改动范围和实施步骤方便父 Agent 接着落地。第二层是用户自定义 Agent。它们可以通过.claude/agents/*.md这样的 Markdown frontmatter 定义工具、模型、权限模式和系统提示词。第三层是插件注入的 Agent 类型。插件扩展能力很强但也更需要清晰的权限边界。这里的设计原则很朴素工具权限要按任务给不要按“Agent 是不是聪明”给。Explore 再聪明也不该写文件执行型 Worker 再普通也可能需要完整工具链。五、工具过滤四层防线比一层配置可靠工具过滤流水线子 Agent 的工具过滤通常不是一层allowedTools就结束而是一条分层流水线。第一层是全局禁用工具。例如 TaskOutput、EnterPlanMode、ExitPlanMode、AskUserQuestion、TaskStop 这类元工具子 Agent 通常不应该直接使用。它们控制的是 Agent 生命周期和交互流程放给子 Agent 风险太高。第二层是自定义 Agent 限制。用户自定义类型不一定经过系统级审计所以需要额外限制避免它们获得与内建 Agent 同等的敏感能力。第三层是异步 Agent 白名单。后台 Agent 没有交互式 UI不能弹权限确认也不适合调用某些需要用户即时响应的工具。因此异步 Agent 更适合走白名单模式只放行 Read、Grep、Glob、Edit、Write、Bash、Skill、NotebookEdit 等可控工具。第四层是类型级禁止列表。例如 Explore Agent 明确禁止编辑类工具Plan Agent 禁止执行改动通用 Agent 则可能更宽松。这四层的价值在于纵深防御。即使某个自定义 Agent 写了一个很宽的工具配置前面的全局策略和异步策略仍然能兜住风险。六、上下文隔离默认隔离显式共享上下文隔离机制多 Agent 系统最怕“看起来并行实际上互相污染”。所以子 Agent 的上下文创建必须遵循一个原则默认隔离显式共享。几个关键字段很能说明这个原则。readFileState通常会克隆。文件状态缓存记录文件最后读取时间和内容哈希。如果子 Agent 读取文件时修改了父级缓存父 Agent 后续判断文件新鲜度就可能出错。abortController通常会创建子控制器。父级中断要能传播到子级但子级中断不应该反向影响父级。这是故障隔离的基础一个 Worker 失败不应该拖死整个任务树。setAppState默认可以是 no-op。子 Agent 的 UI 状态、进度状态不应随便写回父级否则多个后台 Agent 并发更新会让界面和状态变得混乱。setAppStateForTasks又必须共享。因为子 Agent 可能启动后台 Bash 任务如果任务注册信息到不了根 store子 Agent 退出后就可能留下无人管理的进程。queryTracking会生成新的 chainId并把 depth 加一。它一方面用于链路追踪另一方面也能帮助系统限制嵌套深度避免 Agent 无限派生 Agent。这些细节看似底层但决定了多 Agent 能不能安全扩展。没有隔离Agent 越多系统越不可预测。七、异步结果为什么要用 task-notification同步子 Agent 的结果很好理解父 Agent 等它跑完把最后的文本结果作为工具返回值拿到。异步 Agent 则不一样。它启动后父 Agent 先继续推进等 Worker 完成再通过类似下面的结构把结果投递回来⁠⁠⁠ task-notification task-idae9a65ee22594487c/task-id statuscompleted/status summaryAgent completed/summary result.../result usage total_tokens71330/total_tokens tool_uses21/tool_uses duration_ms81748/duration_ms /usage /task-notification这个结构至少解决了四个问题。第一结果可追踪。task-id能把结果和具体 Worker 对上。第二状态清晰。completed、failed、killed 这样的状态让协调器知道下一步是综合、重试还是停止。第三成本透明。token、工具调用次数、耗时都可以记录下来。第四方便去重。系统可以用一个原子标记避免“Worker 被停止后又自然完成”导致重复通知。在更高安全要求下系统还可以对子 Agent 的完整 transcript 做安全分类避免文件里的 prompt injection 借子 Agent 的结果回灌到父 Agent。八、Coordinator真正难的是“只编排不执行”Coordinator 模式的核心约束是协调器不直接做具体执行。它应该做的是•把大任务拆成边界清晰的小任务•给 Worker 写自包含 prompt•决定哪些任务可以并行•收集 Worker 结果•综合判断下一步。它不应该做的是一边派 Worker 查问题一边自己根据半截发现直接改代码。这条约束很重要。因为 Coordinator 的价值不是“多一个更聪明的执行者”而是把任务分解、并行调度和结果综合从执行细节里抽出来。一旦它开始亲自执行任务状态就会混在一起Worker 的发现也容易被误读或过早固化。一个好的 Worker prompt 通常还会包含“这份结果将用于什么”。例如“这份研究将用于 PR 描述”或“这份分析将帮助决定修复路径”。目的明确后Worker 输出会更贴合父级后续使用。九、Swarm信箱、Scratchpad 和故障隔离Swarm 团队通信Swarm 模式把多个 Worker 组织成团队。它不再只是父子关系而更像一组可寻址队友。常见后端有三类。后端实现方式适合场景Tmux创建和管理 tmux 分屏用户本来就在终端里工作iTerm2原生 iTerm2 面板macOS 原生交互体验InProcess同一 Node.js 进程内运行非交互式环境、CI、SDK 场景Swarm 里最关键的不是后端而是通信协议。命名信箱让 Agent 之间可以互相发送消息。Scratchpad 则提供一个共享的持久化空间用来放研究发现、中间结论、任务分配或某个 Worker 需要交给另一个 Worker 的上下文。为什么 Scratchpad 有价值因为如果所有信息都经过 Coordinator 转述会多一次延迟也容易丢失细节。Worker A 可以把原始发现写到 ScratchpadWorker B 直接读取信息损耗更小。但 Swarm 也必须有强故障隔离。每个 Worker 要有独立 AbortController必要时可以单独 terminate 或 kill。否则一个 Worker 卡住、跑偏或持续请求权限会拖住整个团队。十、Plan 模式把“信任”变成一个审批关卡Plan 模式两阶段执行Plan 模式本质上是一个两阶段执行协议。第一阶段是只读探索。Agent 可以阅读代码、派 Explore 或 Plan 子 Agent、整理方案但不能直接改业务文件。它唯一可写的表面通常是计划文件比如~/.claude/plans/{slug}.md。第二阶段是审批后实施。用户批准计划后系统恢复进入 Plan 前的权限模式并把计划内容注入上下文让 Agent 按方案执行。这个设计不是为了增加仪式感而是为了解决复杂任务里的三个痛点。第一避免方向性返工。Agent 先看清楚全局再动手。第二减少局部改动失控。计划先暴露修改范围和关键文件。第三把权限确认从“每个工具调用一次”提升为“整体方案一次”。用户审的是方向不是被迫逐条看工具调用。在团队协作场景下Plan 模式还可以通过信箱把审批请求发给团队领导。也就是说审批不一定发生在用户界面也可以成为 Agent 团队内部的流程节点。十一、最后看设计原则多 Agent 架构真正值得借鉴的不是“派生 Agent”这个动作而是背后的系统边界。第一协调器不执行。它负责拆解、调度和综合避免把执行细节污染到决策层。第二Worker prompt 自包含。每个 Worker 都应该拿到完成任务所需的完整信息而不是依赖父级对话里的隐性上下文。第三工具权限最小化。Explore 只读Plan 只设计执行型 Worker 才拿写入能力。第四上下文默认隔离。共享必须是显式的尤其是状态更新、AbortController、文件缓存和任务注册。第五结果结构化返回。异步任务要有 task-id、status、result、usage才能被可靠综合和恢复。第六复杂度按需升级。子 Agent 能解决的不要上 CoordinatorCoordinator 能解决的不要急着上 Swarm。说到底多 Agent 不是把一个大脑拆成很多小脑而是把复杂工作拆成一套可运行的协作协议。协议清楚Agent 多了才是并行协议不清楚Agent 多了只是噪声。如果你正在设计自己的 Agent 系统可以先问三个问题•这个任务是否真的需要并行•每个 Worker 的输入、权限和退出条件是否清楚•Worker 的结果能不能被父流程可靠消费这三个问题回答清楚多 Agent 架构才有继续复杂化的必要。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】