智能体读写本地文件正成为常态，GitHub Copilot 补齐了本地沙盒与 OTel 监控这两块企业级底座。
它把智能体的执行轨迹和破坏半径同时纳入了企业管控视线。你下半年在内部推行 Agent 落地时，安全合规部门的阻力会小很多。
核心看点
- 通过 OpenTelemetry 实现智能体会话的逐步跟踪与集中监控，打破执行黑盒。
- 引入本地沙盒机制，按项目限制文件系统、网络和凭证访问，物理隔离意外命令。
- 企业托管设置支持跨团队统一下发策略，操作系统无法强制执行时直接报错阻断。
▎打破黑盒与物理隔离的双轨并行
管理员现在可以将智能体活动数据发送到组织兼容的监控工具。这套基于 OpenTelemetry 的框架允许团队跟踪会话流程，包括对 AI 模型的请求和工具调用。你可以审查智能体执行的逐步轨迹，调查意外行为。在隐私保护方面，prompt 和 response 内容默认被排除，启用前需审查内容捕获设置。配置方式是在企业的 managed-settings.json 文件中设置 telemetry 属性并指定端点。
本地沙盒则从物理层面限制了智能体的破坏力。它按项目配置，限制对文件、网络资源和凭证的访问。文件系统支持设置额外读写、只读和拒绝列表；网络控制出站互联网和本地网络；凭证管理 Git HTTPS 和 GitHub CLI 认证。
企业在引入智能体时，面临效率与安全的跷跷板。过去为了安全，企业往往选择云端沙盒或完全禁用本地执行，导致智能体无法访问本地代码库。GitHub 这次提供的本地沙盒方案给出了新的决策框架：在本地环境内划定安全区。对于核心代码库设置拒绝列表，对于需查阅的文档设置只读，对于需修改的配置文件设置读写。这种细粒度控制让安全团队不再需要一刀切地否决本地智能体方案。
▎沙盒策略与监控配置的实操拆解
理解这两项功能的生效边界，是避免生产环境踩坑的前提。以下是核心配置策略的拆解：
- 本地沙盒仅适用于本地仓库和工作树会话，不适用于云沙盒或远程主机。
- 应用设置中的沙盒开关仅对新会话生效，对活动会话需输入 /sandbox on 开启。
- GitHub Copilot app 和 Copilot CLI 的沙盒设置是分开配置的。
- 如果操作系统无法强制执行请求的策略，沙盒 shell 会直接报错，而不是在无沙盒状态下运行。
任何安全机制都有其适用边界。本地沙盒的生效前提是操作系统能够强制执行请求的策略。如果你的开发环境操作系统存在权限漏洞或配置冲突，无法落实这些策略，系统会直接让沙盒 shell 报错。这意味着在老旧或高度定制化的企业内网开发机上，可能会频繁遇到沙盒启动失败的问题。此外，本地沙盒目前仍处于 public preview 阶段，策略细节可能会发生变化。企业在全面推开前，必须先在非核心项目组进行灰度测试，验证操作系统兼容性。
▎配置指南与官方文档索引
要启用本地沙盒，打开应用设置，选择你的项目，在 Sandbox 下开启 Sandbox new sessions。这会应用于项目中的新会话。文件系统、网络和凭证设置的更改将应用于新会话或现有会话重启时。要为企业团队集中管理监控，请在 managed-settings.json 中配置 telemetry 属性。
OpenTelemetry 监控配置指南：
企业托管设置入门：
本地沙盒配置详情：
从行业走向来看，GitHub 的这两个动作释放了一个明确信号：AI 智能体的竞争焦点，正在从模型智商转移到企业级管控力。当所有大厂都在卷参数和推理速度时，谁能率先提供一套让 CIO 和 CISO 放心签字的管控基础设施，谁就能拿下企业级市场的真金白银。OTel 解决了出了事能查的审计需求，本地沙盒解决了出事也破坏不了的兜底需求。对于正在评估智能体落地方案的决策者来说，不要只盯着模型跑分，把管控工具链的成熟度纳入核心评估指标，才是避开生产事故的关键。
点个赞再走？
你在本地跑智能体时，敢直接放开文件读写权限吗？
往期推荐
- ·Claude Opus 5.5陷过度思考，单次失败烧掉2.56美元
- ·美财长确认两月内跟进，中美AI热线防Agent失控
- ·
点击公众号头像 → 历史消息，可翻阅以上文章
