Agent Optimizer：不训练模型，而是优化经验与策略

我们讨论 Agent 优化时，一个问题很快出现了：Agent 变强，是不是一定要重新训练模型？我当时越来越倾向于认为，不一定。

Model
 +
Experience
 +
Policy
 +
Tool Routine
 +
Evaluation

模型权重只是其中的一层。

一、把 Agent 和模型分开

模型变弱
 ↓
Fine-tuning / RL
 ↓
模型变强

另一条路径：
Task → Experience → Retrieval / Reflection → Policy Adjustment → Next Action

这里并没有修改 LLM 的参数。优化的是 Agent 如何利用已经发生过的经验，以及下一次面对类似任务时采取什么策略。这也是我们讨论 Local RL Optimizer 时形成的一个方向：把优化器放在模型之外，让它优化策略，而不是直接修改 LLM weights。

二、经验可以成为 Agent 的外部参数

Task
 ↓
Trajectory
 ↓
Outcome
 ↓
Critique
 ↓
Case / Experience Memory

一次执行产生的轨迹不应该只是日志。它可以成为下一次 Agent 决策时能够使用的经验。

三、JitRL 给我的一个启发

我们讨论过 ICLR 2026 的 JitRL。它让我注意到一个方向：不改变模型梯度，也可以通过非参数化的经验记忆来估计行动的价值。

当前任务
   ↓
寻找相似历史轨迹
   ↓
比较历史 Action 的结果
   ↓
估计 Action Advantage
   ↓
帮助当前决策

这里的意义不只是降低训练成本，也让我开始把 Agent Optimizer 看成一个独立系统。

四、EvoTest：执行本身成为改进输入

Actor
 ↓
执行任务
 ↓
Transcript
 ↓
Evolver
 ↓
分析问题
 ↓
Prompt / State / Tool Routine
 ↓
下一轮 Actor

这和“重新训练一个模型”是不同的工程路径。它优化的是 Agent 的行为程序：Prompt、Persistent Memory、State、Tool Call Routine 和 Execution Strategy。

五、Prompt Evolution 说明了另一种优化对象

我们还聊过 DSPy 生态和 GEPA（Reflective Prompt Evolution）。这里让我关注的不是某一个 benchmark，而是它体现出的方向：优化对象不一定是模型参数，也可以是模型周围的程序。

LLM + Prompt + Tools + Memory + Policy + Evaluation

如果把 Agent 看成这个整体，那么真正需要优化的可能是整个行为程序，而不是只有 LLM。

六、Optimizer 最危险的问题：错误的评价信号

API PASS
12 tests passed
outcome.ok = true

        ↓

用户：问题没有解决

如果 Optimizer 只相信前面的信号，它就会把这个失败案例当成成功案例继续学习。

错误 Proxy
    ↓
Optimizer
    ↓
更强的策略
    ↓
更高的 Proxy 分数
    ↓
更大的 Real Outcome 偏差

因此 Optimizer 的第一步不是“怎么优化”，而是先回答：这个成功信号是真的吗？

七、Case Memory 应该成为 Optimizer 的第一层

Tier 1
Case / Experience Memory

Task
Critique
Trajectory
Outcome
Ground Truth Status
Cost

        ↓
Decision Layer
        ↓
Prompt / Policy / Tool Routine
        ↓
Agent

这些 Case 可以被向量化，用于寻找相似问题；上面再放一个轻量的 Decision Layer。这样比一开始就重新训练一个模型更轻，也更容易观察究竟是什么发生了变化。

这一层我先做成了一个很薄的实现：llm-trace-reuse（站内：Projects）。不改模型权重，只在任务开始时路由：命中 playbook 就走手册，能复用上次的 preferred_path 就不要重新规划。它还没有完整的 Ground Truth，所以 outcome.ok 仍然可能只是 Proxy。

八、Task Fingerprint 连接经验与任务

如果所有历史经验只是一个巨大的向量库，那么相似度本身并不足够。我们讨论过 task_fingerprint：它试图描述问题类型、失败模式、所需能力以及过去什么策略有效。

“和它长得像”
        ↓
“属于同一种问题，因此某种策略可能有效”

九、Optimizer 真正优化的可能是“下一次怎么做”

                 Agent Optimizer
                        │
        ┌───────────────┼───────────────┐
        ↓               ↓               ↓
   Experience       Policy          Tool Routine
     Memory        Adjustment         Tuning
        │               │               │
        └───────────────┼───────────────┘
                        ↓
                     Agent
                        ↓
                    Outcome
                        ↓
                   Evaluation
                        ↓
                     Memory
                        ↺

它优化的不是“模型知道多少”，而是：面对一个任务，Agent 下一次应该怎么做。

十、为什么这条路线可能更适合 Agent

Agent 的任务分布可能一直变化。如果每遇到一种新情况都重新训练模型，周期和成本都很高，也很难知道究竟是什么改变了模型行为。

新问题
 ↓
执行
 ↓
得到经验
 ↓
验证结果
 ↓
写入 Case Memory
 ↓
下一次相似任务直接利用

Agent 可以形成一种轻量的持续改进机制：不是让模型本身不断变化，而是让模型周围的系统不断积累经验。

十一、这不意味着永远不要训练模型

我并不认为经验记忆和策略优化可以替代模型训练。更合理的理解是，它们处在不同层次：

Model Training
    ↓
基础能力

Agent Optimizer
    ↓
任务策略 / 经验 / 工具使用方式 / 行为程序

Runtime / Control Plane
    ↓
执行与治理

十二、最终形成一个持续学习的 Loop

Goal
 ↓
Agent
 ↓
Action
 ↓
Environment
 ↓
Outcome
 ↓
Evaluation
 ↓
Experience
 ↓
Optimizer
 ↓
Policy / Memory / Tool Routine
 ↓
Next Agent
 ↺

这里最重要的不是“自动优化”四个字，而是：经验不会只留在日志里，而是成为下一次决策的一部分。

所以 Agent 的持续进化未必首先表现为模型参数发生变化，也可能表现为经验越来越丰富、策略越来越稳定、工具调用越来越合理、失败模式越来越少。

而整个系统真正需要解决的，仍然是另一个问题：Optimizer 到底应该相信什么结果？ 评测怎么接到优化器，见 Agent 的评价：Proxy Metric ≠ Real Outcome。