从今天觉醒,技术赋予每一个人数字生命
Harness-Zero 精读：当“外挂”能被蒸馏进权重，Agent 还需要专属脚手架吗？
同一个模型，换一套 Harness，任务成功率能从 20% 出头跳到 40% 以上——这是当下 Agent 工程里一个既让人兴奋又让人头疼的事实。兴奋在于，模型之外的系统提示词、工具调用循环、文件系统、沙箱与反馈机制，确实能实打实抬高上限；头疼在于，这份收益被死死绑在部署时的那套 Harness 上。换个领域、换个实例、甚至换个基础模型，最优 Harness 就可能完全不同。
Harness-Zero 这篇工作要回答的核心问题很直接：能不能把“某个专用 Harness 带来的增益”从 Harness 里抽出来，塞进模型权重，让模型在部署时只挂一个固定的通用 Harness 也能保留这份能力？ 顺着这个问题往下读，我们会看到一条从“优化 Harness”到“Agent 即 Harness”再到“微调内化”的完整数据流。
① 技术背景：Harness 是模型的“外骨骼”，也是它的“天花板”
先把概念钉死。在 Agent 语境下，Harness 指模型之外、负责中介模型与环境交互的整套系统：系统提示词、工具定义与调用循环、上下文管理、文件系统与沙箱、编排逻辑、钩子中间件、反馈与重试策略。用一句流行的话概括——只要不是模型权重本身的那部分代码、配置和基础设施，基本都可以算 Harness。
这带来一个结构性矛盾。Harness 的收益是真实的，但它是“条件收益”：在领域 A 上精心演化的 Harness，到了领域 B 可能反而拖后腿；针对某个实例调优的提示词与工具集，换个实例就失效。一个通用 Agent 只有两条路：要么忍受一套次优的共享 Harness，要么在越来越多的专用 Harness 之间做路由——后者在工程上会迅速退化成维护噩梦。
Harness-Zero 的切入点因此很聪明：既然 Harness 的收益本质上是“诱导出了模型的某些行为”，那能不能把这些行为直接写进权重？这就是 harness distillation（Harness 蒸馏）。难点在于，源 Harness 与目标 Harness 的动作空间和可见信息都不一样，源 Harness 的轨迹不能直接拿来当目标 Harness 的监督信号——这是整篇论文必须绕过的第一道坎。
② 主流方案盘点：三条技术路线
路线一：Code-as-Harness（代码即 Harness）。 用可执行代码/脚本把 Harness 逻辑固化下来，让模型生成或调用代码来完成环境交互。职责是“用代码表达动作序列”，代表做法是各类代码解释器型 Agent 框架。优点是动作精确、可复现；缺点是动作空间被代码语法绑死，跨 Harness 迁移时几乎无法复用监督信号。
路线二：Evolved/Specialized Harness（演化式专用 Harness）。 针对特定领域或实例，用搜索、演化或人工调优的方式打磨一套专用 Harness。职责是“把领域知识压进外部系统”，是当前提升 Agent 表现最直接的手段。优点是上限高；缺点是收益不可迁移，部署时一旦摘掉就打回原形。
路线三：Harness-Zero 的 Agent-as-Harness。 关键抽象是引入一个“harnessing agent”：它受优化后的源 Harness 指导，在目标 Harness 的动作空间里先对学生的回答做纠正，再交给目标 Harness 执行。这样，源 Harness 的指导被翻译成了目标 Harness 可执行的演示轨迹，再通过对这些轨迹做微调，把行为内化进权重。部署时，专用 Harness 可以整个移除。
③ 对比与优劣
| 核心职责 | 用代码表达动作 | 把领域知识外置 | 把外置知识翻译成可训练演示 |
| 收益是否可迁移 | 弱 | 几乎不可迁移 | 强（内化进权重） |
| 部署依赖 | 需保留代码层 | 必须保留该 Harness | 可移除专用 Harness |
| 主要成本 | 动作空间受限 | 每领域重复调优 | 需要纠正 Agent 与微调算力 |
| 典型风险 | 跨域复用差 | 路由爆炸 | 纠正质量决定蒸馏上限 |
论文给出的实验信号值得记住：在前沿模型使用同一套演化 Harness 时，agent-as-harness 优于 code-as-harness；移除专用 Harness 后，基础模型的宏平均任务成功率从 23.3% 提升到 44.3%，甚至超过挂着该 Harness 时的 41.7%；在三个领域的 28 种行为模式上，平均恢复了 82.3%。这说明“蒸馏出的行为”不只是拟合了轨迹，而是真的补上了基础模型缺失的能力。
④ 选型建议：按场景而非按潮流
场景一：多领域通用 Agent 平台。 推荐 Agent-as-Harness 路线。你不可能为每个租户维护一套专用 Harness，把领域收益蒸馏进一个固定目标 Harness 下的模型，运维复杂度最低。
场景二：单一高价值垂直任务（如特定科研流程）。 直接用专用 Harness 更划算，调优成本可被任务价值摊薄，蒸馏反而多一层不确定性。
场景三：教学/作品集项目。 建议先手写一个最小 Harness 循环（提示词 + 工具 schema + 重试），再尝试用“纠正 Agent”生成几十条演示做小规模微调。这一小段能力足以写进作品集：你能说清“外部系统增益如何转化为模型能力”这件事。面试常被追问的点是：源与目标动作空间不一致时监督信号怎么对齐？Harness-Zero 的答案是“让纠正发生在目标动作空间里”，这个思路值得你用自己的话复述一遍。
⑤ 未来展望：趋势与未解问题
趋势已经清晰：Harness 正从“手工配置”走向“可演化、可蒸馏、可路由”的三层结构，模型与外部系统的边界在被重新谈判。但仍有硬问题没解决——纠正 Agent 的质量上限如何保证？蒸馏后的行为在分布外实例上是否稳定？当目标 Harness 本身也要演化时，权重里的行为会不会再次失配？对学习者而言，现在最值得练的不是背某个框架的 API，而是理解“动作空间对齐”这个抽象，它会在未来很长一段时间里反复出现。
