16GB 内存也能跑 AI Agent？我把 OpenClaw 放进了 macOS Sandbox
Table of Contents
最近一段时间，本地 AI Agent 项目越来越热。
尤其是 M4 Mac Mini 发布之后，很多开发者第一次意识到：一台只有巴掌大的机器，已经可以在本地运行完整的 AI 工作流。
但真正开始折腾之后，大多数人很快会撞上一堵墙：16GB 内存并没有想象中那么宽裕。
模型、Docker、上下文缓存、浏览器、IDE、LSP、文件扫描、Shell 工具链一起跑起来之后，系统很快开始 Swap。随后，推理变慢，Agent 变迟钝，整个体验会从“未来感”迅速退化成“风扇压力测试”。
所以这个项目最初并不是为了做安全。
它的起点其实很现实：
如何在 16GB 的 Mac Mini 上，稳定运行 OpenClaw？
但继续做下去之后，我逐渐发现：性能问题和安全问题，在本地 Agent 里其实经常是同一个问题。
因为真正的问题不只是“模型占多少内存”，而是 Agent Runtime 能不能被边界化：资源边界、文件边界、执行边界、网络边界，本质上都在回答同一个问题：
这个 Agent 到底可以使用什么，又不应该碰什么？
于是就有了这个项目：OpenClaw Sandbox macOS
本地 Agent 真正的问题，不是模型能不能跑 #
很多人第一次接触 AI Agent 时，看到的只是一个聊天框。
但真正复杂的部分，其实都藏在后面。
Agent 如何规划任务？
Tool Call 如何执行？
Context 为什么会不断膨胀？
模型如何读取文件、调用 Shell、修改代码？
这些东西，如果只使用云端 Agent，其实很难真正理解。因为大多数云端 Agent 本质上仍然是黑盒系统，开发者只能看到最后的结果，很难观察 Runtime 内部发生了什么。
本地 Agent 不一样。
它让你可以直接看到整个执行链路：
- Ollama 的推理状态
- Context 的增长过程
- Workspace 的文件变化
- Shell 调用链路
- Tool Routing
- 容器 Runtime 行为
- 文件系统读写过程
某种意义上，本地 Agent 更像一个可以拆开的 AI Runtime 实验室。
对于学习阶段的开发者来说，这一点非常重要。
即使只是 3B、4B、Q4 量化模型，也足够理解 Agent Workflow、Context Management、Tool Calling、Runtime Scheduling 和 Sandbox Isolation 这些核心问题。
云端模型更像生产服务。
本地模型更像实验室。
如果目标是理解 AI Agent 到底怎么运转，那么第一步未必是调用最强 API，而是先把一个本地 Agent 真正跑起来。
AI 正在从聊天进入执行 #
过去几年，大模型最重要的变化，并不只是“更会聊天”。
更重要的是，它开始具备行动能力。
传统 ChatBot 的工作方式很简单：用户提问，模型生成文本，然后结束。
But Agent 完全不同。
Agent 更像一种自动执行系统。用户只提供目标，模型负责规划、调用工具、执行任务、读取结果，并持续迭代。
它已经不只是回答问题。
它开始真正参与系统执行：
- 读取文件
- 执行 Shell
- 修改代码
- 操作浏览器
- 调用本地工具链
- 根据执行结果决定下一步
这也是 OpenClaw 开始变得有意思的地方。
它让 AI 真正进入了本地操作系统，而不只是停留在聊天窗口内部。
但危险也从这里开始。
真正危险的，并不是模型本身。
而是：
一个拥有系统权限的大模型。
一旦 Agent 可以执行命令，风险等级就完全不同了。理论上，它可以读取本地文件、访问 SSH Key、执行任意 Shell、操作浏览器，甚至修改系统配置。
于是问题开始转变：如果 OpenClaw 默认拥有整个系统权限，能不能把它关进一个边界清晰的运行环境里？
这就是 Sandbox 的意义。
为什么 16GB 会这么容易崩？ #
很多人以为，本地 AI 的瓶颈是 GPU。
但真正运行 Agent 后会发现，问题远远不只是推理。
一个完整的 Agent Runtime 同时会消耗很多资源：
- Docker 虚拟化开销
- 模型显存占用
- Context Window 膨胀
- KV Cache 增长
- Workspace 文件扫描
- 浏览器自动化
- IDE 与 LSP 服务
- Shell 工具链与临时文件
在 Apple Silicon 的 UMA 架构上，CPU 和 GPU 共享同一块统一内存。
这意味着模型、容器、系统服务、浏览器和开发工具都在争抢同一块 16GB 内存。
一旦开始 Swap，体验就会迅速崩掉。
这也是为什么很多人明明能运行模型，却跑不动 Agent。
能跑模型，只说明推理链路能工作。
能跑 Agent，考验的是整个 Runtime。
这个 Sandbox 做了什么 #
为了让 16GB Mac Mini 更稳定地运行 OpenClaw，我最后采用了一种混合 Runtime 架构：
- Ollama 原生运行在 macOS 宿主机上
- OpenClaw Agent 运行在 Colima 容器里
- Colima 使用
vz作为虚拟化后端 - 文件挂载使用
virtiofs - Workspace 通过受限目录挂载进容器
- Agent 只能访问明确暴露的工作目录
- 推理与执行被拆到两个不同边界里
核心思路其实只有一句话：
把推理与执行解耦。
Ollama 留在宿主机上，尽量减少模型运行的额外开销。
OpenClaw 放进容器里，限制它能看到的文件系统和执行环境。
这样做之后，系统不再是一个“所有东西都挤在 Docker Desktop 里”的结构，而是变成了：
- 宿主机负责模型推理
- 容器负责 Agent 执行
- Sandbox 负责权限边界
- Workspace 负责可控上下文
这不是完美方案，但它比默认把 Agent 直接放在完整系统权限下运行要清晰得多。
为什么放弃 Docker Desktop？ #
因为它太重了。
尤其在 16GB UMA 架构上，Docker Desktop 本身就会长期占据不少内存。
再叠加浏览器、IDE、Ollama 和 Agent Runtime，系统很容易进入 Swap。
后来逐渐发现，对于 Apple Silicon 而言，Colima 更适合这种本地 Agent 场景。
原因并不复杂：
- 更轻
- 更接近 macOS 原生虚拟化
- 可以使用
vz - 可以配合
virtiofs改善文件挂载性能
这对 Agent 很关键。
因为本地 Agent 最大瓶颈，经常并不是 GPU，而是文件系统 I/O。
Agent 会频繁扫描 Workspace、监听文件变化、读写代码、生成临时文件、执行 Shell、调用各种工具链。
If 文件挂载速度太慢，整个 Agent 会显得非常迟钝。
virtiofs 在这里的收益很明显：文件系统响应更自然，工具调用的等待感也会少很多。
所以最后选择的是：
Colima + vz + virtiofs
而不是 Docker Desktop。
真正吃内存的，很多时候不是模型 #
另一个长期被低估的问题，是 Context Window。
很多人会关注：“7B 能不能跑？”
但真正拖死机器的，有时候并不是模型参数，而是上下文。
因为 Agent 会不断读取代码、累积历史、生成 Tool Calls、写入 Memory、维护长期状态。
这些内容都会推高 Context 和 KV Cache 的压力。
有时候，一个 4B 模型开启很长的 Context，甚至比一个 7B 模型使用较短 Context 更容易把机器拖进 Swap。
所以本地 Agent 的核心问题已经不是：“模型能不能跑。”
而是：“Runtime 能不能稳定管理上下文。”
这也是为什么 Sandbox 不只是安全设施。
它同样是资源治理设施。
当 Workspace、文件系统、执行环境和上下文入口都被边界化之后，Agent 的行为会更可控，资源消耗也更容易被理解和调整。
实际效果与取舍 #
这套方案的目标不是让 16GB Mac Mini 变成高端工作站。
它解决的是另一个问题：
在有限内存下，让本地 Agent 尽可能稳定、可观察、可调试。
实际使用下来，几个变化比较明显：
- Docker Desktop 带来的常驻负担减少了
- Ollama 原生运行后，推理链路更直接
- Colima +
virtiofs下 Workspace I/O 更顺 - Agent 的文件访问边界更清晰
- 出问题时更容易判断是模型、Context、容器还是工具链导致的
当然，它也有取舍。
16GB 仍然不适合无限制地开大模型、长 Context、多浏览器和复杂 IDE 项目。
如果模型太大，Context 太长，或者 Agent 一次性扫描过大的代码仓库，系统仍然会吃紧。
所以这套方案更适合：
- 学习 Agent Runtime
- 跑中小模型实验
- 测试 Tool Calling
- 观察本地执行链路
- 搭建可控的个人 Agent 环境
它不是魔法。
它只是把混乱的资源竞争，拆成了更容易理解的几个边界。
OpenClaw 已经不太像传统 App #
这是整个项目过程中最大的感受。
OpenClaw 本质上已经不太像传统应用程序。
它更像：
- 一个 Runtime
- 一个 Orchestrator
- 一个 AI Shell
- 一个用户态调度层
它开始拥有文件系统、长期状态、Tool Calling、Context 管理和系统交互能力。
某种意义上，AI Agent 正在逐渐长成一种用户态操作系统。
这也是为什么 Sandbox 会越来越重要。
未来真正危险的，可能不再是：“模型说错话。”
而是：
模型做错事。
这是完全不同的风险等级。
本地 Agent，可能才是真正的未来 #
虽然现在很多 Agent 仍然运行在云端，但长期来看，我越来越觉得：真正强大的个人 Agent，一定会回到本地。
因为真正有价值的信息，本来就在本地：
- 文件
- 邮件
- 浏览器状态
- 工作目录
- 本地工具链
- 长期个人记忆
云端 Agent 很难天然拥有这些上下文。
但本地 Agent 天然具备。
未来很可能会形成一种新的结构：
- 云端负责更强的模型能力
- 本地负责执行、上下文和个人数据
而 Sandbox，会成为这两者之间最重要的边界之一。
Sandbox 并不能彻底解决问题 #
这个项目并不能彻底解决 AI Agent 的安全问题。
但它至少提供了一个重要方向：
不要默认让 AI 拥有整个系统。
未来的 AI 系统，应该更像现代 App：
- 最小权限
- 可隔离
- 可审计
- 可撤销
而不是一个无限制的超级进程。
OpenClaw 很有意思，因为它让很多开发者第一次真正看到：AI 开始从聊天窗口进入操作系统。
而当 AI 真正开始操作系统时，Sandbox 很可能会成为下一阶段最重要的基础设施之一。
如果你也在用 16GB Mac 跑本地 Agent，可以直接从这个 Sandbox 配置开始改。