系列：给 AI Agent 做隔离（1）——一台开发机上的最小可行方案

本系列面向个人开发者与小团队，讲如何把「能跑命令的 AI 助手」关进可管理的边界里。
第 1 篇只做一件事：在你自己的电脑上，搭一套 今天就能用 的最小隔离。

最近行业里又出现了关于 AI 代理越权与沙箱边界的公开讨论。我不在这里复述新闻，只把结论落到操作：

默认信任 Agent，成本会越来越高；默认隔离 Agent，成本主要在一次性配置。

---

目标

完成后你应该得到：

1. 一个专用目录作为 Agent 工作区
2. 一个不能看到 $HOME 隐私文件的容器/环境
3. 一套「先看建议，再确认执行」的习惯

---

步骤 1：单独工作区

mkdir -p ~/agent-workspace
cd ~/agent-workspace

原则：

• 只把当前任务仓库放进来
• 不要把整盘文档、下载目录、桌面挂给 Agent

---

步骤 2：用容器跑命令（示意）

下面是思路示意，请按你本机 Docker/容器工具调整：

docker run --rm -it \
  --network none \
  -v "$PWD":/work \
  -w /work \
  your-dev-image:latest \
  bash

关键点：

• --network none：先断网，需要装包再临时开放
• 只挂载 $PWD：缩小文件系统可见范围
• 不要挂载 ~/.ssh、~/.aws、密码管理器目录

---

步骤 3：密钥隔离

把生产环境变量放到工作区之外，例如系统钥匙串或独立密管。

Agent 需要云权限时：

• 使用 临时凭证
• 过期时间尽量短（分钟到小时级）
• 权限只覆盖当前任务资源

不要把长期 AdministratorAccess 写进 .env 再让 Agent「自己看着办」。

---

步骤 4：执行策略（个人版）

给自己定三条硬规则：

1. Agent 可以改文件，但不能直接 git push 到 main
2. 任何删除、权限变更、外连脚本，必须人眼确认
3. 陌生仓库先在容器里打开，再决定是否信任

这三条不依赖某个厂商功能，换 Cursor、Codex、CLI Agent 都适用。

---

步骤 5：留一点审计

哪怕只是本地记事：

2026-07-23 15:10  允许运行 pytest
2026-07-23 15:22  拒绝执行 curl ... | bash

出了问题，你至少知道「哪一步是自己放行的」。

---

下篇预告

第 2 篇计划写：小团队如何给 Agent 发「工牌」（独立云子账号 + 工具网关思路）。

如果你已经在用某套隔离方案，欢迎留言你的做法——系列会优先补大家真正卡的地方。