福生无量摸鱼天尊

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更稳。

架构 4：团队协作 / Swarm / 角色扮演式多 Agent

这类是大众最熟悉、也是最容易被过度神话的一类。

4.1 AutoGen：团队与 Swarm

AutoGen 把多 agent 组织成 teams，并明确支持多种 team preset，官方教程还专门强调要观察 team 行为，因为这对调试和理解性能很关键。

它的 Swarm 设计里，agent 可以基于能力把任务 handoff 给其他 agent，而且所有 agent 共享同一消息上下文，不依赖一个中央 orchestrator 来统一规划。

Magentic-One 则是另一种更强 orchestrator 的 generalist multi-agent 系统。

flowchart LR A[Agent A] -->|handoff| B[Agent B] B -->|handoff| C[Agent C] C -->|handoff| A X[Shared Context] --- A X --- B X --- C

Swarm 的典型形态

flowchart TD O[Orchestrator] --> W[Web Agent] O --> F[File Agent] O --> C[Coder Agent] O --> E[Executor Agent] W --> S[Shared Task Ledger] F --> S C --> S E --> S

Orchestrator-Team 的典型形态

4.2 MetaGPT：SOP 驱动的角色协作

MetaGPT 非常有代表性，因为它把多 agent 明确映射成“软件公司角色”：产品经理、架构师、项目经理、工程师等，并提出 “Code = SOP(Team)”，也就是把 SOP 物化到由 LLM 角色组成的团队中。

它的味道很像：

flowchart TD R[Requirement] --> PM[Product Manager] PM --> ARC[Architect] ARC --> TL[Project Manager / Team Lead] TL --> ENG[Engineer] ENG --> TEST[Tester / Reviewer] TEST --> OUT[Deliverables]

架构四适合：

  • 开放式复杂任务

  • 多角色分工天然明确

  • 任务本身需要“先讨论，再产出”

  • 你想表达“组织协作”而不是“函数链”

优点

优点是非常直观，尤其适合 demo、论文、产品展示。

缺点

缺点也很大：

  • 最容易过度设计

  • 最容易产生“看起来很忙，实际上在兜圈子”

  • 成本、时延、可控性都更难管

但需要注意的是多 agent 不是越多越高级。如果一个问题本质是固定流程，你硬把它做成团队群聊，最后大概率是在浪费 token。

架构 5：MCP 接入型架构

MCP 不是“又一种 agent 框架”，它更像一种统一接入协议。

MCP 规范明确写了 server 可以向 client 暴露三类能力：

  • Resources：给模型或用户使用的上下文与数据

  • Prompts：模板化消息与工作流

  • Tools：给模型执行的函数能力

资源这块还特别强调：resources 用于向模型共享上下文数据，比如文件、数据库 schema 或应用特定信息。

flowchart TD H[Host App / Agent Runtime] --> C[MCP Client] C --> S1[MCP Server: Papers] C --> S2[MCP Server: Code Repo] C --> S3[MCP Server: Dataset] C --> S4[MCP Server: Experiment Tracker] S1 --> R1[Resources] S2 --> R2[Resources / Tools] S3 --> R3[Resources] S4 --> R4[Tools / Prompts]

架构五适合：

  • 系统需要接很多外部源

  • 不想每接一个系统就写一套私有 adapter

  • 希望把 tools / resources / prompt 模板都统一管理

优点

优点是：

把“接外部世界”这件事标准化。

这对企业系统特别关键。
因为工程难点往往不在 agent 自己，而在：

  • 怎么接文件

  • 怎么接数据库

  • 怎么接知识库

  • 怎么接代码仓库

  • 怎么接实验平台

缺点

MCP 本身不替你解决：

  • 业务状态机

  • 多 agent 协作策略

  • memory schema

  • eval 与 observability

所以它更像接入层，不是完整系统架构。

MCP 最适合放在“平台边界”上，而不是拿来替代业务架构。换句话说：

  • 你的系统内部还是要有状态、memory、流程、trace

  • MCP 负责把外部工具和资源接进来

如何design好一个架构

很多人学了一圈框架后，最容易犯的错就是：

“我全都要。”

结果就是系统图很漂亮，代码全是耦合。

很简单的一条准则，就是从需求出发去考虑架构。

比如说需求更偏固定pipeline，比如：

  • 审论文

  • 生成实验 checklist

  • 代码审查 pipeline

  • 科研报告结构化整理

优先选：

  • 图工作流

  • Flow + Crew

如果更偏开放探索，比如：

  • 网页多步搜索

  • 文件+网页混合调查

  • 开放式软件协作

优先选：

  • Team / Swarm / Orchestrator

如果让我把整篇文章压成一句建议，那就是这句：先问控制流怎么走，再问有几个 agent。

因为系统真正的分水岭不是“单 agent / 多 agent”，而是：

  • 谁控制阶段切换

  • 谁持有任务状态

  • 谁管理 memory

  • 谁记录 trace

  • 谁决定是否调用外部资源

  • 谁负责失败恢复

如果这些问题没有先想清楚，你就算堆再多 agent，也只是让系统更难 debug。

单 agent、图工作流、Flow + Crew、团队协作、MCP 接入，这些都不是非此即彼，而是不同层面的抽象。真正成熟的系统，往往是它们的组合。

  • OpenAI Agents SDK 强调运行时原语与 tracing；LangGraph 强调图与状态

  • CrewAI 强调 Flow 与 Crew 分层

  • AutoGen 强调 team、swarm 与行为可观察

  • MCP 则把 tools、resources、prompts 的接入标准化

把这些东西放到一起看，你会更容易知道：自己到底是在做“一个会说话的 agent”，还是在做“一个能长期工作的 agent 系统”。