---
title: "Agent 为什么越学越不稳定？它需要一套 Git 状态控制 | 行开心的颠倒世界"
description: "给 Agent 加上 Auto-Memory 和自适应 Skill 之后，为什么它的行为越来越不可控？当记忆、技能、脚本与定时任务产生规则冲突，我们需要一套管理 Agent 自身状态的版本控制系统。"
canonical: "https://xingkaixin.me/posts/agent-needs-git/"
language: "zh-CN"
---

# Agent 为什么越学越不稳定？它需要一套 Git 状态控制

给 Agent 加上 Auto-Memory 和自适应 Skill 之后，为什么它的行为越来越不可控？当记忆、技能、脚本与定时任务产生规则冲突，我们需要一套管理 Agent 自身状态的版本控制系统。

2026年9月17日·1,368 字·4 分钟

[Agent](https://xingkaixin.me/tags/Agent/)Git[工程实践](https://xingkaixin.me/tags/%E5%B7%A5%E7%A8%8B%E5%AE%9E%E8%B7%B5/)

![Agent 为什么越学越不稳定？它需要一套 Git 状态控制](https://xingkaixin.me/cover/agent-needs-git.webp)

这两天把一个长期跑在后台的 Coding Agent 停掉了。

刚给它配上自动记忆（Auto-Memory）和自演化技能的时候，它确实表现得很聪明：记住了我偏好的目录结构，学会了按团队规范给 PR 打标签，还会根据报错经历自己写辅助脚本。

但跑了三周之后，它的行为开始飘忽不定。

提一个两行的小改动，它会突然弹窗三次反复确认；涉及核心数据库迁移时，它却一言不发直接把代码推上了分支。

翻开它的配置目录，里面已经乱成一团：

-   `MEMORY.md` 里记着上周的偏好：“用户不喜欢被频繁打扰，常规修改自动通过”；
-   某个 Review Skill 文件里写着前天的指令：“修改文件前必须向用户确认风险”；
-   另外还有一个自动生成的检查脚本，里面硬编码了一个过期的权限参数。

这几个文件单独看都没写错，但拼在一起喂给模型时，模型每一步都在规则冲突里艰难平衡。你查不出它现在的状态到底是从哪一轮修改开始崩坏的。

只做追加的记忆系统不仅不会持续进化，反而会迅速累积出严重的**状态失谐**。

## 无序追加记忆必然引发规则互斥

很多 Agent 框架对长期记忆的理解还停留在“记事本”阶段。

每次对话结束，后台起一个 Summarizer 往 `MEMORY.md` 追加几条用户偏好。用户今天说“多写注释”，它加一条；明天说“注释太啰嗦全删掉”，它又加一条。

时间一长，模型上下文里就会堆满互相矛盾的断言：既要求“遇到复杂逻辑补充行内注释”，又要求“保持代码精简禁止多行注释”。多条互斥规则放在同一个 Prompt 里，Agent 只能靠模型临场随机猜。

更棘手的是，现代 Agent 的状态从来不是一段纯文本。一个严肃参与工程的 Agent，其状态包含长期事实、工作流规约、自建辅助脚本与权限配置。

当 Agent 尝试自我进化去改进某项能力时，它可能更新了 Skill，写了一半脚本，修改了权限，但定时任务中断了。

此时 Agent 就会进入一种“半升级状态”：没有一个文件是损坏的，但整个系统已经彻底失谐。

## 状态管理需要版本控制纪律

在软件工程里，管理复杂系统状态早有成熟范式：

一组关联文件的修改需要**原子提交**，要么全部生效，要么全部不生效；运行中的任务需要**快照隔离**，不受中途写入的干扰；两条互斥规则必须在提交前被显式检测并仲裁；一旦新配置表现劣化，系统必须能精准回滚。

一个长期运行的 Agent，对自身状态的每一次修改都应当是一次严谨的版本演进，绝不能直接在原文件上做黑盒覆写。

目前一些前沿框架已经开始尝试会话快照隔离：当 Session 启动时冻结当前时刻的记忆快照，会话中途产生的新记忆排队进入下一个周期，保证单次会话的认知底座稳定。

但这依然不够。真正的状态管理，必须把校验做在生效之前。

![原子提交经过冲突检查，失败时回滚到稳定状态](https://xingkaixin.me/posts/images/agent-needs-git/agent-needs-git-01.webp)

## 可靠 Agent 的三套版本机制

把版本控制思想引入 Agent 自我演化，系统需要守住三套机制：

### 1\. 跨维度的原子升级包

当 Agent 决定更新某项业务能力时，涉及的 Memory、Skill、辅助脚本与权限必须被打包进同一个原子提交：

```
Commit 3a7f9c2: upgrade(pr-review): switch to AST-based diff analysis
- memory: update reviewer preference
- skills/review.md: add ast-check step
- scripts/parse-ast.py: create helper
- permissions.json: grant exec for parse-ast.py
```

只有当改动全部通过语法检查与沙箱验证后，变更才会合入主干对后续任务生效。任何一步失败，整批修改立刻回滚。

### 2\. 规则冲突的提交前检测

规则冲突的仲裁权绝不能推给模型的推理阶段。

在 Agent 尝试写入新规则或修改 Skill 时，Harness 应当调用冲突检测器，检查新指令是否与现有库里的规则存在直接互斥。

如果发现冲突，系统必须显式发出告警，在提交时附带消解动作（例如显式废弃旧规则），而不是把矛盾的指令同时塞进上下文。

### 3\. 分支实验与能力回滚

引入全新工作流时，不需要直接在生产环境冒险。可以给 Agent 的状态拉一个独立分支：

```
agent checkout -b experimental-refactor-v2
```

让它在分支状态下独立跑 10 个测试 Issue。如果任务成功率提升，再把这套状态合并回主干；如果表现异常，一行命令就能回退到昨天的稳定状态。

* * *

AI Agent 正在从一次性对话框演变为长期驻留的工程工具。

系统不仅要学习新规则，更需要维持状态自洽。如果每一次交互只是在配置目录里无序追加，最终只会堆积成无法维护的死结。

**给 Agent 堆积记忆只是第一步；用版本控制的工程纪律去管理状态演进，才是它长期可靠运转的底座。**

## 版权声明

作者

XingKaiXin

标题

Agent 为什么越学越不稳定？它需要一套 Git 状态控制

发布时间

2026年9月17日

文章链接

[https://xingkaixin.me/posts/agent-needs-git/](https://xingkaixin.me/posts/agent-needs-git/)

本作品采用[CC BY-NC-ND 4.0 DEED](https://creativecommons.org/licenses/by-nc-nd/4.0/deed.zh-hans)许可。

导览

展开导览