一篇Agent 论文揭开了生产真相：能力可以耦合，执行必须标准化

本文来自微信公众号： AIGC从0到1 ，作者：王零壹，原文标题：《一篇 Agent 论文揭开了生产真相：能力可以耦合，执行必须标准化》

8月31日，WHALE这篇论文，提出了一个足够朴素、也足够锋利的判断：模型权重和运行它的Harness，才共同构成了Agent。注意，不是简单的加法。

这里的Harness，不是狭义的提示词模板。

它包括上下文怎样组织，工具如何暴露，检索何时触发，错误怎么处理，任务做到什么程度算结束，记忆写在哪里，多个步骤如何编排。很多时候，它就是一段不断膨胀的可执行代码。

过去大家习惯把模型和Harness分开优化。模型不好，就微调模型；模型已经够强，就改Prompt、换工具、加检索、塞工作流。

这篇名为WHALE的论文认为，这种分法有问题。

模型权重变了，原来的Harness可能不再适合它；Harness变了，原来的模型也可能接不住新能力。无论固定哪一边，另一边最终都会撞上天花板。

于是，它给出了一条简单的路径：先在当前Harness下更新模型权重；再基于更新后的模型搜索更好的Harness；然后继续循环。

论文把这件事叫作Weight-Harness Alternating Learning，也就是WHALE。

在SearchQA、数学推理和棋类任务上，WHALE用Qwen3.5 2B、4B模型做实验，相比只训练权重、只搜索Harness，以及Fast-Slow Training，取得了4.15到24.38个百分点的mean@8准确率提升。小步交替更新，也优于“先把模型练完、再集中搜索Harness”的阶段式方案。

从算法上说，这个结论很有说服力。

一个Agent从来不是“模型加一个Prompt”这么简单。检索不到证据，再强的模型也没有材料可用；工具调用顺序混乱，再好的规划能力也会浪费在无效动作上；模型能力已经提升，旧Harness反而可能继续把它锁在过时的行为里。

但这篇论文真正有意思的地方，是它逼出了一个生产问题：

如果模型和Harness一起进化效果更好，企业是不是应该让它们永远一起滚动？

今天改Prompt，明天换工具，后天微调模型，再跑一轮联合搜索。Agent每周比上一周聪明一点，似乎很理想。

可真正做过生产系统的人，大概会立刻皱眉。

因为能力的联合优化，和系统的联合演化，完全是两回事。

一、WHALE证明了什么，没证明什么

WHALE证明的是：

在特定模型规模、特定任务、特定验证方式下，模型权重和Harness交替优化，能比各练各的获得更高的任务表现。

它没有证明：

一家企业应该把生产Agent变成一台持续进行模型训练、Harness搜索、环境更新和策略重写的机器。

这两句话之间，隔着工程、成本、组织和风险。

WHALE的核心逻辑是“条件过拟合”。

假设你固定Harness，只训练模型。模型会越来越适应这个Harness的上下文格式、工具入口和控制流；但它学到的能力，未必能穿透Harness本身的限制。

反过来，固定模型去搜索Harness，搜索器会尽力为这颗固定的大脑设计最好的外部脚手架。可模型一旦升级，原先为它量身打造的策略，也可能迅速失效。

阶段式训练的问题正在这里。

先训练模型，再搜索Harness，看似更省事，实际容易得到一个“后手追赶前手”的系统：模型适应旧Harness，Harness又适应新模型，但两边都已经在适应一个不断远去的对象。

WHALE的交替机制，是在减少这种错位。

论文甚至把“什么时候切换”当成一个重要变量。权重更新时间过短，训练信号可能只是噪声；Harness搜索时间过长，又可能让它过度贴合一个即将变化的模型。报告里提到，在数学推理任务上，激进的交替节奏就出现过训练不稳定、提前终止的情况。

这说明WHALE并不是“模型训一会儿，Prompt改一下”这么轻的玩法。

连交替频率本身，都成了一个需要再优化的超参数。

从研究角度看，这很正常。联合优化天然会带来联合调度的问题。

到了生产里，这件事就变得昂贵了。

二、论文里的目标函数很短，生产里的目标函数很长

论文真正优化的目标，可以写成：

J(θ,h)

θ是模型权重，h是Harness。

但生产系统的目标，至少应该写成：

生产效用=任务成功价值-训练成本-上线成本-推理成本-评测成本-维护成本-回归风险-迁移成本-部署延迟

甚至这还不够。

你还得加上数据漂移、权限风险、工具可靠性、用户体验、人工审批、模型供应商切换、合规要求和组织协作成本。

论文里，多拿5个点准确率，通常就是一个很明确的收益。

生产里，多拿5个点准确率可能意味着：

• 多几天训练和回归评测；

  
  

• 多一套模型服务与灰度流程；

  
  

• 多一批难以解释的线上问题；

  
  

• 多一次模型迁移时的重做成本；

  
  

• 多几个没人敢删的Prompt规则和重试分支；

  
  

• 多一层“这段代码为什么存在”的历史债务。

  
  

训练效率，不等于生产效率。

Rollout efficiency，也不等于production efficiency。

这不是要否定WHALE。恰恰相反，WHALE把Agent的真实构成拆得更清楚了，也让生产团队不得不面对一件常被忽略的事：

Agent的能力，是一套系统的能力。

模型、上下文、工具、环境、权限、记忆、评测和运行时，任何一层都可能成为实际瓶颈。

Anthropic在一篇关于Agent评测基础设施的文章里给出过一个很刺眼的数字：仅仅改变资源配置，Terminal-Bench 2.0的成绩就可能拉开6个百分点。硬件、超时、并发、沙箱和集群健康状态，都可能改变Agent的最终得分。

一个榜单上两三分的领先，有时未必代表模型能力差异。它也可能只代表某一方拿到了更大的机器、更宽松的超时，或者更稳定的运行环境。

当Agent开始调用工具、写代码、启动容器、访问数据和多轮迭代后，评测测量的已经不只是模型。

它测量的是整个系统。

三、最昂贵的东西，叫“耦合税”

假设一个团队做出了这样的版本：

模型A17+Harness H23+工具集T11+环境E4

它在自己的任务上效果极好。

A17习惯了H23的上下文切分方式。H23里的工具调用和重试规则，又是根据A17的行为特征调出来的。T11的返回格式，刚好被H23里的解析逻辑处理。E4的沙箱、依赖、超时和权限策略，也已经在评测里跑过数百次。

这个版本很强。

但它开始变得难以移动。

你想换下一代模型，H23不一定还有效。你想从闭源模型迁到开源模型，工具调用习惯和上下文结构都要重新调。你想把这个Agent的能力复用给另一个部门，原先的权限、环境、检索库和规则又不适合。

模型和Harness共同进化时，性能会更好；组件深度互相适配时，替换成本也会更高。

这笔看不见的成本，可以叫“耦合税”。

它不会出现在训练日志里，却会在后续每一次模型升级、工具迁移、产品扩展和故障排查中持续收取。

MLOps长期强调模块化、可组合、可替换、可回滚，本质上就是在控制这种税。

很多Agent团队真正的痛苦，也不是“模型还不够聪明”。

而是系统运行半年之后，里面出现了十几层补丁：

模型输出不稳定，加一次结构化解析；

解析偶尔失败，加一次重试；

重试会死循环，加一个终止规则；

终止太早，又加一个反思步骤；

上下文过长，加一段压缩；

压缩后丢信息，再加一套摘要和记忆策略。

最后，没人说得清哪一段真正创造了价值。

更没人愿意删。

这就是耦合从性能优势，慢慢变成技术债的过程。

四、WHALE的代码复杂度，本身就是一个提醒

WHALE的算法表述很简洁，但实验系统并不轻。

论文公开实现：三个领域、四种训练条件，意味着至少十二条训练与评测路径。SearchQA需要检索服务；数学推理需要代码执行与验证环境；Harness搜索本身依赖模型提议与裁判；不同任务又有各自修改过的训练框架、日志系统和资源调度方式。

这不是对论文的质疑。

恰恰是对论文价值的另一种确认：它研究的对象已经不是一个静态模型，而是一套真实的Agent系统。

“算法上简单”，不等于“工程上简单”。

更重要的是，生产团队并不只需要跑通一次。

他们需要知道：

• 新版本是不是比旧版本好；

  
  

• 好在哪里；

  
  

• 如果变差，是哪一层造成的；

  
  

• 变差后能否回滚；

  
  

• 是否会影响另一个工作流；

  
  

• 能否在不同模型、不同云、不同权限环境下重新部署。

  
  

只要这些问题无法回答，联合优化带来的收益就很难稳定兑现。

所以，生产团队真正要建立的，不是一个永远共训练的流水线，而是一套版本化的能力管理机制。

五、正确姿势不是拒绝共演化，而是把共演化关进发布流程

对大多数企业而言，更合理的路径大概是：

共同设计→冻结→验证→打包→部署

先让模型与Harness在研发阶段共同适配。

Harness可以快速迭代。它改的是提示词、上下文策略、工具调用、记忆和工作流，通常分钟级到小时级就能验证。模型则不必频繁训练，只有当评测明确显示“模型能力本身是瓶颈”时，才启动定向的SFT、LoRA或强化微调。

模型更新后，再做一轮Harness适配。

最后把这一套组合冻结，作为一个完整版本上线。

这可以叫WHALE-lite：承认模型与Harness会互相影响，但拒绝让这种互相影响直接泄漏到生产运行中。

上线的对象，不应该只是一个模型ID。

它应该是一份Agent Release：

模型检查点+Harness代码版本+Prompt/Skills+工具契约+权限策略+上下文策略+记忆策略+沙箱镜像+环境配置+评测合同

这里的“评测合同”很重要。

它规定什么任务集算通过，成本上限是多少，最长执行多久，什么行为需要审批，哪些工具不能碰，失败后怎么判定，回归到什么水平就必须停止发布。

这才是生产Agent的最小交付单元：一份能够被复现、被审计、被回滚的发布包。

联合优化特别适合几类任务：高频、稳定、工具链固定、结果可自动验证、每提升一点准确率都有明确商业价值。

例如封闭领域的代码修复，固定流程下的运维响应，大规模规则审核，稳定检索任务，特定博弈或规划问题。

反过来，如果团队每几周就换一次前沿模型，工具API经常变，任务又依赖主观判断，流量不高，客户需求彼此差异很大，过深的共演化通常不划算。

这种情况下，保持组件可替换，往往比把某个任务刷到极致更重要。

六、Harness不会消失，它会分裂成两部分

未来被淘汰的，并不是所有Harness。

会被快速淘汰的是“认知型Harness”。

这类东西包括提示词脚手架、上下文补丁、为了避免模型犯错而添加的重试规则、为了防止模型过早结束任务而写的控制逻辑，以及各种针对当前模型短板的工作流技巧。恰恰是目前很多人在做复杂工作的地方。

它们本质上都在编码一句话：

“这个模型现在还不会什么。”

模型变强后，这些补丁就可能从助推器变成负担。

Anthropic的案例很典型。较早模型接近上下文上限时，常常会过早收尾，团队为此在Harness里加入context reset。后来更强模型不再表现出这种“上下文焦虑”，旧策略就成了死负担。

另一类Harness，可以叫“系统型Harness”。

它包括身份、权限、密钥、沙箱、持久状态、任务队列、检查点、故障恢复、资源调度、审批和审计。

模型越强，这层反而越重要。这就是DeepSeek Harness下注的点。参见模型之外：Agent Harness的第一次收敛

一个只能生成文本的模型，最多写错几段话。一个可以访问数据库、调用支付接口、修改生产代码、驱动浏览器、长期运行的Agent，出错的半径会迅速放大。

当Agent开始拥有更多“手”，系统就必须更清楚地知道：

这双手是谁的；

它有权做什么；

它刚才改了什么；

中断后从哪里继续；

这件事谁批准过。

Anthropic在Managed Agents中，把会话、Harness和沙箱分开：会话是外部持久事件日志；Harness可以替换；沙箱是可重建的执行环境。按照其披露的数据，这套解耦架构让p50首token延迟下降约60%，p95下降超过90%。

智能会变，模型会变，Harness会变。

状态、权限、隔离和恢复，不能跟着一起变。

参见DeepSeek Harness真正赌的不是插件，而是AI能不能修改自己

七、模型越强，Agent系统可能越复杂

这里还有一个看似矛盾的现象。

模型更强之后，固定任务所需的认知型Harness会减少。过去要用十段Prompt、三次反思和两轮重试才能做完的事，未来可能一次调用就够。

但模型更强，也会让团队愿意把Agent放进更长、更复杂、更接近真实生产的任务里。

原来只让它写一段SQL，现在让它查数据、跑分析、生成报告、发给审批人；原来只让它修一个bug，现在让它读仓库、起环境、改代码、跑测试、提交PR；原来只做单Agent问答，现在开始让多个Agent拆任务、交换产物、调用不同系统。

单次任务的认知脚手架变少了，整个系统的运行时复杂度却上去了。

可以把它理解为一种Harness的“杰文斯效应”。

效率提升没有让系统变简单，反而扩大了系统被使用的范围。

因此，未来Agent基础设施的主战场，是让这些长任务稳定运行。

八、MCP不会成为Agent的TCP/IP

当MCP、A2A、AG-UI、A2UI、Skills一起出现时，很多人都在期待一个统一标准。

这种期待可以理解，但可能带错了方向。

MCP主要解决Agent如何连接工具和数据。

A2A主要解决Agent如何与另一个Agent发现、委托和交换任务。

AG-UI、A2UI则更接近Agent如何把过程和结果交给用户界面、业务系统或人类审批者。

Skills处理的是知识、步骤和领域经验如何被封装。

它们不是一套协议的不同版本，而是在不同边界上工作。更像Web世界里的HTTP、DNS、TLS、OAuth、HTML和JSON，各自解决一段连接关系。

Google推动A2A的初衷也很明确：不同厂商、不同框架和不同组织里的Agent，需要一种协作语言。但A2A不能替代MCP，MCP也不能处理运行时的持久状态、权限、恢复和审计。

真正可能沉淀下来的“窄腰层”，是一组Agent执行语义：

TaskCreated

MessageReceived

ModelInvoked

ToolRequested

ToolReturned

ArtifactProduced

StateChanged

ApprovalRequested

CheckpointCreated

TaskCompleted

这不一定会成为某一份统一标准。

但它很可能会以日志、追踪、评测、运行时和审计系统的形式慢慢收敛。因为只要Agent要进入企业系统，就逃不开几个问题：它现在在做什么，做过什么，谁允许它做，哪里可以恢复，结果能否重放。

比起一套通用的Agent Planning IR，我更相信会先出现Agent Execution IR。

规划本身太依赖模型、任务、工具和实时环境，很难被固定成一个永恒的中间表示。执行过程反而更有机会标准化，因为所有系统最终都需要记录任务、状态、事件、产物、权限与检查点。

LangGraph把checkpoint、interrupt、resume当作生产运行时的基础能力；Google的Agent Runtime也提供了持久沙箱、隔离执行和会话内状态延续。

这些工具表面上各不相同，底层都在解决同一个问题：

让Agent从一次性的模型调用，变成一个可长期存在的软件实体。

九、Agent Bundle和Agent Substrate，可能比Agent OS更接近答案

“Agent OS”这个词很有吸引力，但它容易让人误以为，未来会有一个统一产品包办模型、规划、工具、记忆、界面和运行时。

现实更可能是分层。

最上面是应用与业务工作流。

再往下，是Skills、领域知识、规则和组织策略。

中间是模型相关的优化层：Prompt、Harness、上下文工程、模型适配器、Harness编译器。

再下面，是相对稳定的执行契约：任务、状态、事件、产物、审批、检查点。

最底下才是Agent Substrate：身份、权限、密钥、持久状态、运行环境、沙箱、队列、恢复、可观测性和互操作性。

模型是智能。Harness是行为优化。Substrate是系统存在的条件。

这个分法，可以解释许多看似冲突的行业动作。

模型公司在做原生Agent Harness、SDK、评测和沙箱；云厂商在做身份、运行时、隔离执行和协议；框架公司在做工作流、持久化、观察与调试。

大家都在往下走。

原因也很简单：Prompt可以被复制，某个模型版本也会过期。一个能让企业跨模型运行、跨工具迁移、跨环境审计的底座，更难被替代。

所以，未来最有价值的Agent基础设施，很可能集中在几类能力上：

长期运行的Runtime，包括状态、队列、沙箱和恢复。

可观测性与评测，包括追踪、回放、回归检测、成本分析和数据谱系。

Bundle与版本治理，包括模型、Harness、工具、权限和环境的可部署、可审计封装。

Harness Compiler也可能出现。它输入任务目标、预算、延迟、可靠性和风险约束，输出适配不同模型的Harness。只是这条路技术上很迷人，商业上仍有一个问题：客户究竟愿不愿意把核心行为策略交给另一个自动生成层？

答案还没出来。

但Agent Bundle的方向已经很明确。

以后企业交付的不是“一个GPT应用”，而是一个有版本、有权限、有评测、有环境依赖的Agent Release。

十、WHALE留下的追问

回到WHALE。

这篇论文最容易被记住的部分，是模型和Harness的交替优化。

但如果只把它当作又一个训练配方，就太可惜了。

它其实逼迫我们重新回答一个很基础的问题：Agent到底是什么？

它是模型、Harness、工具、环境、状态和权限共同运行的结果。

在能力层，模型和Harness应该共同设计。谁固定谁，谁就可能成为瓶颈。

在生产层，接口必须尽量解耦。否则，每一次模型升级、工具替换和工作流扩展，都会触发一次昂贵的重建。

在发布层，系统应该被打包。模型检查点、Harness版本、工具契约、权限策略、沙箱环境和评测合同，必须一起被记录。

在基础设施层，执行需要被标准化。任务、状态、事件、审批和检查点，不能每次都随着模型换代而重写。

WHALE讲的是“如何让Agent更强”。

它意外揭开的，是另一件更难的事：

当Agent终于开始变强时，什么东西必须足够稳定，才能让它真的进入生产。

答案是边界。

能力可以耦合，执行必须标准化。