Go语言LLM应用框架横评：langchaingo、llmgo、anyi、Eino实战对比

先交代一下这个横评是怎么来的。上个月我把一个跑在 Python 侧的 LLM Agent 服务迁到 Go 侧，迁移前我心想，这活儿应该不算难，Go 生态这几年也该有一套像 LangChain 的东西了。结果在 GitHub 上搜了一圈，确实搜出了 langchaingo、llmgo、anyi、Eino 这四个名字，可越看越不敢下手——它们有的像 LangChain 的搬运工，有的只有薄薄一层客户端，有的背后站着一家大厂，定位完全不同。这篇东西就是我用实际工程视角过完这四个框架之后的记录：它们各自解决什么问题、在编排、流式、工具调用这些关键维度上谁真的能打，以及最核心的——Go 到底能不能复刻 LangChain 那个级别的成功。

适合谁看：已经在 Go 后端里接 LLM 能力、正在选框架的人；在 Python 生态里被 LangChain 教育过、想知道 Go 世界有没有替代品的人；还有那种纯粹觉得"Python 一套全家桶、Go 只能手写 HTTP"不甘心的人。这篇不站队，只讲实际对比和踩坑经验。

1. 先想清楚：Go 在 LLM 应用开发里到底缺什么

1.1 Python 的护城河与 Go 的尴尬位置

Python 在 AI 领域的统治力来自三层：底层是 PyTorch、HuggingFace 这些基础设施，中间是 LangChain、LlamaIndex 这类应用框架，上层是铺天盖地的教程和案例。这三层互相强化，形成了一条完整的反馈回路：框架吸引开发者，开发者贡献生态，生态反过来又巩固框架的地位。Go 呢？Go 在 AI 领域的角色长期停留在边缘——做 API 网关、做推理服务的调度层、做数据管道的搬运工。你要说 Go 不能做 AI，那不对，但你要说 Go 生态里有像 LangChain 一样的东西，过去三年它确实是空白。

这个空白不是没原因的。真正需要 LangChain 式抽象的人，绝大多数是算法工程师、数据分析师、AI 应用开发者，这些人默认就在 Python 环境里工作。而 Go 的开发者群体是另一批人：系统工程师、基础设施工程师、微服务后端。这批人对"一个抽象框架帮我调用另一个抽象框架"这件事，天然是抗拒的。所以过去很长一段时间，Go 侧的 LLM 应用开发状态就是两个字：裸写。

1.2 没有框架时的原始解法：裸写到底痛在哪

裸写的痛，我举个例子你就懂了。假设你的 Go 服务要调用 OpenAI 兼容的聊天接口，第一版你只需要一个 HTTP POST、一个 JSON 结构体、一把 API Key，确实 50 行就够。但真实需求会很快膨胀：要流式输出，你得自己处理 SSE 流、自己处理 chunk 的拼帧和断句；要支持多个厂商，每个厂商的请求和响应结构都有细微差异，你得写适配层；要工具调用，你得维护一个 JSON Schema 注册表，还要处理工具返回后的二次、三次模型调用；要 RAG，你得自己接 embedding 和向量库；要断点续跑、要超时控制、要 token 统计、要链路追踪……

这些事单独拎出来都不难，难的是它们会组合在一起。我在没有框架的裸写项目里最常遇到的就是"流式 + 工具调用 + 超时"三者叠加：模型第一轮返回一个工具调用意图，流还没读完 context 就被一个新请求取消了，下游拿到的 JSON 是半个，整个 agent 循环直接死锁。这种 bug 排查起来极其消耗时间，因为每一层都是你自己写的，没有任何一个叫"框架"的东西帮你兜底。所以我一直认为，Go 需要 LLM 开发框架这件事根本不需要争论，需求是真实存在的。

1.3 横评前先列一个"必须解决的问题清单"

在对比四个框架之前，我先把它们应该解决的核心问题列个清单，后面所有评价都围绕这张清单展开：

• 模型接入抽象：能不能一套接口适配 OpenAI、Anthropic、Ollama、国产模型等不同厂商？
• 编排模型：多步任务怎么组织？线性流水线够不够？要不要支持条件分支和并行节点？
• 工具调用与 Agent 循环：function calling 的 Schema 怎么管理？多轮工具调用的循环边界在哪？
• 流式与取消：SSE 流式是否一等公民？context 取消能否干净地传播到 LLM 调用？
• 可观测性：能不能看到每一步的输入输出、token 消耗、耗时？
• 周边集成：向量数据库、文档加载、embedding 模型的覆盖度如何？

这六个问题，基本决定了一个 LLM 开发框架的上限。下面是逐个框架的体检报告。

2. 四个框架逐个过：定位、架构与真实观感

2.1 langchaingo：成也"像 LangChain"，败也"像 LangChain"

langchaingo 是这个领域名气和 star 数最高的框架，本质上是把 LangChain 早期那套概念地图原封不动搬进 Go：models、chains、agents、memory、document loaders、vectorstores、output parsers，一个都不少。模型接入方面覆盖了 OpenAI、Anthropic、Gemini、Ollama，能连的向量库和嵌入模型也算得上 Go 生态里最全的。

它的优点非常直白：如果你是从 LangChain 过来的，上手成本几乎为零。chain 就是 chain，agent 就是 agent，连命名习惯都不用改。团队里只要有一个人熟悉 LangChain，其他人照着他的写法抄作业就行。我在 2023 年底第一次用它时就是这个感觉——很亲切，像是给 Go 用户开了一扇通往 Python 世界的门。

但它的缺点恰恰也出在这。它是"移植"，不是"重新设计"，所以 LangChain 早期那批抽象上的毛病也跟着一起搬了过来：Chain 嵌套 Chain 导致排查调用链时层层绕；agent 的执行过程像黑盒，出问题只能靠打日志；流式输出的回调模型用起来很别扭，一个流式回调函数里塞了太多职责；包体也偏重，拉下来依赖一长串。更要命的是，LangChain 自己在 2024 年已经转向 LangGraph 那种图编排心智，而 langchaingo 作为移植项目，天然比上游慢半拍。你如果拿它当 LangChain 的"Go 平替"，就得做好永远追着上游屁股跑的思想准备。

2.2 llmgo：极简派，把 LLM 调用当 HTTP 客户端来做

llmgo 走的是完全相反的路线。它不做 chain、不做 agent、不做 memory、不做 vectorstore，核心就是一个薄薄的客户端层：聊天补全、基础流式、基础的函数调用封装，没了。整个库的代码量很小，API 面窄，读源码半小时就能通读。

这种设计的价值恰恰在"薄"字。你不需要理解任何框架概念，把它当成一个带类型约束的 HTTP client 用就行，业务逻辑、步骤编排、状态管理全部自己掌控。对于那种"我只是要让 Go 服务能稳定地调用 LLM，剩下的我自己来"的团队，llmgo 是最没有思想负担的选择。我甚至见过有人直接在 llmgo 之上自己写了一个比 LangChain 清晰得多的 agent 循环——因为没人拦着他们，也没有框架的 Chain 概念逼着他们往既定模型里套。

代价也很明显：它不是一个完整的应用开发框架。你要 RAG，得自己接 embedding 和向量库；要复杂编排，得自己写状态机；要可视化调试，没有。所以它在我这张对比表里的位置不是"LangChain 替代品"，而是"基础组件"——适合做底座，不适合直接拿来当架构。

2.3 anyi：资料最少，但代表一类"轻量 Agent"思路

老实说，anyi 是这四个里我拿到的公开信息最少的，仓库新、文档少、社区讨论稀疏，我翻到的内容有限。但把它放在横评里仍然有意义，因为它代表了一类不可忽视的思路：砍掉一切不必要的抽象，只保留"模型 + 工具 + 简单的 Agent 循环"这三样东西。

这类轻量 Agent 框架的思路是：不要把什么能力都做成框架的一部分，只要把"模型能调工具、工具结果能回到模型、循环有边界"这件事做好，绝大部分 Agent 应用的地基就稳了。至于记忆、检索、编排，都应该是你自己组合出来的业务代码，而不是框架替你做决定。anyi 具体实现到什么程度，我这边能验证的信息有限，就不展开细节了。但我必须提醒一句：对这类新仓库，看看思路是好的，直接上生产要谨慎——社区规模小意味着遇到了问题大概率只能自己解决。

2.4 Eino：字节开源的正规军，图编排和 IDE 调试是杀手锏

Eino 是这套框架里唯一让我觉得"这不是在复刻 LangChain，而是在跟 LangGraph 对标"的一个。它由字节跳动 Cloudwego 团队开源，定位是 Go 语言的 LLM 应用开发框架，整体分两层：组件层和编排层。组件层提供 ChatModel、Embedding、Retriever、Loader、Parser 这类可插拔接口，编排层提供 Chain 和 Graph 两种结构——Chain 解决线性流水线，Graph 解决带分支、合并、条件跳转的复杂流程。

Eino 最吸引我的三点：第一，强类型。Graph 的节点、边、状态都是用 Go 的类型系统组织的，写错了编译期就报错，而不是等运行时爆 panic。第二，流式是一等公民，并且支持提前退出——条件满足后下游节点直接短路，这在多步 RAG 和 Agent 场景里能省不少 token 和延迟。第三，配套的 EinoDev 插件可以在 GoLand 里可视化看整个执行图，每一步的输入、输出、耗时都能点开看，这解决了我前面说的"chain 排查黑盒"的老大难问题。

当然，Eino 也不是没有门槛。它依赖 Cloudwego 自家的一堆基础库，对不熟悉这个生态的人来说，第一次拉依赖会有一种"我怎么把整个微服务全家桶都装进来了"的错觉；另外它还在快速迭代期，API 变动不算小。但综合看下来，它是四个框架里最有"生产级"自觉的一个。

3. 核心维度横评：编排模型、流式、工具调用与可观测性

3.1 一张表看懂四个框架的能力边界

先上总表：

这张表是我花了一阵子逐个验证后的结果，但我要先泼一盆冷水：表格只能告诉你"有没有"，告诉不了你"好不好用"。同样写着"支持流式"，langchaingo 的流式回调和 Eino 的流式 + 提前退出，用起来是两种完全不同的体验。所以下面把几个关键维度拆开细说。

3.2 编排模型决定架构上限：线性 Chain 与图编排的分水岭

我判断一个 LLM 框架值不值得长期用，第一个看的就是编排模型。固定流水线的场景，比如"检索 → 拼 Prompt → 生成回答"，线性 Chain 完全够用，langchaingo 和 Eino 的 Chain 都能干。但真实业务一旦复杂起来，就会冒出大量"如果……那么……"的分支：命中某条件就走 A 分支，不命中就走 B 分支；两个检索源可以并行，最后合并结果再交给模型。这种拓扑线性 Chain 表达不了，需要的是图。

LangChain 自己就是在这上面栽过跟头的：早期 Chain 套 Chain 的设计撑不住复杂流程，后来才搞出 LangGraph 补课。Eino 大概是看明白了这段历史，把 Graph 直接作为一等公民来做，节点、边、条件、合并都是类型化的，甚至支持子图嵌套。至于 llmgo 和 anyi，这个维度基本靠你自己——你要有意识地在代码层面把流程"图化"，而不是堆 if-else。

3.3 流式输出、取消与超时：Go 并发模型的真正用武之地

流式输出是 LLM 应用和普通 HTTP 接口最不一样的地方：你面对的不是一个完整响应，而是一串持续到达的文本块和事件。这个过程里最容易出的三个问题：SSE 流的断帧解析、客户端中断后上游模型调用还在跑、流还没结束 context 就超时了。

Go 在这个领域其实有天然优势：context 的取消传播是语言级的能力，你可以把取消信号一路透传到模型调用层，让下游顺手把请求断掉，省掉无谓的计费。但前提是框架愿意把这种能力做成设计的一部分，而不是事后补丁。Eino 在这点上做得最彻底：流式、取消、提前退出都是一等公民，几个机制能组合使用。langchaingo 和 llmgo 也能做流式，但取消的语义更多要你自己小心翼翼地传递，稍不注意就会踩到"半包 JSON 被当作完整结果解析"的坑。

3.4 工具调用与 Agent 循环：谁做得好，谁只是"能调"

工具调用这块，我的感受是：Go 框架普遍还停留在"能用"阶段，谈不上"好用"。通用的坑有三个：一是各家模型的 function calling 协议细节不一样，同一个 JSON Schema，OpenAI 收、Anthropic 挑，换个国产模型又可能有自己的脾气；二是工具调用不是一次就能成功的，经常要模型 → 工具 → 结果回填 → 再调模型，循环几次才收敛，这个循环的上限和错误处理必须框架给答案；三是工具的并发执行，Go 明明是做并行的好手，但不少框架的 agent 循环还是串行的，工具一把一把地跑，浪费了语言优势。

Eino 的 ToolsNode + 图编排在这种场景下优势明显：工具节点可以是图里的独立节点，多个工具节点的并行关系用 Graph 表达，循环和条件用边的逻辑表达，每一轮的工具调用都在可视化面板里看得见。langchaingo 的 agent 概念也能做到类似效果，但调试体验差一截，状态流转容易变成黑盒。llmgo 和 anyi 因为骨架很薄，工具调用基本等于"封装了个函数调用协议"，循环和错误处理全靠你写循环的时候自己想清楚。

4. LangChain 的成功配方，Go 这边缺哪几味

4.1 LangChain 赢在时机、生态密度和"定义心智"

先别急着骂 LangChain。它被吐槽得最多的时候，恰恰是它最成功的时候。拆开看，它至少做对了三件事：

第一是时机。ChatGPT 在 2022 年底火起来，整个行业一夜之间都需要一套"怎么构建 LLM 应用"的新语言，LangChain 恰好赶在那个窗口期出现，把所有概念一口气命名了：chain、agent、memory、tool。第二是生态密度。它把几百个模型、向量库、文档加载器、输出解析器都集成进了同一个框架，哪怕每个集成都很浅，但架不住人家多——一个庞大的集成面本身就成了网络效应，你用别的框架就得重新找替代。第三是定义了问题本身。在 LangChain 出现之前，大部分开发者根本不知道"LLM 应用开发"应该被拆成哪些步骤，LangChain 用一种有说服力的方式定义了这个问题，让所有人都按它的词汇表交流。

这三件事构成了一个正循环：越多人用，集成越多；集成越多，越多人用。LangChain 复刻不了的部分，也恰恰在这。

4.2 Go 社区为什么天然抗拒 LangChain 式抽象

Go 社区的价值观和 LangChain 那套哲学是拧着的。Go 讲究的是直白、显式、组合优于继承，"一点点复制好过一点点依赖"是 Go 社区流传很广的原则；而 LangChain 的价值恰恰建立在庞大的隐式抽象层上——你都不知道一个 Chain 背后悄悄加载了多少东西。对 Go 工程师来说，这种黑盒感是反直觉的。

还有个客观限制是人群错配。会用 Go 并且有能力做 LLM 编排的人，大多是基础设施和微服务背景，他们对"框架替你做了什么"极其敏感，遇到黑盒第一反应是掀开盖子看源码。而 LangChain 的生态繁荣靠的是海量的 Python 开发者，这些人愿意容忍粗糙的抽象，因为迭代速度对他们更重要。Go 世界没有这个用户基数，你很难指望一个移植框架能吸引到足够多的贡献者去追平上游。

4.3 复刻 LangChain 也许是个伪命题：Go 的赢法在企业级工程化

我的结论是：Go 框架不该去"复刻 LangChain 的成功"，因为 LangChain 的成功里有太多属于 Python 生态、属于那个时点的运气成分，复制不来。Go 真正能赢的位置是企业级工程化——高并发场景下的稳定调用、单二进制部署的便利、严格类型约束下的可维护性、以及把 LLM 能力嵌进现有微服务体系的能力。

从这个角度看，Eino 的路径最值得关注：它没有把 LangChain 的概念搬运过来，而是从 Go 的生产环境需求反推设计——需要强类型、需要可视化调试、需要流式和取消、需要图编排。这种"从工程反推架构"的思路，在我看来才是 Go 框架的正确姿势。其他三个框架，langchaingo 是翻译者，llmgo 是极简工具，anyi 是轻量探索，它们都解决了一部分问题，但都还停留在"替代某个 Python 工具"的思维里。

5. 选型建议与我的实战心得

5.1 不同场景下我推荐的框架组合

说实话，我现在的态度是"看菜下饭"：

• 只是让 Go 服务稳定调用一个或几个模型，没有复杂的编排需求：llmgo 或者直接用各家官方 SDK 包一层薄客户端，省得引入一个框架的概念负担。
• 团队从 Python 生态迁移，成员都熟悉 LangChain 概念，希望保留相似心智：langchaingo 可以快速上手，但要做好后续自己动手补编排能力的准备。
• 要做生产级 RAG、Agent、多步编排，并且团队愿意花时间学一个新框架：Eino 是当前最值得押注的选项，Graph 和 IDE 调试带来的收益远大于学习成本。
• 想快速验证一个 Agent 想法的原型：anyi 这类轻量框架可以玩一玩，但别急着把生产依赖押上去。

5.2 接入这些框架时最容易踩的五个坑

第一个坑：流式响应的取消没处理好。模型已经开始吐字，客户端断了，上游调用却没 cancel，这一轮照样计费。用 Go 的 context，把取消信号从入口一路传到模型调用层，这几乎是所有框架都要求你自己写对的一件事。

第二个坑：工具调用 Schema 的"厂商脾气"。同一个函数定义，不同模型对严格程度、参数格式、是否允许并行调用的接受度都不一样。做多厂商适配时，别指望框架能帮你抹平一切，兼容层里塞满了 if。

第三个坑：把 Python 的习惯带进 Go。在 Python 里你可以让一个对象动态地承担各种职责，在 Go 里这么干只会收获一堆难维护的 interface。给每个包、每个组件划定最小的接口面，这比什么都重要。

第四个坑：误以为"框架支持 = 框架成熟"。我见过有项目因为文档里写着支持某个向量存储就上了生产，结果调了两天发现是实验性功能。选型前一定要看目标功能在框架仓库里的状态，是正式功能还是 todo。

第五个坑：依赖生命周期风险。这几个框架都年轻，Eino 在快速迭代，anyi 处于早期，langchaingo 在追上游 LangGraph。生产项目务必锁版本、做适配层，防止框架升级把业务代码拖下水。

5.3 一个经验：把框架隔离在业务代码之外

最后说一个我自己的教训。去年我做内部 RAG 服务时，一开始直接用 langchaingo，写得确实快，但后来要加一个很绕的业务规则，发现怎么塞进它的 Chain 结构都不对劲，最后我花了两天时间把编排层从框架里剥了出来，改成自己写的一个几十行的循环，反而一下清爽了。

这不是说 langchaingo 不好，而是说——框架应该是你服务里的一个组件，而不是你服务的形状。正确的做法是在业务代码和框架之间画一条薄薄的适配层：业务层只依赖你自己定义的接口，比如 Chat、Retrieve、Agent，框架只是这些接口背后的一种实现。这样无论框架怎么升级、你换不换框架，业务代码都不受影响。我现在的习惯是：llmgo 这类薄客户端直接当底层依赖、不设适配层，因为它的 API 几乎不会绑架你的架构；Eino 这类功能丰富的框架则加一层轻薄封装，给未来留条退路。

把这句话放在最后：别押宝在任何一个框架上，要押宝在你自己代码的接口边界上。框架能帮你省下最初那五百行胶水代码，但后面那五千行的架构决策，还得你自己做，也只能你自己做。