Agents Can Communicate：让 AI 编程会话互相"打电话"

痛点：当你同时开着 Claude Code 和 Codex，却只能靠复制粘贴传话

想象这个场景：你正在开发一个前端功能，用 Claude Code 写了三天，积累了深厚的上下文。突然，遇到一个需要 Gemini CLI 来完成的自然语言处理模块需要接入。这时候传统做法是什么？

把上下文压缩、精简，复制给新会话，然后祈祷它能理解你的意图。原本的会话被"中断"，你失去了宝贵的上下文积累。

Agents Can Communicate（ACC） 解决的就是这个问题——让多个 AI 编程会话之间可以直接通信、传递上下文、完成交接，而不需要人类当"信使"。

背景：多智能体协作的本地化实践

2026 年，多智能体 AI 系统已从学术研究走向生产环境。据 Gartner 预测，到 2026 年底，40% 的企业应用将集成任务特定型 AI 智能体，而多智能体协调失败率在生产环境中高达 41-87%，其中 79% 的失败根源在于规范和协调问题，而非技术缺陷。

当前主流的多智能体协调方案有两类：

• MCP（Model Context Protocol）：解决智能体到工具的通信标准，由 Anthropic 主导，已成事实标准
• A2A（Agent2Agent）协议：解决智能体间的通信标准，由 Google 于 2025 年 4 月推出，现由 Linux 基金会维护

ACC 走的路线介于两者之间——它是一个完全本地化的多会话协调层，不需要服务器，不需要额外账号，每个 AI 会话保持独立，通过文件系统进行消息传递和交接（handoff）。

核心功能：三种协调模式

ACC 支持三种核心协调模式，适用于不同的多智能体协作场景：

1. 直接问答（Ask）

一个会话可以向另一个会话发起问题，另一个会话直接回答并回复。例如，前端会话遇到一个 API 格式不确定的问题，可以直接问后端会话获取答案，不需要人类在中间传话。

2. 代码审查请求（Review）

一个会话可以请另一个会话审查自己的改动，审查结果直接传回给实施者。不同于传统的静态代码审查工具，这里的审查是动态的——另一个 AI 会话基于自己的理解和经验给出评审意见。

3. 工作交接（Handoff）

这是 ACC 最核心的功能。当你需要从一个 AI 模型切换到另一个时（模型逼近上下文限制、想换不同模型思路），Handoff 让你把当前的决策、未完成的工作、下一步计划都记录下来，下一个会话打开时可以无缝衔接继续工作，而不是从头开始。

技术架构：本地优先，无中心控制

ACC 的架构设计非常克制——它是一个纯本地的控制平面，AI 客户端保持独立执行。

发信会话 → [core] → [filesystem store] → [delivery router] → [certified adapter] → 收信会话

核心设计原则：先记录，再传递。

1. 消息先经过 core 验证并持久化到本地文件系统
2. delivery router 根据收信方的在线状态选择最优传递路径
3. certified adapter 负责跨客户端边界传递消息

关键包职责：

包	职责
protocol	ID 生成、Schema 验证、收据状态机
core	会话管理、意图、对话线程、收件箱
storage-filesystem	原子事务、事件日志、持久化视图
adapter-*	各客户端（Claude Code、Codex、Gemini CLI 等）的原生集成
mcp-server	为不支持原生适配器的客户端提供 MCP 轮询参与方式
cli	统一的本地命令边界

值得注意的是，core 包不能导入任何 adapter、Git 或 node:child_process——这是通过包边界测试强制执行的，而非仅仅依赖代码规范。

支持的客户端

目前 ACC 已通过认证集成的客户端包括：

• Antigravity CLI（实验性实时推送支持）
• Claude Code（支持下一轮传递 + 实验性 Apple Silicon macOS 唤醒）
• OpenAI Codex（支持下一轮传递 + 实验性本地守护进程）
• Gemini CLI
• Grok
• Kimi Code

其他客户端可以通过 MCP 协议连接，自行配置协调指令。

上手门槛

安装条件：macOS 或 Linux + Node.js 24+

安装方式：

npm install -g agents-can-communicate
acc install

installer 会自动检测并连接本地支持的 AI 客户端。安装完成后，在项目目录中正常启动各客户端即可。

上手难度：中等。核心门槛是 Node.js 24+ 的版本要求（较新），以及需要本地同时运行多个 AI 客户端。文档质量优秀（16 个独立文档），但初始配置需要理解"本地协调"的概念，不能用传统服务器的思维方式。

局限与争议

1. 模型不保证协作：ACC 只是提供了协调的基础设施，AI 模型是否真正利用这些功能协作，取决于各客户端的集成质量。ACC 不保证每个模型都会注意到依赖关系。

2. Apple Silicon macOS 独占实时唤醒：实验性的会话唤醒功能（live delivery）仅限 Apple Silicon macOS，其他平台用户只能依赖下一轮传递（next-turn delivery）。

3. 无 Web UI：纯 CLI 工具，没有图形界面，适合命令行重度用户，对非技术用户不够友好。

4. 交接依赖人工触发：Handoff 需要用户主动要求 AI 保存交接内容，ACC 不会自动推断交接时机。如果 AI 会话在还能响应时意外中断，ACC 无法恢复从未被保存的上下文。

行业意义

ACC 代表了多智能体协调的一种"轻量级、去中心化"路线。它没有选择构建一个中心化的管理器或使用云服务，而是让每个 AI 会话保持完全独立，通过本地文件系统协调。这避免了单点故障，也不需要额外的 API 密钥或托管服务。

同时，它也呼应了行业对多智能体协作可靠性的追求——通过"先记录再传递"的强顺序保证，确保了消息传递的持久性和可审计性。在上下文窗口压缩、模型切换频繁的 AI 编程实践中，这种交接机制有真实的实用价值。

随着 MCP 和 A2A 等协议逐渐成熟，像 ACC 这样的本地协调层可以作为这些协议在特定场景（离线、单机、多客户端混合）下的补充方案。