企业官网建设流程全解析

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 又正在访问业务数据库的话，后果可想而知。

于是我们开始对比三条路线：

这里要重点说下 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 每执行完一个步骤，就把关键状态（当前步骤、输入输出摘要、下一步计划）写到 Redis，TTL 设为 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 Protocol（AEP），核心原则就是三点：幂等性、超时控制、可重试性。

• 幂等性：每个任务有全局唯一的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 杀掉，任务频繁失败。后来我们统计了线上任务的资源分布，做了分级配额：

这里有一个关键计算逻辑：单节点的沙箱并发上限 = 节点可分配资源 × 冗余系数 ÷ 平均单沙箱配额。我们的生产节点是 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 这个"大脑"提供的一双可以安全动作的手，大脑怎么调度手、手做完事怎么反馈、翻车了怎么恢复，这比手本身长什么样子更重要。另外一个很实用的技巧是，任何新接入的沙箱能力（快照、网络策略、资源缩减），都先跑一个月灰度再全量上线，我们的沙箱系统能稳到现在，靠的就是这个谁都不例外的规矩。