苦涩教训与AI Agent发展路线的启示

苦涩教训与AI Agent发展路线的启示 | 前端进阶之旅

Full translation

完整中文译文

AI 进步竞赛

2019 年，Richard Sutton 写下了那篇具有开创性的文章《苦涩的教训》（The Bitter Lesson）。简单来说，这篇文章得出的结论是：能够随着计算资源增加而持续进步的系统，最终会击败那些无法做到这一点的系统。更具体地说，在 AI 领域，原始算力总能战胜人类精心设计的复杂方案。我过去一直认为，巧妙的编排和复杂的规则才是构建更优秀 AI 系统的关键。这是一种典型的软件开发思维：构建一个系统，找出边界情况，逐一覆盖，然后就万事大吉了。现在看来，我错得太离谱了。

可以把它想象成备战一场马拉松。你可以花几个月完善跑步姿势、购买最新装备，但没有什么比实打实地积累跑量更有效。在 AI 领域，这些里程就是计算周期。

最近，我在照料自己的小花园时，突然意识到这恰好可以类比这一原则。我的植物不需要详细的生长指令。只要具备水、阳光和养分这些基本条件，它们就会自行解决剩下的问题。高效的 AI 系统正是这样工作的。

当我们对 AI 解决方案进行过度设计时，本质上就像是在微观管理一株植物，明确告诉它每一片叶子应该如何生长。这不仅效率低下，而且经常会产生脆弱的系统，使其无法适应新的情况。

三种方案的故事

如今，AI Agent 在企业中最常见的用例之一就是客户支持。下面分享一个我在构建客户服务自动化系统时遇到的真实场景：

**基于规则的方案：**最开始，所有人都构建了一棵庞大的决策树，用数百条规则处理客户咨询。它在常见场景中表现不错，但只要情况稍有变化就会失效，维护工作也变成了一场噩梦。

**算力有限的 Agent：**接着，随着 ChatGPT 的出现，市场上开始有了使用有限计算资源的 AI 客服 Agent。你可以根据历史数据中观察到的模式，或者 SOP 指南来编写 prompt。它们在处理足够简单的问题时效果不错，但面对复杂咨询就力不从心，而且需要持续接受人工监督。如今，许多 AI Agent 正处于这个阶段。其中一条路是进一步限制 Agent，引入更多分支、不同的框架和 guardrail，让 Agent 始终围绕目标行动。不知不觉间，算力就这样被固定住了。或者，你也可以尝试：

**算力有限的 Agent：**接着，随着 ChatGPT 的出现，市场上开始有了使用有限计算资源的 AI 客服 Agent。你可以根据历史数据中观察到的模式，或者 SOP 指南来编写 prompt。它们在处理足够简单的问题时效果不错，但面对复杂咨询就力不从心，而且需要持续接受人工监督。

如今，许多 AI Agent 正处于这个阶段。其中一条路是进一步限制 Agent，引入更多分支、不同的框架和 guardrail，让 Agent 始终围绕目标行动。不知不觉间，算力就这样被固定住了。或者，你也可以尝试：

**横向扩展方案：**然后，我们尝试了一种不同的做法——如果投入更多算力会怎样？这里说的不只是使用更大的 GPU，而是从根本上重新思考我们使用 AI 的方式。我们让 Agent 并行生成多个回答，同时执行多条推理路径，再从中选出最佳结果。每一次客户交互都可能触发数十次 AI 调用，探索不同的处理方式。系统会生成多个可能的回答，对它们进行评估，甚至模拟对话接下来可能如何展开。当然，这种做法的计算成本很高，但效果却出奇地好。系统开始能够处理那些我们甚至从未想到过的边界情况。更重要的是，当系统获得探索多条路径的自由后，它自行发现了一些自然涌现的交互模式。

到了 2025 年，这一模式在强化学习（Reinforcement Learning，RL）Agent 身上体现得更加明显。许多公司仍专注于围绕通用模型构建 wrapper，本质上是在限制模型，让它遵循特定的工作流路径；但真正的突破，将来自那些愿意为 post-training RL 投入算力的公司。这些经过 RL 增强的模型不只是遵循预定义模式，而是在发现全新的问题解决方式。以 OpenAI 的 Deep Research 或 Claude 的 computer-use 能力为例，它们证明了：与复杂的编排层相比，在计算密集型的 post-training 流程上投入资源，能够带来更好的结果。并不是说 wrapper 错了，只是它们只知道一种解决问题的方式。而 RL Agent 拥有探索的自由和庞大的计算资源，能够找到那些我们从未考虑过的更优方案。

RL Agent 的魅力在于它们的学习方式非常自然。想象一下教别人骑自行车——你不会先给对方一本 50 页的手册，详细讲解骑行背后的物理原理。相反，他们会不断尝试、摔倒、调整，最终掌握骑车技巧。RL Agent 的工作方式与此类似，只不过规模要大得多。它们会尝试数千种解决问题的方法，并接收反馈，了解哪些有效、哪些无效。每一次成功都会强化特定的神经通路，每一次失败都会帮助它们避开死胡同。

例如，在客户服务中，RL Agent 可能会发现：有时在对话初期提出一个澄清问题，即使答案看似显而易见，也能显著提高问题解决率。这种行为通常不是我们会写进 wrapper 里的，但 Agent 通过大量试错自行发现了这一模式。关键在于，要拥有足够的计算能力来运行这些实验，并从中学习。

这种方案的强大之处在于，Agent 不受我们既有观念的限制。wrapper 解决方案本质上是在把我们当前认定的最佳实践固化为代码，而 RL Agent 却能够发现全新的最佳实践。它们可能会发现，将看似毫不相关的方法组合起来，比我们符合逻辑、循序渐进的解决方案更加有效。这正是“苦涩的教训”的现实体现：只要算力足够，通过探索进行学习，每一次都会战胜手工编写的规则。

事实上，这一点已经体现在 Claude Code 与 Cursor 之间那场即将变得激烈的竞争中。当前有用户表示，Cursor 配合 Claude Sonnet 3.7 使用时效果不佳，但配合 Sonnet 3.5 却非常顺畅。另一方面，人们又抱怨 Claude Code——它底层使用 Sonnet 3.7——会消耗大量 token。然而，它的实际效果出奇地好。据称，Cursor 将推出按用量计费的版本，以便更充分地利用 3.7 的 agentic behavior¹。我们会在更多领域看到这种现象，尤其是在编程之外：Agent 可以思考多种处理方式，而人类通常只固化了一套工作流。

这对 AI 工程师意味着什么

这一洞见从根本上改变了我们设计 AI 系统的方式：

**从简单起步，大规模扩展：**先从尽可能简单、但足以捕捉问题本质的学习架构开始。然后通过增加算力来扩展它，而不是不断增加复杂度。

**面向规模设计：**构建能够有效利用额外算力的系统。这意味着：可并行化的架构；能够随数据和算力增长而扩展的灵活学习框架；能够处理分布式计算的基础设施。

可并行化的架构
能够随数据和算力增长而扩展的灵活学习框架
能够处理分布式计算的基础设施

**避免过早优化：**在尚未充分利用算力潜力之前，不要花费数周时间优化算法。与直接增加计算资源相比，巧妙工程设计带来的回报往往相形见绌。

其中的影响既深远，也让我们这些工程师多少有些不舒服：

**投资策略：**组织应该把更多资金投入计算基础设施，而不是复杂的算法开发。

**竞争优势：**AI 领域的赢家不会是那些拥有最巧妙算法的人，而是那些能够有效利用最多算力的人。

**职业重心：**作为 AI 工程师，我们的价值并不在于打造完美的算法，而在于构建能够有效利用海量计算资源的系统。这意味着，我们需要从根本上转变构建软件时所采用的思维模型。

这个教训看起来似乎削弱了 AI 工程师的作用，但实际上，它提升了我们的价值。我们的工作是：

设计能够有效利用不断增加的计算资源的系统
构建可扩展的稳健学习环境
创建无需彻底重新设计就能持续成长的架构

未来属于那些能够构建系统、让它们借助计算力量学习和适应的人，而不是那些试图把人类知识编码成僵化规则的人。

请记住：在巧妙的工程设计与原始算力之间的竞赛中，算力会获胜。我们的角色是修建赛道，而不是设计选手的每一个动作。

我的意思是，消息来源就是他们的 Community Manager，所以严格来说，也不能算是“据称”。在这个讨论串中，他们把它描述为更多同步工作与更多委派工作之间的区别，但实际上，这是一场约束与算力之间的较量。这篇文章基本上已经承认了这一点。此时，他们已经发布了一个版本，其中每次 Sonnet 3.7 Max 调用的成本约为 0.05 美元。↩