github - Tony Bai

标签 github 下的文章

霸榜 GitHub 一周！Google 开源 ADK for Go，彻底终结 AI“炼丹”时代？

十一月 24, 2025
0 条评论

本文永久链接 – https://tonybai.com/2025/11/24/google-adk-go-in-action

大家好，我是Tony Bai。

上周，我花了一个下午，仅仅是为了让一个Python写的Agent能稳定地调用我Go服务里的一个简单函数。在那一刻，看着屏幕上纠缠的gRPC、Python虚拟环境和混乱的日志，我脑海里只有一个念头：这不对劲，这绝对不是软件工程该有的样子！

显然，不仅仅是我一个人在为此焦虑。

就在最近，一个名为 google/adk-go 的项目悄然开源，并迅速霸榜 GitHub Go 语言趋势榜长达一周之久！ 全球的 Gopher 似乎都在用脚投票，表达着同一个渴望：我们受够了“炼丹”，我们要回归工程！

过去的一年，AI 的浪潮席卷了整个技术圈。我们 Gopher，作为构建云原生世界的中坚力量，看着 Python 社区在 AI 领域“杀”得热火朝天，心中或许都有一个共同的疑问：

“这场 AI 的盛宴，我们 Gopher 的主菜在哪儿？”

我们习惯了用 goroutine 优雅地处理并发，用 channel 安全地传递消息，用静态编译的单个二进制文件征服任何服务器。我们是天生的“工程师”，我们信奉的是可测试、可维护、可部署的软件工程哲学。

然而，当我们尝试踏入 AI Agent 的世界时，却常常感觉自己像一个闯入了“炼丹房”的“机械师”。面对那些需要反复“吟唱咒语”（调 Prompt）、结果飘忽不定的“丹炉”（模型），我们不禁会问：

我的 Agent 行为不稳定，怎么写单元测试？
Prompt 稍微一改，整个“丹方”都可能失效，版本管理怎么做？
我如何将这个“充满魔法”的 Python 脚本，与我现有的 Go 微服务体系优雅地集成，而不是变成一坨无法维护的“耦合怪”？

这些问题，不是因为我们不懂 AI，而是因为我们太懂工程。我们厌倦了“炼丹”式的不确定性，我们渴望一种能将 AI 的强大能力，用严谨的工程纪律约束起来的解决方案。

现在，Google 亲自下场，为我们递来了“工程图纸”。

Google ADK for Go：写给工程师的 AI Agent 开发框架

这个霸榜的项目，全称是 Agent Development Kit (ADK) for Go。

这不是又一个“玩具”或“研究性”框架。从它的设计理念中，我看到了一个清晰而坚定的信号——AI Agent 开发，正在从“炼丹”式的“艺术创作”，全面进入“工程化”的“工业生产”时代。

而 ADK for Go 的核心哲学，与我们 Gopher 的信仰不谋而合，那就是——代码优先 (Code-First)。

你的 Agent，就是你的 Go 代码： 不再有晦涩的 YAML，不再有天书般的“链”，Agent 的所有逻辑、决策、工作流，都由你亲手编写的、地地道道的 Go 代码来定义。
天生的可测试性： 你的 Agent 就是一个实现了 agent.Agent 接口的 struct。这意味着什么？你可以像测试任何 Go 代码一样，go test 走起！Mock 依赖、断言行为，所有你熟悉的工程实践，全部回归。
Git 即版本管理： Agent 的每一次进化，都是一次清晰的 git commit。Code Review、版本回滚，一切都尽在掌握。
云原生无缝集成： 它就是一个标准的 Go 模块，可以被无缝地集成到你的 Gin/gRPC 服务中，打包成一个极小的 Docker 镜像，部署到任何 K8s 集群。

这就是为什么它能霸榜 GitHub 的原因——它不是在教你如何更好地“调优 Prompt”，而是在教你如何用坚实的工程代码，去彻底终结那个不可控的“炼丹”时代。

Google的adk-go，就是那座连接 Gopher 工程世界与 AI Agent 智能世界的桥梁。

和我一起，从零开始“造”一个真正的 AI Agent

坦白说，ADK for Go 刚刚推出，市面上的教程几乎一片空白。文档虽有，但如何将其与真实的工程场景结合，如何理解其设计背后的权衡，如何避开那些必将遇到的“坑”——这些都需要有人去探索，去趟路。

所以，我决定做这件事。

我将以一个“学伴”和“探索者”的身份，推出我的全新付费微专栏：

《Google ADK 实战：用 Go 构建可靠的AI Agent》

在这个专栏里，我不会扮演一个无所不知的专家。相反，我会将我从零开始学习、实践、踩坑、顿悟的全过程，毫无保留地分享给你。

我们将一起，手把手地、从一个空 main.go 文件开始，完成一次令人兴奋的创造之旅：

第 1-2 讲：思维转变与灵魂注入
我们将彻底理解“代码优先”的哲学，拆解adk-go，了解其中的概念、架构和核心组件，并亲手定义出第一个实现了 agent.Agent 核心接口的智能体。
第 3 讲：为 Agent 插上“手臂”： 让你的Agent能调用任何Go函数，像操作自己的手脚一样自如
我们将学会 ADK 的“魔法”函数 functiontool.New，将一个普通的 Go 函数，零成本地转化为 Agent 可用的工具。
第 4 讲：赋予 Agent “双核记忆”
我们将深入 session（短期记忆）和 memory（长期记忆），让我们的 Agent 能够理解上下文，并记起与你的历史交互。
第 5 讲：从“单兵”到“军团”： 构建一个懂分工、会协作的Agent团队，自动化完成复杂任务
我们将学习 workflowagents，通过编排多个专家 Agent，构建一个强大的“代码生成-审查-重构”自动化流水线。
第 6 讲：从“原型”到“产品”
我们将为 Agent 建立科学的评估体系，并最终将其打包成 Docker 镜像，部署到通用的 Kubernetes 环境中。

学完这个专栏，你将收获的，不仅是一个能跑起来的酷炫 AI 项目，更是一套可复用的、工程化的 AI Agent 构建方法论，以及在 AI 新浪潮中，属于我们 Gopher 的那份自信和底气。

加入这场 Gopher 的 AI 工程化之旅

这个微专栏，是我为你，也为我自己准备的一份“AI 时代 Gopher 生存指南”。它凝聚了我对 Go 工程哲学的理解，和我对 AI Agent 未来的全部热情。

微专栏共 6 篇深度长文，每一篇都是我亲手实践、细节满满的 step-by-step “航海日志”。

我没有设定一个高昂的价格，而是希望与更多志同道合的 Gopher 一起探索。所以，订阅这份专栏，仅需你一杯咖啡的诚意。

花一杯咖啡的时间，你或许能得到片刻的清醒；而用同样的价格投入到这里，我希望能为你带来一次思维的升级和技能的跃迁。

点击这里，或扫描二维码，立即加入。

让我们一起，用代码，构建智能。

P.S. 如果你对 AI Agent、Go 语言或者这个微专栏有任何问题，欢迎在评论区留言，我们一起交流探讨！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

告别低效，重塑开发范式
驾驭AI Agent(Claude Code)，实现工作流自动化
从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

Go 标准库将迎来 Zstandard：性能超越 Gzip，让你的应用更快、更省

十一月 8, 2025
2 条评论

本文永久链接 – https://tonybai.com/2025/11/08/proposal-zstd

大家好，我是Tony Bai。

在 Go 的世界里，一项被社区翘首以盼的提案在沉寂一年后，终于迎来了决定性的进展。2024 年，将 Zstandard 压缩算法纳入标准库的提案（#62513）被正式 Accept，但在那之后便鲜有动静。直到最近的 Go 编译器与运行时会议纪要中透露，这项工作将由社区的明星开发者 Klaus Post 主导推进。

这意味着，在未来的 Go 版本中，开发者将能开箱即用地获得一个官方维护、安全可靠且性能卓越的压缩工具。这不仅是对 Go 生态的一次重要补强，更将直接为无数 Go 应用带来性能提升、带宽节约和成本削减，真正实现“更快、更省”的承诺。

同时，这个提案背后曲折的历程——从激烈的技术选型辩论，到精雕细琢的 API 设计，再到因核心团队资源紧张而搁置，最终由社区力量重新激活——本身就是一幅展现 Go 生态演进的生动图景。

在本文中，我们将探讨 Zstandard 脱颖而出的技术优势，剖析其在工业界的成功案例，并揭示 compress/zstd 标准库从提案、API 设计到最终由社区力量重启的完整历程。

Zstandard：为何是它，而非其他？

在决定为标准库引入新的压缩算法时，Go 团队面临着众多选择。提案发起者 dsnet 在讨论中进行了一次精彩的“选美”，清晰地阐述了为何 Zstandard (Zstd) 能够脱颖而出：

Zstandard (Zstd): 由 Facebook (现 Meta) 开发并开源，拥有极佳的压缩/解压速度和出色的压缩比。更重要的是，它有正式的 RFC 规范（RFC 8878），这对于标准库实现的“正确性”至关重要。
Brotli: 同样优秀，但在设计上更偏向 Web 静态内容，且其庞大的静态字典（约 120KiB）与 Go 追求小体积静态二进制文件的哲学相悖。
XZ (LZMA): 拥有极高的压缩比，但代价是极其缓慢的压缩和解压速度，不适合通用场景。且缺乏正式的、明确的规范。
Snappy / LZ4: 追求极致的速度，但在压缩比上做出了巨大牺牲，应用场景相对小众。

Zstd 巧妙地结合了 LZ77 算法和一种名为 ANS (Asymmetric Numeral Systems) 的现代熵编码技术，在性能、压缩比和资源消耗之间取得了近乎完美的平衡，使其成为替代 Gzip 的“天选之子”。

注：截至Go 1.25.3版本，Go compress目录下提供了多种压缩算法的实现：bzip2实现了Burrows-Wheeler变换及霍夫曼编码；flate提供了DEFLATE算法核心，结合了LZ77和霍夫曼编码；gzip和zlib则分别将DEFLATE算法封装为gzip文件格式和zlib数据流格式；lzw实现了Lempel-Ziv-Welch算法。这些包共同为Go语言提供了多样化的数据压缩与解压缩能力。

注：Zstandard最新RFC规范为RFC 9659。

工业界验证：Discord 与 Cloudflare 的性能飞跃

理论上的优势必须经过实践的检验。Zstd 在工业界的应用早已硕果累累。

**Discord 的 40% 带宽削减：** 通讯巨头 Discord 在将其实时网关的压缩算法从 zlib (Gzip) 迁移到流式 Zstandard 后，获得了惊人的收益。对于核心的 MESSAGE_CREATE 事件，压缩时间缩短了一半以上，负载体积也显著减小。这直接转化为更低的服务端 CPU 占用和客户端带宽节省，最终实现了 整体 Websocket 流量降低 40% 的壮举。
**Cloudflare 的容器镜像加速：** 在其全球容器平台上，Cloudflare 需要快速分发巨大的 AI 模型镜像（常超过 15GB）。通过将镜像层压缩算法从 Gzip 更换为 Zstd，一个 30GB 镜像的拉取时间从 8 分钟骤降至 4 分钟，速度翻倍，极大地提升了全球调度的灵活性和响应速度。

这些案例雄辩地证明，Zstd 是为现代高吞吐量、低延迟应用而生的。

API 设计的艺术：一场关于简洁、安全与未来的辩论

将新包引入标准库，API 的设计是重中之重。#62513 的讨论串完整记录了 compress/zstd API 从雏形到最终形态的演进过程。

核心原则：安全与一致性

提案伊始，就确立了两大基石：

安全优先： 标准库实现必须是纯 Go版本，不使用 unsafe 或汇编。dsnet 强调：“Go 社区调查一致显示，安全性比性能更重要。” 这意味着标准库版本追求的是可审查性、可维护性和跨平台的一致性，而非极致的性能。
API 一致性： 新 API 应与 compress/gzip、compress/flate 等现有包保持风格统一，降低开发者的学习和迁移成本。

社区的声音：Klaus Post 的关键输入

在讨论中，github.com/klauspost/compress 系列库的作者 Klaus Post 扮演了关键角色。他的库是 Go 社区公认的最高性能压缩实现，其丰富的实战经验为标准库的设计提供了宝贵视角。

Klaus 指出，他自己的库 API 相对复杂，是因为支持多线程、异步等高级特性。他赞同标准库应剥离这些复杂性，提供一个完全同步的、线程安全的 API。同时，他也对字典（Dictionary）功能的 API 设计提出了深刻见解，强调了字典预处理的开销问题，这直接影响了后续 API 的设计。

最终定稿的 API

经过多轮讨论，由 Russ Cox (rsc) 总结并最终被接受的 API 形态如下(并非最终版)：

package zstd

const (
    NoCompression      = 0
    BestSpeed          = 1
    BestCompression    = 9
    DefaultCompression = -1
)

type Dict struct { /* ... */ }
func ParseDict(enc []byte) (*Dict, error)
// ... 可能还包含 Marshal/Unmarshal 方法

type Reader struct { /* ... unexported fields ... */ }
func NewReader(r io.Reader) (*Reader, error)
func (z *Reader) Reset(r io.Reader) error
func (z *Reader) AddDict(*Dict)
func (z *Reader) SetRawDict([]byte)
func (z *Reader) Read(p []byte) (int, error)
func (z *Reader) Close() error

type Writer struct { /* ... unexported fields ... */ }
func NewWriter(w io.Writer) *Writer
func (z *Writer) Reset(w io.Writer)
func (z *Writer) SetLevel(int) error
func (z *Writer) AddDict(*Dict)
func (z *Writer) SetRawDict([]byte)
func (z *Writer) Write([]byte) (int, error)
func (z *Writer) Flush() error
func (z *Writer) Close() error

这个设计体现了 Go 标准库的哲学：

Setter 模式： 采用 SetLevel、AddDict 等方法进行配置，而不是更复杂的构造函数重载或函数式选项，兼顾了灵活性和简洁性。
独立的 Dict 类型： 将字典抽象为 Dict 类型，通过 ParseDict 进行预处理。这解决了 Klaus 提出的“重复解析字典开销大”的问题，允许用户一次解析，多次复用。
错误处理： 关键配置（如 SetLevel、ParseDict）返回 error，增强了 API 的健壮性。

漫长的等待与社区英雄的登场

提案于 2024 年被接受，为何直到 2025 年底才真正启动？这背后反映了 Go 核心团队面临的现实挑战。Go 团队规模精简，核心成员的精力需要分配给语言、编译器、运行时等更高优先级的任务。提案发起者 dsnet 也深度参与了 json/v2 等重大项目，无暇分身。

在此期间，Klaus Post 主动请缨，表示愿意贡献一个精简版的、符合标准库要求的实现。然而，这个提议在当时并未得到明确的推进信号。

转机出现在 2025 年 11 月的 Go 团队内部会议。纪要显示，团队终于有带宽来审查社区对 compress/flate 和 compress/zstd 的贡献。会议明确提到：“很高兴有社区审查。我们能去问问 k8s 的人吗？”（意指寻求更多社区的反馈和测试）。这标志着官方正式为 Klaus Post 的贡献打开了大门。随后Klaus Post也给出了自己的贡献时间表，大约在2026年Q1提交第一版实现给Go团队审查。