问题：让两个Claude代码实例对话
一位开发者遇到了一个有趣的挑战：他同时运行着两个Claude Code会话，一个负责后端代码编写，另一个执行测试。他设想，如果这两个AI实例能够直接“对话”，那将是一件非常酷的事情。尽管这最终花费了数天时间，涉及了未公开的API，并让他对Windows文件锁定机制有了超乎寻常的了解，但这个设想最终得以实现。
为何选择文件而非HTTP？
当在同一台机器上运行多个AI代理时，使用HTTP进行通信效率低下。共享文件系统是更自然、更高效的选择。基于文件的消息传递方案提供了多项优势：
- 零基础设施： 无需服务器、端口或Docker容器。
- 免费离线投递： 消息文件会一直保存在目录中，直到被读取。
- 原子写入： 通过临时文件写入并重命名的方式，确保了消息读取的完整性，避免了部分读取。
- 易于调试： 消息是纯JSON格式。
cat inbox/*.json即可作为简单的监控工具。
整个通信机制非常直观：Agent A写入一个JSON文件，Agent B的MCP服务器轮询目录，读取文件，然后将其推送进会话。
该图展示了消息如何在Agent A和Agent B之间通过文件系统流转：Agent A的MCP服务器轮询to-brave-fox/inbox/目录接收消息，并通过send工具将消息发送到to-calm-owl/inbox/目录，供Agent B的MCP服务器读取。
MCP通道的探索
Claude Code包含一个实验性功能，称为“channels”（通道）。通过该功能，MCP服务器可以直接向聊天会话推送通知，而无需用户进行任何操作。这就是cc2cc实现实时消息投递的关键，省去了用户主动询问“有新消息吗？”的步骤。
然而，这个功能隐藏在一个名为--dangerously-load-development-channels的标志后面。这个名称本身就带有警告意味，表明其处于开发阶段且未受官方支持。其文档几乎不存在，开发者通过阅读Claude Code源代码、反复试错以及大量调试才摸清了它的工作原理。
经过一番探索，开发者发现直接使用claude --dangerously-load-development-channels或claude --dangerously-load-development-channels cc2cc是无效的。正确的用法是：
claude --dangerously-load-development-channels server:cc2cc
这个server:前缀的发现，是解决问题的关键一步。
自唤醒：让AI代理自我启动
一个有趣的限制是：MCP服务器是被动的。它们响应工具调用，但不能主动发起调用。这意味着你的AI代理在技术上是“活跃”的（服务器正在运行、轮询并随时待命），但Claude Code...