让 Codex 写代码、Claude 做 review、另一个 Agent 补测试，听起来像个完美的 Agent 协作团队。但现实往往很滑稽：因为它们运行在各自独立的会话窗口、产品形态或执行环境里，甚至可能来自不同的厂商，彼此之间无法直接共享会话、交换状态 。最后居中粘贴 JSON、手动在各种终端和会话框里搬运状态和上下文的，只有你。
你以为配齐了 AI 军团，其实你只是沦为了一个“大模型消息搬运工”。
为了打破这种「假自动化」的尴尬，论文「tap: A File-Based Protocol for Heterogeneous LLM Agent Collaboration」提出了一个叫 tap 的轻量级通信协议，作者把它要处理的问题定义为异构 LLM Agent 协作，也就是来自不同厂商、运行在不同环境里的 Agent，如何围绕同一个代码仓库分工开发、互相 review，并把消息、交接和故障恢复都留下可检查的记录。
tap 不打算让 Agent 变得更聪明，也不试图搭一个大一统 Agent 平台。它选择退回到软件工程里最普通、也最可靠的底层机制，本地文件系统和 Git 工作流，让不同 Agent 在相互隔离的环境下，围绕同一个 repo 老老实实地协作。
消息就是文件，仓库就是现场
面对多厂商、跨环境的 Agent 协作，tap 的核心解题思路有些反直觉：既不去折腾分布式网络，也不去强求大一统的 API 转发，因为每个厂商的执行风格和通信接口天然存在巨大差异 。
它的设计哲学是：消息就是文件，仓库就是现场，Git 就是隔离墙 。tap 把消息的规范性和可审计性寄托在本地文件系统上，以此作为异构 Agent 之间的“外交公共语言” 。
图1：tap 的整体核心架构 。消息在发送时首先被落盘为带元数据的 Markdown 文件并存入公共收件箱。Claude 和 Codex 通过实时通知路径协作，Gemini/MCP models 通过实验性的文件检查路径参与；不同 Agent 通过 git worktrees 做工作区隔离。
双层通信：先落盘，再通知
要把 Claude 和 Codex 连起来，直接用网络实时通信（比如 WebSocket）行不行？行，但不可靠 。Agent 在长流程任务里经常面临各种意外：上下文慢了需要重置、执行环境闪断、或者通知服务崩溃。一旦连接断了，飘在内存里的对话消息就丢了。
于是，tap 设计了一套“虚实结合”的双层通信路径。
Tier 1 文件通信筑基：状态落盘
当任意 Agent 调用 tap_reply 时，系统会先把消息格式化为带有 YAML 元数据的 Markdown 文件，老老实实地写入本地的 inbox/ 文件夹 。
在这个层级上，tap 追求的是绝对的可靠性与宕**机**恢复能力。哪怕负责 review 的 Codex 突然遭遇上下文限制而面临团队换届，新上岗的 Agent 通过 MCP 工具直接去读取 inbox/ 里的原始 Markdown 文件，就能瞬间找回上任 Agent 留下的全部事实上下文。文件系统成了它们可以反复回看的外部记录。
Tier 2 实时通知加速：事件驱动
如果只靠 Tier 1 读写文件，另一个 Agent 总不能写个死循环每隔 1 秒去轮询文件夹，这会把磁盘 IO 跑满，且响应太慢。
于是 tap 叠加上了 Tier 2（实时通信）。当发送方完成文件写入的一瞬间，系统会通过 WebSocket 连接（Codex 端）或 Claude MCP 管道通知，向接收方发一个轻量级的“催办通知”（ping） 。
这种设计深得传统网络工程的精髓——“事件可以丢，但状态必须可查”。接收方收到通知后，并不依赖通知自带的 payload，而是回头重新读取 inbox/ 里的原始文件进行处理。即使实时通知由于网络原因丢失，也只会表现为投递延迟，而不会消息丢失。
接入差异：用配置流程做标准化适配
搞定了通信路径，另一个现实的工程墙撞了上来：不同的 Agent 客户端，接入方式千奇百怪。
Claude 的工具入口在 .mcp.json，Codex 走的是 config.toml，其他模型又是另一套配置。传统的平台思路是强行做一套“大一统 API”，要求所有人来适配我。
Tap 的解法非常务实，既然无法改变各大厂商的接入标准，那就搞一个基础设施层的自动化适配命令——tap add。该命令会直接扫描当前系统的配置环境，针对不同的 Agent 自动生成一套配置文件变更计划，然后原地应用并自动验证，把折腾各大厂商配置文件的脏活给标准化了。它不强求统一的 API，但统一了配置流程。
工作区隔离：用 Git Worktree 避免代码打架
解决了“说话”和“接入”的问题，接着就是“干活”的问题。多厂商的 Agent 频繁读写同一个代码库，必然会导致严重的本地文件冲突。
Tap 没有选择自己去写一套复杂的并发锁机制，而是直接调用了 Git 的底层机制——git worktree。
Tap 为每一个参与协作的 Agent 实例分配一个完全隔离的独立工作树。Claude 在分支 A 改功能，Codex 在分支 B 对应的独立目录下做 review。更绝的是，tap 还把进程 PID、执行日志、状态文件全部按 instanceId 进行了强隔离。这意味着底层共享同一个 Git 仓库，但表层各自有完全独立的文件现场，几只 Agent 同时并行动工也不会把文件状态踩成一团乱麻。
外部记忆：用 Operational Artifacts 支撑跨世代接力
在真实的软件工程里，协作是跨越时间和周期的。但单个 LLM Agent 有个致命的硬伤：它没有持久化的内部状态或长期记忆。
当一轮任务跑满了上下文限制，当前这个 Agent 团队就必须集体换届，让下一轮 Agent 接棒。新上任的 Agent 面临的是“孟婆汤”式的失忆，对前人踩过的坑、做过的技术决策一无所知。
为此，tap 在运行流程中会把团队协作过程中产生的各种记录，以结构化的 Operational Artifacts 形式沉淀到本地。
[运作产物目录结构]
└── operational_artifacts/
├── reviews/ (代码审查记录)
├── findings/ (运行缺陷发现)
├── retros/ (阶段事后复盘)
└── handoff/ (换届交接说明)
这相当于在代码仓库里建立了一个外部记忆体。下一代 Agent 团队“换届上岗”时，第一件事不是盲目去读成千上万行的纯源代码，而是先去读上一任留下的 handoff/和 retros/。工程背景和决策链条得以跨周期、跨代地传递下去。
27 天自应用运行：看看真实仓库里跑得怎样
为了验证这套工程补丁在真实战场上的耐受度，作者玩了一把硬核的—— Self-applied operation，让这套协议在生产环境仓库里“自己开发、自己审查、自己迭代自己”。
在长达 27 天的时间里，Claude 和 Codex 在各自的执行环境里深度协作，Gemini 参与了实验性的文件检查路径，整个 Agent 团队跨越了 37 代的换届接力。
表 1：tap 自应用运行的核心度量指标。数据记录了截止到 2026 年 4 月代码库在长周期自我迭代中所达到的工业规模。
真实运行暴露的问题，才是协议被打磨的地方
任何跑在真实开发现场的协议，其鲁棒性都是在文件锁、文件权限、路径兼容、多进程并发等细碎而琐碎的底层 Bug 中反复打磨出来的。也正因为 tap 坚持将消息、日志和状态落盘，运行中暴露出的这一系列工程边缘 Case 才没有变成“死无对证”的偶发性玄学故障，而是成为了可追溯、可复盘的协议改进项。
表 2：真实运行中暴露出的协议级工程故障与修复方案。
这些踩坑记录表明，异构 Agent 在跨系统协作时，往往会卡在最基础的路径和多实例冲突上。tap 的演进逻辑正是通过不断把这些工程漏洞分派、修复，进而写进协议规范和 Agent 的 Instructions 中。
Review 数据的价值和边界
在这 27 天的演进中，作者从累积的运作记录中，深度交叉比对了 375 个评审产物，并统计出了一组缺陷捕获率数据：
表 3：不同模型配对下的代码评审有效缺陷捕获率统计（Gen 1-37, $$n=37$$） 。
这组数据确实亮眼，但作为一个合格的研发，我们必须看清作者极其克制的清醒反思。这里更适合被看成一个工程信号，而不是一个因果结论：
混杂变量无法被拆开： 这是一个生产环境下的观察性数据，而非完美控制变量的科学实验。由于中后期 Codex 评审 Claude 的大量样本实际上是跑在独立 Linux 服务器上的无人值守 Headless 进程。因此，具体的效果提升，到底是来自模型本身的差异，还是来自角色分配、跨环境的影响，在这套数据集中被交织在了一起，无法单独做因果推导。
安全审查数据不能定量概括： 尽管协议通过人工重新标记，识别出了少量涉及核心安全漏洞与高风险安全隐患的案例（包括识别出
execSyncshell 脚本注入和局部写入端点 CSRF 这类运行时安全漏洞候选风险）。但作者非常坦诚地强调，这部分安全样本非常小，只能作为定性证据来证明异构评审可以带来更宽的检查视角，不能用来定量证明某种模型天生更擅长安全审查。
结合作者引用的 popularity trap 相关研究，我们可以把它理解成一个提醒：只靠相近模型或相近执行环境做 review，可能会共享一部分错误倾向；而异构组合至少提供了更宽的检查视角。但这组数据本身不能单独证明同构组合低就是因为模型盲区重叠
让协议处理同步，让人回到判断与决策
最后，必须打破对“AI 团队完全自治开发”的幻觉。在这篇论文里，人依然是最终的底牌。
在 tap 的运行现场，早期的消息投递频繁需要人类进去“收拾烂摊子”；随着路径稳定， Agent 之间高比例地实现了基于文件的直接通信，但重大的技术方向决策、以及最终合入主分支的最终审批，依然牢牢掌握在人类手里。
Tap 做的事情老派且务实，它用一套本地文件系统和 Git 工作隔离机制，让协议去处理繁琐的跨平台信息同步，把人类从“低价值的 JSON 消息搬运”里解放出来，让人少做低价值的信息搬运，把精力放回判断、取舍和最终审批上。
这很不性感，但很工程。
论文文献：
tap: A File-Based Protocol for Heterogeneous LLM Agent Collaboration. arxiv.org/pdf/2606.14445
