如果要去design一个agent架构，避免不了的就是涉及到对session的管理和agent的架构，一个是表面的，一个是深层的
常见可以分成以下几类：
一类是 thread/checkpoint 型（LangGraph、Dify、Flowise）
一类是 runtime snapshot/controller 型（AutoGen、OpenHands）
一类是 workspace/project 型（Open WebUI、AnythingLLM、FastGPT、LobeHub）
还有一类是 workflow/job 型（InvokeAI、ComfyUI）。
接下来一个一个说
最经典的特征就是会话有唯一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。
最显著的特征就是有明显的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的事务驱动有很相关的意味，不太懂。
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 设计：
chat logs 可以按 workspace / user 查看和导出，多用户模式有明确 RBAC
agent flows 是挂在 workspace 的 agent skills 下面
代码结构也是很典型的 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 模型是不够的。
如果把近两年的主流开源框架放在一起看，大致可以归成 5 类：
单 Agent runtime架构
代表：OpenAI Agents SDK
图工作流 / State Graph 架构
代表：LangGraph
Flow + Crew 分层架构
代表：CrewAI
团队协作 / Swarm / 角色扮演式多 Agent 架构
代表：AutoGen、MetaGPT
MCP 接入型架构
代表：MCP 协议本身，以及围绕 MCP 组织工具/资源的系统
这几类不是互斥关系。很多成熟系统其实是“上层用工作流，局部再放多 agent，外部工具再通过 MCP 接入”
LangGraph 明确区分了 workflow 和 agent：前者是预定代码路径，后者是动态决定过程和工具使用
CrewAI 也把 Flows 和 Crews 拆开，一个管结构化流程，一个管自治协作
这是最容易开始、也最容易被低估的一类。
OpenAI Agents SDK 对 agent 的定义非常直接：
agent 是一个配置了instructions、tools，以及可选handoffs、guardrails、structured outputs 的LLM运行单元。 同时它还内建tracing，可以记录 LLM 生成、工具调用、handoff、guardrails 和自定义事件。
适合：
工具调用不多
流程不太长
上下文主要围绕当前任务
先把“能干活”做出来
不适合：
强状态机
长链路可恢复执行
多阶段研究流程
很复杂的多角色协作
上手快，概念少，很适合做一个强能力专家agent，比如代码修复agent、检索问答agent、实验结果解释agent。
当任务开始变长，或者需要多个阶段时，单agent很容易变成“所有事情都塞给一个大prompt。
这时候你会发现，真正缺的不是再加几个工具，而是：
状态怎么存
失败怎么恢复
过程怎么回放
子任务怎么分
很多项目第一步都应该从这里起。因为你只有先跑通一个能干活的agent，才知道后面到底该加图工作流，还是该加多agent。
如果说单 agent 是“一个人带着工具箱做事”，那图工作流就是“先把路线图画出来，再让每个节点去执行”。
LangGraph 的核心表述非常清楚：
它把agent workflow 建模成graph，强调State、Nodes、Edges；
它明确说workflow 是预定路径，agent是动态过程。
它还提供persistence、streaming、debugging、deployment，以及把subgraph当作node嵌套进去的能力。
再复杂一点时，会变成“图里套图”：
特别适合：
研究工作流
多阶段审批
可恢复执行
需要人类插入 review
需要追踪“当前处在哪一步”
最大的优点是：控制流清晰。
你知道系统现在在：
哪个节点
为什么走到这里
下一步会去哪
如果失败，该从哪里恢复
缺点也很明显：
如果所有事情都画成图，系统可能会变硬。
对于探索性很强的任务，过于固定的图会让 agent 失去灵活性。
如果你的系统是“研究课题发现 → 文献综述 → 实验设计 → 执行记录 → 结论回放”这一类长流程系统，图工作流几乎一定比纯多 agent 更稳。
LangGraph 官方本身就把“workflow 与 agent 的边界”讲得很明白：很多问题首先应该用 workflow。
这是我觉得最适合讲给工程团队的一类架构。
CrewAI 的官方表述很直白：
Flows 是应用骨架，是结构化、事件驱动、管理状态和控制执行的工作流；
Crews 是 Flow 里的自治团队，由多个 agent 协作完成具体任务。
它还把 memory 做成统一系统，可以单独使用，也可以和 Crews、Agents、Flows 集成。
适合：
既想要流程清晰
又想保留局部自治
团队希望“先编排，再协作”
想把 memory 做成基础设施
它最吸引人的地方在于：
把“流程”与“协作”拆开。
这件事特别重要。
因为很多人做多 agent 时，一上来就让大家群聊，结果最后根本不知道谁该负责流程控制。
CrewAI 的分法更工程化：
Flow 负责外层稳定性
Crew 负责内层智能性
如果设计不好，会出现：
Flow 太重，Crew 只是装饰
Crew 太重，Flow 形同虚设
假如说做一个“科研助理系统”，这一类架构其实很自然：
Flow 控制研究阶段
Crew 负责 Gap 分析、综述、实验设计、结果解释
Memory 贯穿全过程
这比顶层一个超级planner，到处调agent更稳。
这类是大众最熟悉、也是最容易被过度神话的一类。
AutoGen 把多 agent 组织成 teams，并明确支持多种 team preset，官方教程还专门强调要观察 team 行为，因为这对调试和理解性能很关键。
它的 Swarm 设计里，agent 可以基于能力把任务 handoff 给其他 agent，而且所有 agent 共享同一消息上下文，不依赖一个中央 orchestrator 来统一规划。
Magentic-One 则是另一种更强 orchestrator 的 generalist multi-agent 系统。
Swarm 的典型形态
Orchestrator-Team 的典型形态
MetaGPT 非常有代表性，因为它把多 agent 明确映射成“软件公司角色”：产品经理、架构师、项目经理、工程师等，并提出 “Code = SOP(Team)”，也就是把 SOP 物化到由 LLM 角色组成的团队中。
它的味道很像：
架构四适合：
开放式复杂任务
多角色分工天然明确
任务本身需要“先讨论，再产出”
你想表达“组织协作”而不是“函数链”
优点是非常直观，尤其适合 demo、论文、产品展示。
缺点也很大：
最容易过度设计
最容易产生“看起来很忙，实际上在兜圈子”
成本、时延、可控性都更难管
但需要注意的是多 agent 不是越多越高级。如果一个问题本质是固定流程，你硬把它做成团队群聊，最后大概率是在浪费 token。
MCP 不是“又一种 agent 框架”，它更像一种统一接入协议。
MCP 规范明确写了 server 可以向 client 暴露三类能力：
Resources：给模型或用户使用的上下文与数据
Prompts：模板化消息与工作流
Tools：给模型执行的函数能力
资源这块还特别强调：resources 用于向模型共享上下文数据，比如文件、数据库 schema 或应用特定信息。
架构五适合：
系统需要接很多外部源
不想每接一个系统就写一套私有 adapter
希望把 tools / resources / prompt 模板都统一管理
优点是：
把“接外部世界”这件事标准化。
这对企业系统特别关键。
因为工程难点往往不在 agent 自己，而在：
怎么接文件
怎么接数据库
怎么接知识库
怎么接代码仓库
怎么接实验平台
MCP 本身不替你解决：
业务状态机
多 agent 协作策略
memory schema
eval 与 observability
所以它更像接入层，不是完整系统架构。
MCP 最适合放在“平台边界”上，而不是拿来替代业务架构。换句话说：
你的系统内部还是要有状态、memory、流程、trace
MCP 负责把外部工具和资源接进来
很多人学了一圈框架后，最容易犯的错就是：
“我全都要。”
结果就是系统图很漂亮，代码全是耦合。
很简单的一条准则，就是从需求出发去考虑架构。
比如说需求更偏固定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 系统”。
