AI Agent 架构怎么选?从单 Agent 到图工作流,一篇讲清 7 种常见模式

做 AI 应用时，很多团队都会经历一个相似的过程：最初，把用户请求交给大模型，再接上几个工具，演示效果就已经不错。随着业务增长，问题开始出现——工具越来越多，指令相互干扰；任务越来越长，执行容易跑偏；参与协作的 Agent 越来越多，却很难判断错误发生在哪一步。

这时，真正需要解决的是任务如何组织、能力如何选择，以及执行过程如何被控制。

架构没有脱离场景的绝对优劣。选型取决于任务的不确定性、协作需求，以及业务对成本、延迟和控制力的要求。

本文整理七种常见模式，用同一类企业办公与数据分析场景，讲清它们的工作方式、收益和代价。

单 Agent 与 Multi-Agent 描述的是执行者如何组织；ReAct 与 Plan & Execute 描述的是任务怎样推进；Router + Skill 描述的是能力如何选择和加载；Blackboard 描述的是共享状态怎样驱动协作；Graph Workflow 描述的是执行路径如何编排。

因此，一个系统完全可以同时采用“单 Agent + Router + Skill + ReAct”，再由 Graph Workflow 管理必须经过的检查和审批节点。

Anthropic 对 Agent 与 Workflow 的区分也有参考价值：前者由模型动态决定执行过程，后者主要沿程序预定义的路径推进。两类机制可以组合使用。参考：Building effective agents

单 Agent 架构由一个 Agent 接收目标、调用模型、选择工具并完成任务。下图展示一次典型执行片段；实际任务可以多次调用工具。

例如，用户要求“查询某个客户的订单状态”。Agent 识别客户信息，调用订单查询接口，再把结果整理成自然语言返回。

它的主要优势是结构简单、起步成本低。执行者只有一个，任务上下文和工具调用较容易追踪，也省去了多个 Agent 之间的交接开销。

但简单结构并不保证低延迟。如果这个 Agent 需要连续调用十次模型和工具，用户一样可能等待很久。当你把大量技能、工具说明和历史记录都塞入同一份上下文时，也容易出现信息干扰、选错工具和指令遵循下降。

单 Agent 适合能力边界清晰的客服助手、知识问答、订单查询和业务原型。它也可以承担复杂任务，只要上下文与工具设计足够合理。

另外，多用户并发主要由服务调度、资源限额和会话隔离解决，不能只凭“单 Agent”判断系统能否承受并发。

ReAct 是 Reasoning + Acting，强调推理与行动交替进行：判断下一步，调用工具，观察真实结果，再决定后续动作。参考：ReAct 论文

用户问“本月销售额为什么下降”。Agent 先查询总销售额，发现下降主要集中在华东地区；接着查询华东地区的渠道数据，再检查促销记录。每一次工具返回，都改变下一步的调查方向。

ReAct 适合路径无法提前写死的探索性任务。故障排查、资料搜集和代码修复，都需要根据环境反馈继续推进。

代价是执行步数难以预测。错误判断可能影响后续操作，反复尝试还会增加 Token 消耗、接口成本和延迟。因此，需要设计次数上限、超时、关键结果检查与失败退出机制。

它的可解释性更多来自可记录的行动轨迹：调用了什么工具、得到什么结果、为什么选择某条业务路径。生产系统不应把公开模型完整思考过程当作审计的前提，也不能把模型给出的解释当作事实证据。

Plan & Execute 把“规划”和“执行”分开：规划器先拆解任务，执行器负责落实步骤，并通过检查决定继续执行还是调整计划。

例如，“收集三个区域的销售数据，分析差异，形成报告”。系统先生成计划：确认统计口径、读取数据、完成比较、撰写报告、验证结论。每一步有明确输入、输出和完成条件。

它的价值在于，让长任务有可检查的阶段和进度。数据缺失或某一步失败时，系统可以定位问题，而不是重新猜测整个任务应该怎样做。

不过，长任务不会因为增加一份计划就自动稳定。如果第一步的统计口径错了，后续步骤执行得再认真，也可能得到错误结论。

静态计划适合环境稳定、步骤明确的任务；带重规划的版本更适合会变化的环境。执行结果偏离预期时，系统应调整剩余步骤，必要时回到用户处澄清目标。

选择这类架构时，重点设计计划粒度、步骤验收和失败恢复。文件生成、批量数据处理等分阶段任务，往往比较适合。

Multi-Agent 用多个 Agent 分工协作。常见组织方式是一个协调 Agent 拆分任务，各个专家 Agent 完成子任务，再提交结果进行整合。下图展示一种协调者与专家分工的实现。

例如，一份行业报告可以由调研 Agent 收集资料，分析 Agent 整理数据，评审 Agent 检查论证，最后由协调者整合。

当任务能分拆，并且各部分需要不同上下文或工具时，分工才有实际收益。独立子任务还可以并行执行，缩短整体等待时间。

但上下文隔离需要显式设计。只设置几个不同的角色提示词，随后把全部历史共享给所有 Agent，并不能有效减少信息干扰。子任务的范围、输入、结果格式和证据来源都应该明确。

多 Agent 还会增加交接、汇总和协调成本。自由互相通信容易产生重复工作、矛盾结论和难以追踪的依赖；如果采用清晰的协调者—执行者结构，复杂度通常更容易控制。

不要预设通信开销一定巨大，或调试难度必然指数增长。应测量新增协作带来的收益是否超过额外成本，再决定是否拆分。

Router + Skill 把通用决策与领域能力分开：Router 识别任务类型，选择对应 Skill；执行器加载该技能的说明、资源和工具，完成工作并检查结果。

例如，用户要求“生成销售报表”，系统加载报表技能；用户要求“整理会议纪要”，系统加载文档技能。无法可靠匹配时，进入澄清或人工处理路径。

这里可以用一句话概括：把无边界的自由发挥，收敛为在明确能力范围内选择和执行。

Skill 不一定是独立 Agent。它可以是一组操作说明、脚本、模板和检查规则，由同一个 Agent 按需使用。先读取技能简介，选中后再加载详细内容，也能减少无关上下文。参考：Agent Skills 工程说明

对于任务分类清楚、技能能够标准化的企业 Copilot，这是一个值得优先评估的方案：能力边界容易定义，技能可以独立维护和评测，也方便观察路由正确率与任务完成率。

但它并不自动带来“极低幻觉”。错误路由、过时技能、不可靠数据和缺少结果校验，都可能造成错误。路由器也应允许“无法确定”，而不是强制从候选项中选择。

缓存同样要区分对象：技能定义和静态模板通常容易缓存；涉及实时订单、用户权限或库存的结果，需要明确更新和隔离策略。

它的长期成本集中在技能治理：划清适用范围、减少能力重叠、管理版本、维护测试样例，并让权限检查落在真实执行层。对于高频且可标准化的办公任务，这些投入通常比不断扩大一个通用提示词更容易管理。

Blackboard，也就是黑板架构，把目标、证据、假设和中间结果放入共享工作区。多个专家模块观察这些信息，在能够推进问题时执行，并把新发现写回。调度逻辑可以集中在控制器中，也可以有其他组织方式。参考：Blackboard Systems

例如调查销售异常：数据专家写入“华东渠道 A 订单量下降”；诊断专家据此提出“流量是否减少”；另一个模块查询活动记录，把“促销结束”作为待验证假设写入黑板。

它适合证据不断出现、下一步取决于新发现的协作任务。与固定分工相比，专家可以围绕正在形成的问题认识，接续补充信息。

黑板不能只是一个所有人随意追加文字的聊天窗口。事实与假设要区分，证据要有来源，更新要有版本，不同结论之间的冲突要被保留和处理。

状态管理混乱、追责困难是需要防范的工程风险，并非黑板架构的必然结果。结构化状态、写入者标识、变更日志与调度记录，可以提高溯源能力。

此外，专家模块可以是 Agent，也可以是普通程序或规则引擎。共享数据库只是基础设施；围绕状态变化组织协作，才是黑板架构的关键。

Graph Workflow 用节点表示处理步骤，用边表示执行关系，用状态保存任务进度。系统沿图推进，在指定位置分支、汇合、检查或等待人工处理。

例如，销售报告必须经过“准备数据 → 生成报告 → 检查报告”。检查通过才输出；可修正的问题进入修改节点；超过重试上限则转人工处理。

它的优势是执行路径明确，容易定位失败位置，也便于把业务规则落实为必须经过的节点。

这里需要纠正一个常见表述：Graph Workflow 不一定是 DAG。DAG 是有向无环图，适合没有回路的依赖关系；如果“修改后再次检查”被表示为返回边，图中就存在循环。节点内部重试，也可以不改变外层 DAG 的结构。LangGraph 的图 API 则明确支持包含循环的执行图。参考：Graph API 文档

长流程还需要执行引擎提供状态持久化、恢复、并行调度和错误处理。画出流程图本身，不等于这些能力已经具备。

它适合审批、订单处理、文档生产等步骤边界较清楚、过程要求较高的任务。前期成本在于梳理状态和异常路径；业务经常变化时，还要考虑图的维护与版本兼容。

尤其要记住：回到前一个节点，不代表自动撤销之前产生的业务操作。付款、发消息或创建订单等动作，应设计防重复执行与补偿机制。

第一，下一步能不能提前确定？能确定，优先评估固定工作流或图工作流；要根据结果探索，可以采用 ReAct；目标很长但阶段可拆，可以增加规划与进度检查。

第二，能力能不能按业务分类？报表、文档、客服等类别清楚时，可以采用 Router + Skill。对跨越多个类别的请求，还需要任务拆解或流程编排。

第三，任务是否真的需要多个执行者？能独立分拆、需要并行或不同上下文时，再评估 Multi-Agent。主要难点在证据共享和动态接续时，可以考虑 Blackboard。

第四，业务要求控制到什么程度？如果某个检查、审批或权限判断必须执行，就应由程序和流程保证。只在提示词中写“请严格遵守”，不足以形成可靠的执行约束。

可以把各类模式的典型定位记成下面七句话：

• 单 Agent：先用一个执行者跑通闭环。
• ReAct：根据反馈探索下一步。
• Plan & Execute：把长目标拆成可检查的阶段。
• Multi-Agent：让可分拆的工作分工协作。
• Router + Skill：把高频任务交给对应能力处理。
• Blackboard：围绕共享证据动态推进问题。
• Graph Workflow：把执行路径和业务关卡明确下来。

这条路径描述了一些系统随着业务增长增加组织能力的过程，却不是所有 Agent 都必须经历的升级路线。

有的企业任务从第一天就适合流水线；有的复杂任务由一个配置合理的 Agent 就能完成；有的图工作流，只在个别节点需要多个 Agent 协作。

更实用的演进方式是：先完成最小闭环，再根据实际瓶颈增加机制。能力选择混乱，就增加路由和技能；长任务偏离目标，就增加规划与检查；独立任务执行太慢，就引入并行；业务过程难以控制，就补充图编排与状态管理。

对于技能分类明确的企业 Copilot，我会优先评估“单 Agent + Router + Skill”，并在需要控制的步骤加入工作流。这是一条有条件的工程建议；最终应通过代表性任务，比较成功率、错误率、延迟、成本和人工接管比例。

好的架构，应当让业务完成得更可靠，让错误更容易被发现，也让团队承担得起长期维护成本。