腾讯财报里提到的 Harness,到底是什么?最近腾讯发了财报，其中有一段提到了 Harness。 管理层解释 WorkBuddy 的时候，提到平台底层有一个Harness 编排层，可以灵活调用不同模型和开发者技能，去处理复杂的 Agentic 任务。 财报出来以后，有朋友问我，Harness 到底是什么？ 这个词最近确实越来越常见。 中文怎么翻，我也没觉得哪个特别好。有人叫智能体调度，有人叫运行框架，腾讯这里用的是“编排层”。 最近刚好在看一篇论文，名字就叫Harness-R1。 https://arxiv.org/html/2608.02276 就顺着这篇聊一下。 后面有时间的话，也想不定期写点最近看到的 AI 论文。不一定追热点，主要写点我自己看完以后觉得有意思的。 Reddit 上关于 Harness 也有不少讨论，有兴趣可以自己翻： https://www.reddit.com/r/AI_Agents/comments/1ujigq2/a_lot_of_conversation_around_harness_engineering/ https://www.reddit.com/r/AI_Agents/comments/1sagti5/removing_llamaindex_mcp_and_rag_made_our_agent/ 我第一次看到 Harness 这个词，其实没觉得是什么新东西。 如果平时有用 Claude Code、Codex 这些 Coding Agent，很多东西早就在里面了，只是以前没统一叫这个名字。 比如你让 Codex： “帮我看看这个项目为什么编译不过。” 它不会只回答你一段文字。 它会读文件，搜代码，改代码，跑编译。 编译炸了，再看报错，继续改。 中间还会调用 Shell、Git、Python，可能折腾十几轮。 真正负责“想下一步干什么”的当然还是模型。 但怎么把文件给它看，允许它调用什么工具，工具跑完以后怎么把结果塞回来，Context 太长了怎么压缩，连续做几次蠢事以后要不要打断，这些都不是模型自己凭空完成的。 这已经是一套系统了。 所以我现在理解 Harness，比较简单： 模型外面那套负责让 Agent 真正跑起来的东西。 Tool、Memory、Context 管理、权限、重试、检查、状态管理这些，都可以往里面装。 定义肯定没这么严格，不过理解这篇论文已经够用了。 Memory 也是类似。 模型不是天然“记得以前发生过什么”。 很多时候只是系统把过去某些东西重新找出来，塞回 Context，让模型这一次又看见了。 所以为什么现在大家开始讲 Context Engineering、Memory Engineering、Harness Engineering，其实是一回事。 模型越来越强以后，注意力慢慢开始从“这个模型会不会做”转到另一个问题： 怎么让它稳定地做出来。 这两个东西差别挺大的。 一个模型偶尔成功一次，和连续跑 100 次都不出问题，不是一回事。 举个论文里的例子就很好懂。 一个购物 Agent，要买符合要求的商品。 东西其实已经找对了，价格也没问题。 但有个规格没选，它直接 Buy Now 了。 任务失败。 怎么办？ 最直接当然是训练模型，让模型以后聪明一点： 下单之前记得检查规格。 但其实还有一种非常程序员的解决办法。 直接在 Buy Now 前面卡一下。 规格没选，不让买。 把这个动作拦下来，告诉模型先把规格选了，然后继续跑。 模型本身一个参数都没改。 最后任务却成功了。 论文里确实有这样的案例：原来的 Agent 找到了合适商品，但没选颜色就买；加了 pre-action 的 guard 以后，第一次购买被拦下来，Agent 随后选了正确颜色，再完成购买。 看代码的人应该会觉得，这也没什么神奇的。 确实。 传统软件工程里 Validator、Guard、Retry、State Machine 这些东西早就有了。 所以 Harness-R1 真正让我觉得有意思的地方是另一个问题： 以前这些规则都是人写的，现在能不能让 AI 自己学着改？ 论文就是在干这个。 它先放一个正常的 Agent 去做任务。 Agent 会失败。 失败轨迹留下来。 然后另外搞一个模型，作者叫它Harness Engineer。 名字挺唬人，我看下来更愿意把它理解成一个专门修 Agent 的程序员。 它看 Agent 刚才是怎么死的，然后去改 Agent 外面的 Harness。 比如： 找到商品 → 没选规格 → 直接购买 → 失败。 它可能就加一段购买前检查。 修改完，不是找另一个大模型过来看两眼，然后说“嗯，这段代码挺合理”。 是真的重新跑。 跑完成功率高了，这次修改有用。 跑完更差，那就是改坏了。 目标 Agent 本身的权重在这里是冻住的。 论文里 Qwen3.5-9B 在三个环境上的平均成功率，默认 Harness 是 44.3%，Harness-R1 做完以后是 53.6%。 9 个点的提升当然不错。 我更感兴趣的是，它把以前没什么用的失败记录又榨了一遍。 以前 Agent 任务失败，日志看完，修 Bug，结束。 现在是： 失败本身也可以变成训练数据。 而且训练的不一定还是原来那个模型。 也可以训练一个“专门负责修它周边系统”的模型。 看到这里，就绕到 RL 了。 我第一次接触 RL 的时候，其实一直拿量化去理解。 不完全一样，但很多研究习惯非常像。 做量化的时候，我们也不知道一个策略到底有没有用。 脑子里先有个逻辑，写出来，回测。 收益多少，回撤多少，Sharpe 多少。 不好，扔掉或者继续改。 很好，也不能马上高兴，先怀疑自己是不是哪里写了未来函数，或者参数调过头了。 Harness-R1 也是这种味道。 Harness Engineer 写出来的代码到底有没有用，不看它解释得多漂亮。 跑。 原来 100 个任务成功 40 个。 改完成功 50 个。 那就有东西。 改完剩 30 个。 那就是瞎改。 这里最后得到的这个分数，就是 Reward。 所以 RL 我觉得第一遍完全没必要先去啃一堆公式。 先这么理解就行： SFT 是给答案，RL 是给结果。 SFT 更像是把历史上一堆优秀案例整理好： 这种情况应该这么做，这种情况应该那么做。 模型照着学。 RL 就有点像把策略直接扔进回测。 我不知道你到底应该怎么写，但最后净值曲线会告诉我这套东西行不行。 Harness 这种问题其实挺适合 RL。 因为同一个错误可能有很多修法。 改 Context 可以。 拦 Tool 可以。 加一个 Validator 可以。 失败以后做 Recovery 也可以。 提前让人手工写一个“标准答案”，反而有点奇怪。 那就都跑一下。 Harness-R1 用的是 GRPO。 这个词最近估计还会经常看到。 Group Relative Policy Optimization。 我自己的理解一直比较粗暴： 同一道题多给几个方案，然后内部比。 比如一个失败，模型一次给 8 个 Harness Patch。 这个 +2，那个 +8，还有一个直接 -5。 那 +8 当然值得多学一点，-5 以后少来。 这里又会冒出来一个词叫 Advantage。 这个拿量化来举例就很好理解。 一个策略今年赚 10%，算不算好？ 不知道。 如果同时期 QQQ 跌了 20%，当然不错。 如果同时期 QQQ 涨了 40%，那这个 10% 就没什么好吹的。 所以不能只看绝对收益，还得看相对表现，这在量化里面叫超额收益。 GRPO 这里也是这样。 不是单看一个 Patch 拿了多少 Reward，还看它在这一组 Patch 里表现怎么样。 PPO、Clip 那些公式我觉得第一次看这篇完全可以先跳过去。 大概知道是在控制训练别一下子改太猛就够了。 反正做量化的人应该很容易理解这种警惕。 某组参数过去十年特别牛，不代表明天应该直接把全部仓位梭进去。 有时候结果太好，反而得多看两眼。 说到这里，论文后面那个 Ablation Study 我看着也很亲切。 消融实验。 写过量化的人应该都很熟悉了。 简单理解就是拆因子。 一个策略里有价值、动量、质量、低波。 最后收益很好。 那到底是谁贡献的？ 把动量拿掉，重新跑。 收益直接塌了。 行，动量看来比较重要。 把质量拿掉，曲线基本没动。 那这个质量因子到底有什么用，就得问一下。 Harness-R1 也这么干。 它的 Harness 可以在几个不同位置介入 Agent。 比如模型真正执行动作之前可以拦一次，工具返回结果以后也可以做恢复。 作者把这些位置一个个拆掉重新测。 拿掉 pre-action，平均成功率掉 3.9 个百分点；拿掉 post-feedback，掉 3.3 个点，这两个影响最大。 看到这里，基本就知道这套东西的收益主要从哪里来了。 不过再往后，我第一反应还是老毛病： 过拟合没有？ 量化搞多了可能都有这种条件反射。 一个回测如果特别漂亮，我现在一般不会先想发财了。 先看 Out-of-sample。 尤其那种 MA 37 天最好，36 天一般，38 天也不行；止损 7.83% 天下无敌，改成 7.5% 就扑街。 这种结果我反而害怕。 Reddit 的量化讨论里也经常有人拿这种参数稳定性判断过拟合：一个参数 15 天很好，改成 14 天突然很差，本身就是个红旗。 Harness-R1 这里同样有这个问题。 它先看这批失败任务，再针对这批任务修改 Harness，然后重新跑。 那很自然就会问： 是不是把这几道题做熟了？ 换一批没见过的呢？ 换个模型呢？ 所以我觉得这篇后面的泛化实验，其实比 44.3% 到 53.6% 更值得看。 作者又拿了 20 个训练时没见过的 target configuration 去测，平均仍然提高了大约 7.06 个百分点，而且 20 个 target 的平均变化都是正的。 这当然不能说明“问题解决了”。 但至少比只给训练任务看一条漂亮曲线强。 论文还做了 held-out task 的测试。 我看论文现在基本都有这个习惯。 Benchmark 上涨了以后，第一件事情不是问涨了多少，而是问： 这个 gain 到底从哪来的？ 数据有没有泄漏？ 换一批题还在不在？ 参数稍微动一下会不会塌？ 和看量化策略越来越像。 最后再回来看腾讯为什么要在财报里专门提 Harness，我觉得就比较容易理解了。 模型当然还是最重要的东西之一。 但到了 Agent 时代，模型已经没办法单独解释最终体验了。 同一个模型，Tool 怎么给，Memory 怎么做，Context 怎么管理，失败以后怎么恢复，危险动作什么时候拦，结果怎么检查，最后差距可能很大。 甚至现在 Reddit 上做 Agent 的人已经开始抱怨，真正费时间的不是那个 Agent Loop，本身反而只占很小一部分，麻烦的是外围那些工具、状态、定时任务、错误恢复和验证。 这也是为什么腾讯把 Harness、模型选择、技能库三个东西并列放在一起，我觉得挺合理。 以前大家问一个 AI 产品强不强，很容易直接问： “底层什么模型？” 以后这个问题可能越来越不够用了。 模型一样，不代表东西一样。 Harness-R1 又比普通 Harness Engineering 多走了一小步。 以前是： Agent 犯错，人发现，然后人改系统。 现在想试的是： Agent 犯错，另一个 AI 看完，然后 AI 自己去改系统，再重新跑。 离什么“AI 自我进化”当然还远。 这篇现在能改的位置还是有限的，而且每生成一个 Patch 都要把任务重新跑一遍，算力成本也摆在那里。 但这个方向我会继续看。 我现在比较感兴趣的已经不是单纯“下一代模型 Benchmark 又涨了几分”。 反而是这些模型出来以后，大家到底还能在外面套些什么东西。 有时候模型没换，AI 也能强很多。 就这样吧~
