四种更新载体
学习信号说明 agent 应当改变，但没说改变发生在哪。选择更新方式的首要依据不是经验出现了多久，而是目标能力能否被某种载体自然表达：事实写成知识、可语言化的策略写成提示词或 Skill、可精确执行的流程写成程序、高维隐式能力才进模型参数。
学习信号说明 agent 应当改变，但没说改变应发生在哪。选择更新方式的首要依据不是经验出现了多久，而是目标能力能否被某种载体自然表达。四种方式并不互斥——医疗影像 agent 靠参数识别病灶、用知识库提供最新指南、用代码计算风险指标。
| 更新方式 | 适合承载 | 主要优势 | 主要局限 |
|---|---|---|---|
| 经验知识库 | 事实、经验规律、例外与来源 | 更新快、可追溯、可按需检索 | 依赖检索和模型正确应用 |
| Prompt 与 Skill | 可语言化的判断原则和操作规范 | 可解释、作用范围可控 | 容易膨胀、冲突或被忽略 |
| 程序与 Harness | 确定性流程、工具和强约束 | 可测试、执行稳定、成本低 | 开发与维护成本较高 |
| 模型参数 | 高维感知、生成风格和隐式策略 | 泛化能力强、推理开销低 | 更新与回归成本高 |
将经验沉淀为知识
最轻量的进化是把多次运行反复出现的经验整理成可检索的知识文档。它与用户记忆共享存储与检索技术，但来源和目标不同：用户记忆提取“用户与世界是什么样的”，经验知识提取“在什么条件下应该怎样做”（“订票前先检查特殊餐食截止时间”是行动经验，而非领域事实）。原始轨迹不适合作为知识单元——它又长又嘈杂。更稳妥的系统保留三层：不可变原始轨迹（审计）、单次运行分析（本次成败与候选教训）、多条同类轨迹的比较归纳（面向未来的 Markdown 文档，写清适用场景、推荐策略、禁止做法、例外、证据来源、最近验证时间）。这与 User-as-Code 同样是两阶段：先保存证据、再离线生成可变知识——避免一次偶发成功立即改变 agent。真正有迁移价值的内容来自对照：同类成功轨迹做了什么、失败轨迹缺了什么。自然语言反思（Reflexion）可参与生成候选教训，但反思本身不是证据；只有与环境结果相符、得到跨轨迹支持、并在新任务上显示正向迁移的内容，才进入正式文档。
将经验写成指令
知识库提供参考资料，Prompt 和 Skill 更有指令性。当多条轨迹反复揭示同一策略错误、且规律能用自然语言清楚表达时，就把它从“可参考的经验”提升为“应遵守的规则”——作用于几乎所有任务的进系统提示词，只在某领域生效的写成按需加载的 Skill。Karpathy 把这种范式称为系统提示学习（System Prompt Learning）：预训练学知识、微调塑习惯，但人类还有一种学习是遇到问题想通后用明确语言提醒未来的自己“下次这类问题先试这个办法”；它与强化学习都从经验改进行为，只是更新算法不同——前者编辑文字，后者用梯度下降改参数。落实到工程上，就是失败后把可语言化的教训写成候选规则——但不应反复重写整份提示，而应据一组同类失败生成最小 diff、注明作用域、检查与现有规则是否矛盾，再在触发失败的边界案例和旧任务保留集上同时评估（防止修好一个维度、回归另一个）。Skill 学习同理但更局部：候选 Skill 要说明何时加载、前置条件、步骤、已知陷阱、验证方法并保存来源；优先在已有 Skill 上做局部 patch，只有确实是新能力才建新目录，避免库里堆满名称不同、内容近似的手册。
将经验写成程序
当经验描述的是稳定、重复、可验证的操作时，每次让模型重读文档再推理并不经济——更合适的是把它编译为工作流、工具或 Harness 代码。可修改的对象远不止新工具：操作层可把浏览器轨迹编译为参数化工作流，控制层可改工具路由/重试/熔断/压缩策略，验证层可新增参数检查与回归测试，架构层可增加 Reviewer Agent。浏览器工作流是典型——像电子表格的宏录制：第一次发邮件时多模态 agent 从像素和 DOM 里摸索控件，之后同类任务只是收件人和内容不同，没必要再让模型从头发现整条路径。但流程记忆必须同时具备动作前验证、动作后验证、存前独立验证——否则很容易得到危险的假象：回放覆盖率 100%、每个按钮都点过，但某字段其实为空、任务从未真正完成。PreAct 报告这类程序在重复任务上有 8.5–13 倍加速。
Agent 修改自己的代码不意味着运行中的进程直接覆盖自身：应从稳定版创建候选分支、由 Coding Agent 生成最小补丁，依次过静态检查、单测、安全扫描、失败轨迹重放、旧任务回归，再灰度发布——把“自我修改”转成可审计的软件发布流程。每个修改请求还应是一份可证伪的变更契约：列出失败证据、推断根因、归属组件、候选修改、预期修复的行为、可能受损的既有行为、以及分别验证两者的用例。候选生成器的输入不应只有失败案例，还要给必须保留的成功行为和此前被拒的修改记录——避免它换个说法重复提交已失败的方案。
将经验写入参数，与优化的尺度
知识、指令、程序都建立在“能力能被外部符号较完整表达”的前提上。医疗影像理解、自然语音韵律、消除文本的“AI 味”、长程规划等高维能力很难压缩成规则或工作流，必须通过后训练（SFT / 偏好 / RL，见第 7 章）写入参数。关键是把经过评价的生产轨迹转化为训练数据（去隐私、过滤错误轨迹、保留独立回归集，训练后检查通用能力与安全对齐是否遗忘）。四种方式常协同：客服的自然语气来自后训练，具体企业政策由知识和 Skill 提供，关键合规由服务端代码兜底。
还有一条正交的轴：系统优化的是某份产物的内容，还是产生/管理这些产物的方法——优化尺度可逐层扩大（单条规则/记忆 → 结构化上下文 → 工作流 → Harness 代码 → 产生候选的优化器代码）。但层级并非越高越好：搜索一条局部规则只需少量边界案例，搜索完整 Harness 却面对更大的候选空间、更高评估成本和更严重的归因困难。明确、反复出现、能定位到单一组件的故障，应优先做可审计的局部补丁；只有局部修改长期解决不了跨组件问题，才上升到工作流/Harness 层。无论上升到哪层，评价器、权限边界、留出测试都必须位于可修改范围之外——搜索空间越大，这个可信根越重要。
工程实践
Zapvol 目前具备四种载体里的前三个的写入点，但自动化的经验学习管道尚未闭合（见进化闭环）：
- 知识——记忆系统的
feedback类型记忆正是“对做法的纠正/确认”，是行动经验的写入点；但从多条轨迹对照归纳出经验文档的离线管道是缺口。 - 指令——提示系统的 L1 支持数据库来的 Agent 自定义指令，Skills 支持按需加载；System Prompt Learning 式的“失败→最小 diff→回归”自动循环是缺口。
- 程序——工具以
ServerToolConfig承载确定性流程与约束；由轨迹触发的自我修改发布流程是缺口。 - 参数——模型后训练属 Ch7，不在 Zapvol 当前范围。
也就是说，Zapvol 有“把经验写到哪里”的四个位置，缺的是“由验证闭环自动决定写什么、并安全发布”的那一层。