Git - Tony Bai

标签 Git 下的文章

霸榜 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 Proxy的“背景刷新”机制，是优化还是“DDoS”？一次社区事件引发的深度复盘

九月 5, 2025
0 条评论

本文永久链接 – https://tonybai.com/2025/09/05/go-proxy-revise-background-refresh-pacing

大家好，我是Tony Bai。

2025年8月14日，Go开发者Ted Unangst发表了一篇措辞犀利的博文——《What is the go proxy even doing?》。他用服务器日志作为证据，公开质疑Go官方模块代理（proxy.golang.org）对其个人代码托管服务humungus.tedunangst.com产生了“洪水般”的、看似毫无意义的巨大流量。这个事件迅速在社区发酵，将一个通常在后台默默工作的核心基础设施，推上了风口浪尖。当然在我的印象中，这已经不是Go社区第一次“抱怨” 官方Go proxy的“诡异”行为给一些小型站点带来的烦恼了。

不过不同的是，这次Go团队的前技术leader、核心成员Russ Cox (rsc) 迅速响应，在Go的官方issue追踪系统中创建了两个关键问题（#75120 和 #75191），不仅承诺调查并解决问题，更罕见地、极其详尽地公开了Go Module Proxy的内部工作原理、缓存策略以及导致此次事件的深层原因。

这场由一篇博文引发的“悬案”及其官方复盘，为我们提供了一个绝佳的机会，去深入理解Go Module Proxy这个我们每天都在使用，却又知之甚少的系统。它背后的“背景刷新”机制，究竟是为了提升开发者体验的“优化”，还是在某些边缘情况下会演变成对小型开源社区的“DDoS”？

事件回顾：来自小型服务器的“呐喊”

Ted Unangst的博文主要控诉了以下几个现象：

持续的背景流量：即使没有任何新版本发布，proxy.golang.org也会以几分钟一次的频率，持续尝试从他的服务器hg clone（克隆）多个仓库。由于他的服务器设置了24小时内只允许一次克隆的速率限制，这些请求大多被429 Too Many Requests拒绝，但在日志中形成了持续的“背景辐射”。
“惊群效应”（Thundering Herd）：当他推送一个新版本（一个新tag）并本地执行go mod tidy后，短短14秒内，他的服务器就遭到了来自Google不同IP地址的、数十个并发的hg clone请求。他将其形容为“洪水来了”。
低效的拉取策略：Proxy每次都执行完整的hg clone，而不是更高效的hg pull，这对于非Git的VCS（版本控制系统）来说，意味着巨大的带宽浪费。

Unangst的质疑直击要害：“为什么你们要这样构建一个分布式系统？……难道Google认为从我的服务器下载比从他们自己的云存储下载更便宜吗？”

Go官方的深度复盘：揭开代理的神秘面纱

Russ Cox的官方回应堪称透明沟通的典范。他不仅承认了问题的存在，还详细解释了Proxy的设计理念和实现细节，让我们得以一窥其内部运作。

Go Module Proxy的核心目标

可用性与可靠性：作为Go生态的中央缓存，确保开发者在任何上游代码仓库宕机时，依然能获取到模块。
降低延迟：通过主动的背景刷新，提前将热门或近期被访问过的模块信息更新到缓存中，使得开发者在执行go get等命令时，能立即获得响应，而不是等待Proxy实时回源。

缓存与刷新策略的权衡

Proxy缓存多种类型的数据，每种都有不同的刷新策略，而这些策略正是问题的根源：

模块Zip包：
- 有许可证：被认为是可再分发的，永久缓存，从不刷新。
- 无许可证：被视为不可再分发，缓存30天后过期。为了避免用户请求时缓存失效导致的高延迟，Proxy会在其25天“高龄”时触发刷新，但前提是过去1天内有人请求过这个版本。
版本列表 (go list -m -versions …)：
- 缓存3小时后过期。为了让go get -u能尽快看到新版本，Proxy会在其25分钟“高龄”时触发刷新，但前提是过去3天内有人请求过这个列表。
版本查询 (go get module@main)：
- 缓存1小时后过期。同样，在25分钟时触发刷新，前提是过去1天内有人请求过。

“万恶之源”：不匹配的刷新与访问周期

在issue #75191中，rsc进行了一次深刻的自我反思，指出了这些策略中的一个致命缺陷——读放大（Read Amplification）。

模块Zip包（无许可证）：刷新周期（25天）与“近期访问”周期（1天）不匹配，但因为时间跨度大，影响不大。
版本列表：刷新周期是25分钟，但触发条件是过去3天内有一次访问即可。这意味着，一个开发者在周一的一次go get -u，将导致Proxy在接下来的72小时内，每25分钟就去上游仓库检查一次更新！
- 最坏情况下的读取放大：3天 * 24小时/天 * 60分钟/小时 / 25分钟/次 ≈ 172.8次。一次用户请求，可能导致Proxy向上游发起172.8次刷新！
版本查询：类似地，一次go get …@main请求，可能导致24 * 60 / 25 ≈ 57.6次刷新。

rsc坦诚，这种激进的刷新策略源于早期社区对“go get无法立即看到新版本”的普遍抱怨，是当时Go团队为了优化开发者体验而做出的决策。然而，对于那些不常用（比如几天才被访问一次）且托管在非Git（如Mercurial）小型服务器上的模块，这种策略就演变成了一场流量灾难。

解决方案：重新“步调一致”

Go团队提出的解决方案，是让刷新周期与“近期访问”的定义“步调一致”（Pacing）。新的策略是：

版本查询：每25分钟刷新一次，但前提是过去25分钟内必须有用户请求。
版本列表：每25分钟刷新一次，但前提是过去25分钟内必须有用户请求。

这个看似微小的改动，却有着深远的影响：

对于热门模块：几乎没有影响，因为它们每时每刻都有用户在请求。
对于无人问津的模块：没有影响，它们不会被刷新。
对于偶尔被访问的模块：影响巨大。现在，一次用户请求最多只会触发未来25分钟内的一次背景刷新。最坏情况下的读取放大被降至最优的1倍。

这意味着，Go Module Proxy因为背景刷新而产生的上游流量，将永远不会超过一个没有缓存、所有请求都实时回源的代理所产生的流量。

对Go开发者和开源维护者的启示

这场事件不仅仅是Go团队的一次内部优化，它为整个生态的参与者都带来了宝贵的经验：

1. 开源模块维护者：如何保护你的服务器？

使用Git：Go Proxy对Git有特殊的轻量级刷新优化。它可以通过git ls-remote来检查更新，而无需克隆整个仓库。对于Mercurial、Bazaar等VCS，目前仍需要完整克隆。 issue #75119 正在追踪为Mercurial添加类似优化的工作。
添加LICENSE文件：如果你的代码允许再分发，务必在仓库根目录添加一个被Go识别的LICENSE文件。这将让你的模块版本被Proxy永久缓存，彻底免除Zip包的刷新流量。
了解求助渠道：Go团队在issue中明确表示，如果你的服务器遭受了来自Proxy的过多流量，应该去Go的官方issue追踪系统报告。他们已经添加了FAQ条目来引导用户。

2. Go模块使用者：如何做一个“好公民”？

理解你命令的“涟漪效应”：下一次你输入go get -u或go get module@main时，请意识到这个简单的命令可能会给模块的源服务器带来持续一段时间的刷新压力。
工具开发者请注意：如果你正在编写扫描或爬取Go模块的工具，请尽可能使用https://proxy.golang.org/cached-only端点。这将只访问Proxy的缓存，不会触发任何到上游服务器的回源或刷新请求。

3. 对Go团队的思考：简单性与复杂性的永恒权衡

这个事件也揭示了Go语言哲学的一个侧面。Go团队为了追求用户体验的“简单”（即时获取最新版本），在Proxy的内部引入了“复杂”的、带有潜在风险的刷新逻辑。当这种复杂性与现实世界的多样性（不同的VCS、不同的模块流行度）碰撞时，问题便暴露出来。

最终的解决方案，回归到了一个更“简单”、更可预测的模型。这再次印证了软件工程的一条黄金法则：简单的、可预测的系统，长期来看往往比一个充满“智能”优化的复杂系统更加健壮。

小结：一次迈向成熟的进化

Go Module Proxy的这次“流量悬案”，最终以一次开放、透明的社区互动和深刻的技术改进而告终。它既解决了小型服务器维护者的燃眉之急，又推动了Go核心基础设施向着一个更公平、更健壮、更尊重生态多样性的方向进化。对于我们开发者而言，这是一个了解Go Proxy内部机制的宝贵机会，也是一堂关于分布式系统设计、社区责任和技术权衡的生动课程。