Agent 沙箱这个东西圈子里聊的人很多但真正把它跑进生产环境、还跑得稳的其实没几家。花椒的 Agent 平台从立项到上线沙箱这一层我们前后换了三版方案从最初能跑 demo 就行的 Docker 容器一路演进到基于 Kata Containers 的轻量虚拟机方案中间踩过的坑、推翻的重做、沉淀下来的选型逻辑和协议设计都值得拿出来认真讲一讲。我先把结论放在前面Agent 沙箱接入生产核心就三件事——Runtime 选型、持久化设计、执行协议定义。这三件事的优先级甚至高过 Agent 本身的智能程度因为沙箱不稳Agent 再聪明也落不了地。这篇就围绕花椒的实践把这三件事拆开讲透顺便聊聊我们在生产环境里踩过的那些坑给正在做同类事情的团队一个可复用的参考。1. Agent 沙箱的选型之路从 Docker 到 Kata 的三次决策1.1 选型前必须想清楚的需求清单很多团队选沙箱方案上来就比性能和隔离性这其实是本末倒置。我们做选型的第一件事是拿着 Agent 平台的实际业务场景列了一份需求清单明确了沙箱到底要解决什么。花椒的 Agent 沙箱要承接三类任务一是代码生成与执行类模型生成 Python/Shell 脚本后需要在隔离环境里跑二是数据分析类Agent 读写业务数据文件、执行查询脚本三是第三方工具调用类比如 Agent 拉取外部 API 数据后再加工。这三类任务有一个共同点执行的代码不可信要么是模型自由发挥生成的要么是插件市场里第三方上传的谁也不能保证它不会干坏事。基于这个前提我们的需求清单是多租户隔离不同业务线、不同权限等级的 Agent 跑在同一批物理机上相互之间必须做到资源隔离和数据隔离。快速启停Agent 执行任务往往是瞬时的沙箱生命周期通常只有几十秒到几分钟冷启动速度直接决定用户体验。资源硬限制单个沙箱必须能强控 CPU、内存、磁盘防止某个跑飞的 Agent 拖垮整个节点。安全边界沙箱内进程逃逸、内核提权、访问宿主文件系统等攻击路径必须被堵死。可观测性沙箱内的日志、指标、执行痕迹要能采集出来不能被隔离掉。持久化能力会话结束不等于数据销毁工作目录和状态要能保存、恢复、审计。这份清单看起来平淡无奇但它是我们后面所有选型决策的依据。没有这份清单你很容易被某个方案的宣传点带偏比如有人告诉你我们的沙箱启动只要 5 毫秒你一听就上头然后发现它的隔离性约等于零生产根本不敢用。1.2 三条主流路线的对比与取舍逻辑我们第一版选型其实没什么悬念直接用了 Docker。理由很现实生态成熟、团队熟悉、镜像机制天然适合做环境一致。但很快我们发现在 Agent 生产场景下Docker 的隔离性有点不够看。Docker 的隔离依赖 Linux 的 namespace 和 cgroups它共享宿主内核。这意味着一旦内核出现提权漏洞容器里的进程是有机会打到宿主上的。之前我们做内部攻防演练安全团队用了一个 CVE 的 PoC 模拟攻击只花了不到半小时就突破了我们的 Seccomp 默认策略拿到了容器外的文件读取权限。这要是发生在线上Agent 又正在访问业务数据库的话后果可想而知。于是我们开始对比三条路线方案隔离模型启动时间内存开销性能损耗生态成熟度Docker 容器namespace cgroups共享内核300ms~1s极小极低极成熟gVisor用户态拦截系统调用500ms~1s中等中高IO/网络损耗20%~40%中等Kata Containers硬件虚拟化内置 Firecracker/QEMU500ms~2s每实例 100MB较低5%左右中等CNCF 项目这里要重点说下 gVisor。gVisor 的思路是在用户态实现一个伪内核拦截沙箱内所有系统调用先经过它的安全检查再转发给真实内核。听起来很安全性能是比较大的代价。我们实测下来gVisor 的磁盘 IO 吞吐比原生低约 35%网络吞吐低约 25%对跑数据分析类任务的 Agent 来说这种性能损耗是不可接受的。而 Kata 走的是真正的硬件虚拟化每个容器背后是一个轻量虚拟机隔离性直接对标云主机性能损耗只有个位数百分比。经过对比测试Kata Containers 是我们认为在隔离性、性能、生态三者之间平衡最优的方案。1.3 最终选型Kata Containers 自研 Sandbox Manager我们的最终架构是底层 Runtime 用 Kata Containers上面罩一个自研的 Sandbox Manager 服务负责沙箱的生命周期管理、资源调度和协议转换。选 Kata 补充三个关键理由。第一Kata 对上层暴露的是标准 CRI 和 containerd 接口也就是说我们把原来的容器编排逻辑改成 Kata 时Agent 侧的代码几乎不用动迁移成本非常低。第二Kata 的每个实例本质是微虚拟机宿主机上有独立的 VMM 进程即使沙箱内发生最坏情况——内核被攻破攻击面也只是那台微虚拟机对宿主机和其他租户没有影响安全边界非常干净。第三Kata 支持直接挂载 volume 和配置资源限额和 Kubernetes 生态无缝衔接我们后续做多节点调度不需要额外造轮子。不过这里有一个血泪教训不要一开始就把 Docker 换掉要先让沙箱在测试环境用 Kata 跑一个月把所有镜像、脚本、依赖的兼容性问题暴露完再考虑切生产。我们当时图省事直接在预发环境切了 Kata结果一堆依赖底层内核模块的 Python 包全失效了连续加班一星期才排查完。后来总结下来Runtime 迁移和业务代码重构一样必须走灰度不能搞一刀切。2. 持久化设计Agent 在沙箱里失忆了怎么办2.1 三层持久化模型文件、会话、状态Agent 沙箱的持久化最常被误解的点是——很多人以为给容器挂个数据盘就叫持久化。实际上Agent 场景的持久化远没那么简单。举个例子用户让 Agent 生成一份数据分析报告Agent 在沙箱里跑了 20 分钟中途网络抖动导致沙箱被回收。重启沙箱后工作目录里的中间文件还在吗Agent 的执行状态还在吗用户和 Agent 的对话上下文还在吗这三个问题对应三层持久化我们在架构上做了明确拆分文件持久化沙箱内产生的文件比如生成的代码、CSV、图片、模型权重需要跨沙箱生命周期保存。会话持久化Agent 与用户的对话上下文、当前任务的状态机、已执行步骤与待执行步骤的队列这些记忆必须能跨会话恢复。状态持久化Agent 运行时产生的结构化数据比如任务执行结果、模型调用记录、工具调用参数需要进入统一的存储供后续分析和审计。三层分别落到了不同的存储组件上。文件层用宿主机 SSD 挂载目录加 MinIO 对象存储双通道会话层用 Redis 做热数据缓存、MySQL 做冷数据落盘状态层直接用 MySQL 存储结构化任务记录。下面分别说清楚每一层的设计与理由。2.2 文件持久化挂载卷 对象存储双通道文件层最容易踩坑。第一版我们只做了宿主机目录挂载每个沙箱启动时把宿主机某个目录挂到容器的/workspace。问题随即而来——沙箱是会被调度的如果这个沙箱在 A 节点挂了下次调度到 B 节点那 A 节点上的文件怎么办总不能每次恢复任务都人肉去找文件在哪台机器上。我们的方案是双通道写入沙箱内所有核心工作文件先落在挂载卷里保证读写性能避免直接写对象存储带来的延迟Sandbox Manager 在沙箱退出时异步把这些增量文件同步到 MinIO形成一个以task_id为前缀的目录结构。恢复任务时先检查 MinIO 上有没有快照有就拉回本地挂载目录再启动沙箱。这里有个性能细节值得说下文件同步不能做成全量拷贝。一个跑数据分析的 Agent 任务/workspace下可能积累了几个 GB 的临时文件全量上传到 MinIO 既慢又占带宽。我们做的是增量同步通过监听文件系统的修改事件inotify只上传新增和变更的文件并且在沙箱正常退出时只同步关键路径比如output/、data/临时目录和缓存目录直接丢弃。实测下来一个正常的分析任务文件同步耗时从原来的 40 多秒降到了 3 秒以内。2.3 会话持久化利用 Redis 与 MySQL 实现状态恢复会话层设计的核心考量是恢复粒度。一开始我们想得很简单把 Agent 的执行状态序列化成 JSON 存到 Redis沙箱挂掉后恢复 JSON 重跑就行。后来发现Agent 的执行状态远不是一个 JSON 能描述的——它包括对话历史、工具调用记录、中间变量、甚至代码执行的具体行号模型可能基于某条报错信息调整代码。我们的会话持久化方案做了分层实时状态Agent 每执行完一个步骤就把关键状态当前步骤、输入输出摘要、下一步计划写到 RedisTTL 设为 30 分钟。这样即使沙箱崩溃我们也能用最近一次写入的状态恢复。任务记录整个任务的元信息task_id、发起人、目标、执行计划、最终结果落到 MySQL确保任务级别可以追溯。上下文快照每隔一段时间比如每 5 步把完整对话上下文快照一次存到 MySQL 的一个session_snapshot表里。恢复时如果 Redis 状态丢了就从最近的快照重建丢失的进度由 Agent 通过总结历史推理的方式补齐。这个分级设计是基于一个很朴素的想法不同数据的重要性和恢复成本不一样没必要一刀切地做全量持久化。实时状态用 Redis 是为了快任务记录用 MySQL 是为了稳上下文快照是为了兜底。生产环境最怕的就是所有数据都在 Redis 里Redis 一挂全没了的脆弱设计。2.4 沙箱快照的具体实现与恢复流程快照在 Agent 场景里还有一个进阶用法——断点续跑。我们的 Agent 有时需要执行一个耗时很长的任务比如批量爬数据、跑模型推理单次沙箱生命周期可能撑不住更常见的是任务执行到一半遇到网络抖动。这时候如果整个任务推倒重来之前的计算成本全浪费了。我们的做法是让 Sandbox Manager 定时对 Kata 沙箱做磁盘快照利用 Kata 底层微虚拟机的能力做整机磁盘快照快照存储在宿主机本地同时将快照元数据记录到 MySQL。任务中断时直接基于最近的快照拉起一个新沙箱Agent 的执行进度自然就恢复到快照时间点。实测下来一个 1GB 左右的工作目录做快照大概耗时 1 秒多恢复耗时在 2 到 3 秒之间和冷启动的差距完全在可接受范围内。做快照时有个细节容易翻车——文件系统一致性。直接对运行中的磁盘做快照可能会抓到处于不一致状态的中间数据。我们是先调用 Kata 的 freeze 接口冻结沙箱文件系统再执行快照操作最后解冻。生产环境里宁可多花几百毫秒做冻结也不能拿数据完整性开玩笑。3. 执行协议设计沙箱内外如何对话3.1 协议设计的原则幂等、超时、可重试沙箱 Runtime 选好了数据持久化也搞定了紧接着要解决的关键问题就是——Agent 调度层怎么和沙箱通信我们一开始直接用 gRPC 调用沙箱内常驻的 Agent Runner 服务图省事暴露问题后才发现自己想简单了。第一个问题是协议耦合。Agent Runner 是我们自己写的但它要执行的代码可能是别的小组写的插件插件不需要关心底层是 gRPC 还是 HTTP它只需要一个明确的我提交一段代码你给我一个结果的接口。第二个问题是超时与重试。网络抖动时 gRPC 调用可能在沙箱执行完成后才返回超时导致上层误以为任务失败重试后重复执行了同一段代码。所以我们基于这些教训设计了统一的执行协议命名上叫Agent Execution ProtocolAEP核心原则就是三点幂等性、超时控制、可重试性。幂等性每个任务有全局唯一的task_id沙箱侧会记录已执行的 task_id重复提交直接返回上次结果绝不重复执行。超时控制协议中明确写死每个任务的timeout_ms沙箱侧定时器一到就强制终止执行进程并返回timeout状态避免任务永久挂起。可重试性消息里带retry_count沙箱侧根据执行状态决定是否可安全重试——比如执行前状态的可以重试执行中状态的要先杀掉进程再重试执行完成状态的直接复用结果。3.2 AEP 协议格式与字段定义协议格式我们选择了 JSON over HTTP而不是 gRPC。原因很实在gRPC 的强类型接口在跨团队协作时确实方便但它的协议定义文件维护成本高而且对调试不友好。JSON 谁都能读谁都能改对 Agent 这类上层代码变更频繁的场景更合适。协议核心是一个任务模型{ protocol: aep.v1, task_id: task-20250110-001, session_id: sess-89f2, action: run, retry_count: 0, payload: { language: python3, code: print(hello), entrypoint: main.py, args: [], env: { PYTHONUNBUFFERED: 1 }, timeout_ms: 30000, resources: { cpu_cores: 1, mem_mb: 512, disk_mb: 1024 } } }对应执行结果的返回消息{ protocol: aep.result.v1, task_id: task-20250110-001, status: success, output: hello\n, exit_code: 0, metrics: { elapsed_ms: 1234, max_mem_mb: 88 }, error: null }在协议设计上我们花了不少心思的是resources字段。为什么任务提交时要显式声明资源需求因为 Sandbox Manager 需要根据资源需求决定把这个任务调度到哪个节点、给沙箱分配多少配额。如果资源不提前声明沙箱只能给一个默认值结果就是大任务被默认配额卡住小任务又浪费了节点资源。另外补充一个实用细节所有消息都要求带上protocol版本号这个字段看着不起眼但在协议升级时至关重要。我们的沙箱节点可能同时跑着 v0.9 和 v1.0 两版协议调度层根据版本号路由到对应能力的节点就避免了新调度器把新协议消息发给旧节点旧节点解析失败的兼容性问题。3.3 执行流程与事件回调机制前面说的是同步执行模型——上层提交任务然后等结果。但实际上 Agent 的任务往往是多轮交互的Agent 先生成一段代码执行看结果再改代码再执行直到满意。如果每轮都走提交任务-等待结果的同步模式效率很低而且沙箱不能复用。我们的方案是引入事件回调机制。Sandbox Manager 跟沙箱内的 Agent Runner 之间维持一个长连接底层是 WebSocket沙箱内发生的每一步执行、每个 stdout 输出、每次资源用量变化都会以事件的形式通过连接推送给上层。上层可以选择等待任务完全结束拿最终结果或者监听中间事件做实时干预比如 Agent 发现执行出错立刻提交一段新代码去覆盖。通过引入事件回调机制我们把一次任务一次执行变成了一次会话多轮执行。会话级的复用带来了一个直接收益沙箱的启动次数大幅下降。最夸张的一个案例有个 Agent 任务在单次会话里连续执行了 17 轮代码修改如果按原来的模式这 17 轮就要执行 17 次沙箱创建、镜像拉取、环境初始化耗时从几十秒拉高到十几分钟。事件回调机制把多轮执行放进同一个沙箱的会话上下文里效率提升非常明显。4. 生产接入的完整实践从 Demo 到真上线的关键一跃4.1 部署架构与资源配额的计算逻辑沙箱在测试环境跑通和真正接入生产是完全不同的两码事。测试环境你可能只有几个沙箱跑挂了重启就行生产环境同时可能有几百个沙箱在跑调度、配额、容错、灰度每一个都是必修课。我们的生产架构分四层接入层API Gateway→ 调度层Sandbox Manager→ 执行层Kata 节点池→ 存储层MySQL/Redis/MinIO。调度层是整个系统的核心负责接收 Agent 任务请求、解析协议、找到合适的执行节点、创建沙箱、跟踪生命周期、回收资源。资源配额这块我们踩过最痛的坑。一开始我们天真地给每个沙箱固定配额比如 1 核 512MB后来发现数据分析类任务一上来就把内存吃满然后被 OOM Killer 杀掉任务频繁失败。后来我们统计了线上任务的资源分布做了分级配额任务类型CPU 配额内存配额磁盘配额典型场景轻量脚本0.5 核256MB512MB简单计算、文本处理标准执行1 核512MB2GB代码生成、API 调用数据分析2 核2GB8GB数据清洗、报表生成重负载任务4 核8GB32GB模型推理、批量处理这里有一个关键计算逻辑单节点的沙箱并发上限 节点可分配资源 × 冗余系数 ÷ 平均单沙箱配额。我们的生产节点是 32 核 128GB 内存的裸金属按 80% 可分配比例、冗余系数 0.7 计算如果平均沙箱配额是 1 核 512MB那单节点并发上限大约是 17 个沙箱。这个数字会作为调度层的硬约束任务来的时候先算节点剩余资源是否足够不够就排队或者路由到其他节点。4.2 安全隔离与权限收敛网络、文件、危险操作安全这块生产接入比测试环境严格得多。我们做了三层收敛。网络层Kata 沙箱默认是完全断网的。需要访问外网的任务由调度层按照任务声明的外网白名单动态下发网络策略。比如 Agent 需要请求某个天气 API调度层就在沙箱的网络策略里放开对应域名和端口的访问任务结束后策略自动清理。这里用到的核心能力是 Kubernetes NetworkPolicy限制条件非常清晰控制粒度能到 DNS 域名级别。文件系统层沙箱内的进程默认只能访问自己的工作目录挂载卷、临时目录、以及系统库路径。通过 Kata 的只读挂载配置把宿主机的敏感目录比如/etc、/var下的配置设为不可见。这个配置必须在沙箱镜像层面做死不能在运行期让 Agent 自己改。危险操作拦截我们在沙箱内预置了一个 Agent Runner 侧的安全策略组件对典型危险命令做实时拦截——比如rm -rf /、fork 炸弹、无限循环等。拦截不是简单地把命令 banned 掉而是先截获命令内容做规则匹配命中高危模式就尝试在执行前取消并返回违规操作提示给上层 Agent要求模型自行修正。这里补充一个实操细节安全策略组件不能依赖 Agent 调用的编程语言本身而应该依赖底层系统调用层面做拦截。为什么因为模型生成的代码五花八门它可以写 Python 调subprocess、可以写 Shell、可以写 Go 程序单纯靠语言层面的正则匹配根本拦不全。我们的拦截层用 eBPF 程序挂在 execve 系统调用上对所有沙箱内进程的启动行为做实时监控只要是命中危险命令模式的进程创建行为全部强制阻断。4.3 监控、告警与日志采集的关键指标沙箱接生产后第二个突然变重要的事情是监控。测试环境你盯着终端看日志就行生产环境几百个沙箱一个节点出现问题可能几分钟后就酿成雪崩。我们围绕沙箱建立了三层监控指标体系节点层CPU、内存、磁盘 IO、网络吞吐、沙箱数量、节点剩余可调度资源。沙箱层单沙箱 CPU 使用率、内存水位、磁盘使用量、存活时长、退出原因正常/超时/崩溃/被回收。任务层任务成功率、任务平均耗时、任务排队时长、不同失败原因占比、各业务线的任务量分布。告警规则按这个思路设计节点层资源超过 85% 就告警因为意味着即将出现调度失败沙箱层如果单个沙箱连续 5 分钟内存使用率超过 90%直接判定为内存泄漏嫌疑告警并触发沙箱回收任务层如果某个业务线的任务失败率超过 10% 就告警说明要么 Agent 出了问题、要么执行环境出了问题。日志采集我们走了弯路。一开始直接让沙箱内的 stdout 打点到宿主机日志文件结果量大不说还不方便按任务查询。后来改成结构化方案所有日志先打到沙箱内的本地日志文件Sandbox Manager 在沙箱退出时把日志文件捞出来做一个简单的日志索引后入库我们用 ClickHouse 存储日志和任务指标再通过 Kibana 做查询分析。现在查一个任务的完整执行日志只需要在平台输入 task_id 就能秒级拉到。这里要特别提醒一句沙箱的退出原因一定要记清楚。我们最开始只记录沙箱退出这个事件后来排查问题发现根本看不出是 Agent 主动结束、执行超时还是节点故障导致的强制回收。后来我们在 Sandbox Manager 里给每个沙箱加了退出原因枚举排查效率直接翻倍。5. 实战中的高频问题与排查实录5.1 Kata 沙箱内 PID 1 进程异常导致 CPU 飙升我们切到 Kata 后遇到的第一个大问题部分沙箱内出现 CPU 使用率异常飙升持续几分钟不退。排查发现Kata 沙箱内的 PID 1 进程是容器默认的/pause或 init 进程当沙箱内的 Agent Runner 进程意外退出后孤儿进程没有被正确回收导致 PID 1 进程不断检查子进程状态陷入 CPU 空转循环。解决办法是在镜像里显式设置一个轻量 init 进程我们用了 tini用它来管理进程生命周期。配置tini作为入口点并保证 Agent Runner 作为它的子进程启动。这个修法很小但在 Kata 下非常关键——Kata 内部是微虚拟机它不会像纯容器那样自动帮你回收所有子进程孤儿进程的问题会被放大。5.2 沙箱快照恢复后文件系统出现不一致快照功能上线后不久有用户反馈任务恢复后数据错乱比如 CSV 文件只写了一半代码文件内容不完整。刚开始以为是快照时机的问题后来定位到是文件系统的 journal 没有按时回放完。排查过程很有意思单独手动触发一次冻结快照恢复文件是好的但生产环境高负载下冻结请求发出后文件系统的 journal 回放还没完成VMM 就开始执行磁盘快照抓到了不一致状态。后面我们方案调整为快照前先通过 fs-freeze 工具冻结文件系统并且强制等待 journal 清理完成后才开始打快照。加上这个约束后再没有出现一次恢复后文件不一致的问题。5.3 大量沙箱并发时节点文件句柄耗尽有次大促活动Agent 任务量暴增几十倍然后沙箱节点们接连挂掉而且挂掉的节点都是相同的报错——too many open files。系统日志显示宿主机文件句柄耗尽所有新沙箱创建失败。根因分析下来有两层。第一层每个 Kata 沙箱在宿主机上会占用大量文件句柄VMM 进程、块设备、网络 tap 设备都要占用 fd这是我们之前没料到的。第二层我们的 Sandbox Manager 没有对节点沙箱数量做硬上限任务多的时候一个节点可能堆了几百个沙箱fd 自然不够用了。解决思路分两步走。第一调大系统fs.file-max和ulimit让单节点能容纳的句柄数翻倍。第二更关键的在调度层加上单节点的沙箱数量硬限制超过限制就把任务路由到其他节点。我们用的计算公式是节点最大沙箱数 系统可调节的 fd 上限 × 单个沙箱预估占用 fd 数的倒数 × 0.8 安全系数。这个限制上线后节点再没有出现过因 fd 耗尽而挂掉的情况。5.4 镜像拉取耗时波动拖垮冷启动 P95生产环境里沙箱冷启动慢的原因大多不在 VMM 本身而在于镜像拉取。我们的 Agent 沙箱镜像有 2GB 多包含 Python 运行时、数据分析库、Node 环境从镜像仓库拉到节点本地慢的时候能到 30 秒以上直接拖垮了任务的端到端耗时 P95。第一版优化是镜像预热——在调度任务前先把镜像同步到目标节点。但任务调度是动态的预热的节点不一定被调度到效果有限。第二版我们换成了镜像分层预热 P2P 分发利用 Kata 沙箱共享镜像层的特性节点之间通过 BitTorrent 协议互传缺失的镜像层而不是所有节点都从中心仓库拉全量镜像。部署后实测冷启动耗时从平均 28 秒降到 6 秒P95 从 45 秒降到 12 秒。这个优化背后的逻辑是镜像仓库的网络带宽是瓶颈但节点之间的内网带宽非常充裕。让节点之间互相分发数据把中心仓库的压力分散到整个集群是性价比最高的解法。5.5 沙箱时钟漂移导致 Agent 时间判断错乱还有个细思极恐的坑——时钟漂移。Kata 沙箱作为微虚拟机它的虚拟时钟可能和宿主机真实时钟存在偏差长时间运行的任务偏差尤其明显。有次 Agent 在沙箱里做定时任务结果执行时间和预期差了 3 分钟查了半天发现是沙箱里的date输出和宿主机差了快 4 秒Agent 基于这个时间做逻辑判断结果就偏了。解决方式是在沙箱启动时挂载宿主机的/etc/localtime和配置 NTP 同步但是纯用 NTP 对 Kata 这种轻量虚拟机开销偏大。我们的做法是启动时直接从宿主机注入当前时间到沙箱同时周期性每 10 分钟从宿主机同步一次时间偏移量。实现不复杂但把问题根治了现在沙箱内时间与宿主机误差控制在毫秒级。沙箱选型、持久化、执行协议这三件事我们分别花了不同的时间周期选型用了两周持久化用了一个月执行协议迭代了三个月。回头看这个投入比例是值得的。协议设计阶段多花的时间在后面接入业务时带来了巨大的收益——花椒内部现在有十几个业务方接入了 Agent 平台他们对接的是同一套协议而不是各写各的沙箱适配器。如果让我给正在做 Agent 沙箱的团队留一句建议那就是先把沙箱外的事情想清楚再动手做沙箱内的事情。沙箱本质上是为 Agent 这个大脑提供的一双可以安全动作的手大脑怎么调度手、手做完事怎么反馈、翻车了怎么恢复这比手本身长什么样子更重要。另外一个很实用的技巧是任何新接入的沙箱能力快照、网络策略、资源缩减都先跑一个月灰度再全量上线我们的沙箱系统能稳到现在靠的就是这个谁都不例外的规矩。