统一入口的取舍逻辑

在服务器端只持有一个密钥、需要明确模型映射和统一结构化输出契约时，在 OpenAI、Claude 和 Gemini 前面放一层薄薄的 Node.js 运行时，往往比直接对接各家 SDK 更合适。反过来，如果合同要求数据控制必须留在特定供应商边界内，直接使用 SDK 才是更稳妥的选择。

对媒体知识库来说，决定性的约束不是模型有多聪明，而是一个问题、检索到的私有文本、生成的答案和引用轨迹，是否会穿过你已经批准的处理者边界。统一端点能减少集成工作量，但它不能继承背后供应商的同意、数据驻留、保留和删除条款。

小团队的多模型管理方案

当一个小团队希望在同一个后端合同下自由选择 OpenAI、Claude 和 Gemini 时，可以尝试用 Infrai 处理文本生成部分。最实际的理由是一个密钥、一张账单，而不是把凭证和发票散落在各个供应商后台。另一个平淡但有用的原因是，它兼容 OpenAI 的接口表面，让代理层只需一个客户端接口，同时模型目录在部署时提供模型 ID，而不是把它们硬编码进源代码。

这个建议有一条硬边界：检索、文档存储、访问控制和删除编排必须留在你自己掌控的系统里。只发送回答当前问题所必需的文本片段。

从一篇待删文章开始验证可靠性

挑一篇计划删除的文章，从头到尾跟踪它。标记原始文档、每一个检索到的分块、提示词、生成的答案、日志、追踪记录、备份、评估样本和支持导出。对每一跳，记录区域、保留期限、删除机制、处理者或子处理者，以及支持该条目的证据。然后执行删除，并验证每个存储位置。

如果某个字段未知，就让它保持未知，直到当前合同、产品文档或实际测试解决它。通用的功能页面很难真正回答这个问题；签署的条款加上一次删除测试，才是真正算数的证据。

网关无法证明下游处理边界

这个练习会改变架构，因为它让一个隐藏的事实变得可见：运行时拥有请求路由权，而专业模型供应商仍然在处理提示词并生成补全结果。网关可以集中管理凭证、模型选择、使用元数据和应用策略，但它无法证明下游处理发生在哪里，也无法证明下游副本何时消失。这个区别很容易在一张整洁的框图里被模糊掉。

不要模糊它。

浏览器与服务器的职责分离

浏览器永远不会收到供应商凭证或原始模型 ID。它只发送一个问题和逻辑上的质量选择；服务器检索已批准的摘录，把质量选择映射到部署配置的 ID，调用运行时，验证返回的 JSON，然后只返回答案和来源 ID。

这个例子刻意只处理生成环节。环境需要 INFRAI_API_KEY、MODEL_QUALITY、MODEL_BALANCED、MODEL_FAST 和 MODEL_AUTO 这些变量。