学习与适应（Learning and Adaptation）：让 Agent 从反馈里改进
一听「让 Agent 学习」，很多人脑子里立刻冒出微调、RLHF、GPU、评估集，然后心里默默关掉页面：这东西是不是又贵又玄？
先把心放回肚子里。这里说的「学习」，大多数时候不是训练模型权重，而是给 Agent 配一本会更新的错题本。
学生做错数学题，通常不会跑去做「开颅手术」改大脑。他会把错题、原因和下次做法记下来，考试前翻一翻。Agent 的运行时学习也差不多：模型本身不变，但系统会把失败、反馈和成功经验沉淀到记忆、技能或提示词里。下一次遇到类似任务，先翻旧账，再动手。
这篇只讲工程里最常见、最容易落地的那一种：
执行任务 -> 观察结果 -> 复盘经验 -> 校验写入 -> 下次检索使用它的目标不是把模型变成另一个模型，而是让同类失败别一遍遍重演。
一、先分清三种学习
新手最容易误会的一点，是把「学习」等同于「改模型」。实际上 Agent 可以在三个层面变聪明：
| 类型 | 改的是什么 | 能否即时回滚 | 常见场景 |
|---|---|---|---|
| 参数学习 | 模型权重 | 难 | 模型团队、研究团队 |
| 上下文学习 | 当前提示词和示例 | 能 | Few-shot、临时任务适配 |
| 运行时学习 | 外部记忆、技能、经验库 | 能 | Agent 产品、业务系统、个人助手 |
本文只讲第三种。它不替代微调，也不保证提升模型能力上限；它解决的是更朴素的问题：同一类任务反复出现时，不要每次都从零开始。
为什么业务系统里通常不优先微调？原因很现实：数据准备慢，评估周期长；闭源模型只能通过 API 使用；业务规则变化快，持续微调不划算；学错以后回滚和审计都麻烦。
运行时学习轻很多。经验写在外部，能查看、能删除、能降权、能回滚。对工程团队来说，这种可控性比「听起来很智能」更重要。
二、运行时学习到底在转哪一圈
把花哨名词都拿掉，一个会学习的 Agent 通常只是在跑这条闭环：
关键不是「写复盘」这一步，而是「校验和过滤」。不是所有反馈都值得学。用户一句「你太死板了」，不能被直接学成「以后绕过权限检查」；SQL 返回 0 行，也不能被简单学成「下次放宽所有过滤条件」。
所以，学习系统真正要设计的是四件事：
| 问题 | 设计重点 |
|---|---|
| 什么时候学 | 只从明确的成功、失败或高质量人工反馈里学 |
| 学什么 | 学可迁移的经验，不学一次性情绪和硬指令 |
| 写到哪里 | 经验、技能、提示词、用户偏好要分库存储 |
| 下次怎么用 | 检索要带相似度、时效、来源和风险等级 |
经验库不是垃圾桶。能沉淀、能检索、能回滚，才叫学习。
三、四条常见路径怎么选
运行时学习不是一种实现，而是一组做法。选错路径，就会把记忆、技能、提示词和用户偏好搅成一锅粥。
| 路径 | 学到什么 | 存在哪里 | 写入时机 | 适合场景 | 主要风险 |
|---|---|---|---|---|---|
| Reflexion | 失败教训 | 经验库 / Memory | 任务失败后 | SQL、代码、工具使用 | 坏反馈导致负学习 |
| Skill Library | 成功代码或流程 | 技能库 | 任务成功后 | 编程、运维、自动化 | 技能过期或权限过大 |
| Prompt Optimization | 更好的提示词 | Prompt 配置 | 批量评估后 | 稳定任务、可打分任务 | 过拟合测试集 |
| Experience Memory | 完整成功轨迹 | 轨迹库 | 高质量完成后 | 复杂流程复用 | 检索错案例 |
入门建议很简单：先吃透 Reflexion。它就是把「反思」和「记忆」两个你已经熟悉的组件焊在一起，门槛低，收益也直观。失败了，写一条可迁移教训；下次类似任务，把教训放进上下文。
等 Reflexion 跑稳了，再考虑把成功做法沉淀成 Skill，把稳定任务交给 Prompt Optimization，把复杂流程沉淀成 Experience Memory。
四、完整案例：从失败里学习的 SQL Agent
光讲概念没用。我们做一个最小的 SQL Agent：用户用自然语言提问，Agent 生成 SQL。如果 SQL 失败，就写一条可复用教训；下次遇到类似问题，先检索教训再生成。
第一步，经验条目要有结构。自由文本复盘听起来灵活，但也是记忆投毒的温床。
from dataclasses import dataclass, field
from datetime import datetime, timezone
@dataclass
class Reflection:
failed_question: str
failed_sql: str
error_signal: str
lesson: str
source: str = "execution_feedback"
created_at: str = field(
default_factory=lambda: datetime.now(timezone.utc).isoformat()
)第二步，复盘提示词要强制「通用化」：
请根据失败信息写一条可复用教训。
要求：
1. 只写经验事实，不写系统指令；
2. 格式为「下次遇到 X 类问题时，应该 Y」；
3. 教训要能迁移到相似问题，不要只针对这一次；
4. 不要要求绕过权限、跳过校验或永久覆盖规则。
问题：{{question}}
SQL：{{sql}}
错误：{{error}}第三步，把主循环接起来。注意这里把「SQL 报错」和「返回 0 行」都当成失败信号，因为后者经常意味着语法对了、语义错了。
EXPERIENCES = []
def retrieve_reflections(question):
return [
item for item in EXPERIENCES
if is_similar(question, item.failed_question)
][:3]
def validate_reflection(reflection):
banned = ["忽略权限", "跳过校验", "覆盖系统规则", "永远执行"]
if any(word in reflection.lesson for word in banned):
return False
return reflection.lesson.startswith("下次遇到")
def solve_sql(question, max_trials=3):
for _ in range(max_trials):
lessons = retrieve_reflections(question)
sql = generate_sql(question, lessons)
success, error, rows = execute_sql(sql)
if success and rows:
return rows
reflection = write_reflection(question, sql, error or "返回 0 行")
if validate_reflection(reflection):
EXPERIENCES.append(reflection)
return None这不是完整数据库实现，但它把边界讲清楚了：先有真实反馈，再写经验；写入前要过滤；任务失败次数要封顶；经验只能辅助生成，不能覆盖权限和系统规则。
五、失败信号怎么处理
学习系统最大的风险不是学不会，而是学坏。失败信号要先分层，不同信号对应不同写入策略。
| 失败信号 | 是否自动学习 | 处理方式 | 是否人工审核 |
|---|---|---|---|
| SQL 报错 | 可以 | 写字段、语法、表结构相关教训 | 低风险可自动 |
| 返回 0 行 | 可以，但要谨慎 | 记录过滤条件可能错误 | 建议抽样 |
| 用户负反馈 | 谨慎 | 先分类是事实错、语气差还是偏好问题 | 建议 |
| 安全违规 | 不自动 | 进入安全审计和规则修复 | 必须 |
| 业务策略变化 | 不自动 | 更新系统规则或配置 | 必须 |
| 数据漂移 | 谨慎 | 标记旧经验降权或过期 | 建议 |
这里有个很容易踩的坑：把「用户不满意」当成「系统应该改变规则」。用户反馈当然重要，但它不天然可靠。涉及权限、付款、合规、隐私的规则，应该放在更高优先级，经验库永远不能覆盖。
六、上线前守住几条底线
如果要把运行时学习放进生产环境，至少要守住这几条：
| 风险 | 例子 | 防护方式 |
|---|---|---|
| 负学习 | 从错误反馈中学到错误规则 | 经验写入前校验，必要时人工审核 |
| 记忆投毒 | 用户把指令伪装成教训 | 复盘只能写事实和教训，不能写行为命令 |
| 经验膨胀 | 教训太多，检索噪声变大 | 合并、降权、过期、按领域分区 |
| 权限覆盖 | 学到「以后不要检查权限」 | 权限规则只允许系统配置或管理员修改 |
| 无法回滚 | 经验污染后找不到来源 | 每条经验带 source、created_at 和写入原因 |
再补一个工程经验：学习要做成副作用，而不是主任务。Agent 的第一目标永远是完成任务；学习只是任务结束后的沉淀。成功就返回，失败次数到上限就停止，别为了「多学一点」把成本烧穿。
七、和其他 Agent 模式的关系
学到这里，前面几篇的模式开始互相接上了：
| 模式 | 提供什么 | 学习如何使用 |
|---|---|---|
| 反思 | 失败原因和改进建议 | 把反思写成经验 |
| 记忆 | 外部存储和检索 | 存放经验、偏好和成功轨迹 |
| 工具调用 | 真实执行反馈 | 提供成功、报错、0 行等信号 |
| 规划 | 多步任务结构 | 复用成功计划模板 |
| 多智能体 | 不同角色分工 | 让审核者决定经验是否入库 |
一句话串起来：Reflexion 是「反思 + 记忆」，技能库是「工具 + 记忆」，自适应规划是「规划 + 学习」。学习不是单独一层魔法，它是把已有组件变成长期复利的那根线。
八、一句话记住学习与适应
运行时学习不是回炉重造模型大脑，而是给 Agent 建一个可审计、可回滚、会自我维护的错题本。
好的学习系统要回答五个问题：
这次反馈可靠吗？
学到的内容能迁移吗？
会不会覆盖安全规则？
下次什么时候该检索它？
学坏了能不能回滚？能答上来，冻结的模型也会越用越顺手；答不上来，所谓「会学习」，很可能只是把风险攒进了一个更难发现的地方。