你是否遇到过这种情况:同一个 Agent,在同一个任务上反复犯错——每次都说「我已经修复了」,然后下一次又犯同样的错误。这是 Agent 记忆系统的失效。本质问题是:Agent「记住」了错误,但从来没有「学会」如何避免。
本文是这个系列的前一篇《AI Coding Agent 自修正模式》的续篇,将自修正的即时纠错能力延伸为持续学习闭环——从失败捕获、根因分析、模式抽象,到策略更新和行为验证,形成一个让 Agent 真正进化的机制。
目录
一、「记住」不等于「学会」
在深入技术细节之前,先区分两个概念:记忆和学习。
当前大多数 AI Agent 的记忆系统,本质上是一个信息检索系统:
Session 开始 → 加载历史上下文 → 执行任务 → 记录结果到记忆文件 → Session 结束
这套机制可以总结为:「见过的问题,下次还能找到答案」。但这不是学习,这是检索。
举一个具体例子:
Day 1:
Agent 在重构正则表达式时,没有先验证原有行为就做了修改
→ 写入了 memory/2026-04-10.md:"修改正则时要小心"
Day 2:
Agent 在另一个项目中遇到正则修改
→ 读取了 memory/2026-04-10.md
→ 但仍然没有先验证原有行为,直接修改 → 再次失败
这说明「记住」没有转化为「学会」。区别在于:
| 记忆(Retrieval) | 学习(Learning) | |
|---|---|---|
| 核心机制 | 存储 + 检索 | 存储 + 分析 + 策略更新 |
| 失败后 | 记录「发生了什么」 | 分析「为什么发生」+「下次如何避免」 |
| 持续性 | 随时间衰减(信息过载) | 随时间增强(模式提炼) |
| 对行为的影响 | 需要主动想起才能用 | 自动影响后续决策 |
真正的学习需要形成一个闭环,每一个失败都要触发一次自我改进的迭代。
二、Agent 记忆的三个层次
理解持续学习闭环的关键,是认识到 Agent 记忆有三个层次——每一层解决不同的问题。
2.1 第一层:事件记忆(Episodic Memory)
事件记忆记录「具体发生了什么」,是原始数据层。
## 事件记录 2026-04-10
**任务**:重构 auth.py 中的登录验证逻辑
**结果**:失败(引入新 bug)
**表现**:登录成功率从 98% 降至 72%
**直接原因**:正则表达式覆盖了不应该覆盖的边界
**时间**:10:00 - 10:30
事件记忆的特点:
- 描述性强:说明白了发生了什么
- 可检索:可以通过关键词找到
- 无抽象:Agent 读到自己失败的记录,但不知道下次如何避免
事件记忆的问题在于:当记录积累到数十条之后,Agent 很难从海量记录中提炼出通用规律。这就是为什么需要第二层。
2.2 第二层:模式记忆(Pattern Memory)
模式记忆从多个事件中提取共同模式,是对事件数据的抽象层。
## Pattern-2026-04-13: RegexModificationWithoutTestGuard
**触发条件**:修改正则表达式、SQL 查询或配置格式
**失败形态**:修改后测试失败,原有功能被破坏
**根因类型**:Agent 没有先验证原有行为就直接修改
**预防策略**:修改前先写一个「验证原有行为」的测试用例
**出现频率**:3 次(2026-04-10, 2026-04-12, 2026-04-13)
**置信度**:高(≥3次)
模式记忆比事件记忆更有价值,因为它揭示了因果链:
事件记忆:修改正则后测试失败了
模式记忆:当我修改任意配置类格式时,没有先验证原有行为 → 会失败
但模式记忆仍然是被动的——它告诉你「什么情况下会出问题」,但没有告诉你「下次遇到类似情况时,具体应该怎么做」。这就是第三层存在的意义。
2.3 第三层:策略记忆(Strategic Memory)
策略记忆存储 Agent 的「元认知」——关于自己思考方式和行为准则的高层知识。
## Strategic-Memory-2026-04-13
**关于重构**:
- 当任务涉及多个模块的交互时,先画架构图再动手
- 任何 > 5 文件的重构,必须先做小范围验证
- 修改正则/配置/SQL 前,先写测试用例验证原有行为
**关于不确定性**:
- 遇到不熟悉的设计决策,先问用户而非猜测
- 当一个决策的后果不可逆时,放慢速度多做验证
**关于验证**:
- 每次修改后立即运行相关测试,不要等到最后全量测试
- 引入新依赖前,先确认已有依赖中没有同功能的库
策略记忆是主动应用的——当 Agent 遇到一个任务时,不需要想起来「上次有个记录说要先验证」,而是这个策略已经存在于它的启动指令中,自动影响当前行为。
三个层次的关系:
事件记忆(原始记录)
↓ 模式提炼
模式记忆(因果抽象)
↓ 策略提取
策略记忆(主动原则)→ 自动影响 Agent 行为
三、持续学习闭环的工程实现
3.1 闭环的五个阶段
失败捕获 → 根因分析 → 模式抽象 → 策略更新 → 行为验证
↑ ↓
└────────────────────────────────────────────────────┘
(新一轮闭环)
阶段 1:失败捕获(Failure Capture)
失败的来源有四种:
- 工具返回错误:
isError: true - Agent 主动标记不确定:「这个改动可能会影响…」
- 用户反馈:Human Feedback
- 任务异常:超时、Token 超预算
失败捕获的关键是立即记录,在 Agent 的工作上下文中就记录下来(不要等到 Session 结束后)。
class FailureCapture:
def __init__(self, memory_path):
self.memory_path = memory_path
self.current_failure = None
def capture(self, task_type, manifestation, agent_trace):
"""在失败发生时立即调用"""
self.current_failure = {
"failure_id": generate_id(),
"timestamp": now_iso(),
"task_type": task_type,
"manifestation": manifestation,
"agent_trace": agent_trace,
"status": "pending_analysis"
}
self._write_episodic(self.current_failure)
def _write_episodic(self, failure_record):
"""写入事件记忆"""
date = today()
path = f"{self.memory_path}/{date}.md"
append_to_file(path, self._format_failure(failure_record))
阶段 2:根因分析(Root Cause Analysis)
这是大多数 Agent 记忆系统的缺失环节。只记录「失败了」是不够的,必须分析「为什么失败」。
ROOT_CAUSE_PROMPT = """
任务类型:{task_type}
失败表现:{manifestation}
Agent 执行过程:
{agent_trace}
请分析以下四个问题:
1. Agent 的决策在哪里偏离了正确方向?
2. 当时的上下文信息是否充足?(足够/不足/误导性)
3. 这个失败是 Agent 能力问题还是信息问题?
4. 如果重新处理类似任务,Agent 应该在哪一步改变策略?
请用以下格式输出:
根因:[一句话描述]
根因类型:[信息不足 | 能力不足 | 误导性反馈 | 系统限制]
预防策略:[具体可操作的行为改变]
"""
根因分类决定了下一步的处理方式:
| 根因类型 | 处理方式 |
|---|---|
| 信息不足 | 在 Context 中补充信息,或优化 Schema |
| 能力不足 | 升级模型,或拆解任务为更简单的步骤 |
| 误导性反馈 | 优化验证机制,添加额外的检查点 |
| 系统限制 | 记录为已知限制,在策略中规避 |
阶段 3:模式抽象(Pattern Abstraction)
当同一个根因出现多次(≥3次),就从事件记忆中提取为模式记忆:
def extract_pattern(failures):
"""
从多个失败记录中提取共同模式
触发条件:相同根因出现 ≥3 次
"""
# 1. 按根因分组
by_root_cause = group_by(failures, "root_cause_type")
patterns = []
for root_cause, group in by_root_cause.items():
if len(group) >= 3:
pattern = {
"pattern_id": generate_id(),
"trigger_conditions": extract_common_triggers(group),
"root_cause": root_cause,
"prevention_strategy": group[0]["prevention_strategy"],
"frequency": len(group),
"confidence": "high" if len(group) >= 5 else "medium",
"first_seen": group[0]["timestamp"],
"last_seen": group[-1]["timestamp"]
}
patterns.append(pattern)
return patterns
模式抽象不是一次性完成的,而是随着失败记录的积累渐进式提炼。
阶段 4:策略更新(Strategy Update)
从高置信度模式(≥3次出现)中提取可操作的行为规则,更新到 Agent 的启动指令或系统 Prompt 中。
策略注入有两种方式:
方式 1:系统 Prompt 注入(持久性影响)
[从失败记录中学到的策略 - 2026-04-13]
当修改正则表达式、SQL 查询或配置格式时:
1. 先写测试用例验证原有行为(golden case test)
2. 在验证基础上做最小化修改
3. 修改后立即运行验证测试
4. 确认原有行为未被破坏后再提交
当前已验证的高置信度模式:
- P-001: RegexModificationWithoutTestGuard(置信度:高,出现 3 次)
- P-002: MultiFileRefactorWithoutSnapshot(置信度:中,出现 2 次)
方式 2:上下文注入(单次任务影响)
def inject_task_context(task):
"""在任务开始时,检查相关模式并注入上下文"""
relevant_patterns = search_patterns(task.type)
if relevant_patterns:
context = "[学习历史] 此任务类型过去出现过问题:\n"
for p in relevant_patterns:
context += f"- {p['pattern_id']}: {p['prevention_strategy']}\n"
context += "请在执行时格外注意上述风险点。\n"
return context
return ""
阶段 5:行为验证(Behavioral Verification)
学习闭环的最后一个环节:验证新策略是否真的有效。
验证方法:
1. 遇到类似场景时,在上下文注入策略提示
2. 记录 Agent 是否真的执行了预防行为(如:是否先写了测试)
3. 执行了 → 记录结果,置信度 +1
4. 没执行 → 分析为什么策略没有被遵循,更新策略描述使其更可操作
5. 策略置信度低于阈值时,触发重新分析
3.2 闭环的自动化程度
完整自动化所有五个阶段是困难的。实际上可以分三档:
| 档位 | 覆盖阶段 | 自动化程度 | 适用场景 |
|---|---|---|---|
| 最小化 | 1 + 4 | 半自动(人工触发) | 个人使用,快速上手 |
| 生产级 | 1-4 | 大部分自动 | 团队使用,有审计需求 |
| 企业级 | 1-5 | 全自动闭环 | 大规模部署,高可靠性 |
对于大多数个人用户,从最小化开始即可:只要做到「失败后记录 + 更新策略注入」,就已经比纯检索式记忆强了一个层次。
四、三层记忆的组织与检索
三层记忆需要不同的组织方式和检索策略。
4.1 文件组织
memory/
├── episodic/ # 事件记忆(按日期)
│ ├── 2026-04-10.md
│ ├── 2026-04-12.md
│ └── 2026-04-13.md
├── patterns/ # 模式记忆(按类型)
│ ├── P-001-regex-modification.yaml
│ ├── P-002-multi-file-refactor.yaml
│ └── P-003-unfamiliar-api.yaml
├── strategic/ # 策略记忆(按领域)
│ ├── refactoring.md
│ ├── unfamiliar-code.md
│ └── high-stakes-decisions.md
└── templates/
├── failure-record.md # 失败记录模板
└── pattern-extraction.md # 模式提取模板
4.2 检索策略
事件记忆的检索:按时间 + 关键词检索
def search_episodic(query, date_range=None):
"""检索相关事件记忆"""
results = []
for file in list_files("memory/episodic/", date_range):
content = read_file(file)
if keyword_match(content, query):
results.append(parse_episodic(content))
return results
模式记忆的检索:按任务类型 + 根因类型
PATTERN_INDEX = {
"code_refactor": ["P-001", "P-002"],
"regex_modification": ["P-001"],
"unfamiliar_api": ["P-003"],
}
def get_relevant_patterns(task_type):
"""任务开始时获取相关模式"""
pattern_ids = PATTERN_INDEX.get(task_type, [])
return [read_pattern(f"memory/patterns/{pid}.yaml") for pid in pattern_ids]
策略记忆的检索:按任务领域直接加载
STRATEGIC_MEMORY_INDEX = {
"refactoring": "memory/strategic/refactoring.md",
"unfamiliar_code": "memory/strategic/unfamiliar-code.md",
"high_stakes": "memory/strategic/high-stakes-decisions.md"
}
五、实战:一个最小化学习闭环的实现
下面展示一个可以直接运行的最小化实现,基于 Claude Code 的 Hooks 机制。
5.1 架构概览
Hook: on_tool_result
↓ 捕获 isError: true 的工具调用
FailureCapture
↓ 写入 episodic memory
Hook: on_end_turn(或定时)
↓ 读取该 session 的失败记录
RootCauseAnalyzer(Claude Code Subagent)
↓ 生成根因分析
PatternExtractor(定期运行)
↓ 提炼为模式记忆
StrategyUpdater
↓ 更新 system prompt 或上下文模板
BehavioralVerifier(下次遇到类似任务时)
↓ 验证策略是否被执行
5.2 核心实现
# ~/.claude/commands/learning-loop.sh
#!/bin/bash
LEARNING_DIR="$HOME/.claude/learning"
mkdir -p "$LEARNING_DIR"/{episodic,patterns,strategic}
capture_failure() {
local task_type="$1"
local manifestation="$2"
local tool_name="$3"
local failure_id="fail-$(date +%Y%m%d-%H%M%S)"
local record_file="$LEARNING_DIR/episodic/$(date +%Y-%m-%d).md"
cat >> "$record_file" << EOF
## $failure_id
**时间**:$(date -Iseconds)
**任务类型**:$task_type
**失败工具**:$tool_name
**表现**:$manifestation
**根因分析**:pending
**状态**:待分析
EOF
echo "✅ 失败记录已保存: $failure_id"
}
analyze_patterns() {
# 定期运行(每周一次),从 episodic memory 中提炼模式
# 使用 Claude Code 对 recent failures 做分析
echo "🔍 分析近期失败记录,提炼模式..."
}
update_strategy() {
# 将高置信度模式转为策略记忆
local pattern_id="$1"
echo "📝 更新策略记忆: $pattern_id"
}
5.3 在 Claude Code 中集成
# ~/.claude/.clauderc
{
"hooks": {
"onToolResult": [
{
"match": {"outcome": "error"},
"run": "capture_failure '{tool.name}' '{result}'"
}
],
"onEnd": [
{
"run": "analyze_patterns_if_needed"
}
]
}
}
这个最小化实现覆盖了:
- 失败捕获(
onToolResultHook) - 事件记录(episodic memory)
- 定期模式分析(
analyze_patterns) - 策略更新(strategy memory)
六、常见陷阱与应对
陷阱 1:过度记忆(Memory Overload)
问题:记录了大量失败,但没有提炼模式,导致记忆文件越来越长却无人阅读。
应对:
- 强制设置模式提炼阈值(≥3次才生成 Pattern)
- 定期清理低价值事件记录(只保留 Pattern)
- 事件记录只保留最近 30 天
陷阱 2:模式误判(False Pattern)
问题:从偶然的两次失败中提炼出错误的模式,导致 Agent 在正确场景下也「过度谨慎」。
应对:
- 模式置信度低于 3 次时,只在 Context 中提示,不自动应用策略
- 设置置信度衰减:长时间未复现的模式,自动降低优先级
- 定期 review 模式是否仍然有效
陷阱 3:策略无法执行(Unactionable Strategy)
问题:提炼出的策略过于抽象,Agent 知道「应该小心」但不知道「具体怎么做」。
应对:
- 策略必须具体到可操作的行为(不是「要小心」而是「先写测试」)
- 检查策略是否包含触发条件(什么情况下应用)和具体步骤(怎么做)
陷阱 4:遗忘学习(Learning Decay)
问题:Agent 记住了新的策略,但随着时间推移,这些策略逐渐不再被引用。
应对:
- 将策略直接嵌入 system prompt 或 .clauderc,而不是放在外部记忆文件
- 定期在 Context 中注入「学习历史提醒」,使策略记忆保持活跃
总结:从「能用」到「越用越强」
持续学习闭环的价值不在于记录了多少失败,而在于:
事件记忆 → 告诉你「上次怎么了」
模式记忆 → 告诉你「这种情况容易怎么错」
策略记忆 → 告诉 Agent「下次遇到这种情况,先这样做」
行为验证 → 确认策略真的有效,否则重新调整
这是一个「失败 → 分析 → 预防 → 验证」的闭环,每一次迭代都让 Agent 变得更可靠。
从工程角度,这套闭环不需要一步到位。可以从最小化开始(只做失败捕获 + 策略注入),逐步增加分析深度和验证环节。关键不是完整性,而是让 Agent 真正从错误中进化,而不是一遍一遍重复同样的失误。
当你建立起这套机制后,你会看到一个明显的变化:Agent 在某个领域内犯错的频率会随时间显著下降。这就是从「能用」到「越用越强」的实际含义。
本文是「持续学习 Agent」的学习笔记,承接《AI Coding Agent 自修正模式》与《Multi-Agent 系统故障诊断实战》,构成「自修正 → 调试 → 持续学习」的能力进化三部曲。