企业官网建设流程全解析

本文深入探讨了多 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 类型通常分成三层。

第一层是内建类型。例如：

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-id>ae9a65ee22594487c</task-id> <status>completed</status> <summary>Agent completed</summary> <result>...</result> <usage> <total_tokens>71330</total_tokens> <tool_uses>21</tool_uses> <duration_ms>81748</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 组织成团队。它不再只是父子关系，而更像一组可寻址队友。

常见后端有三类。

Swarm 里最关键的不是后端，而是通信协议。

命名信箱让 Agent 之间可以互相发送消息。Scratchpad 则提供一个共享的持久化空间，用来放研究发现、中间结论、任务分配或某个 Worker 需要交给另一个 Worker 的上下文。

为什么 Scratchpad 有价值？因为如果所有信息都经过 Coordinator 转述，会多一次延迟，也容易丢失细节。Worker A 可以把原始发现写到 Scratchpad，Worker 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 能解决的，不要上 Coordinator；Coordinator 能解决的，不要急着上 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大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

以上全套大模型资料如何领取？