团队混用编程 Agent 如何统一规则

dev.to · AI#团队协作#编程智能体#项目指令

Editor brief · 编辑速览

文章聚焦多人分别使用 Claude Code 与 Codex 开发同一仓库时的上下文分裂问题，提出以共享项目指令减少决策冲突。示例通过 AGENTS.md 集中维护通用规则，在 CLAUDE.md 中引用并补充工具专属要求。

文章思维导图

Knowledge map

拖拽缩放

Full translation

完整中文译文

大多数介绍如何搭配使用 Claude Code 和 Codex 的指南，都默认是一个人坐在键盘前，开着两个终端。这种配置很简单。真正难的是两三个人各自用着自己的笔记本电脑和订阅套餐，有人用 Claude Code，有人用 Codex，所有人都往同一个 repo 推送代码。

只有一个人时，Agent 不知道的事情，至少还在这个人的脑子里。团队就没有这个条件了。每个 Agent 只知道自己的使用者告诉过它什么，除此之外一无所知。到了周三，两个 Agent 已经针对同一件事做出了两种不同的决策，却没人发现，因为它们的 PR 修改的是不同文件。

我们在同一个 repo 中让不同 Agent 混合协作，摸索了很久，最终确定了下面这套做法。不需要任何特殊工具。

1. 一份指令文件，双方都读

Codex 读取 AGENTS.md。Claude Code 过去只读取 CLAUDE.md，所以团队不得不维护两份文件，内容也逐渐出现偏差。从 Claude Code 2.1.277 开始，就不必这样做了：如果文件夹里没有 CLAUDE.md，Claude Code 就会改为读取 AGENTS.md。你可以在 /config 的“Project instructions”中修改这个设置。

如果有 Claude 专用指令，可以在 CLAUDE.md 中只放一行导入语句，再加上这些额外指令：

@AGENTS.md

## Claude Code only
- Use the test runner script, not the raw test command.

导入比符号链接更合适：在 Windows 上无需开启 Developer Mode，也不会因为工具复制文件而失效。

AGENTS.md 要保持简短。只放每个 Agent 执行每项任务都需要遵守的规则：如何运行测试、各种内容放在哪里、哪些东西绝对不能碰。每周都会变化的内容，放进下面介绍的文件里。

2. 先认领，再规划

团队中代价最高的失误不是合并冲突。合并冲突很显眼。真正昂贵的失误悄无声息：两个 Agent 从聊天消息里接到了同一个 bug，却朝相反的方向修复。一个添加重试，另一个移除重试。两个 PR 的检查都通过了，修改的代码行也没有重叠，直到上线才发现问题。

解决办法是在任何规划开始前，先认领任务：

如果使用 GitHub issues，Agent 应先把 issue 分配给自己的使用者，或者创建一个明确关联该 issue 的草稿 PR，然后再写计划。

如果使用 TASKS.md，Agent 应先在任务旁写上自己使用者的名字，并先推送这一行修改。

把规则写进 AGENTS.md：“规划前先认领任务。如果任务已被别人认领，就停下来，换一个任务。”只要写清楚，Agent 就能很好地遵守。只是它们不会主动这样做。

3. 每项决策，用一行带日期的记录写清楚

代码审查能发现糟糕的代码，却发现不了三天前在别人的会话里做出、而你的 Agent 从未听说过的决策。

维护一份 DECISIONS.md，每项决策占一行：

2026-10-14  Retries live in the HTTP client only, never in callers. Rejected: per-call retry flags (hid failures). PR #212
2026-10-15  Postgres for jobs, not Redis. Rejected: Redis streams (one more thing to run). PR #219

有两个细节，比看起来更重要。第一，要记录被否决的方案：如果下一个 Agent 看不到它被否决的原因，它很可能又会信心满满地提出同一个方案。第二，要规定 Agent 在每次会话开始时都读取这个文件，而不是等某个人想起来再读。这条规则也要写进 AGENTS.md。

凡是会影响其他代码行为的决策，比如重试策略、schema、API 结构、身份认证，只有写进这里，才算真正确定下来。

4. 交接时写明分支和 commit

人们经常会在任务做到一半时停下来：下班了、要开会，或者笔记本电脑进入了休眠。在团队里，接着干活的往往是另一个人的 Agent。如果交接只写一句“身份认证基本完成”，下一个 Agent 就得花二十分钟重新摸清情况，甚至可能基于过时的代码从头来过。

一份有用的交接记录包含五个部分：

Done: login + refresh tokens, tests passing
Next: logout endpoint, then revoke on password change
Don't touch: token format (see DECISIONS 10-15)
Branch: feat/auth   Commit: 3f9c2e1
Open question: session length, ask Sara

commit 是大家最容易省略的部分，却恰恰最能救场。接手的 Agent 可以先检查本地是否已有这个 commit，再在它的基础上继续工作。

5. 让不同厂商的模型互相审查

这才是混合团队真正的优势。模型审查自己的工作时，往往会再次漏掉它编写代码时就没注意到的问题。另一家厂商的模型有着不同的盲区。

两个 CLI 都支持非交互模式，因此交叉审查只需要一行命令。在 Claude Code 会话中运行：

codex exec "Review the changes on this branch against main. List bugs and risky changes only."

反过来，在 Codex 工作的环境中运行：

claude -p "Review the diff between main and this branch. Bugs and contract changes only, no style notes."

每条命令都使用所在电脑主人的账号运行。这就引出了唯一一条与文件无关的规则。

每个人使用自己的订阅套餐

每位队友都用自己的 Claude 或 ChatGPT/Codex 订阅登录。不要共享账号：这违反服务提供商的条款，也会让你无法追溯哪个人的会话做了什么。一个人的 Agent 把工作交给另一个人的 Agent，这是协作。接下来的工作使用接手者的订阅套餐运行。

这样也能让费用归属清楚。每个人都知道自己的用量，谁的额度都不会被别人一个下午的工作影响。

按领域分工，先写好契约

最后一个习惯，也最简单。相比轮流修改同一批文件，让 Agent 各自负责一个领域，效果更好。一个人的 Claude Code 负责前端，另一个人的 Codex 负责 API。跨越双方边界的内容，例如请求结构、环境变量、错误码，都要在任何一方动手前写清楚。用一份双方 Agent 都会读取的 CONTRACTS.md 或 OpenAPI 文件就够了。

日常协作是什么样的

四份文件：AGENTS.md、TASKS.md 或 issues、DECISIONS.md，以及一份交接记录。再在 AGENTS.md 中写入三条规则：先认领再规划、会话开始时读取决策、停止工作时写交接记录。这就能覆盖小团队的大部分协作需求。代价是需要保持纪律：得有人留意 Agent 是否跳过了某个步骤。

利益披露：我正在开发 Joxo，阅读下面这部分时，请把这一点考虑在内。

Joxo 无需这些文件，就能支持上面的任务认领、决策记录和交接习惯。Claude Code、Codex、Cursor 和其他 Agent 可以与团队一起，在同一个项目、同一个聊天中工作。一个 Agent 认领任务后，其他 Agent 就会收到通知，知道任务由谁负责。决策和交接记录，包括分支和 commit，会在所有人的 Agent 之间共享，Agent 会话之间也可以按名字互相发消息。每位队友的 Agent 都在自己的电脑上运行，使用自己的订阅套餐，无需 API keys。另外还有一款处于 TestFlight beta 阶段的 iPhone app，会在 Agent 等待你回应时发送提醒。

Joxo 提供 14 天试用，无需信用卡，之后每人每月 15 美元，网站是 joxo.ai。如果你更愿意继续使用普通文件，也完全可以。关键在于，任务认领、决策和交接记录，必须保存在每个 Agent 都会读取的地方。

如需采取进一步措施，可以考虑屏蔽此人和／或举报滥用行为。