Deepthink 是一个基于 LLM 的多智能体系统，它能用多条并行的"策略分支"同时探索同一个问题的不同解法。当几十个智能体同时读写同一个沙箱仓库时，Git 共享工作区就成了解决"谁写哪里、怎么回滚、怎么剪枝"这一难题的核心机制。本文带你用大白话看懂：一个普通 Git 仓库，是如何同时服务多路并行写入，并支撑回滚与剪枝操作的。

为什么多智能体并行写入是个难题？

想象一下这个场景：Deepthink 收到一个问题后，会先生成 3~4 个不同的解题策略（Strategy），每个策略就是一条"分支"。之后：

• 每条分支的"解题智能体"会并行写出自己的解法
• "评审智能体"并行评审每条分支
• "假设测试智能体"并行验证各种猜想

如果这些智能体随便往仓库里写文件，很快就会互相覆盖、彼此污染。Deepthink 的答案其实很朴素：把"写权限"切得足够碎，让冲突根本不可能发生。

单仓库、单分支：为什么不用 Git 分支？

一个反直觉的设计是：整个仓库只有一个 Git 分支、一棵工作树。所有策略目录（Strategy-1/、Strategy-2/……）并排放在仓库根目录下。

你可能想问：为什么不给每条策略建一个 Git 分支？规格说明文档 Deepthink_Consolidated_Specification.md 的 §8.2 给出了理由：

1. Git 工作树同一时刻只能检出一个分支。如果每个策略一个分支，切换 HEAD 时其他策略的文件夹就会从磁盘上消失，而所有分支必须"同时"在磁盘上可读；
2. 回滚靠的不是 Git 分支。因为每条策略独占一个文件夹，任何两个策略都不会改动同一个文件，所以单独恢复某一个文件夹，完全不会碰到别人的内容。

仓库的整体布局大致如下（摘自 DeepthinkDocs.md 的 Repository 章节）：

repo/ ├── shared_workspace.md 实时共享文档（≤5000 tokens，不提交） ├── tmp/ 共享的草稿与验证脚本目录（不提交） ├── strategies_history/ 策略生成历史 ├── Pruned_Strategies/ 被剪枝归档的策略 ├── Strategy-1/ │ ├── strategy.md │ ├── 解法文件 │ └── history/ 每轮迭代的解法、评审、记忆库 └── Strategy-2/

并行写入的秘诀：目录级写权限隔离

Deepthink 的做法是"写自己的，读所有人的"：

具体实现见 sandboxAccess.ts 中的buildDeepthinkSandboxRepositoryAccess（约 L76）——它为每个智能体角色构建一个最小权限视图：能写哪儿、能读哪儿、哪些目录对它隐藏，全部由代码精确规定。比如：

• 解题智能体能看到同侪分支的目录（以便学习别人哪里走通了），但被隐藏了自己分支下的Critique/子目录，防止"偷看答案"；
• 记忆库、BSR（分支状态评审）智能体只允许读取本分支目录，属于只读角色；
• 谁也不能直接写仓库根目录或.git。

这样，几十路并行写入天然就不会撞车——因为没有任何两个智能体拥有同一个文件的写权限。

提交策略：少提交，但每次都是"完整快照"

既然智能体不碰 Git，那么谁来提交？答案是harness（编排器），而且只在一个时刻提交：迭代屏障（barrier）——即一轮迭代中所有分支全部完成后。

为什么要这么设计？gitRepository.ts 的注释（L98-L101）解释得很清楚：

提交是串行执行的，一次只碰一个策略目录。

原因有两点：Git 仓库每次写操作都会加锁，两个提交撞在一起必然有一个失败；而所有策略又是同一轮结束、同时完成的，正好是并行提交最可能冲突的时刻。因此 harness 选择在"没有任何智能体在写"的屏障时刻，逐一提交每个策略目录（commitStrategyIteration，约 L102），保证每次提交都不会捕获到半写的文件。

提交被刻意保持得很少，但每类提交都有明确用途：

1. 迭代提交：每轮结束后，每个策略文件夹单独提交一次——这是回滚的目标点；
2. 窗口起点提交：每次全局更新完成后，再把每个存活分支提交一次（commitWindowStart，约 L128）——这是"回滚到窗口起点"的锚点；
3. 心跳 / 历史提交：假设心跳结束、策略历史文件写入后，提交共享目录。

回滚与剪枝：Git 如何救回走偏的分支

这是共享工作区最有意思的部分。每隔若干轮，系统会做一次"全局更新"：BSR 智能体先汇报每条分支的进展，再由固定公式（而不是某个智能体的主观判断）得出四种结果之一——继续、原地进化、带回滚进化、剪枝。前两种不涉及仓库变更，后两种则由 harness 直接操作 Git：

回滚（EVOLVE with rollback）

当一条分支"开局不错、后来越走越偏"时，harness 会把它恢复到最后一个好的迭代（rollbackStrategy，gitRepository.ts 约 L208）。规格文档描述了具体过程：

1. 对该文件夹执行git rm -r和git clean -fd，清掉上次提交后残留的半成品文件；
2. git checkout <commit> -- Strategy-N，把该文件夹检出到指定迭代的提交状态；
3. git commit提交恢复结果。

注意这是一个revert 而非 reset：被丢弃的迭代只是离开了工作目录，它们仍然完整保留在 Git 历史里，随时可查。而且因为每条策略独占文件夹，这次恢复不会碰到任何一条其他分支。

剪枝（PRUNE）

当一条分支彻底卡死、没有值得保留的进展时，harness 会把它整个归档（pruneStrategy，约 L221）：

git mv Strategy-1/ Pruned_Strategies/Strategy-1_pruned_01/

然后用序号（_01、_02）避免复用槽位时与旧档案冲突，并为这个槽位建一个全新的空Strategy-1/。新分支从第一行策略文本开始，干干净净；旧分支的全部历史依然躺在Pruned_Strategies/里，没有销毁任何信息。

实时协作通道：5000 token 的共享文档

Git 负责"可追溯"，但智能体之间还需要一条实时沟通通道。这就是仓库根部的shared_workspace.md：所有智能体都能通过shared_workspace工具读它、精准编辑它、追加它，用来交换验证过的中间结论、公式和不变量。

sharedWorkspace.ts 里有三个精巧的设计，保证了"实时协作"不会变成"实时互踩"：

1. 串行写入队列：SharedWorkspaceManager（约 L111）内部维护一个 Promise 队列（enqueue，约 L241），所有并发写入被强制排队执行，从根源上消除写冲突；
2. 5000 token 硬上限：每次edit或append后都会计数，超限直接拒绝，并提示智能体先清理过时内容再更新（约 L134-L208）；
3. 禁止整文件覆写：智能体只允许edit（指定old_string精确替换）或append（追加），想write整个文件会被明确拒绝——"防止覆盖同侪智能体的工作"。

值得一提的还有tmp/目录：它是所有智能体共享的未跟踪草稿区（通过.gitignore排除在 Git 之外），专门放验证脚本、测试脚手架和临时文件。shared_workspace.md和tmp/都不进 Git 历史——因为实时协作的内容变化太频繁，跟踪它们只会制造冲突和噪音。

关键代码与文档索引

想继续深挖的同学，可以从这几处入手：

• Git 操作核心：gitRepository.ts —— 上下文文件提交、迭代屏障提交、窗口起点提交、回滚与剪枝归档；
• 权限模型：sandboxAccess.ts —— 按角色构建最小权限仓库视图与目录策略；
• 共享文档管理器：sharedWorkspace.ts —— 串行写入队列与 token 上限控制；
• 沙箱运行时接口：SandboxToolRuntime.ts —— 快照、恢复策略目录、归档策略目录等后端 API；
• 权威规格说明：Deepthink_Consolidated_Specification.md §8（Repository and access）与 DeepthinkDocs.md 的 Repository 章节。

小结：这套设计值得借鉴什么

Deepthink 的 Git 共享工作区，本质上是把三个经典问题拆解成了三个简单答案：

没有分布式锁，没有复杂的合并策略，甚至没有每个智能体一个 Git 分支——仅仅是目录隔离 + 串行提交 + 最小权限这三条朴素的规则，就让一个普通仓库稳稳支撑起了多路智能体的并行协作。如果你正在设计自己的多智能体系统，这个"先想清楚谁有写权限"的思路，值得抄走。