我们愿意让自己的聪明过时吗

读理查德萨顿的苦涩的教训

我们很容易相信，真正理解一个问题的人，应该能设计出解决它的最好办法。把经验变成规则，把判断变成流程，把流程打磨成可靠的系统，这几乎就是技术能力最直观的证明。

所以，当一个没有装入那么多专家技巧、却愿意做更多搜索与学习的系统后来居上，最难接受的未必是输。更难接受的是：那些确实有用、甚至值得骄傲的理解，并不是通向更高能力的必经之路。

Richard Sutton 在 2019 年写下的《The Bitter Lesson》，让我重新审视这种直觉。起初，这篇文章很容易被读成一句劝告：别太依恋自己的方法。但不依恋还远远不够。一个人可以很愿意推翻方案，却仍然把全部精力花在发明下一套更精巧的手工方案上。Sutton 真正提出的问题更尖锐：我们是在不断替系统发现答案，还是在构造一种能够继续发现答案的方法？

今天的领先不等于明天的进步来源

Sutton 从棋类、语音识别和视觉研究的历史中，提出一个长周期判断：随着单位计算成本下降，能持续利用更多计算的通用方法，最终往往比直接装入人类领域知识的方法走得更远。他着重指出搜索与学习，并主张构造能够发现复杂结构的方法，而不只把人已经发现的结构装进去。他也承认，领域知识与通用方法不必冲突；问题在于前者常占据资源，并使系统更难利用后者。[1]

这里最容易丢掉的词，是“持续”。一种方法在今天做得好，可能因为我们已经替它解决了很多难题。另一种方法今天还显得笨拙，却有办法把更多计算变成更深入的探索，或从更多经验中形成更好的判断。若只比较眼前的一次结果，我们会漏掉它们继续进步的来源。

这并不意味着没有人类知识的系统才算先进。深蓝的成功既依赖搜索，也使用了复杂评估函数和棋局数据库。[2] 真正需要辨认的不是代码里有没有人的痕迹，而是新的能力主要怎样长出来：遇到我们尚未理解的情况，系统有没有继续寻找办法的余地，还是只能等我们先把它想明白？

给两种方案同样多的未来

不妨做一个思想实验。以下没有实验数据，也不预设胜者。任务是从陌生版式的采购单里提取金额、币种和付款条件，并指出支持答案的原文位置。我们比较两种 Agent 方案。

方案 A 来自专家经验：先识别版式，再进入对应流程，提取字段，最后检查金额关系。它也可以在每一步生成多个候选、重试、利用反馈，并不是一台只会机械匹配的稻草人。方案 B 使用同样的模型和工具，但允许搜索不同的处理路径，例如先定位条款、再读表格，或者在发现冲突后换一种解析方式。

先固定模型、任务分布、工具权限和验收标准，不再给任一方添加新规则。把每份任务可用的总计算预算从 C 提高到 10C，再到 100C。这里的倍率只是实验设置；同时记录真实正确率、总成本、延迟和额外人工核验时间。不能让一方把成本藏进“人工帮忙”，另一方却为每次重试付账。

在最低预算下，A 完全可能更好。专家提前排除了大量无效路径，B 却把宝贵的资源花在了摸索上。这种优势很实在，不能因为它来自人工设计就被轻视。

预算增加后，问题才开始变得有意思。A 的既定流程还能怎样使用这些计算？多跑几次相同路径，能否处理第一次就被分错的文档？B 多探索一些路径，又能否真正找到并辨认更好的答案？如果 A 在节点内扩展搜索，同样持续获得收益，那它也在利用 Sutton 看重的机制。架构的名字并不能替我们分类。

然后再做另一组对照：保持计算预算不变，给两边同样多的专家修改时间。我们可能发现，某种方案的每次进步都需要人先辨认一种新例外；另一种方案的改进则更多来自一个能重复使用的搜索或学习机制。这才接近文章真正关心的投资选择：未来的增长主要靠什么，我们又把今天的时间投向了哪里？

这组实验只检验运行时搜索，不能冒充对 Sutton 长期论点的证明。搜索是在当前任务里寻找更好的解；学习还要把经验转成以后也能使用的能力。两者都能利用计算，但不能因一次任务多尝试了几轮，就宣称系统已经学会了什么。

更多计算也可能把错误放大

最强的反驳并不是“人仍然重要”，而是：一个有限期限、有限预算的项目，为什么要为尚未兑现的扩展性买单？如果客户只愿意承担基准预算 C 的成本，A 又明显更可靠，那么选择 A 很可能就是正确决策。长期有潜力，不能自动兑换成今天可部署。

更棘手的是采购单里的付款条件。金额相加可以机械核对，某个例外条款是否改变了付款义务，却未必能靠现有检查器判断。B 搜索出十种答案，如果它们都由同一个有偏差的评分器挑选，多出来的计算可能只是更擅长迎合评分器。内部得分在涨，实际理解没有进步。

人工也不一定能廉价补上这个缺口。核验者可能要对照多个段落，理解前后条件，甚至确认采购单之外的约定。若更多候选意味着更多复杂核验，而核验成本没有下降，便宜的生成就未必带来便宜的可靠答案。

不过，这还没有反驳 Sutton。评估本身也可能通过学习、搜索或更好的实验设计得到改进。今天的验证瓶颈，不足以证明它永远不能被计算突破。它只能提醒我们：此刻还没有找到把更多计算转成可靠进步的完整机制，不能先把预期收益写进成绩单。

我愿意接受的结论因此比“规模总会赢”更有条件，也比“工程约束永远挡住规模”更不舒服：我们需要同时检验候选方法和检验方法。若反馈已经失真，就先修反馈；若搜索空间被人为切得太窄，就试着打开；若收益不足以覆盖成本，就承认当前部署不值得。未来可能改变判断，但不能替现在免除举证责任。

Harness 应该把计算接到发现上

把这个问题带回 Agent Harness，也就是模型之外组织工具、状态和执行的系统，会得到一个比“把旧补丁删掉”更严格的要求。以下是我对原文的延伸：一个框架应当说明，它怎样让新增计算产生新的候选、怎样辨认候选的好坏，以及哪些经验可以进入下一次改进。

如果一个系统无论拿到多少资源，都只沿着我事先写好的路线重复执行，那么它可能很实用，却还没有回答扩展问题。相反，增加十个 Agent、十轮反思，也不自动构成好的答案；如果它们共享同一种盲点，又没有可靠筛选，复杂性只是在内部循环。

回到采购单例子，一个有意义的变化，是允许系统在证据冲突时改用另一条工具路径，并把可确认的失败整理成后续改进的材料。但这仍有两个时间尺度：本次任务内，反馈帮助选择答案；跨任务，经过筛选的经验需要通过策略、记忆或模型更新，才有机会改变下一批任务的表现。更新之后，还要用没有参与改动的任务重新验收。

这时，领域知识仍然能发挥作用：它可以帮助选择有信息量的测试，识别虚假的成功，设计更有效的探索，而不必总以“所有任务都必须这样做”的形式出现。但这也不是人的永久安全区。测试选择、错误分析乃至评估器，都可能被后来的方法部分接管。

权限、停止条件和状态恢复同样不能被聪明的模型一笔勾销，但也不该成为现有架构免受质疑的护身符。禁止未经授权付款，是任务边界；要求每个文档都经过三个角色讨论，可能只是设计者的习惯。前者需要持续履行，后者需要拿出收益证据。要求的延续不等于某份代码、某个岗位或某套流程必然延续。

我们的理解不该成为系统的上限

对个人学习而言，这篇文章最难处理的后果，是它拿走了一种安心的积累观：只要不断增加我知道的规则，系统就会随着我的理解稳步变强。知识仍然有价值，但知识怎样进入系统，可能比知识堆得多厚更重要。

学习 Python、数据库或 Agent 的执行机制，可以让人更准确地理解计算的成本、反馈来自哪里、一次失败为什么发生。可是，如果学习最后只沉淀成“我知道正确流程，所以系统必须遵循它”，我们可能同时获得了能力和限制能力增长的理由。

更值得追求的理解，应该帮助我们设计一个检验：当系统得到更多资源时，它能否找到我们没有逐项写出的解法？如果不能，缺的是计算、反馈，还是我们提前替它关掉的可能性？如果能，我们是否愿意接受它的路径看起来并不像我们认为专家应该使用的路径？

我因此更愿意把《苦涩的教训》读成对技术判断的一次换位。过去容易把好设计看作个人理解的完整呈现；现在还要看，这个设计给尚未被我理解的办法留下了多少空间。我们仍然需要认真构造系统，只是不能把系统越来越像自己，误当成它越来越强的证据。

原文与延伸阅读

[1] Richard Sutton，The Bitter Lesson，2019 年 3 月 13 日。作者原站；得克萨斯大学奥斯汀分校课程保存的原文 PDF。本文依据该完整副本核读。采购单思想实验、Harness 设计和学习讨论均为本文延伸，不是原文提供的实证结论。

[2] Murray Campbell、A. Joseph Hoane Jr.、Feng-hsiung Hsu，Deep Blue，Artificial Intelligence，2002。IBM Research 论文页面。该论文摘要同时列出搜索、复杂评估函数与棋局数据库，说明“利用计算”不等于“完全没有领域知识”。