让智能体跨多个独立仓库协同工作

后端仓库和客户端仓库彼此关联，却各自独立存在——智能体在这种情况下需要一套与单一仓库（monorepo）不同的策略。

与单一仓库（monorepo）的区别

《在大型单一仓库中使用 AI 智能体》一章讨论的是一个仓库下容纳众多子项目的情况。本章讨论的则是相反的情况：多个各自独立、分别进行版本管理的仓库——比如一个 API 后端和一个独立的前端仓库——它们共同组成一个系统，但各自拥有自己的 Git 历史、自己的 CLAUDE.md 和自己的部署流水线。

各仓库自有上下文

每个仓库都保留自己的 CLAUDE.md 及其自身的约定。在后端仓库中启动的智能体会自动了解该仓库的规则——但不会自动加载前端仓库的规则，因为这两个仓库在技术上互不知晓对方的存在。

建立对第二个仓库的访问

Claude Code 可以通过额外的目录访问权限，接入另一个单独检出（checkout）的仓库副本——用于让单一仓库中的相邻软件包可访问的同一种技术，同样适用于磁盘上完全独立的第二个仓库。

协调变更与顺序

如果 API 契约发生变化，通常需要先合并并可部署后端的改动，之后才能调整客户端——或者双方在一个过渡期内保持向后兼容。如果没有刻意安排的顺序和版本管理，客户端和服务器之间就有可能产生不兼容的假设。

示例

任务：为价格信息接口新增一个 'currency' 字段，后端仓库 'tm2-api' 和前端仓库 'tm2-web' 是相互独立的。步骤 1（在 tm2-api 仓库中）：以增量方式将该字段添加到响应 schema 中，由于该字段是可选的，旧版客户端仍然保持兼容。部署上线。步骤 2（通过 --add-dir 或单独的会话访问 tm2-web）：调整客户端，使其在该字段存在时使用新字段，否则使用此前的默认值。步骤 3：只有在两端都确认成功上线之后，才将后端中的该字段标记为必填。

🛠️ 练习——自己动手试试

模拟一次跨两个独立本地仓库的协调变更。

在本地创建两个小型的、相互独立的 Git 仓库，一个作为“API”，一个作为“Client”，二者通过一个简单的文本文件共享一份“契约”（例如一个 JSON schema）。
在 API 仓库中以增量方式修改这份契约（新增一个可选字段），并提交。
让一个智能体同时访问这两个目录，并让它调整客户端，使其在新字段存在时加以使用。
检查客户端在没有新字段（旧版契约）的情况下是否仍然能够正常工作。

✅ 自查清单

☐ 在新版本已经存在的情况下，使用旧版契约的客户端是否仍然保持正常可用？
☐ 智能体是否必须显式地访问第二个仓库目录，还是它自动做到了这一点？

小测验

跨多个独立仓库工作，与在一个包含众多子项目的单一仓库中工作，根本区别是什么？