先给判断
当 Agent 要修改代码时，第一道安全问题不是“它聪不聪明”，而是“它会不会写进我正在编辑的目录”。Git worktree 解决的是工作目录隔离：多个目录可以挂在同一个仓库上，各自拥有 HEAD 和索引，同时共享对象和 refs。它非常适合定时任务、候选分支和并行实验，但不能冒充容器、权限系统或网络隔离。
worktree 实际分离了什么
Git 官方把 linked worktree 定义为同一仓库关联的多个工作树。每个工作树有自己的工作目录、HEAD 和 index；仓库的对象和大多数 refs 仍然共享。这个结构解释了两个看似相反的事实：一个 Agent 可以在独立目录里工作，不会覆盖另一个目录的未提交文件；但两个工作树仍然看到同一套提交对象和远程分支。
对内容流水线而言，这正是需要的边界。主 checkout 可以继续编辑；自动任务在临时 worktree 创建 bot 分支、构建文章和运行测试。最终能否进入 main，仍由 CI、分支保护和 fast-forward 规则决定。
一个最小操作模型
git fetch --prune origin
git worktree add -b codex/content-run /tmp/content-run origin/main
git -C /tmp/content-run status --short --branch
git -C /tmp/content-run rev-parse --git-common-dir运行结束后，先保存提交、测试和 receipt，再按仓库规则处理 worktree。不要在不确认路径的情况下使用 worktree remove；如果目录被手动删除，Git 的管理文件可能暂时残留，之后需要 git worktree prune 清理失效记录。清理是仓库维护动作，不是发布回滚。
为什么不能把 worktree 当沙箱
worktree 不限制进程读取其他路径，也不限制网络请求、GitHub 权限或 Cloudflare 操作。一个拥有写权限的 Agent 仍然可以从 worktree 访问远程、修改共享 refs 或运行发布脚本。因此真正的安全边界需要组合：最小凭据、只允许的命令、状态 branch 的 CAS、精确的公开集合和生产 smoke test。
同样，worktree 也不提供数据生命周期。被复制到临时目录的草稿、构建产物或日志仍然可能包含敏感内容；任务结束后的清理、忽略规则和 receipt 范围必须单独定义。
Agent 使用 worktree 的四条门
- 创建前确认基线，不能从不明 HEAD 开始。
- 工作树只包含本次候选，禁止顺手重构无关页面。
- 提交前检查
git diff --check、测试和精确 route delta。 - 生产成功后把事实写入唯一状态所有者；不要把本地 ignored 文件当作已发布证明。
这些门把 Git 的目录隔离和内容流水线的发布隔离接起来。它们不能证明 Agent 的代码正确，只能让错误更容易被定位和恢复。
什么时候值得用
定时内容生产、依赖升级、自动修复和多版本对比都适合 worktree。单人短任务且工作树干净时，直接在当前目录执行可能更简单；但一旦任务会跨越等待、CI 或外部发布，独立 worktree 的审计价值会快速上升。
来源与边界
Git 文档支持 worktree 的关联目录、共享 refs 和 prune 语义；OpenAI 文档支持在 Scheduled Task 中选择背景 worktree。本文关于 Omnihex 的 bot branch、状态 branch 和发布门，是仓库当前实现的工程应用，不是 Git 对 Agent 安全的承诺。