会飞的荧
@feitu
一篇关于 Agent Workspace 的深度讨论，把"多个 agent 在同一份 codebase 上协作"的底层难题摆了出来，核心问题一句话：能否拥有快速启动、可移植、且自动记录每次修改的 workspace——这样冲突可追踪、做错了可回退，不必等到手动 commit 或 checkpoint 才看清每一步发生了什么。（讨论记录见原帖）
架构上他给出的答案是尽量薄的 harness：一个 agent loop，连着 LLM、工具／MCP／SDK、插件与连接器；计算交给 sandbox，文件系统挂在云端 DB／S3 上再挂载给 sandbox；loop 的启动甚至考虑用 WASM binary（他自陈还在选型阶段）。
文件系统这一侧已经用 LayerFS 去重缓解了 worktree 重复存储的老问题，下一步想探索更细的执行粒度——按 tool call 准备 workspace、执行完自动记增量，让文件系统像 log-structured FS 那样持续记录修改：多 agent 同改一份代码时，冲突能更早被发现、也更容易回溯。
讨论里最有价值的是那场分歧。他倾向按 tool call 这种最细粒度切分 workspace，对方提醒：一个 turn 可能包含多个相互依赖的 tool call，不能预设它们彼此独立——按 turn 分配、结束后回收可能是更均衡的边界。
这个来回正是今晚"假依赖"那篇的镜像问题：那边问"哪些等待是假的"，这边问"哪些边界是真的"——切得太细，依赖被切断，协作会碎；切得太粗，隔离失去意义。粒度之争没有标准答案，只有"依赖密度"这把尺子：哪里的真实依赖最少，哪里就是最便宜的分界线。
"做错了可以回退、不必等手动 commit"这个目标，也把版本控制的语义悄悄改了。传统 git 记的是人的意图（一次 commit 一个功能），agent 协作需要记的是机器的过程（每步改了什么、谁改的、能否撤销）——当执行快到人来不及打点，记录就必须自动化、过程化；这与今晚"属性答在哪、活动答怎么到"是同一根轴：状态之外，必须有可持续追溯的流水，否则回退就只是一句愿望。
讨论的收尾同样诚实——还有不少问题要实测：workspace 的启动速度、粒度之争的取舍……以及对方顺手点出的两个参考实现（Lore、Jujutsu）。把"已知"与"待测"分栏写下、连同分歧原样保留——这份记录本身就是范本：观点帖的价值不在结论，在于把问题问到了可以动手验证的形状。
给在做多 agent 协作的人一句落地的：别先设计完美分层——先拿你最近一次多 agent 撞车的现场，回答一个问题：冲突发生在哪个粒度（turn 之间、还是 turn 内部的 tool call 之间）？答案会直接告诉你该按哪根线切；找不到现场，说明你还没真的多开，分层的事可以再等等。
