导语
Agent 时代有一个反直觉变化：代码越来越便宜，理解代码却越来越贵。

以前一次 commit 大致能代表一次开发工作。人读需求、改代码、跑测试、提交 PR。reviewer 看 diff，基本能还原这次变更的主要逻辑。

AI Coding 把这个前提打碎了。

一个人可以同时开多个 Agent，一个 Agent 也可能继续调别的 Agent。代码生成速度上去了，同一个需求甚至会在短时间里出现多个实现版本。最终留下来的还是 diff，但 diff 背后的东西丢了：最初的 prompt 是什么，Agent 看了哪些文件，试过哪些方案，哪些测试失败过，为什么最后选了这个方向。

当代码只是副产品，真正的工程资产就变成了生成这段代码的​上下文​。
inline-01-session-asset.png

图：代码之外，真正需要被保存的是生成代码的上下文

Git 只回答改了什么，不回答为什么
过去的软件基础设施，几乎都围绕代码产物建设：

repo 管代码状态
PR 管审查流程
CI 管构建和测试
CD 管发布和回滚
这些基础设施对人类开发者很有效，因为人的思考过程大多留在会议、评论、文档和经验里。diff 已经足够代表大部分工作。

但 Agent 写代码时，过程本身变得更重要。

如果只记录最终 ​diff​，后续会遇到几个问题：

场景 只看 diff 的问题 需要补上的信息
Code Review 看得到代码改动，看不到原始意图和约束 prompt、任务目标、Agent 推理路径
交接 新会话不知道前一个 Agent 试过什么 session 摘要、失败尝试、下一步
回归排查 git blame 只能找到 commit 当时为什么这样改、哪些测试支撑它
二次开发 Agent 可能重复旧错误 历史反馈、被否决方案、review 意见
AI 生成代码越多，这个问题越严重。因为 reviewer 审的不是“哪一行是不是 AI 写的”，而是“这次变更是否符合原始意图，以及 Agent 有没有走错路”。

行级归因不够，意图归档更关键
社区已经意识到 AI 代码需要新的归属协议。Agent Trace 这类规范尝试在文件或行粒度标注代码来自 human、ai、mixed 还是 unknown。

这个方向有意义。它让团队知道哪些代码由 AI 参与生成，也能为审计和统计提供基础。

但行级归因解决的是 attribution，也就是谁写了哪行代码。它没有解决更关键的问题：​为什么这样写​。

对于 Agent-first 的软件工程，知道“这行来自 Claude”并不够。另一个 Agent 接手时，它真正需要的是：

当时的任务目标是什么
哪些上下文被读过
哪些方案被尝试过
哪些测试失败过
reviewer 提过什么约束
最终实现为什么被接受
这不是给代码贴身份证，而是给一次变更保留开发记忆。

抽象：把 session 变成 Checkpoint
我们要补的，就是 Git 缺失的那一层。

它不是新的 AI 编码工具，也不是替代 Claude Code、Cursor、Codex 或 OpenCode。它更像一个 Git 感知的记录系统：当 Agent 辅助完成一次变更并提交 commit 时，应该把本次会话上下文归档成 Checkpoint，并和 commit 绑定起来。

一个 Checkpoint 可以包含：

Checkpoint
├── user prompt / task instruction
├── agent transcript
├── tool calls
├── files read / files modified
├── command execution
├── token usage
├── diff summary
├── test and error signals
└── linked commit
这里的关键不是复制 Git。

Git 记录代码状态，Checkpoint 记录代码状态背后的生成过程。

为什么要和 commit 绑定
Agent session 如果只存在聊天工具里，很快会散掉。换设备、换 IDE、换模型、换人接手，历史上下文就断了。

和 commit 绑定后，软件工程的基本追溯链路就能继续成立：mermaid-01.png

图：Agent Session 被采集为 Checkpoint，并绑定到 Git Commit

这样做有三个好处。

第一，review 不再只看结果。reviewer 可以看到 Agent 当时的任务理解、读取范围、工具调用和失败路径，判断它是不是在正确约束下完成的。

第二，交接不再靠复述。一个 Agent 干到一半，另一个 Agent 可以读取历史 session，知道已经试过什么、卡在哪里、下一步该做什么。

第三，知识能沉淀。团队反复处理过的失败、修复、review 意见和工程习惯，可以反过来提炼成 ​skill、checker 或工作流​。
inline-02-review-handoff.png

图：Checkpoint 让 review、交接和知识复用回到同一条链路

低侵入是基础，不然一定会被绕开
这类系统要成立，前提是不能改变开发者已有习惯。

开发者不应该为了记录 Agent 历史，再去打开一个新平台、手动填写一次任务说明、手动上传一次日志。AI Coding 工具已经足够多了，任何额外流程都会被绕开。

更好的形态是 ​CLI-first、local-first、Git-first​。

设计原则 含义 价值
CLI-first 通过 CLI、git hooks、agent hooks 静默工作 不重造 IDE，不打断开发流程
Local-first 采集和检索优先在本地完成 可离线、低侵入、便于审计
Git as database Checkpoint 作为 Git 可版本化对象保存 数据跟随 repo 和 branch 流动
这也是这类系统最有意思的地方：它不是在软件工程之外另建一个“AI 历史库”，而是把 Agent 产生的上下文放回 Git 这条主链路里。

成本问题反而没那么大
很多人第一反应会担心存储成本。Agent transcript 这么多，每次 commit 都记录，会不会很贵？

如果采用 Git object 存储，成本其实比直觉低。

一次中等复杂度的 session 可能有几十轮对话，原始文本几百 KB。Git 对文本压缩效果很好，写入 object 后可能只有几十到一百多 KB。

哪怕一个 50 人团队每天产生 250 个 checkpoint，按每个 100KB 估算，一天约 25MB，一个月不到 1GB。相比研发资产本身，这个成本不算高。

真正需要治理的不是存储，而是​隐私、权限、保留周期和可检索性​。
inline-03-local-first.png