今天咱们来聊一个很多朋友都在问的话题：做 Agent 开发，到底该选什么技术栈？

如果你之前已经跟着我们学了 RAG、ReAct、Plan-Execute 这些 Agent 的核心架构设计，那你心里多半已经有一个疑问了：“道理我都懂了，那具体用什么语言、什么框架来落地呢？”

这篇文章就是来帮你回答这个问题的。我会把 Java、Go、Python 三个语言版本的 Agent 开发技术栈全部拆开给你看，每个语言用什么框架、框架能帮你做什么、底层是怎么串起来的，一次性讲明白。

不管你是 Java 出身的后端同学，还是写 Go 的基础架构选手，又或者是 Python 起步的 AI 爱好者，看完这篇你都能找到适合自己的那条路。

先搞清楚：Agent 技术栈到底需要哪些「积木」？

📷 [图片 token=KYA4b8deeomwBmx1O8EcKwAHnGh（未能下载，见飞书原文）]

在聊具体框架之前，我们得先搞清楚一个问题：开发一个 Agent，到底需要哪些技术能力？

你可以把 Agent 想象成一个「会思考、会干活的助手」。那要造一个助手出来，你至少需要这些「积木块」：

第一块：Web 框架（助手的身体）

Agent 总得有个入口，让用户能跟它对话吧？不管是通过 HTTP 接口、WebSocket 还是聊天窗口，你需要一个 Web 框架来承载这些网络通信。它就是 Agent 的「身体」，负责接收请求、返回响应。

第二块：AI 编排框架（助手的大脑）

这是 Agent 技术栈里最核心的部分。所谓「编排」，你可以理解为「导演」。

一个 Agent 在工作的时候，要做很多事情：调用大模型去思考、去知识库里检索文档、调用外部工具获取数据、把多个步骤串成一条工作流……这些事情的先后顺序、怎么衔接、出错了怎么办，都需要有个「导演」来统筹安排。

AI 编排框架就是那个导演。没有它，你就得自己手写所有的流程控制逻辑，想想都累。

第三块：大模型接入（助手的智商）

Agent 的「聪明程度」取决于背后接的是哪个大模型。通义千问、GPT、DeepSeek……不同的模型能力不同、调用方式不同，编排框架需要帮你屏蔽这些差异，让你可以方便地切换模型。

第四块：工具和知识库（助手的技能包）

做 RAG 要接向量数据库，做 ReAct 要注册工具函数，做 Plan-Execute 要编排多步骤任务……这些能力都需要框架提供现成的支持，让你专注于业务逻辑而不是底层对接。

好了，积木块清楚了。那三个语言分别怎么搭这套积木呢？咱们一个一个来看。

Python 版：LangChain + LangGraph

Python 在 AI 领域的地位，怎么说呢，就像 Java 在企业后端的地位一样，属于「当仁不让的主角」。AI 领域绝大多数的论文、模型、工具，第一个版本基本都是 Python 的。所以 Python 的 Agent 生态也是三个语言里最成熟的。

Python 版的技术栈组合是：LangChain（AI 编排框架）+ LangGraph（工作流引擎）。

📷 [图片 token=AO5FbWE39oBDscxiXeVcLO0On8d（未能下载，见飞书原文）]

2.1 LangChain 是什么？

你可能听说过 LangChain 这个名字，它在 AI 开发圈子里几乎是「绕不过去」的存在。但很多同学对它的印象停留在「好像是个 AI 框架」这个层面，具体它干了什么、解决了什么问题，并不太清楚。

咱们从一个实际痛点说起。假设你要用 Python 开发一个简单的 RAG 对话助手，不借助任何框架，你需要做什么？

1. 自己写代码调用大模型的 API（还得处理不同模型的调用差异）

2. 自己对接向量数据库（Milvus、Chroma 各有各的 SDK）

3. 自己写文档切分逻辑（按段落切？按 Token 数切？）

4. 自己写 Embedding 调用逻辑

5. 自己写检索、重排、拼接 Prompt 的流程

6. 自己做对话历史管理（多轮对话要记住上下文）

7. ……

光列出来就知道有多繁琐了吧？而且这些逻辑，每做一个新项目你可能都要重写一遍。

LangChain 做的事情，就是把这些重复性的「脏活累活」全部封装好，让你用几行代码就能搞定。

你可以把 LangChain 理解为一个「AI 开发的工具箱」。它帮你做了三件关键的事情：

第一件：统一模型接口

不管你用的是通义千问、GPT-4、还是 DeepSeek，LangChain 都帮你封装成了统一的接口。你要切换模型？改一行配置就行，业务代码一行都不用动。

这就好比你家里的各种充电器，虽然手机品牌不同，但都用 Type-C 接口。LangChain 就是那个 Type-C 标准，让你不用关心底层差异。

第二件：封装常用组件

文档加载器、文本切分器、Embedding 模型、向量数据库、检索器、对话记忆……这些 AI 开发中常用的组件，LangChain 都帮你封装好了，而且还提供了几十上百种实现。

比如向量数据库，你要用 Milvus 就导入 Milvus 的组件，要换 Chroma 就换个导入，接口是一样的。

第三件：链式编排

LangChain 名字里的「Chain」就是「链」的意思。它允许你把多个组件像搭积木一样串成一条「链」。比如一条 RAG 链可能是：用户问题 → 检索器 → Prompt 模板 → 大模型 → 输出解析器。

你只需要定义好每个环节用什么组件，LangChain 帮你把数据在组件之间自动流转。

说白了，LangChain 就是 AI 开发的「Spring」。Spring 帮 Java 开发者屏蔽了 Web 开发的底层复杂度，LangChain 帮 Python 开发者屏蔽了 AI 开发的底层复杂度。

2.2 那 LangGraph 又是什么？

你可能会想：LangChain 已经能做链式编排了，为什么还需要一个 LangGraph？

好问题。这就要说到 LangChain 的一个局限了。

LangChain 的「链」本质上是一条直线：A → B → C → D，数据从头流到尾，中间没有分叉、没有循环。对于简单的 RAG 场景，这完全够用了。

但 Agent 的工作方式可不是一条直线。

回想一下我们之前讲的 ReAct 模式：思考 → 行动 → 观察 → 再思考 → 再行动……这是一个循环。还有 Plan-Execute 模式：先制定计划 → 执行第一步 → 检查结果 → 可能要修改计划 → 再执行……这里面既有循环，又有分支判断。

用做饭来类比的话：LangChain 的「链」适合做一道简单菜，比如煮面条，步骤就是烧水 → 下面 → 捞出来 → 加调料，一条线走到底。但如果你要做一桌满汉全席，有些菜要同时开做，有些菜要根据前面的结果决定调料放多少，有些菜做砸了要重来，那你就需要一个更高级的「调度系统」。

LangGraph 就是这个调度系统。

LangGraph 的核心概念是图（Graph）。它把 Agent 的工作流程建模成一张图，图里有：

• 节点（Node）：每个节点代表一个「工作步骤」，比如「调用大模型思考」「执行工具」「检查结果」

• 边（Edge）：节点之间的连线，定义了流程的走向。而且边可以是有条件的，比如「如果模型说要调用工具，就走到工具节点；如果模型说可以回答了，就走到结束节点」

而且 LangGraph 还有一个很厉害的特性：状态管理。

在复杂的多步骤 Agent 中，你需要记住「当前执行到哪一步了」「中间产生了什么结果」「计划列表还剩哪些没做」这些信息。LangGraph 内置了一套状态管理机制，每个节点执行完都可以更新全局状态，下一个节点可以读取到最新的状态。

这就好比一个项目经理手里的看板：每完成一个任务就更新看板状态，所有团队成员都能看到最新进展。

2.3 它们怎么配合工作？

搞清楚了两个框架各自的职责，你可能想问：它们是怎么配合的？

其实很简单。LangGraph 负责控制「流程怎么走」，LangChain 提供「每一步用什么工具」。

举个例子，你要做一个 RAG 对话 Agent：

• LangGraph 定义了整体工作流：接收问题 → 判断是否需要检索 → 检索知识库 → 生成回答 → 检查质量 → 输出

• LangChain 提供了每个节点需要的组件：检索器用 LangChain 封装好的向量检索器，大模型调用用 LangChain 封装好的模型接口，Prompt 拼接用 LangChain 的模板

两者搭配，LangGraph 是骨架，LangChain 是血肉。

2.4 Python 版技术栈总览

最后来一张全景图：

Python 这套方案的最大优势是生态成熟。遇到问题网上搜一搜，大概率能找到答案。社区活跃，更新快，新功能通常第一时间支持。

不过也有不足：Python 本身的性能和类型安全在生产环境里是短板，适合快速原型验证和 AI 研究场景，但如果你们团队的主力语言不是 Python，纯粹为了做 Agent 而引入 Python 技术栈，后期维护成本可能会比较高。

Java 版：SpringBoot + Spring AI Alibaba

如果你的团队是 Java 技术栈（国内大量企业都是），那恭喜你，Java 生态里现在也有了非常趁手的 Agent 开发方案：SpringBoot + Spring AI Alibaba。

为什么把 Java 放在第二个讲？因为 Java 版技术栈的设计思路和 Python 版是相通的，理解了 Python 版的逻辑，Java 版你很快就能理解。

📷 [图片 token=RWHebMqCsoAJsixZjLGctxqmnze（未能下载，见飞书原文）]

3.1 为什么是 SpringBoot？

这个问题可能你都不用我回答。对于 Java 开发者来说，SpringBoot 几乎等于「呼吸一样自然」的存在。

但还是简单说一下，SpringBoot 在 Agent 技术栈里扮演的角色就是前面说的「身体」：

• 提供 HTTP/WebSocket 接口，让用户能和 Agent 对话

• 管理依赖注入、配置管理，让代码结构清晰

• 提供流式返回（SSE）的能力，实现「逐字蹦出」的回答效果

• 提供监控、日志、健康检查等生产级基础设施

如果你已经有 SpringBoot 的项目底座，那 Agent 开发就是在现有基础上「加一层 AI 能力」，不需要从零搭一套新架构。

3.2 Spring AI Alibaba 是什么？

这才是 Java 版技术栈的重头戏。

Spring AI Alibaba 是阿里巴巴基于 Spring AI 框架做的增强版本。那问题来了，Spring AI 又是什么？

Spring AI 是 Spring 官方推出的 AI 应用开发框架。就像 Spring Data 帮你简化了数据库操作、Spring Security 帮你简化了安全认证一样，Spring AI 的目的是帮你简化 AI 应用的开发。

它的核心理念和 LangChain 非常像：统一接口、屏蔽差异、简化开发。

但 Spring AI 有个问题：它最初主要对接的是 OpenAI 等国外大模型，对国内的通义千问、文心一言等模型的支持不够好，对国内常用的向量数据库的适配也不够完善。

Spring AI Alibaba 就是来补这个缺的。

它在 Spring AI 的基础上，增强了对国内 AI 生态的支持，尤其是对阿里云的通义系列模型和相关云服务做了深度集成。

用一句话概括：Spring AI Alibaba = Spring AI 的国内增强版，专门为国内开发者的使用场景做了优化。

3.3 Spring AI Alibaba 提供了什么能力？

咱们还是用「积木块」的思路来拆解，看看它怎么帮你搭 Agent。

能力一：统一的模型调用接口

和 LangChain 一样，Spring AI Alibaba 帮你把不同大模型的调用方式统一了。它提供了一个 ChatClient 接口，不管背后是通义千问还是 DeepSeek，你写的代码都是一样的。

这意味着什么呢？意味着你的 Agent 代码和具体的大模型是解耦的。今天用通义千问，明天老板说试试 DeepSeek，你只需要改一下配置文件里的模型名，代码一行不用动。

对于经历过「甲方今天要换这个模型、明天要换那个模型」的同学来说，这简直是救命的特性。

能力二：开箱即用的 RAG 支持

做知识库 Agent 需要的 RAG 能力，Spring AI Alibaba 都帮你封装好了：

• 文档加载：支持加载 PDF、Markdown、HTML 等多种格式的文档

• 文本切分：内置了多种切分策略，帮你把长文档拆成适合检索的片段

• Embedding：对接 Embedding 模型，把文本转成向量

• 向量存储和检索：对接向量数据库，存储向量并支持相似度搜索

这一套下来，一条 RAG 链路就搭好了。你不需要自己去研究怎么调 Milvus 的 SDK、怎么处理不同文档格式的解析差异，框架都帮你包好了。

能力三：Function Call 支持

还记得我们之前讲 ReAct 时提到的 Function Call 吗？Spring AI Alibaba 对这个能力的支持非常优雅。

你只需要写一个普通的 Java 方法，加上注解和描述，框架就会自动把它注册为一个 AI 可以调用的「工具」。大模型在思考的时候，会自动判断需不需要调用你的工具，如果需要，框架会自动帮你完成调用并把结果回传给模型。

这个过程对你来说几乎是透明的。你只需要关心「工具本身的业务逻辑怎么写」，调用时机、参数解析、结果回传这些事情框架全包了。

能力四：工作流编排

这是 Spring AI Alibaba 里非常重要的一个能力，对标的就是 Python 里的 LangGraph。

Spring AI Alibaba 提供了一套 Graph（图） 编排能力，让你可以用图的方式定义 Agent 的工作流。节点、边、条件分支、循环……这些 LangGraph 能做的事情，在 Java 里一样能做。

它还内置了对几种常见 Agent 模式的支持：

• ReAct 模式：思考 → 行动 → 观察的循环

• Plan-Execute 模式：先制定计划，再逐步执行，执行中可以修改计划

这些模式你不需要从零实现，框架提供了现成的「蓝图」，你在蓝图基础上配置自己的工具和提示词就行。

3.4 和 Python 版的对应关系

看到这里，你应该已经发现了：Java 版和 Python 版的架构思路是高度一致的。我给你画一个对照表：

看到了吧？殊途同归。只是换了个语言、换了个框架的名字，核心思路完全一样。

所以如果你已经理解了 Python 版的架构，转到 Java 版几乎是零成本的。反过来也一样。

3.5 Java 版技术栈总览

Java 版方案的最大优势是企业级友好。如果你们团队已经是 Spring 技术栈，引入 Spring AI Alibaba 几乎没有学习门槛，而且 Spring 生态的成熟度、稳定性、监控能力在生产环境里都是有保障的。

另外一个优势是和阿里云生态的深度集成。如果你们公司用的是阿里云的基础设施（通义千问、向量检索服务等），Spring AI Alibaba 在对接上会非常丝滑。

Go 版：GoFrame + Eino

最后来说说 Go 版。Go 语言近几年在云原生、基础架构领域大放异彩，但在 AI 应用开发领域，它的起步确实比 Python 和 Java 要晚一些。

不过别着急，后发不等于落后。Go 版的 Agent 技术栈虽然年轻，但设计上是站在前人肩膀上的，很多地方的思路反而更清晰。

Go 版的技术栈组合是：GoFrame（Web 框架）+ Eino（AI 编排框架）。

📷 [图片 token=SVO0bSongoMeUWxyr0PcXb6enHd（未能下载，见飞书原文）]

4.1 GoFrame 是什么？

GoFrame 是 Go 语言生态里一个非常成熟的企业级开发框架，你可以把它理解为 Go 版的 SpringBoot。

为什么这么说？因为它们解决的问题非常像：

• Web 服务：提供 HTTP 服务、路由管理、中间件支持

• 配置管理：统一管理各种配置文件

• 日志系统：结构化日志、日志分级

• 数据库 ORM：简化数据库操作

• 开发工具链：代码生成、项目脚手架等

如果你是写 Go 的同学，大概率听说过甚至用过 GoFrame。它在国内 Go 社区的影响力很大，文档也是中文的，上手门槛低。

在 Agent 技术栈里，GoFrame 扮演的角色和 SpringBoot 一样，就是提供 Web 服务的底座。Agent 的 HTTP 接口、SSE 流式返回、配置管理等基础设施，都由 GoFrame 来搞定。

4.2 Eino 是什么？

Eino（读音类似「诶诺」）是字节跳动开源的一套 Go 语言 AI 应用开发框架。

如果说 LangChain 是 Python 世界的 AI 编排框架、Spring AI Alibaba 是 Java 世界的 AI 编排框架，那 Eino 就是 Go 世界的 AI 编排框架。

你可能会好奇：为什么字节要自己做一个 Go 版的 AI 框架？

原因很直接。字节跳动内部大量使用 Go 语言，他们在做内部 AI 应用的时候发现：Go 生态里缺一个好用的 AI 编排框架。现有的 AI 框架几乎都是 Python 的，Go 开发者想做 AI 应用，要么硬着头皮写 Python，要么自己从零造轮子。

于是字节就把自己内部沉淀的 AI 应用开发能力抽象出来，做成了 Eino 这个开源框架。它在字节内部已经支撑了大量的 AI 应用，包括大家熟悉的豆包等产品背后的部分能力。

4.3 Eino 提供了什么能力？

Eino 的能力和 LangChain、Spring AI Alibaba 在大方向上是对齐的，但在具体设计上有自己的特色。咱们还是一个一个来拆解。

能力一：组件化的 AI 能力

Eino 把 AI 应用开发中常用的能力抽象成了一个个标准化的「组件」。

比如：

• ChatModel 组件：负责和大模型对话，支持通义千问、DeepSeek 等主流模型

• Retriever 组件：负责从知识库中检索相关文档

• Embedding 组件：负责把文本转成向量

• Tool 组件：负责封装外部工具，让 AI 可以调用

• Document Loader 组件：负责加载各种格式的文档

每个组件都定义了标准的接口（这是 Go 语言的强项，接口设计天然清晰），你可以随时替换具体的实现。比如 Retriever 组件，今天底层用 Milvus，明天换 Elasticsearch，上层代码不需要任何改动。

这种设计和 LangChain 的思路是一脉相承的。Go 语言本身「面向接口编程」的理念在这里发挥得淋漓尽致。

能力二：流式编排

这是 Eino 在设计上比较有特色的一点。

在 AI 应用里，「流式」是一个非常重要的概念。用户和 Agent 对话时，不希望等半天才看到一个完整回答，而是希望回答像打字一样一个一个字蹦出来。这就要求从大模型到最终输出的整条链路，都要支持「流式处理」。

Eino 在编排层面就把「流式」作为一等公民来对待。它的每个组件都天然支持流式输入和输出，编排的时候不需要你额外处理流式逻辑。

打个比方：你在做一条流水线，有的工人干活快、有的干活慢。传统的做法是等一个工人全部做完，再把半成品交给下一个工人。但 Eino 的做法是：前一个工人做出一点成果就立刻传给下一个，大家「流水线式」地并行工作。这样整体的响应速度就快多了。

能力三：图编排（Graph）

和 LangGraph、Spring AI Alibaba 的 Graph 能力一样，Eino 也支持用「图」的方式来编排复杂的 Agent 工作流。

节点、边、条件分支、循环，这些核心能力一个不少。你可以用 Eino 的 Graph 来实现 ReAct、Plan-Execute 等各种 Agent 模式。

而且 Eino 的 Graph 设计充分利用了 Go 语言的并发优势。多个不相互依赖的节点可以自动并行执行，不需要你手动管理协程。这在处理复杂工作流的时候，性能优势是比较明显的。

能力四：回调和可观测性

开发 Agent 有一个很现实的问题：调试太难了。

一个 Agent 的工作流可能有十几个步骤，中间调了好几次大模型、好几个工具。如果最终输出不对，你得知道到底是哪一步出了问题。

Eino 提供了完善的回调机制。你可以在每个组件、每个节点上挂回调函数，记录输入输出、执行耗时、错误信息等。这些信息对于调试和优化 Agent 来说是非常宝贵的。

而且 Eino 还支持和 OpenTelemetry 等可观测性标准集成。也就是说，Agent 每一步的执行轨迹都可以被追踪和可视化，就像一条链路追踪（Trace）一样清晰。

4.4 和另外两个版本的对应关系

同样，来一张三方对照表：

看到了吧？三个版本的架构思路是完全一致的。不管你用哪个语言，要做的事情是一样的，只是实现的框架不同。

4.5 Go 版技术栈总览

Go 版方案的最大优势是性能和并发。Go 语言天生的协程模型和高性能特性，在需要处理大量并发请求的生产环境里非常有优势。如果你们团队的技术栈是 Go（尤其是云原生方向），Eino 是目前最合适的选择。

另外值得一提的是，Eino 背后是字节跳动，框架本身经过了大规模生产验证，稳定性和实用性是有保障的。

三个版本怎么选？

📷 [图片 token=Su9CbekUKoqtRtxLDAbc6Si1nNf（未能下载，见飞书原文）]

讲完了三个语言版本的技术栈，最后来聊聊怎么选的问题。

先说结论：三个版本在架构设计上是等价的，选择的核心依据是你团队的技术栈，而不是框架本身的优劣。

为什么这么说？因为从前面的分析你应该已经看到了，不管是 Python 的 LangChain + LangGraph，还是 Java 的 SpringBoot + Spring AI Alibaba，还是 Go 的 GoFrame + Eino，它们解决的问题是一样的，提供的能力是对等的，只是语法和 API 风格不同。

所以选择标准非常明确：

• 你团队主力写 Python？ 选 LangChain + LangGraph。生态最成熟，社区资源最丰富，遇到问题最容易找到解决方案。适合 AI 研究团队、快速原型验证、数据科学背景的团队。

• 你团队主力写 Java？ 选 SpringBoot + Spring AI Alibaba。和现有 Spring 项目无缝集成，学习成本最低，企业级特性最完善。适合传统互联网公司、金融等对稳定性要求高的场景。

• 你团队主力写 Go？ 选 GoFrame + Eino。性能最强，并发处理最好，和云原生生态契合度最高。适合基础架构团队、对性能有要求的场景。

换句话说，不要为了用某个 AI 框架而去学一门新语言。AI 框架只是工具，你的业务逻辑、团队协作效率、代码可维护性才是最重要的。用你最熟悉的语言，选那个语言里最成熟的 AI 框架，这就是最优解。

当然，如果你是个人学习者，想从零开始学 Agent 开发，我的建议是先从 Python 入手。原因很简单：Python 版的教程最多、社区最活跃、上手最快，你可以用最短的时间跑通一个 Agent 原型，建立起对整个体系的认知。等你理解了核心概念之后，再切换到 Java 或 Go 版，就是换个框架的事儿。

总结

最后，让我们来做一个总复盘。

今天我们把 Agent 开发的三个语言版本的技术栈全部拆解了一遍。核心要记住的就是这几点：

Agent 技术栈需要哪些积木？

• Web 框架（身体）+ AI 编排框架（大脑）+ 大模型接入（智商）+ 工具和知识库（技能包）

Python 版怎么搭？

• LangChain 做组件封装和链式编排 + LangGraph 做复杂工作流的图编排，生态最成熟

Java 版怎么搭？

• SpringBoot 做 Web 底座 + Spring AI Alibaba 做 AI 编排（统一模型接口、RAG、Function Call、Graph 工作流全包了），企业级最友好

Go 版怎么搭？

• GoFrame 做 Web 底座 + Eino 做 AI 编排（组件化设计、原生流式编排、Graph 工作流、可观测性），性能最强

怎么选？

• 团队用什么语言就选什么版本，不要为框架换语言。核心架构思路是完全一致的，换语言只是换了一层皮。

好了，三个语言版本的技术栈全景图就给大家画完了。有了技术栈的认知基础，接下来我们就可以进入具体的实战环节，一步步把 Agent 搭起来。

我们下篇见！