软件工程 - Tony Bai

标签软件工程下的文章

霸榜 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 创始人的忠告：这五条关于“复杂性”的法则，比算法更重要

十一月 10, 2025
0 条评论

本文永久链接 – https://tonybai.com/2025/11/10/rob-pike-on-complexity

大家好，我是Tony Bai。

在软件工程的殿堂里，我们常常将算法和数据结构奉为圭臬。我们痴迷于时间复杂度的优化，热衷于讨论各种精巧的数据结构。然而，Go 语言的联合创始人 Rob Pike 早在其1989年的一篇C 语言编程笔记中，就为我们留下了一份更根本的“忠告”。这份忠告，凝练为五条（或者说六条？）关于如何对抗软件“复杂性”的黄金法则。

这些法则，诞生于一个需要手动管理内存的时代，却惊人地预言并塑造了 Go 语言的设计哲学。它们的核心思想是：在构建真实世界的软件时，管理复杂性，远比追求算法上的极致精巧更为重要。

本文，就让我们以一名现代 Gopher 的视角，重新聆听这份来自创始人的忠告，理解为何这五条法则，才是构建健壮、可维护软件的真正基石。

法则一 & 二：停止猜测，开始测量

法则一：你无法预知程序的时间花销。

法则二：测量。在测量之前，不要进行性能调优。

这两条法则是所有性能工作的“第一性原理”。它们共同指向一个核心思想：你的直觉是不可靠的。

我们很容易陷入一个误区，认为性能瓶颈一定出在某个“看起来很慢”的算法上。然而，在现代计算机体系中，真正的瓶颈往往隐藏在意想不到的地方：一次意料之外的内存分配、一次糟糕的并发同步、或者一次灾难性的缓存未命中。

一个在“冷路径”上运行的、从 O(N) 优化到 O(1) 的完美算法，其对整体性能的贡献是零。而一个未经测量的、看似无害的“优化”，则可能因为破坏了缓存局部性或引入了锁竞争，反而让程序变得更慢。先找到正确的战场，远比拥有最锋利的武器更重要。

Go 语言将这两条法则的精神，内化为了其强大的工具链。在你动手将一个 O(N) 的循环优化成 O(log N) 之前，Go 的文化要求你：

使用 pprof 进行宏观分析：让数据告诉你，你的程序 90% 的时间到底花在了哪里。这份“忠告”要求我们，只对那个压倒性 (overwhelms) 的瓶颈进行优化。
使用 testing.B 进行微观验证：当你找到了瓶颈，并进行了一处“速度骇客” 般的优化后，用基准测试来证明你的修改确实带来了显著的提升。

法则三 & 四：简单胜于花哨

法则三：花哨的算法在 n 很小时很慢，而 n 通常很小。

法则四：花哨的算法比简单的算法更容易出错，也更难实现。

这两条法则是对“算法至上主义”的直接挑战。经典的算法复杂度（大O表示法）是一个强大的理论工具，但它在工程实践中具有欺骗性，因为它忽略了常数因子和实现的复杂性。

一个 O(log n) 的自平衡二叉树，其实现的复杂性、指针跳转带来的缓存不友好性，使得它在处理一个只有几百个元素的“日常问题”时，性能和健壮性可能远不如一个简单的、O(n) 的切片扫描。

在真实世界的软件中，可读性、可维护性和健壮性，是远比“理论上的最优性能”更为稀缺的资源。一个因过于复杂而充满 Bug 的“花哨”算法，其带来的危害，远大于一个简单、正确但“不够快”的算法。先做对，再做快——并且只有在测量证明有必要时才去做快。

Rob Pike的这两条法则简直就是 Go 语言的设计宣言！

切片 (slice) 和 map 就是一切：Go 刻意保持其内置数据结构的极度精简，正是因为在 99% 的场景下，它们简单、可预测且“足够好”。
“清晰胜于聪明 (Clear is better than clever)”：这是 Go 社区的集体共识。一段任何人都能在 3 秒钟内读懂的简单 for 循环，其长期维护价值，远高于一段只有作者本人才能看懂的、精巧但晦涩的代码。

法则五：数据为王

法则五：数据为王。如果你选对了数据结构并组织得当，算法几乎总是不言自明的。

这是所有法则中最具哲学高度的一条。它将我们的注意力，从“如何操作数据”（算法），拉回到了“如何组织数据”（数据结构）。

因为一个糟糕的数据结构，是任何精妙的算法都无法拯救的。它会迫使你编写出扭曲、晦涩、充满边界情况的“补丁式”代码。而一个优秀的数据结构，则会自然地引导你走向简单、清晰的算法。好的数据结构，是好算法的“母亲”。

这正是 Fred Brooks 在《人月神话》中思想的精髓：程序设计的核心，应该是对数据的思考和组织，而非对算法的炫技。

这也是 Go 语言面向组合、基于 struct 设计的灵魂所在。在 Go 中，我们花费最多时间思考的，往往是如何设计出清晰、正交的 struct。

一旦你的数据结构被设计得当，操作这些数据的方法自然就会变得简单、短小且不言自明。

// 优秀的设计：数据结构先行
type User struct {
    ID   int
    Name string
    Age  int
    Active bool
}

func (u *User) Deactivate() { ... }
func (u *User) IsMinor() bool { ... } // 是否未成年

当你拥有一个设计良好的 User 结构体时，Deactivate 或 IsMinor 这些方法的实现，几乎是“自证”的。

注：想想将Active换为 StatusFlag int ，Deactivate的实现还是“自证”的吗？

法则六：没有法则六

“Rule 6. There is no Rule 6.”

这句俏皮话，是 Rob Pike 编程哲学思想的点睛之笔。它以一种“元规则”的形式，深刻地诠释了前面所有法则的核心精神：对抗不必要的复杂性。它提醒我们，不要让规则本身成为一种新的复杂性来源。

小结

重温来自1989年 Rob Pike 的这份“忠告”，就像是回到了 Go 语言设计的“原点”。它们清晰地告诉我们，Go 语言的诞生，并非一次偶然的灵光一现，而是一种深思熟虑的、跨越数十年的编程哲学的最终体现。

在日常的 Go 开发中，我们或许会面临各种算法选择的诱惑。但 Rob Pike 的这些法则提醒我们，退后一步，首先去测量，去选择简单，去精心设计你的数据。这些看似朴素的原则，其重要性，往往超越了任何一个单一的、精巧的算法。因为它们所守护的，是软件项目中最宝贵的资产：长期的可维护性和清晰性。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？