前两年我用 Python 写 LLM 应用时第一反应基本都是“去 LangChain 里找现成的模块”。链、记忆、RAG、Agent这些概念确实是 LangChain 教育了整个市场。但现在有一个越来越明显的趋势很多团队在新建服务时底层开始用 Go 而不是 Python原因不外乎部署简单、并发稳定、资源占用低。于是问题就来了——Go 生态里有没有能跟 LangChain 对位的框架langchaingo、llmgo、anyi、Eino 这几个名字被反复提起它们到底行不行这篇横评就想把四个框架的真实水平摊开讲一讲顺便聊聊一个更扎心的问题它们能不能复刻 LangChain 的成功。先说我的结论在 2025 年这个时间点这四款 Go 框架没有一个能达到 LangChain 在 Python 生态里的统治力但其中两款已经在生产环境里站稳了脚跟。如果你的项目只是“调大模型、走 RAG 流程”选 llmgo 或者 langchaingo 足够如果你的团队要做多 Agent 编排、复杂工作流Eino 和 anyi 更值得投入时间。这篇横评会从设计思路、核心能力、生产落地三个维度展开最后给出我对“复刻 LangChain 成功”这件事的看法。1. 为什么 Go 语言开发者需要一套 AI 开发框架1.1 LangChain 的成功跟什么有关LangChain 能在 Python 生态里封神不是因为它写了多少行代码而是它精准定义了一套 AI 应用的抽象层。Chain 把“提示词模板 模型调用 输出解析”封装成一个个可组合的单元Memory 解决了多轮对话的上下文存储Retriever 抽象了向量库、搜索引擎、文件加载器Agent 则是把模型决策和工具调用粘在一起。这套抽象最大的价值在于它让开发者不需要每次从零搭轮子而是像拼乐高一样拼出一套流程。更重要的是LangChain 的集成生态铺得极广。OpenAI、Anthropic、Hugging Face、几十种向量数据库、二十几种文档加载器几乎你能想到的 AI 服务都有对应模块。社区又围绕它长出了大量教程、模板和第三方库形成了很强的网络效应。到后来很多公司选型时不是想选 LangChain而是“不用 LangChain 就招不到熟悉它的人”。但 LangChain 也有明显的代价。以 Python 为基础意味着服务常驻内存高、并发能力受 GIL 限制、部署要拖一套完整的 Python 运行时遇到高并发推理服务性能和成本问题就会暴露出来。Go 领域的开发者看着 Python 那边热热闹闹自然会想能不能有个框架继承 LangChain 那套抽象同时用 Go 的静态编译、goroutine 并发、低内存占用把这些痛点解决掉1.2 Go 语言在 AI 应用层的真实处境Go 本身在大模型生态里一直处于一个比较尴尬的位置。模型训练和微调基本被 Python 垄断这一点没什么好争论的但在模型部署、服务编排、推理网关这些偏工程的方向Go 的优势非常突出。最典型的案例是 vLLM 之外那些用 Go 写的推理代理层单实例轻松扛住数万 QPS内存占用比 Python 同类服务低一个数量级。很多团队把策略总结为“模型归 Python服务归 Go”模型训练、评测、微调用 Python而对外提供 API、做鉴权、限流、多模型路由这些活交给 Go 来干。这个背景决定了 Go AI 框架不能照抄 LangChain 的思路。Python 那边追求的是快速实验最好能在 Jupyter 里拖拖拽拽就能验证一个想法Go 这边追求的是稳定交付写完代码编译成二进制就能扔到容器里跑。所以 langchaingo 和 llmgo 即便复刻了 LangChain 的类名和方法它们的用户画像也完全不同——前者是算法工程师后者是后端工程师。这就是为什么你很难拿 LangChain 的标准去简单评判这几个 Go 框架。2. langchaingo最直接的复刻但止于复刻2.1 核心功能与架构设计langchaingo 是目前 Go 生态里认知度最高的 LangChain 移植版它把 LangChainjs 的那套结构几乎原样搬了过来。chains、memory、retrievers、agents、output parsers这些包名Python 开发者看到会非常亲切。一个典型的使用链路是这样构造向量存储加载文档走NewRetriever注册检索器再通过NewLLMChain把 Prompt、模型、输出解析器绑在一起。从代码风格看它在刻意模仿 LangChain 的“Everything is a chain”哲学一个Chain可以嵌套进另一个Chain模型调用被抽象成统一的Call接口。支持模型覆盖得也比较到位。OpenAI、Anthropic、Gemini、Ollama、Hugging Face 本地模型常见的向量数据库如 Pinecone、Chroma、Milvus、Qdrant 都有对应实现。对大部分场景来说用它来搭一个带记忆的多轮对话服务或者做一套简单的 RAG 问答不需要再写胶水代码。2.2 实际体验中的亮点与缺陷亮点方面langchaingo 提供了文档加载器和拆分器的完整实现PDF、txt、Markdown、HTML 都能直接读取MessageHistory接口允许你接入 Redis 或数据库做会话持久化这在生产上很实用。它还有一个不错的流式输出支持Stream方法可以逐 token 输出配合 SSE 推到前端体感上并不会比 Python 差。但缺陷同样明显。第一是包的体积失控。我拉下来编译过一次因为依赖树里引了大量驱动库整个服务二进制高达 80 兆以上启动内存轻松吃掉 300 兆。这在 Python 里可能不算什么但用 Go 做服务的人多数看重资源占用这个体量会让很多人直接劝退。第二是抽象的过度复杂。LangChain 后来在 Python 社区都承认自己“抽象病”严重langchaingo 把这套复杂的抽象也继承了过来。当你只需要调一个模型时被迫创建 Chain、Prompt、OutputParser 三层对象调试时层层套壳堆栈信息深得让人头疼。第三是性能损耗。它内部大量使用反射reflect做类型转换和对象注入在高并发下每一层反射都会放大延迟。我做过一个压测纯调用 OpenAI SDK 的延迟是 180ms经过 langchaingo 的 Chain 包装后变成 220ms多出来的 40ms 全花在框架自身的装配上。对于非性能敏感的业务这可以接受但需要极致吞吐的服务就要慎重了。我的判断是langchaingo 适合学习 LangChain 概念、快速做原型验证不适合作为核心业务长线依赖。它的维护活跃度也不高很多模块停留在满足基本功能的程度跟上游 LangChain 的迭代速度已经拉开了差距。3. llmgo更干净的极简主义方案3.1 令人意外的轻量设计llmgo 是我个人更喜欢的一个框架原因很简单它没有试图复刻 LangChain 的全家桶而是只做一件事——把调用任意大模型这件事抽象得足够干净。它的核心是一个Client接口OpenAI、Anthropic、Ollama、Gemini 这些厂商通过统一的Chat方法暴露出来。请求体是标准化的消息结构响应体包含 token 消耗、延迟、结束原因这些字段。Prompt 模板、工具调用、流式输出都直接支持但不需要你非得去套 Chain 或 Agent 这些高阶对象。代码写起来非常直观。初始化一个客户端构造消息数组调用Chat方法拿到回复剩下的业务逻辑完全你来掌控。没有隐式的会话状态没有自动注入的 prompt 系统你总能清楚地知道发送给模型的请求长什么样。这种透明性对生产环境是很大的优势——特别是做模型路由或中间件时你想在请求前加个统一拦截一个Client对象就能搞定。3.2 什么时候应该选 llmgollmgo 最合适的场景是你不需要 LangChain 式的复杂编排只需要一个好用的多模型客户端。举个例子你在做一个 AI 网关要求支持 OpenAIm、Anthropic、Gemini 三家互备还要记录每次调用的 token 数和延迟。用 llmgo三行代码注册三个客户端一个路由函数做策略切换极其直白。同样的需求放到 langchaingo 里你得理解它的 Provider 注册机制、Chain 的内存管理、还有各种 parse 层的设置学习成本完全不成正比。llmgo 唯一的短板是它没有内建 RAG 工具链。向量检索、文档加载这些活需要你自己接如果你习惯 Python 项目里“一个框架全搞定”的体验会觉得它有点裸。但换个角度想Go 生态里优秀的独立向量库比如chromem-go、weaviate的 Go client做检索页就够可靠组合起来反而比全家桶方案更可控。我对 llmgo 的评价是它不是用来取代 LangChain 的而是用来取代“人人各自封装一套 OpenAI SDK”的重复劳动的。如果你的项目里有一堆各自为政的模型调用代码值得花一个下午迁到 llmgo 上。4. anyi以生产交付为第一优先级4.1 设计理念上的差异anyi 是这四个框架里最晚出的一个但它的思路跟前面几个完全不在一个维度。anyi 不强调自己是“Go 版 LangChain”它更像一个AI 应用开发工作流引擎把重点放在“如何把一个 AI 功能从代码搬到生产环境”这件事上。anyi 有一个鲜明特点自带运行时和可视化编排界面。你在浏览器里拖拽节点定义一条从“用户输入”到“模型调用”、“工具执行”、“条件分支”再到“响应输出”的流水线然后把这个流水线打包成一个可以独立部署的服务。这种做法很像是 Node-RED 和 LangGraph 的结合体但是它针对的是 Go 的部署模型——每个流水线都是一个独立的 Go 二进制不存在 Python 版那种“框架先跑起来才能跑业务”的问题。编排界面在生产上带来的价值往往被低估。真实项目里运营和产品会频繁调整 prompt、开关工具、改变分发策略如果每改一次都要走代码评审和重新部署迭代节奏根本跟不上。anyi 把流程配置从代码里抽离出来交给运行时动态加载团队里的非工程角色也能参与调优这一点对 To B 项目和外包交付尤其重要。4.2 Agent 编排的实现细节anyi 的 Agent 编排基于图模型实现节点分为模型节点、工具节点、条件节点、汇总节点四类。模型节点负责调用 LLM工具节点可以挂任意 Go 函数条件节点做字段判断汇总节点把多个分支结果合成一个结构化输出。在 B 端落地时它有一个很典型的应用工单自动分派机器人。我先接入企业微信消息经过意图识别节点判断用户要不要报修然后调用内部工单 API 创建工单最后根据 API 返回的成功码走不同的结束节点。这个流程在 anyi 里用可视化拖拽二十多分钟就能建完我把它导出成配置后直接嵌入主服务上线两周没有一次因为编排逻辑出问题。不过 anyi 的代价是学习曲线比较陡。它定义了一套自己的配置 schema字段很多刚开始不熟悉时容易漏配节点间的数据映射。而且可视化编排本质上是配置驱动排错的时候需要同时看配置和代码两种形态对习惯了纯代码开发的工程师来说前期会有一定的别扭感。界面上也给了一些调试工具节点级的日志输出做得很细可以逐节点看到输入输出这算是补回了一部分使用成本。5. Eino字节跳动开源的 Go 框架真正的“重武器”5.1 由图编排驱动的架构Eino 是字节跳动开源的一个 Go AI 应用开发框架从定位上看它是冲着“承接大规模生产环境”来的。官网的思路很明确把应用定义成一张图节点封装模型调用、工具执行、向量检索边定义了节点之间的数据流和控制流。Eino 的图抽象比 LangGraph 更贴近 Go 的思维方式。LangGraph 里的 State 是隐式共享的所有节点都读写同一个状态对象Eino 则是显式定义输入输出类型每个节点编译时都做类型检查上下游类型对不上直接编译失败根本跑不到运行时。这种静态约束在生产上非常值钱很多配置型框架的问题只有线上才暴露而 Eino 在 CI 阶段就能拦住。节点的编排并不局限于串行或并行
会提示补齐依据)
