跳到主要内容

AI Agent 技术栈与框架对比

开始做 AI Agent 之后，很多人都会很快遇到另一个现实问题：

到底该选什么技术栈？

因为一眼看过去，会发现这个领域有很多层东西都在同时变化：

  • 模型 API
  • Agent Framework
  • 工具调用层
  • Memory / RAG 方案
  • Observability 平台
  • Evals 工具

这很容易让人产生一种错觉：

做 Agent 就是先选一个“最强框架”。

但真实工程里，技术选型通常不是先找“最强”，而是先分清：

  • 哪一层在解决什么问题
  • 哪一层必须自己掌控
  • 哪一层可以借助框架

这篇文档的目标，就是从工程视角把 Agent 技术栈拆清楚，再讲清楚常见框架和方案到底适合什么场景。

1. 先看一个最重要的结论​

如果只先记一句话，我建议记这个：

AI Agent 没有一把梭的万能框架，真正要选的是一套分层清晰、职责明确、和你当前阶段匹配的技术组合。

技术栈选择不是单点决策，而是一个分层组合问题。

2. 先把 Agent 技术栈拆成几层​

你可以先把一个 Agent 系统理解成下面 6 层：

  1. Model / API Layer
  2. Orchestration / Framework Layer
  3. Tool Layer
  4. Memory / Retrieval Layer
  5. Observability / Evals Layer
  6. Application Layer

这些层不是每一层都必须上重型工具，但你最好知道它们的边界。

3. Model / API Layer：模型与推理能力层​

这一层主要决定：

  • 模型能力上限
  • 推理质量
  • 成本
  • 延迟
  • 上下文窗口
  • 工具调用能力

从工程角度看，你在这一层主要关心的是：

  • 模型是否稳定
  • 是否支持结构化输出
  • 是否支持工具调用
  • 成本和时延是否可接受

3.1 什么时候优先选简单 API 封装​

如果你还在早期探索，通常优先保持简单：

  • 直接用一层很薄的 API 封装
  • 清楚掌握请求和响应结构

因为这能让你更容易理解系统真实行为。

3.2 什么时候需要更复杂的抽象​

当你开始需要：

  • 多模型切换
  • fallback
  • 成本路由
  • 不同任务用不同模型

这时再考虑更高层的抽象会更有价值。

4. Orchestration / Framework Layer：编排与 Agent 框架层​

这一层通常是大家最关注的，也是最容易误解的。

它主要解决：

  • Agent Loop 怎么写
  • 工具怎么注册
  • 状态怎么流动
  • 多步执行怎么编排

4.1 这层常见有 3 种做法​

4.1.1 纯手写编排​

也就是自己写：

  • prompt
  • tool schema
  • loop
  • state

优点：

  • 最透明
  • 最容易理解系统行为
  • 调试最直接

缺点：

  • 重复工作多
  • 扩展时需要自己维护更多结构

这通常很适合学习阶段和最小系统。

4.1.2 轻量编排库​

轻量库通常会帮你做一部分事情，比如：

  • 统一消息格式
  • 工具注册
  • 基础链路封装

优点：

  • 比全手写省力
  • 还能保持较强可控性

缺点：

  • 抽象层一旦不贴合需求，还是要自己兜底

4.1.3 重型 Agent Framework​

重型框架通常会覆盖更多：

  • Agent graph
  • Planner
  • Memory
  • Multi-agent
  • tracing hooks

优点：

  • 起步快
  • 复杂模式现成可用

缺点：

  • 隐式行为变多
  • 调试复杂
  • 学习成本上升

所以是否上重型框架，更多是工程阶段和系统复杂度问题，而不是“越重越高级”。

5. Tool Layer：工具层​

这一层解决的是：

  • Agent 如何和外部世界交互

比如：

  • 搜索
  • 数据库查询
  • 内部 API 调用
  • 文件读写
  • 消息发送

5.1 这层的关键不是框架，而是接口设计​

很多 Agent 的稳定性问题，不是因为框架选错，而是因为工具定义太差。

好的工具层通常要做到：

  • 职责单一
  • 参数明确
  • 返回结构稳定
  • 错误可处理

5.2 选型时该关注什么​

比起“工具接入库多不多”，你更应该关注：

  • 工具 schema 是否清晰
  • 权限与风险边界是否可控
  • 调用结果是否易于回注给模型

6. Memory / Retrieval Layer：记忆与检索层​

这一层通常包含两件事：

  • Memory
  • RAG / Retrieval

6.1 Memory 关注长期连续性​

比如：

  • 用户偏好
  • 项目背景
  • 跨轮状态延续

6.2 Retrieval 关注按需拿知识​

比如：

  • 向量检索
  • 关键词检索
  • 混合检索
  • rerank

6.3 选型时最容易犯的错​

很多人会过早把 Memory 和 RAG 做得很复杂。

但大多数系统早期更需要的是：

  • 清晰的上下文装配
  • 稳定的任务状态
  • 足够简单的检索链路

而不是一上来上很重的“长期记忆平台”。

7. Observability / Evals Layer：可观测与评估层​

这一层经常被低估，但它其实是 Agent 从 Demo 走向工程化的关键。

7.1 Observability 解决什么​

它解决：

  • 单次运行怎么看
  • 工具调用怎么追
  • 状态变化怎么查
  • 问题怎么复盘

7.2 Evals 解决什么​

它解决：

  • 这个版本和上个版本比到底有没有变好
  • 哪些任务提升了
  • 哪些场景退化了

7.3 这一层选型时该关注什么​

你更应该关注：

  • 是否能记录关键 trace
  • 是否能沉淀任务样本
  • 是否能支持回归验证

而不是只看界面漂不漂亮。

8. 常见技术栈组合方式​

8.1 学习期组合​

最适合边学边做的组合通常是：

  • 简单模型 API
  • 手写或轻量编排
  • 1 到 2 个工具
  • 最小状态对象
  • 基础日志

优点：

  • 最容易理解 Agent 本质
  • 最容易调试

8.2 原型期组合​

适合：

  • 已经跑通几个场景
  • 想加快实验迭代

常见组合是：

  • 稳定模型 API
  • 轻量编排层
  • 基础 RAG
  • 工具注册层
  • 简单评估集

8.3 生产期组合​

适合：

  • 已有明确任务边界
  • 开始关注稳定性与治理

更常见的关注点会变成：

  • 路由与 fallback
  • risk guardrails
  • trace
  • evals
  • regression
  • cost control

生产期技术栈追求的不是更“花”，而是更“稳”、更“可治理”。

9. 常见框架选择误区​

9.1 先选框架，再想任务​

这是最常见的倒置。

更稳的顺序通常是：

  1. 先明确任务
  2. 再明确系统形态
  3. 最后再选框架

9.2 觉得重框架一定更适合 Agent​

不是。

很多时候系统真正需要的只是：

  • 清晰 loop
  • 好工具
  • 好状态
  • 好评估

这些并不一定需要重框架。

9.3 把技术栈问题理解成单一框架问题​

Agent 技术栈本质上是分层组合问题，而不是“押宝某一个库”。

9.4 忽视可观测和评估层​

很多人把精力都花在模型和框架上，却忽略了：

  • trace
  • regression
  • evals

结果系统越做越难稳。

10. 一个很实用的选型原则​

如果当前正在做选择，可以优先遵循下面 4 条：

10.1 从任务反推，而不是从框架正推​

先问任务需要什么，再问框架能不能帮上忙。

10.2 优先保持透明度​

在学习阶段，能看懂系统为什么这么跑，比“封装得很高级”更重要。

10.3 只在复杂度真正出现时再加抽象​

不要为了“以后可能会用到”而过早引入太重的层。

10.4 把工程闭环和能力闭环一起考虑​

选型时不仅要看“它能不能跑”，还要看：

  • 好不好调
  • 好不好评
  • 好不好回归

11. 一个推荐的学习与选型顺序​

如果当前主要还是学习阶段，可以按下面这个顺序来：

  1. 先用最简单的模型 API
  2. 自己手写一个最小 Agent Loop
  3. 接一到两个工具
  4. 理清状态和上下文
  5. 再看轻量编排层能帮你省什么
  6. 最后才评估是否值得引入重框架和更复杂平台

这样你能先学到 Agent 的本质，再去用框架，而不是被框架反过来塑形。

12. 一句话总结​

真正成熟的 AI Agent 技术选型，不是追求：

  • 最火的框架
  • 最复杂的架构
  • 最多的抽象层

而是追求：

在模型、编排、工具、记忆、检索、可观测和评估之间，做出一套足够清晰、足够可控、并且和当前阶段匹配的分层组合。

对学习者来说，最好的技术栈往往不是“功能最全”的那套，而是：

最能让你真正看懂 Agent 是怎么运转的那套。