AI 智能体分类体系：从大模型到自主智能体的完整图谱

📌 前记

关于智能体的分类，心里一直是比较困惑的，于是想系统地了解下智能体应该如何分类。基于这个背景，笔者花了比较多的时间去调研学术界和工业界对智能体的分类方式，综合了多篇调研报告以及 Anthropic、OpenAI 的官方文档和 LangGraph、AutoGen、CrewAI、Dify 等主流框架的实践，梳理出了一套笔者认为比较合理的分类体系。这篇文章就是这段调研过程的一个系统性整理。

文章的切入点，是从一个笔者个人困惑很久的问题开始的：大模型本质上只是在"预测下一个 token"，它是怎么就突然具备了推理、规划、反思、协作这些"高阶能力"的？理解了这个问题，再去看分类体系，很多东西就清晰了。

🧠 一、大模型是怎么"变成"智能体的

💡 1.1 一个让笔者困惑很久的问题

在聊智能体分类之前，笔者想先说一个一直困扰自己的问题：大模型本质上就是在"预测下一个 token"，它怎么就突然具备了推理、规划、反思、协作这些"高阶能力"？

这个问题其实是理解整个智能体体系的起点。

大语言模型的底层机制确实是基于概率的序列预测——给定前文，预测最可能出现的下一个词。但当模型的参数规模和训练数据达到一定量级后，一些"涌现能力"（Emergent Abilities）开始出现。这些能力并不是被显式编程进去的，而是在海量文本中"学到"的模式。

🔍 1.2 拆解这些"高阶能力"的来源

关于推理：模型在训练中见过大量"前提→推导→结论"的文本模式（数学证明、逻辑论证、代码调试过程等），所以它能"模仿"推理的形式。Chain-of-Thought（思维链）提示之所以有效，本质上是在引导模型走那条"推理模式"的概率路径，而不是走"直接给答案"的捷径。

关于感知与理解：模型本身不"感知"世界，但通过工具调用（Tool Use）和多模态输入，它可以接收来自外部环境的信息——搜索结果、API 返回值、图像描述——然后在上下文中"理解"这些信息并据此决策。这里的"理解"加了引号，因为它更像是"在给定上下文中做出合理的下一步预测"。

关于规划与决策：当我们用 ReAct 或 Plan-and-Solve 这类提示模式时，实际上是在给模型一个"规划的脚手架"——先想、再做、看结果、再调整。模型并没有真正的"意图"，但它见过足够多的"制定计划→执行→调整"的文本模式，所以能在这个框架下表现得像在"规划"。

关于自我反思与修正：Reflexion 这类工作把"反思"变成了一种显式的文本生成过程——让模型对自己的失败轨迹写一段分析，然后在下一次尝试时把这段分析作为上下文输入。模型不是"真的在反思"，而是"在反思模式的提示下生成了看起来像反思的内容"，但效果确实是实实在在的——它真的能在下一轮做得更好。

关于社交与协作：多智能体系统就更有意思了。多个模型实例通过对话交换信息，各自扮演不同角色（产品经理、工程师、测试员），产出互相校验。每个模型实例依然只是在"预测下一个 token"，但整个系统表现出了"协作"的特征。

✅ 1.3 一个关键结论

智能体的"高阶能力"并不是大模型自带的，而是通过架构设计、提示工程和工具集成，把大模型的"预测能力"组装成了"类智能行为"。这也是为什么我们需要一套分类体系——不同的组装方式，对应不同的能力边界、成本结构和适用场景。

理解了这个前提，后面的分类就清晰多了。

🎯 二、为什么需要一套分类体系

📊 2.1 学术界与工业界的视角差异

调研下来，笔者发现学术界和工业界对智能体的分类视角有明显的差异：

学术界倾向于按组件和能力模块来拆解：大脑（LLM）、记忆、规划、工具使用、批评器等，关注的是"这个系统有哪些认知能力"。

工业界更关心控制流和可治理性：这个系统的执行路径是预设的还是动态的？出了问题能不能回滚？成本能不能预测？

两种视角都有道理，但单独用哪一种都不够。笔者认为需要一套既能解释学术文献里的各种范式演进，又能指导工程落地的分类方法。

🧩 2.2 笔者倾向的分类方法

综合三份调研报告的分析，笔者倾向于采用"主轴 + 正交标签"的分类法：

• 主轴解决的是"控制流与自治边界"问题——你的系统到底是人在控制还是模型在控制
• 规划标签解决的是"单体 Agent 的决策机制"问题——它怎么想、怎么做、怎么改
• 协作标签解决的是"组织方式"问题——一个人干还是一群人干、怎么分工

这三层不是互斥的，而是可以组合的。比如你可以描述一个系统为"Agentic Workflow + Plan-Execute + Multi-Agent 层级式"，精准定位它在分类空间中的位置。

🗂️ 三、分类体系总览

📐 3.1 主轴：控制流确定性（从完全预设到完全自主）

🏷️ 3.2 正交标签一：规划机制

🏷️ 3.3 正交标签二：协作形态

📈 四、主轴详解：从 Workflow 到 Autonomous Agent

⚙️ 4.1 L1：Workflow（确定性编排）

Workflow 是最简单也最可控的形态。所有的执行路径在设计时就已经确定——哪一步调哪个 API、什么条件走哪个分支、出错了怎么处理，全部预设好了。LLM 在其中只是一个"执行节点"，比如做文本总结、做意图分类、做内容生成，但它不决定流程走向。

LangGraph 官方文档对此给出了清晰定义：Workflow 是"预设代码路径、按一定顺序执行"的系统。典型的实现模式包括 Prompt Chaining（提示链）、Routing（路由）、Parallelization（并行化）等。

举个例子：一个客服工单处理系统。用户提交工单后，系统先用 LLM 做意图分类（退款/咨询/投诉），然后根据分类结果走不同的预设分支——退款走退款流程、咨询走知识库检索、投诉走人工转接。每一条路径都是提前定义好的，LLM 只负责"判断走哪条路"和"生成回复内容"，不负责"决定要不要走"。

优势：可控、可测、可审计、成本可预测。你可以精确知道每一次执行会经过哪些步骤、调用多少次模型、花多少钱。

局限：面对不确定的问题需要频繁扩展规则，泛化能力弱。一旦业务场景超出预设路径，整个系统就需要重新设计。

适用场景：业务流程自动化、合规要求高、步骤稳定、异常可枚举的任务。

🔀 4.2 L2：Agentic Workflow（可控自治）

这是笔者认为当前最值得关注的"甜点区"。Agentic Workflow 的主体仍然是流程，但它承认一个现实：总有一些步骤是没法预设的。所以它在流程的关键环节嵌入了"自治决策节点"，让 LLM 在受限的范围内自主决策。

Dify 的 Agent Node 是这种形态的典型产品化实现：在一个可视化 Workflow 中，大部分节点还是确定性的（数据查询、格式转换、条件分支），但某个节点是 Agent Node——它可以在迭代循环中决定是否调用工具、调用哪个工具、何时结束。Agent Node 支持 Function Calling 和 ReAct 两种策略，可以根据模型能力选择。

CrewAI 走的是另一条路：它把流程分为 Flows（事件驱动的确定性骨架）和 Crews（多智能体团队），Flows 控制宏观流程走向，Crews 在各阶段内提供角色自主协作。

LangGraph 则通过 conditional edges（条件边）来实现这种混合——在确定性图结构中嵌入 LLM 驱动的动态分支。

这种中间形态在工业上有两种常见的实现模式：

Agent-in-Workflow：在流程中嵌入 Agent 节点，把"最难预设的一段"交给 LLM。比如一个数据分析流程，大部分步骤是确定的（数据拉取→清洗→入库），但"分析报告生成"这一步交给 Agent 来做，因为分析角度和深度取决于数据本身。

Workflow-as-a-Tool：反过来，把一段确定性流程封装成"工具"，由 Agent 在闭环中决定何时调用。比如 Agent 在推理过程中判断"需要查询数据库"，就调用一个预定义好的数据查询子流程。

这两种模式可以叠加——流程里有 Agent 节点，Agent 节点又可以调用封装好的子流程工具，形成"分层自治"。

举个例子：一个电商营销活动策划系统。整体流程是确定的：分析历史数据→生成策划方案→审核→执行→复盘。但"生成策划方案"这一步是 Agent Node，它需要根据数据分析结果，自主决定要不要调用竞品分析工具、要不要查询用户画像、最终生成什么样的方案。它有工具调用的自主权，但它的输出必须符合下一个审核节点的格式要求，它的迭代次数有上限，它能用的工具有白名单。

优势：在可控边界内引入自治，降低落地门槛，适合灰度升级。

局限：边界设计是个技术活——迭代次数、工具权限、退出条件、可观测日志都需要精心设计。

适用场景：半结构化任务——部分步骤确定、部分需要动态决策的场景。笔者认为目前绝大多数企业级 AI 应用其实都落在这个区间。

🤖 4.3 L3：Autonomous Agent（闭环自主执行）

到了这一层，控制权彻底交给了模型。Agent 在循环中自主决定下一步动作、选择工具、处理结果、判断是否继续。没有预设的执行路径，只有目标和约束条件。

LangGraph 对此的定义是：Agent 是"动态定义过程与工具使用"的系统，适用于"问题和解法都不可预测"的场景。

这类系统的内部机制差异很大，所以需要用规划标签来细分（详见第五节）。但无论内部机制如何，它们有几个共同特征：LLM 掌握执行的控制权、存在与环境的闭环反馈、步骤数量不可预测、需要强终止策略和运行时治理。

举个例子：一个自主代码调试 Agent。你给它一个 bug 报告，它自己去读代码、定位问题、尝试修复、运行测试、如果测试失败就分析原因继续修、直到测试通过或达到迭代上限。整个过程没有预设路径，每一步都是根据当前状态动态决定的。

优势：面对开放性问题具有最强的灵活性和适应性。

局限：成本不可预测、容易陷入无效循环、调试困难、需要完善的治理机制。

适用场景：问题开放、路径不确定、需要持续与环境交互的任务。

🚦 4.4 从 Workflow 到 Agent：什么时候该升级

这是一个非常实际的问题。笔者从调研报告中提炼了三组"强信号"：

信号一：不可预测性上升。 当任务的起始点是高度模糊的自然语言输入，且无法通过关键词映射到特定分支时；当业务逻辑涉及数百个潜在工具或分支，导致硬编码的决策树出现"逻辑爆炸"时——你需要让模型来做决策。

信号二：中间结果依赖。 当工具链的选择和顺序依赖中间结果，且工具失败或返回异常需要动态改道时——Workflow 的静态路径扛不住这种动态性。

信号三：自修复需求。 当业务场景要求系统能从执行失败中自动学习并调整策略，而不是简单报错停止时——你需要反思和自改进机制。

但升级不是越高越好。Anthropic 在"Building Effective Agents"中的核心建议是"从最简单的方案开始，只在确实需要时增加复杂性"。能用 Workflow 解决的，就不要上 Agent。能用 Agentic Workflow 解决的，就不要用 Autonomous Agent。因为每一层升级都意味着更高的成本、更低的可预测性和更复杂的治理需求。

🧭 五、规划机制详解：自主 Agent 内部怎么分

"自主规划 Agent"这个大类内涵太宽了。一个简单的 ReAct 循环和一个 LATS 树搜索系统，虽然都叫"自主 Agent"，但复杂度、成本和能力边界完全不同。所以需要用规划机制标签来细分。

⚡ 5.1 Reactive（ReAct 系）

ReAct 的核心贡献是把"推理轨迹"和"任务动作"交错生成：Thought→Action→Observation 循环。推理帮助模型跟踪状态和处理异常，行动让模型能访问外部信息源来减少幻觉。

它的优点是简单直接、对不确定环境鲁棒；缺点是每步都需要模型参与（成本线性增长）、没有全局规划（纯贪心决策）、容易陷入循环。据报告，ReAct 仅约 30% 的时间能成功完成复杂任务。

例子：一个网页信息检索 Agent。用户问"帮我查一下特斯拉最新季度的营收数据"，Agent 先想"我需要搜索特斯拉财报"，然后执行搜索，看到结果后想"这个数据是去年的，需要更精确的查询"，再次搜索，找到结果后提取数据返回。每一步都是根据上一步的观察即时决定的，没有提前规划。

📋 5.2 Plan-Execute（先规划后执行）

Plan-and-Solve 的核心思想是"先把任务拆成子任务，再按计划求解"。工业实现中，LangGraph 把它抽象为 Planner→Executor→Replanner 的三段式：Planner 生成多步计划，Executor 执行每一步，执行后 Replanner 判断是否需要修改后续计划。

相比 ReAct，它的优势在于减少了每步都"问大模型"的成本（子任务执行可以用轻量模型），而且强制了全局思考。劣势是计划质量决定了上限，遇到意外需要重规划，否则容易失败。

例子：一个数据分析 Agent。用户说"帮我分析一下上个月的销售数据，找出下滑的品类，给出改进建议"。Agent 先规划：1) 拉取上月销售数据 2) 按品类聚合 3) 与前月对比找出下滑品类 4) 分析下滑原因 5) 生成改进建议。然后逐步执行，如果第 2 步发现数据格式异常，就触发重规划调整后续步骤。

🔄 5.3 Adaptive Decomposition（按需分解）

ADaPT 针对的是一个很现实的问题：子任务的难度分布不均。有的子任务简单，一步就能完成；有的子任务复杂，当前执行器根本搞不定。ADaPT 的做法是：先尝试直接执行，如果失败了，就把这个任务递归分解成更小的子任务，直到每个子任务都在执行器的能力范围内。

这种"按需分解"比静态规划更能处理复杂度不均的任务。在 ALFWorld 上比基线高 28.3%，在 WebShop 上高 27%。

例子：一个企业流程自动化 Agent。用户说"帮我完成新员工入职流程"。Agent 先尝试直接执行，发现"IT 设备配置"这个子任务太复杂，就把它分解为"申请笔记本→配置 VPN 账号→安装开发环境→设置邮箱"四个更细的子任务，每个交给对应的工具去执行。如果"配置 VPN 账号"又失败了（比如需要审批），就继续分解为"提交审批→等待→配置"。

🌳 5.4 Search-based（搜索式规划）

LATS 把规划过程建模为一棵搜索树，用蒙特卡洛树搜索（MCTS）在多个候选行动路径间探索和回溯。与 ReAct 的单轨迹贪心搜索不同，LATS 能在"虚拟大脑"中预演多种可能的结果，用价值函数评估各路径的潜在收益，选择最优路径。

在 HumanEval 编程基准上达到 94.4% 准确率（ReAct 约 30%，Reflexion 约 91%）。代价是计算成本显著增加。

例子：一个代码生成 Agent。给定一个编程题，Agent 不是直接写一个解法然后提交，而是同时探索多种解题思路（递归、动态规划、贪心），对每种思路生成代码并用测试用例评估，如果某条路径跑不通就回溯尝试其他路径，最终选择通过率最高的方案。

🪞 5.5 Reflection（反思自改进）

Reflexion 的核心是"不更新权重，而是通过语言反馈来改进"。当任务失败时，模型会对自己的失败轨迹写一段反思分析，存入长期记忆，在下一次尝试时作为额外上下文指导改进。

它在 HumanEval 上将准确率从 GPT-4 的 80% 提升至 91%，本质上是一种"不更新参数的强化学习"。

例子：一个自动化测试 Agent。它运行测试套件，发现有 3 个用例失败。它分析失败原因，生成反思："测试失败是因为我在处理边界条件时没有考虑空数组的情况，下次应该先检查输入是否为空"。这段反思被存入记忆，下次修复代码时，Agent 会自动参考这些反思来避免同样的错误。

⚠️ 5.6 一个重要提醒：这些机制不是互斥的

在实践中，ReAct 和规划经常以混合形式出现。LangGraph 的 Plan-and-Execute 就是最典型的混合架构：Planner 用大模型生成全局步骤列表，每个步骤由 ReAct 式 Agent（可以用小模型）执行，执行后进入 replan 节点动态调整。LATS 在树搜索中嵌入 ReAct 轨迹，ADaPT 用 ReAct 式执行器配合递归规划器。

🤝 六、协作形态与多智能体通信

💡 6.1 多智能体不是第三类应用，而是一种组合模式

这一点笔者认为很关键。多智能体不应该和 Workflow、Agent 并列成为"第三类"——它是一个正交维度，可以叠加在任何控制流形态上。

一个 Workflow 可以有多智能体（比如多个 Agent 并行处理不同分支后投票决策）。一个 Agentic Workflow 可以有多智能体（比如 CrewAI 的 Flows+Crews）。一个 Autonomous Agent 更可以有多智能体（比如 AutoGen 的多 Agent 对话协作）。

📌 6.2 什么时候需要多智能体

OpenAI 提出了两个触发信号：复杂逻辑（提示词包含太多条件语句）和工具过载（工具间存在相似性或重叠）。把 50 个工具分散给多个专精 Agent，效果远好于让一个 Agent 管理所有工具。

另外几个场景也适合多智能体：任务需要多领域专业知识、任务可大规模并行、需要交叉验证（多 Agent 互审能显著降低幻觉率）。

但多智能体也有代价：token 消耗约为单 Agent 的 15 倍，通信开销大，稳定性更难保障。简单聚焦任务、实时延迟要求高、预算有限的场景，应该坚持单 Agent。

例子：一个软件开发多智能体系统。产品经理 Agent 负责需求分析和文档输出，架构师 Agent 负责技术方案设计，工程师 Agent 负责代码实现，QA Agent 负责测试和 bug 发现。它们通过消息传递协作，QA Agent 发现的 bug 会传回工程师 Agent 修复，工程师的修复方案又会被架构师 Agent 审核。这就是 MetaGPT 的核心模式——把软件开发的 SOP 映射到多智能体协作流程中。

🔗 6.3 多智能体通信：同平台用框架协议，跨平台用 A2A

当我们谈多智能体协作时，有一个绕不开的问题：这些 Agent 之间怎么通信？

答案取决于你的系统边界在哪里。

📡 同一平台/框架内：用框架自带的通信机制

如果你的多个 Agent 都运行在同一个框架内——比如都在 AutoGen 里、都在 CrewAI 里、都在 LangGraph 里——那直接用框架内置的通信协议就好。

• AutoGen 用的是多 Agent 对话：Agent 之间像在聊天室里一样通过文本消息交互，支持双 Agent 对话、群聊、嵌套对话等模式。通信基于内存中的消息传递，简单直接。
• CrewAI 用的是任务委派和消息传递：Manager Agent 通过任务分配把工作下发给 Worker Agent，Worker 通过任务结果回传。
• MetaGPT 用的是共享消息池（Pub-Sub 模式）：所有 Agent 把消息发布到一个共享池中，其他 Agent 根据自己的角色订阅感兴趣的消息。
• LangGraph 用的是图状态传递：Agent 之间通过共享的图状态（State）来传递信息，每个 Agent 节点读取状态、执行操作、更新状态。

这些框架内协议的共同特点是：低延迟、紧耦合、适合同一进程或同一服务内的通信。

🌐 跨网络、跨组织、跨平台：A2A 协议

但如果你的 Agent 分布在不同的平台上——比如你的客服 Agent 在 LangGraph 上，供应商的库存 Agent 在另一个框架上，第三方的物流 Agent 又在另一个平台上——框架内协议就不够用了。这时候需要一个跨平台的标准协议。

Google 在 2025 年 4 月发布了 Agent2Agent（A2A）协议，就是为了解决这个问题。A2A 在 2025 年 6 月被捐赠给 Linux 基金会，成为开放治理项目，截至目前已有超过 150 个组织支持。

A2A 的核心机制包括：

能力发现（Capability Discovery）：每个 Agent 发布一个 Agent Card（JSON 格式的能力描述文件，托管在 /.well-known/agent.json），其他 Agent 可以通过这个文件了解它的能力、支持的模态、认证要求等。类似于人类世界的"名片"。

任务管理（Task Management）：通信以"任务"为核心单位。Client Agent 向 Remote Agent 发送任务请求，Remote Agent 处理任务并返回状态更新和结果。任务有明确的生命周期（创建→处理中→完成/失败）。

多模态支持：A2A 不限于文本，还支持音频、视频、结构化数据等多种模态的交换。

安全机制：基于 OAuth 2.0、PKCE 和 API Key 等标准安全实践，保证跨组织通信的安全性。

🔀 A2A 和 MCP 的关系

这里需要澄清一个常见的困惑。MCP（Model Context Protocol，Anthropic 推出）和 A2A 不是竞争关系，而是互补关系。MCP 解决的是"Agent 与工具/数据源之间的连接"（纵向集成），A2A 解决的是"Agent 与 Agent 之间的协作"（横向通信）。一个典型的架构是：Agent 通过 MCP 连接到自己需要的工具和数据，然后通过 A2A 与其他 Agent 协作完成复杂任务。

举个例子：一个跨组织的供应链协作系统。零售商的库存管理 Agent（运行在自己的平台上）通过 MCP 连接到内部的 ERP 系统获取库存数据。当发现某商品即将缺货时，它通过 A2A 协议联系供应商的订单处理 Agent（运行在供应商的平台上），发起采购任务。供应商的 Agent 处理订单后，又通过 A2A 通知物流公司的配送 Agent 安排发货。三个 Agent 分属三个组织，运行在三个不同的平台上，但通过 A2A 实现了无缝协作。

简单总结这个选择逻辑：同一个框架内的 Agent 通信，用框架自带的协议就够了；一旦涉及跨网络、跨组织、跨平台的 Agent 协作，就应该考虑 A2A 这样的标准化协议。

🏗️ 七、Autonomous Agent 对编排框架和平台的额外要求

前面说到，Workflow 和 Agentic Workflow 对框架的要求相对"常规"——本质上就是流程编排、状态管理、条件分支这些能力。但一旦升级到 Autonomous Agent，对编排框架和平台的要求就会陡然上升。笔者认为这一点在做架构选型时非常重要，所以单独拿出来说一下。

⚙️ 7.1 动态控制流支持

Workflow 的控制流是静态的——DAG（有向无环图）在设计时就确定了。但 Autonomous Agent 的控制流是动态的——Agent 在运行时决定下一步走哪里、调用什么工具、是否需要回溯。

这意味着框架必须支持运行时动态构建执行图。LangGraph 通过 conditional edges 和 state-driven routing 来实现这一点；但如果你的框架只支持静态 DAG，那就没法跑真正的 Autonomous Agent。

💾 7.2 可靠的状态持久化与检查点机制

Autonomous Agent 的执行可能很长——几十步甚至上百步。如果中间某步失败了、或者需要人工介入、或者模型调用超时，你需要能从某个检查点恢复，而不是从头重来。

框架需要提供细粒度的状态持久化——不是只在流程开始和结束时存状态，而是每一步都要能存、能恢复。

🛡️ 7.3 严格的运行时治理（Guardrails）

Autonomous Agent 最大的风险是"失控"——无限循环、上下文膨胀、越权操作、成本爆炸。框架必须提供一套完整的治理机制：

• 迭代次数上限：防止 Agent 陷入死循环
• Token/成本预算：到了预算上限强制停止
• 工具调用白名单：Agent 只能调用被授权的工具
• 超时策略：单步执行和整体执行都要有超时
• 人工介入点（Human-in-the-Loop）：在关键决策点暂停，等待人工确认后再继续

🔭 7.4 全链路可观测性

当 Agent 自主执行了 30 步后给出一个错误结果，你怎么排查？你需要看到每一步的推理过程、工具调用参数和返回值、状态变化、以及模型的"思考"过程。

框架必须支持全链路日志记录和追踪（tracing），并且这些日志要有结构化的格式，方便事后分析和可视化。如果框架只给你一个最终输出，中间过程全是黑盒，那在生产环境中根本没法用。

🧠 7.5 记忆管理

Autonomous Agent 需要多种记忆：

• 短期记忆（Working Memory）：当前任务的上下文，包括已执行的步骤、中间结果、工具返回值
• 长期记忆（Episodic/Semantic Memory）：跨任务的经验积累，比如 Reflexion 生成的反思摘要
• 共享记忆（Shared Memory）：多 Agent 系统中 Agent 间共享的信息

框架需要提供灵活的记忆存储和检索机制，包括上下文窗口管理（避免超长上下文导致性能下降）、记忆的版本化和回滚（防止"记忆污染"）。

🔧 7.6 灵活的工具注册与路由

Autonomous Agent 的核心能力之一是"动态选择和调用工具"。框架需要支持工具的动态注册和发现（Agent 能知道有哪些工具可用）、工具描述的质量管理（描述不清晰会导致 Agent 选错工具）、以及工具调用结果的标准化。

📊 7.7 各层级对框架能力的要求对比

这就是为什么不应该轻易升级到 Autonomous Agent——不仅是模型能力的问题，你的整个基础设施和治理体系都需要跟上。

🎬 八、用几个实际例子把分类串起来

最后，笔者用几个场景把整套分类体系串起来，帮助大家直观理解每种分类在实际中的对应。

🎯 场景一：智能客服

一个标准的客服系统：用户输入→意图识别→路由到对应处理流程→生成回复。所有路径预设好，LLM 负责意图分类和回复生成。

Workflow + Single Agent

🎯 场景二：智能营销助手

一个营销活动策划系统。整体流程是固定的（数据分析→策划→审核→执行），但"策划"环节是 Agent Node，它用 ReAct 模式来动态调用市场分析工具、竞品数据 API、用户画像系统，逐步构建策划方案。

Agentic Workflow + Reactive + Single Agent

🎯 场景三：数据分析报告生成器

用户说"分析上季度销售数据并生成报告"。系统整体是流程化的，但分析环节是 Agent Node，它先规划分析步骤（拉数据→按维度聚合→趋势分析→异常检测→生成报告），然后逐步执行，中间根据数据特征动态调整分析方向。

Agentic Workflow + Plan-Execute + Single Agent

🎯 场景四：自主代码调试

给定一个 bug 报告，Agent 自主读代码、定位问题、尝试修复、运行测试。如果测试失败，反思失败原因并记入记忆，在下一次修复时参考之前的反思避免重复犯错。

Autonomous Agent + Reflection + Single Agent

🎯 场景五：复杂编程竞赛

给定一道算法题，Agent 用 LATS 在多种解法间探索——递归、DP、贪心各试一遍，用测试用例评估每种方案，选择最优解。

Autonomous Agent + Search-based + Single Agent

🎯 场景六：软件开发团队

一个类 MetaGPT 的系统：产品经理 Agent 分析需求、架构师 Agent 设计方案、工程师 Agent 写代码、QA Agent 测试。Manager Agent 按 SOP 分配任务并协调进度。Agent 之间通过共享消息池通信，框架内协议搞定。

Autonomous Agent + Plan-Execute + Multi-Agent 层级式

🎯 场景七：跨企业供应链协调

零售商的库存 Agent 发现缺货，通过 A2A 协议联系供应商的订单 Agent 下单，供应商的 Agent 又通过 A2A 通知物流 Agent 发货。三方 Agent 分属不同组织和平台，通过 A2A 实现跨组织协作。每个 Agent 内部可能是一个 Agentic Workflow。

Agentic Workflow + Reactive + Multi-Agent 对等式（A2A 跨平台通信）

✍️ 九、结语

回到开头的问题：大模型只是在预测下一个 token，但通过不同的架构设计，我们可以把这种基础能力组装成从简单工作流到复杂自主系统的完整谱系。

笔者整理的这套分类体系的核心逻辑是三层：

第一层，用主轴回答"谁在控制"——Workflow（系统控制）→ Agentic Workflow（共享控制）→ Autonomous Agent（模型控制）。

第二层，用规划标签回答"怎么思考"——Reactive / Plan-Execute / Adaptive Decomposition / Search-based / Reflection。

第三层，用协作标签回答"几个人干"——Single / Multi-Agent，以及协作模式的选择。

在实际选型中，笔者认为最重要的一条原则是 Anthropic 说的那句话：从最简单的方案开始，只在确实需要时增加复杂性。能用 Workflow 搞定的就不要上 Agent，能用单 Agent 搞定的就不要上多 Agent，能在框架内通信的就不要引入跨平台协议。每一层复杂性都需要对应的工程能力来支撑，否则就可能是在给自己挖坑。