让 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 之间的“外交公共语言” 。图1tap 的整体核心架构 。消息在发送时首先被落盘为带元数据的 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.jsonCodex 走的是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 代的换届接力。表 1tap 自应用运行的核心度量指标。数据记录了截止到 2026 年 4 月代码库在长周期自我迭代中所达到的工业规模。真实运行暴露的问题才是协议被打磨的地方任何跑在真实开发现场的协议其鲁棒性都是在文件锁、文件权限、路径兼容、多进程并发等细碎而琐碎的底层 Bug 中反复打磨出来的。也正因为 tap 坚持将消息、日志和状态落盘运行中暴露出的这一系列工程边缘 Case 才没有变成“死无对证”的偶发性玄学故障而是成为了可追溯、可复盘的协议改进项。表 2真实运行中暴露出的协议级工程故障与修复方案。这些踩坑记录表明异构 Agent 在跨系统协作时往往会卡在最基础的路径和多实例冲突上。tap 的演进逻辑正是通过不断把这些工程漏洞分派、修复进而写进协议规范和 Agent 的 Instructions 中。Review 数据的价值和边界在这 27 天的演进中作者从累积的运作记录中深度交叉比对了 375 个评审产物并统计出了一组缺陷捕获率数据表 3不同模型配对下的代码评审有效缺陷捕获率统计Gen 1-37, n37 。这组数据确实亮眼但作为一个合格的研发我们必须看清作者极其克制的清醒反思。这里更适合被看成一个工程信号而不是一个因果结论混杂变量无法被拆开这是一个生产环境下的观察性数据而非完美控制变量的科学实验。由于中后期 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