现在的 AI Agent，正在从一个“会回答问题的聊天机器人”，变成一个会长期工作、长期学习、不断改变自己的系统。

它会记住用户偏好，会学习新的 Skill，会创建脚本，会安排定时任务，会安装插件，也会调整自己的工作方式。

这听起来是进步。

但一个新的问题也随之出现：

Agent 学到的东西越来越多以后，我们怎么知道它现在到底变成了什么样？

假设一个 Agent 在几周内做了这些事情：

  • 记住用户不喜欢频繁确认；
  • 学会了一套 GitHub PR Review 方法；
  • 写了一个自动检查 CI 的脚本；
  • 创建了一个每天检查 PR 的定时任务；
  • 修改了文件写入权限；
  • 后来又更新了那套 PR Review Skill。

这些东西可能分别存在不同地方：

Memory Skill Script 定时任务 权限配置 插件配置

问题是，它们并不是互相独立的。

定时任务可能依赖某个 Skill，Skill 又依赖某个 Script，Script 还需要特定权限。

一旦其中一部分被修改，另一部分没有同步更新，Agent 就可能进入一种“半升级”状态：

Memory 更新了 Skill 更新了 Script 写到一半失败了 定时任务没有更新

每个文件单独看可能都没有坏，但整个 Agent 已经不再是一个完整、一致的状态。

这就是长期运行 Agent 面临的一个核心问题：

Agent 会不断变化，但这些变化缺少统一管理

Git 真正解决的，不只是代码版本问题

很多人提到 Git，第一反应是程序员写代码时用的版本控制工具。

但 Git 更本质的价值，是解决下面这些问题：

  • 现在是什么状态；
  • 之前是什么状态；
  • 谁改了什么；
  • 为什么改；
  • 两个人同时修改怎么办；
  • 改坏了怎么恢复；
  • 能不能先试验，再决定是否正式使用。

这些问题以前出现在软件代码里。

现在，它们开始出现在 Agent 身上。

所以这里说的 Agent Native Git，并不是让 Agent 学会执行：

git add git commit

而是让 Agent 自己的长期状态，也拥有类似 Git 的管理能力。

也就是说：

Agent 每次学习、修改自己，都不应该只是直接覆盖原来的内容，而应该形成一次可以查看、审查和回退的变化记录。

今天的 Agent 为什么容易越用越乱

现在很多 Agent 都有 Memory。

但大多数 Memory 系统解决的只是：

怎么让 Agent 记住东西。

它们没有解决：

Agent 记住的东西互相冲突怎么办。

例如 Agent 可能先记住：

用户不喜欢每次都被询问。

后来又记住：

修改文件前要询问用户。

再后来某个 Skill 里又写着：

为了提高效率，常规修改无需确认。

这些信息单独看都有道理。

但它们放在一起，Agent 每次执行时都只能自己临时理解：

这一次到底要不要问？

时间越长，这类规则、记忆和例外越多，Agent 的行为就越不稳定。

这可以叫作：

Agent 状态熵。

简单说，就是 Agent 里面的东西越来越多，但它们之间的关系越来越不清楚。

传统 Memory 系统往往只是不断增加内容。

而真正需要的是：

  • 新内容是否覆盖旧内容；
  • 两条规则是否冲突；
  • 这条记忆来自哪里；
  • 它什么时候生效；
  • 它影响了哪些 Skill 和任务；
  • 出问题以后能不能恢复。

这已经不是单纯的“记忆”问题，而是版本管理问题。

Hermes 已经开始做这件事，但还没有完全统一

Nous Research 的 Hermes Agent 是一个很好的案例。

因为它已经开始解决很多类似 Git 的问题。

Hermes 的长期 Memory 主要保存在：

MEMORY.md USER.md

它在写入时会做：

  • 文件锁；
  • 原子写入；
  • 并发修改检查；
  • 异常内容检测；
  • 备份。

Session 启动时，Hermes 还会冻结一份 Memory 快照。

当前 Session 继续使用这份稳定状态，中途新写入的 Memory，要到下一个 Session 才真正进入系统提示词。

这说明 Hermes 已经意识到：

一个正在运行的 Agent，不能一边执行，一边不断改变自己的基础状态。

但 Hermes 的 Memory 目前主要解决的是：

  • 不要写坏；
  • 不要覆盖；
  • 不要丢数据。

它还没有完整解决：

  • Memory 的历史版本；
  • 任意时间点回滚；
  • 多个版本并行实验；
  • 不同 Agent 修改后的合并。

相关实现：

Hermes 的 Skill 系统已经更接近 Git

Hermes 的 Skill 系统走得更远。

Agent 可以：

  • 创建 Skill；
  • 编辑 Skill；
  • 局部修改 Skill；
  • 删除 Skill；
  • 添加脚本、模板和参考文件。

相关实现：

更重要的是，Hermes 有一套 Skill Ledger。

每一次 Skill 被修改，系统会记录：

  • 谁修改的；
  • 做了什么操作；
  • 修改前是什么；
  • 修改后是什么；
  • 修改依据是什么；
  • 修改发生在什么时候。

Skill 文件内容还会根据 SHA-256 保存成去重的内容块，并支持回滚。

相关实现：

这已经很像 Git：

HermesGit修改前内容上一个版本修改后内容新版本Ledger 记录Commit修改人AuthorEvidenceCommit 原因RollbackRevert

但它和真正的 Agent Native Git 仍然有一个关键区别。

Hermes 的设计是：

先修改 Skill 再尽量记录历史

即使 Ledger 记录失败，Skill 修改仍然可以成功。

所以它更像：

修改以后留一份备份和日志。

而真正的 Agent Native Git 应该是：

没有形成完整版本，就不能让修改正式生效。

这是两种完全不同的系统。

Agent Native Git 真正要解决什么

这套系统最核心的，不是“保存更多历史”。

而是把 Agent 每一次变化，变成一个完整的“升级包”。

例如 Agent 决定改进 GitHub PR Review。

这次升级可能包括：

修改一条 Memory 更新一个 Skill 新增一个 Script 创建一个定时任务 增加一项权限

在今天的系统里，这五项变化可能分别写入五个地方。

在 Agent Native Git 里，它们应该被视为一次完整变化：

GitHub PR Review 升级

只有五项全部验证成功，这次升级才正式生效。

否则，Agent 继续使用旧版本。

这可以理解为：

Agent 不再是“边学边直接改自己”，而是“先准备一个新版本，再决定是否启用”。

一套完整的 Agent Native Git 应该有四个关键能力

第一，Agent 每个时刻都应该有一个明确版本

例如：

Agent State: 81fd213

这个版本代表：

  • 当前 Memory；
  • 当前 Skills；
  • 当前定时任务；
  • 当前 Scripts；
  • 当前 Policies；
  • 当前 Plugins；
  • 当前权限配置。

这样，当用户说：

Agent 昨天还正常，今天怎么变奇怪了？

系统就可以比较：

昨天：7aa312 今天：81fd213

然后直接告诉用户：

新增了 2 条 Memory 修改了 1 个 Skill 创建了 1 个定时任务 增加了文件写入权限

今天很多 Agent 做不到这一点。

因为它们没有一个统一版本，只能分别检查不同数据库、文件和配置。

第二，Agent 的修改应该先成为候选版本

Agent 学到新东西以后，不应该立即进入正式运行状态。

更加安全的流程应该是：

Agent 提出修改 ↓ 生成候选版本 ↓ 运行检查和测试 ↓ 用户或系统审查 ↓ 正式启用

例如：

当前版本：A 候选版本：B

B 已经保存，但 Agent 仍然使用 A。

只有 B 通过检查后，才切换过去。

这样即使 Agent 的自我改进出了问题，也不会立刻影响正式工作。

第三，用户看到的应该是“Agent 改变了什么”

现在很多 AI 产品的 Memory 页面是一长串：

Memory 1 Memory 2 Memory 3 Memory 4

用户自己判断哪些该删。

这种方式不自然。

更好的体验应该像系统更新记录：

你的 Agent 本周发生了 6 项变化 Memory + 学会你偏好简洁回答 - 删除一个过时偏好 Skills ~ 改进 GitHub Review 流程 Automations + 新增每周项目复盘 Permissions - 移除一个不再使用的权限

用户可以：

查看原因 查看证据 接受 拒绝 恢复

用户管理的不是一堆零散 Memory。

而是：

Agent 的成长过程。

第四，Agent 的冲突需要被明确发现

有些冲突是文件冲突。

例如两个 Agent 同时修改同一个 Skill。

但更常见的是语义冲突。

例如：

规则 A：修改文件前必须询问。 规则 B：常规代码修改无需询问。

它们可能存在不同文件里，普通 Git 不会认为它们冲突。

但 Agent 执行时会出现不确定性。

所以 Agent Native Git 不能只比较文件的行变化。

它还需要判断：

  • 两条规则是否互相矛盾；
  • 新规则是否覆盖旧规则；
  • 一条规则是否只是另一条规则的例外；
  • 两条 Memory 是否其实是重复内容。

这部分可以由：

  • 结构化规则；
  • Schema；
  • 冲突检测程序；
  • 大模型；

共同完成。

但对于权限、支付、数据删除等高风险内容，不能只让模型自动决定，必须进入人工审查。

哪些东西应该进入 Agent 的版本库

不是所有 Agent 数据都应该保存进 Git。

可以分成三类。

第一类：真正决定 Agent 行为的内容

这些应该进入版本库：

Memory Skills Prompts Policies Scripts 定时任务 Workflow 工具配置 Plugin 清单 Subagent 定义

这些内容发生变化，Agent 的行为也会变化。

第二类：可以重新生成的数据

这些不需要进入版本库：

Embedding 向量索引 搜索索引 缓存 临时文件 运行日志 编译后的 Prompt

例如 Memory 是原始内容。

Embedding 只是由 Memory 计算出来的结果。

只要原始 Memory 还在，Embedding 就可以重新生成。

这和软件开发中：

源代码进 Git 编译结果不进 Git

是同一个道理。

第三类：密钥和敏感凭证

这些绝对不能进入 Git：

API Key OAuth Token 密码 私钥 Cookie

版本库里只能保存一个引用：

使用 github/default 这组凭证

真正的密钥放在系统 Keychain、Vault 或其他安全存储中。

技术上有没有必要重新发明 Git

大概率没有。

Git 底层已经成熟解决了很多最困难的问题：

  • 内容去重；
  • 完整快照；
  • 历史关系；
  • 分支；
  • 回滚；
  • 合并；
  • 数据校验；
  • 多设备同步。

所以更现实的方案是：

Agent State System ↓ Git Engine

底层继续使用 Git。

上层不让用户和 Agent 直接接触 Git 命令。

例如 Agent 不调用：

git commit

而调用：

保存一次 Agent 改进

用户也不会看到：

branch rebase cherry-pick detached HEAD

用户看到的是：

尝试一个新方案 应用改进 恢复之前行为 比较两个版本

Git 只是内部实现。

可以基于哪些现有开源实现

第一版甚至可以直接使用官方 Git。

通过命令行完成：

  • 创建快照；
  • 生成 Commit；
  • 比较版本；
  • 回滚；
  • 创建分支。

这样可以最快验证产品逻辑。

之后再根据系统语言选择嵌入式 Git 实现。

libgit2

成熟的可嵌入 Git 实现。

适合：

  • 桌面应用；
  • 服务端应用；
  • 需要多语言 Binding 的系统。

项目地址：

gix / gitoxide

Rust 原生 Git 实现。

适合：

  • 独立状态引擎；
  • 强调安全和并发的 Agent Runtime；
  • Rust Sidecar 或 Native Core。

项目地址：

Dulwich

纯 Python Git 实现。

适合：

  • Python Agent；
  • 快速原型；
  • 不希望依赖系统 Git 的场景。

项目地址：

go-git

Go 实现。

适合：

  • Go Agent Runtime；
  • 云端 Agent 服务；
  • 单文件部署。

项目地址：

JGit

Java 实现。

适合企业 Java 系统。

项目地址：

isomorphic-git

JavaScript 实现。

适合：

  • Node.js；
  • 浏览器；
  • 轻量 JavaScript 环境。

项目地址：

对于 Electron 或 TypeScript 产品，一个比较稳妥的架构可能是：

Electron / TypeScript ↓ Agent State Service ↓ Rust + gix

TypeScript 负责产品和交互。

Rust 服务负责：

  • 事务；
  • 版本；
  • 数据完整性；
  • 并发；
  • 回滚。

真正需要创新的不是 Git，而是 Git 上面的 Agent 语义

Git 本身只知道：

哪个文件变了

Agent 系统还需要知道：

为什么变 根据什么变 谁提出的 可信度多少 风险多大 是否经过测试 是否已经批准 什么时候正式生效

例如一次 Agent 修改，不应该只有一句：

Update memory

而应该包含：

原因： 用户明确表示希望回答更简洁 证据： 某次对话中的用户原话 影响： 修改沟通偏好 Memory 风险： 低 检查： 未发现与现有偏好冲突 生效： 下一个 Session

所以，Git 解决的是版本基础设施。

真正的新系统要解决的是：

Agent 为什么改变，以及这种改变是否应该被接受。

这件事真正的价值

今天很多 Agent 系统在不断增加：

  • Memory；
  • Skill；
  • Automation；
  • Plugin；
  • Subagent；
  • Self-improvement。

但它们越强，就越容易出现一个问题：

Agent 可以改变自己，却没有一套成熟的方法管理这种改变。

Hermes 已经开始分别补上：

  • Memory 的原子写入；
  • Skill 的来源追踪；
  • Skill 的内容备份；
  • Skill 的回滚；
  • Learning Graph；
  • Self-Evolution 的评估和 PR Review。

相关实现：

这些机制共同说明了一件事：

当 Agent 开始长期运行并修改自己以后，它会自然重新遇到软件工程里的版本控制问题。

Agent Native Git 的价值，就是把这些零散能力统一起来。

它最终要把 Agent 的变化过程，从：

直接修改

变成：

提出修改 生成候选版本 检查 审查 正式启用

这样，Agent 才能真正做到：

  • 可观察；
  • 可解释；
  • 可审查；
  • 可回滚；
  • 可复现；
  • 可安全地自我改进。

结语

模型让 Agent 会思考。

工具让 Agent 会行动。

而版本化状态系统，才让 Agent 能够可靠地成长。

没有版本控制的 Self-Improving Agent，本质上是在直接修改 Production。

Agent Native Git 真正要做的，并不是给 Agent 增加一个 Git 工具，而是把 Agent 的学习和变化，从不可见的内部过程，变成一个可以检查、验证、审查和恢复的工程过程。