Hermes-后通道

Source: Dev.to

我的 AI 代理通过 Discord 机器人进行对话。终于把它修好了。

GitHub 仓库：

我在一台电脑上以独立进程运行了三个 Hermes 代理。它们应该能够协同工作，但好几天都做不到。下面是我尝试的所有方法以及每种方法的失败原因。

在 cron 任务中使用文件

代理 A 在共享文件夹中放置一个 markdown 文件。代理 B 的 cron 在 60 秒后取走它，写下回复，随后代理 A 的 cron 再在 60 秒后取走回复。

一个是/否问题花了两分钟。我看到执行代理空等了 58 秒，等着收到 “use port 8080 not 3000”，于是认定这种方案已经不可行。

HTTP 接口

每个代理绑定一个端口并暴露 /receive 路由。POST 一段 JSON，返回 200。

现在我需要管理端口、认证令牌以及仅在同一台机器上进程间传递的字符串消息的序列化开销。我某晚运行 ss -tlnp，看到这些端口后自问：为什么我要为机器内部的通信跑一个 Web 服务器？

Redis

“直接用 Redis pub/sub 吧。”

确实，PUBLISH agent:executor "hello" 能立刻送达，运行得很完美。

但这时 Redis 成了我需要维护的服务，成了我的攻击面。对于在本地主机上相互传递字符串的三个进程来说，部署一个消息中间件就像叫拖车去打开手套箱一样夸张。

Discord 机器人

这一步把我逼到了谷底。三个代理身份，三个 Discord 机器人用户，一个私有服务器。它们相互发送消息。

它能工作，但太荒唐了。

我真正构建的东西

我把实际需求写在便利贴上：

• 同一台机器上的三个进程
• 发送文本
• 知道是否已收到
• 不需要端口、服务
• 延迟低于一毫秒

Unix 域套接字满足所有需求。它们是文件——chmod 0600，只有拥有者可以访问。内核负责一切。没有 TCP、没有端口、没有外部依赖。

于是我在此之上写了一层薄薄的包装：每个代理对应一个小守护进程。消息采用推送‑断开模式——没有持久连接。代理轮询其守护进程：“有给我的消息吗？”整个实现用 Python，几百行代码，只需要一次 pip install。

真正的创新——我认为是全新的——是会话协议。类似 TCP 的握手：SYN、SYN‑ACK、DATA、FIN、FIN‑ACK。你可以确切知道消息是否已送达，对方是否接受了任务，以及对话何时结束。如今大多数代理通信都是 “扔个字符串然后祈祷”，这对需要协同完成实际工作的代理来说显得不够可靠。

为什么这很重要

如果你在构建多代理系统，而让代理通过文件或 HTTP 互相通信，你就在为一个内核早已解决的问题浪费延迟和复杂度。

它不是一个框架，也不负责编排工作流。它仅仅是可靠地在代理进程之间传递消息，延迟低于一毫秒，并提供确认。这就是全部。