当 Agent 开始用 Git 说话：从一个 Vibe Coding 开发者的发现，到 Agent 协作的未来。
一、一个意外的发现
最近在维护自己的开源项目时，我做了一件很自然的事：让 Agent 帮我处理 GitHub 上的 Issues 和 Pull Requests (PR)。
一开始只是为了省事——Issue 数量太多，让 Agent 帮忙阅读、分类、回复一些常见问题。PR 也是，先让 Agent 做一轮 Code Review，帮我过滤掉明显有问题的提交。
但很快，我发现了一件有趣的事情：给我提 Issue 的，很多也是 Agent；给我提 PR 的，同样是 Agent。
我的 Agent 在和别人的 Agent 对话。
它们用 Issue 的格式交换需求，用 PR 的格式交换代码，用评论（Comment）的格式讨论技术方案。没有人刻意设计过这套流程，但它就这么自然而然地发生了。
那一刻我意识到——GitHub 正在无声无息地演变为一种 Agent 之间的通讯协议。
仔细想想，这并非意料之外。GitHub 天然具备 Agent 通讯协议所需的一切特性：
- 可读且安全：纯文本交互，所有操作透明、可审计。
- 命令式的：Issue 是任务指令，PR 是执行结果。
- 结构化的：标签、模板、状态流转，天然适合机器解析。
- 有版本控制：每一次交互都被完整记录，不会丢失。
Agent 并不需要什么全新的复杂协议，它们已经在利用人类建造的最成熟、最普及的协作基础设施来进行沟通了。
二、巧合还是必然？
就在我和朋友聊完这个观察的第二天，一条新闻映入眼帘：GitHub 前 CEO Thomas Dohmke 宣布创立新公司 Entire，并获得了 6000 万美元的种子轮融资，目标是在 Git 之上构建 Agent 时代的开发者平台。
有时候，你模糊感知到的趋势，会突然被行业里最懂这件事的人用一家公司、一笔巨额融资、一个明确的产品方向所确认——这种感觉非常奇妙。
Thomas Dohmke 在公告中的一句话，与我的感受完全共鸣：
“我们仍然依赖一个在云时代之前构建的软件开发生命周期，它天生是为人与人协作设计的。”
他看到的问题和我看到的一样：现有的 Git/GitHub 体系是为人类协作设计的，Agent 只是在“将就着用”。 能用，但不够高效、不够原生。
三、Entire 是什么，它比 Git 走到了哪一步？
3.1 Git 记录了什么，遗漏了什么
首先回顾现有的 Git 体系。Git 是一个极其优秀的分布式版本控制系统，它忠实地记录了：
- What：哪些文件发生了变更，每一行的具体差异（diff）。
- Who：是谁提交了这次更改。
- When：更改是在什么时间发生的。
- Where：更改发生在哪个分支上。
但它有一个致命的缺失：Why——为什么要进行这样的修改。
在人类手写代码的时代，这个“为什么”或许能勉强通过提交信息（commit message）和 PR 描述来补充（尽管很多人写的只是 fix bug）。但在 Agent 时代，这个缺失被放大了一百倍——
Agent 生成了 500 行代码，你只能看到 diff，完全不了解它背后的推理链条。Agent 做了一个架构决策，选择了方案 A 而放弃了方案 B，你不知道它权衡了哪些因素。你给 Agent 的指令（prompt）、附加的约束条件、以及讨论的过程，在关闭终端或对话窗口的那一刻，可能就全部消失了。
Git 保存了代码“怎么变”，但丢失了代码“为什么这么变”的认知过程。
3.2 Entire 的 Checkpoint：给 Git 补上 “Why”
Entire 发布的第一个产品叫做 Checkpoint。它的做法非常聪明——不直接修改 Git 的核心，而是在 Git 之上增加一层语义元数据。
当你使用 Agent 生成代码并执行 commit 时，Checkpoint 会自动捕获并与这个 commit 的 SHA 哈希值绑定：
普通 Git Commit：
commit abc123 → diff（代码变更）
Entire Checkpoint：
commit abc123 → diff（代码变更）
+ 原始 prompt（你给 Agent 的指令）
+ 推理链（Agent 考虑了哪些方案、放弃了什么）
+ 工具调用（Agent 读取了哪些文件、调用了哪些 API）
+ 约束条件（必须兼容什么、禁止使用什么）
+ token 消耗（花费了多少计算资源/成本）
+ 完整对话记录（整个 session 的完整文本记录）
这些元数据存储在一个独立的 Git 分支（例如 entire/checkpoints/v1）上，以仅追加（append-only）的方式累积。代码仓库本身不受任何影响，完全兼容现有所有的 Git 工作流和工具链。
本质上，Checkpoint 把 Agent 的“想法”从黑箱变成了白箱——变得可追溯、可审查、可在不同 Agent 间共享。
3.3 为什么这件事比“存聊天记录”重要得多
你可能会想：这不就是把 AI 的聊天记录存到了 Git 里吗？
不，区别在于它是 结构化的、版本化的、并且紧密绑定到每一次具体的代码变更。这意味着：
- 代码审查的范式即将改变。 过去你打开一个 PR，面对数千行的 diff，需要逐行阅读代码。现在，你可以先查看与之关联的 Checkpoint——了解 Agent 接到的原始意图是什么、它考虑了哪些备选方案、最终为什么选择了当前的实现。你审查的不再仅仅是“代码语法对不对”，而是“整个思维过程合不合理”。
- Agent 之间有了共享的认知和记忆。 Agent A 在一个 session 中完成了技术选型，session 结束后其工作上下文便消失了。当 Agent B 接手相关任务时，可以直接读取 Agent A 留下的 Checkpoint，继承之前的决策逻辑和约束条件，无需从零开始重新推理。
- 技术决策历史变得可追溯。 三个月后，如果有人提问“为什么当时选择了 SQLite 而不是 PostgreSQL？”，你不再需要依赖模糊的个人记忆，可以直接查询那次 commit 对应的 Checkpoint，当初完整的讨论记录和推理依据都赫然在列。
四、新范式：从“写代码的工人”到“审查 Agent 思维的监督者”
Entire 和 Checkpoint 所指向的，其实是一个更深层次的软件开发范式转变。
旧范式
开发者写代码 → commit → 发起 PR → 同事审查 diff → 讨论 → merge
在这个流程里，代码是核心产物，人的注意力高度集中在“这段代码写得对不对、好不好”上。
新范式
表达意图 → Agent 生成 → Checkpoint 记录推理 → 审查意图和结果 → 验证正确性
流程中的每一步都发生了质变：
- 表达意图——开发者的第一步不再是打开代码编辑器，而是用自然语言精确描述“我要实现什么功能”。例如：“我需要一个 JWT 认证中间件，支持 refresh token 机制，Access Token 过期时间设为 15 分钟，并且必须兼容项目现有的路由结构。” 意图描述本身，正在成为一种新的、重要的工程产物。
- Agent 生成——Agent 接收到意图后，会读取项目结构、分析现有代码库、权衡多种实现方案、做出选择、最后生成代码。这个过程消耗了大量计算资源和复杂的推理链，但在过去，这些宝贵的中间过程全部是“瞬态”的，commit 之后只剩下冰冷的代码差异（diff）。
- Checkpoint 记录推理——现在，这些完整的推理过程被自动捕获并永久保存。你不再需要“有意识地”去手动记录，不需要额外维护复杂的规则文件或技术决策文档。Agent 每次执行 commit 时，Checkpoint 都会在后台自动完成记录。
- 审查意图和结果——你的审查重点不再是一行行地看代码。你审视的是：最初的意图描述是否准确清晰？Agent 做出的决策是否合理？所有给定的约束条件是否都得到了满足？有没有忽略什么关键的边界情况？你审查的是 Agent 的认知过程，而不仅仅是它产出的每一个分号或括号。
- 验证正确性——正确性的验证方式也在进化。Agent 可以同时生成功能代码和对应的单元测试；另一个专门的“审计”Agent 可以读取 Checkpoint，检查推理链是否逻辑自洽；甚至可以通过业务指标来自动验证最终结果是否符合预期。
一句话总结这个范式转变：开发者的核心角色，正在从“亲手写代码的工人”演变为“审查与指导 Agent 思维过程的监督者”。
五、对 Agent 时代更广泛的意义
将 Entire 的愿景放到更大的技术背景中审视，它的意义远超一个单纯的开发效率工具。
5.1 Agent 的世界需要自己的“互联网”
在旧世界里，HTTP 协议是人们访问网站、交换信息的基石，构成了我们熟知的互联网。在新世界里，海量的 AI Agent 也需要自己专属的高效协作协议。
我在开源项目维护中观察到的现象——Agent 通过 Issues 和 PR 进行交流——是一种 隐式的、低带宽的通讯。它只传递了代码和自然语言评论。Entire 想要做的，正是将这种通讯 显式化、高带宽化：不仅要传递代码，还要传递完整的推理过程、上下文图谱和决策依据。
这或许也是为什么 Thomas Dohmke 强调要将其开源，并着重宣传“开放、可扩展、独立”。他不仅仅是在打造一个商业产品，更是在试图推动一个面向未来的、开放的协议标准。
5.2 从 2C、2B 到 2A (To Agent)
最近看到一篇题为《互联网已死，Agent 永生》的文章，里面提出了一个非常精辟的观点：过去的软件主要服务于人类消费者（2C）或企业（2B），而未来最大、最活跃的软件用户群体，可能就是 Agent 本身（2A）。
如果 Agent 成为软件的新“用户”，那么 Agent 之间如何高效、可靠地协作，就成了最关键的基础设施问题。Entire 的 Checkpoint 本质上就是在解决如何让 Agent 之间的协作“体验更好”——不是给人看的华丽用户界面，而是给 Agent “阅读”的、高度结构化的推理数据。
5.3 “韩信点兵”需要现代化的指挥体系
上文提到的文章中还引用了一个绝妙的比喻：韩信点兵，多多益善——并非因为韩信本人武力超群，而是因为他拥有一套高效、严密的指挥体系。
未来，人与人之间能力的差距，很可能将取决于你能有效地驱动多少个 Agent 协同工作。然而，驱动 1 个 Agent 和驱动 100 个 Agent 的复杂度绝非线性增长。没有一套协调体系，100 个 Agent 将陷入一片混乱——各自为战、重复推理、产出互相冲突。
Entire 规划的三层架构（Git 兼容的数据库层、语义推理层、AI 原生开发生命周期层），恰恰对应着这套现代化的“指挥体系”：统一的信息存储中心、共享的态势感知能力、以及清晰的任务协作流程。
六、它解决了我的哪些痛点，又有哪些挑战尚存？
6.1 已解决的：告别“人肉 Checkpoint”
作为一个重度依赖“Vibe Coding”（即通过自然语言与 AI 协同编程）的开发者，我之前最痛的问题是：AI 在上下文窗口被压缩或重置后，会“忘记”之前讨论过的所有东西。
我不得不频繁地通过创建和维护规则文件（比如 CLAUDE.md、cursor rules）来手动保存 Agent 做出的技术选型、架构决策和各种约束条件。这些记录是为了在项目后期重构或进行重大迭代时提供关键参考。但这个操作完全依赖于我的“主观能动性”——而我经常忘记去做。
Checkpoint 直接且彻底地解决了这个问题——你不再需要手动记录任何东西。 每次与 Agent 的对话、每一个技术决策、每一条推理链条，都会自动绑定到对应的代码提交上，成为项目历史中不可分割的永久组成部分。
另一个直接受益的场景是处理 Issue 和 PR。过去，当有人提 Issue 询问“为什么项目不支持 XXX 功能？”时，我需要努力回忆甚至重新调研。现在，我可以直接查询 Checkpoint 历史，找到当初讨论过该功能的那次开发会话，直接引用当时的完整推理过程来回复——有理有据，不依赖于模糊的个人记忆。
6.2 已解决的：多 Agent 协作有了共享认知基础
我当前的工作流已经相当复杂：使用 Git worktree 管理多个功能分支，在每个 worktree 下启动不同的 Agent “团队”去完成特定任务，然后我来审查它们的产出，决定采用哪个方案。
这个过程曾非常痛苦。六个 Agent 团队可能产出数千行代码，我需要在不同方案之间进行比较，还要手动进行集成测试。Checkpoint 至少让方案比较变得容易多了——我不再需要逐行对比晦涩的 diff，而是可以直接阅读不同方案所附带的“推理摘要”和“决策依据”，往往能在 5 分钟内做出更明智的判断。
6.3 尚未解决的：上下文爆炸与精准检索问题
但我直觉上感到，Checkpoint 能解决“存储”问题，却未必能彻底解决 Agent 间的“高效沟通”问题。原因很直接：
模型本身的上下文窗口是有限的。
当你把每次 commit 的完整推理链（可能包含数千至上万 tokens）都保存下来，一个持续开发三个月的项目，可能会累积高达 1000 万 tokens 的 Checkpoint 数据。而目前最顶尖大模型的上下文窗口也不过 20 万 tokens 左右。数据是存下来了，但没有任何一个 Agent 能一次性“看完”。
更关键的是，Checkpoint 机制本身可能会反过来更快地“塞爆”Agent 的可用上下文。 它解决了“信息不丢失”的存储问题，但随即引入了“如何精准检索”的挑战——Agent 怎样才能从海量的 500 个历史 Checkpoint 中，精准定位到当前任务最需要参考的那 2-3 个？又该如何将海量的历史推理，压缩成能够放入有限上下文窗口内的有效摘要信息？
6.4 尚未解决的：从事后记录到实时协调
Checkpoint 本质上是 “事后记录” ——Agent 完成任务、执行 commit 之后，才生成并保存一份 Checkpoint。但在真正的多 Agent 实时协作场景中，我们需要的不仅是事后查阅记录，更需要 工作过程中的实时通讯与状态同步。
例如，Agent Team 1 在开发进行到一半时，决定数据访问层采用 Drizzle ORM——这个关键决策应该实时同步给正在并行开发相关模块的 Team 2 和 Team 3。而不是等到 Team 1 完成整个功能并 commit 后，Team 2 才从 Checkpoint 中读到这个信息，然后发现自己已经实现的部分与之不兼容，导致返工。
这已经超出了 Checkpoint “记录”的范畴，进入了 Agent 间“实时通讯协议”与“协同状态管理”的领域。
6.5 Entire 的完整蓝图如何应对这些挑战？
回到 Entire 公司的完整愿景，Checkpoint 仅仅是其三层架构中的第一块基石。它的整体规划恰好对应了上述待解决的挑战：
| 层次 |
核心解决什么问题 |
状态 |
| Checkpoint（存储层） |
信息不再丢失——永久保存推理过程 |
✅ 已发布 |
| Context Graph（语义推理层） |
从海量 Checkpoint 中精准检索——智能关联与摘要 |
🔜 待发布 |
| AI 原生开发生命周期 |
Agent 间的实时协调与工作流——定义协作协议与流程 |
🔜 待发布 |
其中的 Context Graph（上下文图谱） 可能是承上启下最关键的一层。它需要实现的功能是：不是简单粗暴地将所有历史 Checkpoint 都塞给正在工作的 Agent，而是能根据当前任务的语义，智能检索出最相关的历史上下文，并进行分层级的压缩——可能是完整记录、可能是决策摘要、也可能是关键约束列表，在不同场景下提供不同粒度的信息。
就像人类的记忆系统并非事无巨细地存储所有经历——它拥有遗忘曲线、会进行抽象总结、能够按需回忆。Agent 的 Checkpoint 系统，同样需要类似的智能检索与信息压缩机制。
七、结语
让我们回到最初的起点：在维护开源项目时，我观察到 Agent 已经在利用 GitHub 进行互相沟通。这件事正在全球范围内自然发生，无需任何人的许可或设计。
Entire 所做的，是将这种自然生长的、隐性的 Agent 通讯，转变为显性的、高带宽的、专为 Agent 时代设计的基础设施。
Checkpoint 是坚实的第一步——它将 Agent 的思维过程从黑箱变为白箱，使其可追溯、可审查。而接下来的 Context Graph 与 AI 原生开发生命周期，才是真正实现 Agent 间高效、智能协作的关键。
然而，最深刻的变化或许并不在工具层面，而在我们自身的角色定位：
我们正在从“写代码的工人”转变为“审查与指导 Agent 思维过程的监督者”。
未来的开发者，可能不需要理解每一行代码的具体语法，但必须深刻理解 Agent 的推理是否合乎逻辑、其决策是否正确、有没有遗漏任何关键的业务或技术约束。这是一种全新的核心能力，也伴随着全新的责任。
旧世界的开发者用键盘和逻辑编写代码。新世界的开发者，将用清晰的意图描述和专业的判断力来“指挥”智能体军团。
而像 Entire 这样的下一代基础设施，正是让这种大规模、高效率“指挥”成为可能的现代化“指挥系统”。
地基已经打下，让我们共同期待，其上将建立起怎样令人惊叹的智能协作生态。
引用：
发表于 2026-2-12 11:21:06
|
查看: 30|
回复: 0
