深度｜翁荔连更2篇博客：谨慎对待Scaling Law，Harness将重构AI演进范式

刚刚，前 OpenAI 安全研究副总裁翁荔更新了她的个人博客。

这是她两周内连续输出的第二篇重磅长文。第一篇《Scaling Laws, Carefully》余音未落，第二篇《Harness Engineering for Self-Improvement》便接踵而至，将视线引向一个更热的领域。

两个命题看似割裂：一个在给“大力出奇迹”的参数扩张泼冷水，一个在为模型的“自我迭代”画蓝图。 然而，两者的交汇点，正演变为当前全球人工智能竞赛中，代价最高昂的行业焦虑。

要小心Scaling Laws

（左）Deep-Speech-2 (DS2) 和注意力语音模型的学习曲线，以及（右）不同规模的 DS2 模型的学习曲线。当训练数据量增大时，小型模型的损失曲线趋于平缓。（图片来源：Hestness 等人，2017）

2020年，OpenAI 的 Jared Kaplan 团队发表了一篇后来被奉为圭臬的论文。他们发现，如果把模型参数、训练数据和计算量画在对数-对数坐标上，测试 loss 会呈现出一条近乎完美的直线。模型每变大一点，loss 就按一个固定的幂律下降。这个发现后来被称为 Scaling Laws。

它的价值在于预测。你不需要花几千万美元去训练一个千亿参数的模型，只需要跑几个小规模的实验，拟合出一条曲线，就能估算出大模型的表现。这让"买多少卡、训多少数据"从一个拍脑袋的决定，变成了一道有公式可循的数学题。

测试损失与计算量、数据集大小和参数呈幂律关系，跨越多个数量级。（图片来源：Kaplan et al. 2020）

Kaplan 的配方是这样的：模型参数每增加8倍，训练数据只需增加1.3倍。如果你想让模型更强，主要力气应该花在"把模型做大"上，数据可以省着点用。这个比例直接指导了 GPT-3 的训练：1750亿参数，3000亿 token。

两年后，DeepMind 的 Chinchilla 团队用另一组实验推翻了这个结论。他们在同样的算力预算下，训练了一个700亿参数、但用了14万亿 token 的模型，结果在9个基准测试中的7个上，击败了参数量是自己4倍的 Gopher。Chinchilla 的配方截然相反：模型和数据应该等比例增长。

同一个理论框架，两套实验数据，得出了两个相反的"最优解"。如果 Kaplan 是对的，那整个行业过去两年都在"数据不足"地训练大模型；如果 Chinchilla 是对的，那 GPT-3 和它的追随者们，本质上都是"营养不良"的巨人。

Weng 在《Scaling Laws, Carefully》里做的第一件事，就是把这两条曲线放在一起，追问了一个被很多人忽略的问题：为什么？

答案藏在最不起眼的细节里。

局部幂律指数增长的可视化（图片来源：Pearce & Song 2024）

2024年，Pearce 和 Song 发现，Kaplan 和 Chinchilla 的分歧，很大程度上来自"怎么数参数"。Kaplan 在计算模型大小时排除了 embedding 层——在那些小模型实验里，embedding 参数占了总参数的一个显著比例。Chinchilla 则把 embedding 算进了总参数量。这个看似技术性的选择，直接扭曲了拟合曲线的形状。当你用 Kaplan 的方式重新校准，那个0.73的指数会随模型规模增大逐渐收敛到0.50。

但 Weng 没有停在这里。她进一步指出，Chinchilla 自身的拟合过程，同样藏着 bookkeeping 级的漏洞。

Epoch AI 团队在复现 Chinchilla 的"方法3"——直接拟合损失函数——时，发现了两个 bug。第一个是 Huber loss 的计算方式：Chinchilla 用了平均值而非总和。这导致 loss 值变得极小，L-BFGS-B 优化器误判为已经收敛，提前停止，输出了一套非最优参数。第二个更微妙：关键参数在论文里只保留到了两位小数。Weng 算了一笔账，按照 Chinchilla 给出的置信区间，要达到那个精度，需要跑大约60万次实验。但 Chinchilla 实际只跑了不到500个模型。

"两位小数"和"60万次实验"之间的差距，意味着那条被行业用来规划千亿、万亿参数模型训练预算的曲线，它的地基可能比我们想象的要松软得多。

Scaling Laws失效模拟器

Weng 在文章里嵌入了一个交互式模拟器，用来演示 Scaling Laws 的三种失效模式。假设真实的损失函数是已知的——模型大小和训练数据的最优配比大约是0.51对0.49。现在，你只能在中小规模模型上做实验，然后用拟合出的曲线去"预测"万亿参数模型的表现。

第一种失效来自 loss 的精度。如果你把 loss 值从多位小数舍入到两位，拟合出的参数会发生偏移，外推结果跟着漂移。第二种来自 loss 的噪声。给损失值加上极其微小的扰动——小到千分之一量级——拟合出的曲线形状就会改变。第三种来自拟合区域的选择。如果你只在小模型上拟合，你会得到 Kaplan 式的0.73；如果你只在中等模型上拟合，指数又不一样；只有当你覆盖足够大的规模区间，才会逼近真实的0.50。

这三种失效模式的共同点是：它们在小规模实验里几乎不可见。你的拟合曲线在训练数据范围内看起来完美无缺，但一旦外推到更大的模型、更多的数据，微小的误差会被指数级放大。就像用一把在室温下校准的尺子去测量一座在热胀冷缩中的摩天大楼——尺子本身没问题，但场景变了。

这引出了 Scaling Laws 更深层的假设危机：数据不是无限的。

较强的权重衰减可以减轻由数据重复引起的过拟合惩罚。（图像来源：Lovelace 等，2026）

Scaling Laws 的隐含前提之一，是训练数据无限且唯一——没有重复、没有多轮训练。这个假设在2020年或许成立，但在2026年已经越来越像一个童话。Hernandez 等人在2022年的实验里观察到一个"双重下降"现象：当训练数据里重复数据的比例上升时，测试 loss 不是单调下降，而是在训练中段出现平坦甚至上升。模型开始"记住"重复内容，而不是"学习"新东西。Muennighoff 等人在2023年尝试给数据重复建模，提出一个"有效数据"的折价公式：token 的价值随重复次数指数衰减。Lovelace 等人2026年的工作则更进一步，直接在损失函数里加了一个显式的过拟合惩罚项，发现模型越大，对重复数据越敏感。

这些研究共同指向一个结论：当高质量唯一文本逐渐枯竭，Scaling Laws 的"数据无限"前提正在崩塌。行业开始转向合成数据、强化学习和测试时计算，本质上都是在寻找"不用更多真实数据"的替代路径。

对有效规模拟合结果的残差分析显示：训练 epoch 越多、模型越大，过拟合造成的损害越严重。（图像来源：Lovelace 等，2026）

但 Weng 没有否定 Scaling Laws 的价值。她的核心警示是：这条曲线每一次拟合，都是一次在噪声和近似中走钢丝的过程。参数计数方式、loss 函数的计算细节、数值精度、实验规模的选择，这些看似 bookkeeping 级别的决定，最终会影响一个价值数十亿美金的判断。而在这条曲线上外推的人，最好先看看自己脚下的地基，是不是也外推到了不该外推的地方。

不训练更大的模型，怎么让 AI 变强？

Scaling Laws 的裂缝，让一个问题浮出水面：如果继续堆参数和数据的边际效益正在递减，AI 的第二条增长曲线在哪？

Weng 在第二篇文章里给出了一个答案：Harness Engineering。

Harness 这个词在中文里很难找到一个精确的对应。它不是"框架"，不是"工具链"，也不是"中间件"。Weng 把它定义为"围绕基础模型构建的执行系统"——负责编排执行、决定模型如何思考与规划、调用工具与行动、感知和管理上下文、存储产物、评估结果。简单来说，模型负责"想"，Harness 负责"做"，并且把"做"的结果反馈给模型，让它下一次"想"得更好。

Weng 在文章开头花了不少篇幅追溯"递归自我改进"（Recursive Self-Improvement, RSI）这个概念。1965年，统计学家 I.J. Good 提出了"超智能机器"的设想：一台能在所有智力活动中超越人类的机器，还能设计出更好的机器来改进自身。2008年，Eliezer Yudkowsky 把这个反馈循环具体化——AI 用当前的智能去改进产生智能的认知机制。在现代 AI 里，这个循环不一定是模型直接重写自己的权重，更现实的路径是：模型改进训练流水线和部署系统，而部署系统又催生出性能更好的后继模型。Weng 特意强调了"部署系统"这个词，因为在她看来，原始模型和真实世界之间的那一层，其重要程度不亚于模型本身的 raw intelligence。

这个判断直接指向了 Harness 的价值。看看 Claude Code、Codex、Cursor 这些编码代理的成功，它们的核心竞争力往往不是模型权重本身，而是 Harness 设计。

简化的 Codex 智能体循环：智能体调用工具，工具的响应会影响模型的下一代。（图片来源：OpenAI Codex 智能体帖子）

以 Codex 为例。当你给它一个编程任务时，它不会直接输出一段代码然后结束。它会进入一个循环：观察代码仓库、制定计划、搜索和读取文件、编辑代码、运行测试、检查错误。如果测试失败，它会回到计划阶段重新调整。这个循环不是模型权重里写死的，而是 Harness 设计的。模型提供的是推理能力，Harness 提供的是"让推理在真实环境中落地并持续迭代"的结构。

Weng 把 Harness 和操作系统做了一个类比。操作系统封装了底层的复杂逻辑，给上层应用暴露一个简洁的接口。Harness 也一样——它封装了工具调用、状态管理、错误恢复这些复杂流程，给模型一个干净的交互界面。而 configs、工具接口和其他协议，可能也会像操作系统 API 一样，逐渐在行业里标准化。但 Weng 也强调，Harness 的设计应该刻意保持简单和通用，以便泛化，最好借鉴现有的软件工程实践，让模型能利用预训练知识。

智能体循环过程

与早期的"agent = LLM + memory + tools + planning + action"公式相比，Harness Engineering 额外包含了工作流设计（比如循环工程）、评估、权限控制和持久状态管理。它不再只是 prompt 模板，而是更接近运行时和软件系统设计：模型如何观察、行动、记忆、自我检查、改进。

Weng 梳理了 Harness 的几个核心设计范式。

人工智能科学家用于构思、实验、论文撰写和审阅的流程。（图片来源：Lu et al. 2026）

第一个范式是工作流自动化。Karpathy 的 autoresearch 仓库是一个简洁的示例：模型在一个目标导向的循环里运作——计划、执行、观察/测试、改进、再执行，直到目标达成。这个过程还可能主动向用户请求澄清，以明确任务规格或执行偏好。这个循环不是静态的 prompt 模板，而是一个"运行时"，模型可以在其中分析自己的轨迹和失败案例，然后迭代。Codex 的简化循环图里，模型推理后分叉为两条路径：一条输出 Agent 响应，一条触发工具调用，而工具调用的结果又会回流影响模型的下一次生成。

第二个范式是文件系统作为持久记忆。在长周期任务中，实验日志、代码 diff、论文摘要、错误追踪、历史轨迹往往比模型的上下文窗口长得多。Harness 不应该把所有信息都塞进 prompt 里，而是让模型学会读写文件系统，把状态持久化到磁盘上。Weng 认为，学会用 bash 命令读写文件是 LLM 的"基础技能"——模型需要像人类开发者一样，学会用文件来管理自己的工作记忆。而管理以文件形式存在的持久记忆，自然受益于核心模型能力的提升。

第三个范式是子代理和后台任务。Harness 可以派生多个子代理并行执行，主代理则像一个小型进程管理器：启动任务、检查日志、取消失败运行、合并结果。关键是让并行变得"可检查"——如果子代理的输出只存在于一次性的聊天上下文里，它们很快就会变得不可追溯和过时。只有当它们被存储为文件、日志和状态记录时，模型才能在中断后恢复，并对自己的执行历史进行推理。

编码智能体工具

Weng 还给出了一份编码代理的工具清单，分成了八个组：文件系统（glob、grep、ls、read、write、edit、apply_patch 等）、Shell 执行（bash、PowerShell）、IO（lsp、git_status、git_diff、git_commit）、外部上下文（MCP tools、Skills）、网页搜索（web_search、web_fetch、浏览器工具）、Artifacts（读取文档和图片、生成 HTML 和图片）、后台进程（CronCreate、CronDelete、CronList）、以及代理委托（spawn_agent、resume_agent、wait_agent、list_agents 等）。这份清单的丰富程度说明，编码代理的 Harness 已经远不是一个简单的"调用几个 API"的包装器，而是一个完整的执行环境。

但 Harness 真正让模型"自我改进"的，不是这些工程架构本身，而是三个闭环：反馈、记忆和策略更新。反馈是闭环的起点，Agent 必须知道自己做得好不好。Weng 强调，反馈最好是可验证的，而不是只依赖模型自己的主观判断。模型很擅长生成听起来合理的解释，但这些解释未必对应真实错误原因。真正有用的反思，必须和外部证据绑定在一起——代码是否通过测试，网页是否真的渲染，工具调用是否返回预期结果。

记忆是闭环的存储。但记忆不是越多越好。无筛选地保存所有上下文，会带来噪音变多、错误固化、隐私和安全风险增加。好的记忆系统应该对经验进行筛选、压缩和结构化。它保存的不是所有历史，而是经过提炼的规律。

策略更新是闭环的终点。Agent 不能只是记住信息，还要在未来行动中改变行为。当反馈、记忆和策略更新连起来，Agent 才形成真正的改进闭环。

Weng 在文章里还深入讨论了 Context Engineering，因为"简单地把所有工具响应和模型生成内容追加到上下文里"，在 agentic 任务周期变长时会迅速失控。

智能体情境工程（ACE）框架。（图片来源：Zhang et al. 2025）

她介绍了 ACE（Agentic Context Engineering，Zhang et al. 2025）。ACE 把上下文视为一个不断演进的 playbook，而不是一个越来越长的 prompt。它有三个组件：Generator（生成任务轨迹）、Reflector（从成功和失败的轨迹中提炼洞察）、Curator（用增量、条目化的方式更新结构化上下文）。ACE 的关键设计是，Curator 不会重写整个 prompt blob，而是输出结构化的 (identifier, description) 形式的 bullet points，这些 bullet points 通过确定性逻辑合并到一个结构化的上下文 logbook 里。上下文条目会定期精炼和去重。

元上下文工程（MCE）框架：元层面的技能演化搜索基于上下文管理机制，而底层则优化任务上下文。（图片来源：Ye et al. 2026）

但 ACE 的更新规则和工作流仍然是手工设计的。为了走向更自我改进的循环，MCE（Meta Context Engineering，Ye et al. 2026）把"机制"（如何管理上下文）和"内容"（上下文里有什么）分离开来。MCE 在元优化层面运行技能进化，在基础层面运行上下文优化。一个 MCE 技能定义了一个上下文函数，包含静态组件（prompts、知识库、代码库）和动态操作符（搜索、选择、过滤、格式化）。双层优化的内层是在训练数据上找到给定技能下的最佳上下文，外层是在验证集上找到最佳技能。MCE 不强制像 ACE 那样的启发式规则，而是使用自由形式的技能来存储任务中最重要的知识，并让技能和技能条件化的上下文一起迭代进化。实现上，上下文函数被实例化为一个专用目录中的文件集合，包括静态的 skill.md 和动态的上下文与数据 rollout。

Meta-Harness 外循环优化算法。（图片来源：Lee 等人，2026）

更激进的是 Meta-Harness（Lee et al. 2026）。它的优化对象是"决定和优化哪些信息应该被存储、检索、呈现给模型的代码"。Meta-Harness 的名字意味着它是"优化 Harness 的 Harness"。

Weng 对 Harness 的未来路径做了一个清晰的判断。她认为，很难预测 RSI 在多大程度上会依赖 Harness 工程，但近期的现实路径不是模型直接重写自己的权重。

她给出了两条并行的预测：

第一，Harness 工程会向"元方法论"进化，即优化"获得更好答案的机制"，而不只是优化答案本身。Harness 系统本身成为优化目标，启发式规则更少，通用机制更多。

第二，成熟的 Harness 反过来支持自动研究，形成模型自我改进的闭环；而更聪明的模型又能防止 Harness 过度工程化，保持系统的可持续性。

自约束方法利用弱点挖掘、有界约束方案提出和验证的循环来更新约束。（图片来源：Zhang et al. 2026）

最终，许多 Harness 改进会被内化到核心模型行为中，但外部接口与工具交互层将始终存在。Weng 用 prompt engineering 做了一个类比：手动 prompt 技巧在指令微调和模型推理能力提升后变得不那么核心了，但"指定目标、约束、上下文和评估"的需求从未消失。

基于工作流候选树的流程优化过程。（图片来源：Zhang et al. 2025）

她还梳理了 Harness 中优化对象的演进梯度：指令提示 → 结构化上下文 → 工作流 → Harness 代码 → 优化器代码。随着模型变得更智能和强大，优化的目标向更复杂的对象和更通用的方法移动。

从"模型竞争"到"系统竞争"

把 Weng 的两篇文章放在一起读，可以看到 AI 发展的一个清晰转向。

过去几年，行业的主要叙事是"扩展模型本身"。参数更多、数据更多、计算更大，能力就会提高。Scaling Laws 让这种扩展变得可预测，也让大规模投入有了理论依据。但 Weng 的拆解提醒我们，这条曲线本身比想象中脆弱。它的拟合建立在诸多近似之上，而"数据无限"的假设正在遭遇现实枯竭。

与此同时，另一条叙事正在崛起：扩展模型之外的东西。数据质量、后训练流程、推理时计算、工具调用、记忆、反馈、评估和 Harness，都成为能力增长的新变量。

这不是说 Scaling 结束了。恰恰相反，scale 仍然重要，只是 scale 的对象变多了。

有些场景下，继续训练更大的基础模型是最有效的。通用语言能力、跨领域知识和基础推理能力，仍然受益于预训练规模。但在另一些场景下，更高的收益可能来自系统工程。代码 Agent 需要测试和错误恢复，研究 Agent 需要信息检索和来源校验，办公 Agent 需要长期偏好和上下文记忆，企业 Agent 需要权限控制和可审计流程。

这说明，未来 AI 竞争不只是模型竞争，也会是系统竞争。

模型公司需要理解 Scaling Laws，知道哪些能力可以通过参数、数据和计算继续提升。应用公司则需要理解 Harness，知道如何让模型在具体任务中形成可靠闭环。前者让模型更有潜力，后者让潜力变成可用的生产力。

而大多数公司，可能需要在两条线上同时下注。