Copilot 工具受限时，应先核对执行策略；Ollama 模型接入时，要另查发现条件。换成本地模型，并不自动改变工具权限或离线状态。GitHub 同日公布的本地沙箱与模型发现更新，适合放在一起核对，但不能合并成一个"本地运行就已安全"的结论。
本地沙箱限制的是哪一层？
据 GitHub 官方公告，2026-10-07 的本地沙箱发布说明确认，该能力已在 Copilot CLI、Copilot 应用和使用 Agent Host 的 VS Code 会话中正式可用。这里的 VS Code 范围带有 Agent Host 条件，不能省略限定后写成所有 VS Code 会话都具备相同行为。
公告说明，该能力由 Microsoft eXecution Container（MXC）驱动，把共同的沙箱策略转换为 Windows、macOS 和 Linux 的原生操作系统控制。它约束的是 Copilot 发起的工具和命令：文件系统、网络、凭据等能力的访问，按开发者或组织定义的策略受到限制。
因此，工程核对的对象应是"这个工具任务需要访问什么、应受哪些策略约束"。公告支持跨平台策略这一层事实，却不能据此补出某个策略文件路径、网络白名单字段或错误代码。也不能倒推更新前的任务一律拥有完整系统权限。
企业还可以通过托管设置要求使用沙箱，并施加开发者无法弱化的策略。对团队而言，建议先把组织要求和个人使用选择分别记录，再确认当前入口与任务是否落在已明确的范围内。这是核对顺序，不是本文替组织规定一组新的配置键。
一个有用的判断是：工具受限与模型能力不足需要分开记录。前者涉及任务允许访问的资源，后者涉及模型能否承担调用要求。只有出现"无法完成"的表象，还不足以选定其中一个原因，更不应立即扩大权限来试探。
文件夹、线缆与钥匙置于同一围栏内，分别示意三类访问对象。
Ollama 被发现前需要哪些条件？
GitHub 模型发现官方公告给出的起点是 CLI 1.0.94-0：通过 /model 可以发现正在本地运行的 Ollama 实例里受支持的模型，和已配置模型、GitHub Copilot 提供的云端模型一起选择。这个版本与入口说明针对 CLI，不能直接移植成其他客户端的操作教程。
发现流程要求 Ollama 和目标模型已经安装；它不会代为安装运行时或下载模型。受支持的模型还必须具备工具调用和流式传输能力。只看到某个模型能回答普通问题，不能替代对这两项条件的核对，也不构成发现失败原因已经查明的证据。
建议先记录实际使用的 CLI 版本、Ollama 运行情况、目标模型及其能力说明，再观察 /model 返回的模型列表。这样可以把环境条件与实际观察放在一起；若模型没有出现，先保留看到的现象，不凭本文推定某个错误码或内部失败分支。
如果任务已从个人试用进入业务上线，可以把AI 系统上线前检查作为整体就绪自检的入口；本次产品变更的事实判断仍以两篇官方公告为依据。自检结果不能代替当前环境的回读，更不能证明某条沙箱策略已实际生效。
公告还说明，新发现的模型可以在当前会话中使用，无需重启 CLI。这个便利性只回答会话切换问题，并不附带模型质量、任务成功率或安全隔离效果的保证。对已有工作流，建议保留切换前后的同一任务条件，分别确认模型是否可选、任务是否满足原定验收要求。
换了模型，哪些事项仍须分别核对？
下面把明确的官方规则与读者动作分开。事实列保留原意，动作列是建议的人工核对，不代表厂商已经提供同名检查器，也不是运行结果。先看当前问题落在哪一行，再决定需要补哪类观察。
| 对象或条件 | 来源已确认 | 判断或核对 | 依据 |
|---|---|---|---|
| 工具执行边界 | 沙箱策略独立于模型执行，无论 Copilot 使用哪个模型，策略均应用于工具执行 | 核查当前工具任务的策略要求，不用模型位置推断权限。 | 沙箱官方公告 |
| 模型能力门槛 | 支持的模型必须支持工具调用（tool calling）和流式传输（streaming） | 核查已安装模型对这两项能力的支持，不以能聊天代替核验。 | 模型发现官方公告 |
| 本地与离线 | 选择本地模型不会自动开启离线模式或禁用 GitHub 遥测功能 | 区分模型选择与离线要求，单独记录本次任务的离线设置。 | 模型发现官方公告 |
沙箱公告明确，策略应用于工具执行，不取决于 Copilot 使用哪个模型。因此，不能把"模型已经换到本地"当成解除工具访问限制的理由；同样，也不能把一次成功调用当成所有权限边界都已验证。模型选择和工具授权应各自留下核对结果。
模型发现公告则说明，选择本地模型不会自动启用离线模式，也不会自动禁用 GitHub 遥测。CLI 的离线模式需要显式设置 COPILOT_OFFLINE=true。本文只引用这个启用方式，不据此推导全部网络行为或遥测拦截效果；有具体离线要求时，应单独确认该要求的验收范围。
这张表适合用来区分待核对事项，而不是给环境直接打"安全通过"。例如，已确认模型支持工具调用和流式传输，说明能力条件有了依据；组织策略如何限制该任务，仍是另一项核对。把两项合成一个勾选框，会丢失问题究竟在哪一层的信息。
无字木块与拨杆开关并置，示意模型选择与离线设置需要分别核对。
哪些结论还不能直接用于上线判断？
同一篇模型发现公告还宣布了支持本地模型的智能路由。本文引用的说明没有展开路由选择和失败处理细节，所以这里不推导它如何分配任务，也不把手动 /model 选择说成"当前唯一可靠入口"。若工作流要依赖智能路由，应先补齐相应使用说明和实际验收结果，再作选择。
沙箱失败后的回退路径、策略冲突的处理顺序，也不能从跨平台支持这件事直接推出来。建议把这些问题列为待核验项：需要什么行为、依据在哪里、当前环境观察到了什么。资料不足时保留未知，不在文档或图注里写成"必然终止"或"绝不回退"。
对一次被拒绝或结果不明的工具任务，建议保留实际观察并由负责人复核。复核的目的是确认原有任务与授权是否匹配，而不是为了让任务继续执行就改宽策略。若还没有足以支撑上线决定的证据，应缩小试用范围，避免把尚未验证的判断带入业务运行。
需要把这类 Agent 接入真实业务时，生产就绪审查应先明确任务范围、权限要求与验收证据。建设交付和持续技术顾问工作，再围绕已确认的缺口展开；一份产品更新对照表不能替代这些现场核验。