前两天在群里看到一个讨论说的是某个开源 Agent 项目有人几分钟就把它的设计取舍说得明明白白还有人翻了半天源码还是停留在“哦它用了 Agent还有 Tool好像还有个 Workflow”这种层面。我当时的反应是这个差距其实跟代码读没读完没太大关系。真正拉开距离的是脑子里有没有一套稳定的架构判断框架。当你具备这套框架的时候面对任何一个陌生但热门的 Agent 产品你不会从零开始理解而是下意识地问几个问题它要解决的核心工程问题是什么它选的是单 Agent 还是某种多 Agent 结构它是在用上下文换智能还是在用架构换可控性这篇文章不讲某个具体框架的用法我想聊得更底层一点——把 Sub-Agent 到 Multi-Agent 这条演进路径上的四种核心模式讲透给出一套我自己在项目里反复验证过的决策方法。一、多 Agent 不是起点是终点先说一个我自己交过学费的教训。大概两年前我接手过一个企业知识助手项目前任团队一上来就是 Supervisor 五六个 Sub-Agent 的架构理由是“以后好扩展”。结果呢调试一个简单的问题要在五个 Agent 之间来回追踪日志一次简单的意图澄清硬是要走两轮 Agent 间通信token 成本高得离谱实际效果还不如一个写得干净的单 Agent 几个工具。后来我们把整个系统推倒重做先退回到单 Agent把工具收拾干净反而问题都解决了。LangChain 在他们的架构选型指南里有句话我很认同先从单 Agent 起步优先通过加工具扩展能力只有当系统真的触及了单 Agent 的架构边界才考虑多 Agent。这不是保守是工程常识。每多一个 Agent你就多一层调试复杂度多一份 token 成本多一个潜在的失败点。但话说回来多 Agent 也不是不能用用对了地方收益是实打实的。Anthropic 自己的多 Agent 研究系统在内部评测里比单 Agent 的 Claude Opus 4 性能提升了 90.2%。问题从来不是“要不要用多 Agent”而是“你的场景配不配得上多 Agent 的代价”。二、判断的两个信号别的都是伪需求我见过太多团队引入多 Agent 的理由是“感觉更专业”“别人都在用”这种动机基本都会在生产环境里翻车。真正值得升级的信号我认为只有两个。第一个信号是上下文管理确实撑不住了。当多个领域的专业知识没法舒服地塞进一个 system prompt 里你就得策略性地分发上下文而不是一股脑往里塞。这里有个概念叫 dumb zone就是当 Agent 的上下文窗口接近满载时模型在任务完成度上会明显掉链子——这个我在实践中深有体会一个 prompt 里塞了代码专家、测试专家、安全审计专家、文档专家四套指令之后模型经常会在角色之间“串戏”回答里夹杂着不该出现的口吻。第二个信号是团队协作层面的不同团队需要独立拥有和维护各自的 Agent 能力。比如安全团队维护审计 Agent测试团队维护测试 Agent谁都不用等谁发版本。这个信号偏工程管理技术上不难理解但很多团队一开始压根没意识到这也是一个正当理由。除了这两个其余的“多 Agent 冲动”我基本都劝退。三、四种模式一个都不能漏讲这四种模式我按 LangChain 的分类框架来讲结合 Anthropic、Google、OpenAI 几家的实践它们不是互斥关系真实项目里经常是组合拳。模式一Sub-Agents——集中式编排核心思路很简单一个 Supervisor 当老板拆解任务后分发给专门的 Sub-Agent 干活。每个 Sub-Agent 只关心自己那一块拥有独立的上下文窗口天然就避免了信息互相污染。Sub-Agent 本身通常无状态专注单次任务整个对话的状态和流程控制都在 Supervisor 手里。这套结构最大的好处是能并行多个 Sub-Agent 同时干活吞吐效率能起飞。用户不会直接跟 Sub-Agent 打交道永远是通过 Supervisor 间接沟通。调试上属于中等复杂度重点要盯住 Supervisor 的委派逻辑出问题的时候才能快速定位到底是哪一层出的错。举个我自己在项目里写过的配置结构subagent_config { name: research-agent, description: 针对特定主题进行网络检索。 适用于用户提出需要最新信息的事实性问题时使用。, system_prompt: 你是一名调研专家……, tools: [WebSearch, WebFetch, Read], model: sonnet # 用更快的模型压成本 }Claude Code 里内置的 Explore、Plan、General-purpose 几个子代理走的都是这套路子上手门槛不高。Anthropic 自家的 Research 功能是这个模式的教科书案例LeadResearcher 用 Claude Opus 4 负责分析查询、制定策略然后并行派出 3 到 5 个用 Claude Sonnet 4 跑的 SubAgent各自独立检索每个 SubAgent 至少执行 3 次并行工具调用最后由 CitationAgent 统一处理引用归属结果汇总回 LeadResearcher 做综合输出。这套并行架构能把复杂查询的整体研究时间压缩最多约 90%代价是相比普通对话大概 15 倍的 token 消耗。Anthropic 为了不让这个成本失控专门在 prompt 层设计了一套“努力分配规则”简单问题就用单个 Agent 加不超过 10 次工具调用中等研究上 3 到 5 个 SubAgent 各跑 3 次以上并行调用复杂研究才上 10 个以上 SubAgent 全面铺开。这个分级思路我觉得值得所有做多 Agent 系统的人借鉴——不是所有请求都值得用最贵的架构去接。模式二Skills——渐进式能力加载这个模式很多人会归到多智能体里但严格说它还是单个 Agent只是通过 SKILL.md 这类配置实现能力的按需加载。Agent 一开始只知道每个技能的名字和简介判断需要哪个技能了才把完整指令加载进来。我更愿意把它理解成“用更轻的 prompt 切换替代了完整的 Agent 切换”。Skills 模式下所有能力共享同一个上下文窗口隔离性天然就弱但换来的是对话状态可以自然连续地留在同一个 Agent 里不需要额外搞状态协调。执行是顺序的没有并行调度这回事用户体验上是路径最短的因为你始终在跟同一个 Agent 说话。目录结构大概长这样.claude/skills/ ├── deploy/ │ └── SKILL.md # 部署技能的完整指令 ├── review-pr/ │ └── SKILL.md # PR 审查技能的指令 └── database-migration/ └── SKILL.md # 数据库迁移技能的指令每个 SKILL.md 里是 YAML frontmatter 加详细步骤--- name: deploy description: 将应用部署到生产环境 allowed-tools: [Bash, Read, Edit] --- ## 部署步骤 1. 检查当前分支是否为 main 2. 运行完整测试套件 3. 构建生产版本 4. 执行部署脚本 5. 验证部署结果我自己带团队做编码助手类产品的时候特别偏爱这个模式——能力种类多但单次任务只用得上其中一两个的场景比如同时支持十几种操作模式的编码工具或者在写作、设计、排版几种创意形态之间切换的工具Skills 都比一上来就上 Sub-Agent 划算得多。它的工程代价也很直接对话历史越攒越多后续调用的 token 成本会持续膨胀。但首次调用几乎没有额外调度开销响应延迟是四种模式里最低的。我经常这样跟团队解释 Skills 和 Sub-Agent 的本质区别Sub-Agent 是独立上下文适合大量信息过滤Skill 是共享上下文适合需要连贯对话的场景。记住这一句基本就不会选错。模式三Handoffs——状态驱动的交接这个模式的核心是活跃 Agent 根据对话状态动态切换。A 完成自己的阶段以后把控制权和上下文传给 B。不同 Agent 之间是显式交接上下文可以选择性传递不是整体共享既保留了必要的信息连续性又不至于让无关内容到处扩散。因为各阶段之间存在明确的先后依赖这个模式只能严格顺序执行没法并行。但对用户来说体验是透明的感觉上就是在跟一个 Agent 完整地把事情办完。这里有个我经常被问到的问题Sub-Agent 和 Skills 都是框架原生支持的但 Handoff 底层压根没有一个叫 handoff() 的 API这怎么实现答案是Handoffs 从来就不是一个框架特性它是一种工程模式靠 prompt、状态约束和工程结构拼出来的。落地需要三个要素第一显式定义流程阶段第二每个阶段对应一套角色约束的 Agent 视角比如信息收集阶段就是前台接待的口吻诊断阶段就切换成技术支持的口吻第三也是最容易被忽略但最关键的一点——每个阶段必须有明确的完成条件不然就会卡在阶段里死循环出不来。我自己写过的一个简化示例系统规则: 你将按照以下阶段顺序工作: 1. 信息收集(intake) 2. 问题诊断(diagnosis) 3. 解决方案(resolution) 当前阶段:intake 规则: - 只能提问 - 不要给解决方案 - 当信息完整时,明确声明:进入 diagnosis 阶段当模型输出“信息已收集完成进入 diagnosis 阶段”之后你或者你的系统再注入下一段针对 diagnosis 阶段的 prompt一次 Handoff 就完成了。这套东西说穿了不难难的是把退出条件写得足够严谨不然生产环境里很容易出现卡死在某个阶段的情况——这个坑我踩过不止一次。Handoffs 最适合有明确阶段划分的流程型场景客服工单是最典型的例子从信息收集到诊断到给方案天然分阶段。它牺牲了并行能力在多领域查询上效率是四种里最低的但在强调流程完整和交互自然度的场景里往往是体验最好、可控性最强的选择。模式四Router——并行分发与合成Router 的核心是对输入做语义拆分和职责分流。系统先由 Router 对请求分类拆解把子查询并行分发给各自负责的专业 Agent最后把多个结果合成一个对用户友好的响应。这个模式天然适合跨多个知识域或数据源的查询。企业知识库场景里特别常见用户一次提问可能同时涉及政策文档、业务数据、实时指标比如问“我们的退货政策是什么最近的销售数据如何”Router 会把退货政策交给文档 Agent销售数据交给数据分析 Agent上层再统一整合返回。在 Claude Code 这类环境里Router 通常有三种存在形态主 Agent 里的一段路由决策逻辑这是最常见的一个可调用的工具也就是 Router-as-Tool或者一个轻量的 Sub-Agent只负责分类不负责执行。本质都是同一件事先判断这是什么问题再决定交给谁。Router 的优势是并行能力强、职责边界清晰各分支彼此独立、上下文完全隔离扩展和调试都方便。代价是通常无状态没法靠历史对话减少重复计算如果场景需要连续对话往往得把 Router 当工具嵌进一个有状态的主 Agent 里在并行效率和对话连续性之间找平衡。四、数据不会骗人量化对比给出的答案LangChain 做过一组实际的性能测试分三个场景对比这四种模式结论很值得记一下。单任务请求场景下比如“帮我改个函数支持分页查询”Sub-Agent 模式有明显的额外开销简单任务用不上它。重复请求场景下第二轮同类型请求有状态的模式效率优势非常明显。多领域查询场景下比如对比 Python/JS/Rust 的性能上下文隔离型的模式——也就是 Sub-Agent 和 Router——在 token 效率上优势显著能省下 40% 以上的成本。Anthropic 在工程博客里也披露了一个我觉得比表面数据更重要的发现多 Agent 系统里约 95% 的性能波动可以归因于三个因素——token 使用量占大头影响约 80%工具调用次数和模型选择加起来贡献约 15%剩下的因素影响有限。这句话背后的意思是选对模型带来的收益往往超过单纯把 token 预算翻倍。也就是说在多 Agent 架构里模型选型的重要性远高于无节制堆上下文规模。这个结论我这两年在好几个项目里都验证过——与其纠结要不要把上下文窗口从 100K 拉到 200K不如先看看 Sonnet 是不是已经能替代 Opus 完成这一层的工作。从“token 经济学”角度看多 Agent 系统普遍有约 15 倍的成本放大效应只适合高价值、高复杂度的任务。像那种需要所有 Agent 共享完整上下文的场景、强耦合且高度顺序化的工作流、大多数难以并行拆解的编码任务以及依赖实时协调的系统上多 Agent 基本是得不偿失白白多出成本和复杂度。五、生产环境不会跟你讲道理四个真实的坑架构选对了不代表上线就顺利。Anthropic 分享过他们把多 Agent 系统推向生产时遇到的四个挑战我自己也基本全踩过一遍。第一是状态性带来的复杂度。Agent 在多轮对话里维持状态一个 SubAgent 的轻微失误可能级联放大成后面所有 Agent 的行为都跑偏。应对的办法是在每个 Agent 的输出端设检查点先验证输出质量再往下传别让脏数据一路流到底。第二是非确定性调试。Agent 的动态决策让传统日志分析基本不够用你得有完整的生产链路追踪记录每个 Agent 的输入、决策过程和输出配合可观测性工具记录完整调用链——这个我建议项目一开始就搭好别等出了问题才补补的时候基本已经晚了。第三是部署复杂度。多 Agent 系统没法简单粗暴地停机更新因为 Agent 可能正在执行任务强行打断行为不可预测。比较靠谱的做法是新旧版本共存的渐进式部署让旧版本 Agent 把手头任务跑完再自然退出新版本接管后续请求。第四是同步瓶颈。当前大多数 SubAgent 还是同步执行的信息流转受限。这个我认为是未来一两年值得关注的方向——打通异步执行加 Agent 间消息通道让 SubAgent 在跑的过程中能互相共享发现而不是各干各的等最后汇总。六、一张决策树帮你少走弯路讲了这么多落到实操上我自己现在判断要不要升级架构基本就问这几个问题图片对应的项目演进路径我见过的大多数成熟系统基本都会走这四步先是单 Agent Tools这是大多数项目该待的起点工具多起来、prompt 变臃肿了升级到单 Agent Skills当不同领域确实需要独立上下文空间和专业知识了再引入 Supervisor Sub-Agents到了系统成熟期往往是混合架构——Router 做分类Sub-Agent 跑并行研究Handoff 处理有明确阶段的顺序流程几种模式各司其职。我自己习惯是项目早期先做一版不讲究任何设计模式的简单 Demo跑两三周等感觉认知开始过载、维护起来吃力了再回头套这套决策树去重构。这是我个人的节奏如果你的项目从立项就能大致判断出复杂度天花板提前做全局设计也完全没问题关键是别在需求不明确的时候就上重架构。总结最好的架构从来不是最复杂的架构而是恰好满足需求的最简架构。一个 Agent 加几个好用的工具能解决的问题就没必要引入 Supervisor SubAgent 的复杂度。但当任务的并行性、专业性、上下文管理需求确实超出了单 Agent 的能力边界正确的多 Agent 架构带来的质量提升是实打实的。Anthropic 那个 90.2% 的性能提升数字很唬人但别忘了后面跟着的 15 倍 token 成本——架构选型从来都是性能、成本、可控性这三者的博弈没有免费的午餐。留一个具体场景给你自己练练手假设你在给研发团队搭一个内部技术助手要支持查内部文档、答代码相关问题、辅助排查线上问题偶尔还要做跨领域分析比如“这个接口改动会影响哪些系统、上线风险如何”。现在已经有 15 个以上的工具单 Agent 长 prompt 快到上下文上限了用户开始反馈回答跑偏、不同问题之间“串味”、调试一次要反复重放对话。面对“继续压缩单 Agent 的 prompt”“上 Skills 按需加载”“直接上 Supervisor Sub-Agent 拆开领域”“加一个 Router 并行分发”这四个选项你会怎么选触发你做这个判断的信号到底是工具数量、上下文长度还是错误类型本身欢迎在评论区聊聊你的答案。学习资源推荐如果你想更深入地学习大模型以下是一些非常有价值的学习资源这些资源将帮助你从不同角度学习大模型提升你的实践能力。一、全套AGI大模型学习路线AI大模型时代的学习之旅从基础到前沿掌握人工智能的核心技能​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取二、640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取三、AI大模型经典PDF籍随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型如GPT-3、BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取四、AI大模型商业化落地方案作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。