---
title: Agent 都有记忆了，为什么我还是要反复解释同一件事？
date: '2026-03-18'
summary: 从反复重建开发上下文的问题出发，讨论记忆、项目历史与结构化记录的区别。
lang: zh
category: AI/Agents
legacy_url: https://dozybot001.github.io/2026/03/18/2026-03-18-agent-memory-history/
---

2026 年了，AI coding agent 都有记忆了。

Claude Code 有 memory 和 CLAUDE.md，Cursor 有 rules，各家都在解决”agent 跨 session 记住东西”这个问题。记忆能力确实在变强——agent 可以记住你喜欢什么代码风格、项目用什么框架、测试怎么跑。

但我发现一个奇怪的现象：**即使 agent 有了记忆，我还是经常要重新解释上下文。**

不是解释”这个项目用的 TypeScript”这种偏好——这些 agent 已经记得很好了。我要解释的是：

- 我们现在到底在解决什么问题？
- 上次做到哪了？用户反馈了什么？
- 有哪些长期决策在约束当前的实现？
- 为什么沿着这条路径继续，而不是换一种方案？

这些东西，memory 记不住——**不是因为技术做不到，而是因为它们根本不是”记忆”，它们是”历史”。**

---

### 记忆和历史是两件事

现有的 agent 记忆系统（memory、rules、CLAUDE.md）本质上在回答一个问题：**“你是谁，你怎么工作。”**

- 你是后端工程师
- 你喜欢函数式风格
- 这个项目测试用 pytest
- 不要在 PR 里加 emoji

这些是**偏好和事实**。它们相对稳定，不太随任务变化。

但开发过程中还有另一类信息在持续产生：

- “我们正在重构认证模块”——这是一个**目标**
- “把超时从 5s 改到 30s，测试通过了”——这是一次**交互记录**
- “超时必须可配置，因为不同部署环境延迟不同”——这是一个**长期决策**

这些信息有生命周期（开始、推进、完成、回退），有相互关联（这个决策约束了那个目标），有时间线（先做了 A，用户说不对，改成了 B）。

**它们不是散点式的记忆条目，而是一段结构化的语义历史。**

现有的记忆系统并不是为这件事设计的。把”正在重构认证模块”写进 CLAUDE.md？可以，但等你完成了，谁来删掉它？下一个目标来了，谁来更新关联？这些交互记录散落在不同 session 里，没有统一的对象边界，无法查询、无法追踪、无法关联。

---

### 在 Git 之上，补一层语义历史

我做了一个工具叫 **Intent**。它不替代 Git，也不替代 agent 的 memory，而是补上中间缺失的一层——**语义历史**（semantic history）。

**Git** 回答：代码怎么变了。  
**Memory** 回答：你是谁，你怎么工作。  
**Intent** 回答：你在解决什么，做到哪了，为什么这么做。

核心模型只有三种对象：

| 对象 | 含义 | 类比 |
| --- | --- | --- |
| **Intent** | 一个被识别出的目标 | “我们在做什么” |
| **Snap** | 一次交互快照（问 + 做 + 反馈） | “刚才发生了什么” |
| **Decision** | 一条跨任务的长期约束 | “什么规则在约束我们” |

就这三个。没有更多了。

---

### 对象边界，而不是自由文本

你可能会想：写个 DECISIONS.md 记录决策不行吗？在 memory 里多存一些上下文不行吗？

技术上当然可以。但区别在于：**自由文本没有对象边界。**

Intent 里的每个对象有：

- **明确的状态**——active、done、deprecated。目标完成了就标 done，决策过时了就标 deprecated。不是你去记得”该删掉那条笔记了”，而是状态机在管理生命周期。
- **自动关联**——创建新 Intent 时，所有活跃的 Decision 自动挂上去。你不需要手动维护”这个任务受哪些约束影响”。
- **append-only**——做错了？在新 Snap 里修正，不改旧记录。历史完整可追溯。
- **JSON 输出，CLI 操作**——这不是给人读的文档，是给 agent 用的结构化上下文接口。

这些特性组合在一起的效果是：agent 在新 session 跑一下 `itt inspect`，拿到的不是一堆散乱的文本片段，而是**一个有状态、有关联、有时间线的语义图谱**。

---

### 一个例子

```bash
# 新 session 开始，先看看上下文
itt inspect

# agent 从用户的问题中识别出目标
itt intent create "优化首页加载速度" \
  --query "首页打开要 8 秒，太慢了"

# 记录一次交互
itt snap create "拆分了首屏资源" \
  --intent intent-001 \
  --query "主要瓶颈在哪？" \
  --summary "首屏加载了全部 JS bundle，拆分后降到 2s"

# 沉淀一条长期决策
itt decision create "所有新页面必须做首屏资源拆分" \
  --rationale "统一标准，防止性能回退"
```

下次 session，agent 跑 `itt inspect`：

- **活跃目标**：优化首页加载速度
- **已完成**：资源拆分，首屏 2s
- **全局约束**：新页面必须做首屏资源拆分

不需要重新解释。直接从断点继续。

---

### 这不是一个全新的问题领域

坦率地说，很多人和厂商都在尝试解决 agent 的上下文连续性问题。memory 系统在进步，context window 在变大，各种 RAG 方案在涌现。

Intent 选择的角度不太一样：**不是让 agent 记住更多东西，而是把开发过程中产生的高层语义提升为正式的、有边界的、可查询的对象。**

这个区别看起来微妙，但它决定了信息的可靠性。散落在记忆和聊天里的上下文，可以回忆但不稳定，可以讨论但难以追踪。而有明确边界的对象，可以查询、可以关联、可以管理生命周期。

---

### 试一下

```bash
# 安装
pipx install intent-cli-python

# 或者作为 Claude Code skill
npx skills add dozybot001/Intent
```

- GitHub: [github.com/dozybot001/Intent](https://github.com/dozybot001/Intent)
- 纯 Python，零依赖，MIT 协议
- 数据存在本地 `.intent/` 目录，跟着 Git 一起提交

---

*Intent 不是更好的记忆，不是更好的文档，不是更好的 commit message。*

*它是开发过程中一直在产生、但从未被正式建模的那层东西——目标、交互、决策——的第一类对象。*

*如果你用 agent 写代码，并且发现自己总是在重新解释”我们在做什么、做到哪了、为什么这么做”——这正是 Intent 想解决的。*