天才工程师的“失忆”困境

想象一下，你从古董店买到一盏神灯，召唤出精灵并许愿获得一位顶级工程师（如 John Carmack）来协助完成不可能的项目。然而，精灵设定了严苛的限制：这位天才只能看到代码库中极小的一部分（例如 1/1000），且每次对话都从零开始，没有任何记忆。这种设定导致了一种极端的不对等：你拥有全局视野和标准规范，而天才工程师对上下文一无所知。你必须反复解释同样的事情，这种体验正如当前 AI Agent 在软件开发中的处境。Agent 本质上是被仓库绑定的，它无法看到包含数百或数千个仓库的整体系统。这种空间上的局限性迫使人类成为“记忆”，在每次交互中重新解释意图，导致效率极低且令人抓狂。

跨仓库变更中的重复解释成本

以包含 UI、模块一、模块二和平台四个仓库的项目为例，当我们需要修改 UI 并 propagate（传播）变更时，Agent 需要经历多次重复解释。首先，我们在 UI 库中更改按钮，这是第一次不可避免的解释；接着发布后进入模块一，必须重新解释 UI 库的变化以便其消费该包。由于 Agent 不知道之前的变更和发现的问题，每次修复都需要重新解释原始变更及当前 issue。如果模块一不兼容，需回到 UI 库修复并重新发布，再向模块二解释新变更，最后到平台仓库整合。假设一周后 UI 出现 Bug 需要修复，我们又要重新解释一周前的原始变更和生产环境的问题。本质上是一次变更，却产生了七次重复的解释。这不仅消耗大量开发者时间，还烧毁了巨额的 Token 资源。

Agent 的两大核心缺陷：空间与时间维度

这些问题可归纳为两类：一是“仓库边界”问题，二是“失忆”问题。在空间维度上，Agent 一次只能查看和更改一个仓库，无法像人类那样理解所有仓库如何协同工作。缺乏全局模型导致 Agent 依赖人类进行调研，无法将代码变更与系统其余部分对齐。例如，如果用户未解释清楚 UI 变更对模块一的影响，Agent 可能发布错误版本。此外，Agent 无法同时更新下游消费者以验证变更，即使它在修改 UI 时拥有完美信息。在时间维度上，Agent 没有情景记忆（Episodic Memory），每次会话都是白板。人类被迫充当记忆的载体，记住所有历史变更和上下文。Agent 看到的只是一个会话、一小部分代码库且无记忆，这与“每次只能看一个文件并记住最后五条消息”的荒谬限制无异。

Polygraph：构建统一依赖图以打破局限

为了解决这些问题，我们构建了名为 Polygraph 的 Agent 无关元框架（Meta Harness）。其核心理念是：如果 GitHub 用户能访问数千个仓库，我们就可以分析这些仓库并提取元数据，构建统一的依赖图。这一过程不修改任何代码行，而是在侧面进行。Polygraph 计算每个仓库生产什么、消费什么包以及产生和消耗哪些 API，从而将这些分散的实体缝合在一起。对于拥有约 300 个自有仓库和数千个开源依赖的项目，Polygraph 创造了一个巨大的单一代码库的错觉，使 Agent 能够读取和写入任何位置。通过提供全局视图，Agent 不再需要依赖人类反复解释上下文，从而解决了空间和信息碎片化的问题。

"That's what agents are. Let me walk you through an example of how many times we re-explain things in a simple interaction."

"The first one is that an agent essentially is repo bound... Second is amnesia. Agent forget the work. Every session start with a blank slate. The human becomes the memory in this case."

"Polygraph computes what each one produces, each repo... and lots of other stuff. And this stitches this together uh into this like one big body of code that your agent can work with."

Polygraph 的核心架构：从信息拉取到变更协调

Polygraph 的首要任务是启动一个会话，将相关的代码仓库纳入其中。这一过程看似简单，实则包含了复杂的底层逻辑：它需要设置源代码、安装依赖项，并为每个仓库配置智能体（Agent），最终将它们连接起来以协同工作。其核心目标是提供一个清晰且美观的图形用户界面（GUI），使用户在进行非琐碎的多仓库变更时不会迷失方向。然而，拉取信息仅仅是故事的一半，真正的挑战在于执行变更。当在一个会话中涉及 10 个仓库时，意味着需要处理 10 个拉取请求（PR），并协调所有的持续集成（CI）流程。如果其中一个仓库的 CI 失败，系统必须智能判断故障根源。

"Polygraph treats all the CI as one vector... if module one fails within a polygraph session, it will figure out who fixes it."

Polygraph 将所有的 CI 视为一个整体向量。例如，当 UI 模块一和模块二同时运行 CI 时，如果模块一失败，系统会自动分析是模块一需要补丁，还是 UI 组件本身与模块一不兼容。这种机制允许用户将复杂的多仓库变更视为单个仓库的变更来处理，极大地简化了分布式开发的复杂性。

记忆机制：构建组织的“过目不忘”能力

Polygraph 的强大之处在于其能够修复所谓的“情景记忆缺失”。通过捕获用户的工作内容，无论涉及多少个仓库、拉取请求或智能体轨迹，系统都能捕捉用户的意图并建立关联。这意味着现在可以明确地说：你在一个仓库中的工作与另一个仓库中的工作存在联系。这种全链路的捕获使得任何会话、任何片段的工作都可以在任意机器上恢复，或从任何地方被引用。最终结果是，开发者拥有一个拥有“照相式记忆”的智能体助手。它理解仓库的编写方式、相互关系以及组合逻辑，并记住由每位开发者在每一个仓库中进行的每一次会话。这创造了一种截然不同的开发体验。

实战演示：单命令启动多仓库协作会话

为了展示这一能力，我们来看一个具体的操作案例。在一个仅包含三个仓库的演示环境中（后端、前端等），用户只需运行一条命令，从列表中选择需要修改的后端和前端仓库。假设需要进行一项既涉及 API 变更又影响前端显示的复杂任务，用户需要为会话命名并选择一个已安装智能体（如 Claude）。Polygraph 本身并非智能体，而是围绕智能体构建的元框架（Meta Harness），旨在增强其能力。一旦启动，用户即可像操作单个仓库一样与智能体交互。

"I could interact with it as if I was in a single repo, even though multiple repos are involved."

用户下达指令后，智能体会规划变更方案。尽管涉及多个仓库，但交互体验与单仓库无异。唯一的区别在于用户会获得一个包含所有相关拉取请求的 Polygraph 会话视图。该视图提供了概念性的工作描述，跨越了仓库边界，清晰列出了涉及的仓库、拉取请求及 CI 状态。更重要的是，所有智能体的日志都被捕获并保存，这对于后续恢复会话至关重要。

跨机器与智能体的无缝记忆共享

最引人入胜的功能在于会话的恢复与协作。假设用户 A 完成了部分后端变更，希望同事 B（拥有后端仓库权限）继续完成。用户 A 将会话发送给 B。B 在自己的机器上（可能使用不同的终端、操作系统甚至不同的智能体，如从 Claude 切换到 Cortex）恢复该会话。系统会在 B 的机器上重建完全相同的环境：相同的仓库、相同的 SHA（提交哈希）、相同的智能体配置。

"It's close to the transporter in Star Trek. Like a whole copy of my session is all of its state materialized on their machine so they can continue."

关键在于记忆共享。B 的智能体不仅拥有本地环境，还加载了从 A 的机器捕获的历史轨迹。因此，B 的后端仓库智能体拥有与 A 完全相同的状态和历史记录。即使使用不同的智能体和机器，整个会话的全局状态被“物质化”到 B 的机器上。这种机制类似于《星际迷航》中的传送器，使得协作变得无缝。此外，这也便于代码审查：当对 PR 有疑问时，审查者可以直接在自己的机器上恢复对方的会话，获取完全一致的功能状态和决策历史，而无需询问原作者。这种能力甚至允许在会话中途切换智能体（如从 Claude 切换到 Codex），因为所有决策和上下文都已通过轨迹被完整记录。

自动化生产环境 Bug 修复与上下文重建

在演示中，Victor Savkin 展示了一个极具代表性的场景：当生产环境出现 Bug 时，开发者无需提供详尽的技术细节，只需向 Agent 描述问题即可。例如，他仅输入“引用该会话并指出其基本已损坏”，随后让 Agent 自行诊断。Agent 会主动查找相关信息，如果高层描述不足，它会自动下载必要的依赖库、相关代码片段（shards）、Agent 日志等数据。这一过程的核心在于从原始会话中重构出当时的状态信息。通过这种机制，Agent 能够理解上下文并执行必要的修复操作。Savkin 强调，“我只需要说‘发生了这件事，有个 Bug’”，无需提供任何额外信息。这种自动化不仅节省了人工排查的时间，更确保了修复方案基于完整的上下文而非碎片化的线索。

“The agent will look it up, will download what it needs... It's going to get all this information from the original session to reconstruct that state such that it can do the necessary fixes.”

基于知识图谱的智能仓库检索与复用

除了手动选择代码库，Polygraph CLI 利用内置的知识图谱（Graph）智能理解仓库间的依赖关系。开发者可以通过自然语言指令让 Agent 自动执行复杂任务，例如“找到所有依赖于特定版本库的仓库并更新它们”。Agent 拥有大量关于代码关系的元数据，无需人工干预即可定位目标。此外，系统支持松散查询（loose questions），如“我想写一篇博客文章”或“想在 PR 集合中添加向量索引”。在这些场景下，Agent 会根据仓库间的关联性和内容相关性，自动筛选出最相关的会话或代码库。例如，在寻找向量索引的实现参考时，Agent 能发现多个相关会话。这种能力不仅提高了检索效率，还促进了最佳实践的一致性，避免每个开发者从零开始编写 bespoke（定制）代码。通过复用受尊敬工程师的已有实现，跨仓库的代码一致性得到了显著提升。系统还能根据当前所在的仓库优先推荐相关会话，反之亦然，形成双向的智能关联。

“I could tell my agent, 'Find every repo that depends on a particular version of a library and update it.' ... It knows a lot of metadata about what's going on.”

动态扩展上下文与打破时空限制的全局智能

Polygraph CLI 不仅是一个启动工具，它还能动态扩展 Agent 的上下文边界。Savkin 演示了在 Cloat 会话中，通过指令让 Agent 将外部开源仓库（如 Vitest）引入当前环境。Agent 随即可以深入探索该库的源码，从而解决内部仓库遇到的问题。相比仅依赖静态上下文窗口（如 Context 7），直接访问真实代码库能让 Agent 深入解决深层问题。从架构层面看，传统 AI Agent 受限于“空间”（仅见局部代码）和“时间”（无历史记忆）。Polygraph 打破了这些限制：Agent 可访问组织内所有有权使用的代码库（包括开源部分），不再受空间约束。同时，它提供了完美的记忆能力，“每个会话、每一个决策都触手可及”。这种机制跨越了开发者界限，使得 Agent 能拥有比任何单一工程师更丰富的上下文。Savkin 将其比喻为“蜂巢思维”（Hive Mind），成千上万工程师创建的会话对所有 Agent 开放，每个参与者的贡献都融入这个集体智能中。最后，Savkin 邀请观众访问 try.poligraph.com 体验这一工具。

“Polygraph gives agents access to the entire code your organization can reach... It gives you agent a perfect memory of what happened. ... Almost like sort of the Borg.”

结论

Polygraph通过构建统一依赖图和全链路记忆机制，有效解决了AI Agent在多仓库开发中面临的“空间局限”与“时间失忆”两大核心痛点。它使Agent能够跨越仓库边界获取全局上下文，并实现会话状态在不同机器、智能体间的无缝迁移与复用。这种“蜂巢思维”显著降低了跨仓库变更的重复解释成本，提升了协作效率与代码一致性。然而，该方案目前主要验证了元框架在协调复杂变更和恢复上下文方面的有效性，其实际性能表现、大规模生产环境下的稳定性以及与传统工作流的融合深度仍需更多实证数据支持。