游乐游手机版
首页/AI教程/文章详情

论文解读:Codex写代码Claude审查的基于文件的异构Agent协作协议tap

时间:2026-07-08 15:37
提出基于文件系统的tap协议,通过本地文件与Git工作流实现异构LLMAgent协作。消息落盘确保可靠恢复,实时通知加速通信,Gitworktree隔离工作区,操作产物支撑跨代接力。经27天自应用运行验证了协议在真实开发中的鲁棒性。

先说一个常见场景:让 Codex 负责代码生成、Claude 承担代码审查、另一个 Agent 补充测试用例——听起来像是一支完美的 AI 协作团队。但实际运行起来往往令人哭笑不得:这些 Agent 各自运行在独立的会话窗口、产品形态或执行环境里,甚至可能来自不同的厂商,彼此之间无法直接共享会话、交换状态。最终结果呢?你只能居中粘贴 JSON,手动在各种终端和会话框之间搬运状态与上下文,沦为纯粹的“人工中转站”。

你以为自己配备了完整的 AI 军团,其实你只是个“大模型消息搬运工”。

为了打破这种「假自动化」的尴尬局面,一篇新论文「tap: A File-Based Protocol for Heterogeneous LLM Agent Collaboration」提出了一套名为 tap 的轻量级通信协议。作者将需要解决的问题定义为异构 LLM Agent 协作——即来自不同厂商、运行在不同环境中的 Agent,如何围绕同一个代码仓库进行分工开发、互相审查,并将消息传递、任务交接和故障恢复都留下可供检查的完整记录。

tap 并不试图让 Agent 变得更聪明,也没有打算构建一个大一统的 Agent 平台。它选择退回到软件工程中最普通、也最可靠的底层机制——本地文件系统和 Git 工作流——让不同 Agent 在相互隔离的环境下,围绕同一个代码仓库老老实实地展开协作。

消息即文件,仓库即现场

面对多厂商、跨环境的 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 追求的是绝对的可靠性与宕机恢复能力。哪怕负责审查的 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 对应的独立目录下进行审查。更关键的是,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 的指令集合中。

Review 数据的价值与边界

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

\

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

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

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

来源:https://developer.aliyun.com/article/1745931
上一篇教育系统开发实践:架构设计到落地全流程拆解 下一篇FastAPI结构拆分 Python AI Web框架
本站内容用于信息整理与展示,如有侵权或内容问题请及时联系处理。

相关推荐

补充同频道和同主题内容,方便继续浏览更多相关内容。

同类最新

继续查看同栏目最近更新的文章。

更多
Claude Code官方教你Loop工程附6大省token技巧
AI教程 · 2026-07-08

Claude Code官方教你Loop工程附6大省token技巧

之前写过一篇《Loop Engineering 的保姆级教程》,从概念到多工具实战,比较全面地讲了循环工程的玩法。这两天 Claude Code 官方团队下场,发了一篇博客叫「Getting started with loops」,系统地整理了他们团队内部对「循环」的定义和分类。 这篇博客的含金量十

阿里云2核4G服务器价格与选型:实例规格、收费标准及活动价
AI教程 · 2026-07-08

阿里云2核4G服务器价格与选型:实例规格、收费标准及活动价

阿里云2核4G这个配置,可以说是个人站长和中小企业用户最常关注的“爆款”了。不过它的价格可不是一个固定的数字,而是跟实例规格、带宽、云盘类型、地域等等因素紧密相关。比如目前轻量应用服务器2核4G给到峰值200M带宽、50G ESSD云盘,抢购价能做到9 9元1个月或者199元1年。通用算力型u1实例

阿里巴巴研发效能实践日:敏捷精益项目管理报名
AI教程 · 2026-07-08

阿里巴巴研发效能实践日:敏捷精益项目管理报名

研发效能提升领域又有重磅消息了。阿里巴巴研发效能实践日——由阿里研发效能部主办的线下沙龙品牌,这次携手全球领先的项目管理协会PMI,共同聚焦“敏捷精益项目管理”这一核心主题。听起来就干货满满?别急,活动精心安排了4大主题演讲,旨在帮助参会者在思维层面实现突破,并且回去就能直接落地实践。更关键的是,参

RFID资产管理系统:企业资产数字化高效管控方案
AI教程 · 2026-07-08

RFID资产管理系统:企业资产数字化高效管控方案

数字化转型走到今天,传统人工管资产那套老办法——效率低、差错多、资产一挪窝就成“失踪人口”——已经越来越扛不住了。从仓库、车间到办公室,但凡资产流转量大、品类多的企业,都急需一套能实时盯、自动盘的方案。结合多行业的落地经验来看,RFID资产管理系统之所以能成为主流选择,核心在于它用射频技术把资产全生

智能体工作流知识沉淀:从一次修复到长期记忆
AI教程 · 2026-07-08

智能体工作流知识沉淀:从一次修复到长期记忆

好的,作为一位资深的技术专家和知识管理实践者,我将为你重新讲述这篇文章的核心内容,让这些观点和案例听起来更像是一次真诚的技术分享,而不是一份AI生成的报告。 在传统软件工程里,我们反复念叨“代码复用”,但到了AI Agent参与的工程时代,真正能产生复利的东西变了——从“代码复用”悄然转向了“知识复