当 Agent 开始替你跑代码，为什么只套一层 Docker 不够

Wed, 15 Jul 2026 00:00:00 +0000

当 Agent 开始替你跑代码，为什么只套一层 Docker 不够

你把 Agent 接进内部系统后，最危险的那一步通常不是模型回答错了。

而是它开始替你执行代码：装一个包，跑一段 Python，拉一个仓库，开 Chromium 点几个页面，再顺手访问外网。演示里这是一条 run_code()；线上，它意味着一段由模型拼出来、由用户输入影响、依赖链也未必干净的程序，正在拿你的 CPU、网络和文件系统做事。

很多团队的第一反应是：丢进 Docker，不就隔离了吗？

Docker 当然不是不能用。它有 namespace、cgroup、capability、seccomp，也能配 AppArmor、SELinux 和 rootless。问题在于，Agent 这类负载把它推到了一个更难的位置：你不是在跑一组自己写、自己发布的服务，而是在高频创建执行环境，里面的命令、依赖、网页和输入都更不受控。容器仍与宿主共享内核；一旦把 Docker daemon、宿主目录或过宽的 capability 暴露进去，隔离边界就会被你自己打穿。[1]

这时该换的问题了。

Agent 沙箱不是“能不能把代码跑起来”的组件，而是“代码跑错了，最多能碰到哪里”的运行时。

Cube Sandbox 值得看，正是因为它没有把重点放在再包一层执行 API，而是把 MicroVM、模板快照、网络出口和凭据边界一起做成了面向 Agent 的运行时。它还很年轻，远没有到“装上就高枕无忧”的程度；但它提醒了后端团队一件容易被忽略的事：Agent 执行层，本身就是一套基础设施。

真正要防的，不是那一段 Python

假设你的 Agent 被允许“分析一个 CSV 并生成图表”。过几周，需求会自然长出下一层：

能不能 pip install 一个缺失库？
能不能读取用户上传的压缩包？
能不能抓一个网页再做摘要？
能不能调用企业内部 API 补充数据？
能不能保留上轮生成的文件，下一轮继续修改？

每加一个“能不能”，都不是单纯的工具功能，而是在扩大执行边界。

最直观的风险是任意代码。更难处理的是旁路：代码可以借网络带走数据，可以从环境变量或文件里摸到密钥，可以耗尽 CPU、内存和磁盘，也可能借浏览器自动化碰到本不该访问的后台页面。即使没有逃逸漏洞，只要权限、挂载和出口策略给得太宽，沙箱也会变成“专门给不可信代码准备的跳板”。

所以后端开发者不该只盯着 prompt injection。Prompt injection 是诱因；执行环境、网络策略、密钥注入和审计是否收口，才决定诱因最后能造成多大损失。

一条很实用的判断是：只要 Agent 能执行用户可影响的命令，就先按多租户、不可信工作负载设计；即使今天只有一个内部用户。 因为能力一旦接进产品，使用边界通常只会往外扩，不会自己缩回去。

Kafka 敢把消息写进磁盘，是因为它避开了磁盘最慢的用法

Mon, 29 Jun 2026 18:02:16 +0800

日志量一上来，消息队列先扛不住。

很多团队的第一反应很自然：换 SSD，加 broker，调 batch size，甚至开始怀疑是不是 Kafka 参数没配对。

但吞吐上不去，有时候不是机器不够好。是数据一路都在走慢路：小块写、随机查、反复序列化，从应用层读出来，再拷进 socket，CPU 和 GC 跟着一起烧。

Kafka 最容易被误解的地方就在这里。

它不是让磁盘突然变快了，也不是靠 zero-copy 一个神技把所有问题抹掉。Kafka 真正做对的，是从一开始就把数据路径设计成硬件和操作系统擅长的形状。

顺序，大块，少拷贝。

这才是 Kafka 高吞吐的底层味道。

先把“快”说清楚：Kafka 快，主要快在吞吐

讨论 Kafka 为什么快，先别急着背 partition、ISR、replica、controller。

更应该先问一句：这里的快，到底是哪种快？

很多人把快默认理解成低延迟：一条消息发出去，下一毫秒就要被消费。Kafka 当然也在意延迟，但它最出名的能力不是“单条消息永远最低延迟”，而是持续搬运大量 records 的能力。

也就是 high throughput。

这两个东西不一样。

低延迟像外卖骑手送一单，追的是这一单多久到。高吞吐像港口卸货，追的是一小时能吞掉多少集装箱。你不能拿港口的设计去要求它像骑手一样灵活，也不能拿骑手的速度去推导一个港口的吞吐。

Kafka 更像后者。

它关心的是：数据能不能稳定地、大块地、连续地从 producer 进来，写进 log，再被 consumer 拉走。只要这条路径足够顺，单条消息上的一点点额外开销，被摊到一大批数据里，就不再那么显眼。

所以这篇文章不想把 Kafka 写成“低延迟神器”。它真正值得学的，是高吞吐系统怎么避开慢路径。

“磁盘慢”这句话，太粗了

很多人第一次理解 Kafka 时，会卡在一个矛盾上：

消息不是落磁盘吗？磁盘不是慢吗？那 Kafka 为什么还快？

这个问题的坑在于，“磁盘慢”只说对了一半。

磁盘确实怕慢，但它怕的不是“被使用”，而是被随机、小块、来回折腾地使用。

Kafka 官方设计文档里有一组经典数字：在 6 块 7200rpm SATA 磁盘的配置下，线性写大约可以到 600MB/s，而随机写大约只有 100kB/s，差距超过 6000 倍。

后端架构 on Zampo Blog

当 Agent 开始替你跑代码，为什么只套一层 Docker 不够

当 Agent 开始替你跑代码，为什么只套一层 Docker 不够

真正要防的，不是那一段 Python

Kafka 敢把消息写进磁盘，是因为它避开了磁盘最慢的用法

先把“快”说清楚：Kafka 快，主要快在吞吐

“磁盘慢”这句话，太粗了