三个团队为AI代理丢失跨仓库上下文问题推出了相同的修复方案

三周前，Cortex 2026工程基准测试显示，自AI采用加速以来，每次拉取请求的事故率上升23.5%，变更失败率上升约30%。我随即撰写了关于这些数据及其对爆炸半径的影响的文章。

当时我低估了语言转变的速度。此后，术语不再是“爆炸半径”或“服务目录”，而是“跨仓库上下文”。它几乎总是与“AI编码代理”出现在同一句子中。原因显而易见：一旦阅读大范围运营AI编码代理的团队发布的内容，你会发现他们不再谈论AI如何提高效率，而是谈论为了AI能够在多个仓库间安全部署而必须构建的基础设施。

最近六周内，三个团队发表了相同的诊断和三种不同的解决方案。它们趋同的模式比任何一个单独方案都更有趣，并对我们如何思考代理运行时基础设施有直接启示。

**三个团队的成果**

Neilos（dev.to上的@neil_agentic），3月27日。一位独立创始人运营着超过15个仓库，涵盖Go、Rust、TypeScript、Python和C++，通过Telegram协调十个专门的Claude Code代理。他的文章《如何管理15+仓库的Claude Code（而不失去理智）》直接指出：最终结果是“在会话之间复制粘贴上下文，手动跟踪哪个PR依赖于哪个，以及监护看不到全貌的代理”。

他的解决方案名为ttal，将“读取与探索”与“写入”分离。一个轻量级探索代理可以跨任意仓库读取上下文。工作代理一次只写入一个仓库，在隔离的git工作树中。一个管理代理在头脑中持有跨仓库计划，并将工作路由到正确的仓库。没有作为数据结构的依赖图。跨仓库协调存在于管理代理的推理和一个将名称映射到文件路径的项目注册表中。

Mabl，4月8日。一个由25名工程师组成的团队管理着100多个仓库，在AI加速前每月推送200多个拉取请求和40多个生产版本。到2026年2月，39%的提交是AI辅助的，在基础设施仓库中这一比例达到60%。他们的文章《我们如何构建系统让AI代理在75+仓库间推送真实代码》描述了一个四层架构。其中关键的一层是“跨仓库基础”。

在跨仓库基础内部，有一个“仓库协调图”：850多行的结构化注册表，覆盖79个仓库，包含详细的依赖图、发布/订阅主题映射、数据库表所有权和规定的发布顺序。当代理处理跨仓库功能时，它会查询此图以确定哪些仓库需要更新、合并顺序（先上游库再消费者）以及根据CODEOWNERS和依赖链标记哪些审查者。他们报告称，没有这一层，“每次代理调用都需要人工提供上下文”。有了它，“上下文漂移从约40%的失败降至5%以下”。

Meta，4月6日。我本周早些时候写过Meta部落知识引擎的文章，这里简略。Meta构建了一个多阶段AI流水线，包含50多个专门代理，用于映射其一个大数据流水线的部落知识。最后一段揭示了重点：“我们生成了一个跨仓库依赖索引和数据流图，展示变更如何在仓库间传播。这将‘什么依赖于X？’从多文件探索（约6000令牌）转变为单次图查找（约200令牌）。”

对于代理在规划过程中最常见的问题之一，令牌减少了30倍。

**相同与不同**

痛点完全相同。所有三个团队都描述了代理生成本地正确但破坏未知消费者的代码。Mabl称为上下文漂移，Meta称为部落知识，Neilos称为代理“看不到全貌”。现象只有一个：决定变更安全性的依赖图存在于任何单一仓库边界之外，也即代理的上下文窗口之外。

解决方案的差异具有启发性。

Mabl和Meta都构建了依赖图作为可查询的底层。Mabl的依赖图是一个结构化的850行注册表，代理在规划时查询。Meta的是一个解析器生成的图索引，代理作为工具调用。形式略有不同，但操作模式相同：确定性结构，自动刷新（Mabl通过注册表更新和CODEOWNERS，Meta通过重新解析源代码），作为单次查找而不是多文件探索。图独立于代理，且比任何单个代理会话更持久。

Neilos的ttal采取了不同方法。跨仓库信息存在于管理代理的工作内存和一个将项目名称映射到文件系统路径的TOML文件中，架构将写入隔离到一次一个仓库，并在管理代理的提示中保持协调模型。这适合拥有十个代理和十五个仓库的独立运营者。在Mabl的规模下，同样的问题重塑了解决方案。一旦有25名工程师在79个仓库中工作，没有单个代理的上下文窗口足以容纳协调模型，而且手动注册表在高吞吐量下无法保持最新，因此依赖模型必须存在于任何代理之外。

我从中学到的是，依赖图作为可查询的底层并非风格选择，而是问题规模化后的必然结果。三个团队遇到了同一堵墙。两个团队明确构建了底层；一个通过协调处理，这在独立规模下是正确的选择。一旦运营代理的团队超过那个规模，底层就是你应该构建的。

**为什么这应该是一个原语，而不是每个团队重新构建**

Mabl的文章几乎理所当然地列出了这一层。Meta的文章在关于代理群体和评论遍数的部分之后，只用一段提及。两个团队都将其视为实现目标的基础设施。在这两种情况下，结构层是他们构建中最便宜、最可复用、最持久的部分。Mabl的每个仓库的CLAUDE.md如果没有维护者会退化。Meta的LLM生成上下文文件如果没有自我刷新的评论群体也会退化。依赖图不会退化，因为解析器在每次推送时运行。

这就引出了每一个非Meta或Mabl的团队的问题：你真的想自己手动编写一个850行的仓库协调图吗？并在仓库添加、归档、重命名和重构时保持其更新？在50名工程师的组织中，这相当于一个全栈工程师月的工作量，以及持续维护的税收，而这并不在任何人的工作描述中。在200名工程师的组织中，这是一个专门平台团队的责任，与所有其他可能工作竞争。

这个原语应属于任何单个团队之上。图本身是结构化的，源自源代码，且在所有组织中形状相同。你真正需要的东西（哪些仓库从哪些仓库导入，谁消费哪个制品，变更的传递爆炸半径）无论你有50个还是500个仓库都是相同的问题。没有理由让每个运行AI编码代理的多仓库组织都从头编写自己的版本。它是一个底层，而不是一个功能。

**作为API的形态**

Riftmap通过单个只读令牌自动发现GitHub或GitLab组织中的跨仓库依赖图，解析十个生态系统中的清单文件：Terraform、Docker、Helm、Kubernetes、Kustomize、Go、npm、Python、Ansible和GitHub Actions/GitLab CI（未来还会添加更多）。该图可通过HTTP API查询，供AI代理在规划期间调用。

自然的代理流程是三次调用。给定代理在github.com/myorg/payments-api的克隆中工作：

1. 将本地克隆URL解析为Riftmap仓库

curl -s "$RIFTMAP_BASE_URL/repositories/lookup?url=https://github.com/myorg/payments-api" \ -H "X-API-Key: $RIFTMAP_API_KEY"

2. 一次往返获取上下文：仓库 + 依赖项 + 反向依赖 + 制品 + 新鲜度字段

curl -s "$RIFTMAP_BASE_URL/repositories/$REPO_ID/context" \ -H "X-API-Key: $RIFTMAP_API_KEY"

3. 只有真正需要时：传递爆炸半径

curl -s "$RIFTMAP_BASE_URL/repositories/$REPO_ID/impact?max_depth=3&min_confidence=0.8" \ -H "X-API-Key: $RIFTMAP_API_KEY"

三次调用回答Mabl的仓库协调图和Meta的依赖索引旨在解决的问题。完整模式发布在https://app.riftmap.dev/openapi.json。获取一次，交给你的代理，其余的就是类型化的httpx或fetch调用。Python和TypeScript版本的这些示例在代理集成文档中，以及每个响应携带的新鲜度合约（last_scanned_at、last_commit_sha、last_activity_at、archived），以便代理判断图是否过时，要么警告用户，要么触发重新扫描。

这就是今天的底层，以HTTP API形式暴露。接下来是MCP服务器和CLI，按此顺序，以便任何Claude Code、Cursor或Cline代理可以直接引入而无需编排HTTP调用。顺序和当前状态在公共路线图页面上跟踪。

**接口比模型更持久**

此时合理的反对意见是：模型最终不会在跨仓库推理方面足够好，从而不再需要这些吗？Claude 5或未来版本不会直接解决吗？

我认为问题不会按照反对意见假设的方向发展。即使假设模型在跨仓库推理方面持续改进，有三点依然成立。

首先，从多仓库组织的依赖清单中进行解析，是在做一个解析器可以确定性和低成本完成的工作。即使前沿模型完美执行，每次调用仍需支付令牌成本，而实际上这是一个预计算的查找。Meta的30倍令牌减少不是模型质量问题，而是架构问题。图索引总是比重新构建更便宜。

第二，模型每六个月变化一次。依赖图不会。稳定API后面的可查询图，无论调用它的代理是Claude 4.7、Claude 5还是2027年的任何模型，其形状保持不变。接口比模型更持久。投资底层与投资任何特定代理的上下文策略处于不同的时间尺度。

第三，新鲜度问题是结构性的。今天训练的模型不知道你的团队上周创建的仓库。昨晚扫描生成的图知道。只要仓库图的变化速度超过模型重新训练的速度，这种差距就存在，而底层就是缩小差距的方法。

模型在跨仓库推理方面变得更好可能改变的是图上面的层次。更好的基于验证结构的语义推理。更好的针对已知消费者影响的自动PR审查。更好的图本身的自然语言界面。这些都是真实的事情，并且会很重要。它们都位于底层之上，而不是替代它。

**总结**

我开始的这三篇文章，正是我构建Riftmap所需的相同模式证据，只是有更响亮的名字。工程师愿意花费真正的工程时间来构建某物，意味着该物是必要的。当三个独立团队在两周内发表相同的诊断时，模式就是模式。

架构赌注没有改变。先确定性解析器。图作为持久层。AI作为上面的层，锚定在验证结构上，而不是重新构建它。