让 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 之间的“外交公共语言” 。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/5a8aa598d070f1eebc459e2b197ca773.png)

图1：tap 的整体核心架构 。消息在发送时首先被落盘为带元数据的 Markdown 文件并存入公共收件箱。Claude 和 Codex 通过实时通知路径协作，Gemini/MCP models 通过实验性的文件检查路径参与；不同 Agent 通过 git worktrees 做工作区隔离。

## 双层通信：先落盘，再通知

要把 Claude 和 Codex 连起来，直接用网络实时通信（比如 WebSocket）行不行？行，但不可靠 。Agent 在长流程任务里经常面临各种意外：上下文慢了需要重置、执行环境闪断、或者通知服务崩溃。一旦连接断了，飘在内存里的对话消息就丢了。

于是，tap 设计了一套“虚实结合”的双层通信路径。

1. Tier 1 文件通信筑基：状态落盘
    

当任意 Agent 调用 `tap_reply` 时，系统会先把消息格式化为带有 YAML 元数据的 Markdown 文件，老老实实地写入本地的 `inbox/` 文件夹 。

在这个层级上，tap 追求的是**绝对的可靠性与宕****机****恢复能力**。哪怕负责 review 的 Codex 突然遭遇上下文限制而面临团队换届，新上岗的 Agent 通过 MCP 工具直接去读取 `inbox/` 里的原始 Markdown 文件，就能瞬间找回上任 Agent 留下的全部事实上下文。文件系统成了它们可以反复回看的外部记录。

2. 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** 形式沉淀到本地。

```Plain
[运作产物目录结构]
└── operational_artifacts/
    ├── reviews/     (代码审查记录)
    ├── findings/    (运行缺陷发现)
    ├── retros/      (阶段事后复盘)
    └── handoff/     (换届交接说明)
```

这相当于在代码仓库里建立了一个外部记忆体。下一代 Agent 团队“换届上岗”时，第一件事不是盲目去读成千上万行的纯源代码，而是先去读上一任留下的 `handoff/`和 `retros/`。工程背景和决策链条得以跨周期、跨代地传递下去。

## 27 天自应用运行：看看真实仓库里跑得怎样

为了验证这套工程补丁在真实战场上的耐受度，作者玩了一把硬核的—— **Self-applied operation，让这套协议在生产环境仓库里“自己开发、自己审查、自己迭代自己”**。

在长达 27 天的时间里，Claude 和 Codex 在各自的执行环境里深度协作，Gemini 参与了实验性的文件检查路径，整个 Agent 团队跨越了 37 代的换届接力。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/358f12dc750719093f61200e415d79a3.png)

表 1：tap 自应用运行的核心度量指标。数据记录了截止到 2026 年 4 月代码库在长周期自我迭代中所达到的工业规模。

## 真实运行暴露的问题，才是协议被打磨的地方

任何跑在真实开发现场的协议，其鲁棒性都是在文件锁、文件权限、路径兼容、多进程并发等细碎而琐碎的底层 Bug 中反复打磨出来的。也正因为 tap 坚持将消息、日志和状态落盘，运行中暴露出的这一系列工程边缘 Case 才没有变成“死无对证”的偶发性玄学故障，而是成为了可追溯、可复盘的协议改进项。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/780a91b2e0d7f3aeb1c2b95d58f8b168.png)

表 2：真实运行中暴露出的协议级工程故障与修复方案。

这些踩坑记录表明，异构 Agent 在跨系统协作时，往往会卡在最基础的路径和多实例冲突上。tap 的演进逻辑正是通过不断把这些工程漏洞分派、修复，进而写进协议规范和 Agent 的 Instructions 中。

## Review 数据的价值和边界

在这 27 天的演进中，作者从累积的运作记录中，深度交叉比对了 375 个评审产物，并统计出了一组缺陷捕获率数据：

![](https://developer.qcloudimg.com/http-save/yehe-12464096/d25fc8fea2f05df6b05f20bdbace02be.png)

表 3：不同模型配对下的代码评审有效缺陷捕获率统计（Gen 1-37, n=375） 。

这组数据确实亮眼，但作为一个合格的研发，我们必须看清作者极其克制的清醒反思。这里更适合被看成一个工程信号，而不是一个因果结论：

1. **混杂变量无法被拆开：** 这是一个生产环境下的观察性数据，而非完美控制变量的科学实验。由于中后期 Codex 评审 Claude 的大量样本实际上是跑在独立 Linux 服务器上的无人值守 Headless 进程。因此，具体的效果提升，到底是来自模型本身的差异，还是来自角色分配、跨环境的影响，在这套数据集中被交织在了一起，无法单独做因果推导。
    
2. **安全审查数据不能定量概括：** 尽管协议通过人工重新标记，识别出了少量涉及核心安全漏洞与高风险安全隐患的案例（包括识别出 `execSync` shell 脚本注入和局部写入端点 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

让 Codex 写代码、Claude 做 review、另一个 Agent 补测试，听起来像个完美的 Agent 协作团队。但现实往往很滑稽：因为它们运行在各自独立的会话窗口、产品形态或执行环境里，甚至可能来自不同的厂商，彼此之间无法直接共享会话、交换状态 。最后居中粘贴 JSON、手动在各种终端和会话框里搬运状态和上下文的，只有你。

论文解读：Codex 写代码，Claude 做 review，中间谁来传话？拆解基于文件的异构 Agent 协作协议 tap

tap论文提出轻量级文件协议，解决多厂商、异构LLM Agent协作难题：以本地文件系统与Git为基座，通过“消息即文件、仓库即现场”实现可靠通信；双层机制（落盘存证+事件通知）兼顾鲁棒性与实时性；借助worktree隔离、配置自动化与外部记忆体（Operational Artifacts），支撑跨代接力开发。让AI专注分工，人回归决策。

人工智能

编程语言

架构设计

论文提出tap协议解决异构LLM Agent协作难题，采用本地文件系统和Git工作流实现跨厂商Agent协同开发。通过双层通信机制确保消息可靠传递，利用Git Worktree隔离工作区，并建立外部记忆体保存协作记录。27天自应用运行验证了协议稳定性，将人类从低效信息搬运中解放，专注于核心决策。

软件工程

文件系统

代码解释

服务器

WebSocket

Linux

Agent

JSON

2026上云采购 | AI焕新·智启新局

coding

tione

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

论文解读：Codex 写代码，Claude 做 review，中间谁来传话？拆解基于文件的异构 Agent 协作协议 tap-腾讯云开发者社区-腾讯云

论文解读：Codex 写代码，Claude 做 review，中间谁来传话？拆解基于文件的异构 Agent 协作协议 tap

论文解读：Codex 写代码，Claude 做 review，中间谁来传话？拆解基于文件的异构 Agent 协作协议 tap

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐