AI Agent技术趋势与框架选型#
一句话答案#
Agent 框架从 Chain-based（早期 LangChain）演进到 Graph-based（LangGraph、ADK 2.0、Microsoft Agent Framework 的 Workflow）再到 SDK-native（OpenAI Agents SDK、Claude Agent SDK），选型核心看状态管理需求和团队技术栈；趋势上推理模型、MCP 标准化、上下文工程正在重塑 Agent 开发范式。
核心要点
1. 主流框架对比#
| 框架 | 核心抽象 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|---|
| LangChain（1.x） | create_agent + middleware；旧版 Chain 移到 langchain-classic | 生态丰富，组件多；agent 跑在 LangGraph 上 | 抽象层多，调试要看底层 | 快速原型，标准 RAG / 工具调用 Agent |
| LangGraph（1.x） | StateGraph | 显式状态机，可视化，支持人工介入 | 学习曲线陡 | 复杂多步骤，需要审批流 |
| OpenAI Agents SDK | Agent / Runner / Handoff / Guardrail / Session | 轻量，原生 Handoff，内置 Tracing | 与 OpenAI 模型集成最好 | OpenAI 生态项目 |
| Claude Agent SDK | 把 Claude Code 的 agent loop 做成库：内置工具 / Hooks / Subagents / MCP / 权限 / Sessions | 文件、Shell、搜索等工具开箱即用 | Anthropic 生态 | Claude 生态项目，代码/运维类 Agent |
| Google ADK（2.x） | Agent + 图工作流（2.0 起顺序/并行/循环模板被图工作流取代） | 多语言（Python/TS/Go），与 Gemini、Vertex 集成好 | 1.x→2.0 有破坏性变更 | Google Cloud 生态 |
| Microsoft Agent Framework | Agent + 类型化图 Workflow | AutoGen + Semantic Kernel 合并后的继任者，支持 checkpoint、暂停/恢复 | AutoGen 多 Agent 团队迁移要重新设计 | .NET / Python 企业项目；AutoGen 已进入维护模式，新项目不再推荐 |
| AgentScope（2.0） | 统一的 Agent 类 / Msg / Toolkit / middleware | 多 Agent 协作是核心场景，ReAct 循环开箱即用，middleware 可插控制逻辑 | 大版本之间类名和 API 会调整 | 多 Agent 协作；要自主选工具又要外挂规则 |
| CrewAI | Crews（角色分工的 Agent 团队）+ Flows（事件驱动工作流） | 角色分工直观，Flows 补上确定性编排 | 深度定制仍受框架约束 | 多 Agent 角色扮演、业务流程自动化 |
| 自研 | 自定义 | 完全可控 | 开发维护成本高 | 特殊需求，核心系统 |
2. LangGraph 核心概念#
- StateGraph：定义状态流转图（节点=处理函数，边=条件路由）
- Checkpoint：状态持久化，支持断点恢复和回放
- Human-in-the-loop：在关键节点暂停等待人工审批
START → classify_intent
├── "查询" → retrieve → generate → END
├── "操作" → plan → [human_approve] → execute → END
└── "闲聊" → chat → END3. AgentScope：面向多 Agent 的 Python 框架#
定位：阿里通义实验室开源的 Agent 框架，Python、异步优先，从一开始就把多 Agent 协作作为核心场景，同时提供单 Agent 的 ReAct 实现；另有 Java 版（agentscope-java）。2.0 是破坏性升级：原来独立的 AgentScope Runtime（工具沙箱、Agent-as-a-Service API、可观测性）并入核心，1.x 进入维护期（具体组件与版本特性以官方文档为准）。
核心抽象（按职责列；大版本之间类名会调整，以当前版本官方文档为准）：
| 抽象 | 作用 |
|---|---|
Msg | Agent 之间、Agent 与用户之间传递的统一消息对象；2.0 改为 Pydantic 模型，并提供 UserMsg / AssistantMsg / SystemMsg 等工厂方法 |
Agent（ReAct 循环） | 推理 → 调工具 → 观察的循环；1.x 叫 ReActAgent，2.0 重构为统一的 Agent 类，对外暴露 reply / reply_stream |
工具注册（Toolkit） | 注册工具函数，自动生成 schema；2.0 把工具、skills、MCP、工具组都作为一等公民 |
| Model / Formatter | 封装各家模型调用，把消息转成各家 API 格式 |
| 扩展点 | 1.x 用 hook（回复、推理、执行工具前后）；2.0 废弃 hook，改为 agent middleware |
| 多 Agent 编排 | 1.x 用 MsgHub + pipeline 做消息广播和顺序/并行编排；Java 2.0 已移除 pipeline 包（含 MsgHub），改为 middleware + 子 Agent + 事件流，Python 2.0 以官方文档为准 |
和其他框架对比：
| AgentScope | LangGraph | OpenAI Agents SDK | |
|---|---|---|---|
| 编排思路 | 消息驱动，Agent 之间收发 Msg | 显式状态图（节点 + 边） | Agent + Handoff |
| 控制流 | 主要在 Agent 循环和子 Agent 编排里 | 画在图上，最可控 | 轻量，框架代管 |
| 扩展方式 | 在 Agent 上挂 middleware | 加节点、条件边、中断点 | guardrail、hook |
| 适合 | 多 Agent 协作、想要 ReAct 循环开箱即用又要能插控制逻辑 | 流程需要可视化、断点恢复、审批 | 快速搭建，与 OpenAI 模型集成最好 |
选型提示：流程能画成确定的图，用 LangGraph 更直观；想让模型自主选工具，同时在循环外挂终止、预算、权限这类规则，AgentScope 的 middleware 用起来顺手，常见做法是主循环交给框架的 ReAct Agent，约束写成自己的钩子，再用中间件适配到框架上，做法见 [Agent Harness与Hook设计](/topics/ai-agent/Agent Harness与Hook设计)。换框架时要特别检查「静默失效」：原来依赖框架行为的逻辑（超时、token 统计、异常传播、工具入参校验）换框架后可能不报错地失效，要逐个功能对照验证。
4. 四大技术趋势（2025-2026）#
| 趋势 | 内容 | 影响 |
|---|---|---|
| 推理模型（o-series, Extended Thinking） | 模型自身具备深度推理能力 | 减少工具调用次数，一次思考更深 |
| MCP 成为事实标准 | 工具以标准化协议暴露 | Agent 可即插即用接入工具生态 |
| 上下文工程取代 Prompt 工程 | 关注 Context 的组装和管理 | 记忆/检索/压缩成为核心能力 |
| 多模态 Agent | Vision + Tool Calling + Computer Use | Agent 能直接操作 GUI 和理解图片 |
5. Computer Use / Browser Use#
Agent 直接控制键鼠操作 GUI（截图→识别→点击/输入）：
- 场景：自动化测试、RPA 替代、遗留系统集成
- 代表：Anthropic Computer Use、Browser Use SDK、Playwright MCP
6. Coding Agent 崛起#
端到端编写代码、运行测试、修复 Bug：
- 代表：Claude Code、Cursor、GitHub Copilot cloud agent（2026-04 由 Copilot coding agent 更名，在 GitHub Actions 驱动的临时环境里改代码、跑测试，可直接在分支上工作而不必开 PR）
- 核心能力：代码理解 + 工具调用（Shell/Editor/Git）+ 自验证循环
面试回答（2分钟版）
Agent框架经历了三个阶段的演进。最早是LangChain的Chain-based模式，用链式调用串联LLM和工具，生态丰富但抽象过重调试困难；到了1.x，LangChain把重心放到create_agent加middleware，旧的Chain挪进了langchain-classic。然后是LangGraph的Graph-based模式，用显式状态图定义节点和条件路由，支持Checkpoint断点恢复和Human-in-the-loop人工审批，适合复杂多步骤流程；Google ADK 2.0和微软的Agent Framework也都走向了图工作流，微软那边AutoGen已经进入维护模式。现在还有SDK-native路线比如OpenAI Agents SDK和Claude Agent SDK，更轻量原生集成。选型我建议：快速原型用LangChain，复杂流程需要审批和状态管理用LangGraph，绑定特定模型生态用对应SDK，核心系统考虑自研。技术趋势方面我关注四个方向：推理模型让Agent一次思考更深减少工具调用次数，MCP协议正在成为工具集成的事实标准实现即插即用，上下文工程取代Prompt工程成为核心能力——关注Context的组装压缩和管理，多模态Agent具备视觉和Computer Use能力可以直接操作GUI。Coding Agent也在快速发展，能端到端写代码跑测试修Bug，代表有Claude Code、Cursor和GitHub Copilot cloud agent。多Agent协作和ReAct循环开箱即用的场景还可以看AgentScope，它2.0把ReActAgent统一成Agent类、用middleware替代hook。换框架时最大的坑是静默失效：原来依赖框架行为的超时、token统计、异常传播换框架后可能不报错地失效，要逐个功能对照验证。结合项目时可以讲：为什么选这个框架、在哪一层做了取舍、迁移时用什么数据验证行为没变。
追问与易错
追问方向：
- LangChain 和 LangGraph 怎么选？什么时候该迁移？ → 线性流程用 LangChain，需要条件分支/循环/人工审批/状态持久化时迁移到 LangGraph。Agent 复杂度超过”检索→生成”就该考虑迁移；LangChain 1.x 的
create_agent本身跑在 LangGraph 上，需要自定义节点时再下沉到 LangGraph - 推理模型怎么改变 Agent 的设计？还需要 ReAct 循环吗？ → 推理模型（o-series/Extended Thinking）让单次推理更深，减少工具调用次数。仍需 ReAct 处理外部交互，但循环次数更少
- 自研框架什么时候值得？成本怎么评估？ → 当现有框架的抽象层成为障碍（需要精细控制每步行为）或有特殊需求（如 Java 生态 + MCP 原生）。成本：自研 2-3 人月 vs 框架 1 周但后续定制受限
- Computer Use 的准确率够生产用吗？ → 准确率以 OSWorld 等基准的最新榜单为准；简单表单填写可用，复杂 GUI 操作仍不稳定。适合内部工具自动化和 RPA 替代，面向用户的场景需要人工复核
- AutoGen 现在还能选吗？ → AutoGen 已进入维护模式（只修 bug 和安全问题），微软官方建议新项目用 Microsoft Agent Framework；它把 AutoGen 的 Agent 抽象和 Semantic Kernel 的企业能力合并，多 Agent 用类型化图 Workflow 表达，单 Agent 迁移容易，多 Agent 团队要重新设计
易错点：
- ❌ “框架越新越好” → 成熟度和社区生态同样重要，新框架可能缺文档和 debug 工具
- ❌ “用了框架就不需要理解底层” → 出问题时需要看框架源码排查，理解底层 ReAct 原理是基础
- ❌ “推理模型让 Agent 过时了” → 推理模型改变了 Agent 设计，但复杂任务仍需工具调用和多步编排
- ❌ “大家都用 Python 就选 LangChain” → 团队技术栈匹配度和深度定制需求比框架流行度更重要，Java/Spring Boot 团队可以选 Spring AI（Function Calling 与 MCP 原生支持）
- ❌ “框架类名背下来就行” → 这类框架大版本常有破坏性变更（如 AgentScope 2.0 把
ReActAgent并入Agent、hook 换成 middleware），面试时讲职责比讲类名稳