本文作者：李玉涛（Leo），长春师范大学 数据科学与大数据技术专业 2027 届本科生，辅修数学双学位。 个人主页：一.chat（xn--4gq.chat）｜ GitHub：Leo-Li638（github.com/Leo-Li638）
最近翻 AI 行业的周报，有个趋势几乎刷屏：各家 coding agent 正在集体从「弹窗问你」转向「关进沙箱」。GitHub Copilot 的本地沙箱正式可用，Kiro 把 agent 的 shell 命令搬进操作系统级沙箱，Google Antigravity 上线了自动放行安全操作的 Auto 模式，微软甚至给 agent 发了 Microsoft 365 账号------最新的「同事」有了自己的登录名。
作为一个自己折腾浏览器自动化和本地 AI 平台的人，我认为这是今年比「模型又变强了」更值得关注的工程变化。
一、旧方案的问题：许可弹窗是个「替身」
过去主流的安全设计是：agent 每次要执行命令，先弹窗问用户「可以吗？」。听起来很稳妥，实际用起来两头难受------
- 对用户：一天点几十次「允许」，最后变成无脑全点「允许」，安全形同虚设；
- 对 agent：每一步都要等人拍板，多步任务被切成碎片，效率崩掉。
弹窗的本质问题在于：它把「边界」这个本该由系统保证的东西，外包给了人类的耐心。
二、新方案：把墙砌进操作系统
这波变化的核心思路是：先用 OS 级沙箱把 agent 能碰的文件、网络、凭证圈死，然后才允许它少问或不问。行业周报里的几个实例：
- GitHub Copilot：本地沙箱正式可用，agent 能访问哪些文件、网络、凭证，由开发者或组织策略统一设定；
- Kiro CLI：shell 命令跑在操作系统沙箱里，出站网络默认封锁；沙箱开启后，自主模式干活不再逐条询问；
- Google Antigravity ：Auto 模式自动批准文件编辑和安全命令，但不可逆操作前必须停下，出沙箱的命令还要先过一道独立审查 agent；
- 微软：直接给 agent 配了 M365 账号------它要接任务、要被「离职回收」，已经是正式员工待遇了。
一句话总结这个新范式：问题从「它多久问一次」变成了「它不问的时候，能碰到什么」。
三、为什么这事对个人开发者也重要
我自己写浏览器自动化脚本时吃过同样的亏：一个自动发布脚本，第一次跑的时候差点把测试数据发到正式环境。那次之后我给自己立了几条规矩，回头看和行业趋势完全同构：
- 环境分离：测试账号和正式账号物理隔离，脚本只能拿到其中一套凭证------对应沙箱的「凭证不出圈」；
- 不可逆操作必须有人工确认点：删除、发布这类动作，脚本跑到这一步必须停下来等人------对应 Antigravity 的「不可逆前必停」；
- 能力清单显式化：把「这个 agent 能做什么、绝对不能做什么」写成文档------我沉淀的那些 SKILL.md，本质上就是给 agent 的行为边界说明书。
沙箱化不是大厂的专利，「先划边界、再给自主权」这个顺序，任何自己搭自动化的人都应该照抄。反过来说：一个向你承诺「全自动、无需确认」却不提供任何边界机制的工具，是在要信任而不给墙------慎用。
四、接下来值得盯的两件事
- 自主权会不会随沙箱捆绑销售：已经有厂商把「开自主模式」和「开沙箱」做成绑定选项。如果成为行业惯例，「有没有 OS 级边界」会变成选型 agent 工具的硬指标。
- agent 身份管理：有了账号就要有权限治理、审计日志，甚至「离职流程」。这是企业级 IAM（身份与访问管理）向 agent 的整体迁移，相关工程岗位需求大概率会涨。
写在最后
Agent 的自主性在涨，但这次行业选择的路线不是「更聪明的 AI 更少犯错」，而是「先修墙，再放权」。对正在搭自己自动化系统的人来说，这个顺序值得直接抄进自己的工程里。
我的自动化实践和踩坑记录都整理在个人主页 一.chat （xn--4gq.chat） 上，代码在 GitHub（github.com/Leo-Li638）。...
李玉涛（Leo）· 长春师范大学 · 数据科学与大数据技术 + 数学双学位 · 2027 届