用途：这是一条并发设计原则，适用于多个并发执行者（如智能体、goroutine、进程）可能写入同一文件、分支、键或状态对象的场景。核心主张是先判断这些执行者是否真的需要同一个可变对象；若不需要，就消除共享；若共享是真实不变量，再用结构化方式强制串行化。
主要能力与要点：
- 识别共享可变状态，例如双方都读写的文件、都推送的分支、都定义并消费的 API。
- 默认做法是消除共享写入目标：给每个执行者独立的文件、键、分支或状态目录，只在读取或汇报边界合并。示例：两个 worker 各自把 lastX 字段写进同一个 state.json 仍属共享变更；拆成 indexer-state.json 与 metrics-state.json 则不是。
- 只有当单一共享写入目标确实是真实不变量时，才结构化串行化访问，手段包括锁文件、顺序阶段、单写入者执行者或原子 compare-and-swap。
- 把“我们需要一把锁”视为需要检查的设计异味，而不是默认答案。
原因：对共享状态的并发写入会产生竞态条件，这类问题间歇出现、难以复现、调试成本高；仅靠告诉智能体或 goroutine“轮流来”并不起作用，指令和约定不是并发控制。
限制：资料未提供具体实现代码、安装命令、平台支持或收费信息，暂未提供。