AI Agent 越开越多，磁盘快满了？试试 Codex 共享资料架构

AI 编程助手、Agent、上下文工程和多会话协作正在成为日常开发的一部分。但如果每个 Codex 会话都要复制一整套基础资料，效率提升很可能先被文件管理拖慢。

一个常见但隐蔽的效率陷阱

很多团队已经开始用 Codex 等 AI 编程助手处理需求分析、代码生成、测试修复和文档整理。为了让每个会话拥有独立的工作目录，常见做法是：

当基础资料只有几百 MB 时，这个做法还不明显。一旦资料增长到 10 GB，且同时运行 20 到 30 个会话，问题就会集中出现：

• 磁盘空间被大量重复文件占满；
• 新会话启动需要等待完整复制；
• 资料更新后，不同会话使用的版本不一致；
• 多个会话修改同一份文件，容易互相覆盖；
• 每个项目都需要重新维护一套目录初始化流程。

真正的问题不是复制速度不够快，而是把“共享基础资料”和“会话私有修改”混在了一起。

核心方案：共享资料集中管理，会话目录独立运行

推荐采用两层结构：

D:\\codex\\
├─ shared\\
│ ├─ base-v1\\
│ └─ base-v2\\
└─ sessions\\
├─ session-001\\
│ ├─ reference
│ ├─ work
│ ├─ output
│ └─ session.json
└─ session-002\\
├─ reference
├─ work
└─ output

各目录职责非常明确：

• shared：集中保存所有会话都会使用的基础资料；
• base-v1、base-v2：基础资料的不可变版本；
• reference：当前会话访问共享资料的入口；
• work：当前会话的代码修改、分析结果和临时文件；
• output：最终交付文件；
• session.json：记录会话使用的资料版本。

这样，每个会话仍然拥有自己的工作目录，但不再复制完整资料。

Junction：Windows 上的目录级共享入口

Junction 是 Windows 提供的一种目录联接。它类似于目录快捷方式，但应用程序访问时会把它当作普通文件夹。

例如，下面两个路径可以指向同一份内容：

D:\\codex\\shared\\base-v1
D:\\codex\\sessions\\session-001\\reference

会话访问：

D:\\codex\\sessions\\session-001\\reference\\README.md

实际上读取的是：

D:\\codex\\shared\\base-v1\\README.md

资料只存储一份，reference 只是一个访问入口。

创建 Junction 的 PowerShell 命令如下：

New-Item -ItemType Junction `
-Path "D:\\codex\\sessions\\session-001\\reference" `
-Target "D:\\codex\\shared\\base-v1"

也可以使用 Windows 命令：

mklink /J "D:\\codex\\sessions\\session-001\\reference" "D:\\codex\\shared\\base-v1"

Junction 主要用于本机目录，不适合直接指向网络共享路径。如果共享资料位于 NAS 或网络盘，需要改用网络映射、同步工具或其他远程存储方案。

还要特别注意：Junction 本身不提供权限隔离。通过 Junction 修改文件，实际上就是修改共享目录中的原文件。因此，reference 应当设置为只读，或至少通过文件权限和流程约束禁止写入；需要修改的内容，应保存到当前会话的 work 或 output 目录。

新会话如何使用共享资料？

建立好 reference 目录后，可以在新会话的第一条消息中加入明确规则：

本会话需要使用共享基础资料。
​
请将当前会话目录下的 reference/ 作为共享资料目录：
​
– 先读取 reference/README.md 和 reference/manifest.json，如果存在；
– reference/ 中的内容只允许读取，不要修改、删除或复制整个目录；
– 需要生成或修改文件时，将结果保存到当前会话目录下的 work/ 或 output/；
– 优先复用 reference/ 中已有的资料，不要重新创建同类文件；
– 如果发现资料缺失、版本不匹配或无法访问，请先说明问题；
– 本会话使用的共享资料版本是 base-v1。

之后只需要补充具体任务：

请基于 reference/ 中的项目规范完成本次任务。
代码修改放在 work/，最终文件放在 output/。

为了让这套规则长期生效，可以把它写入每个会话目录根部的 AGENTS.md。在当前会话工具会自动读取该文件的前提下，新会话就不需要重复解释目录职责和读写边界；如果工具不会自动读取，仍应在第一条消息中发送上述规则。

基础资料更新：不要覆盖，使用版本化发布

共享资料更新时，不建议直接修改正在被多个会话使用的目录，而应该发布新版本：

shared\\
├─ base-v1\\
├─ base-v2\\
└─ base-v3\\

例如：

• 旧会话继续使用 base-v1；
• 新会话使用 base-v2；
• 验证新版本稳定后，再逐步迁移旧会话。

每个会话可以记录自己的资料版本：

{
"session": "session-001",
"baseVersion": "base-v1",
"createdAt": "2026-08-28T10:00:00+08:00"
}

这种方式能保证任务可复现，也避免基础资料更新后突然影响正在执行的 Agent 任务。

效果评估：磁盘占用可减少 90% 以上

假设：

• 基础资料大小为 10 GB；
• 每个会话的私有文件为 0.5 GB；
• 同时运行 30 个会话。

全量复制

30 × (10 + 0.5) = 315 GB

共享目录

10 + 30 × 0.5 ≈ 25 GB

对比结果：

这项优化减少的是文件复制和目录维护成本，不会自动减少 AI 模型读取文件时的上下文消耗。因此，基础资料仍然需要保持目录清晰，避免把无关的大文件全部暴露给每个会话。

代码项目应使用 Git worktree

Junction 适合固定文档、图片、规范、模板和只读数据。如果多个会话都需要独立修改同一个代码项目，更适合使用 Git worktree：

git worktree add `
"D:\\codex\\sessions\\session-001" `
-b "codex/session-001" `
HEAD

这里使用 HEAD 可以兼容默认分支名为 main、master 或其他名称的仓库；如果仓库明确使用 main，也可以将 HEAD 替换为 main。

Git worktree 可以让每个会话拥有独立分支，修改互不覆盖，还能单独提交、回滚和合并。

可以按照下面的原则选择方案：

落地时记住四条规则

规则一：共享资料只读

避免某个会话意外修改公共文件。

规则二：基础资料必须版本化

不要在一个“当前版本”目录中直接覆盖文件，应创建 base-v2、base-v3。

规则三：输出必须归属会话

代码修改、日志、缓存、临时文件和最终交付物，都保存到当前会话目录。

规则四：创建流程自动化

用一个 PowerShell 脚本自动完成目录创建、Junction 建立、版本记录和规则文件写入，避免人工操作出错。

结语：让 AI 会话拥有独立性，也拥有共享能力

多会话协作的效率瓶颈，往往不在 AI 模型本身，而在资料组织方式。

当每个会话都复制一份基础资料时，存储、时间和版本维护成本会随着会话数量线性增长；当共享层和会话层被拆开后，系统就能同时获得：

• 独立的会话工作空间；
• 统一的基础上下文；
• 更快的 Agent 启动速度；
• 更低的磁盘占用；
• 更清晰的版本追踪；
• 更少的文件覆盖风险。

对于固定资料，使用 Junction；对于需要独立修改的代码，使用 Git worktree；对于敏感信息和临时文件，坚持会话隔离。

这不是单纯的目录技巧，而是一种适合 AI 编程助手时代的工作空间设计：

共享知识，独立执行；统一上下文，隔离变化。