AI Agent技术趋势与框架选型#
一句话答案#
Agent 框架从 Chain-based（LangChain）演进到 Graph-based（LangGraph）再到 SDK-native（OpenAI Agents SDK），选型核心看状态管理需求和团队技术栈；趋势上推理模型、MCP 标准化、上下文工程正在重塑 Agent 开发范式。
核心要点
1. 主流框架对比#
| 框架 | 核心抽象 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|---|
| LangChain | Chain / Agent | 生态丰富，组件多 | 抽象过重，调试难 | 快速原型，标准 RAG |
| LangGraph | StateGraph | 显式状态机，可视化，支持人工介入 | 学习曲线陡 | 复杂多步骤，需要审批流 |
| OpenAI Agents SDK | Runner / Agent / Handoff | 轻量，原生 Handoff | 绑定 OpenAI 生态 | OpenAI 生态项目 |
| CrewAI | Role-based Agent | 角色分工直观 | 定制能力弱 | 多 Agent 角色扮演 |
| Claude Agent SDK | Agent / Tool / Subagent | 思考链透明，工具原生 | Anthropic 生态 | Claude 生态项目 |
| 自研 | 自定义 | 完全可控 | 开发维护成本高 | 特殊需求，核心系统 |
2. LangGraph 核心概念#
- StateGraph：定义状态流转图（节点=处理函数，边=条件路由）
- Checkpoint：状态持久化，支持断点恢复和回放
- Human-in-the-loop：在关键节点暂停等待人工审批
START → classify_intent
├── "查询" → retrieve → generate → END
├── "操作" → plan → [human_approve] → execute → END
└── "闲聊" → chat → END3. 四大技术趋势（2025-2026）#
| 趋势 | 内容 | 影响 |
|---|---|---|
| 推理模型（o-series, Extended Thinking） | 模型自身具备深度推理能力 | 减少工具调用次数，一次思考更深 |
| MCP 成为事实标准 | 工具以标准化协议暴露 | Agent 可即插即用接入工具生态 |
| 上下文工程取代 Prompt 工程 | 关注 Context 的组装和管理 | 记忆/检索/压缩成为核心能力 |
| 多模态 Agent | Vision + Tool Calling + Computer Use | Agent 能直接操作 GUI 和理解图片 |
4. Computer Use / Browser Use#
Agent 直接控制键鼠操作 GUI（截图→识别→点击/输入）：
- 场景：自动化测试、RPA 替代、遗留系统集成
- 代表：Anthropic Computer Use、Browser Use SDK、Playwright MCP
5. Coding Agent 崛起#
端到端编写代码、运行测试、修复 Bug：
- 代表：Claude Code、Cursor、GitHub Copilot Workspace
- 核心能力：代码理解 + 工具调用（Shell/Editor/Git）+ 自验证循环
面试回答（2分钟版）
Agent框架经历了三个阶段的演进。最早是LangChain的Chain-based模式，用链式调用串联LLM和工具，生态丰富但抽象过重调试困难。然后是LangGraph的Graph-based模式，用显式状态图定义节点和条件路由，支持Checkpoint断点恢复和Human-in-the-loop人工审批，适合复杂多步骤流程。现在还有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。
追问与易错
追问方向：
- LangChain 和 LangGraph 怎么选？什么时候该迁移？ → 线性流程用 LangChain，需要条件分支/循环/人工审批/状态持久化时迁移到 LangGraph。Agent 复杂度超过”检索→生成”就该考虑迁移
- 推理模型怎么改变 Agent 的设计？还需要 ReAct 循环吗？ → 推理模型（o-series/Extended Thinking）让单次推理更深，减少工具调用次数。仍需 ReAct 处理外部交互，但循环次数更少
- 自研框架什么时候值得？成本怎么评估？ → 当现有框架的抽象层成为障碍（需要精细控制每步行为）或有特殊需求（如 Java 生态 + MCP 原生）。成本：自研 2-3 人月 vs 框架 1 周但后续定制受限
- Computer Use 的准确率够生产用吗？ → 当前准确率约 70-80%，简单表单填写可用，复杂 GUI 操作仍不稳定。适合内部工具自动化和 RPA 替代，面向用户的场景需要人工兜底
易错点：
- ❌ “框架越新越好” → 成熟度和社区生态同样重要，新框架可能缺文档和 debug 工具
- ❌ “用了框架就不需要理解底层” → 出问题时需要看框架源码排查，理解底层 ReAct 原理是基础
- ❌ “推理模型让 Agent 过时了” → 推理模型改变了 Agent 设计，但复杂任务仍需工具调用和多步编排
项目实践（DocMind）： 选 Spring AI 不选 LangChain/LangGraph 的原因：Java 技术栈（Spring Boot 生态）+ 需要深度定制 ReAct 循环和工具调用流程 + MCP 原生支持。实践验证：143 个 Java 源文件（~18,200 行后端），35 个 Vue/TS 文件（~6,900 行前端），6 个 Phase 迭代，20 次 A/B 测试均有量化数据。框架选型的核心教训：不要因为”大家都用 Python”就选 LangChain，团队技术栈匹配度和深度定制需求比框架流行度更重要。