假设你接到的需求不是“改一个函数”而是“在六个仓库里完成同一个新功能的端到端实现”。前端仓库要加页面后端仓库要加接口共享库要改类型定义还有一个仓库要补数据库迁移脚本。如果让一个 AI agent 来做这件事它面对的难点根本不是“提示词写得够不够好”而是改动应该落到哪个目录、跑测试时用哪个工作目录、多仓库之间的耦合依赖怎么验证。这类问题的工程答案过去往往落在代码索引上先把所有仓库扫一遍建立搜索库、依赖图、符号表agent 再去查索引。但最近看到的一个项目思路有点不一样。这个项目叫 Orbit它的标题写得很克制One agent across many repos: real worktrees, no index。翻译过来就是一个 agent 横跨多个仓库使用真实的 worktrees不依赖索引。这句话值得展开因为它的取舍完全绕开了过去几年的“索引一切”思路。1. 为什么跨仓库开发是 agent 场景里最难的一类任务1.1 agent 写代码不难难的是让改动落在正确的位置大模型生成代码的能力已经不需要再验证了。哪怕是初学者也能让 agent 写一个函数、一个页面、一个单元测试。但生成代码只是第一步真正困难的是把生成结果落到一个真实项目的正确位置。跨仓库场景下这个困难会被放大agent 要同时理解多个仓库的目录结构要决定改动分散在哪几个仓库要保证这些改动在构建和测试时能互相配合。这类任务过去人能做好是因为人有“多仓库心智模型”知道每个仓库的职责边界、知道改动波及面、知道每个仓库的构建顺序。而 agent 默认没有这个模型它需要外部工具帮它建立。如果工具设计得不好agent 就会把代码写在错误的位置或者把上下文塞得过大导致输出质量下降。这也是为什么很多 agent 项目只能停在“演示能跑通”的阶段却很难真正进入日常开发流程。1.2 单仓库 agent 与多仓库 agent 之间隔着一条工程化鸿沟市面上大多数 agent 工具默认基于单个工作目录工作。你在一个目录里启动 agent告诉它改这个文件、加那个函数它只需在当前目录中寻找、读取、修改。但跨仓库任务不是这样的。几个仓库之间可能是服务调用关系可能是共享依赖关系也可能是互相导入的类型关系。一个 agent 要在这几个仓库之间做一次一致的改动就必须能同时操作多个工作目录。单仓库 agent 只需要管理一个工作区多仓库 agent 需要管理多个工作区并对工作区之间的关系有判断。这已经不是模型能力问题而是工程架构问题。所以标题里最值得关注的不是“agent”而是across many repos和real worktrees。前者定义了问题域后者给出了解法方向。1.3 传统索引方案为什么会在多仓库场景下失效过去解决“agent 怎么理解多个仓库”的主流思路是建立索引把每个仓库的路径、符号、依赖、读取关系全部扫描一遍存进一个可查询的数据库或向量库。agent 通过查索引来回答“这个函数在哪里”“谁依赖谁”。这种方案在小规模单仓库里很好用但到了多仓库场景会暴露几个问题索引维护有成本。仓库一旦频繁变更索引就会漂移agent 查到的可能已经是过期信息。多仓库之间存在版本差异、分支差异。静态索引很难实时对应到每个仓库当前的真实状态。索引往往偏重“结构信息”而 agent 在动手改代码时真正需要的通常是“当前文件内容”和“当前目录状态”。标题里强调 “no index”本质上是想绕开这个复杂度与其维护一份可能过时的静态索引不如让 agent 直接面对真实的工作目录。这里值得先停下来理解一个区别如果 agent 面对的是真实文件系统那么它读到的每一个文件都是“当前状态”如果 agent 面对的是索引那么它只能读到“上次扫描时的状态”。跨仓库开发中这个差异会直接决定改动是否正确。2. Orbit 的做法用真实 worktree 替代静态索引2.1 git worktree 是什么为什么适合 agentgit worktree 是 git 自带的机制同一个仓库可以从不同分支检出多个工作目录。每个 worktree 有独立的目录、独立的 HEAD但共享仓库的.git对象库。这意味着你可以在同一个仓库上并行维护多个工作目录每个目录可以检出一个不同分支互不干扰。对 agent 来说这个机制非常有用每个任务可以创建一个独立的 worktreeagent 在其中自由修改不影响其他任务。任务之间并行执行时目录隔离是天然的不会出现多个 agent 改同一个文件导致冲突。任务结束后可以直接基于该 worktree 的 diff 做审查、构建、测试。也就是说worktree 提供的是一条“活的工作目录链”而不是一份静态代码快照。需要澄清一个容易混淆的点git worktree 内部也有一个 git index也就是暂存区。标题里的 “no index” 不是指“不使用 git 暂存区”而是在强调“不建立额外的代码索引”。这里的 index 更像是指那些需要提前扫描、持续更新的静态代码知识库。2.2 “无索引”不是不做上下文而是不维护一份静态快照有人可能会担心不建索引agent 怎么知道代码结构怎么完成跨文件搜索这里要区分“上下文获取”和“静态索引”上下文获取是 agent 在需要的时候去读取文件、搜索路径、查 git 历史。静态索引是提前扫描所有内容存起来供后续查询。Orbit 的标题显然指向前者agent 面对的是真实文件系统它可以通过工具调用去查找内容、读取文件、查看 git 状态而不是依赖一份离线索引。这种设计的好处非常明显agent 每次看到的内容都是真实的、当前状态的不会出现索引过期导致幻觉式调用。代价是每次都要实时获取上下文相比直接查索引会更慢也对 agent 的工具调用能力提出了更高要求。但从“改动真正落到仓库里”这个角度看实时真实目录比静态索引可靠得多。2.3 从结果看每次任务都能拿到一个可审查的真实目录对工程团队来说最关心的不是 agent 用了什么机制而是结果好不好审查。按任务创建 worktree 的做法天然带来一个优势每个任务都有独立的目录、独立的分支、独立的 diff。你不需要从一大坨改动里挑出“哪些是这次任务产生的”只需要检查这个 worktree 的 diff。这解决了 agent 落地时一个关键问题可审查性。审查一个 agent 的改动往往比让 agent 写代码更难。如果 agent 把改动直接塞进现有分支你很难判断它是否碰了不该碰的文件如果它有独立 worktree你把 diff 拉出来一眼就能看出改动范围。在这个设计下agent 的输出不再是一段“建议”而是一份可以进行真实构建、真实测试、真实 code review 的变更集。这个差别决定了它能不能被放进正式开发流程。3. 从探索到落地如何在多仓库上跑通一个 agent 任务3.1 最小验证流程先解决“改得到、看得到、查得到”如果我想验证一个类似 Orbit 的思路不会一上来就让它完成一个包含五个仓库的大型任务。更稳妥的方式是先做一个最小验证确认最核心的三件事agent 的改动能真实落在多个工作目录里。每个工作目录里的改动可以独立查看。多个仓库之间的构建或测试能够相互配合。具体步骤可以是准备两个以上的仓库仓库之间最好有一个真实的依赖关系例如一个共享库和一个使用该共享库的服务。在某个仓库里启动 agent让它基于当前主分支创建一个新的 worktree。给它一个明确的单点任务比如在共享库新增一个函数并在另一个仓库里调用它。检查两个仓库的改动是否都落在预期位置。分别执行两个仓库的测试看是否能互相打通。这个流程的核心指标只有一个agent 的改动是否真实落在两个 worktree 目录里并且两个仓库的构建能够打通。如果跑通了再逐步增加任务复杂度。不要反过来。3.2 关键参数和设计问题任务隔离、并行、清理、分支策略实际使用中有四个问题必须提前想清楚这比模型参数更影响可用性。任务隔离是否每个任务独立 worktree还是多个任务共用一个更推荐每个任务独立因为清理和回滚都方便。并行度同时运行多个 agent 任务时每个任务消耗的内存、CPU、磁盘都不同。先限制并发数例如同一时间最多 2 到 3 个任务跑稳定后再逐步加。清理策略worktree 不会自动消失任务结束后要清除对应的分支和目录否则磁盘会越来越满。需要约定谁负责清理、什么时候清理。分支策略从哪个主分支切出 worktree任务完成后是合并回主干还是直接提交一个 PR这需要团队先行约定。从工程经验看这四个问题如果不在第一天定清楚后面一定会在某个夜晚爆发。3.3 输出检查清单diff、构建、测试、提交一个跨仓库 agent 任务完成后至少要检查四层检查项具体内容目的diff 范围查看所有仓库的改动文件确认没有误改防止 agent 碰了不该碰的文件构建结果在对应的 worktree 目录中执行构建确认仓库间依赖关系正确测试结果运行相关单测或集成测试确认改动真实可用提交记录确认每个仓库都有自己的分支和 commit方便独立回溯和回滚建议把这四条写成一个清单固定下来每次 agent 任务完成后都按这个顺序跑一遍。3.4 当改动落到错误位置时的排查链路跨仓库 agent 最容易出的问题不是“代码写得不对”而是“代码改到了错误的地方”。比如该改后端仓库agent 却改到了共享库该基于 main 分支创建 worktreeagent 却从旧功能分支切了出来。遇到这种问题不要急着怪模型按这个顺序排查看现象是改动写到了错误仓库还是写到了正确仓库但错误分支看输入任务描述里是否明确说明了仓库范围、路径边界和分支要求看环境worktree 是否基于正确分支创建agent 的当前工作目录是否指向了预期仓库看参数agent 的 root 目录、allowed paths、ignore 规则是否限制了操作范围看工具边界当前工具是否支持显式指定目标仓库还是完全依赖模型自行判断大多数情况下问题出在输入描述不清晰或者工具没有提供足够的“操作边界约束”。这提醒我们跨仓库 agent 不是把模型能力变强了而是把任务描述和操作边界变成了系统设计的一部分。注意不要一上来就把批量数和并发数拉满。先用一条样例确认输入、输出和日志都正常再逐步扩大任务规模。4. 不要急着推广这类工具的适用边界4.1 适合什么人、什么场景基于标题的设计判断Orbit 这类方案更适合以下几类场景。微服务团队改动经常横跨多个服务仓库每次功能开发都要同时改 API 定义、服务实现、客户端调用。半拆分仓库结构多个仓库互相依赖但又没有完全 monorepo 化。团队还处在“仓库拆分后不知道怎么保持一致”的阶段。需要 agent 并行修改多个仓库的批处理场景例如统一升级某类配置、批量修改接口签名、跨仓库增加日志埋点。这些场景的共同特点是仓库之间有真实依赖改动需要跨仓库同步验证。worktree 的隔离能力在这里能发挥最大的作用。4.2 不适合什么人、什么场景反过来有几类场景不一定需要这种方案。不适合场景原因单仓库小任务一个文件改一行直接用普通 agent 或 IDE 插件就够了强依赖全量代码上下文的场景如果任务必须理解整个仓库的所有历史逻辑仍建议先做人工梳理对实时性要求极高的场景worktree 的创建、切换、构建仍然有时间成本仓库边界混乱的代码库如果仓库结构本身不合理任何工具都很难帮你建立秩序这些边界意味着先把适合的场景用起来不要指望一个工具解决所有问题。4.3 工程上需要补的东西清理策略、权限、异步任务管理、可观测性从长期使用维度看至少还缺四块拼图。清理策略worktree 和分支生命周期管理。任务完成后是立即删除 worktree还是保留一段时间用于回溯这需要明确的规则。权限控制谁可以运行 agentagent 可以推送到哪些分支跨仓库改动是否必须经过人工审查异步任务管理长时间运行的 agent 任务如何处理排队任务结束后如何通知相关人员可观测性agent 的每一步操作日志是否可追溯如果改坏了能不能从日志里还原整个过程如果只是尝鲜默认配置通常够用如果要放进真实生产环境这些能力基本是必须的。5. 跨仓库 agent 真正改变的是什么5.1 从人肉协调多个仓库到 agent 作为流程执行者过去跨仓库功能开发最消耗精力的部分往往是“协调”先在前端仓库改再去后端仓库改还要确保共享库先发布或先合并。现在 agent 可以把这些步骤流程化它可以在多个 worktree 中依次修改按依赖关系执行构建和测试最后输出一个统一的变更预览。这就把“一次性的跨仓库操作”变成“可复用的执行流程”。这是这一类工具真正改变工作流的地方。它带来的价值不是“省了十分钟”而是让一个需要多人协调、多个步骤对齐的复杂任务变成了可以被记录、被复现、被改进的标准流程。5.2 它带来一个新问题怎么审查 agent 的跨仓库改动跨仓库 agent 也带来了新的审查挑战。一次改动可能涉及多个仓库、多个分支、多个 commit普通 diff 只能看到单个仓库的变化难以评估跨仓库整体一致性。可行的实践是为每个跨仓库任务创建一个“任务说明文档”记录任务目标、涉及仓库、预期改动、测试结果。这样审查者可以按任务审查而不是按仓库审查。任务说明文档可以很简单但必须包含三块这个任务要做什么。涉及哪些仓库每个仓库的改动意图是什么。验证方式是什么测试结果如何。有了这个文档跨仓库审查就不需要评审者自己去多个仓库之间拼图。5.3 一个可复用的评估框架如果你看完这篇文章想评估一个类似工具是否适合团队可以用下面这个五问框架改动是否落在真实目录而不是虚拟补丁这决定了改动能否被真实构建和测试。任务之间是否天然隔离这决定了并行任务会不会互相干扰。结果是否容易审查这决定了它能否进入正式 code review 流程。上下文是否来自当前真实状态这决定了 agent 会不会基于过期信息行动。清理、权限、日志等工程能力是否具备这决定了它能否长期稳定运行。如果五个问题答案都是肯定的说明这个工具已经具备进入生产流程的基础。如果有一两个不满足要先评估影响有多大再决定是否值得深入试用。跨仓库 agent 的赛道还很年轻。Orbit 用 “real worktrees, no index” 这个设计取舍给了一个很清晰的信号与其建立一套复杂的索引体系去模拟理解代码不如让 agent 直接站在真实代码面前。这个思路不一定适合所有团队但值得每一个试图把 agent 引入正式开发流程的人认真想想。真正决定工具能否落地的从来不是模型多聪明而是它能不能在真实仓库里留下可以被检查、被测试、被回滚的真实改动。