PILOT：让AI智能体一边干活一边被人盯着改，而不是干完再挨批

你有没有遇到过这种情况：让一个新来的实习生做一个复杂项目，你选择完全放手，等他做完一周之后你才发现，他从第二天就走错了方向，后面的所有努力都是在错误的路上狂奔。

这不是一个假设。这恰恰是现在所有AI智能体（Agent）系统正在发生的事。

当AI智能体去执行一个需要几十步、甚至上百步操作的复杂任务，比如在终端里排查一个系统故障，或者修复一个大型代码仓库里的多语言bug，它会一步步试错、调整、再试错。这个过程会积累大量的经验，成功的路径值得被记住，走过的死胡同值得被标记出来避开。

问题是，几乎所有现有的"自我改进"方法，都是等这次任务彻底结束之后，才回头去总结经验。

这就带来一个很扎心的后果：这次任务哪怕走偏了，也没人能救它。经验只能留给下一次任务用，而这一次，已经废了。

一篇来自AllSpark团队的论文《PILOT in the Loop: Live Self-Improvement for Long-Horizon Agents》提出了一个新思路：为什么不能让自我改进变成"活的"，一边干活一边纠偏，而不是等干完了才复盘？

这篇论文提出的系统叫PILOT，在Terminal-Bench 2.0这个高难度基准测试上，一次性把性能拉高了最多9.8个百分点，在持续自我进化的场景下，更是让最好成绩提升了14.6个百分点。这个数字意味着什么，我们后面会慢慢拆开讲。

事后诸葛亮式的自我改进，到底差在哪

先说清楚一件事：AI智能体的"自我改进"不是什么新概念。

反思（Reflection）*：让AI在完成任务之后回顾自己的操作记录，找出哪里做得不对。

评判式评估（Judge-based evaluation）*：用另一个模型或规则去给最终结果打分。

自我进化的执行框架（Self-evolving harness）*：根据完成的任务轨迹和反馈，去修改提示词、技能库或者记忆内容。

这三种方法都有一个共同的特点，它们都是"验尸式"的，都发生在任务已经结束之后。

这样做的代价是什么？论文里讲得很直白：新提炼出来的知识，既没法帮上产生它的那次任务，也没法立刻被验证是否真的有效，只能留到下一次运行或者另一次单独评估里去试试看。

打个比方。你在健身房练深蹲，教练不在旁边看，你自己录了个视频，晚上回家复盘发现膝盖内扣了整整两周，这两周的训练全都是在错误姿势下加重量。如果教练当场就能看到你的动作并喊一声"膝盖往外顶"，你立刻就能纠正，而不是带着错误的肌肉记忆练了两周才发现问题。事后复盘能让你下次练得更好，但救不了这两周已经练废的动作。

那为什么不能一边执行一边纠正呢？论文指出，这里有一个架构上的死结。

现有的AI智能体架构大致分两种。第一种是单智能体自我纠错，就是同一个AI既执行任务，又要判断自己做得对不对。问题在于，它的注意力资源（也就是它能记住和处理的信息量，术语叫"上下文窗口"）是有限的。

上下文（Context）*：AI模型在生成回复时能够"看到"和参考的全部信息，包括之前的对话、执行记录、工具输出等，容量有限。

这就好比让一个正在开车的人同时兼职做导航员和交通安全监督员。他既要盯着方向盘、油门、周围车辆这些执行层面的细节，又要抽出脑力去判断"我是不是已经开错高速公路出口了"。执行细节会挤占本该用来做战略判断的脑容量，结果往往是，等他意识到走错路的时候，已经开出去二十公里了。

第二种架构是子智能体委托（subagent delegation），也就是主智能体把任务分派给一个子智能体去执行，自己等结果。这种做法确实把"干活"和"监督"分开了，但主智能体通常只有在子智能体彻底跑完之后，才能看到它的最终总结报告。

这就像你把一个任务外包给一个自由职业者，双方约定"做完发我"，中途你完全看不到进度，等收到成果的时候，如果方向错了，唯一能做的就是要求返工，而不是在他刚开始跑偏的那一刻就叫停。

论文把这两种架构的问题概括成一句话：现有架构没办法同时做到"实时纠偏"和"专职监督"这两件事。这就是PILOT要填补的空白。

PILOT怎么设计：监督者和执行者，分工不分家

PILOT的核心思路其实很朴素：把"干活的"和"看着干活的"彻底分成两个独立的角色，但让他们之间保持一条实时通话的热线。

论文里管这两个角色叫"监督者"（Supervisor）和"工作者"（Worker）*：工作者负责实际执行任务，比如敲命令、改代码；监督者不参与具体执行，专职盯着工作者的进展，判断要不要出手干预。

工作者在一个独立的上下文环境里干活，所有琐碎的试错细节、报错信息、死胡同，全部留在它自己的记忆空间里，不会污染监督者的视野。监督者的上下文里只保留任务目标、关键节点、最近发生的事，以及"这个方向是不是不对劲"这类判断所需的信息。

这套设计里有两个关键机制，一个叫实时引导（live steering），一个叫实时自我进化（live self-evolution）。我们一个一个讲。

实时引导：一条随时能插话的热线

实时引导机制的核心，是监督者和工作者之间维持着一条双向的"活线"。这条线上跑着五种信号。

工作者这边，会主动发出三种消息。第一种叫通知（Notification），工作者觉得该汇报进展了，就发个消息，发完继续干活，不用等回复。第二种叫提问（Question），工作者遇到需要监督者拍板的问题时，会暂停下来，直到得到回复才继续。第三种叫结果（Result），工作者彻底完成任务后，系统会自动把最终结果发给监督者。

监督者这边，可以主动做两件事。一种叫引导（Steer），监督者发现工作者当前的做法有问题，会去翻看工作者留下的相关执行记录，然后给出具体的纠正建议，插入到工作者下一步的行动里，当前这一步不会被打断，等它做完再接收新指令。另一种叫中止（Abort），如果监督者判断继续让这个工作者跑下去已经没有意义了，直接叫停。

这个设计解决的根本矛盾是什么？

是"及时性"和"清醒的判断力"之间的冲突。单智能体自纠错能做到及时，但判断力会被执行细节淹没；子智能体委托能保持判断力的清醒（因为不用亲自下场干活），但做不到及时（只能等结果）。PILOT把这两个优点同时拿到了，办法就是让监督者一直"在线"，但从不"下场"。

论文里举了两个真实的案例，特别能说明这套机制怎么起作用。

第一个案例是关于一个叫winning-avg-corewars的中等难度任务，工作者花了二十多分钟去调试一种叫DAT-clear的策略变体，反复实验，结果始终跟多个对手打平，一直达不到要求的胜率。监督者这时候插话了，说的是："别再测试那些合成对手了，彻底换个策略，去找一个已发表的成熟方案，拿它去打真正的五个对手。"工作者立刻接受了这个建议，转向使用一个叫Silk Warrior 1.3的公开经典方案，调整复制策略后，最终通过了全部五项阈值测试。

第二个案例更技术性一些，涉及一个叫torch-tensor-parallelism的高难度任务。工作者在实现一个叫RowParallelLinear的模块时，把偏置项（bias）加进了矩阵运算里，然后再做跨设备的求和归约（all_reduce），这个顺序错误导致偏置项被重复累加了好几倍。监督者发现问题后指出，偏置应该在归约操作之后再加，而不是之前。工作者认可了这个纠正，改完之后顺利通过了全部13项验证测试。

这两个案例的共同点是，监督者不是在事后指出"你之前错了"，而是在错误还没导致任务彻底失败之前，就把工作者从错误的路径上拽回来。

论文还做了一个很细致的统计分析：在Terminal-Bench 2.0的一次性测试里，人工检查所有成功的任务轨迹，统计有多少是真正靠这种实时纠偏才成功的。结果发现，简单任务里一次都没有出现（因为简单任务本来就在AI能力范围内，用不着外部纠偏），但在困难任务里，两个不同的模型分别有6.1%和19.7%的成功案例，是直接依靠监督者的实时干预才没有失败的。

这个数据挺说明问题的。任务越难，执行链条越长越脆弱，出错的机会越多，监督者能出手挽救的空间也就越大。反过来说，如果没有这套实时纠偏机制，这部分本可以成功的任务，很可能就直接失败了，而且是失败在没人看得见的中间某一步。

实时自我进化：把监督过程中学到的东西存下来

第二个机制解决的是另一个问题：这次监督学到的东西，怎么才能不白费，让下一次任务也受益？

论文把这套持久化的知识仓库叫做"框架"（Harness）*：包含技能库（Skill library）和记忆（Memory）两部分，会跨任务持续保存下来，供后续启动的工作者加载使用。

工作原理是这样的：当监督者在实时监督某个工作者的过程中，发现了一个值得沉淀的成功套路，或者一个反复出现的失败陷阱，它会把这个知识写进技能库或记忆里，形成一个更新过的框架版本。而这个更新，是在任务还没结束、还不知道最终成败之前就发生的，靠的是"这个操作看起来靠谱"这种直接判断，而不是等裁判打分之后才决定值不值得记录。

这里有个很关键的细节：论文的实验设计里，只有当一轮任务真正通过验证之后，这次任务里产生的知识更新才会被正式并入下一轮的共享框架；如果这次任务失败了，这些临时更新会被舍弃。也就是说，验证结果只用来筛选"哪些更新值得留下"，而不参与"要不要生成这个更新"的决策过程。

这套机制像什么？

有点像一个老木匠带徒弟。徒弟在做一件新家具的时候，师傅在旁边看着，发现徒弟琢磨出了一个巧妙的榫卯连接方式，当场就把这个手法记在师傅自己的笔记本里，不是等这件家具卖出去、顾客满意之后才补记。而且这个笔记本是所有徒弟共用的，下一个徒弟接手类似活计时，直接翻笔记本就能用上这个手法，不用再自己摸索一遍。如果不这样做，每个徒弟都得从零开始试错，同样的坑要踩很多遍，这就是没有这套机制时候的默认状态：经验困在了单次任务里，出不来。

实验怎么设计的：让AI在"复用经验"这件事上被真正考验

论文设计了两种评估场景，来分别检验这两个机制。

第一种叫一次性场景（one-shot setting），每个任务都从一个全新的、干净的框架状态开始，专门用来检验实时引导机制在单次任务执行中的效果，跟框架积累的历史知识无关。

第二种叫自我改进场景（self-improvement setting），把Terminal-Bench 2.0的全部任务组织成一轮又一轮的迭代，每一轮所有任务共享同一个框架状态，做完一轮之后，只有成功任务产生的知识更新会被合并进下一轮的共享框架里，然后所有智能体带着这个更新过的框架进入下一轮。这个设计是为了检验实时自我进化机制能不能真正把监督过程中积累的经验，变成对后续任务有用的知识。

论文选用了两个开源大模型作为测试的基础模型，分别是GLM-5.1和Kimi-K2.6，并且监督者和工作者用的是同一个模型，这样能确保比较的是"架构设计"带来的差异，而不是"模型能力差距"带来的差异。

对比的基准系统包括Pi（PILOT就是在这个框架基础上扩展出来的）、OpenCode、Terminus-2、Hermes等几个业内常见的单智能体框架，以及在代码修复任务上额外对比的Mini-SWE-Agent。

一次性场景下的结果

在Terminal-Bench 2.0上，PILOT在两个模型上都拿到了最高的一次性通过率：GLM-5.1上是71.9%，比排第二的OpenCode（66.9%）高出5.0个百分点；Kimi-K2.6上是71.3%，比排第二的Pi（66.9%）高出4.4个百分点。

|框架|GLM-5.1|Kimi-K2.6|两模型平均|

|Terminus-2|64.0|59.6|61.8|

|Hermes|60.1|64.0|62.1|

|OpenCode|66.9|64.6|65.8|

|Pi|65.7|66.9|66.3|

|**PILOT**|**71.9**|**71.3**|**71.6**|

在困难任务子集上，差距拉得更大：PILOT在两个模型上都拿到55.0%，比Pi分别高出5.0和6.7个百分点。这跟前面提到的实时干预数据是吻合的，难任务恰恰是监督机制发挥作用的主战场。

在软件工程类的两个基准（SWE-bench Multilingual和SWE-bench Pro）上，PILOT在SWE-bench Pro上以59.9%的平均分显著领先，比第二名Pi的55.5%高出4.4个百分点；在SWE-bench Multilingual上位列第二，跟第一名Pi非常接近。

综合六个"模型-基准"组合，PILOT拿了五个第一。

自我改进场景下的结果

这才是真正检验"活的自我改进"是否有效的地方。

跑了20轮迭代之后，PILOT在GLM-5.1上的最佳通过率从66.3%一路涨到80.9%，涨幅14.6个百分点；在Kimi-K2.6上从68.5%涨到80.9%，涨幅12.4个百分点。

而在同样条件下，也就是所有框架从同一个初始技能库出发、接受完全相同的任务输入的对比实验里，PILOT涨了14.6个百分点，OpenCode只涨了7.9个百分点，Pi只涨了2.3个百分点。

这个差距说明什么？说明单纯拥有一个可以存放技能的仓库，跟能不能真正把执行过程中的经验高效地转化成仓库内容，是两码事。PILOT因为有专职的监督者盯着执行过程去提炼知识，转化效率明显更高。

技能库本身也在实打实地变大：GLM-5.1对应的技能数量从62个涨到83个，Kimi-K2.6从50个涨到81个。这说明PILOT不是把每次任务当成孤立事件处理，而是真的在把执行经验持续沉淀成一个越来越丰富的可复用技能池。

更有意思的是效率指标。随着技能库的积累，每完成一个任务所需要生成的输出量（用token数衡量）显著下降：GLM-5.1从每任务平均2.85万个token降到1.63万个，降幅42.9%；Kimi-K2.6从4.19万降到2.21万，降幅47.4%。

而"每百万token能换来多少次成功评估"这个效率指标，反而涨了：GLM-5.1提升110.3%，Kimi-K2.6提升134.0%。

这组数据放在一起看特别说明问题。既省钱（token更少），又更容易成功（每单位成本的成功率更高），这背后的逻辑是，当一件事之前已经有人蹚过路，你不需要重新摸索，直接照着做就行，探索成本大幅下降了。

这就好比一个新手厨师第一次做红烧肉，得反复试火候、试调料比例，可能炒糊几次才摸出门道。但如果厨房里已经有一本详细写清楚"多大火候、几分钟翻面、糖色怎么炒不发苦"的笔记，第二次做同样的菜，速度快了，失败率也低了。PILOT做的事情，本质上就是让每个工作者不用重新当那个第一次做菜的新手。

按任务难度拆开看，性能提升也主要集中在难任务上：GLM-5.1在简单任务上只多通过了2个，中等难度多6个，困难任务多8个；Kimi-K2.6分别是1个、7个、12个。这个规律跟一次性场景下的观察是一致的，困难任务的执行链条更长，出错和积累经验的机会都更多，所以自我改进的收益也更大。

从这一整套数据来看，PILOT真正做到的，是把"这次任务的监督经验"和"下次任务的执行能力"用同一条时间线串起来了，不再是两件事后才发生联系的独立事件。

写在后面

读这篇论文的时候，有个细节让我停下来想了一会儿：监督者和工作者用的是同一个模型。

这意味着PILOT带来的性能提升，完全不是因为用了一个更聪明的模型去监督一个较笨的模型，而是纯粹的架构设计红利。同一个能力水平的AI，仅仅因为被拆成两个角色、分配了不同的注意力任务，整体表现就能提升好几个百分点。这个事实本身，比任何具体数字都更值得琢磨：很多时候限制我们的不是能力不够，而是同一份注意力被迫同时处理执行和判断这两件事，谁都做不精。

另一个值得单独说一说的地方，是论文对"什么才算真正被实时引导挽救的成功案例"的定义。他们没有简单地说"监督者插话之后任务通过了就算数"，而是要求必须证明监督者指出了具体错误、工作者确实采纳了这个建议、并且最终是沿着修正后的路径完成的，凡是干预被忽略、过时或者多余的情况，都被排除在外。这种较真的统计方式，让6.1%到19.7%这个区间的数字有了分量，不是一个可以随便注水的漂亮数据。

论文自己也坦承了局限：因为迭代式的自我改进要把每个任务重复跑很多轮，成本比单次推理高得多，所以目前的验证只覆盖了三个基准和两个开源模型，监督者和工作者也始终是同一个模型担任。如果换成能力更强的模型来当监督者，去指导一个能力较弱的执行模型，会发生什么？这个问题论文没有回答，留给了未来的工作。

Q&A

Q1：PILOT是什么？

A：PILOT是一个由监督者和工作者组成的双角色AI智能体系统，能在任务执行过程中实时纠正走偏的操作，并把过程中学到的有用经验实时存入可复用的技能库，供后续任务直接使用。

Q2：PILOT和普通的AI自我反思方法有什么区别？

A：普通反思方法都是等任务彻底结束后才总结经验，没法挽救正在进行的任务；PILOT让一个独立的监督角色全程盯着执行过程，能在任务还没失败之前就实时纠偏，并同步把经验写入知识库。

Q3：PILOT的效果具体好在哪里？

A：在Terminal-Bench 2.0上一次性通过率最高提升9.8个百分点；在持续自我改进场景下，最佳通过率提升12.4到14.6个百分点，同时输出成本下降超40%，成功率反而更高。