严肃的AI用户是想要一个订阅，还是一个连接所有提供商的本地应用？

全面声明：我是 KeyRing AI 的创始人，这是一款用于跨多个 AI 提供商工作的本地优先桌面应用。目前这不是开源的，所以如果这让文章对某些人来说不那么有用，我能理解。**我在此分享架构/经验教训，而不是要求任何人注册。** 核心架构决策是避免成为提示中继。桌面应用在本地存储提供商凭据，在用户机器上运行编排层，并直接从用户机器向提供商 API 发送请求。网站不在 AI 请求路径中。它处理商业/分发流程，如账户、许可证验证、下载和更新。 **这种分离带来了一些技术限制：** 1. *提供程序适配器需要通用的内部结果形状，而不会抹平提供程序特定的功能。* 2. *工具定义必须按提供程序进行翻译，而不是内联手动构建。* 3. *流式和非流式响应需要兼容的规范化，以便 UI 可以一致地处理它们。* 4. *本地历史记录必须在不将对话状态发送到中央后端的情况下有用。* 5. *许可证必须能够在不强制通过许可服务器发送提示的情况下执行。* 许可部分是其中更有趣的经验之一。普通的 SaaS 可以在每个服务器请求上强制执行访问。本地优先的应用不能依赖这种模式。我采用的方法是服务器端许可证验证，然后是一个短期有效的 Ed25519 签名授权信封。在运行受保护的提供程序工作流之前，桌面端在本地验证签名、签发者、受众、机器绑定和有效期。 **目前的限制：** * BYOK 设置仍然比普通 Web 登录更麻烦。 * 提供程序 API 不会统一公开功能，因此能力映射是持续进行的工作。 * 本地优先并不意味着仅本地推理；许多请求仍然发送到云 AI 提供商。 * 跨提供程序比较很有用，但如果用户盲目启用所有功能，可能会变得昂贵。 文档/上下文： [https://keyringlabs.com/docs](https://keyringlabs.com/docs) [https://keyringlabs.com/architecture](https://keyringlabs.com/architecture) 对于那些构建过 AI 客户端或提供程序抽象层的人：在无中继、多提供程序桌面架构中，你们会最密切关注哪些故障模式？