https://guangmingluo.github.io/tags/go/Recent content in Go on Guangming BlogHugozh-cnFri, 08 May 2026 17:00:00 +0800https://guangmingluo.github.io/post/eino-ai-framework-deep-dive/Fri, 08 May 2026 17:00:00 +0800https://guangmingluo.github.io/post/eino-ai-framework-deep-dive/Go 开发者做 AI 应用，痛在哪？ 过去两年，AI 应用开发几乎成了 Python 的专属领地。LangChain、LlamaIndex、AutoGen……这些耳熟能详的框架，无一不是 Python 原生。作为一个写了多年 Go 的开发者，我经常面对一种尴尬：明明后端服务是 Go 写的，明明线上跑的是微服务架构，一旦要接入 LLM 能力，就不得不引入 Python 中间层，或者手搓一堆 HTTP 调用。 这种"语言割裂"带来的问题远不止于多写几行胶水代码。更深层的是：你失去了 Go 最引以为傲的东西——编译期类型检查帮你挡住的一大类错误，goroutine 带来的优雅并发模型，还有单一二进制部署的简洁运维体验。而在 AI 应用场景下，这些恰恰又是最需要的：LLM 的 I/O 延迟高、流式输出复杂、工具调用的参数校验容易出错、Agent 状态管理需要并发安全…… 所以当 CloudWeGo 团队推出 Eino 这个 Go 语言 AI 应用开发框架时，我的第一反应是：终于有人认真对待这件事了。 Eino 是什么：不止是 “Go 版 LangChain” Eino（发音 [‘aino]，接近 “I know”）是 CloudWeGo 开源的 Go 语言 LLM 应用开发框架。很多人第一眼会把它理解为"Go 版 LangChain"，这个类比不算错——Eino 确实从 LangChain、LlamaIndex 等框架汲取了灵感——但它又不只是简单地把 LangChain 的概念用 Go 重写一遍。 Eino 的设计哲学更接近于：用 Go 的方式，解决 AI 应用开发的工程化问题。什么意思呢？LangChain 生于 Python，天然带着 Python 的思维——动态类型、鸭子类型、隐式的链式调用。这些在原型阶段很爽，但在生产环境中，尤其是 Go 开发者习惯的强类型、显式错误处理、编译期保证的语境下，就显得格格不入。https://guangmingluo.github.io/post/kitex-2026-evolution/Fri, 08 May 2026 14:30:00 +0800https://guangmingluo.github.io/post/kitex-2026-evolution/2026 年的 Go RPC 框架格局正在经历一轮静默但深刻的变化。gRPC 依然是跨语言通信的事实标准，但在纯 Go 微服务场景下，开发者对性能和治理深度的需求远超 gRPC 标准库所能提供的上限。Kitex 在过去几个月连续推出 v0.16.0、v0.16.1、v0.16.2 三个版本，更新频率之快、改动之深，让我这个社区贡献者都觉得有些意外——这不是常规的 Bug 修补版本节奏，而是一次围绕流式 RPC 成熟度和运行时内存效率的系统性攻坚。 本文不是 Release Notes 的翻译，而是我想从一个长期跟踪 Kitex 演进的开发者视角，聊聊这三个版本背后的技术脉络和设计取舍。 版本演进总览：一条清晰的主线 先看时间线： 版本 发布日期 核心主题 v0.16.0 2026-04-05 流式 RPC 可观测性与安全性 v0.16.1 2026-04-05 gRPC 写缓冲复用 & ttstream 背压 v0.16.2 2026-05-08 进程内调用、gRPC 内存池化、服务发现优化 v0.16.0 和 v0.16.1 同一天发布，但解决的问题截然不同。前者聚焦流式 RPC 的"正确性与可观测性"，后者解决的是流式场景下的"内存安全与资源效率"。v0.16.2 则把优化范围从流式扩展到整个运行时——从服务发现的对象分配到 gRPC 的 framer buffer 池化，再到一个全新的进程内调用机制。 贯穿这三个版本的核心线索是：Kitex 正在从"功能可用"走向"生产级可靠"。这话听起来像是废话，但如果你关注过流式 RPC 在生产环境踩过的坑（LLM 流式响应 OOM、跨流状态泄漏、连接池泄漏），就会理解这背后的工程量。 核心特性深度解读 一、流式 RPC 的"三连击"：超时、可观测、状态安全（v0.16.0） v0.16.0 的三个流式特性拆开看都是修复性质，合在一起却是一次完整的问题闭环。 1. Recv Timeout：流式调用终于有了精确的"时间窗口" 在 v0.