1. 为什么是Go语言？——AI框架的另一种可能
1.1 Go在AI领域的尴尬与机会
做后端开发的同行应该都有感受：2023年以ChatGPT为分水岭的大模型爆发，带火的是两套技术栈——Python的LangChain/LlamaIndex生态，以及TypeScript的Vercel AI SDK。Go语言在这场AI浪潮里，很长一段时间处于一个“能调API但不配拥有姓名”的状态。你在GitHub上搜“LangChain Go”，出来的仓库星星数量可能还不如Python版的一个周边模块。
但事情正在起变化。越来越多的企业级后端服务是Go写的，尤其是网关、调度系统、微服务基础设施。当这些系统要接入大模型能力时，Go开发者面临一个尴尬：要么用Python单独起一个AI服务，要么在Go里裸调OpenAI SDK。前者引入跨语言调用复杂度，后者则失去编排、Agent、记忆管理等高级抽象。这就是langchaingo、llmgo、anyi、Eino这批Go语言AI框架出现的真实背景——它们试图在Go的并发哲学和LLM应用开发之间搭一座桥。
我自己的经历是，从2023年底开始，陆续在手头的项目里尝试用Go框架接大模型。踩过不少坑，也对比过这几个框架的取舍。这篇文章想把这些经验摊开聊一聊，帮还在观望的Go开发者少走弯路。
1.2 LangChain的Go化之路：既要又要
LangChain在Python世界的成功，本质上是定义了一套“大模型应用开发的抽象层”：把Prompt、模型、输出解析器、检索器、记忆、Agent、工具调用这些概念标准化。有了这套抽象，开发者可以像搭积木一样组合出复杂的AI应用。
但Go语言社区对这套抽象的态度非常分化。一部分人认为，LangChain过度抽象，概念臃肿，调试困难，与其“复刻LangChain”，不如做减法；另一部分人则认为，没有抽象层，每个项目都要重复造轮子，最终代码库会失控。这种分歧直接导致了一个结果：Go的AI框架没有像Python一样“大一统”，而是走出了几条不同的路。
langchaingo走的是“尽量还原LangChain”的路，llmgo走的是“轻量统一调用”的路，anyi更像一个面向具体场景的工具集，Eino则是字节跳动开源的重编排框架。这四个框架的横评，其实也是在问一个问题：LangChain那套设计哲学，到底适不适合Go？带着这个问题往下看，你会发现答案并不简单。
2. 四个候选框架逐个拆解
2.1 langchaingo：最像LangChain的“移植品”
先说langchaingo，这是目前Go社区里名气最大、Star数最高的LLM应用框架。项目地址在GitHub上，名字就叫langchaingo，目标是做“Go版的LangChain”。
langchaingo的核心抽象和LangChain保持高度一致：
- Chains：把Prompt模板、模型调用、输出解析串成一条执行链路
- Agents：让模型决定调用哪个工具
- Memory：维护多轮对话的历史状态
- Document Loaders与Vector Stores：对接LangChain生态常用的组件，比如加载PDF、文本，并写入向量数据库
代码风格也是照搬LangChain的思路。一个最直观的例子，用langchaingo构造一个简单的LLM调用：
package main import ( "context" "fmt" "log" "github.com/tmc/langchaingo/llms" "github.com/tmc/langchaingo/llms/openai" ) func main() { ctx := context.Background() llm, err := openai.New(openai.WithModel("gpt-4o-mini")) if err != nil { log.Fatal(err) } _, err = llm.Call(ctx, "Explain the concept of a queue in one sentence.", llms.WithTemperature(0.7)) if err != nil { log.Fatal(err) } }如果你是LangChain老手，这段代码几乎不需要解释。它还提供OpenAI、Anthropic、Google Gemini、Ollama等多种后端的统一接口，也就是说，你写业务代码时可以不必绑定某一家模型供应商。
实际使用感受：langchaingo最大的价值是“熟悉”。它会让你想起在Python里写LangChain的日子，概念迁移成本极低。但代价也很明显——它是这四个里面最“重”的。API表面覆盖广，但很多模块还在快速迭代，接口变更比较频繁，有时为了兼容某一家新模型，需要升级到特定版本。
2.2 llmgo：轻量、纯粹的LLM客户端
如果说langchaingo是“全家桶”，llmgo就是“螺丝刀”。llmgo的定位非常聚焦：只做一件事——统一不同LLM提供商的调用接口。它不包含Agent、Memory、Chain这类高阶抽象，而是提供一套干净的客户端封装。
llmgo的设计哲学是“少即是多”。它把模型提供商抽象成统一的Chat接口，你传入messages，拿到response，仅此而已。对于只需要在Go服务里快速接入LLM能力的开发者来说，llmgo的上手成本无限低。
看一个实际应用的例子，用llmgo接OpenAI和Anthropic：
package main import ( "context" "fmt" "log" "github.com/jupiter/llmgo" ) func main() { ctx := context.Background() // 通过统一的接口访问不同模型 chat := llmgo.NewChat(llmgo.ProviderOpenAI, llmgo.WithModel("gpt-4o-mini")) response, err := chat.Complete(ctx, []llmgo.Message{ {Role: llmgo.RoleUser, Content: "你好，介绍一下你自己"}, }) if err != nil { log.Fatal(err) } fmt.Println(response.Content) }在实际项目中，我经常把llmgo当成一个“底层SDK”来用。它不限制你用什么模式实现Agent或多步调用，而是把这些逻辑留给上层代码。对于那些习惯自己掌控流程、不想被框架绑架的开发者来说，llmgo这种“不做多余的事”的态度反而很舒服。
实际使用感受：llmgo最大的优点是小巧、干净、依赖少。缺点也一样明显——它没有解决“应用开发”的问题，只解决了“调用”的问题。你依然要自己处理Prompt模板、上下文管理、重试逻辑、结构化输出解析。如果你指望用llmgo做一个复杂的RAG系统，那还需要自己拼装所有部件。
2.3 anyi：面向场景的Go AI工具箱
anyi这个框架在社区里的知名度相对低，但不代表它没有价值。我接触anyi时最大的感受是，它更像一个“面向场景的工具箱”而不是“开发框架”。anyi提供了大量可直接复用的AI组件：文本摘要、情感分析、意图识别、结构化信息抽取等，每一项都被封装成了可独立调用的函数。
这种设计思路非常Go——函数是一等公民，组合大于继承。anyi项目的核心是一个模型调度层加上若干场景化API。开发者不需要理解复杂的Chain和Agent概念，只需要调用某个函数，传入文本，拿到结果。
举一个实际用法，用anyi做意图识别：
package main import ( "context" "fmt" "log" "example.com/anyi" ) func main() { ctx := context.Background() engine := anyi.New(anyi.WithEndpoint("ollama"), anyi.WithModel("qwen2.5:7b")) intent, err := engine.ClassifyIntent(ctx, "把预算报表发给财务团队") if err != nil { log.Fatal(err) } fmt.Println("意图：", intent.Label, "置信度：", intent.Score) }这个特性让anyi在办公自动化、内容处理这类有明确输出格式的业务场景里非常顺手。
实际使用感受：anyi的取舍很聪明——它不做通用大模型抽象，而是主打“高频场景标准化”。但它的局限在于社区小、文档少，遇到问题基本得自己翻源码。另外，它依赖的底层模型服务需要自己部署或配置，对于只想快速体验的开发者，启动成本也不低。
2.4 Eino：字节系的全能编排框架
Eino是这四个里“背景最硬”的一个。它是字节跳动开源的高层AI应用开发框架，在字节内部已经支撑了不少业务。Eino这个名字来自“Elegant + Inno”的拼写组合，也能看出它的野心：既要优雅，又要创新。
Eino最大的特点是深度支持Graph编排。它有别于简单的Chain串联，而是像LangGraph一样，把流程抽象成图——节点（Node）负责执行，边（Edge）决定流转逻辑。这种设计对复杂Agent和流程控制非常关键。
一个采用Eino的典型工作流逻辑是：先判断用户意图，再决定是调用工具、查询知识库、还是直接回答。这个过程在Eino里可以表达为清晰的状态图。
Eino在字节内部的定位是“大模型应用开发基础设施”，因此它非常注重生产环境的工程能力：可观测性、重试机制、限流、并发控制、流式输出、运行时钩子等，都是Eino开箱即用的功能。这种“生产第一”的取向，正好击中了Go后端团队的痛点。
实际使用感受：Eino的完成度在四个框架里是最高的，整体设计也更工程化。但相应的，学习曲线也是最陡的——它的抽象层级多（Flow、Node、Graph、Processor、Operator等），需要花时间理解概念。文档和示例虽然在逐步完善，但刚开始时会觉得“模块太多，不知从哪入手”。
3. 横评对比：能力矩阵与场景匹配
3.1 功能对比一览
先放一张我整理的对比表，方便大家快速建立整体认知：
| 维度 | langchaingo | llmgo | anyi | Eino |
|---|---|---|---|---|
| 定位 | 全功能应用框架 | 轻量LLM客户端 | 场景化工具箱 | 重编排生产框架 |
| 核心抽象 | Chain / Agent / Memory | Chat接口 | 场景API | Graph / State |
| 模型接入数 | 多（OpenAI、Anthropic、Gemini等） | 多 | 中（依赖配置） | 多（含自研模型） |
| 内置RAG组件 | 有（Document Loader + Vector Store） | 无 | 部分 | 有（扩检索） |
| Agent能力 | 内置工具调用、多步计划 | 无 | 部分 | 支持Graph编排Agent |
| 流式输出 | 支持 | 支持 | 部分 | 支持 |
| 生产特性（重试、限流、监控） | 基础 | 无 | 无 | 完善 |
| 社区活跃度 | 高 | 中 | 低 | 中（背靠字节） |
| 上手难度 | 中 | 极低 | 低 | 高 |
这张表看完，你会发现这四个框架根本不是一类竞争者，而是“光谱”上的不同位置。langchaingo和Eino更像是“框架”，提供完整应用骨架；llmgo和anyi更像是“库”，解决单一层面的问题。理解这一点，比单纯比谁Star多更有价值。
3.2 各自适合什么场景
基于上面的对比，我根据自己的实际项目经验，把它们的适用场景说清楚。
langchaingo适合的场景：你已经对LangChain很熟悉，希望在Go里复刻类似体验；你需要快速搭建一个原型验证概念（PoC），比如一个带RAG和Agent的问答系统。它适合中小团队，因为团队里可以共用LangChain的概念语言，降低沟通成本。
llmgo适合的场景：你有一个存量Go服务（比如API网关、工单系统、内容审核管道），只想给它加一个“智能回复”或“文本分类”能力，不想为了这件事引入整套框架。llmgo就像是给老服务打一个补丁，干净无侵入。
anyi适合的场景：你的业务有大量重复的AI调用模式，比如大量文本分类、信息抽取。anyi把这些操作标准化，让非AI专业的后端同学也能像调用普通函数一样调AI能力。但前提是你愿意适应它的封装方式。
Eino适合的场景：你正在从0搭建一个生产级AI服务，且它承载的是核心业务逻辑，比如复杂的Agent系统、自动化工作流、多步骤任务编排。团队愿意投入时间学习一套新的抽象，并对稳定性、可观测性有较高要求。
就我个人经验而言，选择框架的原则是：先想清楚你要解决的是“调用问题”还是“编排问题”，再决定要不要上重型框架。很多人一上来就搬langchaingo，最后发现只是调个接口，白白引入一堆概念和依赖。
4. 实操体验：用Go框架跑通一个RAG链路
4.1 场景设计与环境准备
光说不练是隔靴搔痒。我设计了一个具体的实操场景：做一个面向内部文档的RAG问答系统。用户提问，系统召回相关文档片段，交给大模型生成回答，同时附上引用来源。这是目前企业应用AI最主流的方式之一。
环境配置如下：
- Go 1.21+
- 向量数据库：本机用Chroma跑内存模式（避免额外部署）
- Embedding模型：使用本地Ollama跑的
nomic-embed-text，省去调外部API的费用 - 大模型：用Ollama跑
qwen2.5:7b，兼顾效果和资源占用
这个组合的好处是全部本地运行，不依赖外网API，适合闭门开发调试。
4.2 用langchaingo实现RAG
langchaingo支持把文档切块、向量化、存进向量库、再做相似度召回。它的Document Loader生态比较丰富，可以直接加载Markdown或PDF文件，配合recursivecharactertextsplitter切块。
核心代码骨架如下：
package main import ( "context" "fmt" "log" "github.com/tmc/langchaingo/chains" "github.com/tmc/langchaingo/embeddings" "github.com/tmc/langchaingo/llms/ollama" "github.com/tmc/langchaingo/schema" "github.com/tmc/langchaingo/vectorstores/chroma" ) func main() { ctx := context.Background() // 初始化Ollama LLM和Embedding llm, err := ollama.New(ollama.WithModel("qwen2.5:7b")) if err != nil { log.Fatal(err) } embedder, err := embeddings.NewEmbedder(llm) if err != nil { log.Fatal(err) } // 初始化Chroma向量库 store, err := chroma.New( chroma.WithDatastore("local"), chroma.WithEmbedder(embedder), ) if err != nil { log.Fatal(err) } // 写入文档 doc := schema.Document{ PageContent: "Go 语言由 Robert Griesemer、Rob Pike 和 Ken Thompson 设计，于 2009 年正式对外发布。", } _, err = store.AddDocuments(ctx, []schema.Document{doc}) if err != nil { log.Fatal(err) } // 检索相关片段 docs, err := store.SimilaritySearch(ctx, "谁设计了Go语言？", 3) if err != nil { log.Fatal(err) } for _, d := range docs { fmt.Println("召回：", d.PageContent) } // 组装QA Chain chain := chains.NewRetrievalQAFromVectorStore(llm, store) answer, err := chain.Call(ctx, map[string]any{ "query": "谁设计了Go语言？", }) if err != nil { log.Fatal(err) } fmt.Println("回答：", answer) }langchaingo把“索引文档-检索-生成回答”这三步封装成了RetrievalQA，几乎是一行代码的事。实际运行中要注意：首次写入Chroma时，Embedding计算会耗时较长，本地CPU跑模型时尤其明显；另外，Chroma会启动一个本地持久化服务，注意端口冲突问题。
4.3 用llmgo实现“极简版”RAG
llmgo因为不提供高层抽象，RAG链路需要我们显式地分步实现。先向量化用户问题，再到文档库中去查找，最后把查询结果拼进Prompt里，交由模型生成回答。这个流程写起来是啰嗦了一点，但每一步都在你掌控之中。
package main import ( "context" "fmt" "log" "github.com/jupiter/llmgo" ) func main() { ctx := context.Background() chat := llmgo.NewChat(llmgo.ProviderOllama, llmgo.WithModel("qwen2.5:7b")) docs := []string{ "Go语言由Robert Griesemer、Rob Pike和Ken Thompson设计，于2009年发布。", "Go语言强调简单、高效和并发编程能力。", } query := "谁设计了Go语言？" // 完整逻辑：检索相关文档片段（这里使用简单关键词匹配作为示例） var contextDocs []string for _, d := range docs { if contains(d, "设计") || contains(d, "发布") { contextDocs = append(contextDocs, d) } } prompt := fmt.Sprintf("基于以下资料回答问题。资料：%v。问题：%s。", contextDocs, query) response, err := chat.Complete(ctx, []llmgo.Message{ {Role: llmgo.RoleUser, Content: prompt}, }) if err != nil { log.Fatal(err) } fmt.Println(response.Content) } func contains(s, sub string) bool { return len(s) > 0 && len(sub) > 0 && indexOf(s, sub) >= 0 } func indexOf(s, sub string) int { for i := 0; i <= len(s)-len(sub); i++ { if s[i:i+len(sub)] == sub { return i } } return -1 }这里用关键词匹配代替了真正的向量检索，只是为了让代码精简。生产环境当然要接真实数据库。体会最深的是：llmgo把“自由”还给你了，但自由意味着责任。你需要自己处理文档上下文截断（context window管理）、相似度计算、错误重试——对于追求可控性的团队，这是优点；对于追求效率的团队，这就是重复劳动。
4.4 用Eino实现带状态的Agent流程
Eino的RAG体验和前面两个完全不同。它鼓励你把流程定义成Graph，每个节点可以是一个检索操作、一个模型调用或一个工具，节点之间有明确的数据流。
大致的Eino实现思路是：
package main import ( "context" "log" "github.com/bytequence/eino/components/tool" "github.com/bytequence/eino/graph" ) func main() { ctx := context.Background() // 定义检索工具 retrieveTool := tool.NewRetriever(tool.WithIndexName("docs")) // 定义模型节点 llmNode := tool.NewChatModel(tool.WithModel("qwen2.5:7b")) // 构建执行图 g := graph.New(graph.WithStateConfig()) g.AddNode("retrieve", retrieveTool) g.AddNode("generate", llmNode) g.AddEdge("retrieve", "generate") runner, err := g.Compile(ctx) if err != nil { log.Fatal(err) } output, err := runner.Run(ctx, "谁设计了Go语言？") if err != nil { log.Fatal(err) } log.Printf("回答：%v", output) }Eino把编排逻辑显式地画成图后，代码的可维护性极大增强。你要调整流程（比如加一个意图识别节点，或加信息过滤节点），只需要在Graph里增减节点和边即可，不用大规模重构代码。但请注意：Eino的Graph API在不同版本间变化比较明显，网上搜到的示例代码不一定能在当前版本编译通过，建议以官方仓库的examples目录为准。
4.5 四个框架的实操体感对比
把上面的过程完整跑下来，它们给开发者的体感差异非常明显：
- langchaingo：一站式体验最接近LangChain，RAG链路开箱即用，但依赖版本兼容需要注意。
- llmgo：需要自己拼装组件，代码量个人看着多一些，步骤是透明的，调试定位问题非常轻松。
- anyi：没有完整RAG链，偏向分类/抽取场景，实际RAG场景中需自行组装。
- Eino：图编排的思维方式需要一段时间适应，一旦适应，复杂流程会变得非常清晰，工程特性也很扎实。
如果让我给一个“能不能用的结论”：这四个都能用，但不要在选型时只凭“上下手快慢”下结论，还要考虑长期维护成本、团队学习成本、以及你项目里AI流程的复杂度演进方向。
5. 常见问题与排查技巧实录
5.1 依赖与版本冲突
Go的模块系统虽然在依赖管理上已经比较成熟，但AI框架迭代速度极快，经常出现“今天能跑，明天升级后报错”的情况。
我踩过最典型的坑是：多个框架同时引入时，它们对go-openai这类底层库的版本要求不一致，导致编译报错。解决办法是锁定底层依赖版本，可以在go.mod中显式声明需要兼容的版本，或者在引入框架前先查看其依赖版本要求。
经验之谈：别急着追新版本。AI框架的每个minor版本都可能引入Breaking Changes，尤其是langchaingo这种抽象层厚的框架。上线前把依赖版本固定好。
5.2 并发调用LLM的隐性问题
Go的并发能力是最大优势，但在LLM调用上要格外小心。你以为的“并发加速”，可能会变成“并发限流”。
许多模型API对并发数有严格限制，超出会返回429（Rate Limit）。Go里用goroutine一把梭，很容易瞬间触发限流。我在项目里用langchaingo跑批量文本处理时，即时发现并发20个请求，很快被OpenAI限流。
解决思路是引入信号量（Semaphore）或令牌桶限流，控制并发数。比如：
sem := make(chan struct{}, 5) // 并发上限5 for _, item := range items { sem <- struct{}{} go func(it string) { defer func() { <-sem }() // 调用LLM }(item) }另外要注意，并发调用时上下文窗口是否超出上游限制。如果多个请求共用同一个Memory，还要加锁保护状态，避免数据竞争。
5.3 本地模型与云端模型的结果漂移
在不同模型之间切换时，输出格式和准确率会出现明显差异，这一点容易忽略。同一个Prompt，GPT-4o能稳定输出JSON，换成Ollama本地跑的小模型可能出现语法错误。
我的做法是：在生产环境使用云端大模型，在开发和测试阶段使用本地小模型，两者之间的能力差异通过测试用例把控。如果你用本地模型做开发，成果合入主分支时，一定要压测云端模型的表现，不要假定“换模型只是换API地址”。
5.4 文档切块粒度怎么调
RAG系统真正跑起来后，你会发现文档切块是一片乱局。切太粗：上下文塞爆，检索不准确；切太细：语义被切断，召回质量下降。
我目前的经验值：通用文档用512个字符左右的块大小，重叠（overlap）设为128个字符左右。但具体项目需要微调——代码文档和自然语言文档的最优参数完全不同。调参时可以用一个验证集，人工标注几个“问题-答案”对，计算召回率和回答准确率的变化。
5.5 流式输出的前端适配
Go后端做SSE流式输出时，很多开发者会踩到“响应头没有正确设置”或者“客户端一直拿不到数据”的坑。使用Eino或langchaingo的流式接口时，注意在HTTP层正确处理Content-Type: text/event-stream，并且不要对响应做缓冲。
一个重要经验：流式输出过程中，每个chunk里包含的是增量token，而不是完整句子。前端拼接时必须累积所有chunk才能得到完整回答。为了便于前端正确处理增量内容，建议在事件格式里带上[DONE]标识，表示流结束。
6. 能否复刻LangChain的成功？——我的判断
6.1 LangChain成功的本质是什么
LangChain的成功不在于代码写得多好，而在于三件事：时机、生态、叙事。
2022年底ChatGPT发布后，所有人都想快速做出LLM应用，LangChain正好提供了一个“标准答案”——你不需要从零分析Prompt怎么设计，直接拉一个Chain就行。它让开发者在最短时间内建立起“能做AI”的信心。
生态方面，LangChain和向量数据库、模型提供商、文档工具形成了强大的正循环——每加入一个集成，LangChain的价值就大一分，而生态伙伴也能借它的流量获客。
这才是最难的：LangChain卖的不是代码，是“标准”。
6.2 Go框架的差距在哪里
四个框架各有优势，但目前都谈不上“复刻LangChain的成功”，原因有几个：
社区规模是最大瓶颈。Python有大量AI研究者、数据科学家在使用，而Go核心用户群是后端的“老油条”，他们对AI的热情和投入远不如Python生态。没有社区，就没有人贡献新集成，就没有教程，没有issue讨论，框架再完善也难破圈。
生态集成也差得远。LangChain的集成数量数以百计，而目前Go框架的模型接入、向量库、工具链都还集中在一线必需项上。像MCP、外部知识库网关、新的国产模型接入，Go框架的响应速度总是慢半拍。
另一个问题是没有统一的API规范。Python生态里LangChain后来者居上，LlamaIndex走差异化路线，仍然有大量追随者。但Go生态这几个框架各自为战，设计理念甚至互相矛盾（重抽象 vs. 轻抽象），长期来看会分裂心力，让潜在贡献者不知道该投奔谁。
6.3 机会在哪里
尽管“复刻LangChain”很难，Go生态却不乏机会。我认为突破口有三个：
第一，重度Agent生产化。Python生态的Agent框架大多偏原型验证，生产级部署的稳定性、并发控制、可观测性短板明显。Eino正在走这条路——用Go的工程优势做纯生产级Agent运行时。如果能补齐社区和生态，Eino有机会成为Agent落地的“运维标准”，虽然不是仿照LangChain，但价值远高于复刻。
第二，企业后端嵌入AI能力的“无感接入”。Go是很多企业后端服务的主力语言，如果llmgo这类轻量方案能把AI能力封装成“像调用Redis一样简单”，让后端开发者无痛接入LLM，这会是Go独有的定位。不需要Agent、不需要Graph，就是简单的、稳定的接口调用。
第三，国产模型与私有化部署的集成。国内大量模型都是Go为主的后端栈，Go框架如果能第一时间适配通义、文心、DeepSeek、Kimi等模型，同时兼容本地私有化部署方案，就能切走相当多的国内市场份额。这个方向需要的是响应速度和本地化适配能力。
与其执着于“复刻LangChain”，不如想清楚Go在AI应用层有一座别人翻不过的山——生产环境。这是Go安身立命的领域，AI应用也终将走向这里。
在我自己日常的项目里，现在不过分依赖单一框架。做快速原型时用langchaingo，因为它模型接入全、RAG组件丰富；做低成本内嵌时用llmgo，因为它简单不造作；做复杂Agent系统时考虑Eino，因为它生产特性扎实。anyi则在特定场景（文本分类、意图识别）里有独特价值。说实话，这四个框架都还不完美，但它给了Go语言一个明确信号：AI应用开发不会一直属于Python，工程化、服务化的AI应用市场，Go有机会占住一个大位。
最后分享一个小策略：选框架前，先写一个“最小可跑通的Demo”，覆盖你生命周期里最重要的那一步（通常是RAG或Agent），跑一遍你就会清楚哪些框架是加分项，哪些是负担。这个习惯，帮我避免了在一次又一次的框架迁移中浪费时间。
