我给AI代理配备邮件而非更好推理能力，它们开始互相修复代码错误。

我见过的大多数多代理设置都将代理视为孤立的工人。每个代理获得一个任务，执行它，返回结果。彼此之间没有意识。没有协调方式。只是并行执行，共享一个剪贴板。我一直在公开构建一个多代理框架。出乎我意料的是，最重要的竟然不是推理能力，而是通信。在我的系统中，每个代理都是一个领域专家。邮件系统只关心邮件。路由系统只关心路由。它们生活在各自的目录中，拥有自己的身份文件、自己的记忆、自己的测试。每次会话都会触发一个钩子，在任何其他操作之前加载身份。没有代理会冷启动。问题在于协调。代理无法写入自己目录之外的文件——有一个硬性阻止跨分支写入的机制。这是设计使然。但这也意味着，一个发现别人代码有bug的代理不能直接去修复它。所以我给了它们电子邮件。我原本以为：代理们会共享数据。传递结果。也许同步状态。但实际发生的是：它们做的第一件事就是互相提交错误报告。一个代理在另一个代理的域中发现了一个测试失败。它发送了一封电子邮件：“嘿 @routing，当你分支名中包含点时，你的路径解析会失败。这里是回溯信息。”路由代理被唤醒，读取邮件，然后修复了问题。没有人类介入其中。 “send”和“dispatch”之间有区别——send只是把信件投进邮箱。dispatch则是投递信件并同时按响门铃。它会启动代理并将其指向收件箱。 drone @ai_mail send @routing "Bug report" "Path fails on dotted names..." drone @ai_mail dispatch @routing "Fix needed" "Traceback attached..." Send = 邮件。Dispatch = 邮件 + 唤醒。 邮件代理有696个测试。不是因为有人坐下来写了696个测试用例。而是因为它在生产环境中不断出错，每次修复都增加了一个测试。路由系统有80多个会话的经验，只做路由这一件事。这些代理之所以可靠，并不是因为它们有更好的模型——而是因为它们几个月来一直在失败和修复。代理们可以自由地互相调度。如果测试运行器在另一个代理的代码中发现了一个bug，它会直接唤醒那个代理。协调器无需批准。只有协调器本身被保护，不会被调度——你不想让一个工作代理为了杂活而唤醒CEO。安全强制机制并非传统方式。代理无法通过直接写入另一个代理的收件箱文件来伪造消息——它们必须使用邮件系统。写阻止也是如此。是硬性强制，而不是“请勿”。 有一个监控层，这样我就不会盲目飞行。每个代理操作都有音频提示——我无需盯着终端就能听到正在发生什么。实时仪表板显示一切。如果一个代理遇到相同的错误2-3次，观察者会捕捉到模式并调度正确的专家进行调查。我通过可见性而非审批关卡保持参与。 整个项目是开源的。pip install aipass + 两个初始化命令即可运行。基于CLI，构建在Claude Code上。目前专注于Linux。 [https://github.com/AIOSAI/AIPass\](https://github.com/AIOSAI/AIPass) 真心提问——有其他人尝试过给代理通信能力而不是仅仅更好的推理吗？我看到的一切都是关于让单个代理更聪明。似乎没有人在构建协调层。