混合 AI：在本地与云端之间选择，同时掌握数据控制权

混合 AI 是一种将本地设备或基础设施上运行的模型，与通过云服务访问的模型相结合的架构。 系统根据数据的性质、所需的输出质量和可用资源，将任务交给合适的环境处理。用户可以手动选择，也可以由路由系统按照既定规则分配。

例如，开发助手可以使用本地模型为保密代码生成测试，再通过获准使用的云服务分析公开文档。两个环境属于同一个工作流程，但并不需要同时处理每一个请求。其价值在于为任务和企业约束选择合适的能力，而不是把所有工作都交给同一个模型。

设想一个团队需要修复客户应用中的一个模块。代码包含专有业务逻辑，助手能够读取文件、提出修改并运行测试。在开始之前，团队需要明确：助手可以使用哪些信息，这些信息可以在哪里处理，以及如何验证结果。

先确定数据边界，再选择模型

团队规定，客户代码只能在本地设备或获准使用的企业基础设施上处理。公开文档则可以发送给经过批准的外部服务。凭据不应进入助手的上下文。

这些规则先于模型质量评估，限定了可选范围。如果本地模型无法解决问题，自动将代码仓库传给外部提供商，就会越过已经确定的边界。可行的替代方案包括使用获准的企业服务、准备不含保密信息的示例，或交由开发者接手。

路由应在获准的目标之间作出选择，而不是在任务变难时绕过约束。 路由是指按照既定标准，将请求分配给不同模型。任务复杂度只是其中一个标准，数据保密要求和可用资源同样重要。

将模型接入开发流程

GitHub Copilot CLI 的本地模型选择功能提供了一个实例。GitHub 于 2026 年 10 月 7 日发布的公告说明，开发者可以通过已经运行的 Ollama 实例发现模型，并在当前会话中使用。

团队需要单独安装运行时和模型，确认服务端点，并选择支持流式输出和工具调用的模型。手动选择与自动路由是不同的能力：同一公告还提到了结合本地模型的智能路由，并提示关注其可用性信息。因此，团队应核实当前配置实际支持的功能，而不能将二者视为等同。

对于客户模块，第一步可以是明确选用一个本地模型。只有在团队清楚它能处理哪些请求、哪些任务需要其他获准资源之后，才适合考虑自动选择。

同时控制工具的行为

本地模型提出修复方案后，助手可能运行一个会下载依赖或连接外部服务的命令。虽然推理发生在本地，整个工作流程仍然可能产生网络流量。

GitHub 明确指出，选择本地模型不会自动开启离线模式，也不会关闭遥测。即使 CLI 启用了离线设置，配置为目标的远程提供商仍然可能接收上下文。因此，服务端点、遥测和工具连接需要分别检查。

Copilot 的本地沙箱可以按照应用的策略，限制文件、网络和其他系统能力的访问。在这个场景中，团队可以允许读取目标模块和运行测试，同时限制访问其他目录和网络目标。

保密性取决于数据经过的完整路径：模型、工具以及所连接的服务。 为助手提供工具或数据源的 MCP 服务器，也应纳入相同的检查范围。允许处理一个文件，并不意味着允许把它传出去。

比较最终完成的工作

确定边界后，团队可以让本地模型和一个获准的企业服务处理同一任务。主要指标是得到正确且经审核批准的修改所需的时间，而不只是生成速度。

评估应包含通过的测试、需要返工的内容和审核时间。开发者还要确认测试是否覆盖真正的需求：测试套件运行无误，并不代表它验证了客户关心的行为。

资源也属于同一项评估。规划机器容量时，需要一起考虑模型权重、上下文内存和运行时消耗。量化可以减少内存占用，但是否值得采用，取决于输出质量与硬件兼容性。

成本还包括硬件、能源、维护和团队投入的时间。使用配额则取决于产品条款。如果本地结果需要大量修改，其总体价值可能不如能够正确完成工作的获准远程服务；反之亦然。

选择能力，保留责任

对于团队而言，本地与云端之间的选择，只有在保护客户代码并帮助交付可靠修改时才有意义。模型可以更换，但数据约束以及谁负责批准结果，必须始终清楚。

这让关注点从单个模型的能力，转向使用模型的整个系统的质量。企业能够采用更合适的能力，同时保留自己的规则、避免隐含的数据传输，也不必每次都重新建立验证流程，才拥有更大的自主性。

混合 AI 的价值不在于拥有更多模型，而在于能够自主选择如何使用这些模型，同时保留对自身工作的控制。 相比模型所处的位置，这种有依据的选择能力，才更能使 AI 成为企业可靠的资源。