模型能力越强，模型之外的那部分越重要。2026 年 10 月，两家公司在同一个月里先后把这个问题摆上了台面：10 月上旬，Google Cloud AI Research 联合西北大学发布论文《Harness²: Recursive Agent Harnessing for an Open World》并开源实现；三周后的 10 月 31 日晚，DeepSeek Harness 团队发布技术文章《Super-agent 设计探索》并开源原型仓库。两家没有引用对方，媒体也把后者简单对标成「对抗 Claude Code」，但把两份材料放在一起读会发现，它们回答的是同一个问题的两个侧面——当模型本身不再是瓶颈，agent 的底座该由什么构成。
更有意思的是，两份答案在一个前提上完全一致：模型权重全部冻结。改进只发生在模型之外。这个共同选择本身就是这个阶段最重要的行业信号。
一、harness：从提示词技巧到系统问题
先统一术语。一个 agent 由两部分组成：模型，和包在模型外面的 harness——系统提示词、记忆、技能、工具、护栏、编排逻辑的总和。同一个模型装进不同的 harness，表现可以差出两位数的百分点；Harvey 的法律基准 LAB 上，Harness² 单步改进就把 GLM-5 的逐条部分通过率拉高 11.8 个百分点（59.6→71.4）。
过去两年，harness 工程以两种形态存在：一种是手艺——每个团队手写提示词、手工调技能文件，靠工程师的直觉迭代；另一种是产品——Claude Code、Codex 这样的成品 coding agent，harness 封装在产品里，用户看不见也改不动。这两种形态在单任务场景下都够用：一次对话、一个任务、一种工具集。
但 agent 的形态正在跨出单任务的边界。个人助手要 7×24 在线、同时推进多件事；专业 agent 要进入办公流程和法律这类高风险领域，任务千变万化。两个新瓶颈随之出现：
- 多任务并发时，瓶颈从模型能力转移到人的注意力。一个人同时盯三五个会话就是上限，再强的模型也救不回来——这是 DeepSeek 那篇文章的出发点；
- 任务分布漂移时，手写的 harness 跟不上。为办公任务调好的提示词，遇到法律任务就失灵；靠人手工为每个领域重新设计 harness，工程量随场景线性增长——这是 Google 那篇论文的出发点。
两家各自接了其中一个。DeepSeek 管调度，Google 管进化。
二、DeepSeek 的答案：调度，或者「注意力的经济学」
DeepSeek 的文章有个反直觉的起点：agent 越自主，越危险的不是它做错事，而是它浪费人的注意力。一个能替全团队干活的 agent，也能耗光全团队的注意力——每条主动汇报、每个不必要的确认提问，都在消耗比算力更稀缺的资源。dsh-superagent-prototype 仓库里的第一篇文档把这写成宪法式的原则："Take as little human attention as possible, and give as much value as possible"——每条消息、每个通知、每个设置项，给出的价值必须超过它消耗的注意力，否则删掉。
围绕这个原则，文章把计算机系统的经典设计逐条搬进 agent 层。调度：常驻 Router 层只分派不干活（甚至可以不配 Bash 工具、用轻量模型），隔离的 Worker 层只干活不对外说话，上下文互不污染。缓存：上下文窗口当内存管理——常用信息直接内联，长文截断后留续读入口，对象之间用 ID 连成引用图、需要时逐跳召回；文章的原话是「浪费上下文窗口，就是浪费模型的智能」。快慢路径：群聊消息、代码评论、CI 结果这类环境事件流是高噪音低触发的，先过程序级准入表快筛，再交给模型慢判。全双工：工具调用改成异步的 start/stop，后台跑长任务时前台随时能接新指令。存算分离与看门狗：计算上云、状态入库、执行环境留在本地设备；主系统之外再挂一个独立的看门狗会话，用模型判断 Worker 是否有实质进展——因为 agent 的常见故障不是进程崩溃，而是陷入无效循环。
这些设计思想媒体已有很多转述；真正值得看的是原型源码——我们把这个仓库（MIT，TypeScript，216 个文件）完整读了一遍，有三层观察是读文章读不到的。
第一，LLM 被系统性关进了三个笼子。 整个系统里模型只出现在三个位置：评估（只读工具，禁 bash、禁委托）、路由（accept/attach/stop/ignore 四选一）、干活（Worker 会话）。其余全部是确定性代码：调度循环是一个两秒一次的定时器，并发合并、重试退避、恢复语义全在代码里。文章没有明说这个设计立场，但代码里最清楚：模型负责判断，状态机负责一切不变量。
第二，授权是一等公民的数据，不是提示词。 每张工作票（Ticket）创建时固化一条不可变的授权记录（Mandate）：谁批的、依据什么、范围多大、当时配置的版本号。改配置时系统逐票计算影响——授权依据失效的工作当场停掉。主动发起的工作默认跑在「只记录不执行」的观察模式，人看着对了才放开。这是我们读过的开源 agent 实现里第一份把「这个 agent 为什么有权做这件事」做成完整审计链的。
第三，代价诚实。 文章自曝实验是合成负载（编码工作用「只耗时工具」代替）、拿更多 token 换时间；仓库 README 第一句就声明这是研究原型而非正式产品，也明言部分设计属未来方向；文章里讨论的 BYOM 跨设备执行和外部看门狗两个模块，代码中未见对应实现——按名称与功能检索全仓库零命中。
三、Google 的答案：进化，或者「无标准答案时怎么改进自己」
Google 的问题意识截然不同：不问怎么调度多任务，而问 harness 本身怎么随任务进化。Harness² 的设定是：执行模型（executor）冻结在现成的编码 agent（OpenCode 或 Codex）里，一个改进者会话（默认 Claude Opus 4.8）观察执行轨迹，直接改写 harness 的八个组件——系统提示词、护栏、长期记忆、工具指引、子代理、技能、脚本、插件。每个组件就是一个文件，所以每次编辑都是一个可审查、可回滚的 diff。八个组件各有激活方式：系统提示词、护栏、记忆、工具指引每次调用都在场；技能只在被触发时才进上下文，不用就不占窗口——按需加载本身就是一层上下文经济。
论文把自己放在一条清晰的谱系里：早期的 harness 优化在训练任务上离线搜出一个好配置再部署（Meta-Harness 一路），静态配置遇到开放世界的任务分布往往失灵；另一路把记忆做成检索（ReasoningBank），把过去轨迹里的策略蒸馏回上下文，但 harness 本身不变。Harness² 主张第三条路：harness 在开放世界里随任务递归进化，而且改进过程自己也要被改进——每个任务结束后，系统用这次改进的完整记录去更新改进机制本身。两级递归都挂在这条主张上：任务级为没有验证器的世界设计对比证据，harnessing 级让改进经验跨任务存续。
难点在于：开放世界的任务没有标准答案，也没有可靠的验证器。你怎么知道一个改动是真改进？Harness² 的答案是对比证据：同一个任务跑一遍参考执行，然后让改进者提出两个候选 harness——一个针对跨领域的通用执行缺陷（规划混乱、工具误用、上下文管理不当），一个针对当前领域的具体知识缺口——两个候选各自在同一个任务上执行，改进者对比轨迹和产出，判断每个编辑是「缓解」「无变化」还是「回归」，最后组合出采纳版本，每个决策绑定具体观察到的行为证据，而不是想象中的分数提升。
任务级的改进只是递归的一半。真正的机关在上面一层：任务完成后，系统回顾整个改进记录，把「什么改动、在什么条件下、解决了什么缺陷」提炼成经验，连同采纳的 harness 一起存入经验库。下一个任务不直接继承上一个 harness——高度定制的 harness 换个任务分布就是噪声——但改进者带着全部经验开始工作。递归改进自己的改进过程，才是这套系统成立的前提。
实验数字的四个正确读法：
- 弱模型受益更大。GLM-5 加一步改进后（64.2→75.7）反超 Gemini 3.5 Flash 的原装 harness（OpenCode 配置 72.4、Codex 配置 74.5，两档都超）；为 Gemini 改的 harness 原样搬给 GLM-5，代码域 +17.3 分。带改进 harness 的弱模型，胜过带原装 harness 的强模型——harness 优化的边际收益对弱执行器更高，这直接影响「买最强模型还是调好外壳」的经济学。
- 经验库是命门。不经参考执行与候选探测、也没有经验库，直接在基础 harness 上逐任务细化，WorkBuddy-Bench 代码域的分数从 73.4 跌到 63.2——大跌来自「无对比证据＋无库」的朴素重改组合（单独去库的细粒度消融在 WorkBuddy 上只掉 3.1 分）；而 k=1 就地累积的库已足以恢复基线。对比证据与经验沉淀，缺一不可。
- 递归 k=2 已超过基线的 k=5（在 WorkBuddy 的代码与办公两域）。并行与串行两种递归跑到 k=2，就已超过图中两条基线（检索记忆 ReasoningBank 与逐任务改写的 Harness Scaling）跑到 k=5 的成绩——收益来自「改对东西」，不是堆叠重改；论文的算力–成绩 Pareto 图中，参与算力对比的两种 Harness² 配置都落在前沿上。同样把额外推理预算花在逐任务重改上的 Harness Scaling，12 组基准×配置组合里 7 组低于基线。
- 同一模型当自己的改进者也成立。从 GLM-5 到 Opus 5，executor 和 editor 用同一个模型的五组同模型配对全部提升——不依赖一个更强的模型来当老师。
这套系统在实现层的防作弊设计同样值得记录：改进者拿到的证据全部以文件形式放在隔离的工作目录，一个守卫函数拒绝交接任何含评分标准、评分结果的内容——文件名和正文双重扫描，连 agent 自己写出的 harness 也要先过同一道检查才能入库。被污染的文件，此后不能再作为证据发给后续任务。
代价同样要诚实说：每一步改进意味着候选 harness 各自完整执行一遍任务，k=5 的递归就是五倍的执行开销加改进者会话成本；论文承认并行只降延迟不省算力，并在失败分析里列了九个回归案例——选择会选中更弱的候选（55 分的输出胜过了 95 分的），错误的前提会跨候选传播。
四、对位：同一个系统的两个器官
| 维度 | DeepSeek Super-agent | Google Harness² |
|---|---|---|
| 回答的问题 | 多任务并发下，谁来调度 | 任务分布漂移下，谁来改进 |
| 冻结什么 | 模型 | 模型（executor 与 editor 可以是同一个） |
| 不变量由谁保证 | 代码状态机（单写者引擎、Mandate、准入矩阵） | 对比证据纪律（行为对比、经验库、守卫函数） |
| 状态跨任务靠什么 | Thread/Ticket 引用图＋订阅直通 | 经验库（采纳的 harness＋EXPERIENCE.md） |
| 改动发生在哪 | 会话调度与授权层 | harness 文件本身（每次编辑是 diff） |
| 开源形态 | MIT，研究原型，非正式产品 | Apache-2.0，论文级实现，活跃维护 |
| 自认的未竟事项 | BYOM、看门狗未实现；实验是合成负载 | 库管理、自适应预算列为 future work；九个回归案例待解 |
拉远看，两份答案的共同点比分歧更根本。都不动模型权重——把改进保持在文本和代码层，意味着每次改动可 diff、可审查、可回滚，这是任何权重更新都不具备的工程属性。都把不变量的保证移出了模型——DeepSeek 把模型关进三个笼子、调度交给定时器；Google 的改进者本身就是 LLM，但它的判断被约束在「对比证据＋绑定观察」的框架里，产出入库前过守卫检查。
两家都显式设防，对象不同——DeepSeek 把所有外部输入标注为不可信数据、评估会话禁 bash，防的是提示词注入；Harness² 拒绝让任何评分信息进入模型上下文，防的是考题泄漏。两家在不同的路上走向同一个认识，Anthropic 的「脑手分离」提法（DeepSeek 文章明确引用）提供了一个旁证：agent 底座的可信度，来自模型裁量范围之外的确定性结构。
分歧在时间尺度上。调度解决的是任务进行时的问题——多个工作项同时推进，注意力怎么分配、授权怎么流转；进化解决的是任务之间的问题——上一个任务学到的东西，怎么让下一个任务做得更好。一个管运行，一个管迭代。
所以真正的问题不是「哪家对」，而是这两份答案什么时候合流。一个持续在线、同时推进多任务的 agent，必然也需要它的 harness 随任务进化——Super-agent 的提示词、准入规则、技能与子代理配置，本身就是 Harness² 意义上的八组件；反过来，Harness² 的改进者在多任务环境里跑，也需要调度、授权和注意力管理。调度和进化是同一个系统迟早都要长出的两个器官。两家都开源了（MIT 和 Apache-2.0），等于把两块积木都放进了公共域——大厂各自押注垂直栈，拼装别人的积木不构成差异化动力，把两块拼起来的工作，更可能发生在下游。
五、判断
「harness 工程」正在从手艺升格为学科。 两份独立证据：Super-agent 把九篇设计文档当代码管（有一个测试文件专门验证架构文档与实际代码文件一致）；Harness² 的每次改进者会话都带成本审计字段（美元成本、是否命中缓存、尝试次数），改进本身被当作可度量的工程过程。提示词技巧时代没有这些——当一个领域开始做一致性和成本核算，它就成了工程学科。
参照实现的卡位战已经开打。 DeepSeek 自 8 月以来的三个月里连落三子：8 月开源 Harness 运行时，10 月中旬开源推理引擎 DeepInfer，10 月底亮出 Super-agent 架构（原型仓库上线三天约 1.4 万 stars）；Google 用论文级实现加 Apache-2.0 定标准。底层定义权的争夺从模型层上移到 harness 层——这里的开源不只是姿态，是先手。
对开发者的直接含义：弱模型加调好的 harness，是一笔被低估的交易。 GLM-5 改进后反超 Gemini 原装、跨模型迁移 +17.3 分、同模型自改全线成立——模型采购的性价比公式正在被 harness 优化的边际收益改写。这在推理成本占大头的 agent 场景里，是实打实的钱。
验证点也立在这里：Harness² 自认的库管理和自适应预算（按任务难度分配探索深度）什么时候补上；Super-agent 文章承诺的 BYOM 和看门狗什么时候从设计变成代码；以及第一份把调度与进化拼在同一系统里的开源实现出现在哪里。两家都把未竟事项写得明明白白——这批工作的另一个共同点，是把「我们还做不到什么」当作论文和代码的一部分发出来。
信源
- Harness² 论文 arXiv:2610.14224（2026-10-09）；代码 github.com/google-research/harness2（Apache-2.0，140 文件）
- dsh-superagent-prototype github.com/deepseek-ai/dsh-superagent-prototype（MIT，216 文件）；DeepSeek Harness 团队《Super-agent 设计探索：迈向更自主的 Agent 系统》（2026-10-31，经智东西等媒体全文转载）
- 两个仓库全部源文件于 2026-11-03 拉取核读，文件数与星标数均为当日读数（两仓库持续更新中）；实验数字取自论文正文与附录