🧱 AI Agent 技术栈(2026 版)
在你的 LLM 和一个真正能上生产环境的 Agent 之间,隔着六层基础设施。这篇文章逐层拆解:每层是什么、2024 到 2026 发生了什么、以及最重要的——你的项目到底需要哪几层。
📌 01 · 为什么要重画这张图
文章开篇讲了一个典型场景:你的团队为一个客服聊天机器人选了 LangGraph。三周之后,你们已经搭出了一张有 14 个节点的状态图、一个往 Redis 写数据的自定义 checkpointer,还有一套为「一周才失败一次」的工具调用准备的重试逻辑。而这个 Agent 做的事情是:回答退款问题,调用一个 API。
作者的判断很直接:一个基于 OpenAI SDK 的 50 行脚本,外加两个 MCP server,就能做到同样的事。问题出在哪?——没有人事先梳理过这个问题真正需要哪几层基础设施。
再看参考系的问题。2024 年 11 月,Letta 发布了一张 AI Agent 技术栈图,后来成了作者接触的工程团队里约一半人的默认参考——如果你在 LinkedIn 上刷到过、或在 Slack 频道里见人钉过一张「Agent 分层图」,大概率就源自那篇文章。
但那张图到写作时已经 14 个月 了,期间变化巨大:
- 🔌当时 MCP 还不存在;
- 🧠记忆(Memory)还被当成向量数据库的附属品来处理;
- 📦还没有任何厂商在出官方原生的 Agent SDK;
- 📏评估(Eval)压根不在图上。
🗺️ 02 · 我们到底在画什么
在画栈之前,先回到一个循环。作者在其早前文章《What Is an AI Agent?》中把 Agent 定义为 think–act–observe(思考–行动–观察)循环:模型对任务进行推理,采取一个行动(调用工具、写入记忆),观察结果,然后循环往复,直到任务完成。这个循环是原子单位——本文讲的所有东西,都是让这个循环能在生产环境中可靠、规模化运转的基础设施。
🚧 Agent 栈不是 LLM 栈
一个聊天机器人需要的是推理服务,可能再加上 RAG。而一个 Agent 需要的是:跨多步执行的状态管理、由协议约束的工具访问、跨会话持久化的记忆、自主推理循环,以及实时约束行为的护栏。作者强调:这是一组从根本上不同的基础设施问题。
边界说明:本文映射的是「你的 LLM 与生产级 Agent 之间的六层」,不覆盖训练基础设施、数据管线、模型微调——那些是相邻的栈。RAG 在作者的 Issue #5 里已深入讲过,本文只是拉远镜头,展示 RAG 在大图景里的位置。
🔄 2024 → 2026:重画地图的三件事
- MCP 标准化了工具连接整个「工具层」都是因它而生的新品类。
- 推理模型改变了 Agent 的自主能力边界单次推理调用的 Agent 开始取代一部分多步链条。
- 记忆成为一等公民的架构原语不再是「拴在向量数据库上的事后补丁」。
⚖️ 03 · 评估每一层的三个问题
在每一层做技术选型时,作者建议问三个问题:
🖥️ 04 · 第 1 层:模型与推理(Models & Inference)
这一层的变化「语气大于实质」。两件事改变了格局:
其一,推理模型(reasoning models)——o1、o3、DeepSeek R1、带扩展思考(extended thinking)的 Claude——改变了 Agent 能规划和执行的边界:以前需要多步链条才能解决的问题,现在一次推理调用就能解决。
其二,开源权重模型(open weight)——Llama 3.3、DeepSeek V3、Qwen 2.5——大幅缩小了质量差距,「永远用最大的闭源模型」不再是默认建议。正在形成的模式是:用闭源模型做原型,用开源权重模型上生产。
🔌 05 · 第 2 层:协议与工具(Protocols & Tools)
这一层在 2024 年根本不是一个独立品类——当时每个框架都有自己的一套工具定义 JSON schema。现在 MCP(Model Context Protocol)已经是标准:
- 📈SDK 月下载量 9700 万;
- 🤝被 OpenAI、Google、Microsoft 采纳;
- 🏛️已捐赠给 Linux 基金会。
与此并行,Browser Use(浏览器自动化)爆发式增长——不到一年拿下 7.8 万 GitHub star;而 2024 年还没有任何人把浏览器 Agent 放到生产环境。
Agent 之间也开始互相对话了:IBM 推出了 ACP,Google 推出了 A2A。两者都还不是标准,但它们要解决的问题(Agent 与 Agent 的协作)真实存在且在增长。
💬 没接触过这两类漏洞?点这里换种说法
../../ 之类的相对路径爬出授权目录);「代码注入」大意是把恶意代码混进输入,让系统当成正常指令执行。放在 MCP 场景下:一个工具服务器如果不校验输入,Agent 帮攻击者「动手」的风险就是真实的。🧠 06 · 第 3 层:记忆与知识(Memory & Knowledge)
2024 年,「记忆」的意思就是「挑一个向量数据库,然后做 RAG」。2026 年,记忆是一个一等公民的架构原语,分成三个明确的层级(tier),而三个层级最终都汇入同一个地方:Agent 每次调用时看到的上下文窗口。
上下文窗口本身也变得巨大:Gemini 达到 100 万+ token,Claude 达到 20 万。但更大的窗口并没有消灭对记忆的需求——它改变的是权衡:什么东西直接塞进上下文,什么东西按需检索?
🧩 这层出现的几个新事物
📐 Context Engineering(上下文工程)
它取代了「prompt engineering」成为核心学科:不再是写一个更好的 prompt,而是架构性地设计 Agent 每次调用应该看到什么信息。
当记忆分成三个层级、窗口大小有限而信息无限时,「放什么进窗口」本身就成了一个需要设计的系统问题,而不是一句话措辞问题。
原文给的具体机制是 memory blocks:上下文窗口里的命名、结构化字段,Agent 每一轮都可以读取和改写——不再把所有东西倒进 system prompt,而是让 Agent 自己管理状态:留什么、更新什么、丢什么。
- 🐘pgvector 成了「不需要专用向量数据库的团队」的默认选择——它就是加了个扩展的 Postgres。
- 🕸️GraphRAG 成为第二种检索选项:不做 embedding 匹配,而是沿实体之间的关系行走;这个领域由 Neo4j 领跑。
- 😴Sleep-time compute(睡眠时计算)——Agent 在空闲时间处理信息——还在研究阶段,但预示着 Tier 3 的走向。
① 从 Postgres 里的对话历史 + 结构化 system prompt 开始;
② 当历史超出上下文限制时,再加向量检索;
③ 只有当 Agent 需要跨会话学习时,才加 agentic 的记忆管理。
🧰 07 · 第 4 层:框架与 SDK(Frameworks & SDKs)
每个主要 AI 实验室现在都在出自己的 Agent SDK:OpenAI 有 Agents SDK(由 Swarm 演化而来),Google 发布了 ADK,Microsoft 有 Semantic Kernel 和 AutoGen,Hugging Face 做了 smolagents。两年前,LangChain 是唯一的选择;现在你要在三个阵营里挑——这个选择在 2024 年根本不存在:
起步快,但锁死在一家模型上
可移植,但需要更多搭建工作
完全掌控,自己裸写
LangGraph 坐稳了图式编排的头把交椅:v1.0 于 2025 年 10 月发布,生产部署案例包括 Uber、JPMorgan、LinkedIn、Klarna。LangChain 的 agent 现在底层就构建在 LangGraph 之上。
与此同时,「自己造」阵营也在壮大:2024 年试过 LangChain、跟抽象层搏斗过的团队,现在改写基于厂商 API + MCP 的薄封装。不用框架意味着完全掌控——直到你的 Agent 需要状态管理或复杂分支为止。
📏 08 · 第 5 层:评估与可观测性(Eval & Observability)
这一层在 2024 年几乎不存在。现在,它是最大的缺口。LangChain 的《State of Agent Engineering》调查发现:
实现了可观测性
评估(evals)
「生产质量死掉的地方」
🏗️「评估即基础设施」的三层收敛形态
- 每个 PR 上跑的快速检查Agent 有没有调用正确的工具?
- 夜间回归测试套件用一个 LLM 来评判输出质量(LLM as judge)。
- 持续的生产监控当 Agent 表现漂移(drift)时发出告警。
面向 Agent 的专用基准测试也出现了:Context-Bench(测记忆管理)、Recovery-Bench(测错误恢复)、Terminal-Bench(测 coding agent)。
🛡️ 09 · 第 6 层:护栏与安全(Guardrails & Safety)
Agent 护栏已经从 LLM 护栏中分化出来,成为一门独立学科。2024 年,护栏指的是模型的输入/输出过滤器;2026 年,你的 Agent 会调工具、花钱、采取行动——护栏的含义变成了:给工具调用授权、强制执行速率限制、校验 Agent 实际做了什么。
一批「吃过亏」的团队摸出了 guardrails before action(行动前护栏)模式:把授权强制放在工具执行层,而不是输出层。原因很朴素:等你过滤响应的时候,Agent 已经把那封邮件发出去了。
其他进展:OWASP 发布了 MCP Top 10(beta 版)——第一份真正面向「连接工具的 Agent」的安全检查清单。而部署这块仍然是 DIY 状态:LangGraph Cloud 和 Bedrock Agents 确实存在,但大多数生产团队仍在用 FastAPI + 自己的基础设施部署。作者提醒:这一层是你将花掉最多计划外工程时间的地方。
🎯 10 · 你在造哪种 Agent?
① 🔍 无状态工具调用器(stateless tool caller)—— 周末项目
基于知识库回答问题、查一笔订单、查库存。
一个厂商 SDK + MCP + Postgres。不需要框架,不需要向量数据库。
原文原话:这是一个「周末项目(weekend project)」。
② 🔁 多步工作流(multistep workflow)—— 先建评估再部署
端到端处理一笔退款、跨五个文件评审一个 PR、对支持工单做分诊和路由。
步骤之间相互依赖、事情会在中途失败、Agent 行动前需要人来审批。
LangGraph + MCP + 评估。部署前先建评估——因为这类 Agent 的失败是无声的(break silently)。
③ 📚 会学习的 Agent(an agent that learns)—— 记忆优先
跨会话记住你的偏好、随时间越来越熟悉你的代码库、跨数周追踪项目上下文。
记忆优先(memory-first)的架构 + 向量数据库 + 评估。
编排是容易的部分;难的是决定记住什么、丢掉什么,以及怎么防止旧上下文污染新答案。
④ 🕸️ 多 Agent 系统(multi-agent system)—— 需要全栈
Agent 向其他 Agent 委派任务、把研究任务拆给多个专家、并行运行多条工作流。
完整的六层栈。
两个 Agent 互传上下文就已经很难调试了;五个 Agent,如果每次交接(handoff)上没有 trace 级评估,根本不可能调。原文建议:先建评估基础设施,再建第二个 Agent。
💻 11 · Coding Agent:六层全开的实战样本
作者称 coding agent 是 AI Agent 栈最被验证(most proven)的应用——六层全部同时在运转:
| 层 | Coding Agent 里的实际形态 |
|---|---|
| 🖥️ 推理层 | 这些工具每天服务数亿次请求。Cursor 会根据任务在 Claude、GPT-4 和自家微调模型之间做路由。 |
| 🔌 协议层 | MCP server 连接编辑器、终端、文件系统和 Git——这就是 Agent 读你的代码、跑命令的方式。 |
| 🧠 记忆层 | 代码库感知(codebase-aware)的检索 + 重排(reranking)。Agent 不会读你的整个仓库,而是只取出与这次编辑相关的文件。 |
| 🧰 框架层 | 带 RL 循环的自研编排系统——不是 LangGraph,也不是厂商 SDK,而是为代码生成、评审、迭代专门打造的控制流。 |
| 📏 评估层 | Cursor 根据用户接受/拒绝建议的行为,每 90 分钟重新训练一次它的接受率模型——这就是「评估在生产中持续运行」。 |
| 🛡️ 护栏层 | 沙箱化执行防止 Agent 失控:它可以写代码、跑代码,但被限制在一个容器里,能碰的东西有限。 |
📋 12 · 技术栈速查表(Cheat Sheet)
| 层 | 🧳 状态管理 | 🔒 锁定风险 | 🕳️ demo→生产鸿沟 |
|---|---|---|---|
| 1 · 模型与推理 | 无(API 无状态) | 闭源高 开源低 | 全栈最小 |
| 2 · 协议与工具 | 不存在(调完即走) | 低(MCP 开放标准) | 中(安全与治理) |
| 3 · 记忆与知识 | 本身就是状态层,复杂度全栈最高 | 中(pgvector 可迁,专用工具难迁) | 大(长对话开始遗忘) |
| 4 · 框架与 SDK | SDK 代管 / LangGraph 显式 / DIY 自扛 | 全栈最高(编排代码不可移植) | 大(失败/重试/超时/人审) |
| 5 · 评估与可观测 | 很重要(要看清中间步骤) | 中(OTel 可迁,评估套件难迁) | 全栈最大(原型零评估) |
| 6 · 护栏与安全 | 需要实时追踪 Agent 状态 | 低(多为自写策略代码) | 实际上无限大 |
🔭 13 · 更大的图景
❌ 大多数团队的现状(像还活在 2024)
· 还不知道自己需不需要状态,就先选了 LangGraph;
· 还没用爆 Postgres,就先加了向量数据库;
· 一个能跑的 Agent 都还没发布,就开始设计多 Agent 架构;
· 没有评估、只做输出过滤、system prompt 一直膨胀到把上下文窗口噎死。
✅ 走出来的团队在做什么
· 每次部署都跑评估,而不是一个季度跑一次;
· 护栏放在工具调用层,而不是输出层;
· 记忆架构是设计出来的,不是从框架默认值里继承来的。
前文那张决策流程之所以存在,是因为一个工具调用型聊天机器人和一个多 Agent 研究系统,几乎不共享任何基础设施。把它们当同一种东西对待,你会把前者盖过头、把后者盖不够。作者点破:这中间的差距不是天赋,也不是预算——是「知道哪几层对你这个具体的 Agent 重要」,而不是六层每层都盖一半。
—— 但即便到那时,当生产环境出故障,你仍然需要知道是哪一层坏了。这正是这篇文章存在的意义。
📚 14 · 来源清单(原文引用)
- “The AI Agents Stack”,Letta,2024 年 11 月。
- “Donating the Model Context Protocol and Establishing the Agentic AI Foundation”,Anthropic,2025 年 12 月。
- “120+ Agentic AI Tools Mapped Across 11 Categories [2026]”,StackOne,2026 年 2 月。
- Henrik Plate & Darren Meyer,《Dependency Management Report》,Endor Labs,2026 年 1 月。
- Jason Liu,《Context Engineering Series: Building Better Agentic RAG Systems》,2025 年 8 月。
- “LangChain and LangGraph Agent Frameworks Reach v1.0 Milestones”,LangChain,2025 年 10 月。
- 《State of Agent Engineering》,LangChain,2025 年 12 月。
- Yunfei Bai、Allie Colin、Kashif Imran、Winnie Xiong,“Evaluating AI Agents: Real-World Lessons from Building Agentic Systems at Amazon”,Amazon,2026 年 2 月。
- OWASP MCP Top 10,OWASP。