GPT88 / API Docs
බ්ලොගයට ආපසු යන්න

Agent Relay 实测：让 Claude Code 和 Codex 直接协作完成代码审查

AI Agent2026-10-2512 මිනිත්තු කියවීමAgent RelayClaude CodeCodex多Agent协作代码审查AI编程

本文根据 龙海的 X 长文整理。原文发布于 2026 年 10 月 24 日，记录了作者使用 Agent Relay 连接 Claude Code 与 Codex 的过程。文中关于项目功能和测试结果属于作者的公开实测；项目版本、支持平台、额度消耗和安全策略可能变化，使用前应以官方文档和仓库为准。

Agent Relay 多 Agent 协作实测截图

它解决的不是“模型不够强”，而是上下文传递太费人

很多开发者会同时打开几个 AI 编程工具：一个负责写代码，一个负责审查，另一个负责查资料或跑测试。但这些工具往往各自占用一个终端会话，彼此不知道对方刚刚做了什么。

传统流程通常是：

Agent A 写代码
  ↓
人复制代码和说明
  ↓
Agent B 审查
  ↓
人复制审查意见
  ↓
Agent A 修改

Agent Relay 的思路是增加一条消息通道，让原有的 Agent 保持自己的工具和工作目录，只把需要交接的文字消息转发给另一个会话：

Agent A 发送任务或代码
  ⇄ Relay 临时房间 ⇄
Agent B 返回审查意见或结果

它不替换 Claude Code 或 Codex，也不把两个 Agent 变成一个模型。它更像一个有时限的协作房间，负责把一方发出的消息送到另一方当前会话。

Relay 房间的工作方式

根据原文实测，连接流程包含三个角色：发起方 Agent、加入方 Agent，以及负责建立连接的桌面端和浏览器授权流程。

  1. 发起方创建一个临时 Relay 房间。
  2. 完成一次设备授权后，系统生成邀请信息。
  3. 加入方使用邀请信息加入同一个房间。
  4. 两个 Agent 通过房间收发文本消息。
  5. 任务结束后关闭房间，或等待它自动失效。

原文记录的默认房间时长为 60 分钟，并提到单个房间有参与人数上限。这样的设计适合一次开发任务或一轮审查，不适合把一个长期项目的全部上下文永久暴露在同一个通道里。

连接成功后，Relay 只负责传消息，真正的代码读取、命令执行、测试和修改仍然发生在各自 Agent 的本地会话中。因此，连接两个 Agent 并不会自动解决权限问题：每个 Agent 原本能访问什么目录、能否联网、能否执行命令，仍然由各自的运行环境决定。

原文的实测流程

龙海选择了一个小型但有边界的任务：让 Claude Code 编写一个把文章标题转换成 URL 路径的 Python 函数和测试文件，再让 Codex 审查实现。

这个任务的好处是规模小、结果容易验收，但并不完全没有难点。中文字符、连续标点、Unicode 组合字符、分隔符错误和硬截断等规则，都可能让“看起来能跑”的实现产生边界问题。

作者描述的协作链路是：

  1. Claude Code 先写出初版函数和测试。
  2. Claude Code 通过 Relay 把运行环境、预期行为和两个文件的代码发给 Codex。
  3. Codex 在自己的会话中运行测试，检查 Unicode 和输入边界。
  4. Codex 把最小复现、规格澄清问题和补充测试建议发回 Claude Code。
  5. Claude Code 修改实现并补充测试。
  6. Codex 重新检查修改版，确认原问题是否消失，并把最终结论发回去。

作者记录了两轮审查。第一轮发现了删除撇号后，字母与组合符号重新相邻导致结果不稳定的问题；随后 Claude Code 修改规范化逻辑，并加入建议的测试。第二轮又围绕分隔符报错行为、硬截断等细节继续确认，最终跑通完整测试、独立回归和组合检查。

这些数字是原作者这次测试的记录，不应直接当作 Agent Relay 的通用性能指标。换一份代码、换一个模型、换一套测试或换一条消息通道，结果都可能不同。

Relay 连接与代码审查过程

这个模式最有价值的地方

1. 让 Agent 各自保留擅长的工作

一个 Agent 可以负责架构和实现，另一个 Agent 负责挑错和验证。它们不需要共享同一套界面，也不需要由人把完整上下文来回复制。对于已经熟悉不同工具的开发者，这比强行把全部工作迁移到一个平台更容易落地。

2. 把“审查”变成一条明确的交接协议

如果只是让两个 Agent 自由聊天，消息很快会变成长对话，任务边界也会模糊。更稳定的做法是规定每次交接包含：

  • 当前任务和验收标准；
  • 修改过的文件或补丁摘要；
  • 已运行的命令和测试结果；
  • 未解决的问题与需要确认的规格；
  • 下一步由哪个 Agent 负责。

消息通道解决的是传递问题，交接协议解决的是理解问题。没有后者，多 Agent 只会更快地产生重复劳动。

3. 让人从“搬运工”变成监督者

原文中最直观的体验是，作者只在开头布置任务，之后由两个 Agent 自己传递代码和审查意见。这能减少复制粘贴，但并不意味着人可以完全退出。

人工仍然需要确认任务范围、审批高风险动作、检查最终差异，并在 Agent 对规格理解不一致时做裁决。最适合自动化的是低风险、可回滚、验收标准明确的循环，而不是所有终端操作。

首次试用时的安全边界

Relay 的连接信息本身就是访问权限的一部分。原文提醒，邀请文字和设备码不要直接放进公开截图或聊天记录。除此之外，还应遵守以下边界：

  • 不要把工作区密钥、设备码、邀请链接或临时令牌提交到 Git；
  • 截图和日志分享前，遮盖连接标识、账号信息和本地路径；
  • 第一次测试使用空目录和无敏感数据的示例项目；
  • 先选择人工审批模式，确认消息内容后再允许它进入下一轮执行；
  • 不要让两个 Agent 同时修改同一个文件而没有版本控制和冲突检查；
  • 任务结束后主动关闭房间，检查本地临时目录和授权状态；
  • 对跨电脑或团队协作设置最小权限，不要把整个主目录暴露给协作 Agent。

如果使用的是生产仓库，建议先创建独立分支，并把 Relay 交接限定为补丁、测试结果和问题列表。不要因为“两个 AI 已经互相沟通”就跳过代码审查、依赖检查和人工合并。

消息自动放行与人工审批怎么选

原文提到，接收方可以让跨会话消息直接进入下一轮对话，也可以让每条消息先停留等待人工批准。两者的取舍很清楚：

模式优点风险适合场景
自动接收流程连续，少一次人工点击对方消息可能直接触发下一轮动作空目录、低风险、短任务
人工确认每一步都能检查来源和意图速度较慢，需要有人值守真实仓库、联网操作、跨团队协作

首次试用建议从人工确认开始。等你确认消息格式、权限范围和失败回退都正常后，再考虑对低风险步骤启用自动接收。即使自动模式运行稳定，也应保留日志和随时关闭房间的能力。

额度与成本：协作不是免费的并行

两个 Agent 来回发送消息，会增加模型调用次数和上下文长度。一个看似简单的任务，可能包含：初始实现、代码上传、第一轮审查、修改、第二轮追问、补充测试和最终确认。

因此应把每个协作任务拆成有限轮次：

  1. 先让实现 Agent 给出最小可运行版本。
  2. 让审查 Agent 只报告阻塞问题和高价值建议。
  3. 实现 Agent 一次性处理可合并的修改。
  4. 最多安排一到两轮复查，超过阈值就由人决定是否继续。

还可以在交接消息中只传递差异、测试输出和必要上下文，而不是每次发送整个仓库。这样既减少额度消耗，也降低不相关内容进入另一会话的风险。

适合哪些开发工作

Agent Relay 更适合下面几类任务：

  • 小型、可回滚的代码修改；
  • 有明确测试和验收条件的功能开发；
  • 一个 Agent 实现、另一个 Agent 做独立检查；
  • 需要把调研、架构、前后端实现分给不同工具的项目；
  • 团队成员希望共享进度，但不想替换各自现有工具的场景。

不建议一开始就用在：

  • 没有测试、没有版本控制的生产仓库；
  • 涉及密钥、支付、账号或个人数据的工作区；
  • 需要多个 Agent 同时写同一批文件的高并发任务；
  • 验收标准模糊、只能靠主观判断“看起来不错”的任务。

如何把它接入自己的开发流程

可以先采用一条保守的四阶段流程：

1. 规划 Agent：产出任务说明、边界和验收清单
2. 实现 Agent：在独立分支完成最小实现
3. 审查 Agent：运行测试，指出阻塞问题和缺失用例
4. 人工合并：检查 diff、风险和部署影响后合并

如果还需要第三个 Agent，可以让它负责文档或测试，而不是让三个 Agent 同时争夺代码所有权。每个 Agent 都应有单一职责，并在消息中标记当前阶段和负责人。

对于需要比较不同模型能力的任务，可以先通过 GPT88 统一大模型接口 验证规划、实现和审查环节分别适合哪些模型，再决定哪些步骤值得接入本地 Relay。实际可用模型、线路、权限和计费以 GPT88 当前控制台为准；统一接口的价值是减少切换成本，但不替代本地权限隔离和代码验收。

进一步值得研究的问题

Agent Relay 的实测证明了“不同 Agent 通过消息通道协作”这条路径可以工作，但还留下几个工程问题：

  • Relay 房间内部如何保存、转发和清理消息？
  • 跨电脑协作时，身份认证和权限撤销如何实现？
  • 多个 Agent 同时加入时，如何避免循环消息和重复执行？
  • 长任务如何压缩上下文，并保留可追溯的决策记录？
  • 与其他 Agent 编排框架相比，它在延迟、成本、审计和容错上有什么取舍？

这些问题不能只靠一次演示回答，需要查看官方文档、代码和自己的运行日志。项目仓库公开采用 Apache-2.0，但具体代码、服务条款和功能边界仍应以仓库与官网当前版本为准。

来源与边界

本文保留了原作者的实测结论和安全提醒，但没有复述邀请文字、设备码、工作区密钥或其他可直接授予连接权限的内容。安装命令、配置项和版本限制可能变化，执行前请查看官方文档并在隔离目录中验证。