Sandbox 为什么是 AI 中台的必选项：Claw 运行时与安全隔离
约 2824 字大约 9 分钟
2026-05-17
只要 AI 开始真正执行工具、脚本和外部调用，系统就会立刻从“生成文本”变成“执行动作”。一旦进入这个阶段，很多过去还能靠提示词约束的问题就会失效：模型可能会访问不该访问的网络、读写不该读写的目录、执行不该执行的脚本，或者在长链路里因为某个工具失控而把整个服务拖垮。
这就是为什么 AI 中台一旦进入可执行阶段，Sandbox 就不再是锦上添花，而是必选项。联犀在这一点上的做法并不是把所有执行都留在主服务里，而是把控制面和执行面拆开：aisvr 负责控制面，claw 负责实际运行循环，再通过容器级和容器内两层约束构建安全边界。
为什么 AI 运行时不能直接塞进主服务
很多系统在早期做 AI 能力时，会把“执行工具”简单理解成在现有服务进程里多跑一段脚本或多发几个 HTTP 请求。这在功能验证阶段当然方便，但问题也非常直接：主服务的稳定性和执行任务的风险被绑在了一起。
一旦运行时直接驻留在主服务里，工具执行和业务控制面就共享了同一个进程空间、同一套文件系统视野和同一组网络能力。模型如果触发了重型脚本、失控子进程、危险地址访问或异常长尾任务，首当其冲被拖垮的就是整个 AI 中台入口。换句话说，执行面不再是某种附加能力，而是反向成为主服务的风险源。
这也是联犀把 claw 抽成独立执行服务的根本原因。aisvr 保留主数据模型、会话生命周期、Skill 元数据、知识加载、记忆编排和 HTTP/RPC 入口，claw 则专门承载单个 clone 的工具 dispatch、脚本执行和 SSE 事件输出。这样一来，控制面和执行面终于有了明确边界。平台不是“把模型权限收紧一点”，而是从运行时结构上承认：执行能力必须被放到更可隔离、更可销毁、更可治理的区域里。
Claw 的价值，不只是“多一个容器”
从表面上看，claw 像是把执行逻辑换了个宿主，真正的价值却不在容器形式本身，而在于它让 AI 中台第一次拥有了一个独立的执行平面。
这意味着：
- 会话控制和任务执行可以分开治理
- 执行失败不必直接污染主控制面
- 每个 clone 可以拥有更明确的 workspace 和生命周期
- 平台能够围绕“启动、探活、停止、重建”来定义 AI 执行环境，而不是把执行过程揉进一个常驻服务线程里
更重要的是，独立执行面让安全隔离终于有了抓手。因为只有当执行环境可以被单独约束，资源限制、网络隔离、文件系统隔离和宿主边界隔离才真正有落点。否则所谓“Sandbox”最后往往只是某些进程级限制和一堆不可靠的运行时约定。
Sandbox 的意义，是把 AI 能力变成“可上线的执行能力”
很多团队理解 Sandbox 时，容易把它等同于“限一下 CPU 和内存”。这当然是必须做的，但远远不够。
对 AI 中台来说，真正危险的往往不是单一资源超限，而是执行环境越过了原本不该越过的边界：
- 不该访问的内网地址被访问
- 不该看到的宿主目录被读取
- 不该长期存在的 workspace 被扩散利用
- 一个任务的副作用外溢到其他 clone 或其他租户
所以联犀的 Sandbox 不是单点保护，而是两层结构：
第一层是容器级隔离，把 claw 本身从主服务里隔开；第二层是容器内的 sandbox-go 约束，对任务进程继续施加资源、网络和文件系统层面的限制。
这套结构的核心不是“更复杂”，而是承认 AI 执行环境需要分层防御。容器解决的是宿主边界和生命周期问题，容器内 Sandbox 解决的是任务边界和运行细节问题。两层都在，平台才不会把所有安全希望压在某一个开关上。
文件系统隔离为什么比很多人想象得更重要
AI 一旦能够执行脚本，就天然会与文件系统打交道。
如果 workspace 只是一个方便写文件的目录，这件事看起来没什么问题；但如果 workspace 没有边界，风险就会非常现实：不同 clone 之间的产物可能互相可见，某个执行任务可能读取到不该读取的内容，甚至把敏感文件误当作工具输入。
联犀在这里采用的策略很清楚：每个 clone 对应自己的宿主持久目录，容器侧只挂载这一份具体 workspace，而不是把整个 workspace 根目录一并暴露进去。这样做带来的收益非常明确。
首先，clone 之间的文件天然隔离，不需要靠运行时再做二次约定。其次，执行环境被销毁后，工作目录仍然可保留，平台既保留了运行期隔离，也保留了必要的持久化能力。最后，控制面可以更清楚地理解某个 clone 当前到底对应哪一份执行上下文，而不是在共享目录里猜测。
这也是 AI 运行时和传统脚本执行器的一个重要差别。AI 工具链不是偶尔跑一段运维脚本，而是会长期围绕某个分身、某个会话、某个业务对象反复执行。workspace 因此不只是临时目录，而是运行语义的一部分。
网络隔离为什么必须默认严格
对 AI 运行时来说，网络边界往往比 CPU 边界更危险。
因为模型具备持续尝试外部调用的能力，而网络访问一旦放开，后果通常不是“这次请求慢一点”，而是内网探测、元数据访问、错误外呼、意外泄漏甚至横向利用。
联犀在这部分采取的是较强的默认约束：sandbox-go 路径下，任务进程进入受限 netns，只允许通过受控代理口出网，并对内网地址、元数据地址和黑名单目标做专门限制。
这个设计思路非常重要，因为它说明平台的默认立场不是“先全放开，再按需补黑名单”，而是“先把边界收紧，再决定哪些访问值得被放行”。
这类策略对 AI 特别关键。传统后端请求通常由开发者显式决定目标地址，而 AI 工具调用很多时候是模型根据上下文临时选择的。如果没有一个后端级的网络隔离层，安全边界最后只能依赖 prompt 或业务逻辑的临时兜底，这在工程上是不够的。
对应的开源执行面仓库
这一篇最直接对应的开源补充仓库，就是 .gits/sandbox。
这个仓库不是简单的示例工程，而是联犀当前 AI Agent 安全执行面的独立仓库形态。里面能直接看到这篇文章讨论的很多能力都已经被做成明确事实：
- 独立执行服务本身
readyz / runtime/start / runtime/stream / runtime/stop这类运行时接口- cgroup / prlimit 资源限制策略
CLONE_NEWNET、iptables、SOCKS5 白名单等网络隔离实现- clone 级 workspace 与 smoke 测试脚本
这说明 Sandbox 在联犀里不是某个文档上的安全愿景，而是已经具备独立仓库边界的执行面能力。对外讨论这套设计时，把 .gits/sandbox 一并放进视野里，会更容易理解为什么我们说它不是“主服务里的一个小模块”，而是一层可以独立演进、独立验证、独立发布的安全执行基础设施。
控制面与执行面的分离，也是在做故障隔离
Sandbox 的价值并不只在安全层面，它还同时改善了故障控制。
一套成熟的 AI 中台不仅要防止“错误地执行”，还要防止“执行失败后把整个服务拖死”。把 claw 作为独立执行面之后，很多故障可以被自然限制在更小范围内：
- 单个 clone 的运行循环出错，不必直接影响所有会话入口
- 某个任务超时或进程异常，可以围绕该 runtime 做停止和重建
- 容器生命周期管理成为可操作对象，而不是只能在主进程里猜状态
对于 AI 平台来说，这种故障隔离能力非常实际。因为工具执行、脚本运行和外部调用的失败模式，远比普通 HTTP API 丰富得多。只有当平台能把失败控制在执行面里，控制面才能继续稳定承担会话管理、知识加载、记忆编排和入口路由等职责。
Sandbox 的边界：它不是万能安全神话
当然，Sandbox 也不是“有了就绝对安全”。
它能解决的是执行环境边界问题，但它并不会自动替平台完成工具级语义校验、租户级授权判断或业务级幂等控制。换句话说，Sandbox 负责把运行时关进笼子里，但笼子里允许执行什么、哪些工具可以被调用、哪些 endpoint 被视为可信，仍然需要平台其他层一起定义。
这也是联犀同时保留 MCP 安全模型、租户 scope、白名单、超时和速率控制的原因。真正可靠的 AI 安全体系，不会把希望押注在单一机制上，而是让运行时隔离、工具约束和业务权限各自承担自己的职责。
总结
AI 中台进入“可执行”阶段之后，真正的挑战就不再只是模型能力，而是执行环境是否可控。联犀之所以把 claw 抽成独立执行服务，并叠加 Sandbox 双层隔离，本质上是在回答一个很现实的问题：怎样让 AI 的工具能力、脚本能力和外部调用能力真正具备可上线条件。
答案不是“把模型限制得更保守”，而是把控制面和执行面拆开，把容器边界和任务边界同时收紧，把 workspace、网络和资源变成平台明确治理的对象。只有这样，AI 中台才不是一个会说话的执行器，而是一套可以长期运行、长期治理、长期演进的执行平台。
更新日志
2026/5/18 10:48
查看所有更新日志
43ef3-docs(blog): 新增后端与架构系列技术博客 18 篇，更新原有 7 篇于
