AWS Hydro 团队：用编译器在智能体信任边界外拦截编码错误

本月早些时候，Hydro 背后的团队开发出一种新方法，用于检查分布式系统在故障后重新发送消息时是否仍能正确工作。

这产生了一个被 Shadaj Laddad 向我描述为“像是一个 5000 行的 PR”的东西。Hydro 是一个用于分布式系统的开源 Rust 框架，这类软件同时运行在多台机器上，而现在大部分代码由智能体编写，人类负责引导。这个 PR 很难拆分成更小的部分，因为它的各个组件相互协作。

对于一个开发者所依赖、用来捕获 bug 的工具来说，要审查的代码量实在太大了。Laddad 是 AWS 旗下 Hydro 团队的研究负责人，他说这是团队花大量时间思考的问题。上周，我在圣何塞举行的 AGNTCon + MCPCon 上与他坐下来交谈。他原定于第二天发表主题演讲，届时他将论证代码审查无法跟上智能体编写代码的速度。

Laddad 告诉我，智能体让团队能够追求更高的目标，他说 PR 提交得更快、运行时间更长。“你可以让某个功能在孤立状态下运行良好，然后把它与其他东西混合在一起，突然之间这些保证就失效了，”他说。

而且你不能只相信测试。他说，在大多数智能体工作流中，智能体既编写代码，也编写单元测试。“智能体很棒，但它们不可预测，”Laddad 说。这种不可预测性正是它们具有创造力的一部分原因，同时也让人难以审查所有这些测试，并确认它们确实做了团队想要的事情。

他的答案是共享的正确性检查，放在智能体的“信任区”之外，例如由编译器强制执行的那些检查。Rust 的借用检查器就是他的例子：它在代码运行之前就能捕获竞态条件。Hydro 为分布式系统做了类似的事情，在编译时捕获多种类型的 bug，这样智能体就能对自己引入的错误获得即时反馈。团队仍在探索的更广泛目标是智能体可以共享的领域特定护栏。

为了寻找候选方案，团队研究历史项目中的反复出现的模式。幂等性——确保重试的请求不会执行两次——在设计评审中反复出现，因此团队正在研究它能否成为通用护栏。Laddad 认为这是古老阶梯上的下一级台阶。C 语言让程序员免于在汇编中弄乱函数调用。Java 把内存分配从他们手中接了过去。他认为，智能体让下一层变得更加紧迫。

不过编译器也有局限。正如 The New Stack 在 8 月报道的那样，AI 生成的 Rust 代码可以完美编译，但仍然可能是错的。

同一个团队还构建了 Infinity，这是 AWS 于 10 月 23 日宣布的一个开源智能体运行时。它会在智能体等待工具调用或 CI 作业时将其挂起，而不是让它持续运行。Laddad 引用了一项基准测试，显示在单个 Raspberry Pi 上可以运行 75,000 个并发智能体。根据 AWS 的公告，这个数字是从一次服务器测试中推算出来的，在该测试中每个空闲智能体大约使用 100 KB。

Hydro 本身是一个早期版本，专为运行高吞吐、低延迟服务且一直担心分布式系统 bug 的团队而构建。Laddad 指出，用户目前应该预期会有粗糙之处和学习曲线。回报是能够放心地更改系统，而不必担心几个月后它会出问题。

Hydro 和 Infinity 在 hydro.run 上开源，由 AWS 和 UC Berkeley 联合构建。

文章《AWS 的 Hydro 团队希望编译器捕获编码智能体的错误》首先发表于 The New Stack。