Agent 框架选型

框架不是选最火的，而是选「你最可能需要、又最容易被替换掉」的那一层。大多数团队真正需要的是循环、状态和可观测性，而不是一套全家桶。

#框架应该替你解决什么

一个 Agent 框架的价值，按重要性排序：

1. 循环与工具调用：消息管理、工具执行、并行、错误处理；
2. 状态与持久化：检查点、恢复、长任务；
3. 人工介入：暂停、审批、恢复；
4. 流式与事件：前端能实时看到进度；
5. 可观测性：trace、token、工具调用；
6. 评估与部署：测试、托管、监控；
7. 多 Agent 编排：交接、路由、共享状态；
8. 生态：MCP、模型适配、集成。

如果某个框架只解决了第 1 项，它更像一个 SDK，而不是平台。选型时先列出你真正需要的 3 项，再看谁能覆盖。

#2026 年的主要路线

这一节描述的是「路线」而不是版本排名。具体 API 迭代很快，请以官方文档为准。

#图 / 持久化编排

LangGraph（Python / JS） 把 Agent 建模为状态图：节点、边、条件分支、检查点、人工中断。生态成熟，适合复杂流程与长任务。代价是概念多、抽象重，简单任务会显得啰嗦。

Temporal / Restate / Cloudflare Workflows 通用持久化执行引擎，不是专门的 Agent 框架。适合「Agent 只是流程中的一步」的企业系统：重试、超时、补偿、跨天等待都很成熟。需要自己封装模型调用。

Microsoft Agent Framework 整合了 Semantic Kernel 与 AutoGen 的路线，偏企业 .NET / Python 生态，强调类型、可观测性与多 Agent 编排。

#Agent SDK

OpenAI Agents SDK（Python / JS） 轻量，核心概念是 Agent、Handoff、Guardrail、Session、Tracing。适合以 OpenAI 模型为主、需要快速搭多 Agent 交接的场景。跨厂商支持在增强，但仍以自家生态最顺。

Claude Agent SDK（Python / TS） 把 Claude Code 的 Agent harness 暴露出来：文件读写、命令执行、子 Agent、hooks、MCP、权限模式。适合编码与本地自动化，模型侧主要绑定 Claude。

Google ADK 面向 Gemini 生态的 Agent 开发套件，支持多 Agent、工具、评估与部署，和 Google Cloud 集成紧密。

Pydantic AI（Python） 类型安全、结构化输出友好，API 简洁，适合后端工程师。生态比 LangGraph 小，但可读性好。

Mastra（TypeScript） 面向 TS/JS 的 Agent 框架，包含工作流、RAG、评估、本地开发体验，适合前端/全栈团队。

#多 Agent / 角色协作

CrewAI：用角色、任务、流程描述协作，上手快，适合内容生产与业务流程。复杂控制流的表达能力有限。

AutoGen / AG2：研究导向的多 Agent 对话与群聊，适合实验与原型。

Swarm 类：去中心化交接，灵活但难以保证全局目标与可观测性，生产慎用。

#RAG / 数据层

LlamaIndex：文档解析、索引、检索、查询引擎非常完整，也可以做 Agent。适合知识密集型应用。

Haystack：偏搜索与管道编排，企业搜索场景成熟。

#低代码 / 平台

Dify：可视化工作流、知识库、模型管理，适合业务团队快速上线。 n8n：通用自动化 + AI 节点，适合把 Agent 嵌进现有业务流程。 Coze / 扣子：面向对话机器人与插件生态，适合轻量产品。

低代码的代价是：复杂逻辑受限、调试黑盒、迁移成本高。适合验证需求，不适合做核心壁垒。

#协议与工具

MCP SDK：不是 Agent 框架，而是连接工具的标准。任何框架都可以用。

#对比表

#选型清单

先回答这八个问题：

1. 主要语言是什么？ 团队不熟的生态会拖慢一切。
2. 需要长任务/暂停恢复吗？ 需要就优先图或持久化引擎。
3. 需要人工审批吗？ 检查框架的 interrupt/resume 能力。
4. 需要多 Agent 吗？ 还是单 Agent + 工具就够？
5. 模型是否锁定？ 未来换模型时，迁移成本多大？
6. 可观测性是否内置？ 没有 trace 的框架，调试会很痛苦。
7. 部署在哪里？ Serverless、容器、边缘，支持程度不同。
8. 出问题能否读源码？ 黑盒平台在复杂故障前很无力。

#一个「不用框架」的选项

如果任务简单，直接用官方 SDK + 自己的状态机可能更好：

# 不需要 LangGraph，也不需要 CrewAI
state = init_state(goal)
for step in range(MAX_STEPS):
    action = model.decide(build_context(state))
    if action.done:
        break
    state = apply(state, execute(action))
save(state)

好处是：没有抽象泄漏、调试直接、依赖少。坏处是：检查点、恢复、并发、可视化都要自己写。

一个实用判断：当你开始手写「暂停/恢复/重试/状态持久化」时，再考虑上框架。 在此之前，框架可能是负担。

#迁移与锁定

选框架时，尽量把业务逻辑放在框架之外：

• 工具实现是普通函数，不依赖框架类型；
• 提示模板独立存放；
• 状态用普通数据结构，可序列化；
• 模型调用通过统一接口，便于切换；
• 评估集与框架无关。

这样即使换框架，核心资产仍在。

#反模式

#我的默认建议

• 后端团队、复杂流程：LangGraph 或 Temporal + 自研 Agent 层；
• 快速做多 Agent 原型：OpenAI Agents SDK；
• 编码/本地自动化：Claude Agent SDK；
• TS 全栈：Mastra 或 OpenAI Agents SDK（JS）；
• 知识库为主：LlamaIndex + 轻量编排；
• 业务同学验证需求：Dify / n8n，验证后核心逻辑代码化；
• 只需要一个循环：官方 SDK + 200 行代码。

#小结

• 框架的价值在循环、状态、HITL、可观测性和部署，不只是「能调工具」。
• 按语言、任务长度、审批需求、模型锁定、部署环境选型。
• 简单任务不用框架；复杂流程优先图/持久化引擎。
• 把业务逻辑放在框架之外，降低迁移成本。
• 没有 trace 的框架，不建议上生产。

下一篇算一笔实在账：模型怎么选，成本怎么降。