AI 智能体是如何随时间真正学习的
大多数构建 AI 智能体的团队都将模型视为固定不变的产物。你选择一个基础模型，编写提示，连接一些工具，然后发布。如果智能体开始出错，你会调整系统提示或切换到更新的模型。在这种框架下，学习发生在“上游”——在 AI 实验室中，在预训练和 RLHF 阶段——而不是在你的技术栈中。
这是一种错误的思维模型。随着时间推移而改进的智能体，是在三个不同的架构层面上实现这一点的，其中只有一个层面涉及修改模型权重。了解这一区别的团队能够构建出质量持续提升的系统；不了解的团队则会不断手动修补相同的故障模式。
智能体学习的三个层次
将已部署的智能体想象成一个技术栈：
- 模型层：神经网络及其权重
- 驾驭层：运行智能体的代码、指令、工具和编排逻辑
- 上下文层： 运行时注入的外部配置——记忆、每个用户的指令、动态工具集
学习可以在每个层独立发生。大多数工程工作默认关注模型层，但实际上，驾驭层和上下文层通常更快、更安全、也更具针对性。
第一层：模型权重
这是传统的机器学习：在精选轨迹上进行监督微调（SFT），通过人类或 AI 反馈进行强化学习，或从更强的模型中进行知识蒸馏。如果操作得当，它功能强大，但也伴随着实际成本。
核心问题是灾难性遗忘：为新任务更新权重会降低模型在旧任务上的性能。在你的客户支持领域微调过的模型，可能会在它之前表现良好的推理任务上变得更差。弹性权重整合（EWC）等技术会惩罚对早期任务很重要的权重的巨大变化，而渐进式神经网络则通过为每个任务添加新容量同时冻结旧权重来完全避免遗忘。Meta FAIR 最近的工作利用稀疏记忆微调——每次前向传播只激活一小部分记忆槽——将新知识与现有表示隔离开来。
实际结果是：模型层学习是高杠杆但高风险的。它需要仔细评估、受控发布和大量数据基础设施。大多数团队应该在穷尽其他两层之后再考虑它。
第二层：驾驭层
驾驭层是模型和用户之间的一切：系统提示、工具定义、重试逻辑、输出解析器、路由代码。这一层完全在你的控制之下，不需要重新训练任何东西。
一种名为**元驾驭层（meta-harness）**的模式明确了这一点：一个独立的智能体——通常是更强的模型——分析生产执行轨迹，并提出对驾驭层本身的改进建议。它可能会注意到某个工具在 30% 的时间里以错误的参数被调用，并建议一个更清晰的描述。或者它识别出一种可靠导致幻觉的提示模式并进行重写。人类批准这些更改；循环再次运行。
这比上下文更新慢，但比模型重训练快。而且与权重变化不同，它是完全可审计的——你仓库中的一个 diff。当 Claude Code 分析一个失败的任务并建议更新 CLAUDE.md 时，这就是驾驭层学习的具象体现。
第三层：上下文层
上下文学习是最快、最有针对性的：你在运行时更新注入到提示中的内容，而无需更改模型或代码。这包括：
- 每个用户的记忆：每次调用前从记忆存储中检索的事实、偏好和历史记录
- 每个租户的配置：针对不同组织的不同工具集、指令或角色
- 动态更新的技能：一个基于实际效果随时间推移而改进的少样本示例库
值得一提的一种模式是离线梦想（offline dreaming）：定期处理一批最近的执行轨迹，提取可泛化的见解，然后将这些见解写回上下文存储。一个处理调度的智能体，在运行 500 次后可能会注意到，某个特定时区的用户总是会覆盖其默认会议时间——并相应地更新其工作记忆。无需模型更新。
权衡在于，上下文学习受限于上下文窗口大小和 检索质量。你不能将所有内容都编码到提示中。这就是为什么这三层是互补的，而不是相互替代的。
基础原语：轨迹
没有轨迹，这一切都无法运行。轨迹是智能体执行的完整记录：输入、每个工具调用及其结果、中间推理步骤和最终输出。轨迹是 SFT 的训练数据，是元驾驭层的输入，也是离线梦想的原始材料。
早期投资于轨迹基础设施的团队往往会随着时间的推移而领先。复合效应是真实存在的：每一次生产运行都成为改进的潜在信号。将智能体视为黑盒——只记录输入和输出——的团队正在丢弃大部分此类信号。
一个有用的视角：将你的轨迹存储视为一个飞轮。你记录得越多，你就能改进得越多。你改进得越多，你的轨迹就越好（因为更好的智能体会遇到更多有趣的边缘情况）。如果你构建了闭环基础设施，这个循环就会加速。
一个好的轨迹存储应该包含什么：
- 完整的工具调用历史，包括延迟和错误代码
- 人类或 AI 对运行是否成功的判断
- 结构化元数据（用户、租户、任务类型、模型版本）
- 中间推理步骤，而不仅仅是最终输出
选择何时应用每一层
合适的层级取决于你正在优化什么以及你需要多快的速度获得结果。
在以下情况使用上下文 更新：
- 故障模式特定于某个用户或租户
- 你有清晰、有针对性的修复方案（一个新的记忆条目、一个修正的指令）
- 你需要在生产环境中快速迭代
在以下情况使用约束层更新：
- 故障模式出现在许多用户中
- 根本原因是工具描述不明确、指令模糊或缺少错误处理程序
- 你希望修复是可代码审查和版本控制的
在以下情况使用模型层更新：
- 你有一个需要持久新知识或风格的领域（例如，一个新的产品线，一套专业的术语词汇）
- 上下文和约束层修复已达到极限
- 你有足够的标记轨迹数据和评估基础设施来安全地验证更新
在实践中，大多数团队应该按顺序执行这些操作：首先修复上下文，然后是约束层，最后考虑精调。每个层级的成本和风险状况都会增加，所以在尝试更高层级之前，请验证较低层级是否无法解决问题。
生产模式
在那些做得好的团队中，一些模式反复出现：
粒度很重要。 并非所有学习都应该是全局的。一个对某个用户有效的修复可能对另一个用户是错误的。构建你的学习基础设施以在正确的范围内运行：针对偏好学习进行按用户划分，针对领域特定行为进行按租户划分，针对系统性错误进行全局划分。
离线优先于在线。 实时学习——在实时任务中更新上下文或记忆——虽然诱人但很脆弱。一个在任务中途更新自身上下文的模型可能会累积错误。从轨迹的离线批量处理开始；只有当你对更新逻辑有信心时，才转向在线学习。
评估不可或缺。 每一个学习更新——无论是新的记忆条目、修改后的系统提示，还是精调模型——在投入生产之前都需要进行评估。即使是微小的改动也可能产生意想不到的下游效应。在这里快速行动的团队是那些拥有良好评估机制的团队，而不是那些跳过评估的团队。
约束层的人工监督。 自动化的元约束层建议很有用，但在发布提示和工具变更之前，应该由人工批准。上下文更新（例如添加记忆条目）通常可以更自动化；约束层变更则应通过代码审查。
发展方向
研究前沿正在推动开发能够在这三层中提出并评估自身改进的智能体——不仅仅是建议一个记忆条目，而是推理模型更新是否合理以及需要哪些数据来验证它。这类系统已开始出现在研究环境中。
对于今天的实践者而言，机会虽然更适度但仍相当可观：仪表化你的轨迹，在上下文层构建一个反馈循环，并根据生产数据定期审查你的约束层。大多数已部署的智能体都在运行初始构建时编写的静态提示和固定工具定义。这些智能体与那些随着时间推移质量不断提高的智能体之间的差距，主要是基础设施和流程差距，而不是模型能力差距。
现在弥合这一差距的团队，将随着底层模型的改进和所有三种学习模式成本的持续下降，获得越来越持久的优势。
