随着各种AI工具的出现，CLI工具也成为了AI应用的一种重要形式。你有没有想过，用 Go 写一个支持流式输出的 AI 命令行工具？

很多 AI 应用都支持 CLI 模式，比如 Claude Code、 CodeBuddy CLI 等，命令行工具有它的优势：启动快、资源占用少、适合开发调试。而且用 Go 写的话，编译出来就是一个单文件，分发特别方便。

这篇文章就来分享一下如何用 Go 实现一个支持流式输出的 AI 命令行工具。

你有没有遇到过这样的情况：和 AI 聊了十几轮，突然发现它"忘记"了之前说过的内容？或者 API 调用因为 Token 超限直接报错？

这是因为大模型有上下文长度限制，对话越长，历史消息越多，就越容易超限。结合我的理解，这篇文章分享一下如何实现上下文压缩，让你的 AI 应用既能"记住"关键信息，又能节省成本。

调用大模型 API 时，你有没有遇到过这些问题：某个模型突然限流、响应变慢、甚至直接挂掉？或者 不同模型价格差异大，想根据任务复杂度选择合适的模型？如果你的服务只依赖单一模型，这些问题就是单点故障。解决方案很简单：多模型 + 负载均衡。这篇就聊用 Go 实现 AI 多模型负载均衡的思路和代码。

假设你的应用只调用 OpenAI 的 GPT-4，某天 OpenAI 服务波动，你的应用就跟着「躺平」。更现实的问题是：

调用大模型 API 时，你是直接拼接字符串，还是用模板管理？如果只是简单调用，字符串拼接够用；但当 Prompt 越来越多、越来越复杂，散落在代码各处的字符串就成了维护噩梦。变量替换、多语言提示、版本化管理，这三个问题不解决，代码迟早变成「意大利面条」。这篇就聊用 Go 实现 Prompt 模板管理的实践。

假设你有一个翻译场景，最简单的写法：

做 RAG、语义检索或推荐时，要把 Embedding 向量 存起来、按相似度查，就得用向量数据库。Go 里常见的选择有三类：Pgvector（PostgreSQL 扩展）、Milvus、Qdrant。选哪个取决于你是否已有 Postgres、数据量和运维成本。这篇就聊这三者在 Go 里的客户端选型和接入要点。

• Pgvector：是 PostgreSQL 的一个扩展，向量当一列存。适合本来就用 Postgres 的团队，不想多维护一个组件，数据量在百万级以内、QPS 不是特别夸张时很够用。Go 里用 pgx + pgvector-go 即可。
• Milvus：独立向量库，支持大规模、分布式，适合向量数据量很大或要单独扩缩容的场景。官方有 milvus-sdk-go，接口偏「集合 + 列式插入 + 建索引再搜」。
• Qdrant：也是独立向量库，API 设计偏 REST/gRPC，过滤条件（payload filter）和多向量支持比较顺手。Go 用 github.com/qdrant/go-client，文档和示例都比较全。

想让大模型回答你公司内部文档的问题？直接喂文档太占 Token，而且模型会「忘记」长内容。RAG（检索增强生成） 的做法是：把文档切块、转成向量存起来，用户提问时先检索相关片段，再把片段和问题一起发给模型，让它基于这些上下文回答。实现一套 RAG 服务，核心就三步：文档切块、向量化、检索。

大模型有两个局限：上下文长度有限（不能塞太多文档）、知识有时效性（训练数据可能过时）。RAG 的做法是：

用 Go 做语义检索、推荐或 RAG 时，总要算向量相似度。做法大致三种：自己写几行、用数值库、或者交给向量数据库。下面按「方案」捋一捋，方便你按场景选。

向量相似度用在语义检索、推荐、去重聚类等场景很常见，但数据量差别很大：有时就几百几千个向量在内存里算，有时是百万级要做近似最近邻（ANN）检索。所以没有一种写法能通吃，有的场景适合手写，有的适合用库，有的直接上向量库。下面分别说。

大模型支持「工具调用」后，对话里可以查天气、查库、调 API；模型会返回该调用哪个函数、传什么参数。服务端要做的，就是解析模型返回的 tool_calls、执行对应逻辑、把结果塞回对话。用 Go 实现，结构清晰、易维护。下面说清楚解析、执行与一整轮怎么串起来。

Function Calling（Tool Use）指：你把可调用的函数列表以 JSON Schema 等形式传给大模型，模型在需要时会在回复里带 tool_calls，指明函数名和参数。服务端解析后执行真实逻辑，把结果再发给模型，由模型生成最终回答。

最近在折腾 Cursor、Claude 等 AI 编程工具的朋友，多半见过两个词：Skill 和 MCP。一个负责「教 AI 怎么做事」，一个负责「让 AI 能调用外部能力」。于是有人问：既然 Skill 越来越强，会不会有一天完全取代 MCP？

目前来看：不会。 二者解决的是不同层面的问题，更像是「左手和右手」的关系，而不是谁替代谁。

用 Go 写后端、CLI 或运维工具时，要把大模型能力接进去，第一个问题往往是：Go 里该用哪个 SDK？生态够不够用？ 和 Python/Node 相比，Go 的 AI 生态更「散」，但近几年已有不少可用方案。本文按云端大模型、MCP、本地模型、RAG 四类场景盘点主流库，并给出选型建议。

场景：调用 OpenAI、国产大模型或兼容 OpenAI 协议的 API。

首选：openai-go（github.com/openai/openai-go），OpenAI 官方维护的 Go 库，覆盖 Chat 补全、流式输出、Function Calling、Embeddings、语音与图像等能力，与官方 REST API 保持一致，后续迭代有保障。

当 AI 应用需要查数据库、调 API、读文件时，总不能把整套系统都塞进提示词里。Model Context Protocol（MCP） 就是为解决这个问题而生：它让大模型通过统一协议安全、可控地连接外部数据源和工具。如果你在用 Go 做后端或 CLI，用 Go 写 MCP 服务再合适不过——编译成单二进制、并发友好、部署简单。这篇文章就聊聊 Go 里如何快速实现一个 MCP 服务，以及目前主流的 Go MCP 框架 该怎么选。

MCP（Model Context Protocol）是一套开放标准，用来在 AI 应用和外部系统之间建立安全、可控的连接。大模型通过 MCP 可以：

• 调用工具（Tools）：执行计算、查库、发请求等
• 访问资源（Resources）：读文件、读 API 数据等
• 使用提示模板（Prompts）：复用结构化提示

你是否曾希望有一个能真正理解你指令的数字助手？你不再需要一步步指导它做什么，只需告诉它“帮我策划一个三亚五日游行程，并预订机票和酒店”，它就能自动完成搜索、比较、预订的全过程。这就是AI Agent（智能体）带来的未来。

简单来说，如果把ChatGPT这样的大模型比作“超级大脑”，那么AI Agent就是给这个大脑装上了“手脚”和“工具”，让它能够主动行动，而不仅仅是被动回答问题。

与传统AI系统不同，AI Agent具备自主决策能力。你只需要给定一个目标，它就能够独立思考并规划如何达成这个目标，调用各种工具完成任务。

在当今AI技术飞速发展的时代，作为Go开发者，我们正站在一个重要的转折点。AI不再只是Python社区的专属领域，Go语言凭借其高性能、并发处理和简洁的语法，正在AI应用开发中崭露头角。这篇文章将带你全面了解Go开发者必须掌握的AI技术和概念。

Go语言凭借其出色的并发性能、高效的内存管理和简洁的语法，在构建AI应用基础设施方面具有天然优势。与AI工作负载通常需要大量的网络请求和并发处理的特点完美契合。

在实际应用中，Go语言特别适合构建高性能AI服务后端、数据处理管道、模型部署和服务化等场景。无论是通过API集成大模型，还是构建完整的RAG系统，Go都能提供稳定高效的基础支撑。

在当今数字化时代，实时通信已成为各类应用的标配能力。无论是即时聊天、在线协作，还是火爆全球的AI应用，都离不开高效可靠的实时通信技术。本文将深入解析两种主流的实时通信方案：SSE和WebSocket，并重点探讨SSE在AI领域的重要应用。

实时通信技术是现代Web应用的基石。从最早的HTTP轮询到长轮询，再到如今的SSE和WebSocket，技术的发展始终围绕着更低延迟、更高效率的目标前进。

传统的HTTP请求-响应模式虽然简单易用，但在实时性要求较高的场景下显得力不从心。服务器必须等待客户端请求才能返回数据，这种被动模式无法满足即时通讯、实时数据监控等场景的需求。

苟日新，日日新，又日新。

生活从不眷顾因循守旧、满足现状者，从不等待不思进取、坐享其成者，而是将更多的机遇留给善于和勇于创新的人们。

在人工智能飞速发展的今天，无论是 AI 相关的技术，还是 AI 相关的产品，都是层出不穷、日新月异。