https://x.com/yan5xu/status/2114574333423259682

回复 joye： 这条推的主张很明确：禁止 agent 直接通信，信息对齐走文档，功能对接走 API 或 MCP。论证是从“agent = prompt + 模型”推出的——既然通信的双方最终都只是把对方的输出塞进自己的 prompt，那不如把值得共享的信息直接放进共享的文档里，省掉一层。 这个思路有价值，但我觉得它是把“通信”和“上下文共享”当成了一回事，而这两件事在工程上并不是一回事。 第一，“只要能看到 prompt 就不需要通信”成立的前提，是双方可以共享同一份上下文。但现实里并行 agent 的上下文往往是故意隔开的：上下文窗口有预算，两个 agent 各自负责不同的子任务，不该互相污染内容，也不该多花几千 token 去看对方的全部历史。禁止通信再走文档，实际效果是让它们变成“定期对齐的异步协作者”，代价是延迟。所以真正的区别在于同步与异步的差异，而并非通信对不通信。 第二，文档只能承载“可描述的状态”，承载不了“事件”。Yoyfun 那条回复说的就是这个场景：一个负责开发的 agent 改完代码触发 HMR，需要通知专门跑浏览器验证的测试 agent 去拉代码验证。这件事在文档里怎么写？写“我已经改完了”吗？那测试 agent 得靠轮询才知道该动了。有了通信，就能省掉轮询，即时唤醒对方。MCP 也给不了这个能力——MCP 是拉取式的请求/响应，没有推送语义。所以“信息对齐走文档、功能对接走 MCP”覆盖不了的，恰恰是事件驱动的协调：谁该动、什么时候动。 第三，推里那句“怎么知道 prompt 哪些内容是值得被看的”，其实指向的是另一个问题：上下文的选择与压缩。这个我完全同意值得做，但它属于“写什么进文档”的质量问题，并不能推出应该禁止通信。文档写不好，agent 看不到关键信息就出事故，和通信不可靠是一个量级的风险。 我的立场是：默认用共享文档做状态对齐，这个应该成为规范，因为文档可审计、可 review、可回滚，还不会因为某个 agent 睡死而丢消息。但事件层要留一条明确的消息通道，并且要限流、要能审计，不能变成自由聊天。按 Cursor、Claude Code 那套 subagent 编排的经验，出事最多的其实就是 agent 间环形对话和互相甩锅，所以“禁止直接通信”作为默认值是对的，但当成硬规则会逼着人用轮询去模拟消息队列。 顺便，评论区提到的 obelisk 那条可以看看，它走的是“把历史 session 变成可被 query 的东西”这条路，正好是推文里那个“什么内容值得被看”的具体解法之一。