如果要去design一个agent架构，避免不了的就是涉及到对session的管理和agent的架构，一个是表面的，一个是深层的

session管理

常见可以分成以下几类：

  • 一类是 thread/checkpoint 型（LangGraph、Dify、Flowise）

  • 一类是 runtime snapshot/controller 型（AutoGen、OpenHands）

  • 一类是 workspace/project 型（Open WebUI、AnythingLLM、FastGPT、LobeHub）

  • 还有一类是 workflow/job 型（InvokeAI、ComfyUI）。

接下来一个一个说

thread/checkpoint 型

最经典的特征就是会话有唯一ID，并且

1. LangGraph

它把 thread 当成持久会话容器，图的每一步都能被 checkpointer 存成 checkpoint，天然支持 human-in-the-loop、故障恢复、time travel debugging。

短期记忆是 thread-scoped，长期记忆则跨 thread 放在 store 里。

再往上，Agent Server 又把 assistants / threads / runs 做成正式 API 资源。

如果有做一些session - 多agent的DAG体系，那几乎可以一一对应到它的 thread / checkpoint / run / graph steps。

它的内核基本上被魔改的最多，也是非常通用的框架。

2. Dify

它用 conversation_id 维持会话，后续调用必须带这个 id，而且官方明确说 API 创建的会话和 WebApp 里的会话彼此隔离。

它的 Chatflow 是“每一轮对话触发一次”的 workflow，自带 chat memory，就设计的很符合qa系统的直觉。

conversation variables 会在整个 chat session 内持久化，而普通 workflow variables 是每次运行重置的。

部署层面它又把 api、worker、worker_beat、web、plugin_daemon、sandbox 分成多个服务，并且既能消费外部 MCP 工具，也能把自己的 app 发布成 MCP server。

Dify最值得看它的“产品化session”，很符合session first的直觉。

3. Flowise

Flowise 的 UI 和 Embed Chat 默认会为每次新对话生成唯一 chatId，用它来隔离不同用户/不同对话。

官方文档也明确说同一个 chatId 会复用同一 thread。

Prediction API 里把 chatId、chatMessageId，甚至 sessionId 都显式暴露出来。

工程上它是一个 server / ui / components 的 monorepo，还专门做了 Embed Proxy Server，避免在前端暴露 Flowise host、chatflow id 和 API key。

同时又支持 Memory nodes、AgentFlow V2 的 Flow State 和 MCP tools。

Flowise最值得看它的 chatId 设计和前后端接法，比起dify它更加纯粹的适用于qa。

runtime snapshot/controller 型

最显著的特征就是有明显的event-driven，以请求为中心进行state转变。

1. AutoGen + OpenHands

AutoGen 是 event-driven 框架，官方明确要求 agent、team、runtime 的 state 可 save/load，而且 state 必须 JSON-serializable。

它还特别说明这很适合“stateless endpoint 的 web app”，因为每次请求都可以从持久化状态恢复 runtime。

OpenHands 则把 Agent、State、Action、Observation、Runtime、AgentController 拆得很清楚，Controller 负责驱动主循环。

前端是 React/Remix + Redux + TanStack Query，MCP 也是正式一层。

这个组合非常像openclaw的“agent loop + session memory + tools/MCP”的方向。

有非常明显的runtime/controller，不好说是不是online的首选？感觉这种跟db的事务驱动有很相关的意味，不太懂。

workspace/project 型

1. Open WebUI

它强调自己是 stateless，container-first 架构，目标是水平扩展。

session和知识不是绑在单个进程上，而是落到持久层。

用户侧除了 chat，还有 folders/projects，可以把 system prompt 和 knowledge base 绑定到一整组 chats 上。

同时又支持跨 chat 的 long-term memory，以及 Functions/Tools 这类 Python 插件体系。

MCP 方面它从 v0.6.31 开始原生支持，但因为它是 web-based multi-tenant 环境，所以官方只做 Streamable HTTP，这一点未来做前后端兼容很重要。

2. AnythingLLM

AnythingLLM 更像 workspace-first 设计：

  1. chat logs 可以按 workspace / user 查看和导出，多用户模式有明确 RBAC

  2. agent flows 是挂在 workspace 的 agent skills 下面

  3. 代码结构也是很典型的 full-stack monorepo（frontend / server / collector / embed 等）。

它的 MCP 生命周期设计也很务实：不会在应用启动时自动拉起所有 MCP servers，而是等你打开 Agent Skills 或真正触发 @agent 时再启动，避免资源在多租户场景里被一次性吃光。

我认为在所有涉及到多模态的数据上，只要存在非llm的处理workflow，都值得看 workspace/user 两级隔离。

3. FastGPT + LobeHub

FastGPT 官方把对话工作流、插件工作流、双向 MCP 辅助工作流、知识库、多库复用、OpenAPI、对话 CRUD、Iframe 嵌入都列成核心能力。

而它新出的系统插件设计文档又明确反思了“所有功能都塞在 Next.js monorepo 里”会让插件和主系统一起耦合发版，于是开始把插件演化从主仓组织中解耦。

LobeHub 这边更偏 chat-first agent 平台：它把 chat API 前后端交互、agent-runtime、context-engine、conversation-flow、database 等 package 公开分层

agent-runtime 明确就是 plan-execute loop，支持 tool batch execution、human-in-the-loop 和多 agent 协作，topics 则相当于在一个会话里再切子主题。

在全栈，大而全的项目这一块，这俩是很值得看的项目怎么处理应用编排。

1. Haystack：最值得看它的工具兼容层，而不是 UI。
Haystack 把 pipeline 明确成 directed multigraph，把 agent state 做成独立容器；Toolset / SearchableToolset 用来组织和按需发现大量 tools，官方文档明确提到 catalog 里可以包含 MCPTool / MCPToolset；实验性的 chat history store 也把 chat_history_id 定义成不同 conversation/session 的隔离 namespace。它对“产品级 session UI”不算强意见，但对“skills / tools / MCP catalog 怎么组织”很成熟。

2. InvokeAI + ComfyUI：文生图/视频方向里，一个是正例，一个更像反例。
InvokeAI 明确有 invoker / sessions / invocations / services 四层抽象，而且官方前端文档直接承认：ReactFlow state 与后端 graph structure 在结构上不兼容，所以真正执行前必须做转换；它最近还在推进同一后端上的多用户隔离。ComfyUI 则更偏 stateless job server：API 可以做成无状态并横向扩展，靠 queue + WebSocket status 驱动执行。对纯生成任务它很强，但对你这种“多轮对话 + session memory + 审批 + MCP”的系统，单独照抄 ComfyUI 的 session 模型是不够的。

agent架构

如果把近两年的主流开源框架放在一起看，大致可以归成 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 或应用特定信息。