AI 编程助手能自己跑命令了，它到底能碰到你什么

「AI 编程助手现在能自己跑命令了」这句话，在三家官方文档里指的不是同一件事。有的指它能读你的文件，有的指它能在你点过同意之后执行一条命令，有的指它可以在你不在场的时候把测试跑完、把分支推上去。把这几件事混在一起谈「自主度」，结论一定是错的。

更麻烦的是，真正决定「它能碰到你什么」的东西，往往不在功能介绍页，而藏在两个没人主动去点的角落：运行模式（Cursor 叫 Run Modes，Claude Code 叫 Permission modes）和沙箱配置。前者决定哪些动作需要你点同意，后者决定在没有你同意的情况下，一个命令最远能走到哪里。这两件事在官方文档里是分开写的，而且默认值经常和直觉相反。

这篇只做一件事：把 Cursor、Claude Code、Devin 三家官方文档里关于「可自动执行的动作」「是否需要逐步确认」「沙箱隔离范围」的声明，按同一套标准排到一条光谱上。本文没有做任何本地实测，所有结论都来自官方页面原文；官方页面没有写的地方，本文直接写「官方未披露」，不填推测值。数据于 2026 年 9 月 24 日重新核对。

本文方法：官方公开数据交叉核对，未做本地实测。所有数字均标注来源，核对日期见文末。

一、能力侧：官方声明里，哪些动作可以不经你确认就执行

先把三家官方文档里「明确写了可以自动执行」的动作列出来。这张表里没有一行是本文的推测，全部是官方页面的原文表述；「是否需要逐步确认」这一列也是官方自己写的，不是本文推断的。

这张表里有四处值得单独拎出来。

第一，Cursor 的默认档已经自动批准了文件写入。官方原文是「Agents can modify workspace files without approval, except for configuration files. Changes save immediately to disk.」需要你同意的只有配置文件。官方在同一页还配了一句警告：如果你开了自动重载，「agent changes might execute before you can review them」——改动可能在你审阅之前就已经被执行了。

第二，终端命令是另一回事。官方原文：「By default, terminal commands need your approval.」MCP 是最保守的一环：「All MCP connections need your approval. After you approve an MCP connection, each tool call still needs individual approval before running.」网络请求也被收紧了——默认情况下工具只向 GitHub、直链抓取和搜索服务发请求，官方原文是「Agents cannot make arbitrary network requests with default settings.」

第三，Claude Code 的默认档正好相反。Manual 模式下「Claude Code starts with read-only permissions」，改文件、跑能改动系统的命令之前都要问你。但这里有一个几乎没人注意的默认值差异：官方在权限模式文档里写明，「On Pro, Max, and Team plans, the built-in starting permission mode is auto mode.」，而 Enterprise 计划或使用 Claude Console API key 的会话，内置默认档是 Manual。同一个工具，个人订阅用户默认进入自动模式，企业用户默认进入手动模式。官方没有解释这个差异的原因，只说明内置默认档取决于运行方式、套餐和功能开关的获取情况。

第四，Devin 这一类「云端自主代理」在官方文档里的表述方式完全不同。官方对能力的描述很直接：「Devin is an autonomous AI software engineer that can write, run and test code.」Workspace 的 Shell 面板被描述为「where you can watch commands being executed and view output logs」——是「观看」，不是「逐条批准」。但本文在 Devin 的官方文档与定价页中未核到关于逐步确认机制、沙箱文件系统边界的声明，因此这一行只能留白。这不是 Devin 做得更差，而是「官方没写」和「官方写了没有」是两件事——这一点对做安全评估的人来说，本身就是需要记录的信息。

二、边界侧：四个真正把 agent 拦住的地方

能力侧讲的是「它能做什么」，边界侧讲的是「什么情况下它做不成」。这一侧的信息更分散，官方把它们放在沙箱配置、网络策略和企业管理控制三处。下表按同一个维度横向对齐三家。

把这张表竖着读一遍，会看到三条官方自己写下的限制，比任何第三方评测都更有说服力。

边界一：沙盒不是硬边界，官方自己承认。Cursor 在 Run Modes 文档里把三种模式定义完之后，专门用一个小标题写了「Auto-review is not a security boundary」，正文是：「The classifier can make mistakes. It can allow a call you would have blocked, or block a call you would have allowed.」在 Agent Security 页，官方对整组运行模式的定性是「best-effort guardrails rather than a hard security boundary」。Claude Code 那一侧的措辞不同但方向一致：沙盒文档里写着「Sandboxing reduces risk but is not a complete isolation boundary.」

边界二：读写权限是不对称的。这是整张表里最容易被忽略的一格。Claude Code 的沙盒默认只允许写工作目录，但默认可读整台计算机，官方甚至主动提醒这会允许读取 ~/.aws/credentials 和 ~/.ssh/，并给出对策：用 sandbox.credentials 阻止读取这些文件，或把它们加进 denyRead。Cursor 的做法不同——它默认允许读取，但用 .cursorignore 让 agent 看不见指定文件，同时把 .git/config、.git/hooks 这类路径直接列进受保护清单。「防写」和「防读」是两套完全不同的配置项，只做前者等于没设边界。

边界三：云端与本地走的是两套默认值。Cursor 的本地前台 agent「requires user approval for every command」，而它的 Cloud Agent「auto-runs all terminal commands」。官方在同一页把风险写得很清楚：「Auto-running introduces data exfiltration risk: attackers could execute prompt injection attacks, tricking the agent to upload code to malicious websites.」并且 Cloud Agent 的网络默认是开放的——「The agent has internet access by default.」相比之下，Claude Code 的云会话是反过来的：「Network access is limited by default and can be configured to be disabled or allow only specific domains.」同样是云端跑 agent，一家的默认是「能上外网」，另一家的默认是「不能」。这个差异在采购对比表里通常不会出现。

还有一条不属于沙盒、但同样构成边界的限制：并发会话上限。Devin 官方对比表里，这一行的 Free 列是不可用标记，Pro 与 Max 各为「Up to 10」，Teams 与 Enterprise 为「Unlimited」。官方没有解释为什么单席位上限恰好是 10，但这意味着在 Pro 档上，你一次最多让 10 个会话同时跑。速率与并发上限这类限制平时被当成性能参数，实际上它决定了「一个 agent 出问题时能波及多大范围」。

三、把九个档位排到同一条光谱上

上面两张表是分工具看的，接下来换成按自主度分级看。分级标准是本文自己定的，规则只有一条：不看工具宣称有多强，只看官方文档里「哪些动作需要你先点同意」。五级的定义如下，图中每一行都对应官方文档里的一段原文。

• 1 级：只做代码补全，不读仓库内容
• 2 级：可读文件与检索，写文件、执行命令都需要逐步批准
• 3 级：自动修改工作区文件，命令仍需批准
• 4 级：命令可在受限沙箱内自动执行，高风险动作交分类器或直接拦截
• 5 级：命令与提交全自动执行，不逐步向你确认

这张图最值得看的是第一行和第四行的距离。同一个 Cursor，本地默认档和云端 Agent 之间跨了两级——从「终端命令要你批准」直接跳到「从不请求批准」。而如果按厂商来比，会得出「Cursor 比较保守、Devin 比较激进」这种粗糙结论；按档位来比才会发现，决定风险的不是厂商，是你打开的是哪一个模式。

第二个值得注意的地方是「4 级」这个位置挤了三行。Cursor 的自动审查、Cursor 的全自动、Claude Code 的自动模式都落在这一级，但它们到达这一级的路径完全不同：Cursor 的自动审查靠「先沙箱、沙箱跑不了再交分类器」，Claude Code 的自动模式靠「分类器先审、读操作与工作目录内编辑直接放行」，而 Cursor 的全自动是既没有分类器、也不强制沙箱。同一条线上，风险差别很大——这也是为什么只看「要不要确认」这一个维度不够，必须叠上沙箱边界一起看。

第三个是 5 级那三行。Cursor 云端 Agent 和 Claude Code 免确认模式的共同点是「不逐步确认」，但官方对它们的适用范围给出了完全不同的建议：Claude Code 官方对 bypassPermissions 的说明是「Only use this mode in isolated environments like containers, VMs, or dev containers without internet access」，而 Cursor 的 Cloud Agent 官方声明它默认就有互联网访问。一个是「请在无网络的隔离环境里用」，一个是「默认能上外网」——同样是 5 级，官方给的使用条件相反。

四、三个容易踩的坑

五、按场景怎么选

• 只在本地改代码、想把风险压到最低：Cursor 用 Allowlist 模式配一份尽量小的清单；Claude Code 留在 Manual 模式。注意 Cursor 默认已经自动批准工作区内的文件修改，只卡命令——如果你连文件改动也想逐条看，需要显式调整。
• 想减少确认次数、但不放弃兜底：Cursor 官方推荐的档位是 Auto-review（原文称其为「The safest useful setup for most people」）；Claude Code 对应的是 auto 模式，Pro / Max / Team 套餐在终端里默认就是这个档。
• 跑长任务、准备无人值守：切云端之前先确认出口策略。Cursor Cloud Agent 默认能访问互联网，三档策略里默认那一档不是最严的；Claude Code 的云会话网络默认受限，可以配成只允许指定域名。
• 要让整个团队用同一套基线：两家都支持管理员压过个人配置。Cursor 在仪表盘里配置团队级运行模式和沙盒网络规则，团队设置优先于个人与项目文件；Claude Code 用托管设置，把 permissions.disableAutoMode 设为 disable 可以彻底移除自动模式，连 --permission-mode auto 启动的会话也会退回 Manual。
• 代码不能出内网：Devin 的 VPC 部署与 Teamspace 隔离都只在 Enterprise 档；Cursor 的做法是用 Tailscale 或 Cloudflare Tunnel 让 Cloud Agent 通过认证通道访问私有服务，而不需要把服务暴露到公网；Claude Code 的自托管环境则由你自己的部署负责隔离、网络出口与 git 凭据。这三条路径的信任模型差别很大，可以对照数据政策对比一起看。
• 需要审计记录：Claude Code 官方写明云会话里的所有操作都会被记录，用于合规与审计；Cursor 侧对应的是 Enterprise 的合规日志与审计日志能力，以及 ConfigChange 这类可在会话中拦截配置变更的钩子。
• 关注并发规模：Devin Pro 与 Max 的并发会话上限是 10 个，Teams 与 Enterprise 不限。这一条直接决定了同时能跑多少任务，也决定了单个会话出问题时的影响半径。

回到方法上。这篇和本站前几篇做的是同一件事——把席位计费拉平、把上下文窗口拉平、把数据政策拉平。这一篇拉平的是「自主度」：不按厂商比，按档位比；不只看「要不要点同意」，还要看沙盒把命令关在了多大的笼子里。官方文档里最有价值的三句话都不是宣传语，而是三段免责声明——「best-effort guardrails rather than a hard security boundary」「Auto-review is not a security boundary」「not a complete isolation boundary」。厂商主动写下来的边界，比任何对比表都更值得先读一遍。