一文梳理Agent开发核心技术栈

公众号名称：AI编程实验室

作者名称：鲁工

发布时间：2026-06-11 16:22

大家好，我是鲁工。

这两年我看过不少人做Agent。

一个下午就能Vibe出一个能跑的demo，接个模型，写几个工具，循环一跑，演示的时候也像那么回事。

但一上生产环境，问题就来了。

原因也不复杂。我们大多数情况下做的是Agent的大脑，Agent外面那层壳没做或者做得不多。

这层壳，行业里现在有个挺火的名字叫Harness。我之前专门写过一篇，感兴趣可以翻：LLM向左，Agent Harness向右。

今天换个角度聊。把这层壳剥丝抽茧，看看2026年一个能上生产的AI Agent，技术栈到底由哪些零件组成，每一层现在都有哪些工具能选。

我用ChatGPT和Gemini跑了两份DeepResearch，把Anthropic、OpenAI、Google、Manus、Cursor几家的公开实践扒拉了一遍，方法论框架梳理了一波。我在它的基础上又补了一轮工具层的调研，把抽象的工程主题转向到具体能用的东西上。

在Agent开发技术栈里，模型可能是大家最不需要操心的那一环。

模型和网关

绝大多数人对Agent技术栈的理解，停在第一层就结束了，就是调一个模型 API。

但生产环境里，我们很少会把自己绑定在一家模型上。

今天Claude强，明天Gemini降价，后天DeepSeek在某个业务场景上突然就够用了。我们需要的是一个能随时切换、能做故障转移、能统一算账的中间层。这层叫模型网关。

现在这块能选的东西已经很成熟了。

自托管想自己掌控的，用LiteLLM，一套接口统一几百家模型。图省事不想运维的，用OpenRouter，注册完就能用，模型覆盖面也最广。要更生产级的路由、日志、预算和护栏，Portkey做得更全。如果你本来就在Vercel上，它的AI Gateway接进去几乎零成本，就是路由逻辑相对简单。

这层看着简单，但风险是，它也是个容易被攻击的一环。

今年3月份，LiteLLM的1.82.7和1.82.8两个版本在PyPI上被供应链投毒，植入了偷凭据的恶意代码，专门捞SSH密钥、云凭据和K8s的secret。

我提这个不是要说LiteLLM不好，它是个好东西。

我想说的是，Agent技术栈每多一层依赖，你的攻击面就多一块。后面聊安全的时候你会发现，这种隐患在这套栈里到处都是。

回到模型本身。

为什么说它最省心？因为模型现在越来越像公用电力了。能力在涨，价格在跌，接口在趋同，换一家的成本越来越低。它正在变成大宗商品和基础设施。

真正决定你的Agent好不好用的，是它外面那一圈。

具体就是：

• Agent framework

• Tool use / MCP

• Agent planning / Workflow orchestration

• Memory / Context management

• State machines / Multi-step execution

• Retry / Fallback / Recovery logic

• Agent evals / Reliability testing

• Cost / Latency optimization

• Human-in-the-loop patterns

如何选择Agent编排框架

在模型基础上，继续往下走，是编排框架，也就是决定你的Agent怎么思考、怎么调工具、多个Agent怎么配合的那套东西。

这是整个技术栈里选择最多、也最容易选错的一层。

2026年第一梯队基本是五分天下。

LangGraph去年10月就发了1.0正式版，主打把Agent流程画成一张有向图，循环、并行、审批门都能表达，还自带检查点和时间回溯，复杂工作流比较稳定。​CrewAI走的是角色制路线，把多个Agent编成一个crew分工干活，社区最大，四万多stars，原生支持MCP和A2A。​OpenAI的Agents SDK主打一个简单，靠handoff在Agent之间转交，从零到能跑最快。​谷歌的ADK把上下文正经拆分成Session、State、Memory三层，多模态和GCP原生是强项。​Anthropic则把Claude Code背后那套harness抽象出来做成了Claude Agent SDK，这个我之前也专门聊过：X上点赞近万的Claude Agent SDK教程，到底讲了什么？

工具一多，新手第一反应就是让人推荐一个框架开始上手。

但要不要用重框架，本身就是个有争议的问题。

Anthropic在那篇被引用烂了的《Building Effective Agents》里给过一个很明确的态度：他们见过的最成功的实现，用的几乎都是简单、可组合的模式，复杂框架反倒少见。他们的建议是，框架能帮你快速起步，但往生产环境推的时候，要敢于把抽象层一层层减掉，回到基础组件。

社区里还有个挺出名的项目叫12-Factor Agents，把当年Heroku那套十二要素搬到了Agent上，核心思想也是一致的：别让框架的抽象把关键决策点给藏起来了。

框架最大的好处是让你三十分钟就能跑通一个多Agent demo。它最大的坑也在这，等你要调一个具体行为、要排一个莫名其妙的bug，会发现关键逻辑全被它包在黑盒里，想动都动不了。

所以我的个人建议是这样。

如果你的流程本身就复杂，有大量循环、分支和人工审批，那LangGraph这种把流程显式画出来的，值得用。如果你做的是结构相对固定的活，即确定性的顺序流，往往比让模型去当协调者更省钱也更稳，这种情况你甚至不一定需要重框架，自己写个循环可能更清爽。

框架是辅助，不能替代人走路。能自己依靠基础组建搭建的部分，尽量自己搭。

Tool Use和MCP

模型是脑子，工具就是手。

Agent区别于Chatbot最大之处，关键就在它能调工具去改变外部世界，搜索、读写文件、执行代码、调API。

底层机制还是function calling。报告里把这件事的本质说得很准，工具调用其实是一道受约束的动作选择题，比单纯的函数映射要讲究得多。怎么定义schema、怎么限制模型在当前状态下只能选哪些动作（Manus那套logit masking就是干这个的），都有讲究的。

工具怎么设计，Anthropic和Manus都有成体系的经验，我在Context Engineering那篇 里整理过，这里不重复展开。一句话原则：工具要自包含、容错、意图清晰，相似的工具别堆太多，不然模型会迷惑。

2025年之后，MCP成了Agent行业的事实标准。去年12月，Anthropic把 MCP捐给了Linux基金会下面新成立的Agentic AI Foundation，OpenAI和Block作为共同发起方，AWS、谷歌、微软、Cloudflare、GitHub一票大厂都进来当支持成员。一个协议能让这帮平时打得头破血流的公司坐一张桌子，本身就说明问题。

规模上，根据公开信息，活跃的公共MCP Server已经过万，PulseMCP这类目录站收录的甚至有15000多个，SDK每月下载量超过9700万次。ChatGPT、Cursor、Gemini、Copilot、VS Code全都接了。

跟MCP配套的还有一个A2A，谷歌发起的，现在也进了Linux基金会。两者分工不一样，MCP管Agent怎么连工具，A2A管Agent怎么跟另一个Agent对话协作。

当然，MCP本身也有局限性。

MCP Server装太多，工具一爆炸，模型反而容易选错，上下文也跟着膨胀，这个也是我在之前文章中经常强调的点，MCP按需安装，定期维护。而且每个第三方server都是一段别人写的代码，跑在你的环境里，安全边界要自己划清楚。又是一个容易被攻击的一环。

但统一接口这件事，对整个生态的价值，怎么估计都不算高。

Memory机制

聊到这你会发现一个规律，每往上一层，离模型就远一点，离工程就近一点。

Memory（记忆）这一层尤其明显。

模型本身是有上下文窗口的，上下文多了或者超出窗口了，模型推理性能就会断崖式下跌。你想让Agent记住用户上周说过什么、记住一个跨越好几天的任务进展，就得自己在外面给设计一套记忆系统。

按照行业实践，记忆可以分为四层。

最上面是推理用的草稿纸，临时的，不落库。往下是会话态，存这一轮对话的状态。再往下是长期记忆，得靠向量检索、关键词检索、结构化查询这些手段去捞。最底下是外部知识库。

放在一两年前，这些基本得自己拿向量数据库手搓。现在不一样了，专门做 Agent记忆的公司已经起来了一批。

社区里最火的是Mem0，四万八千多stars，刚拿了2400万美元的 A 轮，定位是从零到有持久记忆最快的那条路，夹在你的模型和向量库中间，自动从对话里抽事实存下来。​Zep走的是另一条路，底层是个叫Graphiti的时序知识图，它不只存事实，还追踪事实随时间怎么变，做时序推理是强项。​Letta来头最大，它是当年那个MemGPT研究项目的生产化版本，借了操作系统的思路，把内存分成在上下文里的和在外部存储里的，像分页一样换进换出，适合特别长的任务。​LangChain自己也有个LangMem，配套它自己的生态。

底层向量库这块就更不缺了，Pinecone、Weaviate、Qdrant、Chroma、Milvus，还有直接长在Postgres上的pgvector，选哪个看你团队本来的技术栈。

想给产品加个性化、记住用户偏好，Mem0上手最快。要做严肃的时序推理，搞清楚一件事在不同时间点是什么状态，Zep的知识图更对路。本来就泡在LangChain生态里，那LangMem最省心。任务特别长、要反复交班接力，Letta那套分页换页的思路为好。

记忆这件事的工程化，本质是上下文工程的延伸，绕不开缓存、压缩和检索那几件事。

State machines和Multi-step execution

如果让我挑一层，是大多数自研Agent最缺、又最致命的，那就是这一层：状态机和多步执行。

有句话我印象很深：长时多步的Agent，真正的瓶颈很多时候不在推理强不强，在于有没有一个显式的状态机。

这话戳中了一个普遍的幻觉。

很多人以为模型够聪明，多步任务它自己就能扛下来。实际是，步子一多，指令遵循的概率指数级下滑。

我之前那篇Harness里有这么一个计算数据：假设每一步成功率高达95%，看着挺高，但一个二十步的流水线跑下来，端到端能成功的概率只剩大概36%。这就是复合失败，每一步的小误差会被放大。

光靠模型自己硬扛是扛不住的。得把流程显式地建成状态机，每一步都有明确的状态、检查点、重试预算和副作用记录，所有对外的写操作都得带幂等键，挂了能从最近的检查点接着跑，不用从头再来一遍。

这套东西工程上叫Durable execution，持久执行。

它解决的就是crash恢复、重试、长时运行、暂停再续这些事。显式状态机，具体到工程上，很大程度就是这类工具在兜底。

2025年这个赛道明显热了起来，AWS、Cloudflare、Vercel都下场了，背后的推手基本就是Agent基建的需求。

具体选型，老牌标杆是Temporal，它跟LangGraph的检查点、跟Vercel的AI SDK都有现成的整合方案，做耐久Agent是成熟路线。轻量一点、对开发者更友好的有Inngest和Restate。Vercel自己也出了个Workflow，DBOS也在这条线上。

我特别想提醒新手注意这层，是因为它最容易被跳过。

demo阶段你根本碰不到它。进程不会挂，任务几秒就完，谁会想着做恢复。

等你真上了生产，跑一个要几小时的任务，中间机器重启了一次，整个任务从头再来，副作用还重复执行了一遍，那一刻你可能才会意识到这层壳的重要性。

Sandbox

只要你的Agent要执行代码，尤其是模型自己现写的代码，沙箱这层就跑不掉。

道理很朴素，你总不能让一个模型生成的脚本，直接在你的生产机器上root权限裸跑。

万一它一个rm写错了路径，那就彻底砸蛋。

所以得给它一个隔离的、用完即焚的环境。这两年这块也冒出来好几个专门的玩家。

E2B是专门为Agent做的，底层用Firecracker微虚拟机做硬件级隔离，据说差不多半数Fortune 500在用。Vercel的Sandbox主打跑不受信代码，临时算力，用完销毁。Daytona卷的是速度，号称90毫秒就能起一个环境，还带Computer Use，能去操作浏览器和桌面。Modal则把GPU也带上了，H100、H200、B200随便挑，适合要跑重计算的场景。

这一环平时存在感不强，但凡是认真做编码Agent的，没有一个绕得过去。

可观测性和Agent评测

到这一层，我们已经基本把Agent搭起来了。

但搭起来不等于能用。

你怎么知道它干得好不好？挂在哪一步了？这个月烧了多少token？某次改prompt之后，是变好了还是悄悄变差了？

答不上来，你就没法优化，只能凭感觉瞎调。

报告里关于评测有个核心转变讲得特别到位：评估一个Agent，不能再只盯着它最后那个答案对不对，得看它整条轨迹走得顺不顺，工具调得对不对，中间有没有绕远路。

这就是为什么传统那套监控不够用，得上专门的Agent可观测性平台。

这块现在三家分得比较清楚。重度用LangGraph，那LangChain自家的LangSmith最顺手。特别看重评测科学性的话，Braintrust在这块更专。想要开源、框架无关、自己能私有化部署，那就是Langfuse。另外Arize Phoenix也能自托管，Helicone走代理网关路线，零代码改动就能给你算成本。

顺便说个行业动态。Langfuse今年1月被ClickHouse收购了，背后是一轮四个亿美金的融资。一个做Agent可观测性的开源项目能卖到这个价，也能侧面说明这个方向有多被看好。

底层还有个好消息，OpenTelemetry把生成式AI的语义约定也立起来了，agent、workflow、tool、model 这些span怎么记，延迟和token怎么算，开始有统一标准了。这意味着你的埋点不会被某一家平台绑死。不过要提醒一句，这套约定目前不少字段还挂着开发中的稳定级标签，字段名后面可能还会变，别太早写死。

光有trace还不够，还得有评测。

跑评测的框架，DeepEval、Ragas、promptfoo、还有OpenAI自己的Evals都可以用。业界比较公认的做法是分三层，单元测试打底，再用LLM当裁判做主观打分，最后在真实生产流量上做采样。报告里分得更细，从任务级、轨迹级、端到端，一直到对抗安全和线上金丝雀，一共四五层。

Human-in-the-loop

Agent的最后，是把控制权适当还给人。

Agent越自治，越要想清楚一件事：哪些动作，绝对不能让它自己拍板。

删库、对外发邮件、改权限、动钱，这类高风险操作，必须卡一道人工审批。护栏工具像Guardrails AI、英伟达的NeMo Guardrails、Meta的Llama Guard，能在输入输出两端做拦截和合规检查。

但人审这件事，还有一个很容易被忽视的问题，叫审批疲劳。

如果你什么都让人点确认，人很快就会麻木，闭着眼睛一路点同意，那这道关就形同虚设了（如同有人日常使用Claude Code，无脑接受推荐决策）。

所以正确的做法是按风险分级。无副作用的只读操作，放它自己跑。中风险的，让它把要做的事先摆出来给你看一眼。只有真正高危的，才强制人工把关。

Claude Code就是这个思路的好例子，默认只读，要写要执行得你显式授权，权限边界需要用户自己设置。

所以不能把人审理解成对自治能力的妥协。它其实是责任边界的工程化表达。

Agent开发的组件落地顺序

一路梳理下来，大概能感觉到，Agent技术栈涉及到的东西还是蛮多的。

模型、网关、编排框架、工具协议、记忆、状态机、持久执行、沙箱、可观测性、评测、人工护栏，七七八八的，确实不少。

DeepResearch报告给出了如下落地顺序：

它建议分四个阶段。第一阶段，先把最不性感的地基打牢，工具的schema、状态存储、日志、还有一个最小的评测集。第二阶段，再上计划工件、分层记忆、重试和回滚。第三阶段，才轮到并行子Agent、预算治理和缓存优化。要等到第四阶段，才去碰真正的强自治，长时运行、事件驱动、自动修复那些。

为什么是这个顺序？

因为报告里有个判断我非常认同：Agent的性能跃迁，通常不来自某个单点的炫技，而来自harness、上下文、工具、评测这些地方一点一点的小优化，叠加出来的。

地基不稳，上面堆得越花哨，塌得越快。

我之前写过一篇为什么95%的AI Agent产品都会失败？里面聊的那些翻车案例，复盘到最后，几乎都怪不到模型头上，问题全出在这层壳没搭好。记忆没分层、状态没持久化，恢复没设计，评测没建立，权限没边界。模型每强一分，输出的波动反而被放大一分，你会觉得它偶尔惊艳、偶尔离谱，整体根本不可控。

把这些控制面补齐，模型的价值才会从灵光一现，变成可重复的产能。

在这套技术栈里，模型确实是你最不用操心的一层。它会自己变强、变便宜、变得可替换。真正需要你投入心血、也真正构成壁垒的，是它外面这一圈又一圈的壳。

模型是大宗商品，壳才是护城河。

当然，这层壳也别搭得太重。

OpenAI的研究员Noam Brown说过一句话，大意是别花六个月去搭一个可能六个月后就被淘汰的东西。模型在飞速进化，今天你精心搭的Harness，明天可能就被一个更强的模型直接干掉了。

这话其实和上面并不矛盾。

它提醒的是，壳要搭，但要搭得轻、搭得模块化、随时做好被拆掉重来的准备。架构约束、反馈回路、状态管理这些骨架不会消失，但具体的实现得保持可替换。

就像从马车到汽车，马鞭没了，方向盘和刹车会一直在。Harness只会换个名词，但永不消失。

如果觉得有用，点个赞或者在看，也方便更多朋友看到。

感谢您阅读我的文章。我是鲁工，九年AI算法老兵，AI全栈开发者，深耕AI编程赛道与AI科研赛道。

>/ 作者：鲁工

---

内容效果不满意？点此反馈