不用 Python 也能做 AI Agent：有人用 Go 把 OpenAI 的 SDK 移植了

一、它是什么：Go 版的 openai-agents-python

agents-go 是 openai-agents-python 的 Go 移植版，追踪上游版本 v0.17.4。

目标是：用 Go 的地道 API（idiomatic Go），实现和 Python SDK 的行为对齐。不是简单翻译，而是把 Python 的设计理念重新用 Go 的语言特性表达出来。

需要 Go 1.26+（用到泛型、迭代器、os.Root 等新特性）。一个最简单的 Agent 长这样：

agent := &agents.Agent{
    Name:         "assistant",
    Instructions: agents.StaticInstructions("You are a helpful assistant."),
    Model:        "gpt-4o",
}

res, _ := agents.Run(context.Background(), agent, "Hello!", agents.RunOptions{
    ModelProvider: openai.NewProvider(),
})
fmt.Println(res.FinalOutputString())

地道到什么程度？ 用 Go 的泛型定义工具、用结构体 tag 反射生成 JSON Schema、用迭代器做流式事件：后面会讲。这不是"能用 Go 写"，是"用 Go 写得比 Python 还顺"。

二、功能完整度：和 Python 版几乎对齐

README 列了一张功能对照表，几乎覆盖了 Python SDK 的所有能力：

这不是个半成品移植，是几乎功能对齐的完整版。 尤其几个亮点：

• 会话分叉：可以从历史某个点分叉出新会话，这在 Python 版里也是高级功能
• 多 Provider 路由：不同 Agent 走不同后端
• ChatGPT 订阅登录：能用你的 ChatGPT 订阅额度跑 Agent，不烧 API 费

三、Go 的三个天然优势

Ifade 在帖子里说："Go 做这种事情并不吃亏"。具体体现在三方面：

优势 1：并发模型天然适合多工具并行

Agent 经常要并行调用多个工具（同时查天气、查股票、查地图）。Go 的 goroutine + channel 是为并发而生的：

// Python 要 asyncio.gather()，Go 天然并发
go callTool1()
go callTool2()
go callTool3()

Python 的 asyncio 要 async/await 满天飞，Go 的 goroutine 是隐式的、轻量的、编译器优化的。多工具并行在 Go 里几乎是免费的。

优势 2：类型系统让状态流转清晰

Python 的 Agent 状态流转经常靠 dict 和运行时检查，调试时容易懵。Go 的强类型让每一步状态都明确：

type weatherArgs struct {
    City string `json:"city" jsonschema:"the city"`
}

getWeather := agents.NewFunctionTool("get_weather", "Look up the weather.",
    func(ctx context.Context, tc *agents.ToolContext, args weatherArgs) (string, error) {
        return "sunny in " + args.City, nil
    })

函数工具的参数用 Go 结构体定义，tag 反射生成 JSON Schema 给模型看。 编译期就检查类型，不用等运行时炸。

优势 3：单二进制部署

这是 Go 对 Python 的杀手级优势：编译出一个二进制，扔到任何机器上就跑。不用装 Python、不用管虚拟环境、不用 pip install 一堆依赖。

agents-server 就是这个优势的体现：内嵌前端（go:embed）、内嵌 SQLite、一个二进制开箱即用。对比 Python Agent 平台要装一堆依赖、配虚拟环境、打包成 Docker……Go 版的部署体验是降维打击。

四、Go 的一个真实劣势：JSON Schema 反射

Ifade 也很诚实："唯一麻烦的是 JSON Schema 那块，Go 的反射写起来没 Python 的 Pydantic 舒服"。

这是实话。Python 的 Pydantic 把"定义数据结构 → 生成 JSON Schema → 校验输入"做得极其丝滑。Go 要靠 struct tag + reflect 包 + 第三方库（这里用了 google/jsonschema-go）手动反射，代码确实啰嗦。

但这是工程代价，不是能力缺失。 牺牲一点开发体验，换来的是编译期类型安全和运行时性能。对生产环境来说，这个交换是值得的。

五、agents-server：一个完整的 Agent 平台 Demo

光移植 SDK 不够，Ifade 还写了个完整的 Web 应用验证它能跑：agents-server。

这是个单二进制的 Agent 平台：

• 内嵌前端：Primer 风格 UI（GitHub 的设计语言），支持暗色模式
• 内嵌 SQLite：开箱即用，不用配数据库
• REST API + WebSocket 流式：完整的前后端
• 自动生成 auth token：启动时打印，安全

go build -o agents-server ./cmd/agents-server
./agents-server --port 8080

打开 http://127.0.0.1:8080，可以在浏览器里配置 Agent、MCP 服务、沙箱、记忆、技能，跑带流式输出和工具审批的对话。

这个 Demo 的价值不只是验证 SDK，它本身就是一个可用的、轻量的、自托管的 Agent 平台。对比那些重型平台（要 K8s、要 Redis、要一堆微服务），agents-server 的"单二进制 + SQLite"是极简主义的胜利。

"野路子"前端的诚实自嘲

Ifade 在帖子里自嘲前端写法很野："没有构建步骤，裸 JSX 通过 go:embed 打进二进制，浏览器端 ESM 直接跑，React.createElement 手搓 UI，不要学这个写法哈，纯粹是为了保持单二进制部署才这么搞的 /手动狗棍"。

这种坦诚很可爱。 他清楚知道这是"为单二进制牺牲了工程规范"，不是推荐的最佳实践，是为了部署体验做的取舍。承认自己用了 hack，比假装这是好设计真诚得多。

六、设计权衡：为什么核心塞在一个 package

README 的 Design notes 里有个有意思的决策：核心代码全塞在一个 agents/ package 里，没有按"工具/输出/模型"细分。

原因很 Go 特有：import cycle（循环依赖）。如果拆成 tools/、models/，工具回调引用 RunContext，模型接口引用 Tool，就会形成循环依赖。Go 不允许循环 import，所以只能把它们放一起。

这不是偷懒，是 Go 语言特性的真实约束。 Python 没有这个问题（Python 的 import 是运行时解析，可以循环）。这种语言差异，正是"移植"时要做的真实工程权衡。

七、沙箱的安全设计：Docker 作为独立模块

沙箱（让 Agent 跑不可信代码）是高危功能。agents-go 的处理很谨慎：Docker 后端是独立 module，核心 SDK 不依赖它。

// 核心只要 sandbox 接口
import "github.com/zzir/agents-go/sandbox"

// 用 Docker 才单独引入
import "github.com/zzir/agents-go/sandbox/docker"

Docker 后端默认无网络、只读根文件系统、丢弃 capabilities、非 root 用户、CPU/内存/PID/时间限制：一套完整的沙箱安全配置。

这种"Docker 作为独立模块"的设计体现的是场景收敛加依赖极简：核心 SDK 只 4 个依赖，要 Docker 沙箱才单独 go get，不污染核心。

八、谁该关注

强烈推荐，如果：

• 你是 Go 开发者，想做 AI Agent 但不想碰 Python
• 你想要一个单二进制部署的 Agent 平台（运维友好）
• 你在做后端服务，想把 Agent 能力嵌进去（Go 比 Python 更适合做服务）
• 你关心并发性能（多工具并行在 Go 里几乎免费）
• 你想对比 Python/Go 两种 Agent SDK 的设计差异

可能要注意：

• 需要 Go 1.26+（比较新，部分老项目要升级）
• JSON Schema 反射不如 Pydantic 顺手（Go 的真实代价）
• 前端是"野路子"（作者自己说了，别学）
• 追踪的是特定上游版本（v0.17.4），新功能要等移植

九、它背后的意义：Agent 生态的去 Python 化

agents-go 不只是一个移植项目，它代表一个趋势：Agent 生态正在摆脱 Python 绑定。

agent-native（TypeScript）、Pi（模型自由的 CLI）、agents-go（Go SDK）这类项目都在这条线上。

这些项目证明了一件事：Agent 的核心逻辑（编排、工具调用、状态管理、流式、Tracing）不依赖任何特定语言。 Python 早先占优只是因为生态先发（LangChain 们），不是技术必然。

Go 的并发模型、类型系统、单二进制部署，对生产级 Agent 服务其实是更优解。 当 Agent 从"Demo 阶段"走向"生产部署"，语言选择的重心会从 Python 倾向 Go/Rust/TypeScript：因为它们更适合做长期运行的后端服务。

agents-go 是这个趋势的早期样本。

十、小结

一句话：agents-go 是 openai-agents-python 的 Go 移植版，功能几乎对齐，配套单二进制的 agents-server 平台。Go 的并发和类型系统让 Agent 开发不吃亏，单二进制部署对生产环境是降维打击。

Ifade 帖子里那句"Go 做这种事情并不吃亏"是真的。而且不止"不吃亏"，在并发、类型安全、部署体验上，Go 还有真实优势。

如果你是 Go 开发者，又被 Python Agent 生态绑架得不爽：agents-go 给了你一条用自己熟悉的语言做 Agent 的路。 而且这条路，可能比 Python 那条更适合生产部署。

加上那个单二进制、内嵌前端、SQLite 开箱即用的 agents-server：这大概是目前最轻量的自托管 Agent 平台方案。

本文基于 Ifade（@Ifade）的论坛帖子及 agents-go 仓库整理。仓库 https://github.com/zzir/agents-go ，MIT 协议，Go 1.26+，追踪 openai-agents-python v0.17.4。配套 agents-server 单二进制 Demo 在 cmd/agents-server/。

推荐配合：前面写的 Pi（多模型编排）、agent-native（TypeScript 原生 Agent 框架）、senda（Go+Wails 的轻量哲学）、企业 Agent 平台工程书（Part V Agent 能力链 + Part VIII 部署）：agents-go 是它们在 Go 语言侧的对应物。