定位：专业复盘体 + 分点 + 图 + 完整信息密度。原稿：《Agent架构的分层设计与生产落地》

最近我在给一个故障诊断 Agent 做技术选型。一开始的做法很直接：把 LangChain、LangGraph、AutoGen、CrewAI、Dify 等框架列成清单，逐项对比功能。

但对比到后面我发现，这种做法得不出结论。因为现在这些框架的功能边界已经高度重合：Graph 框架可以编排多个 Agent，Multi-Agent 框架也可以定义固定流程，RAG 框架开始支持 Agent，低代码平台也提供 Workflow、Memory 和 Tool Calling。

所以我调整了评估方式，改成围绕几个关键问题来判断。在展开这些问题之前，先把两个基础概念理清。

Agent 框架是什么

Agent 框架是模型与业务系统之间的一层运行基础设施。单独的大模型通常只能完成一次输入和一次输出，而一个完整的 Agent 还要解决一系列问题：

  1. 如何调用外部工具
  2. 如何保存任务状态
  3. 如何决定下一步操作
  4. 如何完成多步骤任务
  5. 如何让多个 Agent 分工
  6. 如何接入知识库
  7. 如何处理失败、重试和恢复
  8. 如何记录执行过程
  9. 如何引入人工审批

不同框架的差异，本质上来自它们优先解决的问题不同。几个主流框架的核心抽象对比如下：

框架 核心抽象 优先解决的问题
LangGraph、Spring AI Alibaba Graph Node、Edge、State 有状态流程编排
AutoGen Agent、Message、Conversation Agent 间消息协作
CrewAI Role、Task、Crew 角色分工和任务协作
LlamaIndex Document、Index、Retriever 数据接入和知识检索
Dify、N8n 可视化节点 低代码交付

所以选型的第一步，是明确当前系统最需要保证的能力：是流程正确、模型自主，还是高风险人工介入、状态持久与断点重试。

Graph 与 Multi-Agent 的关系

这里有个容易混淆的地方：Graph 和 Multi-Agent 并非互斥的框架类型。

Graph 是一种流程编排和执行方式，解决「整个任务按什么顺序和规则执行」；Multi-Agent 是一种系统架构，解决「哪些 Agent 参与任务、如何分工协作」。

在 LangGraph 或 Spring AI Alibaba Graph 中，一个 Node 可以是普通函数、工具调用、LLM 调用，也可以是一个完整的 Agent。所以 Graph 完全可以用来编排 Multi-Agent，例如：

Supervisor Agent → Research Agent → Coding Agent → Review Agent →（不通过则返回 Coding Agent）

这是一个 Graph，同时也是一个 Multi-Agent 系统。反过来，多个 Agent 也可以像 AutoGen 那样，通过消息和对话动态协作。

更准确的理解是：Multi-Agent 描述「谁和谁协作」，Graph 描述「协作过程如何执行和流转」。

控制权：交给代码还是模型

Agent 系统首先要在确定性和自主性之间做取舍，两端各有利弊：

  1. Graph/Workflow（代码强控制）：节点、状态、流转规则都由代码显式定义。适合业务步骤明确、执行路径需要审计、需要人工审批、需要暂停恢复、失败后要从指定节点重试的场景。典型例子是退款流程：识别原因 → 查询订单 → 判断条件 → 人工审批 → 执行退款 → 通知用户——这类流程涉及权限和合规，不应完全交给模型自主决定。
  2. Agent Loop（模型高自主）：由模型自主完成「观察 → 判断 → 调用工具 → 获取结果 → 再判断」的循环。适合任务步骤无法提前确定、需要动态探索、工具组合取决于中间结果的场景，例如「研究一项新技术并形成报告」。但自主性越高，代价越明显：执行路径难预测、容易无效循环、token 与工具调用成本不稳定、失败难定位、测试审计更困难。

因此生产系统通常会在两端之间做组合：外层用 Graph 控制关键流程，节点内部允许 Agent 自主规划和调用工具。核心区别在于，主要控制权放在显式规则上，还是放在模型自主上。

是否拆分多 Agent

我遇到过这个纠结：任务复杂，是不是就应该上多 Agent。后来发现，多数情况并不需要。

一个设计得当的单 ReAct Agent（思考 → 执行 → 观测）配合多个工具，本身就具备闭环的规划、执行与反思能力，足以应对大部分看似复杂的场景。强行拆分反而会引入更多问题：

  1. 上下文同步成本：原本在同一个上下文窗口内就能闭环的逻辑，被拆成跨 Agent 的上下文同步、状态传递与会话协议管理。
  2. 工程维护成本：复杂度、调试难度、token 消耗和延迟都会上升，还需要维护多套 Prompt 和 JSON Schema。

判断一个系统是否真正属于 Multi-Agent，看它有没有多个独立的：

  • System Prompt
  • 上下文与 Memory
  • 工具集合
  • 权限范围
  • 决策过程

例如：Research Agent 可以访问搜索和知识库，Coding Agent 可以操作代码和执行测试，Review Agent 只有只读权限、负责质量审核——三者目标、工具、权限都不同，这样拆分是合理的。

反过来，如果只是把意图识别、检索、答案生成写成三个 LLM 节点，它们共享同一个角色、上下文和目标，那么这其实只是一个 Agent 的多阶段工作流，还算不上真正的 Multi-Agent。

所以原则很明确：单 Agent 加工具能解决的，不要拆；只有明确存在职责边界时才拆。

能力组件：RAG / Memory / Tool

RAG、Memory、Tool 与 Graph、Multi-Agent 不应放在同一层级比较。前者是 Agent 的能力组件，后者是执行模型。

RAG

解决「Agent 如何获取模型参数之外的知识」，涵盖文档解析、切分、索引、检索、重排到引用溯源。如果系统以企业知识库、文档问答或大规模数据检索为核心，可以优先考虑 LlamaIndex、Haystack 等在数据处理和检索上更成熟的框架。

Memory

解决「Agent 如何保存和使用历史信息」。记忆不能简单塞进消息历史，需要按生命周期、权限和存储方式细分：

  1. Graph State：当前任务的运行状态
  2. Short-term Memory：当前对话的上下文
  3. Long-term Memory：跨会话的用户偏好和历史
  4. Agent Memory：某个 Agent 私有的信息
  5. Knowledge Base：企业级公共知识

Tool

解决「Agent 如何操作外部系统」，常见的有数据库、HTTP 服务、搜索引擎、浏览器、代码执行环境以及 MCP 暴露的能力。选型不能只看是否支持 Function Calling，还要考虑：

  1. 工具参数是否结构化
  2. 是否支持超时和重试
  3. 是否可以限制工具权限
  4. 是否支持并行调用
  5. 是否有执行沙箱
  6. 工具调用是否能够审计
  7. 重试是否会产生重复副作用

代码框架与低代码平台

代码框架和低代码平台解决的是不同的交付问题：

  1. 代码框架（Spring AI Alibaba、LangGraph、AutoGen、LlamaIndex 等）：灵活度高、支持单元测试和版本管理、适合复杂业务逻辑、容易集成企业基础设施。
  2. 低代码平台（Dify、Flowise 等）：强调可视化编排、快速搭建、Prompt 与模型统一管理，适合原型和简单流程。但流程复杂之后会暴露问题：可视化连线难以维护、复杂状态逻辑难以表达、深度定制成本上升、存在平台依赖。

因此两者不必二选一：低代码平台管理 Prompt、知识库和简单流程，核心业务能力封装在代码服务中。

生产级能力需要单独评估

可观测、可审计、人工介入等能力，属于生产系统的横向要求，并非 Graph 框架独有。选型时需要独立评估：

  1. 状态持久化与恢复：是否支持 Checkpoint？服务崩溃或重启后能否断点恢复？
  2. 人机协同：是否支持 Interrupt/Resume？高风险操作是否支持人工审批？
  3. 容错与执行控制：节点失败能否单节点重试？有没有全局超时和任务取消？工具调用有没有幂等保障？
  4. 可观测性：是否记录完整执行路径（Trace）？是否记录 Prompt/模型版本？有没有 token 成本统计？
  5. 系统安全与评估：是否支持评测回归？有没有租户隔离和敏感信息过滤？

这些能力在 Demo 阶段差别不明显，进入生产环境后，拉开差距的往往就是这些运行时能力。

五步完成选型

把这些维度串起来，实际落地时按下面的顺序评估：

  1. 判断流程确定性：业务流程的确定性有多高？执行步骤能否提前确定？是否存在严格业务规则？固定程度越高，越适合 Graph/Workflow；开放程度越高，越适合 Agent Loop。
  2. 判断是否拆分 Multi-Agent：系统内是否存在职责、目标完全不同的独立角色？是否需要对工具和权限做硬隔离？单 Agent 能通过配置工具解决的，就不要拆。
  3. 确定能力组件：按真实业务场景按需装配——RAG、Memory、Tool Calling、MCP、代码执行、浏览器能力、模型路由。
  4. 确定生产要求：是否需要人工审批/干预？服务宕机后能否状态恢复与重放？流程是否包含高风险副作用？是否满足合规审计、效果回归评测、Token 成本与延迟限制？
  5. 结合团队和技术生态：技术栈是 Java 还是 Python？是否基于 Spring？是否使用特定云厂商？能否无缝融入现有微服务、权限和监控体系？

落到具体场景

回到故障诊断 Agent 这个场景：它的主干有明确的 SOP（从告警触发到定位修复），但涉及网络、数据库、应用等多个领域，知识与工具高度隔离，且生产操作有高风险合规要求。

因此最终的方案是：Graph 控制主流程 + 多个领域 Agent 负责专业分析 + RAG 检索历史案例 + MCP/Tool 调用日志与监控 + Checkpoint 保存进度 + Interrupt 实现人工审批 + Tracing 与评测提供可观测性。

graph TD
  A[告警触发] --> B[Workflow 流程控制]

  subgraph B [Graph / Workflow 主流程]
    C[Planner 规划 Agent] --> D1[DB 子 Agent]
    C --> D2[Network 子 Agent]
    C --> D3[Log 子 Agent]
  end

  D1 & D2 & D3 --> E[能力组件: RAG + MCP / Tool + Memory]

  B -->|Interrupt| F[人工审批]
  F -->|Resume| G[执行修复]

  subgraph Base [生产级横向基建]
    P1[Checkpoint 进度保存]
    P2[Tracing 链路审计]
    P3[评测与可观测性]
  end

  Base -. 运行保障 .- B

这个方案是在不同架构层级上按需组合，并没有在 Graph、Multi-Agent、RAG 之间做非此即彼的单选。

总结

Agent 框架之间真正的差异，主要体现在三点：

  1. 抽象方式：框架默认如何表达和定义业务问题。
  2. 执行范式：框架默认如何调度和推进任务流程。
  3. 工程落差：从 Demo 到生产，还需要补充多少工程治理与运维能力。

理解清楚这几个层级，选型判断就会比单纯对比功能列表准确得多。