怎样把真实需求变成智能体的进化方向？

递归自我改进最诱人的地方，是把“让智能体变好”这份工作也交给智能体。它发现缺点，修改自己的方法，再用更好的方法发现下一处缺点。这个循环似乎一旦转起来，就有了不断加速的可能。但在第一次修改之前，我们得先给它一个方向：什么变化，算是变好了？

写出更长的反思，增加一个规划步骤，换一套听起来更成熟的提示词，都很容易。可用户想要的可能只是：把一份表格整理好，保留原来的公式，别弄坏另一张工作表。自进化的方向，要从这些真实要求里长出来。我们需要把工作做成可以重新开始、允许不同做法、又能判断结果的任务。评测集在这里开始承担一种更有意思的角色：它规定了这个系统准备学会怎样的生活。

把一台真正的电脑装进考场

OSWorld 做了一件很直接的事：让智能体使用真正的操作系统和应用。表格交给 LibreOffice，网页交给 Chrome，文件留在文件系统里。智能体看到屏幕，操作鼠标键盘，改变的是软件实际保存的状态。这样一来，打开错窗口、找不到菜单、跨应用复制时漏了内容，都会自然发生。日常工作的复杂性，有很大一部分已经由这些软件替研究者实现好了。

更细的一点是，工作常常从半途开始。用户不会总给你一台刚开机的空电脑：文档已经打开，浏览器停在某个页面，桌面上还有上一次操作留下的文件。OSWorld 用任务配置准备这些现场，下载材料、打开应用、调整窗口。这个细节很重要：如果每道题都从干净首页出发，智能体学到的熟练，很可能只是熟悉了考场入口。

要让这台电脑反复接受试验，关键在于虚拟机。系统先恢复基础快照，再按任务配置搭出现场；一轮运行结束，丢掉这次造成的变化，就能重新开始。OSWorld 把快照与初始化脚本组合起来，也避免了为每一道题各存一整份庞大的机器状态。于是，同一次失误可以交给旧方法、新方法、另一种模型反复尝试。过去只能看一遍的工作过程，变成了可以做对照实验的对象。

134 种函数，都在回答“做成了没有”

OSWorld 原始论文的 369 个任务，配了 134 种独立的评估函数。这个数字让我感兴趣，是因为它暴露了通用智能体背后很不通用的工作：判断一张表格有没有改好，与判断浏览器里的某类数据有没有删掉，需要理解完全不同的对象。模型可以共用，鼠标键盘也可以共用，验收的含义却要一件件建立起来。

它把验收拆成了取证和判断：先从环境拿到相关状态，再交给对应规则。论文里的例子包括读取 Chrome 的 Cookie 数据，确认指定网站的记录是否清除；取出修改后的表格，与目标要求比较；从界面的无障碍树确认是否到达了正确位置。同样叫“看结果”，其实可能是在看数据库、文件内容，也可能是在看当前界面。验证器有自己的观察接口，无须受限于智能体做题时看到的那张截图。

拿表格举个延伸例子：要求“让金额列保留两位小数”，真正要检查的应当是相关单元格的数值格式。截图里恰好出现了两个零，并不能说明格式设置正确；把数字改成文本，也可能做出相同外观。如果任务还要求后续可以计算，数值类型就同样属于验收内容。OSWorld 的表格评估代码 会打开工作簿，按配置检查单元格、样式、数据验证等属性。这种深入对象内部的检查，让“像是做对了”与“确实满足要求”有机会被分开。

有了这种验收，解法反而可以自由。菜单、快捷键、脚本，都可能把同一份文件改好；只要符合任务允许的操作范围，就应当有机会通过。我们为结果规定必要条件，把中间的选择留给智能体。反过来，如果用户要求保留编辑能力，验证器却只检查导出的图片，那么整个系统都会被引向一种省事的错误：学会交出漂亮截图，同时丢掉用户真正需要的东西。

复现一个世界，需要控制哪些东西？

桌面快照只管得到桌面。浏览器背后的订单已经提交，外部网站的数据已经变化，恢复本地机器都不会把它们倒回去。WebArena 于是把购物、论坛、代码协作等网站也部署到受控环境里，并提供恢复初始状态的方式。它保留真实网站的导航、表单和业务关系，又把后台状态纳入试验范围。一个世界能否重开，取决于它的关键状态到底留在谁手上。

编程领域的 SWE-Gym 则把这个思路落在代码仓库上：自然语言问题、对应代码、可执行环境和测试共同组成一个任务。只给一份报错描述，模型能讨论原因；把依赖和测试也搭起来，它就能改代码、运行、观察，再试另一种办法。桌面、网站、仓库，看起来差得很远，背后却共享一件事：把现实中一次性的工作，变成能反复发生、能给出反馈的经历。

如果轮到我们为一个新领域做评测，我会先把下面四件事写清楚，再考虑题量：

• 工作从哪里开始。 输入材料、已有进度、账号状态和外部依赖，都决定智能体实际面对的难度。
• 哪些选择会改变结果。 观察必须足以支持判断，动作必须覆盖真实工作；关键依赖应能重建，或提供行为可信的替身。
• 完成以后留下什么证据。 文件、业务记录、状态变化与质量要求要能对应，必要时同时检查不能破坏的内容。
• 还会遇到哪些同类处境。 改变材料、初始状态、任务组合与异常条件，才能看到方法的适用范围。

例如，“整理客户名单”可以包含去重、字段修复与导出。但一个值得练习的环境还会留下重复姓名、缺失字段、已有筛选和被公式引用的列。我们不用复制整个公司，只需要保留会影响这项工作的因果关系。只要删除一列会真的破坏引用，智能体就得学会先检查；如果这个后果被模拟器省掉，它得到的熟练就会带着缺口。真实感最有价值的部分，是行动确实要付出它在现实里应有的代价。

评测开始参与开发

一组能够重开的任务，会改变我们修改智能体的方式。先运行现有系统，看它在哪些处境停住；补一份领域材料，改一个工具接口，或者调整某个技能；然后回到相同起点比较。需要修改的也未必总是智能体：任务要求含糊、数据过期、验证器误判，同样会制造失败。评测开发的第一轮，往往也在教我们把业务理解得更清楚。

这里有三个容易混在一起的结果：刚才那道题过了，一类题更常过了，真实使用更好了。第一项只说明修复有了落点；第二项需要换材料、换起点继续测；第三项还要看任务分布是否贴近用户的工作，以及成本、速度、错误后果是否可以接受。拿同一道题不断修改，当然能得到进展，但我们最终想留下的是能迁移的方法。用于挑选修改的任务与最后检验效果的任务，应当分开。

产品上线之后，这个任务集合也会继续生长。用户的一次纠正，可以变成一个新场景；一份失败记录，可以促使我们补上原来没考虑的初始状态。前提是保存足够的现场材料，能够把问题重新放回环境。只留下“导出失败”四个字，下次能研究的空间很小；留下输入文件、操作过程、软件版本和实际产物，才有机会看见究竟是哪一步让事情走偏。

一间考场，也可以是一间练习室

现在把这套设施再看一遍：它有任务、有可以行动的环境、有重置能力，还有结果反馈。这已经具备了训练中反复探索所需的基本条件。有效的运行可以筛成示范，供监督微调学习；同一环境也可以在强化学习中，让模型尝试不同动作，再依据反馈调整选择。开发时用来比较两个运行框架的设施，到了训练阶段，仍然能派上用场。

但“能给分”还不等于“容易学”。如果一个任务要走一百步才有一次成功反馈，模型可能长期碰不到值得学习的行为。人类示范、现成工具、技能指引和由易到难的任务，都能帮助它先走到有效路径附近。评测说明终点在哪里，其他支持让终点有机会被抵达。两者一起，才把一个艰难的业务要求变成可以开发、可以探索的能力方向。

这也是我把评测放在自进化开头的原因。我们很容易被“智能体修改自己”吸引，先去设计那个修改器。但修改器能做的事，受制于它能够观察和检验的世界。把一个新领域做成可重现的任务，把用户的要求落到可信的验证器上，就已经在为智能准备一种新的经验来源。接下来才轮到那个更具体的问题：经历了这些任务以后，它究竟应该把什么改进留下来？