这段时间我用 Go 写了一个 Agent 框架 Covonaut，定位是生产级而非玩具：把"跑通单个 Agent、编排多个 Agent、再对外暴露成服务"整条链路都打通。

做的过程中，不少人问过同一个问题：Agent 框架这不是 Python 的天下吗，你怎么用 Go 写？

借着这个问题，我想认真聊聊当时的考量。

先说 Covonaut 现在是什么样

几个实打实的数字：

整个项目九万多行纯 Go 代码；go.mod 里只有一个外部依赖 gorilla/websocket，而且只用在 WebSocket 传输那一层，核心基本是自包含的；支持 Go 1.25 及以上版本。

支持的大模型我接得比较全：OpenAI 兼容系（DeepSeek、Qwen、Moonshot、Groq、Together 等）、Anthropic、Gemini、AWS Bedrock、GCP Vertex、GitHub Copilot、Mistral。A2A、ACP、AG-UI、A2UI 这四种 Agent 协议也都做齐了——其中 A2A 还能跟 Google ADK 互操作。

当时这么设计，是觉得 Agent 框架最后拼的不只是"能跑通工具调用"，而是能不能稳稳接进真实系统，所以协议和模型覆盖，被我放在了很靠前的位置。

为什么是 Go

第一个理由很现实：部署。纯 Go、几乎没外部依赖，编译出来就是一个独立可执行文件。我要做的是长期跑的服务，要进容器、要在不同环境分发，单二进制省了很多心。

第二个是并发，Agent 里多 Agent 并行、工具并发调用、流式事件推送都是常态，Go 的 goroutine 在这种负载下写起来顺、跑起来轻。

第三个是被我后来证明很值得的一个决定：依赖可控。核心自包含意味着版本冲突和供应链风险都小。回头看，这对一个要被人长期依赖的框架，比想象中要重要。

一点想法

用 Go 做 Agent 框架，核心价值在于"长期运行、高并发、部署简单、依赖可控"这类生产场景。Covonaut 只是把这件事认真做了一遍。

至于它能不能被更多人用起来，取决于有多少人真的需要在生产环境里用 Go 跑 Agent。

GitHub: github.com/covoyage/covonaut