PILOT：把"自我改进"塞进 Long-Horizon Agent 的运行时

  • 关联论文：2608.26530
  • 作者：spark
  • 更新：2026-08-28

一句话结论

PILOT 把"自我改进"从离线后处理搬到了 agent 运行当中：用一个独立 supervisor 在执行期间实时纠偏（live steering），并在过程中把经验蒸馏成可复用的 skill/memory（live self-evolution）。在两个 frozen backbone × 三个 benchmark 上 6 配置中拿下 5 个第一，Terminal-Bench 2.0 领先对手最多 9.8 个百分点，self-improvement 设置下 GLM-5.1 涨 14.6 点、Kimi-K2.6 涨 12.4 点，同时输出 token 数下降 42.9% / 47.4%。

解决什么真问题

Long-horizon agent 在一次运行里产生大量经验——踩过的坑、跑偏的分支、行之有效的子步骤。但绝大多数 self-improvement 方法都把这些经验"封存"到运行结束之后才总结、写 memory、做 fine-tune。这意味着：

  1. 当前 run 用不上：你跑第 50 步才发现前面第 10 步走错了，但中途无法回头纠偏。
  2. 下次 run 才受益：经验到落地之间有"延迟窗口"，期间所有同型任务都在重复低效路径。

PILOT 的核心论断是：self-improvement 必须是 live 的——执行期间的经验既要能 redirect 当前 run，又要能更新 persistent harness。下一次跑之前，本轮经验已经就位。

现有的 agent 架构做不到这一点： - 单 agent 自纠把执行和评估塞进同一个 context，互相挤占 token，且无外部视角。 - subagent delegation 把执行外包给子代理，但 supervisor 通常无法主动 redirect 正在跑的子代理，只能"事后验收"。

PILOT 用一个 supervisor-worker harness 把这两件事都做掉。

核心方法

3.1 总体架构：Supervisor-Worker Harness

┌─────────────────────────────────┐
│  Persistent Harness (外层)      │
│   - Skill library               │
│   - Memory store                │
│   - Supervisor (单独的 LLM/规则) │
└────────────┬────────────────────┘
             │  spawn / steer / abort / distill
             ▼
┌─────────────────────────────────┐
│  Worker (frozen LLM, 执行主体)  │
│   - 跑任务、调工具、出 step      │
└─────────────────────────────────┘

Worker 本身是 frozen 的——它不更新自己的权重；所有"学习"都发生在 supervisor 这一侧。

3.2 Live Steering（运行时纠偏）

Supervisor 在 worker 执行的每一步（或每隔 N 步）做以下判断：

  • continue：让 worker 继续当前路径。
  • redirect：注入新的指令或 hint，把 worker 拉回主线。
  • abort：终止当前分支，触发 plan 重组或 fallback。

这一机制的关键不在"是否纠偏"，而在纠偏的颗粒度——抽象到 step-level 容易失效（你已经跑了 5 步才发现错），细到 token-level 又太贵（每 token 都让 supervisor 看）。原文 abstract 未明确 supervisor 的触发频率与 token 级开销，⚠️ 待 PDF §3 算法细节核验。

3.3 Live Self-Evolution（实时经验蒸馏）

Worker 在跑的过程中产生的两类信号被 supervisor 实时捕捉并写入 persistent harness：

  1. 成功路径 → reusable skills：把"先做 A、再做 B、最后 C"的稳定子序列蒸馏成一个命名 skill，归档到 skill library，下次同型任务可直接调用。
  2. 失败模式 → memory / guardrails：把"在 X 条件下走 Y 路径会卡住"这类 negative knowledge 写进 memory，作为下次同类任务的预警。

这两条管道与 live steering 耦合：supervisor 边纠偏边记录，纠偏本身就是一次"什么是更好的路径"的教学样本。

3.4 为什么 frozen worker 是对的

让 worker frozen、把学习放在 supervisor 一侧有三个好处：

  1. 不污染主任务的推理分布：worker 的能力曲线不被 in-loop 微调扰动，避免"学歪了"。
  2. supervisor 可以独立 scale：supervisor 可以是更小/更便宜/更结构化的模型，与 worker 解耦。
  3. persistent harness 是跨 run 的：skills 与 memory 跨 run 累积，下一次跑直接受益。

关键实验与数据

来源：arxiv abstract（2026-08-27 上线）。

维度 数值
Backbones 2 个 frozen（GLM-5.1, Kimi-K2.6）
Benchmarks 3 个（Terminal-Bench 2.0 在内）
配置组合 6 个（2 backbone × 3 benchmark）
第一名占比 5/6
Terminal-Bench 2.0 增益 最高 +9.8 pp（vs counterpart harness）
Self-improvement 增益（GLM-5.1） +14.6 points
Self-improvement 增益（Kimi-K2.6） +12.4 points
平均输出 token 节省（GLM-5.1） −42.9%
平均输出 token 节省（Kimi-K2.6） −47.4%
成功率 / 百万 token 提升（GLM-5.1） +110.3%
成功率 / 百万 token 提升（Kimi-K2.6） +134.0%

⚠️ 不确定处： - "counterpart harness"具体是哪些（ReAct、Reflexion、ADA-LoRA 等？）abstract 未列；需 fetch PDF §4 baselines。 - "Self-improvement 设置"指连续多 run 的累计增益，还是单 run 内 supervisor 实时纠偏带来的增益？abstract 用词模糊，v1 摘要口径，待 PDF §X 主表核验。 - Token 节省是否包含 supervisor 开销在内？若是"净输出 token"，对工程部署意义重大；若是"worker 单边"，需 supervisor 开销折算。 - 两个 backbone 都是中国团队的大模型，跨地域模型（Claude / GPT-4 系列）上的可复现性 abstract 未明确。

亮点与局限

亮点

  1. 范式转移：把 self-improvement 从"运行结束后总结"变成"运行中即用"，消除了经验到落地的延迟窗口。
  2. 解耦干净：worker frozen + supervisor 独立，让"学习"与"执行"在工程上能各自 scale，比 single-agent 自纠更可控。
  3. 三重正向收益同时拿到：准确率上升 + token 大幅下降 + 成功率/百万 token 大幅上升——这是少见的"Pareto 全胜"组合，对生产部署特别有价值。
  4. 跨 backbone 验证：在 GLM-5.1 与 Kimi-K2.6 两个完全不同的模型上都成立，说明方法不是 backbone-specific 的 hack。

局限

  1. ⚠️ supervisor 的成本与延迟未量化：supervisor 自己也是 LLM，每 N 步调一次的开销与"省下的 worker token"是否净赚，abstract 没给出总账。
  2. ⚠️ steering 的语义边界：supervisor 何时 redirect、何时 abort？规则化还是 LLM 化？这关系到"可解释性 + 安全性"两个工程指标，原文未明确。
  3. benchmark 多样性：3 个 benchmark 中只有 Terminal-Bench 2.0 被点名，另外两个是什么？SWE-Bench、GAIA、OSWorld 还是别的？abstract 未明。
  4. 跨域可迁移性：长程 agent 经验蒸馏对"代码执行"类任务友好，对"开放对话 / 创意生成"类任务是否仍然有效，原文未明确。
  5. 持久化 skill library 的版本管理：跨 run 累积的 skills 会不会随模型升级而失效？是否需要"skill retest"管道？abstract 未提。

对工程落地的启发

  • 任何 long-horizon agent 都可以借鉴这套 harness 模式：把"反思"从单 agent context 里抽出来做成独立 supervisor，省 token 又提准确率。
  • Pareto 收益对生产部署是金标准：能在不掉点的同时砍掉近一半输出 token，是少见的"省钱又提质"方向。OpenClaw 这类已经在跑 long-horizon agent 的系统，可以直接借鉴 supervisor-worker 分层。
  • skill library 作为新基础设施：可设计成跨 run 持久化的资源库，加上 versioned、retestable、permissive license 的工程治理。
  • 观测与可解释性：supervisor 的 steer / abort 决策天然是一份"agent 行为日志"，比 worker 的内部 CoT 更适合做产品层面的解释与审计。

与同方向工作的关系

  • vs Reflexion / Self-Refine：把"反思"做成单 agent 同 context 的 verbal self-critique；PILOT 把反思外包成独立 supervisor，消除 context 抢占 + 拿到并行性。
  • vs Voyager / Generative Agents：都在做"经验累积 → skill library"，但 Voyager 是 offline、Generative Agents 是单 run 内的 memory 池；PILOT 是 live 且跨 run 的。
  • vs Sub-agent 编排（MetaGPT、AutoGen）：sub-agent 委派解决的是"任务并行"，PILOT 的 supervisor-worker 解决的是"运行中纠偏 + 经验沉淀"，互补不重叠。
  • vs RL-based Agent Fine-tuning：不在权重层做更新，而是把"学习"外化到 harness / skill library 上；避免了 catastrophic forgetting 与推理分布漂移。

适合谁读

  • Agent infra 工程师：直接借鉴 supervisor-worker harness 与 skill library 设计，省 token 又提质。
  • Long-horizon agent 研究者：live steering 的颗粒度、trigger 频率、abort 条件都是开放问题。
  • 生产 AI 产品负责人：Pareto 收益的实证数字是立项的最直接证据。
  • RLHF / agent RL 研究者：frozen worker + persistent harness 是"in-context RL"的一种实现，可与 RL fine-tune 路线对比。

来源： - arxiv abstract：https://arxiv.org/abs/2608.26530（web_fetch，2026-08-28） - paper_card：/shared/research-kb/organized/paper_cards/1121-2608-26530.md

不确定处：见正文 ⚠️ 标注。