用 Go 写后端、CLI 或运维工具时，真正让人犹豫的往往不是“能不能接 AI”，而是该先选哪一层库：直接调云端模型、做 MCP 服务端、接本地推理，还是顺手把 RAG 链路也搭起来。Go 的 AI 生态确实不像 Python、Node 那样集中，但常见场景已经有比较稳定的选择；本文就按这四类需求拆开看，并把新项目、老项目分别适合的路线讲清楚。
调用云端大模型：优先看官方 SDK 与兼容接口
如果你的需求是调用 OpenAI、国产大模型，或者任何兼容 OpenAI 协议的服务，Go 里最值得优先看的仍然是官方路线。
新项目为什么更适合 openai-go
openai-go（github.com/openai/openai-go）是 OpenAI 官方维护的 Go 库，覆盖 Chat 补全、流式输出、Function Calling、Embeddings、语音、图像等能力，接口设计与官方 REST API 基本保持一致。对新项目来说，这意味着两点价值：
- 后续 API 变更更容易跟进；
- 能力覆盖更完整，减少中途换库成本。
如果你的系统本身就是 Go 后端，想把大模型能力尽快接进业务流里，openai-go 通常是最省判断成本的起点。
老项目为什么还能继续用 go-openai
sashabaranov/go-openai 是社区里使用多年的老牌库，接口风格更偏传统，很多存量项目已经稳定运行在这套封装上。对于这类项目，没必要为了“追新”立刻重构；如果当前调用稳定、封装成熟，继续保留也完全合理。
更实际的做法是：老链路不动，新功能再评估是否切到 openai-go。这样既不会打乱现有服务，也能逐步靠近官方 SDK 的更新节奏。
兼容 OpenAI 协议的服务怎么接
无论是国产模型平台，还是自建的兼容服务，只要走 OpenAI 兼容 API，通常都不需要重新找一套专门的 Go SDK。大多数情况下，只需要调整：
BaseURLAPI Key
就可以沿用 openai-go 或 go-openai 的调用方式。这也是 Go 里一个很现实的选型思路：优先复用兼容协议，而不是为每个模型平台都引入一套新库。
接 MCP：把工具、数据和内部能力暴露给 AI
如果场景不是“调用模型”，而是要让 Cursor、Claude Desktop 这类客户端使用你的工具、内部 API 或数据源，那么重点就从模型 SDK 转向 MCP 服务端实现。
MCP 服务端的首选库
modelcontextprotocol/go-sdk（github.com/modelcontextprotocol/go-sdk）是更稳妥的首选。它由 MCP 组织与 Google 等合作维护，支持 MCP 的三类核心能力：
- Tools
- Resources
- Prompts
在传输层上，它支持 stdio、HTTP、SSE，并且整体实现与当前 MCP 规范保持同步。对于要长期维护的 Go 服务端项目，这点很关键，因为 MCP 还在快速演进，跟规范走通常比依赖某个轻量封装更稳。
为什么官方 go-sdk 更适合作为默认选择
做 MCP 服务端时，最终目标不是“代码最短”，而是让客户端能稳定发现、调用并理解你的能力定义。基于官方 go-sdk 实现的服务，可以更直接地被 Cursor、Claude Desktop 等客户端接入，协议对齐的风险也更低。
如果团队后续还要扩展更多工具、资源或提示模板，这种官方实现的可维护性通常会更好。
社区封装适合什么情况
如果你希望减少样板代码，或者更喜欢某一种更贴近业务的调用方式，也可以再看 MCP-Go 等社区封装。它们很多是基于或兼容官方协议做的二次抽象，适合快速试验和轻量项目。
但从默认策略上看，优先官方 go-sdk，再考虑社区封装，通常是风险更低的顺序。
本地模型与推理服务：Ollama 最省事，其他服务优先走兼容层
对不少 Go 项目来说，本地模型的价值不只是“离线可用”，还包括内网部署、数据不出域，以及更容易控制推理成本。这个场景里，Ollama 仍然是最容易落地的一条线。
调用 Ollama 的推荐方式
Ollama 本身就是用 Go 开发的，因此它仓库里的 api 包（github.com/ollama/ollama/api）就是最自然的官方客户端。它支持：
- Chat
- Generate
- Embed
配置也比较直接，通过环境变量 OLLAMA_HOST 就能指定本机或内网地址。对于 Go 开发者来说，这意味着接入路径很短：服务端只要知道模型地址和调用方式，就能把本地模型能力快速接进现有系统。
vLLM、TGI 这类推理服务怎么处理
如果你对接的不是 Ollama，而是 vLLM、TGI 等自建推理服务，情况通常反而更简单。因为这类服务多数都会提供兼容 OpenAI 的 HTTP 接口，所以你往往不需要额外寻找所谓“官方 Go SDK”。
常见做法有两种：
- 直接用标准库
net/http发请求； - 沿用 go-openai 或同类封装，改一下
BaseURL。
如果服务协议本身不是 OpenAI 风格，再根据实际情况选择 gRPC 或 HTTP 即可。换句话说，在推理服务这一层，协议兼容性往往比 SDK 品牌更重要。
RAG 与 Agent：一站式框架和自建链路各有位置
当需求从“调用一次模型”升级到“文档检索、上下文拼装、多步骤编排”时，选型重点就会落到 RAG 和 Agent 相关能力上。Go 里这部分虽然没有 Python 那么热闹，但已经有能用的主线方案。
想少写编排代码，可以先看 langchaingo
langchaingo（github.com/tmc/langchaingo）可以理解为 Go 版的 LangChain。它提供的模块比较完整，包括：
- LLM 抽象
- chains
- agents
- embeddings
- vectorstores
- documentloaders
- memory
如果你的目标是用一套库把“文档加载 → 切块 → 向量化 → 检索 → 调 LLM”串起来，它能明显减少样板代码。并且它支持接入 OpenAI、Ollama、Gemini 等多种模型，适合已经熟悉 Python LangChain 思路、又想在 Go 里复用这类工作流的人。
不想上整套框架，也可以自己串
另一条路线是轻量自建：只拿需要的组件，把链路手工串起来。这种方式尤其适合对性能、依赖体积、调用细节有明确控制需求的团队。
一个典型组合是：
- Embedding 用 openai-go 调 API；
- 向量库使用 Qdrant、Milvus、Weaviate、Pgvector 等对应的 Go 客户端；
- 编排层自己实现“切块 → 向量化 → 检索 → 拼 prompt → 调 LLM”。
这样做的好处是结构清晰、依赖更可控，也更容易按业务特征优化召回和提示词拼装逻辑。
选框架还是自建，关键看复杂度与控制权
如果你更在意快速验证、减少编排工作量，langchaingo 会更顺手；如果你更在意可控性、可观测性和链路精简，自建方式往往更贴合 Go 项目的长期维护习惯。
原文提到的 Google AI Go SDK + Weaviate RAG 示例，也可以作为自建链路时的参考思路。实际决策时，不必纠结“哪条路线更高级”，重点是看团队是否真的需要一整套抽象层。
选型速查：不同场景怎么落库更稳
| 场景 | 首选方案 | 备选 / 说明 |
|---|---|---|
| 调用 OpenAI 等 | openai-go（官方） | sashabaranov/go-openai（老项目可保留） |
| MCP 服务端 | modelcontextprotocol/go-sdk | MCP-Go 等社区封装 |
| 本地 Ollama | ollama/ollama api 包 | 第三方 ollama-client（按需） |
| 其他推理服务 | net/http + OpenAI 兼容封装 | 视服务协议选 gRPC/HTTP |
| RAG / Agent / 链式调用 | langchaingo（Go 版 LangChain） | openai-go + 向量库、Google 示例等（自建链路） |
一套更实用的落地建议
如果是新项目，可以把默认组合定得直接一些：
- 云端模型用 openai-go；
- MCP 服务端用 MCP 官方 go-sdk；
- 本地模型优先用 Ollama api；
- RAG 或 Agent 先判断是要一站式，还是要轻量自建。
如果是老项目，已经跑在 go-openai 上且足够稳定，完全可以继续保留，把迁移动作放到新能力开发或下一轮技术整理时再做。无论选哪条路线，依赖都建议定期更新，并配合安全扫描，避免 AI 相关依赖长期滞后。
结语
Go 的 AI 生态确实比 Python、Node 更分散，但主干已经比较清楚：云端模型有 openai-go，MCP 有 modelcontextprotocol/go-sdk，本地模型有 ollama/ollama 的 api 包，RAG 与链式调用可以在 langchaingo 和自建链路之间选择。只要先按场景拆问题，再按协议兼容性和维护成本选库，用 Go 做 AI 应用已经能相当顺手地落地。
