福生无量摸鱼天尊

logo
福生无量摸鱼天尊

agent系列：（四）agent架构

2026/03/15
0
0

如果把近两年的主流开源框架放在一起看，大致可以归成 5 类：

  1. 单 Agent runtime架构
    代表：OpenAI Agents SDK

  2. 图工作流 / State Graph 架构
    代表：LangGraph

  3. Flow + Crew 分层架构
    代表：CrewAI

  4. 团队协作 / Swarm / 角色扮演式多 Agent 架构
    代表：AutoGen、MetaGPT

  5. MCP 接入型架构
    代表：MCP 协议本身，以及围绕 MCP 组织工具/资源的系统

这几类不是互斥关系。很多成熟系统其实是“上层用工作流，局部再放多 agent，外部工具再通过 MCP 接入”

  • LangGraph 明确区分了 workflow 和 agent：前者是预定代码路径，后者是动态决定过程和工具使用

  • CrewAI 也把 Flows 和 Crews 拆开，一个管结构化流程，一个管自治协作

架构 1：单 Agent runtime

这是最容易开始、也最容易被低估的一类。

OpenAI Agents SDK 对 agent 的定义非常直接：
agent 是一个配置了instructions、tools，以及可选handoffs、guardrails、structured outputs 的LLM运行单元。 同时它还内建tracing，可以记录 LLM 生成、工具调用、handoff、guardrails 和自定义事件。

flowchart TD U[User Request] --> A[Agent Runtime] A --> I[Instructions] A --> T[Tools] A --> G[Guardrails] A --> H[Optional Handoffs] A --> O[Structured Output] A --> TR[Tracing / Logs] O --> R[Response]

适合：

  • 工具调用不多

  • 流程不太长

  • 上下文主要围绕当前任务

  • 先把“能干活”做出来

不适合：

  • 强状态机

  • 长链路可恢复执行

  • 多阶段研究流程

  • 很复杂的多角色协作

优点

上手快，概念少，很适合做一个强能力专家agent，比如代码修复agent、检索问答agent、实验结果解释agent。

缺点

当任务开始变长，或者需要多个阶段时，单agent很容易变成“所有事情都塞给一个大prompt。
这时候你会发现，真正缺的不是再加几个工具，而是：

  • 状态怎么存

  • 失败怎么恢复

  • 过程怎么回放

  • 子任务怎么分

很多项目第一步都应该从这里起。因为你只有先跑通一个能干活的agent，才知道后面到底该加图工作流，还是该加多agent。

架构 2：图工作流 / State Graph

如果说单 agent 是“一个人带着工具箱做事”，那图工作流就是“先把路线图画出来，再让每个节点去执行”。

LangGraph 的核心表述非常清楚：

  • 它把agent workflow 建模成graph，强调State、Nodes、Edges；

  • 它明确说workflow 是预定路径，agent是动态过程。

  • 它还提供persistence、streaming、debugging、deployment，以及把subgraph当作node嵌套进去的能力。

flowchart TD S[Start] --> P[Plan] P --> R[Retrieve] R --> C[Critic] C -->|enough evidence| W[Write Answer] C -->|not enough| R W --> E[End]

再复杂一点时，会变成“图里套图”：

flowchart TD A[Main Graph] --> B[Gap Finder Subgraph] A --> C[Literature Synthesis Subgraph] A --> D[Experiment Planning Subgraph] A --> E[Execution / Reflection Subgraph]

特别适合：

  • 研究工作流

  • 多阶段审批

  • 可恢复执行

  • 需要人类插入 review

  • 需要追踪“当前处在哪一步”

优点

最大的优点是：控制流清晰。

你知道系统现在在：

  • 哪个节点

  • 为什么走到这里

  • 下一步会去哪

  • 如果失败，该从哪里恢复

缺点

缺点也很明显：

  • 如果所有事情都画成图，系统可能会变硬。

  • 对于探索性很强的任务，过于固定的图会让 agent 失去灵活性。

如果你的系统是“研究课题发现 → 文献综述 → 实验设计 → 执行记录 → 结论回放”这一类长流程系统，图工作流几乎一定比纯多 agent 更稳。

LangGraph 官方本身就把“workflow 与 agent 的边界”讲得很明白：很多问题首先应该用 workflow。

架构 3：Flow + Crew 分层

这是我觉得最适合讲给工程团队的一类架构。

CrewAI 的官方表述很直白：

  • Flows 是应用骨架，是结构化、事件驱动、管理状态和控制执行的工作流；

  • Crews 是 Flow 里的自治团队，由多个 agent 协作完成具体任务。

  • 它还把 memory 做成统一系统，可以单独使用，也可以和 Crews、Agents、Flows 集成。

flowchart TD U[User / Trigger] --> F[Flow] F --> S1[State] F --> C1[Crew A: Retrieval Crew] F --> C2[Crew B: Analysis Crew] F --> C3[Crew C: Planning Crew] C1 --> M[Unified Memory] C2 --> M C3 --> M F --> O[Output / Next Event]

适合：

  • 既想要流程清晰

  • 又想保留局部自治

  • 团队希望“先编排，再协作”

  • 想把 memory 做成基础设施

优点

它最吸引人的地方在于：

把“流程”与“协作”拆开。

这件事特别重要。

因为很多人做多 agent 时，一上来就让大家群聊，结果最后根本不知道谁该负责流程控制。

CrewAI 的分法更工程化：

  • Flow 负责外层稳定性

  • Crew 负责内层智能性

缺点

如果设计不好，会出现：

  • Flow 太重，Crew 只是装饰

  • Crew 太重，Flow 形同虚设

假如说做一个“科研助理系统”，这一类架构其实很自然：

  • Flow 控制研究阶段

  • Crew 负责 Gap 分析、综述、实验设计、结果解释

  • Memory 贯穿全过程

这比顶层一个超级planner，到处调agent更稳。