Claude Code 会话各自为战？AgentBus 本地消息总线让多个 Agent 实时通信

你正在用 Claude Code 开发一个前后端分离的项目。前端会话负责修改 React 组件，后端会话处理 API 接口。突然，前端需要知道后端的某个接口返回值格式——你只能复制输出、切到另一个终端、粘贴、提问、再切回来。这种「终端乒乓」不仅打断思路，还浪费珍贵的上下文窗口。

多会话协作的痛点，简单但顽固。

为什么这是个真问题

使用 AI 编程 Agent（Claude Code、Codex CLI、Cursor 等）时，一个典型的中大型项目往往需要多个并发的 Agent 会话：

每个会话都陷入信息孤岛：后台会话刚改完数据库 schema，前台会话还在用旧的字段名做查询。中间结果靠人工复制粘贴，跨会话的实时协调几乎不可能。

手动方案的代价很直接：

• 每次切换上下文，损失 30 秒到 2 分钟（重新定位到合适位置）
• 粘贴输出时丢失运行上下文（Agent 无法回溯”为什么这个 API 返回了那个格式”）
• 多个窗口同时工作时，很容易发生「一方改了一方不知」的同步失误

传统做法：从复制粘贴到文件共享

目前最常见的做法是文件共享——一个会话写入临时文件，另一个会话读取：

cat > /tmp/api-contract.txt << 'EOF'
POST /api/v2/users
Request: { name, email, role }
Response: { id, name, email, role, created_at }
EOF

cat /tmp/api-contract.txt

这种做法虽然可行，但缺点明显：

• 没有实时通知——前端会话不知道文件何时更新
• 需要手动管理文件路径和文件名
• 多人协作时容易产生冲突

另一个做法是让两个会话共用同一个 shell 变量文件或配置文件，但这要求 Agent 主动去读取最新版本，没有推送机制。

AgentBus：本地消息总线的解决方案

AgentBus（MIT 许可证，TypeScript）是一个本地消息总线，专为 AI Agent 会话的实时通信而设计。它的核心思想很简单：用一条 SQLite 总线连接所有会话，一个 MCP 服务器负责发送，可插拔的 delivery 机制负责接收。

┌───────────────────────────────────────────┐
│  CORE (SQLite bus.db)                      │
│  身份注册 · 名称映射 · 消息持久化          │
│  发送(SEND)    ·    投递(DELIVERY)         │
│  始终在线           可插拔组件             │
└───────────────────────────────────────────┘

它不试图替代 A2A 或 ACP 这些远程 Agent 通信协议——它解决的是同一个机器上、正在运行中的交互式会话之间如何实时通信这一最后一公里问题。

安装

AgentBus 依赖 Bun 和 Claude Code v2.1.80+（channel 功能需要 research-preview 版本）：

git clone https://github.com/biswajitpatra/agentbus
cd agentbus
bash scripts/install.sh

安装脚本会自动注册始终在线的 agentbus 发送服务器，并列出可用的 delivery 组件。然后启用 Claude Code 的 channel delivery：

bun run agentbus enable claude-channel

基本使用：让两个 Claude Code 会话对话

启动两个 Claude Code 会话，各分配一个名称，并加载 channel 组件：

AGENTBUS_NAME=frontend claude --dangerously-load-development-channels server:agentbus-channel

AGENTBUS_NAME=backend claude --dangerously-load-development-channels server:agentbus-channel

现在在前端会话中问：

"send_message to backend: 用户注册接口返回的 JSON 结构是什么？"

后端会话会收到一个 事件：

用户注册接口返回的 JSON 结构是什么？

后端 Agent 可以直接回复：

"send_message to frontend: POST /api/v2/users 返回 { id, name, email, role, created_at }，其中 id 是 UUID v4"

整个过程中，两个会话各自保持自己的工作上下文，只在需要时交换信息。

核心功能一览

AgentBus 提供以下 MCP 工具：

消息路由基于稳定的身份 ID（runtime:token），名称只是一个可变标签——你可以随时重命名会话而不影响历史消息的寻址。

不使用 MCP 时的替代方式

即使你的 Agent 不支持 MCP channel（如非 Claude Code 的会话），也可以通过 shell 直接发送消息：

AGENTBUS_NAME=frontend bun run agentbus send backend "API 响应格式是什么？"

bun run agentbus peers

bun run agentbus name api-gateway

在 Bash 子进程中运行的命令会自动获取 CLAUDE_SESSION_ID 环境变量，因此 CLI 能计算出正确的身份 ID——不需要额外配置。

实战场景：前后端契约对齐

以一个典型的 Web 应用开发为例。你正在开发用户管理系统，后端会话定义了数据库 schema，前端会话需要知道 API 响应格式。

步骤 1：后端会话定义 API

后端会话完成注册接口开发后，直接向前端发送消息：

"broadcast: 用户注册 API 已完成，返回 JSON 格式: { id: uuid, name: string, email: string, role: string, created_at: datetime }，字段名全部使用 camelCase"

步骤 2：前端会话接收并适配

前端会话收到广播后，立即更新自己正在编写的请求代码，完全不需要等待开发者手动同步。

步骤 3：双向验证

如果前端在联调中发现某个字段缺失或格式不对，直接回复：

"send_message to backend: role 字段在注册响应中是 'admin'/'user' 字符串还是枚举值？created_at 的时区是什么？"

后端会话可以在同一上下文中查看自己的代码，确认后回复。整个对话在 30 秒内完成，无需切换终端或手动查找代码。

架构设计要点

AgentBus 的架构有几个值得注意的设计决策：

发送与接收分离：发送层是一个始终在线的 MCP 服务器，永不消耗消息（不会把消息标记为已读）。接收层是可插拔的 delivery 组件，每个 delivery 独立启用或关闭。这意味着你可以同时运行多个 delivery（如 Claude Code channel + 未来的 Gemini A2A delivery），它们共享同一条总线。

至少一次投递：delivery 只有在确认消息已成功注入目标会话后，才将 delivered_at 标记为非空。如果出现竞争（两个 delivery 同时试图投递同一消息），只有最先完成投递的那个会成功，其余通过 msg_id 去重。

无网络端口：AgentBus 只监听本机 SQLite 文件，不打开任何网络端口。安全性建立在「同一机器、同一用户」的边界上——如果你在本机运行多个 Agent 会话，它们天然属于同一个信任域。

使用建议

1. 命名规范：为每个会话分配有意义的名称（api-gateway、db-migration、frontend-ui），而不是用默认的随机 ID。命名在 set_name 中可以随时修改。

1. 广播 vs 点对点：全局信息用 broadcast（API 契约变更、项目配置更新），定向信息用 send_message（特定模块的代码评审、参数讨论）。

1. 不要滥用消息：每个 消息都会进入接收会话的上下文窗口。保持消息简洁、聚焦，避免发送冗长的日志或代码块——优先发送关键信息和引用地址。

1. 配合文件系统使用：对于大型代码片段或数据，AgentBus 传递路径和摘要，通过共享文件系统交换完整内容。消息总线负责「通知」，文件系统负责「存储」。

总结

多 AI Agent 会话的实时通信是一个被低估的需求——当你同时在 2-3 个终端中工作，每个终端都有一个 AI 编码助手时，跨会话的信息孤岛会显著拖慢开发节奏。AgentBus 用一条 SQLite 消息总线 + MCP channel 提供了轻量级的解决方案：不依赖网络基础设施，不改变你的工作流，只在需要时悄无声息地把消息送到正确的会话。

相关链接：

• AgentBus GitHub
• AgentBus SPEC.md — 协议细节
• Claude Code 文档
• Session Bridge — 文件邮箱方案
• Clauder — 跨会话消息先驱