tmux-msg-for-ai：基于 tmux 的 Agent 间消息总线，为 Claude Code 多会话协作而生

多 Agent 系统的老大难问题是什么？让多个 AI 会话之间互相通信。

Claude Code、ChatGPT、Cline 这些 AI 编程工具，每个都跑在独立的会话里，有自己的上下文窗口、自己的执行流程。你让它们各干各的没问题，但想让 Agent A 做完某件事后告诉 Agent B「你该开始了」，或者 Agent B 做一半需要 Agent A 的中间结果——这就尴尬了，它们之间没有天然的通信渠道。

2026 年 7 月 28 日，一个叫 tmux-msg-for-ai 的开源项目在 GitHub 上线，目标就是用最轻量的方式解决这个问题——不引入消息队列、不依赖网络服务，就靠 tmux 这个终端复用器本身的能力，搭建一条 Agent 间的消息通道。

一、工具介绍

tmux-msg-for-ai 是一个基于 tmux 的消息总线工具，专为 Claude Code 等 AI 编程 Agent 的多会话协作场景设计。

它的核心思路非常朴素：既然多个 Agent 会话都在 tmux 的 session 里跑，那 tmux 本身就天然是一个共享环境。通过在 tmux 的 buffer 里写消息、读消息，就能实现 Agent 之间的异步通信，不需要额外架设服务器、消息队列或网络依赖。

作者 Marcin Dudek 在项目介绍里写道：「Send a message to another agent session and have it arrive when that session is actually ready.」——把消息发到另一个 Agent 会话，等那个会话空闲的时候再接收。这个设计切中的正是多 Agent 系统里「异步协作」的核心场景。

目前项目还处于早期阶段（今天刚刚创建），MIT 开源协议，用 Shell 编写，依赖 tmux。GitHub 地址为 github.com/MarcinDudekDev/tmux-msg-for-ai。

为什么要关注这个项目？因为 2026 年的 AI Agent 开发生态里，Claude Code、Cline、Aider 等 CLI Agent 的日活用户已经非常庞大。但绝大多数用户仍然停留在「一个会话干一件事」的阶段，真正把多个 Agent 编排成一个协作团队的用法——因为缺乏好用的通信基础设施——仍然是小众玩法。tmux-msg-for-ai 瞄准的就是这个空白：一个零配置、零依赖的 Agent 间通信方案，让多 Agent 协作的入门门槛降到最低。

二、核心功能

1. 跨会话消息发送

在同一个 tmux 服务器下，不同 session 里的 Agent 可以向目标 session 发送文本消息。不需要知道目标 Agent 的 IP、端口或 API 地址，只需要知道 tmux session 的名字。

这意味着你可以在一个 session 里跑代码审查 Agent，在另一个 session 里跑代码生成 Agent，在第三个 session 里跑测试 Agent——然后通过 tmux-msg-for-ai 让它们互相通知任务进度。

2. 消息到达通知

消息不会丢失。发送方把消息写入 tmux buffer 后，接收方 Agent 通过轮询或触发机制感知到新消息，在空闲时主动拉取处理。这种设计避免了「正在处理复杂任务时被中断」的问题。

对比传统的消息队列方案（RabbitMQ 等），tmux-msg-for-ai 的优势在于「就绪感知」——消息不是立即推送给目标，而是等目标主动拉取。这对于 AI Agent 场景特别重要，因为 Agent 的推理和执行过程不能随意打断。

3. 纯 CLI 接口

整个工具通过命令行调用，不依赖 GUI、Web 界面或第三方服务。对于 Claude Code、Cline 这类 CLI 原生 AI Agent 来说，集成成本极低——只需要在 Agent 的 prompt 或脚本里加入相应的命令调用即可。

举个例子，你可以在 Claude Code 的 CLAUDE.md 配置文件里加上一条系统指令：「当遇到需要传递给其他 session 的信息时，使用 tmux-msg-for-ai 发送。」这样 Agent 在每次执行任务时都会自动考虑跨会话协作。

4. 零外部依赖

只需要 tmux 和 Shell 环境。不需要安装 Redis、RabbitMQ、Kafka 或任何消息队列系统，不需要配置网络端口，不需要担心防火墙问题。只要是跑 tmux 的机器就能用。

依赖越少，维护成本就越低。对于个人开发者来说，这意味着你可以在自己的开发机上 5 分钟之内搭好一套多 Agent 协作环境。对于团队来说，这意味着不需要申请额外的基础设施资源，也不需要运维团队的介入。

5. Agent 就绪感知

项目的一个关键设计是「消息在目标 session 就绪时才送达」。Agent 正在执行复杂任务时不会被打断，消息会在 tmux buffer 里排队，等 Agent 处理完当前工作后再读取。这对于生产环境的多 Agent 协作至关重要。

三、使用场景

场景 1：Claude Code 多会话编排

这是 tmux-msg-for-ai 最直接的用法。假设你在做一个全栈项目，需要同时处理前端、后端、数据库和测试四个模块。传统做法是你开一个 Claude Code 会话，把所有任务塞进去，结果上下文很快爆满，Agent 的推理质量急剧下降。

用 tmux-msg-for-ai 的做法是：开四个独立的 tmux session，每个 session 跑一个 Claude Code 实例，各自专注一个模块。会话 A（前端）完成组件开发后，通过 tmux-msg-for-ai 告知会话 B（后端）「前端 API 接口已定义，可以开始了」。会话 B 完成后通知会话 C 做数据迁移，会话 D 跑集成测试。整个流程不需要人类介入，Agent 之间自己协调。

场景 2：AI Agent 工作流管道

数据采集 Agent → 数据分析 Agent → 报告生成 Agent，三步流水线靠消息总线串联。前一步的输出作为消息写入 tmux buffer，后一步在就绪时取走处理。

这个模式的好处是每一步都是异步的——数据采集 Agent 可以一直跑，不管下游的 Agent 是否就绪。数据分析 Agent 跑完了会通过消息总线通知报告生成 Agent，但报告 Agent 不会被强制打断当前任务。

场景 3：调试与监控

在主 Agent 工作过程中，通过消息总线向监控 Agent 发送进度报告、错误日志。即使主 Agent 崩溃，监控 Agent 依然可以读取到崩溃前的最后一条消息。

这在长期运行的 Agent 任务中特别有用。比如你让一个 Agent 通宵跑数据迁移，它每完成一个阶段就通过 tmux-msg-for-ai 向监控 session 发送一条状态消息。第二天早上你打开监控 session，就能看到完整的执行时间线，不需要翻日志。

场景 4：人机协作

人类在另一个 tmux pane 里操作，通过消息总线向 Agent 发送指令或反馈。Agent 处理完后再通过消息总线返回结果，形成完整的「人类发任务 → Agent 干活 → 人类验收」闭环。

这个场景有趣的地方在于——消息总线的两端不需要区分是「人类」还是「AI」。对人类来说，就是在一个 tmux pane 里敲一行命令发消息；对 Agent 来说，就是从 buffer 读到一条消息然后处理。两者用的是完全相同的接口，没有认知负担。

四、价格方案

由于是开源项目，没有任何收费计划。如果你需要商业支持或定制开发，可以直接联系作者。

五、功能特点

优势：

1. 极其轻量 — 纯 Shell 脚本，几百行代码解决一个真实痛点，不引入复杂基础设施。相比之下，搭建一套 RabbitMQ 需要安装 Erlang、配置 VHost、管理用户权限——tmux-msg-for-ai 只需要你已经有 tmux。
2. 零网络依赖 — 不需要配置端口、防火墙、认证，tmux session 之间天然互通。这意味着不存在端口被占用、防火墙规则忘记放行、认证 token 过期这些运维问题。
3. 非侵入式 — 不需要修改 Claude Code 或其他 Agent 的代码，通过 CLI 命令集成。你甚至可以在不重启 Agent 的情况下随时切换通信方式。
4. 异步解耦 — 发送方和接收方不需要同时在线，消息在 buffer 里排队等待。Agent A 发完消息后可以继续做自己的事，Agent B 在就绪时再去取，两者互不阻塞。
5. 生产友好 — 消息送达机制充分考虑 Agent 忙碌状态，不会打断正在执行的复杂任务。即使 Agent B 正在处理一个 10 分钟的长推理任务，Agent A 发来的消息也会在 buffer 里安静等待。

局限：

1. 项目刚起步 — 今天刚创建，0 Star，功能还在原型阶段。README 只有基本的功能说明，文档和 API 还不完善，可能还存在未发现的 bug。
2. 仅限 Unix — 依赖 tmux，Windows 原生不支持（WSL 可用）。如果你主要在 Windows 开发，需要先装 WSL。
3. 单机范围 — 只能在同一台机器的 tmux session 之间通信，不支持跨主机。如果你的 Agent 分布在不同的服务器上，这个工具就不适用。
4. 消息持久化 — tmux buffer 不是持久化存储，tmux 服务器重启后消息会丢失。对于需要持久化的消息场景，建议结合日志文件或其他存储方案。
5. 社区尚小 — 目前只有作者一人维护。这意味着 bug 修复和功能更新的速度取决于作者的个人时间安排，没有社区贡献者的补充。

六、上手指南

安装：

发送消息：

接收消息：

在 Claude Code 中集成：

更详细的使用说明请查看项目 GitHub 仓库的 README。

七、常见问题

Q1：这个工具和 n8n、RabbitMQ 这些消息队列有什么区别？

tmux-msg-for-ai 解决的场景非常具体——CLI 环境下的 AI Agent 间直接通信。它不追求通用性，只做一件事：让同一个 tmux 服务器下的 Agent 会话能互相发消息。

对比来说：RabbitMQ 是一个通用的消息队列系统，功能强大但部署复杂，需要安装 Erlang、配置 VHost、管理用户权限、设置 Exchange 和 Queue。n8n 是一个可视化工作流编排工具，提供了图形化的拖拽界面，但它的主要使用场景是 API 集成和自动化流程，对 CLI Agent 的原生支持有限。

tmux-msg-for-ai 的定位比它们都更「窄」也更「轻」——它只做 CLI 环境下 Agent 间的消息传递，不做持久化、不做路由、不做可视化编排。正因为目标明确，它才能做到零配置、零依赖。

Q2：只能在 Claude Code 里用吗？

不是。任何 CLI 环境下的 AI Agent（Cline、Aider、Codex CLI 等）都可以通过调用 Shell 命令来使用 tmux-msg-for-ai。甚至人类用户也可以在 tmux pane 里手动发送消息，实现人机协作。

从技术上来说，tmux-msg-for-ai 不依赖于任何 AI 工具——它只是利用 tmux 的 buffer 机制做消息传递。无论是 AI Agent 还是人类，只要能在命令行里执行 Shell 命令，就能用它。

Q3：跨机器能用吗？

目前不支持。tmux-msg-for-ai 依赖 tmux 服务器共享，只能在同一台机器的不同 session 之间通信。如果需要跨机器通信，可以考虑搭配 SSH 隧道或其他网络方案，但这不是项目当前的设计目标。

对于分布式场景，目前更成熟的选择是 Celery（Python 生态）、Temporal（通用工作流）或者直接用消息队列中间件。

Q4：消息会丢失吗？

tmux buffer 在 tmux 服务器存活期间消息不会丢失，但 tmux 重启后 buffer 会清空。对于生产环境的关键消息，建议结合日志记录或其他持久化方案。

一个简单的做法是让接收方在收到消息后立即写入日志文件，这样即使 tmux 重启，消息也不会彻底丢失。

Q5：项目能商用吗？

可以。项目基于 MIT 协议开源，可以自由使用、修改和分发，包括商业用途。MIT 协议是目前最宽松的开源协议之一，不限制商用，不要求开源衍生代码。

八、同类项目对比

tmux-msg-for-ai 的独特之处在于它不试图替代这些成熟方案，而是填补了一个被忽视的空白：本地 CLI 环境下的 Agent 间通信。

九、写在最后

tmux-msg-for-ai 解决的问题其实很简单：多 Agent 协作时，需要一个让它们能「打招呼」的通道。它选的不是最强大的方案（消息队列、事件总线等），而是最轻量的方案——tmux 就在那里，为什么不用？

这个项目刚在今天上线，0 Star、0 Fork，但它切中的是一个真实痛点。随着 Claude Code 等 CLI Agent 的普及，多会话协作的需求只会越来越强。一个零配置的消息总线，让多个 Agent 在同一个终端里互相配合，可能正是很多开发者需要的「最后一公里」工具。

对于正在搭建多 Agent 工作流的开发者来说，这个项目值得关注。它可能不会成为下一个 Kafka，但作为 Claude Code 多会话协作的粘合剂，方向是对的。

（来源：GitHub MarcinDudekDev/tmux-msg-for-ai）