适合阅读场景： 当你正在设计 AI Agent 系统，却感觉手工搭建的工作流和规则越来越多，效率不高；或者你想知道为什么「更好的模型」会悄悄吃掉你花大力气做的工程优化。
读完这篇文章，你将获得：一套判断 Agent 架构是否「可扩展」的检验标准、当前最常见的三个设计反模式，以及一个真正符合 AI 发展规律的构建思路。
一、70 年 AI 研究只教会我们一件事
1997 年，深蓝（Deep Blue）通过大规模深度搜索击败了国际象棋世界冠军卡斯帕罗夫。这不是靠把人类的下棋知识灌进系统——恰恰相反，它靠的是极其纯粹、甚至有些「笨拙」的暴力搜索。二十年后，围棋领域上演了同样的故事：AlphaZero 完全抛弃了人类棋谱，通过自我对弈（self-play）从零开始学习，最终超越了所有基于人类领域知识的系统。
在语音识别领域，1970 年代 DARPA 竞赛中，基于统计和计算的方法（如隐马尔可夫模型，HMMs）击败了那些试图模仿人类发音知识的方案。在计算机视觉领域，手工设计的特征提取器（边缘检测、SIFT、广义圆柱体）最终被可以大规模训练的卷积神经网络取代。
这些故事指向同一个结论。Richard Sutton 在 2019 年的博客文章《The Bitter Lesson》（苦涩的教训）中把它写成了最简洁的一句话——这篇文章当时不到 1,200 字，如今在 Google Scholar 上已被引用数百次，包括 Google DeepMind 的「A Generalist Agent」论文和 Noam Shazeer 的 switch transformer 论文：
「从 70 年的人工智能研究中能读到的最大教训是：借助计算能力的通用方法最终是最有效的，而且优势巨大。」
这个结论之所以「苦涩」，是因为它否定了一个我们最自然的直觉——把人类的聪明才智手工编码进系统。Sutton 指出，AI 研究者反复尝试将人类知识内嵌到系统中，这种做法短期内确实有效，也能带来研究者的满足感，但从长远来看，它会导致进展停滞，甚至阻碍真正的突破。真正持续有效的路径，是让方法本身能够随算力增长而自动扩展——目前来看，这样的方法只有两个：搜索和学习。
二、为什么今天关于 Agent 的很多想法可能重蹈覆辙
Sutton 的观察并没有停留在 2019 年。2025 年 9 月他在 Dwarkesh Patel 的播客中重新审视了自己的文章，说出了一个更尖锐的判断：
「大语言模型是从训练数据中学习，而不是从经验中学习。」
在 Sutton 看来，今天的 AI 领域虽然在引用《苦涩的教训》，做的却大致是相反的事——LLM 本质上是在模仿人类文本，而不是在世界中行动、观察后果、形成目标、从经验中学习。2025 年更新的第二章中，他甚至直言：「整个领域一直在引用 2019 年的文章，但做的却大致是它所反对的东西。」
把这个框架放到今天的 Agent 构建上，你会看到三个正在重蹈覆辙的模式。
反模式一：工作流陷阱（Workflow Trap）
很多 Agent 框架通过可视化的工作流构建器，让你用拖拽的方式把「研究 → 摘要 → 撰写」串起来。这在产品层面很合理——当前的 AI 模型还不够可靠，似乎只能靠这种方式达到可用水平。YC Demo Day 上的观察也印证了这一点：几乎所有路演产品都属于「垂直工作流」类别。
但问题在于，你其实是在把自己对任务分解的假设硬编码进架构了。当模型进步时，你的工作流不会自动变简单，因为团队已经绑定在那个流程图上了。YC 合伙人 Jarred 在 Lightcone 播客中也印证了这个观察：
「第一波基于固定流程的 AI 应用，大多被新一代 GPT 模型淹没了。」
反模式二：专职子代理幻觉（Specialized Subagent Illusion）
设计一个研究 Agent、一个写代码 Agent、一个写作 Agent——这看起来很像人类的组织架构。但人类组织是在认知有限、沟通成本高的约束下演化出来的，AI 并不必然有这些限制。当你把固定的角色分工冻结在架构里，你是在进口人类的限制，而不是利用运算的优势。
单 Agent 加技能的模式在很多串行任务中反而比多 Agent 协作更高效——因为沟通本身就会产生信息损失，而且错误会在串联架构中不断累积。UBC TEA Lab 的李霄霄教授的研究发现，单个 Agent 在配备大约 20 到 30 个技能时达到最佳性能，再往上加，性能就会饱和甚至下降——因为上下文窗口就是它的「工作记忆」，当 Context 变得非常长的时候，AI 也会 Lost in the Middle。
反模式三：循环天花板（For-Loop Ceiling）
「LLM + 循环 + 工具就够了」听起来很精简，但你唯一的扩展旋钮就是迭代次数。面对复杂任务，这是一维的扩展，很难并行化，也容易浪费 token。正如一位分析者所指出的，这种模式的唯一扩展方式就是增加循环次数，而面对复杂任务时，这种一维扩展很难真正解决问题。
三、什么才算是真正符合「苦涩的教训」的做法
符合 Bitter Lesson 的做法有两个核心特征：把额外的算力转化为更好的决策，而不是依赖固定的人类设计分解方式。
方向一：动态子代理生成（Dynamic Subagent Spawning）
不要在设计时预先固定 Agent 的分工和流程，而是让模型在执行时根据任务需求自行决定怎么拆解、要生成几个子代理、各自做什么。Anthropic 的多 Agent 研究系统、LangChain 的 Deep Agents、Claude Code 的子代理委派，虽然具体实现方式不同，但都遵循同一个原则：随着模型进步，委派策略可以「免费」变好，不需要你重写组织图。
一个实用的检验标准是：
如果模型能力明年翻倍，你的系统会不会在不需要大幅重构的情况下，变得更简单、更便宜、或更可靠？
如果答案是「会」，你可能站在 Bitter Lesson 这边。如果你的扩展计划是「加更多节点/角色」，那是在扩展人力；如果是「让模型通过通用方法分配更多算力」，那才是在扩展运算。
方向二：递归语言模型（Recursive Language Models）
MIT 的研究者把整个 prompt 当成外部字符串，模型通过代码和递归自我调用来推理。这种方式可以处理比原生注意力窗口大 100 倍的输入，在 600 万到 1100 万 token 的基准测试上达到 91% 以上的准确率，而且因为模型是选择性检视上下文而非全部处理，成本可以便宜到三分之一。这背后的逻辑是：让模型自己决定要检视、压缩、递归什么，而不是人类来规定。
四、Harness：模型之外的真正竞争力
在讨论具体做法时，有一个概念绕不开——Harness（马具）。这个来自腾讯云开发者的定义非常清晰：
Agent = LLM + [上下文 + 工具 + 约束 + 验证 + 纠正]
前两项（上下文 + 工具）让 Agent「能做事」；后三项（约束 + 验证 + 纠正）让 Agent「不做错事」。Anthropic 也对 Workflow 和 Agent 做了明确区分：Workflow 是大模型和工具在既定路线下进行交互的系统；而 Agent 则具备自主 Planning 和进化的能力，不仅能使用工具，甚至能创造工具。
一个有力的证据来自 LangChain：在 Terminal Bench 2.0 基准测试上，他们通过改进 Harness——让 Agent 自动检查自己的执行结果、检测是否陷入重复循环、优化思考策略——把准确率从 52.8% 提升到 66.5%，排行榜从 30 名开外跃升到前 5 名。改的不是模型，是 Harness。
另一个案例是 OpenAI 工程团队：3 名工程师用 5 个月完成了约百万行代码和近 1,500 个 PR，达到传统开发速度约 10 倍，背后的支撑就是把 Harness 做对了。
这里有一个关键的辩证关系：模型越强，Harness 越关键。 模型能把工具调用内化得越多，它接触的系统边界就越宽，一旦出错波及面也越大——所以越强越需要那三层外壳兜底。这正呼应了 Anthropic 的立场：模型厂商真正的优势不是「把框架做薄」，而是能对「模型 + 外围 Harness」做协同优化。
五、你现在可以做的事
回到 Sutton 的框架，那些需要手工搭建的规则和流程，本质上都是在「把人类知识内嵌到系统中」。这条路短期内有效，但长期必然被更通用的方案超越。2025 年 11 月 Anthropic 发布 Opus 4.5 后，Agent 已经能够解决数月前只有专家级人类才能处理的复杂长时任务——这个门槛正在持续后移。与此同时，SWE-bench Verified 上 Agent 软件开发的性能从 2024 年 3 月的约 30% 攀升到 2026 年初的约 80%，通用模型能执行的任务长度每七个月翻一番——任何建在模型之上的「wrapper」都可能被更强的模型直接吞掉。
具体到行动层面：
- 从最简单的方案开始。 直接 API 调用优于复杂框架，清晰代码优于聪明抽象——每一层抽象都会成为未来的调试盲区。
- 让每个工具都返回结构化、可校验的反馈。 不要只返回一句「成功」就完事。把 linter 这类检查内嵌进去，形成「执行 → 验证 → 反馈」的闭环。
- 默认拒绝一切，显式开放。 能力像手机权限一样，关着才是常态。任何默认开启的副作用都是一颗定时炸弹。
- 给模型一个状态栏。 把任务进度、环境状态、可用能力持续喂回去——模型自己看不见仪表盘，得靠壳帮它校准。
- 永远别信模型那句「我搞定了」。 去真实世界里验证一下再说。验证只看工具返回的结构化结果，不看它自己说的。
- 危险操作用工作流兜底，开放探索交给自主 Agent。 确定性的关键步骤绝不允许被跳过，枚举不出的才放它去逛。
六、需要警惕的局限
在结尾，有必要指出几件事的不确定性：
-
90-90 法则的提醒。 软件工程中的 90-90 法则（90% 的功能花了 90% 的时间完成，剩下 10% 的功能也需要 90% 的时间）同样适用于 AI 发展。我们可能只完成了 AI 发展中比较「容易」的部分，剩下那最后的 10% 甚至 0.1%，难度可能远超想象。自动驾驶从 L2 到 L5 的跨越就是最好的前车之鉴。
-
验证瓶颈仍然存在。 那些需要人类判断、无法自动验证的任务，进展速度会远远慢于可以自动验证的领域（如数学和代码）。这意味着在可预见的未来，「手工搭建的规则」在特定场景下仍然不可替代。
-
Sutton 的判断来自单一来源。 他关于「LLM 不是通往真正智能的足够路径」的论断，目前主要来自他本人的播客言论和博客文章，尚未得到广泛的独立验证。同样，Karpathy 将 LLM 比作「鬼魂」（人类数据的统计精炼）而将 Sutton 的理想智能体比作「动物」（从经验中学习、植根于物理世界）的比喻，也仍是单一来源的观察。
-
模型进展的速度本身就是一个变量。 从 2024 年 3 月到 2026 年初，SWE-bench Verified 上 Agent 软件开发的性能从约 30% 攀升到约 80%。这个速度本身也提醒我们：今天看起来稳固的工程方案，可能在下一次模型发布后就被大幅削弱。
下一步
如果你正在构建 AI Agent 系统，建议按以下顺序检验你的架构：
- 列出你系统中所有手工搭建的规则、流程和角色分工
- 逐一问自己：如果模型能力提升一倍，这个部分会不会变得多余？
- 如果答案是「会」，考虑把它改成让模型自主决策的形态
- 如果答案是「不会」，保留它，但确保它有清晰的验证和纠错机制
最后一点： 《苦涩的教训》的核心不是让我们放弃所有人类知识，而是提醒我们——人类知识会不断向上游迁移，而下游会被自动化吃掉。 今天的 Harness 工程，本质上就是在模型还不够稳时，帮你补上那些暂时还不能交给模型自己处理的环节。随着模型每内化一层，Harness 就卸下一层，转而兜底新的前沿。