学习与自进化

订单调查第一次遇到支付回调延迟时，可能需要多次查询和人工解释。下次遇到类似情况，系统能否少走弯路，又不把上次的偶然原因套到所有订单上？这就是运行时经验改进要解决的问题。

“学习”需要说明改变了什么、对谁生效、凭什么认为更好。 本文讨论上下文、经验和策略配置的改进，不展开模型权重训练。固定配置也可以完成有价值的任务；是否引入自动学习，应由重复问题和可验证收益决定。

1. 三个时间尺度对应三种改动范围

为与自主性 A1–A4、记忆 M1–M4 区分，本文使用 T1–T3 表示学习时间尺度。这是本系列的组织方式，不是行业统一标准。

尺度	改变什么	订单调查示例	生效范围
T1 会话内适应	当前上下文与工作状态	用户补充“支付已成功，请查履约记录”	当前运行或加载这份上下文的会话
T2 跨会话经验	经过筛选的持久记录与示例	保存某版本接口的状态含义与已验证查询方法	获准检索且满足适用条件的任务
T3 跨版本策略改进	提示模板、工具描述或执行策略	调整未知支付结果的处理流程	使用新配置版本的运行

T1 不更新模型权重。它能否跨会话出现，取决于应用是否持久化并重新加载上下文，不能断言会话一结束就必然清零；它也有上下文管理、权限隔离和推理成本。

T2 是记忆系统的一种用途，保存的是带适用条件的建议与证据。T3 将经验用于候选配置改进，需要独立评测和发布过程。三者可以配合，也可以只采用其中一部分。

Reflexion 展示了利用语言反馈和情景记忆影响后续尝试的方法；这说明改进不一定需要更新模型权重，不代表任意自动总结都能提高表现。Reflexion 论文

2. 从运行记录中提炼候选，不直接制造规则

假设支付接口返回超时，Agent 随后查询交易记录并确认已支付。可提炼的经验是“超时不能等同于未支付，应按操作标识查询”，而不是“支付超时一定是回调延迟”。

经验需要区分观察事实、已确认原因和推测。保留动作、输入条件、实际结果与必要的简短决策说明，不要求采集模型隐藏推理过程。

下面是说明性记录：

{
  "experience_id": "payment-timeout-lookup",
  "status": "candidate",
  "kind": "recovery_pattern",
  "scope": {
    "tenant_id": "tenant-demo",
    "task_kind": "order-investigation"
  },
  "applies_to": {
    "tool_contract": "payment-query-v2",
    "condition": "查询超时，业务结果尚未确认"
  },
  "recommendation": "保留未知状态，按获准的查询路径核对交易记录",
  "evidence_refs": ["trace-demo-014"],
  "unresolved": ["该次超时的根因"],
  "policy_version": "policy-v2"
}

一次成功可以成为候选，不能自动成为全局最佳方法。失败案例也并非天然比成功案例重要：它们各自帮助理解失败条件和可行路径，需要依据影响、复现性和证据质量选择。

工具序列哈希可用于精确去重，但普通哈希距离没有语义相似度含义。若要识别相似路径，应使用结构比较或适当表示，并检查输入条件、动作副作用和执行结果。

3. 入库先检查权限、证据和适用范围

经验检索前就应限制租户、用户范围、任务类型、工具版本与当前可用状态。不能先做全库向量搜索，再把未授权记录交给模型筛选；相似度也不能扩大访问范围。

入库与更新重点包括：

检查	处理
来源是否合法且可追溯	无来源或不允许复用的材料不进入正式经验库
结论是否被证据支持	未确认原因保留为假设，不写成事实
适用条件是否明确	保留用户偏好、任务模式与全局策略的区别
是否存在冲突	核对时间、范围与版本，必要时并存或替换旧版本
是否真正重复	同时比较含义和条件，相似度只提供候选
是否建议越权行为	隔离候选，由可信策略与审核流程处理

“包含两个以上具体实体就不能泛化”不成立，具体记录也可能是可复现证据；个体偏好更不需要推广到所有用户才有保存价值。把用户范围写成 None 也不应自动解释为全局共享，公开范围需要明确授权。

旧经验评分高不能成为拒绝新证据的唯一理由。新旧建议相反，可能是接口版本变更，也可能是过去的结论错了。不同 kind 的记录同样可能冲突，例如“少做查询”的偏好不能覆盖“缺少必要证据就不能判断”的要求。

4. 记录有帮助的次数，也保留统计条件

在固定任务范围内，可以用简单的 Beta–Bernoulli 模型维护“被评为有帮助”的后验均值。使用 Beta(1,1) 先验时：

def helpfulness_posterior(helpful, unhelpful):
    for count in (helpful, unhelpful):
        if type(count) is not int or count < 0:
            raise ValueError("counts must be nonnegative integers")
    return {
        "mean": (helpful + 1) / (helpful + unhelpful + 2),
        "observations": helpful + unhelpful,
    }

没有观察时均值为 0.5，只表示所选先验，不能宣称这条经验有 50% 的成功率。先验伪计数也不计入实际 observations。

这个模型假设评价可视为同一稳定过程的伯努利观察。现实中，检索选择偏差、重复用户和模型评审错误可能破坏假设；“任务成功”也不证明成功由这条经验造成。因此还要保存版本、标注依据、反例和样本分布，不能只按一个均值自动推广。

失效处理也不能只按时间衰减。权限撤销、工具下线或关键反例出现时，可以立即停用；不常用但仍有效的规则不应只因半年未命中就被遗忘。软删除与真实的数据清除、缓存失效是不同操作，需要分别完成。

5. 动态 Few-shot 先筛选，再在预算内选择

动态示例的价值是为当前任务提供相近且有效的参考。完整顺序应是：

根据认证身份、任务与版本过滤可用经验。
检索相关候选，并检查结果质量与证据。
按相关性、适用性和多样性排序。
在实际 token 预算内选择示例，保留必要输入与结果。
记录本次使用的经验 ID 与版本，观察其效果。

语义相似度阈值取决于嵌入模型和语料，没有通用的 0.85 即“基本相同”。用固定阈值去除相近示例是启发式去重，也不能直接称为完整的 MMR 优化。

最近被使用不等于内容最新。若用 last_used_at 作为新鲜度，会持续强化已经流行的经验，让少被检索的有效记录更难出现。应区分验证时间、资料版本与使用热度。

动态示例是参考材料，不应被拼接成高优先级权限指令。比较收益时至少设置固定示例、动态示例和不使用示例的基线，观察新增上下文成本与目标任务表现。

6. 策略优化把候选生成与部署分开

DSPy 与 OPRO 等工作研究了以指标和示例驱动语言模型程序或提示的优化。它们提供候选搜索与选择思路，实际效果仍由任务、指标和评测方法决定。DSPy 论文、OPRO 论文

在订单调查中，一轮改进可以这样开展：从超时案例提出候选提示，在调优集上筛选，再用未参与选择的评测集和安全回归检查，最后进行受控灰度。反复使用同一份测试集挑最佳候选会对测试集过拟合，候选越多越需要独立验证。

样本量由预期效果、方差、显著性和检验功效决定，不能固定写成“Agent 必须 500–1000 条”。同样，“最多改三处”“每周只能更新一次”只是可能的流程参数，不能保证行为变化小。一次词语修改也可能改变工具选择。

下面只演示如何构造独立的候选配置对象，避免浅拷贝连带修改当前版本：

from copy import deepcopy

EDITABLE_SECTIONS = frozenset({"task_guidance", "examples"})

def propose_sections(current, changes):
    if not isinstance(changes, dict):
        raise ValueError("changes must be an object")
    if any(key not in EDITABLE_SECTIONS for key in changes):
        raise ValueError("section is not editable")
    if any(not isinstance(value, str) for value in changes.values()):
        raise ValueError("section content must be text")
    candidate = deepcopy(current)
    candidate["sections"].update(changes)
    return candidate

它检查可改字段，不检查新文本的全部语义，也不负责发布。权限、数据范围和工具执行政策仍由外部服务强制执行，不能靠把安全段落放进“不可修改 prompt”就宣称边界牢固。

优化器与执行器可以相同，也可以不同，需通过评测选择。换模型不保证消除偏差；把改动移到工具描述也不天然更安全，因为描述会影响是否调用、怎样传参和怎样理解结果。

7. 偏好记忆应尊重用户表达的范围

用户说“这次短一点”，作用于当前回答；说“以后订单报告都先列异常”，才表达了更长期、更明确的范围。显式表达通常比隐式推断更有依据，但也要区分临时要求和长期偏好。

多次删减答案可能意味着偏好简洁，也可能是答案重复或错误。重复行为提供线索，不能单靠编辑长度和次数推导原因。应用推测的偏好时应保持可查看、可纠正、可删除，并避免改变必要事实或任务要求。

新要求不一定覆盖所有旧偏好。按用户、场景和有效时间保存，当前明确指令优先于不匹配的历史推断。用户在一次任务中批准的外发动作，更不能被学习成以后的永久授权。

8. 学习优化策略，权限变更走独立控制流程

系统可以自动提出新工具、新宏或配置建议，但建议本身不能授予新权限。已有工具的组合也可能扩大实际影响，例如连续批量操作超出单次允许范围，因此组合需要独立验收。

可由学习过程提出	必须由可信控制面决定
哪个查询顺序可能更有效	允许访问哪些数据和工具
哪个示例更适合当前任务	经验是否可以跨用户或租户共享
哪种格式更易阅读	对外发送是否需要审批
怎样减少重复操作	新工具及其权限是否上线

安全策略可以通过授权的工程流程改进，并非永远不能改变；关键是运行中的学习组件不能自行扩大权限。英文关键词黑名单也不是有效的权限证明，换一种表达就可能绕过，最终需要执行层限制和策略测试。

只保留成功案例属于选择偏差，优化代理评分而偏离真实目标属于目标错配，二者不能混成同一个概念。应同时检查成功与失败、覆盖范围和实际业务效果，避免把更长的回答或更多工具调用当成能力提高。

9. 用保留能力与新增收益衡量学习

评估改进时，先固定任务、工具和计费条件，再比较：

指标	解释
新场景增益	未参与调优的目标任务表现变化
旧场景回归	原有任务是否退化，哪些群体受到影响
适应效率	达到约定表现需要多少交互、费用与时间
经验贡献	使用经验与不用经验的对照差异
边界保持	权限、隐私与必要审批是否仍生效

“新场景成功率 / 训练场景成功率”会受两组任务难度影响，不宜直接命名为泛化能力。评分也不必全部由 LLM Judge 给出：结构化结果、工具状态和业务不变量可以用确定性检查。

提示词变化导致的旧任务退化，与权重训练中的灾难性遗忘是相关的工程类比，不是同一机制。回归集只能覆盖已纳入的案例，不能宣称验证了所有已知能力；线上仍需要分组监测和异常回滚。

跨版本改进的发布方式按后果和授权决定。高影响变更可以要求人审，已有明确授权的低风险配置可在自动门禁内发布；不必把所有 T3 改动都定义为影响全量用户。版本分配、观察窗口和回退方案应与实际影响范围一致。

这类学习的价值在于，把运行中的证据转成可检验的改进。经验库、候选生成与评测流水线逐步成熟后，多个 Agent 才能复用成果，同时保留各自的数据和权限边界。下一篇把这些能力组织成共享平台。