Go - Tony Bai

标签 Go 下的文章

AI 时代，Go 语言会“失宠”还是“封神”？—— GopherCon 2025 圆桌深度复盘

一月 20, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/01/20/ai-and-go-opportunities-and-challenges

大家好，我是Tony Bai。

在 AI 的滔天巨浪面前，每一位 Go 开发者心中或许都曾闪过一丝不安：Python 似乎统治了一切，我的 Go 语言技能树还值钱吗？AI 会取代我写代码吗？我该如何在这个喧嚣的时代保持清醒？

在 GopherCon 2025 的压轴圆桌会议上，一场名为“AI 与 Go：机遇与挑战”的深度对话给出了答案。

嘉宾阵容堪称豪华(从左二到右分别是)：

Ian Cottrell: Google工程师，现从事 AI Agent 开发
Katie Hawkman: 前 Go 团队成员，现 Mercari 平台工程师
David Soria Parra: Anthropic 技术专家，MCP (Model Context Protocol) 联合创始人
Jaana Dogan: 前 Go团队成员，Google Gemini Serving 团队专家, adk-go项目成员
Samir Ajmani: Google Go 团队工程总监

他们没有贩卖焦虑，也没有盲目吹捧，而是用冷静、务实的工程师视角，为我们描绘了 Go 在 AI 时代的真实版图。

Go 的新机遇：AI 基础设施的“基石”

当被问及“Go 能提供什么 Python以及其他编程语言无法提供的价值”时，嘉宾们的回答出奇一致：生产级的可靠性与并发能力。

Samir Ajmani 提出了一个精准的洞察：Go 的崛起得益于云原生时代的爆发，而 AI 正在带来“第二次云原生机遇”。

现状：目前的 AI/ML 基础设施大量依赖 Python，适合快速原型和实验。
痛点：当这些原型需要走向大规模生产，需要处理高并发推理、构建复杂的 Agent 编排、或者实现像 MCP (Model Context Protocol) 这样需要高度可靠性的协议时，Python 的动态特性和性能瓶颈开始显现。
Go 的位置：Go 语言天生的高并发模型、静态类型安全、以及构建大规模分布式系统的基因，使其成为构建 AI 生产基础设施（Serving, Orchestration, Agent Protocols）的完美选择。

Katie 分享了一个真实案例：她在黑客马拉松中选择用 Go 而非 TypeScript 来编写 MCP Server，因为 Go 的代码在处理复杂协议逻辑时更易读、更易维护。

David(Anthropic)就个人经验和观察，认为Go 是目前AI最擅长生成的语言代码之一，这也是Go的一大优势！

Python 也许是 AI 的“训练语言”，但 Go 有望成为 AI 的“运行语言”。

职业焦虑：AI 会取代我们吗？

面对“AI 取代程序员”的言论，嘉宾们的态度是——“这只是另一种生产力工具，它改变了工作方式，但提升了人的价值。”

Samir Ajmani：未来的软件构建方式可能会变成“组件组装”。但这依然需要懂系统设计、安全性和可靠性的专业人士来构建这些高质量的组件。对于初级开发者，门槛确实变高了（简单的代码生成不再是技能壁垒），但对于具备系统思维的工程师，这是最好的时代。
Jaana Dogan (Google)：她提出了一个令人耳目一新的视角——“代码写得快了，不仅没让我失业，反而让我更强大了。” AI 极大地缩短了编码时间，这意味着工程师可以更快地去“连接点” (connect the dots)：将孤立的组件串联成系统，与更多人协作，验证更多设计想法。个人的产出能力被放大了，你不再是一个单纯的“螺丝钉制造者”，而更容易成为一名“系统架构师”。
David Suryapara (Anthropic)：作为一名非 Go 核心开发者，David 的观察更为冷静。他认为，纯粹的“代码编写”技能（例如熟练背诵 API、手写 CSS）确实面临贬值。但核心工程能力——如拆解复杂需求、设计分布式系统、处理边缘情况——将变得前所未有的重要。 AI 抬高了入行的地板，但也让那些拥有深厚解决问题能力的工程师变得更加不可替代。
Katie Hawkman：写代码从来不是工作中“最难”的部分，而是“最有趣”的部分。真正的难点在于——如何渐进式交付？如何设计良好的 UX？如何优化系统性能？这些是 AI 短期内无法完全替代的工程智慧。
Ian Cottrell：我有 40 年的开发经验，每一次生产力工具的飞跃（从汇编到 C，从 IDE 到自动补全），人们都说“不需要程序员了”。结果呢？我们的需求量反而更大了。我们只是在提升期望值，尝试解决更难的问题。

不要试图成为每一个 AI 工具的专家。选择一个工具（如 Cursor 或 Claude Code），深入掌握它，让它服务于你的工作流，而不是被它淹没。

理性审视：算力、能源与负责任的 AI

主持人提出了一个尖锐的问题：在区块链曾因高能耗饱受诟病之后，我们该如何理性看待 AI 巨大的算力和能源消耗？作为开发者，我们该如何权衡使用 AI 工具的成本？

嘉宾们的回答，揭示了工程优化在 AI 时代的巨大潜力：

Samir Ajmani (Google) 分享了一个令人振奋的实验：Go 团队尝试将 MCP 支持集成到 Go 语言服务器 (LSP) 中。结果发现，当 AI 能够直接调用精确的工具（Tools）而不是在那“空想”时，任务完成率提高了，延迟降低了，最重要的是——Token 消耗量减少了近 50%。 这意味着，通过优秀的工程工具（如 Go），我们可以显著降低 AI 的运行成本和碳排放。
Jaana Dogan (Google) 认为我们正处于优化的早期阶段。就像当年的数据库优化一样，模型推理 (Inference) 的效率优化将是接下来的重头戏。缓存、量化、专用硬件，这些工程手段将大幅抵消模型增长带来的成本。
David Suryapara (Anthropic) 提到了“小模型与蒸馏”。我们不需要每次都动用最昂贵、最慢的“超大模型”来解决所有问题。未来，针对特定领域（如代码生成）进行微调和蒸馏的小模型，将在效能和成本之间找到完美的平衡点。

不要盲目堆砌算力。“负责任的 AI”不仅是道德要求，更是工程优化的必然方向。 用更少的 Token 做更多的事，这本身就是 Go 开发者擅长的“资源优化”技能的延伸。

务实派的生存指南：过滤噪音，回归本质

在 AI 炒作的喧嚣中，如何保持清醒？

从“小”开始：不要被“AGI 即将到来”的宏大叙事吓倒。像 Katie 建议的那样，承认自己是初学者，哪怕是 MCP 的创始人也说“现在没有所谓的专家”。放下包袱，去尝试写一个简单的 Agent，去用 Go 写一个 MCP Server。
关注“确定性”：Jaana 和 Ian 都提到，AI 模型本质上是概率性的（非确定性），而工程系统需要确定性。Go 语言强大的静态分析、测试工具链和类型系统，是约束 AI 幻觉、构建可靠系统的最佳防线。用 Go 的“确定性”去包裹 AI 的“不确定性”，是未来的核心工程模式之一。
解决实际问题：不要为了 AI 而 AI。如果老板让你“加点 AI 进去”，试着去寻找那些真正能通过 AI 提升效率的痛点（比如自动化文档更新、复杂日志分析），而不是生搬硬套。

小结：Go 社区的“绿地”时刻

这场圆桌会议传递出的最强烈信号是：乐观。

我们正处于一个类似于 2013 年 Docker 诞生前夜的时刻。AI 领域的“Kubernetes”、“Prometheus”还没有被写出来。这片巨大的空白，正是 Go 开发者施展拳脚的“绿地” (Greenfield)。

正如 Samir 所言：

“如果我想让 AI 真正能够与现实世界进行交易（比如订购 Pizza 并且真的送到），这中间需要大量的、可靠的基础设施。而 Go，是构建这一层的绝佳语言。”

所以，Gopher 们，别慌。带上你的并发模型，带上你的工程智慧，去构建 AI 时代的钢铁地基吧。

资料链接：https://www.youtube.com/watch?v=r40Mwdvg38M

你的 AI 实践

听了这些顶级专家的观点，你是否对 Go 在 AI 时代的未来更有信心了？在你目前的开发工作中，是否已经开始尝试用 Go 构建 AI 应用或基础设施？你认为 Go 在 AI 领域最大的短板是什么？

欢迎在评论区分享你的实战经验或困惑！让我们一起探索 Go + AI 的无限可能。

如果这篇文章为你扫除了职业焦虑，别忘了点个【赞】和【在看】，并转发给身边迷茫的 Gopher 朋友！

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

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

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

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

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

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

Go 语言的“魔法”时刻：如何用 -toolexec 实现零侵入式自动插桩？

一月 19, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/01/19/unleashing-the-go-toolchain

大家好，我是Tony Bai。

“Go 语言以简洁著称，但在可观测性（Observability）领域，这种简洁有时却是一种负担。手动埋点、繁琐的初始化代码、版本升级带来的破坏性变更……这些都让 Gopher 们痛苦不已。

可观测性的三大支柱

相比之下，Java 和 Python 开发者享受着“零代码修改”的自动插桩福利。Go 开发者能否拥有同样的体验？

在 GopherCon UK 2025 上，来自 DataDog 的资深工程师 Kemal Akkoyun 给出了肯定的答案。他通过挖掘 Go 工具链中一个鲜为人知的特性，不仅实现了这一目标，还将其开源为一个名为 Orchestrion 的工具。今天，就让我们一起揭秘这背后的“黑魔法”。

痛点：Go 语言的“反自动化”体质

在 Go 中集成分布式追踪（如 OpenTelemetry），通常意味着你需要：

手动修改代码：在 main 函数中初始化 Tracer Provider。
到处传递 Context：在每个函数签名中添加 ctx context.Context。

OpenTelemetry Go SDK难于集成。

样板代码爆炸：在每个关键路径上通过 defer span.End() 开启和结束 Span。

这种手动方式不仅效率低下，而且容易出错。如果有遗漏，追踪链路就会断裂；如果库升级，你可能需要重写大量代码。

与 Java Agent 的字节码注入或 Python 的动态装饰器不同，Go 是静态编译语言，运行时极其简单，没有虚拟机层面的“后门”可走。这似乎是一个死局。

Gopher强烈希望 Go 也能像其他语言那样，轻松实现插桩从而注入追踪(trace)能力：

破局：编译时“大挪移”

Kemal 及其团队发现，Go 虽然没有运行时魔法，但在编译时却留了一扇窗：-toolexec 标志。

$go help build|grep -A6 toolexec
    -toolexec 'cmd args'
        a program to use to invoke toolchain programs like vet and asm.
        For example, instead of running asm, the go command will run
        'cmd args /path/to/asm <arguments for asm>'.
        The TOOLEXEC_IMPORTPATH environment variable will be set,
        matching 'go list -f {{.ImportPath}}' for the package being built.

这是一个鲜为人知的 go build 参数。它允许你指定一个程序，拦截并包装构建过程中的每一个工具调用（如 compile、link、asm 等），让你可以在真正的compile、link 等之前对Go源码文件 (以compile等命令行工具的命令行参数形式传入) 做点什么。

为了让大家直观感受 -toolexec 的作用，我们先来看一个最简单的“拦截器”示例。

假设我们写了一个名为 mytool 的小程序，它的作用仅仅是打印出它接收到的命令，然后再原样执行该命令：

// mytool.go
package main

import (
    "fmt"
    "os"
    "os/exec"
)

func main() {
    // 注意：将日志打印到 Stderr，避免干扰 go build 读取工具的标准输出（如 Build ID）
    fmt.Fprintf(os.Stderr, "[Interceptor] Running: %v\n", os.Args[1:])

    // 原样执行被拦截的命令
    cmd := exec.Command(os.Args[1], os.Args[2:]...)
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr
    if err := cmd.Run(); err != nil {
        os.Exit(1)
    }
}

现在，当我们使用 -toolexec 参数来编译一个普通的 Go 程序时：

# 先编译我们的拦截器
go build -o mytool mytool.go

# 使用拦截器来编译目标程序
go build -toolexec="./mytool" main.go  // 这里的main.go只是一个"hello, world"的Go程序

你会看到类似这样的输出：

[Interceptor] Running: /usr/local/go/pkg/tool/darwin_amd64/compile -o ...
[Interceptor] Running: /usr/local/go/pkg/tool/darwin_amd64/link -o ...

看到了吗？go build 并没有直接调用编译器，而是先调用了我们的 mytool，并将真正的编译器路径和参数作为参数传给了它。之后再调用回原命令，在上面示例执行完go build -toolexec=”./mytool” main.go后，我们同样看到了编译成功后的可执行二进制文件main。

这就给了我们一个惊人的机会：既然我们拦截了编译指令，我们当然可以修改它，甚至修改它即将编译的源文件！

但是，仅仅打印几个日志、拦截一下命令，离真正的“自动插桩”还有很远的距离。要在真实复杂的 Go 项目中，安全、准确地修改成千上万行代码，同时还要处理依赖管理、缓存失效、语法兼容等棘手问题，绝非易事。

这正是 Orchestrion 登场的时刻。它不仅将 -toolexec 的潜力发挥到了极致，更将这套复杂的流程封装成了一个开箱即用的产品。

深度解构：Orchestrion 的“编译时手术”

Orchestrion 是什么？

简单来说，它是 DataDog 开源的一个编译时自动插桩工具。它的名字来源于一种模仿管弦乐队声音的机械乐器（Orchestrion），寓意它能像指挥家一样，协调并增强你的代码，而无需你亲自演奏每一个音符。

有了 -toolexec 这把钥匙，Orchestrion 就开启了一场编译时的“精密手术”。这不仅仅是简单的拦截，而是一场与 Go 编译器配合默契的“双人舞”。

安装下面图片中步骤，你就可以自动完成对你的go程序的插桩：

Kemal 在演讲中展示了一个复杂的时序图，Orchestrion 的工作流远比我们想象的要精细：

精准拦截：
当 go build 启动时，Orchestrion 守在门口。它并不关心链接器（linker）或汇编器（asm），它的目光紧紧锁定在 compile 命令上。每当 Go 编译器准备编译一个包（Package），Orchestrion 就会叫停。
AST 级解析与“无损”操作：
它读取即将被编译的 .go 源文件，将其解析为 AST（抽象语法树）。
手术式注入 (Injection)：
根据预定义的规则（YAML 配置），Orchestrion 开始在 AST 上动刀：
- 添加 Import：自动引入 dd-trace-go 等依赖包。
- 函数入口插桩：在函数体的第一行插入 span, ctx := tracer.Start(…)。
- 函数出口兜底：利用 defer span.End() 确保追踪闭环。
  甚至，它还能识别 database/sql 的调用，自动将其替换为带有追踪功能的 Wrapper。
狸猫换太子：
手术完成后，Orchestrion 将修改后的 AST 重新生成为 .go 文件，保存在一个临时目录中。
最后，它修改传递给编译器的参数，将原始源文件的路径替换为这些临时文件的路径。
透明编译：
真正的 Go 编译器（compile）被唤醒，它毫不知情地编译了这些被“加料”的代码。

最终生成的二进制文件，包含了完整的、生产级的可观测性代码，而你的源代码仓库里，依然是那份清清爽爽、没有任何第三方依赖的业务逻辑。

Orchestrion：将“魔法”产品化

Orchestrion 不仅仅是一个概念验证，它是 DataDog 已经在生产环境中使用的成熟工具（现已捐赠给 OpenTelemetry 社区）。它解决了一系列工程难题：

1. 像 AOP 一样思考

Orchestrion 引入了类似 AOP（面向切面编程） 的概念。通过 YAML 配置文件，你可以定义“切入点”（Join Points）和“建议”（Advice）。

例如，你可以定义一条规则：
* 切入点：所有调用 database/sql 包 Query 方法的地方。
* 建议：在调用前后包裹一段计时和记录代码。

2. 解决 Context 丢失的终极“黑魔法”

Go 的许多老旧库或设计不规范的代码并没有在参数中传递 context.Context。为了在这些地方也能传递追踪 ID，Orchestrion 做了一件极其硬核的事情：它修改了 Go 的运行时（Runtime）！

通过修改 runtime.g 结构体，它引入了类似 GLS (Goroutine Local Storage) 的机制。这允许在同一个 Goroutine 的不同函数调用栈之间隐式传递上下文，彻底解决了 Context 断链的问题。虽然这听起来很危险，但在受控的编译时注入环境下，它变得可行且强大。