我们为多模型智能体构建了一个小型网关——难点在于流式处理和工具调用

我一直将提供商切换视为模型选择问题。结果变成了一个集成问题。我们的编码智能体和自动化工作流根据任务使用多个提供商：Claude用于长上下文，GPT用于一些编码任务，其他模型则用于成本、延迟或可用性。起初，每个应用都有自己的提供商适配器。这方法一直有效，直到我们运行的智能体足够多，以至于边缘情况变得比模型选择本身更昂贵。问题主要围绕边界：- SSE数据块并不总是与消息或JSON边界对齐；- OpenAI的`tool_calls`和Claude的`tool_use`块以不同形式承载类似信息；- 提供商为类似的故障返回不同的状态码、错误主体和完成原因；以及- 当每个项目都有单独的密钥和计费视图时，使用量核算变得难以协调。因此，我们为自己的工作流构建了一个小型网关。应用程序与一个统一的契约通信，提供商特定行为在网关边界处终止。当前设置有两条兼容的请求路径：- OpenAI兼容的Chat Completions，用于现有SDK和智能体框架；- Claude Messages兼容的请求，用于需要Anthropic内容块格式的应用程序。在这些端点之后，网关当前处理：- 规范化的SSE事件和使用量元数据；- OpenAI工具调用和Claude工具使用块之间的转换；- 提供商特定的错误规范化；- 动态模型配置和路由；以及- 在一个控制台中管理API密钥、预付余额和使用量跟踪。仍然需要最多测试的部分不是正常路径。而是部分流式传输后的重新连接、保存原始提供商事件用于调试，以及确保重试或回退不会使成本核算产生误导。