为什么 Go 语言非常适合开发 AI Agent

原文：Alexander Belanger - 2025.06.03

如同地球上几乎所有人一样，过去的几个月里，我们也一直在关注着 Agent 的发展。

特别值得一提的是，我们观察到 Agent 的采用推动了我们编排平台的增长，这让我们对哪些技术栈和框架------或者干脆没有框架------在此领域表现良好有了一些见解。

我们看到的一个更有趣的现象是混合技术栈的激增：一个典型的 Next.js 或 FastAPI 后端，搭配着一个用 Go 语言编写的 Agent，甚至在非常早期阶段就如此。

作为一名长期的 Go 语言开发者，这着实令人兴奋；下面我将解释为何我认为这将成为未来更普遍的做法。

什么是 Agent？

这里的术语有些混乱，但通常我指的是一个在循环中执行的进程，该进程对其执行路径中的下一步操作拥有一定的自主权。这与预定义的执行路径（例如定义为有向无环图的一组步骤，我们称之为工作流）形成对比。Agent 通常包含一个基于最大深度或满足某个条件（如"测试通过"）的退出条件。

当 Agent 开始规模化（即：拥有实际用户）时，它们通常具有一些共同特征：

它们是长时间运行的------从几秒到几分钟甚至几小时不等。
每次执行的成本都很高------不仅仅是 LLM 调用的成本，Agent 的本质是取代通常需要人工操作员完成的任务。开发环境、浏览器基础设施、大型文档处理------这些都花费 $$$ 钱的。
在它们的执行周期中，经常需要在某个时刻接收用户（或另一个 Agent！）的输入。
它们花费大量时间等待 I/O 或人类输入。

让我们将这一系列特征转化为对运行时的要求。为了限定问题范围，假设我们正在处理一个在远程执行的 Agent，而非在用户本地机器上（尽管 Go 对于分发本地 Agent 也是一个绝佳选择）。在远程执行的情况下，为每次 Agent 执行运行一个单独的容器成本会高得惊人。因此，在大多数情况下（尤其是当我们的 Agent 主要是简单的 I/O 和 LLM 调用时），我们最终会得到大量并发运行的轻量级进程。每个进程可以处于特定状态（例如，"搜索文件中"、"生成代码中"、"测试中"）。请注意，不同 Agent 执行的状态顺序可能并不相同。

这种包含许多并发、长时间运行进程的系统，与大约十年前的传统 Web 架构截然不同。在传统架构中，对服务器的请求处理速度要快得多，使用一些缓存、高效的处理程序和 OLTP 数据库就能高效地服务数千名日活用户。

事实证明，这种架构转变非常适合 Go 语言的并发模型、依赖通道（channel）进行通信、集中的取消机制以及围绕 I/O 构建的工具链。

高并发性

让我们从最明显的一点开始------Go 拥有极其简单且强大的并发模型。创建一个新的 goroutine 所需的内存和时间成本非常低，因为每个 goroutine 只有 2KB 的预分配内存。

这实际上意味着你可以同时运行许多 goroutine 而开销很小，并且它们在底层运行在多个操作系统线程 上，能够利用服务器中的所有 CPU 核心。这一点非常重要，因为如果你碰巧在某个 goroutine 中执行非常消耗 CPU 的操作（比如反序列化一个大型 JSON 结构），其影响会比你使用单线程运行时（如 Node.js）要小（在 Node.js 中，你需要为阻塞线程的操作创建 worker 线程或子进程），或者比使用 Python 的 async/await 也要好。

这对于 Agent 意味着什么？因为 Agent 的运行时间比典型的 Web 请求长得多，所以并发性就成为了一个更关键的问题。在 Go 中，相比于在 Python 中为每个 Agent 运行一个线程，或者在 Node.js 中为每个 Agent 运行一个 async 函数，你受到为每个 Agent 生成一个 goroutine 的限制要小得多。再加上较低的基础内存占用和编译成单一二进制文件的特点，在轻量级基础设施上同时运行数千个并发 Agent 执行变得异常简单。

通过通信共享内存

对于那些不了解的人，Go 语言有一个常见的习语：不要通过共享内存来通信；相反，通过通信来共享内存。

在实践中，这意味着不需要尝试跨多个并发进程同步内存内容（这是使用类似 Python 的 multithreading 库时的常见问题），每个进程可以通过在通道（channel）上获取和释放对象来获得该对象的所有权。这样做的效果是，每个进程只在拥有对象所有权时关心该对象的本地状态，而其他时候不需要协调所有权------无需互斥锁（mutex）！

老实说------在我编写过的大多数 Go 程序中，我使用等待组（wait groups）和互斥锁（mutexes）的次数往往比使用通道（channels）更多，因为这样通常更简单（这也符合 Go 社区的建议），并且只有一个地方需要并发访问数据。

但是，在建模 Agent 时，这种范式非常有用，因为 Agent 通常需要异步响应用户或其他 Agent 发来的消息，并且将应用程序实例视为一个 Agent 池来思考是很有帮助的。

为了更具体说明，让我们编写一些示例代码来表示 Agent 循环的核心逻辑：

go 复制代码

// 注意：在真实世界的例子中，我们需要一种机制来优雅地
// 关闭循环并防止通道关闭；
// 这是一个简化示例。
func Agent(in <-chan Message, out chan<- Output, status chan<- State) {
    internal := make(chan Message, 10) // 内部缓冲区大小为 10 的通道

    for {
        select {
        case msg := <-internal: // 从内部通道读取消息
            processMessage(msg, internal, out, status)
        case msg := <-in: // 从外部输入通道读取消息
            processMessage(msg, internal, out, status)
        }
    }
}

func processMessage(msg Message, internal chan<- Message, out chan<- Output, status chan<- State) {
    result := execute(msg) // 执行消息处理
    status <- State{msg.sessionId, result.status} // 发送状态更新

    if next := result.next(); next != nil { // 获取下一步消息（如果有）
        internal <- next // 将下一步消息发送到内部通道
    }

    out <- result // 发送处理结果
}

(请注意，<-chan 表示接收者只能从通道读取，而 chan<- 表示接收者只能向通道写入。)

这个 Agent 是一个长时间运行的进程，它等待消息到达 in 通道，处理消息，然后异步地将结果发送到 out 通道。status 通道用于发送关于 Agent 状态的更新，这对于监控或向用户发送增量结果很有用；而 internal 通道用于处理 Agent 的内部循环。例如，内部循环可以实现下图中的"直到测试通过"循环：

尽管我们使用 for 循环来运行 Agent，但该 Agent 的实例在消息之间不需要维护任何内部状态。它本质上是一个无状态归约器，其决策执行路径的下一步操作不依赖于某些内部状态。重要的是，这意味着任何 Agent 实例都能够处理下一条消息。这也允许 Agent 在消息之间使用持久化边界，例如将消息写入数据库或消息队列。

使用 `context.Context` 的集中取消机制

还记得 Agent 执行成本很高吗？假设一个用户触发了一个价值 10 美元的执行任务，但突然改变主意并点击"停止生成"------为了节省成本，你希望取消这次执行。

事实证明，在 Node.js 和 Python 中取消长时间运行的工作极其困难，原因有很多：

库之间缺乏统一的取消机制------虽然两种语言都支持中止信号（AbortSignal）和控制器（Controller），但这并不能保证你调用的第三方库会尊重这些信号。
如果信号取消失败，强行终止线程是个痛苦的过程，并可能导致线程泄漏或资源损坏。

幸运的是，Go 采用 context.Context 使得取消工作变得轻而易举，因为绝大多数库都预期并尊重这种模式。即使某些库不支持：由于 Go 只有一种并发模型，因此有像 goleak 这样的工具，可以更容易地检测出泄漏的 goroutine 和有问题的库。

丰富的标准库

当你开始使用 Go 时，你会立即注意到 Go 的标准库非常丰富且质量很高。它的许多部分也是为 Web I/O 构建的------比如 net/http、encoding/json 和 crypto/tls------这些对于 Agent 的核心逻辑非常有用。

Go 还有一个隐含的假设：所有 I/O 在 goroutine 内部都是阻塞的------再次强调，因为 Go 只有一种方式运行并发工作------这鼓励你将业务逻辑的核心编写为直线式程序。你不需要担心用 await 包装每个函数调用来将执行推迟给调度器。

与 Python 对比：库开发者需要考虑 asyncio、多线程（multithreading）、多进程（multiprocessing）、eventlet、gevent 以及其他一些模式，几乎不可能同等地支持所有并发模型。因此，如果你用 Python 编写 Agent，你需要研究每个库对你所采用的并发模型的支持情况，并且如果你的第三方库不完全支持你想要的模式，你可能需要采用多种模式。

（Node.js 的情况要好得多，尽管 Bun 和 Deno 等其他运行时的加入增加了一些不兼容的层面。）

性能剖析（Profiling）

由于其有状态性（statefulness）和大量长时间运行的进程，Agent 似乎特别容易出现内存泄漏和线程泄漏。Go 在 runtime/pprof 中提供了出色的工具，可以使用堆（heap）和分配（alloc）配置文件找出内存泄漏的来源，或者使用 goroutine 配置文件找出 goroutine 泄漏的来源。

额外优势：LLM 擅长编写 Go 代码

由于 Go 语法非常简单（一个常见的批评是 Go 有点"啰嗦"）并且拥有丰富的标准库，LLM 非常擅长编写符合 Go 语言习惯的代码。我发现它们在编写表格测试（table tests）方面尤其出色，这是 Go 代码库中的一种常见模式。

Go 工程师也往往反对框架（anti-framework），这意味着 LLM 不需要跟踪你使用的是哪个框架（或框架的哪个版本）。

不足之处

尽管有以上诸多好处，仍然有很多理由让你可能不会选择 Go 来开发你的 Agent：

第三方库支持仍然落后于 Python 和 Typescript。
使用 Go 进行任何涉及真正机器学习（real machine learning）的工作几乎是不可能的。
如果你追求最佳性能，那么有比 Go 更好的语言，如 Rust 和 C++。
你特立独行，不喜欢（显式）处理错误。