超越提示词：为 AI Agent 引入版本控制

与 AI Agent 交互的当前工作流往往给人一种“凭运气”的感觉。你提供一个提示词，Agent 执行一系列更改，突然间一个文件夹消失了，或者一个关键函数被重写了。当你问“你为什么要这样做？”或“这次更改是什么时候发生的？”时，Agent 往往难以提供精确的回答，因为它缺乏对其自身演进路径的结构化记忆。

这正是 re_gent 旨在填补的空白。通过为 AI Agent 引入专门的版本控制系统 (VCS)，该项目寻求将 git 的严谨性——二分查找 (bisecting)、回退 (rewinding) 和审计 (auditing)——引入到非确定性的 Agent 执行世界中。目前支持 Claude Code，re_gent 试图将 Agent 行为背后的“意图”形式化，允许开发者将 Agent 会话视为一系列可追溯、可逆的提交 (commits)。

问题所在：Agent 会话的“黑盒”

大多数开发者将 AI Agent 作为高速实现引擎使用。然而，随着会话复杂度的增加，几个痛点也随之浮现：

缺乏溯源性： 在漫长的会话中，很难准确指出特定的逻辑更改是在何时引入的。
“撤销”之难： 虽然一些 IDE 提供基础的撤销功能，但要撤销跨多个文件的、由 Agent 驱动的复杂更改集，通常需要人工干预或完全重启会话。
缺失意图： 标准的 git 提交记录了 what（更改了什么），但它们并不总能捕捉到在特定提示词-响应周期内 Agent 内部推理过程中的 why（为什么更改）。

辩论：专用 VCS 与标准 Git

“为 Agent 提供 Git”的引入在开发者社区引发了重大辩论，主要集中在：当 Agent 已经精通标准 Git 时，是否有必要使用专门的工具。

支持标准 Git 的观点

许多批评者认为，Agent 已经拥有关于如何使用 Git 的数十年训练数据。从这个角度来看，专门的 VCS 是多余的。一些人建议，问题不在于缺乏工具，而在于缺乏合适的工作流。例如，一些开发者使用“Agent 钩子 (agent hooks)”——通过自动化脚本触发 git add . 和 git commit 并附带工具使用说明——来维护更改历史。

“我认为 git 更像是一种针对 AI 垃圾内容的防御和质量控制手段，而不是应该被自动化的东西。”

这种情绪凸显了一种关键的紧张关系：对自动化的渴望与对人工监督的需求。许多开发者更倾向于在将 Agent 的更改提交到永久历史记录之前进行手动审查，以避免“AI 垃圾内容”污染代码库。

支持专用层的观点

专用 Agent VCS 的支持者认为，Agent 交互的粒度与人类开发不同。一次人类的提交可能代表一个已完成的功能，但 Agent 可能需要十次迭代式的提示词来达到同样的状态。

将每一次提示词-响应周期作为“微提交 (micro-commit)”进行跟踪，可以实现一种粒度，这种粒度在主项目历史记录中会显得杂乱，但对于调试 Agent 的推理过程却非常有价值。正如一位贡献者所指出的，像 Jujutsu (jj) 这样的工具已经提供了自动提交功能，使得在不弄乱最终分支历史的情况下比较提示词之间的 diff 变得更加容易。

Agent 可审计性的替代方案

围绕 re_gent 的讨论催生了几种管理 Agent 状态和意图的替代策略：

计划驱动实现： 与其采用直接的“提示词 $\rightarrow$ 实现”流程，一些人建议采用“提示词 $\rightarrow$ 计划 $\rightarrow$ 实现”阶段。通过在代码旁边提交一份具体的计划文件，将“为什么”作为仓库的一等公民进行记录。
基于内容寻址的存储： 一些新兴工具正转向基于 DAG (有向无环图) 的提交历史和 CRDT (无冲突复制数据类型) ，以允许 Agent 在团队间进行协作并进行点对点历史同步。
会话索引： 与其使用 VCS，一些开发者依赖于对会话日志进行索引（例如，在 ~/.codex/sessions 中），允许 Agent 搜索自己的历史记录以查找之前的对话或决策。

结论：迈向 Agent 管理治理

无论是使用像 re_gent 这样的独立工具，还是与现有 Git 工作流进行更紧密的集成，亦或是转向基于计划的开发，共识是清晰的：随着 Agent 从简单的聊天界面转向自主贡献者，对可审计性的需求变得至关重要。从“黑盒”执行到透明、版本化的历史记录的转变，不仅是一种便利——它是 AI Agent 在专业生产环境中规模化应用的必要条件。