你是否遇到过这种情况:同一个 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 很难从海量记录中提炼出通用规律。这就是为什么需要第二层。

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)

失败的来源有四种:

  1. 工具返回错误isError: true
  2. Agent 主动标记不确定:「这个改动可能会影响…」
  3. 用户反馈:Human Feedback
  4. 任务异常:超时、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"
      }
    ]
  }
}

这个最小化实现覆盖了:


六、常见陷阱与应对

陷阱 1:过度记忆(Memory Overload)

问题:记录了大量失败,但没有提炼模式,导致记忆文件越来越长却无人阅读。

应对

陷阱 2:模式误判(False Pattern)

问题:从偶然的两次失败中提炼出错误的模式,导致 Agent 在正确场景下也「过度谨慎」。

应对

陷阱 3:策略无法执行(Unactionable Strategy)

问题:提炼出的策略过于抽象,Agent 知道「应该小心」但不知道「具体怎么做」。

应对

陷阱 4:遗忘学习(Learning Decay)

问题:Agent 记住了新的策略,但随着时间推移,这些策略逐渐不再被引用。

应对


总结:从「能用」到「越用越强」

持续学习闭环的价值不在于记录了多少失败,而在于:

事件记忆  →  告诉你「上次怎么了」
模式记忆  →  告诉你「这种情况容易怎么错」
策略记忆  →  告诉 Agent「下次遇到这种情况,先这样做」
行为验证  →  确认策略真的有效,否则重新调整

这是一个「失败 → 分析 → 预防 → 验证」的闭环,每一次迭代都让 Agent 变得更可靠。

从工程角度,这套闭环不需要一步到位。可以从最小化开始(只做失败捕获 + 策略注入),逐步增加分析深度和验证环节。关键不是完整性,而是让 Agent 真正从错误中进化,而不是一遍一遍重复同样的失误

当你建立起这套机制后,你会看到一个明显的变化:Agent 在某个领域内犯错的频率会随时间显著下降。这就是从「能用」到「越用越强」的实际含义。


本文是「持续学习 Agent」的学习笔记,承接《AI Coding Agent 自修正模式》与《Multi-Agent 系统故障诊断实战》,构成「自修正 → 调试 → 持续学习」的能力进化三部曲。