听起来这应该是 Coding Agent 最擅长的场景：有明确目标，有现成 CLI，有结构化数据，也不需要太复杂的业务判断。理论上，只要把飞书 CLI 配好，让 Codex 定时跑一段脚本，就可以把这件事交给 Agent 处理。
但真正跑起来后，我们很快遇到了一个有点棘手的问题：沙箱。
因为飞书 CLI 需要读取本地 keychain 里的认证信息，而 Codex 的执行环境默认不会让 Agent 随便访问这些凭证。于是任务经常不是卡在代码逻辑上，而是卡在权限、环境和执行边界上。
这时候很容易产生一个疑问：
为什么现在的 Coding Agent 都非要跑在沙箱里？
如果 Agent 本来就是为了替我干活，那为什么还要给它设置这么多限制？为什么不能直接让它像我本人一样访问本地环境、读取凭证、调用工具、执行命令？
刚好昨天，Anthropic 官方也宣布为 Claude Managed Agents 增加自托管沙箱能力。这个更新看起来很“基础设施”，不像模型升级那样容易引发讨论，但它其实指向了一个更实际的问题：当 Agent 不只是回答问题，而是要真正执行代码、调用工具、访问业务系统时，它到底应该被放在什么样的环境里运行？
所以这篇文章想顺着这个问题聊清楚两件事：
第一，为什么 Coding Agent 需要沙箱，它到底在防什么，又会带来哪些使用上的麻烦。
第二，所谓“自托管沙箱”到底是什么，为什么 Anthropic 会在 Claude Managed Agents 里补上这块能力，以及它对企业 Agent 落地意味着什么。
一、飞书 CLI 让 Agent 进入真实工作流
过去我们说 Agent 写代码，更多是让它读项目、改文件、跑测试。
但飞书CLI 这类工具出现后，Agent 的能力边界开始往业务系统里延伸。
这意味着 Agent 不再只是“帮你生成一段文本”，而是可以开始做事：
- 读取多维表格数据
- 整理文档内容
- 查询日历
- 发送消息
- 创建任务
- 更新业务记录
这就是飞书 CLI 对 Agent 的价值：它把飞书里的业务能力，变成了 Agent 能调用的命令。
而当 Agent 通过飞书 CLI 读取多维表格、写文档、发消息时，它不是在访问一份普通本地文件，而是在以某个身份操作飞书里的资源。
这个身份可能是用户，也可能是应用或机器人。无论是哪一种，都绕不开授权、凭证和权限范围。
从人的角度看，这很烦。但从系统角度看，这很合理。
因为一旦 Agent 可以自由读取本地凭证，它就不只是能访问飞书 CLI，也可能接触到更多敏感信息。比如本地 token、SSH key、API key、浏览器缓存、公司内部配置等。
我们在官方 GitHub README 也有类似风险提醒：AI Agent 在获得飞书权限后，会在授权范围内以用户身份执行操作，可能带来模型幻觉、不可预测执行、提示词注入、敏感数据泄露或未授权操作等风险。
二、沙箱限制的不是能力，而是边界
Coding Agent 为什么需要沙箱？
因为它已经不只是聊天窗口，而是一个能执行命令的程序。
它可以运行：
npm install
python script.py
lark-cli base list-records
git commit
curl api.example.com
这些命令一旦跑起来，就会涉及文件系统、网络、环境变量、系统凭证和外部服务。
如果没有沙箱，Agent 的权限就很容易变成“和用户本机一样大”。这在个人项目里已经有风险，在企业场景里更不可接受。
所以沙箱主要限制的是几类东西：
限制对象 | 对飞书 CLI 的影响 |
本地凭证 | 能不能读取 keychain、token、OAuth 登录态 |
文件系统 | 能不能读取配置文件、脚本、.env |
命令执行 | 能不能运行 CLI、安装依赖、启动脚本 |
网络访问 | 能不能请求飞书 API、访问内部服务 |
持久状态 | 定时任务重启后，认证状态还在不在 |
这也是 Agent 落地时经常出现的体验断层：
人手动能跑，不代表 Agent 在沙箱里也能跑。
因为人是在自己的完整开发环境里操作；Agent 则是在一个被限制过的执行环境里操作。
这不是飞书 CLI 的问题，也不完全是 Codex 或 Claude Code 的问题，而是所有工具型 Agent 都会遇到的问题。
三、沙箱的优劣
好处
最大的好处是四个字：可控放权。
它让 coding agent 能从“每一步都要问你”的玩具，变成“可以独立跑一段工作流”的工具。
具体好处有这些：
好处 | 解释 |
安全 | 限制文件、网络、命令、权限，降低误删和泄密风险 |
可回滚 | 在隔离环境里改代码，最后只提交 diff / PR |
可复现 | 环境固定，依赖固定，方便复现 bug 和测试 |
可并行 | 多个任务可以在多个沙箱/VM 里同时跑 |
更少打扰 | 安全范围内自动执行，只有高风险操作才打断用户 |
企业可治理 | 可以加审计、权限策略、网络白名单、密钥隔离 |
对企业来说尤其重要。因为企业不怕 agent 不够聪明，最怕的是：它很聪明，但权限边界不清楚。那就像招了个实习生，第一天就给了生产数据库 root 权限，刺激但不养生。
放到飞书 CLI 场景里也是一样。
合理的设计不是让 Agent 永远不能访问飞书，而是让它只访问必要范围：
只读某个多维表格
只操作某个应用授权下的资源
只允许调用白名单命令
写入或删除动作需要确认
日志完整记录
这样 Agent 才能从 demo 走向稳定使用。
坏处
但沙箱也确实会带来麻烦。
- 环境不完全等于真实开发环境
沙箱里可能没有你本地的：
私有依赖
本地数据库
内部 CLI
系统级工具
特定版本 SDK
公司 VPN
于是 agent 可能说“测试失败”，但其实是环境没配好；或者在沙箱里跑通了，本地/生产又不一样。
- 配置成本高
为了让 agent 真正能干活，你得配置：
安装依赖
构建命令
测试命令
环境变量
mock 服务
网络访问规则
私有 registry
权限策略
这对小项目还好，对大企业 monorepo 就很麻烦。很多时候，coding agent 的瓶颈不是模型，而是“工作环境能不能被机器稳定复刻”。
- 网络和权限限制会降低效率
有些任务确实需要访问外部文档、下载依赖、调用 API、查内部服务。但沙箱为了安全，会限制网络或敏感目录访问。
结果就是 agent 做到一半卡住：
我无法访问该依赖源。
我无法读取该配置文件。
我无法连接测试数据库。
这不是 agent 蠢，是安全边界把路堵了。
- 性能和成本更高
沙箱、容器、Cloud VM 都要资源。尤其是云端 coding agent，如果每个任务都 clone repo、装依赖、跑测试，成本不低。
大仓库尤其痛苦：启动慢、依赖重、测试久、缓存复杂。
- 容易制造“安全幻觉”
沙箱不是万能防护。
如果你把 .env 主动挂进沙箱，把内网权限也放进去，再给它联网权限，那沙箱就只是个塑料保鲜膜。
更麻烦的是，很多风险不是“读了不该读的文件”，而是：
生成了有漏洞的代码
误改了权限逻辑
引入了恶意依赖
把业务逻辑理解错了
这些不是 OS 沙箱能完全解决的，还需要 code review、测试、权限审批、审计和人类判断。
本质取舍
可以这样理解：
沙箱是 coding agent 从“助手”走向“执行者”的前提。
没有沙箱，agent 权限太危险，只能处处确认。
有了沙箱，agent 可以大胆干活，但会牺牲一部分真实环境、效率和灵活性。
所以最好的设计不是“全封死”，也不是“全放开”，而是分层：
低风险：自动执行
中风险：在沙箱内执行
高风险：请求确认
极高风险：禁止执行
四、为什么自托管沙箱开始变重要？
以上我们讨论的内容，能解释为什么 Anthropic 要给 Claude Managed Agents 增加自托管沙箱。
Claude Managed Agents 的默认模式，是在 Anthropic 托管的云容器里执行工具和代码；而自托管沙箱则把工具执行放到用户自己控制的基础设施里。Anthropic 文档里的说法是：编排仍在 Anthropic 一侧，但工具执行会移动到你控制的基础设施中，因此 agent 的代码、文件系统和网络出口不会离开你的环境。
简单说就是：
Claude 负责思考和调度
企业负责执行环境
这不是“自托管 Claude 模型”。
而是自托管 Agent 的“手”。
Agent 的大脑还在 Anthropic，真正执行命令、访问文件、连接内部服务的地方，则可以放在企业自己的云、VPC 或其他基础设施里。
Cloudflare 和 Anthropic 的集成也是这个方向。Cloudflare 官方博客提到，这个集成允许开发者在 Claude Platform 上运行 agent loop，同时使用 Cloudflare 执行代码、保护私有服务连接，并运行自定义工具调用；还可以通过 outbound proxy 设置 egress 策略、endpoint allowlist、凭证注入和私有网络访问。
这对企业很关键。
因为企业真正敏感的，不只是 prompt，而是 Agent 执行时会接触到的东西：
代码仓库
内部系统
业务数据
API 凭证
数据库
企业协作工具
审计日志
网络访问权限
五、从飞书 CLI 看 Agent 落地：工具只是第一步
如果 Agent 要通过飞书 CLI 操作企业数据，企业自然也会关心：
Agent 用谁的身份调用？
凭证放在哪里？
Agent 能访问哪些飞书资源？
网络出口怎么管？
操作日志在哪里？
删除和写入动作怎么审批？
能不能接入企业自己的权限系统？
这些问题不是模型本身能解决的，而是执行环境要解决的。
飞书 CLI 给 Agent 提供了进入业务系统的入口；沙箱决定 Agent 进入之后，能走到哪里、能做什么、出了问题能不能被控制住。
如果只是个人玩具项目，可以手动授权、手动确认、手动兜底。
但如果是企业 Agent，尤其是要接入飞书这样的协作系统，就不能只看“能不能跑通”。更重要的是：
能不能安全地跑
能不能稳定地跑
能不能以合适的权限跑
能不能被审计和回滚
这也是自托管沙箱的意义。
它不是为了把系统变复杂，而是为了让企业在使用 Agent 时，不必在“完全放权”和“完全不用”之间二选一。
结语
一开始遇到 Codex + 飞书 CLI 的 keychain 问题时，我们直觉上觉得沙箱有点烦。明明只是想读取一个多维表格，为什么还要被权限拦住？
但继续往下看会发现，这个小问题其实正好暴露了 Agent 落地的核心矛盾：
Agent 越能干活，越需要边界。
因此，未来看一个 Coding Agent 或企业 Agent 平台，可能不能只看模型多强、工具多少、上下文多长，也要看它能不能提供足够可靠的执行边界。飞书 CLI 也会沿着这个方向持续演进：让 Agent 更容易接入飞书工作流，同时让身份、权限、数据访问和操作过程保持可控。
