Agent 都有记忆了，为什么我还是要反复解释同一件事？

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，拿到的不是一堆散乱的文本片段，而是一个有状态、有关联、有时间线的语义图谱。

一个例子

# 新 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 记住更多东西，而是把开发过程中产生的高层语义提升为正式的、有边界的、可查询的对象。

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

试一下

# 安装
pipx install intent-cli-python

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

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

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

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

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

Dozy Memory | Blog on Tech & Life