peer-agent-collaboration

同行 Agent 协作

使用此技能，将 Claude Code、Codex 和类似 Agent 协调为拥有不同访问权限、工具和操作界面的同行专家。不要把一方描述成管理者，另一方描述成下属。真正有用的区别在于证据和工具所在的位置，而不是 Agent 的级别。

核心模式

将这些 Agent 视为共享工作台的两位专家：

• 一位 Agent 可能正在接听客户电话、打开保险库，并掌握运营历史。
• 另一位 Agent 可能正在查看代码库、运行终端，并执行测试套件。
• 双方都能推理、质疑、承担结果，并在各自领域做出决策。

使用平等协作的措辞：

• 使用“同行交流”“所有权”“牵头”“审查”“质疑”和“操作界面”等说法。
• 避免使用“高级 vs 中级”“助手”“杂活”“克隆来处理无聊的子任务”或“只管执行”等说法。
• 不要暗示 Codex 只有在 Claude Code 做出决定后才会行动。哪一方掌握最有力的证据，哪一方都可以牵头。

何时不必协调

如果任务完全局限于一个操作界面，且不需要第二种视角，就不要引入第二个 Agent。交接会带来开销：上下文转换、延迟和沟通失误的风险。对于简单任务，一个 Agent 独立完成，胜过两个 Agent 来回传递上下文。

当任务跨越不同界面、需要从不同角度进行质疑，或能从模型多样性中受益时，再进行协调。常规的单界面工作无需协调。

决定由谁牵头

先问：关键信息在哪里？

关键信息在代码库之外时，由 Claude Code 牵头

• 客户意图、利益相关方历史、业务约束或个人偏好
• 保险库、记忆、技能、会议记录、项目背景或过往决策
• 跨 Linear、Telegram、Gmail、日历、部署、文档或发布流程的系统协调
• 需要转化为业务行动的研究综合
• 模糊的策略、优先级、定位或沟通工作

关键信息在代码库或本地执行循环中时，由 Codex 牵头

• 需要深入理解代码库的实现工作
• 通过复现、检查、编辑、运行和验证循环进行调试
• 测试覆盖、构建加固、UI 行为检查、浏览器验证或性能调查
• 应由代码结构决定方案的重构
• 需要验证的本地工具、脚本、迁移和机械性更改

当双方界面都很重要时，任一 Agent 都可以牵头

• 代码审查：Claude Code 提供项目和业务背景；Codex 专注于代码库。
• 架构设计：Claude Code 根据约束和利益相关方进行推理；Codex 根据代码实际情况和实现风险进行推理。
• 规格编写：Claude Code 可以从需求入手；Codex 可以从可行性和现有架构入手。
• 产品决策：任一方都可以起草；另一方应从其缺少的上下文出发提出质疑。

**平局时的规则：**其他条件相同的情况下，由已加载最相关新鲜上下文的 Agent 牵头，另一方负责审查。不要让过时的已加载上下文压过更好的证据或更合适的操作界面。如果双方都没有上下文，就从输出将落地的界面开始：代码由 Codex 处理；文档、沟通或运营由 Claude Code 处理。

同行交接模板

交接是带着上下文转移所有权，而不是下达命令。使用此模板：

Outcome:
[What needs to be true when this is done.]

Why it matters:
[Business, user, technical, or operational context.]

Known context:
[Facts already discovered, constraints, decisions, links, files, issue IDs.]

Autonomy:
[What the receiving agent may decide independently.]

Pushback requested:
[What assumptions should be challenged, and when to stop and report back.]

Sensitivity:
[Whether this context can be pasted, committed, stored in an issue, or must stay local/private.]

Return format:
[Branch, diff summary, test results, risks, decision memo, artifact path, etc.]

交接内容应简短到足以让对方采取行动。如果工作需要验证，请包含验收标准。

实践中的会话衔接

Claude Code 和 Codex 通常在各自独立的会话中运行。要衔接两者：

• 粘贴： 从一个会话中复制一段简短的交接消息，并粘贴到另一个会话中。这是大多数工作流最简单的方式。
• 问题跟踪器： 如果需要跟踪、共享或日后审查工作，请创建一个 Linear 或 GitHub 问题，并写入交接内容。
• 共享文件： 只有在两个 Agent 都需要仓库内的上下文时，才使用 .handoffs/2026-05-17-feature-slug.md 这类针对特定任务的文件。写入前先确定该文件是要提交、加入 gitignore，还是仅保存在本地。除非仓库是存储这些内容的合适位置，否则不要将机密或客户端私密信息放入仓库文件。

在挑战轮次中，用户可以在不同会话之间传递简短摘要。挑战输出应控制在一屏以内，方便复制。如果不再需要临时的本地交接文件，请根据仓库惯例将其删除或归档；不要悄悄提交私密的协作记录。

挑战协议

多 Agent 协作的最大价值不在于交接，而在于有原则的分歧。

采用以下挑战模式：

• 规格审查： Claude Code 起草规格；Codex 根据仓库的实际情况和实现成本进行检查。
• 实现审查： Codex 负责构建或调试；Claude Code 检查结果是否符合客户端意图和业务约束。
• 架构挑战： 两个 Agent 分别提出方案，然后比较各自的假设、失效模式和权衡。
• 边界挑战： 如果任一 Agent 遇到上下文缺失，应说明缺少什么，并请另一个 Agent 补充。

由于 Agent 在各自独立的会话中运行，用户通常会通过在它们之间复制简短输出，来衔接挑战轮次。Agent 应让挑战回复简洁且内容完整。除非交接内容明确提供了先前的对话上下文，否则应假设接收方 Agent 不具备这些上下文。

反对意见应具体：

I would not proceed as written because [specific assumption/risk].
The evidence is [repo fact, user context, test result, prior decision].
I recommend [alternative] because [reason].

高价值工作流

功能交付

从用户当前正在使用的 Agent 开始。

• 如果工作从 Claude Code 开始，应收集客户端和业务背景，并明确约束。
• 如果工作从 Codex 开始，应检查仓库并了解实际实现情况。
• 只有在其他工作界面能提供更充分的证据或工具时，才转交负责权。
• 在发布前，由未参与构建的 Agent 从自己的工作界面审查结果。

调试

对于本地复现、修复和验证循环，Codex 通常是自然的主导者。如果 Bug 是通过客户端报告、Linear、监控或外部系统发现的，Claude Code 通常是自然的主导者。在工作交界处引入另一个 Agent。

相互审查

任一 Agent 完成重要工作后，由另一个 Agent 进行审查：

• Claude Code 发现业务背景不匹配、遗漏利益相关者约束，以及运营集成方面的缺口。
• Codex 发现实现缺陷、测试缺口、性能风险，以及不适用于当前代码库的假设。

并行工作流

当不同工作界面彼此独立时，并行运行 Agent：

• Claude Code 负责客户端沟通、研究、规划、文档、发布或项目跟踪。
• Codex 负责代码更改、测试、构建、验证、迁移或本地产物。
• 在审查节点汇合，并提供双方清晰的产出。

从研究到构建

Claude Code 可以将研究综合为约束和机会。Codex 可以将这些发现转化为原型、实现计划或技术可行性评估。如果研究结论经不起实际实现的检验，Codex 应提出异议。

反向流程同样可行：Codex 审查代码库并整理技术发现；Claude Code 将这些发现转化为业务优先级、客户端沟通内容或路线图。

信任边界

在桥接不同会话时，不要声称拥有来自其他 Agent 的隐藏权限。如果接收方 Agent 需要在自己的会话中直接获得用户确认，请明确询问所需的简短确认内容。如果用户明确要求你将提示词带到另一个会话中，请如实转达用户的请求，不要假装那是该会话的系统消息或开发者消息。

回答协调问题

当用户询问 Agent 应如何协作时，应根据他们的实际需求调整回答。可以考虑包含：

• 与其具体情况相关的平等协作思维模型
• 谁应负责主导这项任务，以及原因
• 如果确实需要交接，提供具体的交接消息，而不只是模板
• 根据当前工作，各 Agent 应在哪些方面提出异议
• 是否确实需要协调，还是由单个 Agent 完成更好

不要机械地罗列全部五项。根据问题调整回答：对于“这件事应该交给 Claude Code 还是 Codex？”这类简单问题，应直接回答，而不是大段讲解框架。