本文深入探讨了多 Agent 架构的设计与实现从子 Agent 到 Coordinator再到 Swarm 团队模式详细解析了如何通过分层工具过滤、上下文隔离和异步结果处理等机制构建高效的协作系统。文章强调协调器不执行、Worker prompt 自包含、工具权限最小化等设计原则旨在帮助读者理解多 Agent 架构的核心思想并提供了实用的选择规则和实现细节。多 Agent 架构从单个助手到协作团队多 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 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取
掌握多 Agent 架构：从单个助手到高效协作团队，小白也能轻松上手并收藏！
本文深入探讨了多 Agent 架构的设计与实现从子 Agent 到 Coordinator再到 Swarm 团队模式详细解析了如何通过分层工具过滤、上下文隔离和异步结果处理等机制构建高效的协作系统。文章强调协调器不执行、Worker prompt 自包含、工具权限最小化等设计原则旨在帮助读者理解多 Agent 架构的核心思想并提供了实用的选择规则和实现细节。多 Agent 架构从单个助手到协作团队多 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 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取
