IPC：工件，而非对话

进程一旦必须协作，操作系统给它们一份小而固执的菜单：管道给邻居之间的流，消息队列给离散的包裹，共享内存给需要明确纪律的大宗数据，信号给一位的紧急情况。六十年的实践把一份信条压进了这份菜单：数据走存储，控制走消息——两者从不混淆，因为各自干对方的活都极其糟糕。

多 agent 系统正在以昂贵的方式重新发现这份信条。时髦的默认做法——agent 之间靠对话交换状态、记录在各分支间流淌——正是把两个通道搞混了。对话是被当成数据通道用的控制通道：合并需要结构时它是无结构的，记录需要耐久时它是易逝的，而且两头都按 token 计费。合并方随后要从对话里挖掘结论，连同对话里的含糊其辞、死胡同和自信的错误一起挖。

操作系统的答案可以逐字转写。共享内存 ↔ 黑板：分支把工件——发现、草稿、证据表——以声明好的格式写进共享存储，需要时免礼读走；一座建得好的 microsite 上的持久 store、被当作长期共享记忆的 corpus，就是这个形状。消息 ↔ 任务通道：派活、完成、阻塞、取消都是小的、带类型的、离散的——是包裹，不是意识流。信号 ↔ 中断：停止、超时、预算耗尽——一个比特，立即送达，先于一切处理。而管道保留它唯一诚实的用途：一条线性链，每个阶段的产出确实是下一个阶段的输入，不分叉，不合并。

有个流行框架的表达式语言借了管道的 | 符号，然后就止步于此——它拿了标点，没拿信条。Unix 里的管道是一份关于流的契约：单向、有界、有背压。没有契约的符号只是装饰。

判断任何 agent 间通道的方法就是操作系统的方法：载荷若是必须存活、必须被检查、必须被第三方核验，它就属于存储、是一件工件；若只是通知、中断、派活，它属于消息。对话——无界、无结构、不可检查——是没人做这个决定时剩下的东西。本系列要论证的，是这个决定几十年前就已经被正确地做过了。