通过所有测试的代码仍可能让AI代理崩溃

最初为使软件对人类可预测而设计的 Google Go，现在正将自己定位为专为机器编写者打造的语言。8 月 11 日周二，Google 在 Google Developers Blog 上阐述了这一立场，指出 Go 语言体积小、类型系统静态、开发工具链完整，这些特性是帮助 AI Coding Agent 捕捉并修复自身错误的重要护栏。

随着 Coding Agent 生成代码的速度远超人工审查的速度，工程挑战正在转向代码的检查与维护工作。

选择更少，错误更少

一些开发者喜欢 Go 的地方，恰恰是另一些开发者感到沮丧的地方。Go 语言相对较小，有意限制了语法形式，其标准的 gofmt 工具在所有地方都应用相同的格式化风格。对 AI Agent 而言，这减少了它可能生成的模式种类，使预期输出更容易识别。

因此，Go 编译器会立即拒绝不存在的方法、错误的类型以及其他在动态类型语言中可能隐藏到运行时才暴露的结构性错误。但编译器无法判断 Agent 是否误解了任务要求、是否应用了错误的业务规则，或者是否将信息暴露给了错误的用户，因此人工监督仍然是必要的。

编译器无法判断 Agent 是否误解了任务要求、是否应用了错误的业务规则，或者是否将信息暴露给了错误的用户，因此人工监督仍然是必要的。

工具链作为 Agent 护栏

在 Go 环境中工作的 Agent 可以使用 gofmt 格式化变更、运行测试套件、使用原生模糊测试探测意外输入、并使用 govulncheck 查找对易受攻击函数的调用，而无需首先弄清楚项目采用了哪些第三方工具。如果它下载了一个模块，Go 的校验数据库可以标记出与记录版本不再匹配的副本。

标准库还可能降低机器生成代码特有的某种风险。Coding Model 有时会根据其训练数据中的模式推荐过时的、已被弃用的或根本不存在的包，但这些保护措施都无法消除软件供应链风险。漏洞扫描受限于已被发现并录入数据库的内容。

gopls 语言服务器现在可以通过 MCP 服务器将编译器错误和代码分析直接发送给 AI 工具，而 Go 1.26 中重建的 go fix 可以使用预定义的转换来更新旧代码，而不是让模型从头重写。

这些工具实际上成为了 Agent 工具链的一部分。模型提出变更，自动化工具检查其是否符合语言规范和项目要求。

Coding Model 有时会根据其训练数据中的模式推荐过时的、已被弃用的或根本不存在的包。

合并后的可维护性

2026 年 6 月的一项研究"Is Agent Code Less Maintainable Than Human Code?"（Agent 编写的代码比人类编写的代码更难维护吗？）试图衡量这种下游影响。研究人员创建了 CodeThread 框架，在该框架中，Coding Agent 在人类编写或 Agent 编写的早期任务实现上完成后续任务。

在四个 Coding Agent 和四个基准测试中，Agent 在基于之前由 Agent 编写的代码进行构建时，成功率较低。即使人类和 Agent 的实现最初都通过了测试，任务解决率的差异在某些比较中达到了 13.1%。研究人员发现了在输入验证、错误处理和实现行为方面的更微妙差异。

代码审查研究指向了类似的问题。一项针对 300 个开源项目中 278,790 条内联审查对话的独立研究，发现人工审查者在审查 Agent 编写的代码时，比审查人类编写的代码多进行了 11.8% 的审查轮次。

AI 审查建议被采纳率为 16.6%，而人工审查建议的采纳率为 56.5%。当 AI 建议被接受时，它们导致的代码规模和复杂度增幅更大。人工审查者更可能提出关于测试、理解以及知识传递的问题。

这些研究都没有在 Go、Python、JavaScript 和 Rust 中给 Agent 相同的任务，因此它们无法证明 Go 能产生更可维护的代码。它们确实表明的是：代码可以通过原始测试，但仍然可能在下一个 Agent 处理时出现问题，留下人类开发者来处理后续的大部分变更。

这些研究都没有在 Go、Python、JavaScript 和 Rust 中给 Agent 相同的任务，因此它们无法证明 Go 能产生更可维护的代码。

速度规模化时代，无聊即胜利

Agent 不介意人类开发者可能感到繁琐的重复性工作。在 Go 中，编译器标记错误类型、格式化工具保持每个文件一致、测试运行器在代码到达审查者之前就展示变更是否有效。

Go 不是唯一拥有这些护栏的语言，但当机器产生的代码超出人们有时间阅读的数量时，曾经使其显得"无聊"的限制现在看来截然不同了。