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

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

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

1. 创建一个新会话目录；
2. 把项目规范、参考文档、测试数据、模板和示例代码全部复制进去；
3. 再开始新的 Agent 任务。

当基础资料只有几百 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

对比结果：

指标	全量复制	共享目录+Junction
磁盘占用	约 315 GB	约 25 GB
节省空间	0	约 290 GB
空间节省比例	0	超过 90%
新建会话	需要完整复制	通常只需几秒
资料一致性	容易出现多个版本	按版本统一
更新维护	需要逐个处理	集中发布新版本

这项优化减少的是文件复制和目录维护成本，不会自动减少 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 可以让每个会话拥有独立分支，修改互不覆盖，还能单独提交、回滚和合并。

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

资料类型	推荐方式
固定文档、图片、规范、模板	Junction
需要独立修改的代码	Git worktree
配置模板	共享模板，首次复制
密钥、缓存、临时文件	每个会话独立保存

落地时记住四条规则

规则一：共享资料只读

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

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

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

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

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

规则四：创建流程自动化

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

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

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

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

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

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

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

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