导读： Agent 的 Skills、工具、Hooks 和执行规则可以随时更新，但经过业务微调的模型，未必能正确适应这些变化。淘宝直播团队提出 Harness-Aware Training，让模型在训练时接触不同的 Harness 配置，并通过实验验证了这种方法的价值。Microsoft Agent Lightning 则从另一个角度，研究如何让真实 Harness 参与模型训练。这两项研究提出了一个值得关注的问题：当 Agent 的执行环境持续演进，模型该如何跟上？
假设我们给一个 Agent 配置了查询优惠券的工具，名字叫 coupon_lookup。经过一段时间的训练，它已经能够稳定处理用户关于优惠券的问题。
后来，团队升级了工具接口，将名称改为 coupon_query，同时调整了参数和功能描述。Agent 运行时能看到最新的工具定义，模型权重也没有变化。
按理说，模型应该根据新的工具说明继续执行任务。但如果它在训练中反复见到的都是 coupon_lookup，就可能继续尝试调用旧工具，或者错误理解新接口。
类似的问题还可能发生在 Skills、System Prompt 和 Hooks 上。团队更新了一条业务规则，希望 Agent 立即按照新规则工作；模型却可能继续遵循训练时形成的习惯。
Harness 已经更新，不代表模型一定能够正确适应。
这里的 Harness，可以理解为 Agent 外部的执行框架。它组织模型的上下文、工具、规则和执行流程，也负责必要的检查与反馈。团队可以通过修改 Harness 改变 Agent 的行为，而不用每次都重新训练模型。
最近，我读到淘宝直播数字人团队的一篇研究：《Training Agents to Evolve with Their Harness》。
研究人员发现，当较小的模型长期在固定 Harness 下训练，它可能记住特定的工具名称、Skill 标识和 Prompt 模板。一旦 Harness 发生变化，模型未必能够正确理解新配置。
为了改善这个问题，他们提出了 Harness-Aware Training（HAT）。
这项研究吸引我的地方，是它揭示了一个容易被忽略的工程问题：我们希望 Harness 能快速演进，但模型能否适应这种演进，也需要经过训练和验证。
先看淘宝团队遇到的实际问题。
他们开发的是电商直播数字人，需要实时回答观众关于商品、库存和营销活动的问题，还要根据直播间情况调整互动方式。
这类场景有两个比较突出的要求。
一方面，响应必须足够快。观众正在等待主播回复，模型如果需要很长时间才能给出答案，就会影响直播互动。
另一方面，业务规则经常变化。新的营销活动可能要求调整推荐策略，商品接口可能升级，合规规则也可能更新。
为了让系统快速适应这些变化，淘宝团队设计了一个可演进的 Harness，将运行能力拆成几个独立模块：
这样一来，增加一个 Skill、修改工具描述或调整回复规则，都可以通过 Harness 更新完成。
模型不需要因为每次业务策略变化而重新训练。
但这里出现了一个矛盾。
大模型通常有较强的通用理解能力，面对新的工具定义和指令，可能直接理解并使用。然而，在淘宝团队的实验中，部分强模型的响应延迟无法满足直播需求。
因此，他们需要使用速度更快、经过业务训练的较小模型。
固定 Harness 下的监督微调（SFT）确实能够改善业务表现。问题是，模型可能学会了一些只在训练配置中有效的捷径。
例如，看到某个固定名称就选择对应 Skill，看到熟悉的工具描述就使用记忆中的调用方式，或者习惯了特定的指令排列顺序。
论文把这种现象称为 Surface-form Overfitting，可以理解为对名称、格式和固定表达方式的过拟合。
这还会带来另一个问题：模型在特定业务中变得更熟练，通用指令遵循能力却可能下降。
比如，面对训练中没有见过的新格式要求或回复约束，它可能不如微调之前的基础模型。
于是，淘宝团队需要同时解决两件事：让较小模型具备足够好的业务能力，也让它能适应不断变化的 Harness。
淘宝团队的核心思路其实很容易理解。
既然 Agent 上线后会遇到不同版本的 Harness，那么训练时就不能只让模型接触一套固定配置。
为此，他们设计了 Harness-State Augmentation（HSA），即 Harness 状态增强。
研究人员会对训练中的 Harness 做受控修改，构造出多个不同版本，让模型在这些版本下学习完成任务。
例如，原来的工具叫 coupon_lookup，增强后的版本可能叫 coupon_query。名字和描述可以变化，但工具代表的能力需要保持一致。
对于 Skills，可以重命名、改写规则描述、调整顺序，甚至加入与当前任务无关的干扰项，检查模型能否根据实际内容选择正确 Skill。
对于 System Prompt，可以调整指令的排列方式，也可以在合法范围内修改回复长度、最大交互轮次等约束。
Hooks 则可以模拟不同的错误提醒、重试要求和消息结构，让模型学习收到反馈后应该如何调整。
这些变化有一个重要前提：必须保持任务语义，或者处于明确允许的业务约束范围内。
例如，将商品查询工具改名可以是一种有效的训练增强。但如果新工具实际上改变了业务规则，返回的信息和原来完全不同，就不能简单当成同一任务的等价变体。
这种方法希望减少模型对固定名称和模板的依赖，让它更多根据当前提供的工具、规则与上下文作出决定。
不过，增加训练数据的变化还不够。
淘宝团队进一步把 HAT 组织成三个阶段。
第一阶段：学习不同 Harness 下的正确操作。
团队使用能力更强的模型，在不同 Harness 配置下生成执行轨迹，再筛选质量较好的样本，用于监督微调。
这里还有个值得关注的细节。如果执行轨迹中出现 Hook 错误，模型经过重试后才得到正确结果，研究人员通常会删除中间的错误操作，保留最终正确行为。
他们不希望模型养成先犯错、再依赖 Hook 修复的习惯。不过，也会保留少量完整的重试轨迹，让模型知道如何处理失败反馈。
第二阶段：恢复通用指令遵循能力。
业务微调可能让模型过度适应特定场景。
因此，团队引入 General On-Policy Distillation（通用领域在线策略蒸馏，OPD），以微调前的基础模型作为参考，让当前模型在通用指令任务上进行学习，尽量恢复受到影响的通用能力。
第三阶段：在变化的 Harness 环境中实际执行任务。
前两个阶段主要通过已有示例学习，真实 Agent 却还会遇到工具错误、Skill 选择失败以及 Hook 触发重试等情况。
为此，团队构建了参考生产环境的直播模拟器，让模型在其中执行多轮任务，并通过强化学习（RL）根据反馈改进。
一部分任务使用原始 Harness，另一部分使用增强后的 Harness。这样既保留了对当前生产配置的适应，也让模型接触更多可能出现的变化。
把三个阶段放在一起看，HAT 做了两件很重要的事：让模型在训练中见过更多合法的 Harness 变化，并尽量避免业务训练损害原有的通用能力。
这篇论文最值得关注的部分，是研究人员没有只评价当前 Harness 下的任务表现，还专门测试了模型对变化的适应能力。
我们先看三个模型：
论文报告了以下结果：
| 评测项目 | Base | 固定 Harness SFT | HAT |
|---|---|---|---|
| 直播业务问答综合评分 | 80.3 | 89.5 | 94.8 |
| Harness 变化场景综合评分 | 75.4 | 88.2 | 94.6 |
| IFEval 指令遵循（Prompt-level） | 81.5 | 73.8 | 83.5 |
数据来自论文的 Table 3，使用 Qwen3.6-35B-A3B 系列模型。其中直播业务和 Harness 变化评分采用作者设计、经过人工校准的评判流程，IFEval 使用公开指令遵循基准。三项评分不能简单相加，也不能解释为通用任务成功率。
这组数据说明了一个很有意思的现象。
固定 Harness 微调已经让直播业务问答明显改善，综合评分从 80.3 提升到了 89.5。但与此同时，IFEval 指令遵循分数从 81.5 下降到了 73.8。
模型更适应业务了，在一些通用指令任务上却退步了。
HAT 的表现则有所不同。它在直播业务问答和 Harness 变化评测中继续提高，同时将 IFEval 分数保持在接近、甚至略高于基础模型的水平。
论文还通过消融实验进一步分析各阶段的作用。
其中值得关注的是，仅仅在监督微调阶段加入 Harness 状态增强，就已经改善了固定配置训练造成的部分能力退化。后续的通用蒸馏与强化学习，则继续改善业务表现和指令遵循。
因此，这组结果能够支持的判断是：在论文测试的模型和 Harness 变化范围内，HAT 改善了业务能力、环境适应性与通用指令遵循之间的平衡。
但我觉得，另一组实验更有实际工程价值。
研究人员从真实直播数据中选取了 1,500 个案例，其中 500 个用于分析问题、修改 Harness，另外 1,000 个作为保留测试集。
他们主要修改 System Prompt 和 Skills，然后将完全相同的修改应用于固定 Harness 微调模型和 HAT 模型。整个过程没有重新训练模型权重。
结果是：
两者使用相同的 Harness 修改，却产生了明显不同的结果。
这说明，在这些测试案例中，HAT 模型更能够利用更新后的 Harness 规则改善行为。
当然，这组实验检查的主要是直播回复的自然度、口语化等问题。51.7% 是相对于 HAT 模型修改前错误数的降幅，并不表示 Agent 的总体错误率下降了 51.7%，更不能推广到所有 Coding Agent。
但它提出的问题非常实际。
当我们发现 Agent 有问题，并通过修改 Harness 解决时，模型究竟能在多大程度上理解并执行新的规则？
对于频繁调整 Skills、工具和执行约束的团队，这可能是一项需要单独验证的能力。
论文还报告了淘宝直播的线上 A/B 测试。相较于原有 ReAct 系统，采用新 Harness 方案的实验组，人均商品详情页浏览量相对提高了 0.91%。
这个结果提供了生产实践的补充证据，但测试比较的是整套系统，包括 Harness、模型与其他配置的共同变化，不能把收益单独归功于 HAT。
所以，判断 HAT 的技术价值，我更看重前面的离线对照和相同 Harness 修改实验。
淘宝 HAT 关注模型能否适应变化的 Harness。另一个相关问题是：训练模型时，能不能直接使用真正运行在生产环境中的 Harness？
Microsoft Research 在 《Agent Lightning v1.0: Towards Harnessed Agentic RL》 中研究了这件事，并且公开了 Agent Lightning 的代码实现。
过去，一些强化学习系统会自己控制模型调用和环境交互。要训练某个 Coding Agent，开发者可能需要在训练框架中重新实现它的执行循环。
但真实 Harness 已经越来越复杂。它会管理上下文、调用工具、压缩历史消息，也可能协调多个 Agent。
如果训练时用的是一套简化实现，模型接受训练的环境就可能和实际部署环境存在差异。
Agent Lightning 提出 Harnessed Agentic RL，让真实 Agent Harness 继续管理执行过程。训练系统通过兼容模型 API 的代理接收调用、记录轨迹，再将这些数据转换为训练样本。
这套方案有一个容易被忽略的难点：真实 Agent 的一次任务执行，不一定对应一条连续的模型训练样本。
例如，Coding Agent 阅读代码后修改文件、运行测试，期间 Harness 可能压缩上下文。压缩前后的模型请求已经不再拥有完全相同的历史 Token 序列。
如果训练系统简单拼接这些请求，模型看到的训练上下文就可能与实际执行时不同。
因此，Agent Lightning 需要处理训练样本拆分、Token 对齐和任务级奖励计算等问题，尽量让训练过程准确反映真实执行。
在 Coding Agent 实验中，Microsoft 使用 mini-SWE-agent 和约 6,000 条训练样本对 Qwen3.5-9B 进行强化学习。作者报告，模型在 SWE-bench Verified 上的 Pass@1 从 41.8% 提升到了 56.4%。
这说明直接利用真实 Harness 进行训练是一条可行的研究路线。不过，它与淘宝 HAT 使用的是不同任务、模型和训练方法，实验分数无法直接比较。
把两项研究放在一起，我觉得可以看到两个相关但独立的方向：
淘宝 HAT 研究的是模型如何适应变化的 Harness；Agent Lightning 研究的是如何让真实 Harness 参与模型训练。
前者更关注模型的适应能力，后者更关注训练环境和真实运行环境的一致性。
它们没有共同验证某一套组合方案，但都说明 Harness 已经成为模型训练需要认真考虑的一部分。
读完这两项研究，我首先想到的，并不是团队要不要立即开展模型微调或强化学习。
对于大多数使用现成大模型 API 的团队，更新 Skills、Prompt 和工具后，通常没有条件，也不一定有必要重新训练模型。
但有一件事可以先做起来：为 Harness 的变化建立一套回归验证机制。
我们已经习惯了代码修改后运行测试。Harness 变化实际上也可能改变 Agent 的行为，但很多时候，我们只验证新增规则是否有效，很少系统检查已有任务是否受到影响。
例如，团队修改了一个代码仓库理解 Skill，希望 Agent 能更准确地找到需要修改的文件。
新增的 Skill 在几个样本中表现很好，可是此前能够正确完成的需求，是否会因此检索到错误的文件？其他工具的选择是否受到影响？任务执行的成功率和成本有没有变化？
这些问题都可以通过真实任务回放逐步回答。
我倾向于将 Harness 的变化验证组织成四个环节。
首先，记录 Harness 版本和每次修改的内容。
除了 Skill、Prompt 和工具定义，还需要知道对应的模型版本、上下文配置以及质量检查规则。否则，同一个任务前后表现发生变化，我们可能无法判断原因来自哪里。
其次，建立一小批稳定的历史任务。
挑选具有代表性的真实需求，保存原始输入、必要的工程上下文、任务执行结果以及验收条件。每次修改 Harness 后，使用相同任务进行回放。
这既能检查新规则是否有效，也能发现过去能完成的任务是否退步。
再次，针对 Harness 本身设计变化测试。
例如，修改工具名称和描述、调整 Skill 加载顺序、改变 Prompt 的表达方式，或者模拟不同的 Hook 错误反馈。
这些测试需要保证变化合法，并且有明确的预期结果。否则，我们可能把业务能力改变造成的正常结果差异误判为模型适应性问题。
最后，把执行失败区分为不同来源：是 Harness 定义有问题，模型没有正确理解当前规则，还是工具、环境或验证条件发生了变化。
只有经过这样的分析，才能进一步判断应该修改 Skill、改进工具接口、增加验证规则，还是确实需要投入模型训练。
这套做法是我从论文中提炼出的工程建议，并不代表已经经过 HAT 或 Agent Lightning 的完整验证。
它的价值在于，让 Harness 的演进从依靠少数示例和人工体验，逐步建立起可重复、可对照的验证依据。
更进一步，如果团队持续保存 Harness 变更、任务轨迹、错误恢复和验证结果，这些材料未来还可能用于模型训练或训练效果评估。
不过，那已经是下一阶段的问题。数据质量、隐私、训练成本、奖励设计和适用场景，都需要单独考虑。
回到最初的问题。
Agent 的 Harness 可以快速更新，模型却可能继续按照过去熟悉的方式执行。淘宝 HAT 的研究表明，在特定场景中，可以通过让模型在训练时接触多种 Harness 状态，提高对变化的适应能力；Agent Lightning 则提供了让真实 Harness 直接参与强化学习的工程实现。
对实际研发团队而言，我认为最重要的启发可以先落在一件事上：
每次更新 Harness，我们不仅需要确认新的规则生效了，还应该知道它让哪些任务变好了、哪些任务退步了，以及模型是否真正理解了这次变化。
当这些变化能够被持续记录和验证，Harness 才更容易成为一套可以长期演进的工程能力。
《企业研发 AI 自动化》是我持续记录 AI 进入真实研发流程后的实践系列。
它关注的不只是 AI Coding 工具本身，而是从需求输入、任务表示、Agent 执行到自动化验证的完整链路：AI 如何在真实工程系统里稳定运行，并逐渐形成可复用的研发自动化能力。
欢迎关注和交流～
