观察

先自我改进的,可能不是模型本身

Lilian Weng 这篇文章讲的是一个很容易被低估的判断:近期 AI 的自我改进,未必首先发生在模型权重里,而更可能发生在模型外面的 harness 里。

harness 很难用一个中文词完全盖住。它不是单纯的 prompt,也不是传统意义上的 agent 框架。更准确地说,它是包在 base model 外面的运行系统:怎么给任务、怎么组织上下文、怎么调用工具、怎么存文件、怎么开子进程、怎么评估结果、怎么从失败里更新下一轮策略。模型本身像发动机,harness 则像变速箱、仪表盘、道路规则和维修手册的组合。

这件事重要,是因为我们常把“AI 自我改进”想象成模型直接改写自己的神经网络权重。但工程上更近的一条路是:模型先学会改进自己周围的工作方式。它不必先变成更大的模型,也可以通过更好的 workflow、更干净的上下文、更可靠的工具调用、更持久的文件记忆、更严格的 eval,让同一个 base model 做出更好的结果。

这也是 coding agent 最近让人感觉变化很快的原因之一。Claude Code、Codex 这类系统的能力,不只来自模型本身,也来自它们拥有一个越来越像软件运行时的 harness:能读文件、改文件、跑测试、看日志、维护计划、等待后台任务、恢复中断状态。模型不再只是一次性回答问题,而是在一个可观察、可执行、可回滚的环境里工作。

Lilian 把 harness 的设计模式分成几类:workflow automation、file system as persistent memory、sub-agent and backend jobs。看起来都很朴素,但它们合在一起改变了模型的有效认知边界。上下文窗口再长,也不该承担所有记忆;真正长程的 agent 应该把状态沉到文件、日志、实验结果和可复用 artifacts 里。智能不只在模型参数中,也分布在模型与外部状态的接口上。

我觉得文章最有洞见的一点,是把 harness engineering 看成 meta-methodology:优化的对象不再只是“这一次怎么答得更好”,而是“如何构造一个系统,让下一次更容易答好”。这个层级一变,很多工作就连起来了:context engineering、workflow search、self-harness、evolutionary program search、auto-research,本质上都在优化模型周围的认知机器。

这也解释了为什么 SkillOS 这类工作值得重视。SkillOS 没有更新执行模型的权重,而是训练一个 skill curator,让它从任务轨迹里新增、更新、删除 Markdown 技能。换句话说,它优化的是 harness 里的记忆和技能管理层。执行者还是那个执行者,但它周围多了一套会复盘、会归档、会扔掉坏经验的系统。

从这个角度看,SkillOS 不是孤立的 agent memory 论文,而是 harness-level self-improvement 的一个具体样本:

任务轨迹
  -> 复盘与提炼
  -> 技能库更新
  -> 下一次执行更好

这条链路还很粗糙。技能检索可能浅,错误经验可能中毒,workflow 可能过度手工,eval 可能不可靠。但它指向的方向很清楚:自我改进不一定从“模型改自己”开始,也可以从“模型改自己的工作环境”开始。

这甚至可能是更自然的路径。人类做复杂工作时,也不是每次都靠大脑突变来变聪明;我们写笔记、改流程、造工具、沉淀 checklist、复用脚本、建立团队协作方式。个体能力之外,还有一整套外部认知结构在累积。AI agent 的 harness,正在变成类似的东西。

所以我读完这篇文章后的判断是:未来一段时间,AI 能力进步的关键观察点,不应只盯模型 benchmark,也要盯 harness benchmark。谁能更好地管理上下文,谁能更可靠地从失败中更新 workflow,谁能把经验压缩成可复用技能,谁就可能让同一个模型释放出不同数量级的有效能力。

参考

为什么写这个笔记本

2023 年之前我在这里写的大多是工程笔记。从现在起,这个流用来记录智能革命早期的短观察—— 那些我更想立刻记下、免得日后被后见之明冲淡的半成形想法。更长的文章仍然放在 文章 里。

(这是一条示例,随时可以编辑或删除,然后开始写。)

ChatGPT 之前:我的一段大模型经历

回顾一下 ChatGPT 之前,我参与大模型研发的那段日子。

我们最早是和北京智源人工智能研究院(BAAI)合作做大模型的。那时 GPT-3 刚刚出来,北京市随即立了一个大项目,要做自己的大模型,参与的主要有清华唐杰、孙茂松老师团队,以及人民大学文继荣老师团队。项目一共四个方向:面向中文的预训练大模型、融入知识的大模型、多模态大模型,以及蛋白质序列大模型。

文老师负责多模态方向,后来推出了悟道·文澜大模型。我在其中带的是一个创新中心,从 2020 年年中起步,目标很具体:做一个”个人智能信息助手”。我们以智能信息检索与挖掘为基础,在智能搜索、问答系统、对话机器人这几个方向上打技术底座,再把成果往产品上推——落地的重点场景之一是政务服务,想让普通人查询、办理政务事项时能更省力一些。现在看只是初步的尝试,但在当年,这是一个相当硬的挑战。

当年 WIRED 就这个项目做过一篇报道,其中也提到了我们这条线:

“This is a big project,” Wen says with a big grin. “It takes a lot of computing infrastructure and money.” … Wen says his language system could serve as an intelligent assistant to help citizens perform civic tasks online … Zhanliang Liu, project lead for the effort and previously an engineer at Baidu … says his team has built a prototype [for one such government service]. “It is a really tough challenge,” he says.

火车最初也跑不过马车

用 GPT 和 GitHub Copilot 写代码已经大半年,却还常看到有人在争论:AI 到底能不能写代码。

代码确实还不完美。但别忘了,火车最初也跑不过马车。一项新技术起步时有多笨拙,几乎从不预示它最终能到达的高度。

这也让我想起 Douglas Adams 的那段话(出自《The Salmon of Doubt》):

任何在我出生时已经有的科技都是稀松平常的;任何在我 15 到 35 岁之间诞生的科技都是改变世界的革命性产物;任何在我 35 岁之后诞生的科技都是违反自然规律、要遭天谴的。

我们对一项技术的判断,往往不取决于它本身,而取决于它出现时我们的年纪。

端倪:MRC、UIE,与我们错过的那一步

回头看,用 QA/MRC(机器阅读理解)来做各种 NLP 任务,在当年是小火过一把的——有多火,可以参考复旦邱锡鹏、黄萱菁老师团队那篇 Paradigm Shift in Natural Language Processing。但多数人,包括我,只是把这个范式套到自己关心的任务上,然后窃喜于:这么简单的配方,竟然如此有效,甚至吊打 SOTA。

反观 GPT 的作者,他们敏锐地看到:互联网数据里本就散落着大量的任务描述。于是,基于对并行计算友好的 Transformer 架构,用 next-token 预测这个最朴素的语言模型目标,暴力刷互联网数据——竟一步步做成了真正的 NLP 大一统模型,直到初步建起那座巴别塔。云泥之别。

其实,把 NLU 当作 QA 来做、把信息抽取统一成 text-to-structure(UIE),都已经露出了 LLM 的端倪。只是我们没敢再往前多想几步——差的不是技术,是想象力,和胆识。

这一点我自己尤其有体会:2020 年我带队参加第八届 CCF 大数据与计算智能大赛(BDCI),凭一套 MRC 的打法拿了三等奖和”产业应用潜力”奖(51CTO 的报道)。离那层窗户纸并不远,却终究没能捅破。