Hermes-백채널

Source: Dev.to

내 AI 에이전트들이 Discord 봇을 통해 대화하고 있었다. 드디어 해결했다.

GitHub repo:

나는 PC에서 세 개의 Hermes 에이전트를 별도 프로세스로 실행한다. 이들은 협업해야 하지만, 며칠 동안 전혀 협업하지 못했다. 아래는 내가 시도한 모든 방법과 각각이 실패한 이유다.

Files on a cron job

에이전트 A가 공유 폴더에 마크다운 파일을 떨어뜨린다. 에이전트 B의 크론이 60 초 후에 이를 가져와 답장을 쓰고, 에이전트 A의 크론이 그로부터 또 60 초 뒤에 가져간다.

예/아니오 질문 하나에 두 분이 걸렸다. 나는 실행기 에이전트가 “use port 8080 not 3000”이라는 메시지를 받기 위해 58 초 동안 대기하는 모습을 보고 이 방법은 끝났다고 판단했다.

HTTP endpoints

각 에이전트가 포트를 바인딩하고 /receive 라우트를 노출한다. JSON을 POST 하면 200을 반환한다.

이제 포트, 인증 토큰, 같은 박스 안 프로세스 간에 문자열만 주고받는 메시지에 대한 직렬화 오버헤드를 관리해야 한다. 어느 날 밤 ss -tlnp를 실행해 포트들을 확인하고 스스로에게 물었다: 왜 머신이 스스로와 대화하기 위해 웹 서버를 운영하고 있지?

Redis

“그냥 Redis pub/sub을 써라.”

그리고 맞다 — PUBLISH agent:executor "hello"는 즉시 전달된다. 완벽히 동작한다.

하지만 이제 Redis는 내가 운영해야 하는 서비스가 되었고, 모니터링 대상이 되었으며, 공격 표면에 추가된 존재가 되었다. 로컬호스트에서 문자열을 주고받는 세 개의 프로세스에 메시지 브로커를 설치하는 것은 마치 트렁크를 열기 위해 견인 트럭을 부르는 것과 같다.

Discord bots

여기가 바닥을 친 순간이다. 세 개의 에이전트 정체성, 세 개의 Discord 봇 사용자, 하나의 비공개 서버. 서로에게 메시지를 입력했다.

동작했다. 그리고 말도 안 되는 일이었다.

What I actually built

나는 실제로 필요했던 것을 포스트‑잇에 적었다:

• 같은 머신에 있는 세 개의 프로세스
• 텍스트 전송
• 수신 여부 확인
• 포트, 서비스 없음
• 1 ms 이하 지연

Unix 도메인 소켓이 모든 요구사항을 만족한다. 파일이기 때문에 chmod 0600만 하면 소유자만 접근한다. 커널이 모든 것을 관리한다. TCP도, 포트도, 외부 의존성도 없다.

그래서 나는 얇은 레이어를 만들었다: 에이전트당 작은 데몬 하나. 메시지는 푸시‑앤‑디스커넥트 방식으로 전송되며, 지속적인 연결이 없다. 에이전트는 데몬에 “내게 온 메시지가 있나요?”라고 폴링한다. 전체 구현은 파이썬 몇 백 줄, pip install 하나면 된다.

실제 혁신 — 내가 새롭다고 주장하는 부분 — 은 세션 프로토콜이다. TCP‑스타일 핸드쉐이크: SYN, SYN‑ACK, DATA, FIN, FIN‑ACK. 메시지가 전달됐는지, 상대 에이전트가 작업을 수락했는지, 대화가 언제 끝나는지를 실제로 알 수 있다. 오늘날 대부분의 에이전트 통신은 “문자열을 던지고 기도한다”식이라, 실제 작업을 조율해야 하는 에이전트에게는 부족했다.

Why this matters

멀티‑에이전트 시스템을 구축하면서 파일이나 HTTP를 통해 에이전트가 서로 대화하게 만든다면, 수십 년 전 커널이 해결한 문제에 지연과 복잡성을 낭비하는 것이다.

이것은 프레임워크도 아니고 워크플로를 오케스트레이션하지도 않는다. 단순히 에이전트 프로세스 간에 메시지를 신뢰성 있게, 1 ms 이하의 지연으로, 확인과 함께 전달한다. 그것이 전부다.