Busbar

每一个严肃的 AI 应用都在走向多模型、多供应商的架构。你希望用 Claude 处理一类任务，用 GPT 处理另一类，用便宜模型做分类，还要在主模型被限流时有一个备用方案。一旦你对接了不止一个供应商，就必须在你的应用和它们之间架设一层中间件——也就是网关。

如今市面上的网关大多只做两件事：把所有供应商统一适配成 OpenAI 的接口格式，以及在失败时进行重试。两者都在悄无声息地损耗信息。而且它们都算不上真正的 AI 控制平面。

适配成 OpenAI 格式，会丢掉每个供应商真正值得使用的特性：Anthropic 的思维块、Gemini 的安全设置、Bedrock 的工具调用封装。你获得了可移植性，却以能力为代价。

失败重试只是错误处理，并非故障转移。调用抛出异常，然后某个东西再重试一次，而此时你的用户已经感受到了卡顿。而且一次盲目的重试可能会猛击一个本已宕机的供应商。

这两件事本身没有错。只是当网关成为承载关键任务的基础设施时，它们远远不够。

我正在构建的东西

Busbar 就是你的 AI 控制平面

无损翻译，双向贯通。输入端支持六种线协议中的任意一种，输出端对接任意供应商，中间通过一个超集化的中间表示进行转换，使各家的原生特性在跳转中得以保留，而不是被压平抹去。

请求内部完成故障转移。在客户端看到任何字节之前，就能在不同供应商之间重新路由——甚至在流式传输中途也可以，全程受截止时间和跳数预算约束。用户永远不会察觉到那一瞬的踉跄。

一个懂得区分责任归属的熔断器。对每一次失败进行分类（供应商宕机、你的请求有误、超出上下文长度、认证或计费问题），并对症下药，而不是一味撞南墙式地重试。

一个静态的 Rust 单文件二进制。没有 Python sidecar，没有解释器，请求路径上没有 GC。密钥归你，网络归你，数据通路归你。

为什么是我，为什么是现在

多模型架构今年正在走向主流，而控制平面正是可靠性和可移植性承诺能否兑现的关键所在。我认为正确的架构应当以可靠性为先、以无损为目标，而不是模仿 OpenAI 的形态、依赖简单的重试机制。我宁愿从底层金属级开始打造这一切，也不愿把它当作一个解释型代理的补丁硬塞上去。