Agent 框架如何选型？核心能力与设计差异

无论大家之前做的是前端，还是后端，应该都遇到过一种情况，那就是：

同一个需求，通常不只有一种技术方案。

以前端为例。

开发同一个 Web 应用，我们既可以选择 Vue，也可以选择 React。虽然两者的设计思路和生态不同，但大部分业务需求都能完成。

Agent 开发也是一样。

现在可以用来开发 Agent 的框架并不少，LangChain 也不是唯一选择，更不一定适合所有项目。

那么问题就来了：

咱们为什么要专门学习 LangChain？

难道只是因为 LangChain 的 GitHub Star 多，或者网上的教程多吗？

肯定不是的～

Agent 框架的价值是什么

先假设现在要实现一个订单查询 Agent。

用户输入：

查询订单 A1024 当前的处理状态。

模型接收到这个指令之后，判断应该调用 get_order_status，生成 orderId 参数。Tool 返回订单信息以后，模型再把结果整理成用户可以看懂的回答。

如果，咱们只做到这的话，直接使用模型厂商提供的 SDK 就够了。

但是，一个完整的企业级别的 Agent 项目，需要可比这种小 demo 复杂多了。

比如：

• 模型提出调用 Tool Call 以后，谁负责继续执行下一轮？
• Tool 参数不合法怎么办？
• 当前登录用户是谁？
• 是否需要进行权限隔离？
• 一次任务最多允许调用几次模型？
• 执行过程怎样实时推送到页面？

你看，这些问题就很麻烦，如果咱们直接用原生代码写，就很费劲（参考前几章的项目代码量）

所以说，实际企业项目开发中，咱们是必须要使用框架做的。

不同框架采用了什么设计路线

就像前面所说的一样，同一类型的框架（或者说 “技术实现方案”）都有很多，这里跟大家理解一些 Agent 常见的技术方案，方便大家面试和应付领导的时候吹一吹。

第一：模型 SDK

最基础的方案，就是直接使用 DeepSeek、智谱、OpenAI 或其他模型供应商提供的 SDK。

模型 SDK 通常会帮咱们完成请求鉴权、Message 序列化、流式响应和 Tool Calling 数据转换。

但是，模型返回 tool_calls 以后，后面的逻辑咱们都得自己处理了。

第四章写的 AI 编程 Agent，基本就是这种方案。

这种方案最大的好处就是：简单。

几乎不需要额外学习什么语法。

第二：AI SDK

AI SDK 是一套面向 TypeScript 的 AI 开发工具。

它对模型 Provider、文本生成、Tool Calling、结构化输出和 UI Streaming 做了统一封装。

目前也提供了 ToolLoopAgent，可以自动执行多轮 Tool Loop。