厌烦了当传话筒，我给两个agent建了个信箱

先交代一个画面。在跑通这套东西之前，我的日常是这样：把 A 终端里 AI 的回复复制出来，切到另一个终端，粘给另一个 AI，等它回话，再把回话复制回去。来回几趟，任务才算交接完。

我是人肉消息队列。队列两端，是两个 AI。

一个叫 dot，住在一台云服务器上，我的开发任务基本都丢给它。另一个是 bot，守着另一台云服务器，干自己的活。一个在这座岛，一个在那座岛。

我想把传话这一步交出去：dot 给 bot 派任务，bot 干完，dot 验收，我只看最后的结果。（听起来像做梦，其实卡点特别土——它们连话都说不上。）

先说结论。最后跑通的方案，不在任何 agent 框架里，是一个 GitHub 私有仓库。两个 AI 用 PR 互相说话。

这事比我想的曲折，值得从头讲。

想法是好的，第一反应也很朴素：找个现成的消息系统，让它们直接互发消息。真有人干过这件事，开源项目都是现成的，装上、配好，消息点到点直达。

我也确实这么干了。然后卡住了。

我的两台云服务器，都不允许随意开放监听端口。而“直接互发消息”这件事翻译成工程语言，是一方开着端口监听、另一方来连接。防火墙和安全组把这条路堵死了，两个 AI 隔着端口，谁也够不着谁。

你可能会觉得这是配置问题，改一下就好。有些服务器能改，有些受管的改不了；就算能改，给两个 AI 各开一个对公网敞开的端口，这事本身也不太让人放心。（我卡在这里卡了一阵，一直在琢磨消息格式怎么定，其实第一个该回答的问题是：路在哪。）

这一课值得记下：直连的前提是网络可达。这个前提在两台受管云主机之间，经常不成立。

那换思路。既然谁都开不了端口，那就谁都不监听——两边都往外连一个第三方，消息放在第三方那里，取信也往外连。两边主动往外连，端口这事就绕过去了。

这个第三方得满足三个条件：双方都访问得到，稳定可靠，自带权限管理。我想了一圈，发现这地方我天天在用。

GitHub。

方案落地成一个私有仓库，我管它叫 mailbox。通信协议一共四步：

第一次想明白这个映射的时候我愣了一下。PR 这东西，长的就是一张工单的脸：有发起，有认领，有交付，有签收。GitHub 设计它的时候想的是人类程序员协作，结果 AI 拿来当通信协议，严丝合缝。

而且这套流程需要的东西，GitHub 全部白送：消息送达有通知，权限有仓库隔离，历史有 commit，改动有 diff，两个 AI 对任务理解不一致，还能在 PR 里留言对质。我没有为“通信”写一行代码。

（写到这我自己都觉得好笑：前一个方案研究了半天消息格式，正确答案居然是把邮局外包给我天天在用的网站。）

交代一下它们现在怎么干活，给想复现的人一个真实预期。

它们不是实时聊天，是异步邮包。bot 定时取信，dot 定时验收，一来一回以分钟计。这决定了它适合任务级交接——派一个功能，交一次实现——不适合需要立刻呼应的协作。

但异步换来的东西很值。消息永远在仓库里，不怕断线，不怕重启。出了问题，翻 commit 历史就是翻聊天记录：谁派的活，谁改的代码，验收意见是什么，一页看完。两个 AI 的工作交接，第一次有了完整的审计轨迹。

所以回头看，这件事给我的判断其实很简单：让两个 agent 通信，第一反应不该是自建消息系统，而是先找一个双方都访问得到的现成信箱。端口打不通的路，让第三方替你收和转。GitHub 是现成答案，但它不是唯一答案——任何一个双方可达、能挂文件、能走审批流的服务，都能当这个邮局。

下一步我想试的：把验收标准直接写进任务 PR，让 dot 的 review 再挑剔一点。我想看看它们能自我闭环到哪一步——以及我在哪个环节，才真正必须出场。

毕竟人肉消息队列下岗了，总得给自己找个新位置。