常见的 Agent 开发框架有哪些？怎么选？
一句话回答
按类型可以分成四类：编排框架（如 LangChain、LangGraph），提供模型、工具、检索等组件的统一抽象，并用链或图来编排流程和状态；模型厂商的 Agent SDK（如 OpenAI Agents SDK、Claude Agent SDK），封装好 Agent 循环和常用能力，对自家模型支持最好；多 Agent 框架（如 AutoGen、CrewAI），专注多个 Agent 的分工协作；低代码平台（如 Dify、Coze），可视化搭建，上手快但定制能力有限。选型看可控性、可观测性、团队技术栈和厂商锁定。建议先用原生 API 手写一遍 Agent 循环，理解原理后再按需引入框架。
详细解析
四类框架
| 类型 | 例子 | 提供什么 | 适合 |
|---|---|---|---|
| 编排框架 | LangChain、LangGraph、LlamaIndex | 统一的模型、提示、工具、检索器接口；把流程建模成链或图，支持状态、循环、持久化和人工介入 | 要接多种模型和数据源、流程较复杂的应用 |
| 厂商 Agent SDK | OpenAI Agents SDK、Claude Agent SDK | 现成的 Agent 循环，以及工具调用、交接、护栏、追踪等能力；有的直接内置读写文件、执行命令等工具 | 主要使用某一家的模型，想快速搭出可靠的 Agent |
| 多 Agent 框架 | AutoGen、CrewAI | 定义多个角色、任务和它们之间的协作方式 | 需要多个 Agent 分工协作的场景 |
| 低代码平台 | Dify、Coze | 可视化编排工作流、知识库和 Agent，直接发布成应用或 API | 业务人员搭建、快速验证、内部工具 |
前端和全栈团队还常用面向 TypeScript 的工具包，比如 Vercel AI SDK：统一多家模型的调用方式，支持流式输出和多步工具调用，并提供前端的对话 Hook。LangChain、LangGraph 也都有 JS/TS 版本。
几个代表的特点
- LangGraph：把应用表示成由节点和边组成的图，节点之间共享状态；支持循环和条件分支，可以保存检查点，中断后等待人工确认再恢复。适合需要精细控制流程的长任务
- OpenAI Agents SDK：核心概念是 Agent、工具、交接（handoff）、护栏（guardrails）、会话和追踪，用少量概念组织单 Agent 和多 Agent 应用
- Claude Agent SDK：把 Claude Code 背后的 Agent 运行框架做成了库，内置读写文件、执行命令、搜索等工具，以及上下文管理、权限控制、钩子、子 Agent 和 MCP 接入，适合构建编程或操作文件系统的 Agent
- AutoGen：微软开源的多 Agent 框架，Agent 之间通过收发消息协作。它已转入维护状态，官方建议新用户改用 Microsoft Agent Framework
- Dify：开源，可以私有化部署，适合有数据合规要求、又希望快速搭建的团队
选型维度
| 维度 | 要问的问题 |
|---|---|
| 可控性 | 能不能看到并修改每次发给模型的 Prompt？流程能不能精确控制？抽象层有没有挡住关键细节？ |
| 可观测性 | 能否方便地追踪每一步的输入输出、token 和耗时？能否接入现有的监控和追踪系统？ |
| 团队技术栈 | 团队主要用 TypeScript 还是 Python？框架在这门语言上是否成熟？ |
| 厂商锁定 | 能否方便地切换模型？工具定义、提示词和数据能否迁移？ |
| 部署和运维 | 能否部署在自己的基础设施上？是否支持长时间运行和断点恢复？ |
| 维护成本 | API 变化快不快？升级是否经常带来不兼容的改动？ |
先用原生 API 理解原理
Agent 的核心不过是"消息数组加工具调用循环"，几十到几百行代码就能写出来，见 手写一个最小的 Agent 循环。先手写一遍，再看框架解决了哪些问题：状态持久化、人工介入、多 Agent 编排、追踪……真正需要这些能力时再引入框架，选型时心里也更有数。
面试官可能追问
LangChain 和 LangGraph 是什么关系？
它们出自同一个团队，可以配合使用。LangChain 侧重组件，提供模型、工具、检索器等的统一接口和现成的 Agent；LangGraph 是更底层的编排库，用图和共享状态描述流程，适合需要持久化、人工介入、精细控制的 Agent。LangChain 提供的 Agent 就构建在 LangGraph 之上，LangGraph 也可以脱离 LangChain 单独使用。
低代码平台适合做生产系统吗？
适合流程标准、需求变化快、主要由业务人员维护的场景，比如内部知识库问答、简单的客服机器人。不足是复杂逻辑难以表达，版本管理、代码审查、自动化测试不如代码方便，性能和成本也难以精细优化；有合规要求时，还要看能否私有化部署。常见做法是先用低代码平台快速验证，核心业务再用代码实现。
怎么避免被框架或模型厂商锁定？
把核心资产掌握在自己手里：工具写成普通函数加 JSON Schema，优先做成 MCP Server；提示词放在自己的代码仓库里；数据存在自己的存储中；模型调用经过一层自己的适配器，见 适配器模式。框架只做薄薄的一层编排，再配一套评测集，迁移时能用数据确认效果没有变差。
易错点
- 按热度、Star 数选框架，而不是按需求和团队情况
- 用了框架却从不看实际发给模型的 Prompt，出了问题无从排查
- 以为用了厂商的 SDK 就只能用那一家的模型。有的 SDK 支持接入其他模型，但不同模型对各项特性的支持程度不同，要实际验证
AI 模拟面试官
用自己的话回答，AI 对照参考答案打分、指出遗漏，再追问，最多 3 轮
这道题你掌握了吗？
选一个最接近的状态，没掌握的题会出现在"我的进度 · 待复习"里。
学习记录暂存在本机浏览器。登录后自动同步到账号，换设备也能看到。