本文永久链接 – https://tonybai.com/2026/02/18/why-we-chose-go-over-python-for-llm-gateways

大家好，我是Tony Bai。

在 2026 年的今天，人工智能早已走出了实验室，成为企业级应用的核心驱动力。Python，凭借其在机器学习领域的绝对统治地位——拥有 PyTorch、TensorFlow、Hugging Face 等无可匹敌的生态系统——长期以来被视为 AI 开发的“默认语言”。

然而，随着 AI 应用从模型训练（Training）走向推理服务（Inference）和应用编排（Orchestration），工程重心发生了微妙的转移。当我们谈论模型本身时，Python 是王者；但当我们谈论承载模型流量的基础设施——网关、代理、路由器时，Python 还是最佳选择吗？

近日，开源 LLM 网关项目 Bifrost 的维护者在 Reddit 上分享了一篇题为《Why we chose Go over Python for building an LLM gateway》的技术复盘，引发了社区的强烈反响。他们放弃了拥有 LiteLLM 等成熟竞品的 Python 生态，转而使用 Go 重写了核心网关。结果令人咋舌：延迟降低了约 700 倍，内存占用降低了 68%，吞吐量提升了 3 倍。

这场技术选型的背后，折射出的是 AI 工程化进入深水区后，对并发模型、资源效率与部署架构的重新审视。

Python 的“舒适区”与“性能墙”

在项目的初期，选择 Python 似乎是理所当然的。

1. 生态惯性与“胶水”优势

绝大多数 AI 工程师都是 Python Native。从 LangChain 到 LlamaIndex，几乎所有的 Agent 开发框架都优先支持 Python。使用 Python 构建网关，意味着可以直接复用现有的库，甚至可以直接挂载一些轻量级的 Python 逻辑来处理 Embeddings 或 RAG（检索增强生成）流程。FastAPI 的易用性更是让开发者能在几分钟内搭建起一个服务。

2. 遭遇瓶颈：网关的本质是 I/O

然而，LLM 网关的业务属性决定了它的性能痛点。与计算密集型（CPU-bound）的模型推理不同，网关是典型的 I/O 密集型应用。它的核心职责是：

• 接收成千上万的客户端请求。
• 将请求转发给上游提供商（如 OpenAI, Anthropic, 或自建的 vLLM）。
• 等待上游响应（这是最耗时的环节，LLM 的首字延迟 TTFT 通常在秒级）。
• 将流式响应（SSE）回传给客户端。

在这个过程中，网关绝大部分时间都在“等待”。

3. Python 的并发痛点

Bifrost 团队在测试中发现，当并发请求数达到 500-1000 RPS（每秒请求数）时，Python 的瓶颈开始显现。

• GIL（全局解释器锁）的幽灵：虽然 Python 的 asyncio 可以处理 I/O 并发，但 GIL 依然限制了多核 CPU 的利用率。对于需要处理大量并发连接、同时可能涉及少量数据处理（如 Token 计数、PII 过滤）的网关来说，线程竞争（Thread Contention）成为了不可忽视的开销。
• 昂贵的上下文切换：在 Python 中维持数千个并发连接，其上下文切换的开销远高于编译型语言。

Go 的降维打击——数据背后的技术真相

Bifrost 团队最终选择了 Go。这一决定并非出于对语言的偏好，而是基于冷冰冰的 Benchmark 数据。让我们深入分析他们披露的核心指标。

延迟（Latency）：微秒与毫秒的鸿沟

数据对比：
* Bifrost (Go): ~11 微秒 (0.011ms) / 请求
* LiteLLM (Python): ~8 毫秒 / 请求

这是一个惊人的 700 倍 差距。

虽然 8 毫秒在人类感知中似乎微不足道，但在高并发架构中，这被称为“开销放大”。

• 累积效应：在一个复杂的 AI Agent 工作流中，可能涉及几十次 LLM 调用。如果每一层网关都增加 8ms 的延迟，累积起来就是可感知的卡顿。
• 高负载下的劣化：在 10,000 个并发请求下，Go 引入的总处理时间仅为 110ms，而 Python 方案则产生了惊人的 80 秒总 CPU 时间开销。这意味着 Python 方案需要消耗更多的 CPU 核心来维持同样的响应速度，否则请求就会排队，导致尾部延迟（Tail Latency）飙升。

此外，Go 的 net/http 标准库在处理 HTTP 请求时经过了极致优化。Go 不需要像 Python 那样依赖 ASGI/WSGI 服务器（如 Uvicorn），其原生的 HTTP 处理能力配合 Goroutine，使得每个请求的内存分配和 CPU 周期都降到了最低。

并发模型：Goroutine vs Asyncio

架构对比：
* Go: 10,000 个 Goroutines，每个仅占用 ~2KB 栈空间。
* Python: 受限于 OS 线程开销或 Event Loop 的单核瓶颈。

LLM 网关的特殊性在于长连接。LLM 的流式输出可能持续数秒甚至更久。这意味着网关必须同时维护成千上万个活跃连接。

Go 的 GMP（Goroutine-Machine-Processor）调度模型天生适合这种场景。成千上万个 Goroutine 可以复用少量的系统线程，上下文切换由 Go Runtime 在用户态极速完成，几乎不消耗系统内核资源。

相比之下，Python 即使使用了 uvloop，在面对海量并发连接的数据搬运时，其解释器的开销依然是一个沉重的包袱。

内存效率与成本

数据对比：
* Go: 内存占用降低 ~68%。
* 生产环境: Go 跑在 t3.medium (2 vCPU, 4GB) 上即可；Python 则需要 t3.xlarge。

对于大规模部署 AI 服务的企业来说，这意味着基础设施成本直接减半。

Python 的动态类型系统和垃圾回收机制导致其对象内存占用较大。而 Go 的结构体布局紧凑，且编译器能进行逃逸分析（Escape Analysis），将大量对象分配在栈上而非堆上，从而显著降低了 GC 压力和内存占用。

社区深度探讨——AI 时代的语言版图重构

这篇帖子在 r/golang 引发了极高质量的讨论，评论区揭示了行业内更深层次的趋势。

“AI 能够写代码”改变了竞争规则

过去，Python 的一大优势是“开发效率高”。写 Python 代码通常比写 Go 或 Rust 快。

但在 2026 年，“Agentic Coding”（即利用 AI Coding Agent 辅助编程）已经成为主流。

有开发者指出：“LLM 让编写 Rust 和 Go 变得非常高效，你完全可以享受到高性能语言的红利，而不用支付编写它们的‘学习成本’。”

这是一个极其深刻的洞察。

• Rust 的借用检查器：以前是新手的噩梦，现在 LLM 可以很好地处理生命周期标注。
• Go 的样板代码：if err != nil 虽然繁琐，但 Copilot/Cursor/Claude Code等 可以一键生成。

当“编写代码”不再是瓶颈时，“运行时性能”和“稳定性”的权重就被无限放大了。这进一步削弱了 Python 在后端基础设施层的竞争力。

Rust 还是 Go？

既然要高性能，为什么不直接上 Rust？

评论区对此展开了激辩。虽然 Rust 在理论上拥有比 Go 更高的性能上限和内存安全性（无 GC），但 Go 在“开发效率”与“运行效率”之间找到了完美的平衡点。

• Rust: 适合构建数据库、搜索引擎内核等对延迟极其敏感且逻辑复杂的底层组件。但 Rust 的“认知负担”依然较重，且编译速度较慢。
• Go: 提供了 80% 的 Rust 性能，但只有 20% 的开发难度。对于网关、代理这类中间件，Go 的标准库（特别是 net/http）极其成熟，编译速度极快，且自带 GC 能让开发者从内存管理的细节中解脱出来，专注于业务逻辑（如限流、计费）。

对于大多数 AI 网关场景，Go 是性价比最高的选择。

Python 的归宿：模型与胶水

这是否意味着 Python 将被淘汰？绝不。

社区共识非常明确：Python 的护城河在于 ML 生态。

• 模型训练与微调：PyTorch/JAX 无可替代。
• 数据科学与探索：Jupyter Notebook 是数据科学家的后花园。
• 快速原型开发：在验证想法阶段，Python 依然是最快的。

但在生产环境部署（Production Serving）阶段，架构正在发生分离：

• 控制平面（Control Plane）：由 Go/Rust 接管，负责流量调度、鉴权、日志、监控。
• 数据平面（Data Plane）：核心推理引擎（如 vLLM）虽然内部可能有 C++/CUDA 优化，但外层接口仍常由 Python 封装。

Go 在 AI 领域的未来展望

Bifrost 的案例只是冰山一角。我们正在目睹 Go 语言在 AI 领域的“新基建”运动。

静态二进制文件的魅力

Deployment simplicity 是作者提到的另一个关键点。

部署 Python 应用通常意味着：配置 Docker -> 安装 Python -> pip install requirements.txt -> 解决依赖冲突 -> 虚拟环境管理。

而部署 Go 应用：COPY bifrost /usr/local/bin/ -> Run。

在容器化和 K8s 盛行的今天，Go 的静态链接二进制文件极大地简化了 CI/CD 流程，减小了镜像体积，提升了冷启动速度（这对于 Serverless AI 推理尤为重要）。

AI 专有工具链的完善

虽然 Go 在 Tensor 操作库上不如 Python 丰富，但在应用层工具上正在迅速补齐。

• LangChainGo: 社区正在移植 LangChain 的核心能力。
• Vector Database Clients: Milvus, Weaviate, Pinecone 等向量数据库都有优秀的 Go SDK。
• 主流大模型 GenAI SDK: 像Google等主流大模型厂商官方对 Go 的支持力度都很大，Gemini、Claude、OpenAI 等模型的 Go SDK 体验都还不错。

架构师的决策建议

如果你正在构建一个 AI 应用平台：

• 不要用 Python 写网关：不要让 GIL 成为你高并发路上的绊脚石。
• 不要用 Go 写模型训练：不要试图挑战 PyTorch 的地位，那是徒劳的。
• 采用“三明治架构”：
  • 上层：Go 处理高并发 HTTP 请求、WebSocket、SSE。
  • 中层：Go 处理业务逻辑、数据库交互、Redis 缓存。
  • 底层：Python/C++ 容器专门负责模型推理，通过 gRPC 与 Go 层通信。

小结

Bifrost 从 Python 到 Go 的迁移，不仅仅是一次代码重写，更是一次架构理念的升级。它证明了在 AI 浪潮中，基础设施的性能与模型的智能同等重要。

随着 LLM 应用规模的爆发式增长，计算成本和响应延迟将成为企业关注的焦点。Go 语言凭借其高效的并发模型、极低的资源占用和极简的部署体验，正在成为 AI 基础设施层的“事实标准”。

对于 Gopher 而言，这是一个最好的时代。我们不需要成为算法专家，只需要发挥 Go 语言最擅长的能力——构建高性能、高可靠的管道，就能在 AI 时代占据不可或缺的一席之地。

资料链接：https://www.reddit.com/r/golang/comments/1r27pqx/why_we_chose_go_over_python_for_building_an_llm/

你认为 Python 会被“边缘化”吗？

随着 Agentic Coding 的普及，高性能语言的入门门槛正在消失。在你的 AI 实践中，是否也感受到了 Python 在生产部署时的无奈？你认为 Go 在 AI 领域还会攻下哪些阵地？

欢迎在评论区分享你的看法！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2026/02/15/openclaw-core-engine-pi-architecture-philosophy-minimalism

大家好，我是Tony Bai。

在 AI 辅助编程工具（Coding Agent）日益臃肿的今天，我们是否走偏了方向？

过去的两年里，我们见证了从 ChatGPT 复制粘贴，到 Copilot 自动补全，再到 Cursor 和 Claude Code 这种全自动 Agent 的演进。然而，随着功能的堆砌，工具变得越来越“重”。Claude Code 从一个轻量级的 CLI 变成了一个充满 80% 我们不需要功能的“宇宙飞船”，系统提示词（System Prompt）在每次更新中剧烈变动，甚至导致模型行为不可预测。

作为 OpenClaw 的核心智能体，Pi 的诞生源于一种“反叛”精神：如果我不需要它，我就不会构建它。

本文将基于 Pi 作者的深度复盘，剖析如何构建一个极简、可控、且在基准测试中击败主流竞品的 Coding Agent。你可以将之看成一份关于 AI 原生应用架构设计的教科书。

回归原点——为什么要重新造轮子？

在决定构建 Pi 之前，作者尝试了市面上几乎所有的 Agent Harness（智能体框架），包括 Claude Code, Codex, Amp等。

现有工具的“三大原罪”

• 不可控的上下文（Context）：现有的框架往往在背后注入大量并未在 UI 中展示的 Prompt。对于 Coding Agent 来说，上下文工程（Context Engineering）是核心。如果开发者无法精确控制输入模型的每一个 Token，就无法获得稳定的输出。
• 糟糕的调试体验与黑盒：大多数框架不允许开发者检查每一次交互的细节。当 Agent 犯错时，你不知道是 Prompt 的问题，还是模型的问题。
• 自托管（Self-hosting）的噩梦：许多框架（如 OpenCode）依赖 Vercel AI SDK，这在处理自托管模型（如 Ollama, vLLM）的工具调用（Tool Calling）时经常出现兼容性问题。

Pi 的设计哲学

Pi 的核心理念是：Opinionated and Minimal（固执且极简）。

它不是为了服务百万用户而设计的通用产品，而是为了满足硬核开发者需求而生的“瑞士军刀”。为了实现这一目标，Pi 被拆解为四个核心模块：

• pi-ai: 一个统一的 LLM API 抽象层。
• pi-agent-core: 智能体循环与事件流处理。
• pi-tui: 一个基于差异化渲染的极简终端 UI 框架。
• pi-coding-agent: 将上述组件串联起来的 CLI。

驯服多模型世界的“巴别塔” —— pi-ai

构建 Agent 的第一步是解决模型调用的碎片化问题。虽然市面上看似只有四家主流 API（OpenAI, Anthropic, Google, xAI），但在实际工程落地中，细节充满了魔鬼。

API 的“方言”问题

尽管大家都声称兼容 OpenAI 格式，但各家的理解千差万别：

• Reasoning 字段的混乱：OpenAI 不支持在 Completions API 中返回推理过程，而 DeepSeek 等推理模型则在各自的字段中返回（有的叫 reasoning_content，有的叫 reasoning）。
• 参数的不兼容：Cerebras 和 xAI 不支持 store 字段；Mistral 使用 max_tokens 而不是 max_completion_tokens；Grok 不支持 reasoning_effort。

pi-ai 建立了一个健壮的适配层，通过详尽的测试套件（覆盖图像输入、推理追踪、工具调用）来抹平这些差异。

真正的上下文无缝切换（Context Handoff）

这是一个极具创新性的功能。在开发过程中，我们经常需要切换模型（例如：用便宜的模型做推理，用昂贵的模型写代码）。

然而，不同提供商对“工具调用”和“思维链”的格式定义完全不同。如果中途从 Claude 切换到 OpenAI，上下文往往会崩溃。

pi-ai 实现了跨提供商的上下文序列化与反序列化。

• 它将 Anthropic 的 标签转换为 OpenAI 能够理解的内容块。
• 它处理了提供商特有的签名 Blob 数据，确保在切换模型后，对话历史依然连贯。

这意味着你可以用 Claude Sonnet 进行规划，然后无缝切换到 GPT-5 Codex 进行代码生成，最后序列化保存到 JSON 中以备后用。

被遗忘的“中止信号”

许多 LLM SDK 忽略了 AbortController 的支持。在生产环境中，能够随时打断 Agent 的胡言乱语是至关重要的。pi-ai 从底层支持了全链路的中止信号，不仅能停止文本生成，还能停止正在进行的工具调用。

结构化的工具结果

传统的 Agent 框架往往直接将工具的文本输出扔给 LLM。但在 UI 层面，用户需要看到更丰富的信息（如图片、图表）。

Pi 引入了“分离式工具结果”设计：

• 给 LLM 看的：纯文本或 JSON。
• 给 UI 看的：结构化数据或 Base64 图片。

例如，一个天气工具可以给 LLM 返回“东京 25度”，同时给 UI 返回一个包含温度趋势图的 JSON 对象供渲染。

重新发明终端 UI —— pi-tui

为什么一个 Agent 项目要自己写一个 UI 框架？作者给出的理由非常硬核：现有的 TUI 库（如 Ink, Blessed）要么太重（像写 React），要么已停止维护。

TUI 的两种流派

• 全屏接管模式（Full Screen）：像 Vim 一样接管整个视口。缺点是失去了终端原生的滚动条和搜索功能。
• 线性追加模式（Linear Append）：像标准 CLI 一样追加输出，只在需要时回溯光标更新内容。这是 Claude Code 和 Pi 选择的路线。

差异化渲染

为了在不使用 React 这种重型 Virtual DOM 的情况下实现无闪烁更新，Pi 实现了一个基于 Retained Mode（保留模式）的渲染引擎。

• 组件缓存：每个组件（如消息框、输入框）缓存其渲染结果。如果内容未变，直接复用。
• 双缓冲技术：维护一个“后备缓冲区（Backbuffer）”，记录屏幕上当前显示的内容。
• 最小化重绘：每次更新时，仅重绘发生变化的行。

这种极致的优化使得 Pi 在 Ghostty 或 iTerm2 等现代终端中实现了丝滑的、近乎零闪烁的体验，同时内存占用极低（仅几百 KB）。

极简主义的智能体设计 —— Less is More

这是 Pi 最具争议也最具启发性的部分。它彻底抛弃了业界流行的“最佳实践”，走出了一条极其精简的道路。

System Prompt：1000 Token 足矣

与 Claude Code 动辄上万 Token 的 System Prompt 不同，Pi 的 Prompt 加起来不到 1000 Token。

现在的 Frontier Models（前沿模型）已经经过了大量的 RL（强化学习）训练，它们天生就懂如何写代码。你不需要教它“你是一个资深的工程师”，你只需要给它工具。

工具集：只要这 4 个就够了

Pi 没有为每种操作都封装专门的工具（如 create_file, delete_file, search_code），而是回归了 Unix 哲学。

它只提供了 4 个原子工具：

• read: 读取文件。
• write: 覆盖/创建文件。
• edit: 基于字符串匹配的精确修改（Surgical edits）。
• bash: 执行任意 Shell 命令。

模型非常擅长使用 Bash。为什么要封装一个 ls 工具？直接让模型运行 ls -la 就好了。为什么要封装 grep？模型自己会写 grep 命令。这种设计不仅减少了 Token 消耗，还赋予了 Agent 无限的灵活性。

安全哲学：YOLO 模式 (You Only Look Once)

现在的 Coding Agent 充斥着“安全剧场（Security Theater）”。它们试图拦截每一个文件读写操作，或者限制网络访问。

但作者指出：一旦你允许 Agent 写代码并运行代码，游戏就结束了。Agent 完全可以写一段 Python 脚本来绕过所有的文件系统沙箱。

Pi 的选择是：完全信任（Full Trust）。

• 没有权限拦截。
• 没有命令预检查。
• 完整的网络和文件系统访问权限。

与其做无用的防御，不如让开发者在隔离环境（如容器或虚拟机）中运行 Agent。

拒绝“过度工程化”

• No Built-in To-dos: 任务列表应该存在于 TODO.md 文件中，而不是 Agent 的内存里。文件是最好的持久化。
• No Plan Mode: 所谓的“规划模式”往往限制了 Agent 的灵活性。Pi 鼓励通过对话和 Markdown 文件（PLAN.md）来进行持久化的规划。
• No MCP Support: 作者认为 MCP（Model Context Protocol）对于大多数用例来说是“杀鸡用牛刀”。像 Playwright MCP 这种服务，一上来就往上下文里塞 13k Token 的工具描述，极其浪费。Pi 的替代方案是：CLI 工具 + README。Agent 需要用什么工具，就读那个工具的 README，然后用 Bash 调用。这是最自然的渐进式披露（Progressive Disclosure）。

放弃后台 Bash，拥抱 tmux

Claude Code 试图在后台管理耗时的进程（如开发服务器），但处理得并不好，且缺乏可观测性。

Pi 的解决方案极其极客：使用 tmux。

如果 Agent 需要运行一个长时间的 Server 或调试器（LLDB），它会直接在 tmux 会话中启动。用户可以随时 Attach 到这个会话中查看日志、接管调试。这是最高级的可观测性。

实战效果与基准测试

这种“简陋”的架构真的行吗？数据说明了一切。

在 Terminal-Bench 2.0 基准测试中，使用 Claude Opus 4.5 的 Pi Agent：

• 排名第 7，仅次于经过重度优化的 Codex CLI 和商业化产品 Warp。
• 击败了 OpenHands, SWE-Agent 等著名的开源 Agent 框架。
• 准确率达到 49.8%，与排名第一的 Codex CLI (60.4%) 差距并不大，考虑到代码量的巨大差异，这是一个惊人的成绩。

更有趣的是，测试中表现优异的 Terminus 2 也是一个极简 Agent——它只给模型一个 tmux 会话，没有任何其他工具。这强有力地证明了：对于强大的模型来说，最原始的接口（Terminal）往往是最有效的。

小结：构建属于你的 Agentic Workflow

Pi (OpenClaw的内置Agent) 的故事告诉我们：在 AI 时代，软件工程的护城河不在于你堆砌了多少功能，而在于你对模型能力的深刻理解和对架构的极度克制。

• 透明胜过黑盒：让记忆和计划变成可见的 Markdown 文件。
• 通用胜过专用：Bash 是 Agent 与世界交互的通用语。
• 极简胜过繁杂：每一个多余的 Token 都是对模型智商的侮辱。

如果你厌倦了现有工具的笨重与封闭，不妨参考 Pi 的思路，利用 pi-ai 这样的基础设施，去构建一个真正懂你、且完全受你掌控的 Coding Agent。

这不只是造轮子，这是在定义 AI 时代的“开发者尊严”。

资料链接：

• https://mariozechner.at/posts/2025-11-30-pi-coding-agent/
• https://github.com/badlogic/pi-mono

你认为 AI 工具该“重”还是“轻”？

面对日益臃肿的 AI 插件，你是否也渴望回归那种“只有 4 个工具”的极简掌控感？在你的开发流中，有哪些功能是你觉得完全多余、甚至干扰了你的“心流”的？你认同“完全信任（YOLO）”这种安全哲学吗？

欢迎在评论区分享你的极客观点！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。