当话题转向AI编程时，Python往往是那个不假思索的默认答案。但随着AI应用的重心从模型训练转向自主智能体和复杂的工程化落地，基础设施层的语言选择正在发生微妙的变化。
近期，开源数据编排工具 Bruin 的作者撰写了一篇名为《Go 是开发 AI Agents 的最佳语言》的文章，在 Hacker News 上引发了数百条跨语言阵营的激烈讨论。
为什么一位拥有十年 Python 和 JS 经验的开发者，最终选择用 Go 来构建现代 AI 基础设施？在 AI 生成代码日益普及的当下，编程语言的“静态类型”、“编译速度”和“语法极简主义”又被赋予了哪些新的价值？
本文将深入剖析这场争论，探讨在所谓的“氛围编程”时代，Go语言如何凭借其独特的设计哲学，意外地切中了 AI Agent 开发的要害。
为什么是 Go？来自生产一线的工程反思
Bruin 是一个开源的 ETL（提取、转换、加载）工具。在数据工程领域，Python 拥有近乎统治级的地位（Pandas, Airflow 等），按理说，Bruin 本应用 Python 编写。
但作者最终选择了 Go。原因在于，AI Agent 和数据编排工具在本质上属于基础设施，它们面临的工程约束与模型训练截然不同：
-
极致的并发需求：Agent 绝大部分时间都在等待外部 API 的响应（如 OpenAI, Anthropic）。Go 极其轻量的 Goroutine 机制（2KB 栈空间，极低的上下文切换成本）允许在单机上轻松维持数万个并发请求，而 Python 的 GIL（全局解释器锁）即使配合 asyncio，在达到一定并发量后也会遇到明显的线程竞争瓶颈。（注：最新版 Python 已计划移除 GIL 限制）
-
极简的部署体验：Go 编译出的单一静态二进制文件，无需像 Python 那样处理复杂的虚拟环境（venv）、依赖冲突和运行时版本问题。对于需要在用户侧运行的 CLI 工具而言，Go 堪称“分发即运行”的典范。
-
跨平台验证的便利：Go 语言原生支持跨平台编译，这不仅意味着开发者可以轻松构建多平台产物，未来的“后台 AI Agent”也能在一个隔离的沙箱中快速验证代码的跨平台兼容性。
除了上述硬核的工程指标，作者还坦诚地分享了一个极其主观但对初创团队至关重要的考量：开发体验与情绪价值。
作为项目在很长一段时间内的核心贡献者，他深刻地意识到：“对于一个小型团队来说，在构建大型项目时，快乐和活力是最稀缺的资源之一。因此，至关重要的是，我不能对自己每天要面对的技术栈感到畏惧或厌烦。”
Go 语言或许在某些特性上不如 Python 灵活，也不如 Rust 表达力强，但它带来的那种“一切尽在掌握”的确定性和快速获得反馈的成就感，能让开发者在漫长的马拉松式开发中保持心流状态。这种心理层面的正向反馈，在探索 AI Agent 这类充满不确定性的前沿领域时，往往是支撑团队坚持走下去的关键力量。
如果说以上只是 Go 作为“云原生王者”的常规操作，那么在引入大语言模型作为“代码生成器”后，Go 的语言特性产生了奇妙的化学反应。
静态编译：给 AI 戴上“紧箍咒”
当 Coding Agent 开始每分钟吐出成千上万行代码时，最大的挑战不再是“如何生成”，而是“如何验证其有效性”。
在解释型语言（如 Python 或 JavaScript）中，代码的正确性往往只有在运行到特定分支时才能被验证。作者指出，这是 Go 在对抗 AI 幻觉时最大的优势之一：Go 是一门强类型的编译型语言。
编译器的“守门员”效应
当你用 LLM 生成 Go 代码时，go build 命令成了一道天然且严苛的防火墙。类型不匹配、未使用的变量、错误的函数签名——这些占据了 AI 幻觉相当大比例的低级错误，会被 Go 编译器瞬间无情地驳回。
正如一位 Hacker News 网友所言：“在这个人人都在‘氛围编程’的时代，你迫切需要一个编译器在背后支持你。Go 让你可以写稍微随意一点的代码，但又不会像 Python 或 JS 那样毫无底线。编译器扮演了看门人的角色，将混乱控制在一定范围内。”
为什么不是 Rust？
讲到编译期安全，Rust 绝对是无可争议的王者。但为什么作者认为 Go 比 Rust 更适合 AI Agent？
- 迭代速度决定一切：AI Agent 的工作流是一个“生成 -> 编译 -> 报错 -> 修复”的紧密反馈循环。Go 的编译速度几乎是瞬时的，这使得 LLM 的试错循环可以极快地运转。而 Rust 漫长的编译时间，在这里成为了致命的瓶颈。
- 借用检查器的‘认知负荷’：Rust 的内存模型（生命周期、借用）极其复杂。现阶段的 LLM 在处理复杂的借用关系时，常常会陷入“为了让编译器闭嘴而无脑
clone()”的陷阱，导致生成的代码偏离 Rust 的最佳实践。
- 更平缓的试错成本：Go 的垃圾回收机制让 AI（以及审查代码的人类）可以专注于业务逻辑，而不必在内存管理上耗费计算 token 和审查精力。
简单来说：Rust 的上限极高，但门槛太陡；Go 用 20% 的努力（快速编译+GC），换取了 80% 媲美 Rust 的安全性，这恰好是 AI 快速迭代的最优解。
极简主义与“无聊”的胜利
Go 语言自诞生起，就因其语法的“无聊”和“死板”（比如缺乏灵活的宏、长期没有泛型、繁琐的错误处理）而饱受争议。然而，在 AI 时代，这种“无聊”却意外地成为了巨大的优势。
“只有一种做法”的红利
Python 和 JavaScript 以“灵活”著称。在一个 JS 项目中，有人用 CommonJS，有人用 ES6 Modules；有人用 npm，有人用 pnpm。对于人类来说，这叫“生态繁荣”；但对于 LLM 来说，这叫“状态空间爆炸”。
Go 是极其“固执己见”的语言。
- 格式化代码？只有
gofmt。
- 怎么处理错误？永远是
if err != nil。
- 怎么写测试？标准库
testing 包。
正如作者指出的：“要求 Agent 格式化 JS 代码，它会去引入一个新工具并尝试配置它；而在 Go 中，它只需要运行 gofmt。”
这种高度统一的代码风格，意味着在 LLM 的训练语料库中，Go 代码的“信噪比”极高。模型不需要在多种编程范式中猜测你的偏好，它输出的 Go 代码通常具有高度的同质性和可预测性。
人类可读性：代码审查的最后防线
当 AI 成为主要的“代码编写者”时，人类的角色将不可避免地向“代码审查者”倾斜。
如果 AI 生成了一段高度抽象的 Haskell 代码，或者使用了大量宏的 Rust 代码，人类审查者需要耗费极大的脑力去反编译这些逻辑。
而 Go 代码是出了名的“所见即所得”。没有隐藏的控制流，没有复杂的运算符重载。当 AI 生成了几百行 Go 代码时，即使是一位初级开发者，也能相对轻松地顺着逻辑线读懂它在干什么。
在 AI 编程的下半场，“代码易读”将比“代码易写”重要得多。
跨越阵营的交锋：Hacker News 的不同声音
当然，这篇文章在 Hacker News 上并非一边倒的赞同。不同语言阵营的开发者提出了极其犀利的反思。
反思一：Python 真的过时了吗？
Python 拥护者指出，文章混淆了“运行时性能”和“开发生态”。
虽然 Go 在高并发和 I/O 上优于 Python，但如果 AI Agent 的核心逻辑涉及大量的数据科学计算、复杂的概率模型，或者需要直接调用底层的 C++ 机器学习库，Python 依然是不可替代的粘合剂。对于许多初创团队来说，“让代码先跑起来”远比“让代码跑得快”更重要。
反思二：类型系统能否取代测试？
支持函数式语言（如 OCaml, F#）的开发者指出，Go 的类型系统依然过于薄弱。
Go 缺乏代数数据类型和模式匹配，导致其虽然能抓住低级语法错误，但难以像 Rust 或 OCaml 那样“在编译期保证业务逻辑状态的正确性”。
对于他们而言，如果 AI 真的足够聪明，应该让它生成具有极强类型约束的代码，把正确性完全交给编译器，而不是像 Go 那样依然需要编写大量的单元测试。
反思三：长远来看，语言还重要吗？
这是一个终极的哲学问题：如果未来 AI 不再犯错，能够零成本生成正确的机器码，高级编程语言还有存在的意义吗？
有评论认为，当模型能力足够强时，我们甚至不需要编译型语言的保护，直接用自然语言（英语）加上 LLM 生成运行时的 WebAssembly 可能才是终局。在这个维度上，争论 Go 还是 Python，就像在争论用什么牌子的算盘一样没有意义。
小结：实用主义者的狂欢
在 AI 技术日新月异的当下，我们容易陷入一种对“前沿”的盲目崇拜，认为只有最复杂的语言、最先进的模型才能构建出优秀的系统。
但 Bruin 作者的实践和 Go 社区的繁荣告诉我们另一个故事：工程的本质是权衡。
Go 并不是世界上最完美的语言，它的类型系统不如 Rust 严谨，它的生态不如 Python 庞大。但它用极致的编译速度、简单的并发模型、出色的跨平台支持和高统一的编码规范，构建了一个容错率极高的工程基座。在这个基座上，无论是人类还是 AI Agent，都能以较低的“认知摩擦力”输出可靠的工业级代码。
资料链接：
你更看好谁？
在 AI 编程的下半场，语言的地位正在重构。你是坚守 Python 的生态优势，还是更看好 Go 在“基础设施级 Agent”中的潜力？你认同“编译器是 AI 的最佳守门员”这个观点吗？
欢迎在评论区分享你的看法！也欢迎到 云栈社区 的相应板块深入探讨更多关于 Go、Python 和 AI 工程化的话题。
发表于 前天 05:02
|
查看: 15|
回复: 0
