本文深入剖析 Agent 架构，拆解为控制流、上下文、行动接口三层，提供同层对比与选型决策树，助你轻松理解 LangGraph、AutoGen 等框架差异。无论 AI 应用选型还是框架学习，这篇都值得收藏。Agent = 决策循环 + 上下文 + 动作接口，三者组合形成架构。文章强调分层对比，避免常见错误，并提供实用的选型指南与工程化建议。
市面上聊「Agent 架构」的文章，十篇里有八篇在犯同一个错误：把不在同一层的东西放在一起比——拿 ReAct 比 Supervisor，拿 RAG 比多 Agent，然后得出一些似是而非的结论。
这篇文章把 Agent 架构拆成三个正交层，在每一层里做同层对比，最后给出拆分原则与选型决策树。无论你是在做 AI 应用选型，还是想搞懂 LangGraph、AutoGen 这些框架到底差在哪，这篇都值得收藏。
Agent = 一个决定「下一步做什么」的循环 + 一套喂给它的上下文 + 一组它能触达的动作。
三者各自都有多种实现，组合起来才叫「架构」。
一、先分层，再比较：三个正交层
整个版图按分类图谱展开：
- L1 控制流层——谁决定下一步？
固定工作流 / Router 分流
单 Agent 循环：ReAct 交错推理、Plan-and-Execute、ReWOO 无观察推理、Reflexion 自我批判、搜索型 ToT / LATS
多 Agent 拓扑：Supervisor 编排者、Hierarchical 分层团队、Sequential 流水线、Network 对等交接、Group Chat 群聊辩论、Blackboard 黑板
- L2 上下文层——模型每一步看到什么？
纯上下文窗口 / 滚动摘要压缩 / 向量检索 RAG / 结构化记忆 / 文件系统记忆 / 分层记忆
- L3 行动接口层——Agent 怎么对世界产生影响？
Function Calling / CodeAct 代码即动作 / GUI 计算机操作 / 标准化协议 MCP
关键是：三层互相正交，可以自由组合。你完全可以用 ReAct 循环 + 分层记忆 + CodeAct 接口，也可以用 Supervisor 拓扑 + 纯上下文窗口 + Function Calling——两种组合都成立。
三个高频混淆，先排掉：
① 把 RAG 当架构——RAG 是 L2 的一种实现，不是 L1 的替代品；
② 把 多 Agent 当能力升级——它是 L1 的一个选项，买到的是上下文隔离与并行，不是「更聪明」；
③ 把 MCP 当架构——它是 L3 的接入标准，解决的是工具集成的 N×M 问题。
二、动手前先问：到底要不要 Agent？
| 方案 | 什么时候用 | 代价 |
|---|---|---|
| 单次 LLM 调用 （+ 检索） | 任务一步能完成，输入输出形态固定 | 几乎没有。先试这个 |
| 固定工作流 （DAG 编排） | 步骤已知且稳定，只是每步需要 LLM 能力 | 不适应意外；但可测试、可预算、可回归 |
| Router 分流 | 有若干已知分支，需要模型判断走哪条 | 分类错误会整条链走错，需要兜底分支 |
| 单 Agent 循环 | 步骤数与顺序事先无法确定 | 成本与延迟不可预先界定，需设步数/预算上限 |
| 多 Agent | 任务可切成彼此独立的子任务，且中间上下文巨大 | 通信开销、上下文传递失真、归因困难 |
工程上的默认顺序：单次调用 → 工作流 → 单 Agent → 多 Agent。每往后一步都要有明确理由，不能因为「看起来更先进」。
三、单 Agent 架构族：五种范式
单 Agent 不等于简单。这一族内部的差异，主要在「规划」和「执行」如何交错，以及是否引入搜索与回溯。
四、多 Agent 架构族：六种拓扑
多 Agent 的本质不是「多个大脑更聪明」，而是三件具体的工程收益：
上下文隔离——脏活在子 Agent 里做完，只回结论；
并行——独立子任务同时跑；
提示词与工具集专精——每个角色只带自己需要的那套。
凡是这三条都用不上的场景，多 Agent 基本是净亏损。
① Supervisor / 编排者-工作者（最主流）：
一个中心编排者负责拆解与派发，专职工作者只对自己的子任务负责。控制流清晰可控、天然支持扇出并行；但编排者是瓶颈也是单点，工作者之间无法直接协商。适合研究/检索扇出、多源信息汇总、代码库多维审查。
② Hierarchical / 分层团队：
Supervisor 的递归形态，Leader 再管工作者。能支撑很大的任务树；但误差沿层级累乘——三层每层 90% 可靠，端到端只剩约 73%。一般业务场景不建议超过两层。
③ Sequential Pipeline / 流水线：
固定阶段链，A 的输出是 B 的输入。完全确定，可单元测试、可回归、成本可预算；但零适应性，误差逐阶段放大。严格说这属于工作流而非 Agent，但它常是正确答案。
④ Network / 对等交接：
没有中心，任何 Agent 可把控制权交给任何其他 Agent。路由最灵活、无单点瓶颈；但不确定性最强，极易形成交接死循环。必须硬性设置交接次数上限。
⑤ Group Chat / Debate 群聊与辩论：
多角色在共享会话里轮流发言，主持者收敛结论。能削弱单模型的片面性；但 token 成本随角色数 × 轮数倍增，且会出现「群体附和」——一个自信的错误答案反而被强化。角色之间必须有真实的立场或信息差。
⑥ Blackboard / 黑板共享状态：
不直接通信，全部读写一块共享状态。角色间彻底解耦、状态天然可观测（黑板即审计日志）；但需要自己实现冲突解决与写入仲裁，实现复杂度最高。适合长跑型、可中断续跑、人机混合协作的场景。
Supervisor 模式是怎么跑起来的
用户下达复杂任务，编排者拆解为彼此独立的子任务；
并行扇出：每个工作者带着「子任务 + 约束 + 验收标准」开工，大量读取外部原始材料；
工作者在自己的上下文里消化原始材料；
关键设计：只回结论，不回过程——如果回传全部过程，上下文隔离这个最主要收益就被抹掉了，这是实践中最常见的实现错误；
编排者做汇总与一致性裁决，输出最终结果；
瓶颈提醒：编排者的上下文最终要装下所有汇总。
多 Agent 不是升级，是权衡。工程实践中反复出现的三个事实：
- token 消耗通常是单 Agent 的数倍——每个子 Agent 重新加载系统提示与背景，编排者还要再读一遍所有汇总；
- 主要失败模式是「跨边界上下文丢失」，不是模型不够聪明——子 Agent 做出局部合理、全局错误的决定，这类错误比模型自身的错误更难发现；
- 写入密集型任务不适合多 Agent——多 Agent 同时改同一份产物会互相覆盖。读取/检索密集型才是舒适区。
可操作的判据：如果子任务之间需要频繁互相确认，说明这条边界切错了，应该合回一个 Agent。
五、上下文与记忆架构：长任务的天花板
控制流决定 Agent 能走多少步，上下文架构决定它走远之后还记不记得为什么出发。长任务的质量天花板通常由这一层决定。
| 方案 | 机制 | 关键取舍 |
|---|---|---|
| 纯上下文窗口 | 全部历史原样累积 | 零失真、最简单；但线性膨胀直到溢出，成本随步数增长 |
| 滚动摘要压缩 | 旧历史压成摘要 | 能撑很长任务；但压缩即失真，反复压缩会累积漂移 |
| 向量检索（RAG） | 外部知识按需召回 | 知识量无上限、可溯源；但召回不准就等于没有，切块策略严重影响效果 |
| 结构化记忆 | 状态写成明确字段/表/清单 | 精确、可校验、可被程序读写 ；需预先设计 schema |
| 文件系统记忆 | 中间产物落盘当外部工作区 | 容量几乎无限、产物可被人直接检查；Agent 可能忘记自己写过什么 |
| 分层记忆 | 工作区 + 长期库分离（MemGPT 一类） | 兼顾容量与精度，接近「操作系统分页」；换入换出策略要调 |
实践优先级：先用结构化记忆管任务状态，再用文件系统存大块产物，最后才考虑向量检索补外部知识。直接上 RAG 管过程状态是常见弯路——过程状态需要的是精确，而检索给的是近似。
六、行动接口层：Agent 怎么动手
| 接口形态 | 优势 | 劣势 / 风险 |
|---|---|---|
| Function Calling | 可控性最好 ，每个动作有明确签名与校验点；权限易收敛 | 组合表达力弱；工具多了选择准确率下降 |
| 代码即动作（CodeAct） | 表达力极强 ，循环/条件/组合一次写完，步数大幅减少 | 必须有沙箱与资源限制 ；不可逆操作风险高 |
| GUI / 计算机操作 | 能覆盖没有 API 的系统，兼容性最后兜底 | 慢、贵、脆弱；成功率明显低于 API 路径 |
| 标准化协议（如 MCP） | 解决 N 个模型 × M 个工具的集成爆炸；工具可复用分发 | 引入一层间接性；仍需自己做权限与审计 |
选择逻辑：有 API 就别用 GUI；需要组合与循环用 CodeAct，需要严格管控用 Function Calling；工具要跨项目复用走标准化协议。三者可以混用——高危动作走 Function Calling 显式收口，数据加工走沙箱代码。
七、拆分专章：按什么拆、拆到什么粒度
「要不要拆、怎么拆」是多 Agent 架构真正的决策点。拓扑只是结果，切边界的依据才是设计。
六种拆分维度
| 维度 | 怎么切 | 主要收益 |
|---|---|---|
| ① 按上下文隔离 （最强理由） | 大量中间材料的脏活交给子 Agent，只回结论 | 主 Agent 上下文保持干净，走更多步不失焦 |
| ② 按并行度 | 互不依赖的子任务同时扇出 | 压缩墙钟时间 （唯一能真正省时间的拆法） |
| ③ 按生成-审查分离 | 产出者与批判者分开，刻意制造差异 | 质量提升最稳定的一种拆法 |
| ④ 按工具集/能力 | 每个角色只挂自己需要的工具与提示词 | 工具选择准确率上升 |
| ⑤ 按成本分层 | 强模型做规划与裁决，弱模型做批量执行 | 单位任务成本显著下降 |
| ⑥ 按权限/数据边界 | 按数据域与操作权限切，边界即安全边界 | 爆炸半径可控 ，满足合规隔离 |
五个拆分反模式
① 按人类岗位拆——「产品经理 Agent / 架构师 Agent / 工程师 Agent」看起来直观，但人类岗位划分是为了解决人的沟通带宽与专业壁垒，而模型没有这两个约束。这样拆通常只是把一次调用变成四次，外加三次上下文失真。
② 拆写入密集型任务——多个 Agent 改同一份产物必然互相覆盖。
③ 拆出需要频繁互相确认的边界——来回确认三次以上，说明边界切错了。
④ 为了「显得先进」而拆——没有对应六种收益中的任何一种，就是纯亏。
⑤ 让子 Agent 回传全部过程——上下文隔离收益直接归零，只剩代价。
粒度判断的三条经验法则
- 结论压缩比：子任务的「过程材料量 ÷ 结论量」越大，越值得拆出去；比值接近 1 时不该拆。
- 依赖密度：子任务之间的依赖边越少越该拆，全连通的子任务集合应当合并。
- 层数上限：业务场景下不建议超过两层——每加一层，可靠性累乘、延迟叠加、归因成本同步恶化。
八、选型速查表
| 场景 | 推荐架构 | 理由 |
|---|---|---|
| 固定流程的内容/数据加工 | 流水线工作流 （不用 Agent） | 确定、可测、可预算 |
| 已知若干分支的分流处理 | Router + 各分支工作流 | 只需一次判断，不需要循环 |
| 检索问答、运维排查 | 单 Agent ReAct | 步数中等且需边看边调 |
| 成本敏感的高频批量收集 | ReWOO | 观察不入推理上下文，可并行、可预估 |
| 写代码 / 可自动验证的产出 | Reflexion （配可执行校验） | 有真实 oracle 时收益最大 |
| 深度研究、多源调研 | Supervisor 扇出 | 读取密集、子任务独立、结论压缩比高 |
| 多维度代码/文档审查 | Supervisor + 生成-审查分离 | 每个维度独立评审后汇总 |
| 方案评审、风险对抗 | 群聊 / 辩论 | 需要多视角权衡，角色须有真实立场差 |
| 客服多技能分流 | 对等交接 （须设交接上限） | 角色边界清楚，路由需灵活 |
| 长周期、可中断续跑 | 黑板共享状态 | 状态外置，异步友好，可审计 |
| 离线高价值难题 | 搜索型 ToT / LATS | 能接受成本换质量 |
九、工程化：让架构真正可用的四件事
- 护栏（必做）：最大步数、最大交接次数、token/费用预算、重复动作检测、高危动作显式确认。没有预算上限的自主循环不能上生产。
- 可观测性：记录每一步的输入上下文、决策、动作、观察与耗时成本。多 Agent 还要记录跨边界传了什么——因为失真就发生在这里。
- 评估：端到端成功率之外，要分别评估每个角色的单点质量与交接质量。只看端到端会掩盖是哪一环坏了。
- 渐进式演进：从单次调用起步，只在有具体证据时才升一级。每次升级都要能说出它买到了六种收益中的哪一种。
常见失败模式速查：
| 症状 | 通常的真实原因 | 处理方向 |
|---|---|---|
| 反复执行同一动作 | ReAct 无全局计划 + 无重复检测 | 加重复检测；引入轻量前置规划 |
| 长任务后期质量下滑 | 上下文膨胀，早期约束被稀释 | 结构化记忆固化约束与待办 |
| 子任务结果局部对、整体错 | 跨边界上下文丢失 | 交接时显式传递约束与验收标准 |
| 成本远超预期 | 群聊/网状拓扑无上限；或子 Agent 回传全过程 | 设硬上限；强制只回结论 |
| 自评总说「没问题」 | 评估者与生成者无差异 | 换模型、给评分规则、接可执行校验 |
| 交接不收敛、跑不停 | 缺少全局终止判断 | 加交接计数上限与显式完成判据 |
写在最后：五条可以直接拿去用的判断
先分层再比较。控制流、上下文、行动接口是三个正交层，不在同一层的方案不构成竞争关系。
默认从简。单次调用 → 工作流 → 单 Agent → 多 Agent，每往后一步都要有具体证据，不是「看起来更先进」。
多 Agent 买的是上下文隔离、并行、专精三件事，不是智力。这三条都用不上就是净亏损。
拆分的第一原则是结论压缩比高、依赖密度低。按人类岗位拆是最常见的错。读取密集型可以拆，写入密集型不要拆。
长任务的天花板在上下文层，不在控制流层。与其换更复杂的拓扑，先把任务状态结构化固化下来。
大模型的知识又多又杂，到底怎么学？
做这行久了，被问最多的问题就一个：大模型的知识又多又杂，我到底先学啥？翻了一堆资料，看啥都像重点，结果啥都没学进去。今天把我自己一路摸出来的顺序捋一遍，零基础、应届生、转行的都适用。跟着走，至少方向不乱、不瞎忙，学完拿得出手。
第一阶段（10天）：初阶应用
这一阶段就一个目标：把大模型真正"玩明白"，不是只会聊天那种，而是能调教它、能用代码把大模型和业务接起来。
- 大模型 AI 能干什么？
- 大模型是怎样获得「智能」的？
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例：向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段（30天）：高阶应用
这阶段正式进实战，目标很实在：做出两个能拿出手的东西——一个私有知识库，一个 agent 对话机器人。
为什么要做 RAG
搭建一个简单的 ChatPDF
检索的基础概念
什么是向量表示（Embeddings）
向量数据库与向量检索
基于向量检索的 RAG
搭建 RAG 系统的扩展知识
混合检索与 RAG-Fusion 简介
向量模型本地部署
…
走完这 30 天，Python 或 JavaScript 背景的基本能独立做一套 RAG 应用，简历上也敢写"大模型应用开发"了。
第三阶段（约20天）：动手微调
学到这，你已经开始 “造” 模型了 —— 通过微调，搞出垂直领域的专用小模型。
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2：手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。
到此为止，大概2个月的时间。你从 “只会用” 变成 “能造” 的 AI 小子。那么你还想往下探索吗？
想要入局AI大模型赛道、抢占行业红利的朋友，微信扫描下方CSDN官方认证二维码，即可100%免费领取全套学习资料！
第四阶段（20天）：商业闭环，部署落地
技术学完，落地才算数。这阶段带你搞明白大模型怎么真正跑起来、用起来。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身：基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例：如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
想要入坑大模型的朋友，给大家准备了一份2026 年最新 AI 大模型全套学习资料：
1、大模型系统化学习路线
2、大模型学习视频教程
3、大模型学习书籍&电子文档
4、AI大模型最新行业报告
5、大模型项目实战&配套源码
6、2026大模型大厂面试真题
7、为什么要学习大模型？
我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年，人才缺口已超百万，凸显培养不足。随着AI技术飞速发展，预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。
8、适合谁学？
- 传统后端 / Java / 前端开发，想转型 AI 应用
- 大学生、应届生，想拿更好的 offer
- 产品经理、运营，想武装职业竞争力
- 技术负责人，想给团队落地提效
学习是反人性的，但回报是真金白银。技术会更新，赛道会切换，但只要你先动手，机会就永远站在你这边。
9、这些资料真的有用吗？
这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。
资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。
想要入局AI大模型赛道、抢占行业红利的朋友，微信扫描下方CSDN官方认证二维码，即可100%免费领取全套学习资料！
好了，就写到这。路线是死的，人是活的，卡住了随时来问我。觉得有用就点个收藏，别让它进收藏夹吃灰——动起来比啥都强。
