Harness-Zero：将智能体脚手架蒸馏进模型权重的技术实践

1. 从外挂脚手架到内化本能Harness-Zero 到底想解决什么问题第一次看到 Harness-Zero 这个标题我脑子里蹦出来的画面是攀岩。一个攀岩高手在爬一条极难的线路时身上挂满了快挂、绳索、保护器这些装备帮他完成了一次漂亮的攀登。但如果有一天把这些外部装备全部撤掉他还能不能爬上去Harness-Zero 想干的事情本质上就是回答这个问题——把智能体Agent身上那些外挂的专用脚手架Harness行为通过蒸馏的方式直接刻进模型权重里让模型自己就长出这套能力。这个思路为什么值得聊因为现在绝大多数智能体系统本质上都是模型 外部脚手架的组合。模型负责理解和生成脚手架负责规划、工具调用、状态管理、错误重试、格式约束这些脏活累活。你搭一个能查数据库、能调 API、能多步推理的智能体往往要写几百上千行的编排逻辑用 LangChain、Dify、Coze 这类框架把模型架起来。问题是这套脚手架是通用的、外部的、和模型本身解耦的。换一个模型脚手架可能就不灵了脚手架写得越复杂延迟越高、成本越大、出错点越多。Harness-Zero 的核心主张是与其在模型外面套一层又一层脚手架不如让模型在训练阶段就见过这些脚手架的行为模式把脚手架的决策逻辑蒸馏进权重。这样推理时模型自己就能完成原本需要外部编排才能做到的事情。打个比方这就像教一个徒弟做菜——以前是你站在旁边一步步指挥外部脚手架现在是你把整套流程反复演示给他看让他形成肌肉记忆蒸馏进权重最后他自己一个人就能掌勺。Agent-as-Harness这个提法是理解整个项目的钥匙。它把智能体本身当作脚手架来看待——也就是说一个已经调好的、带完整外部编排的智能体系统它的行为轨迹怎么规划、怎么调工具、怎么纠错、怎么收尾本身就是一份高质量的教学数据。Harness-Zero 要做的就是把这些行为轨迹收集起来用蒸馏的手段让一个裸模型学会这套行为。学成之后这个模型不再需要那套外部脚手架自己就能扮演一个完整智能体的角色。适合谁来读这篇如果你正在做智能体开发、智能体搭建或者你在用 Dify、Coze 这类平台搭工作流又或者你在研究模型蒸馏、知识蒸馏的技术路线那这套思路对你会有直接启发。哪怕你只是好奇为什么有些智能体不用排队、响应那么快理解 Harness-Zero 的动机也能帮你把很多现象串起来。接下来我会从设计思路、核心细节、实操流程、踩坑排查四个层面把这件事掰开揉碎讲清楚。2. 内容整体设计与思路拆解为什么是蒸馏而不是继续堆脚手架2.1 外部脚手架的三个死穴要理解 Harness-Zero 为什么选蒸馏这条路得先看清楚外部脚手架到底卡在哪。我做过不少智能体项目脚手架的问题基本集中在三个地方。第一个死穴是通用性与专用性的矛盾。一个脚手架框架为了适配尽可能多的场景必须做得足够通用——它得支持各种工具调用格式、各种规划策略、各种状态管理方式。但具体到某一个任务比如帮用户查订单并处理退款真正需要的逻辑可能只有那么几步通用框架里 90% 的代码都是冗余的。冗余带来的是延迟和不确定性每一步编排都要经过框架的解析、路由、校验链路越长出错概率越高。第二个死穴是模型与脚手架的耦合脆弱性。脚手架里往往写死了很多针对特定模型的 prompt 模板、输出格式假设、工具调用约定。你换一个模型这些假设可能全部失效。我见过太多团队脚手架调得好好的模型一升级整个智能体就崩了因为新模型对 prompt 的响应方式变了或者工具调用的格式偏好变了。这种耦合让系统极其脆弱。第三个死穴是推理成本与延迟。外部脚手架意味着每一轮交互都要走模型生成 → 框架解析 → 框架决策 → 再喂给模型的循环。多步任务下这个循环可能跑十几轮每轮都有额外的 token 开销和网络往返。用户等的是秒级响应你给的是十几秒体验直接崩盘。2.2 蒸馏的本质把过程知识压进参数知识Harness-Zero 的破局点在于它认识到脚手架里真正有价值的东西不是那些代码框架而是行为模式——也就是在什么情况下该做什么决策的知识。这种知识本质上是可以被模型学习的。这里要区分两种知识。一种是参数知识就是模型权重里已经存着的东西比如语言能力、常识、推理能力。另一种是过程知识就是先做什么、再做什么、遇到什么情况怎么调整的流程性知识。传统脚手架承载的是过程知识而 Harness-Zero 想做的是把过程知识蒸馏进参数知识里。蒸馏在这里的用法和传统知识蒸馏略有不同。传统知识蒸馏通常是大模型教小模型让小的学大的输出分布。而 Harness-Zero 的蒸馏是带脚手架的智能体教裸模型让裸模型学会脚手架的行为轨迹。教师信号不是 soft label而是完整的行为序列——包括规划步骤、工具调用、参数填充、错误处理、终止判断。这更接近行为克隆Behavior Cloning的思路但结合了蒸馏的框架。为什么这个思路成立因为大模型本身已经具备了很强的潜在能力它缺的往往不是能力而是知道在什么场景下该调用哪种能力。脚手架做的事情很大程度上就是在替模型做能力调度。如果能把这种调度模式教给模型模型自己就能完成调度脚手架就可以撤掉了。2.3 Agent-as-Harness把智能体当数据工厂Agent-as-Harness 这个设计最巧妙的地方是它把已经调好的智能体重新定位成了数据生产器。传统思路里智能体是最终产品脚手架是它的支撑结构。而 Harness-Zero 的思路里智能体是教师它的行为轨迹是教材最终产品是一个不需要脚手架的裸模型。这个视角转换带来几个好处。第一数据质量有保障。脚手架调好的智能体它的行为轨迹是经过验证的、能跑通的、有明确成功信号的。这比从零构造训练数据靠谱得多。第二覆盖场景广。一个通用智能体框架能处理的任务类型很多收集到的轨迹天然覆盖多种场景。第三可迭代。脚手架可以不断优化优化后的行为轨迹可以持续蒸馏进模型形成脚手架改进 → 模型提升 → 脚手架可以更简单的正循环。我个人的判断是这个思路特别适合那些任务模式相对固定、但调用频繁的场景。比如客服智能体、销售智能体、代码检视智能体这类它们的交互模式有很强的规律性脚手架里沉淀的决策逻辑高度可复用蒸馏的性价比极高。反过来如果是那种每次都要全新推理的开放任务蒸馏的收益就没那么大因为过程知识本身就不固定。2.4 方案选型的取舍为什么不直接微调有人可能会问既然是要把行为教给模型为什么不直接拿轨迹数据做监督微调SFT非要叫蒸馏我的理解是两者在 Harness-Zero 里其实是融合的但蒸馏这个词更准确地描述了它的核心机制——教师信号的构造方式。直接 SFT 通常是用输入-输出对来训练模型学的是给定这个输入输出应该是什么。但 Harness-Zero 要教的是给定这个状态下一步该做什么决策这是一个序列决策问题。它的教师信号不是单个输出而是整个决策序列而且往往带有为什么这么决策的隐式信息比如工具调用的参数是怎么从上下文推出来的。这种信号更接近蒸馏里软目标的概念——它传递的不只是答案还有答案背后的推理路径。另外蒸馏框架允许引入温度、软标签、多教师等机制能更细腻地控制知识迁移的过程。比如可以让多个不同配置的脚手架智能体同时当教师取它们的共识行为作为学习目标这样学出来的模型更稳健。这些是纯 SFT 不容易做到的。3. 核心细节解析与实操要点蒸馏管线怎么搭3.1 教师智能体的构造脚手架要调到位整个 Harness-Zero 管线的第一步是把教师智能体调好。这一步的质量直接决定最终模型的上限。我的经验是教师智能体不需要追求最强但一定要追求最稳和最可解释。具体来说教师智能体的脚手架要满足几个条件。行为可记录每一步的输入状态、决策动作、工具返回、中间结果都要能完整落盘。决策可复现同样的输入教师的行为要基本一致不能今天这么调工具、明天那么调否则蒸馏出来的模型会学到矛盾的行为。成功可判定每个任务要有明确的成功/失败信号这样才能筛选出高质量轨迹。在工具选型上我倾向于用那些行为透明的框架。比如 Dify 这类平台它的工作流节点是显式的每个节点的输入输出都能拿到很适合做轨迹采集。而一些高度封装的框架内部决策过程是黑盒采集轨迹就很困难。如果你在用 Coze 搭智能体也要注意把关键节点的日志打开否则后面蒸馏时拿不到细粒度数据。提示教师智能体的 prompt 要尽量显式化。也就是说把原本隐含在模型直觉里的决策逻辑尽量写成明确的规则或步骤。这样采集到的轨迹才有清晰的行为模式可学而不是一堆模糊的、难以归纳的输出。3.2 轨迹采集采什么、怎么采、采多少轨迹采集是 Harness-Zero 里最耗工程的一环。采什么我建议至少采集四类信息状态当前上下文、历史动作、工具返回、动作调用了什么工具、传了什么参数、生成了什么文本、结果工具返回什么、任务是否推进、元信息时间戳、轮次、是否成功。怎么采最稳妥的方式是在脚手架层做拦截。所有工具调用、所有模型生成、所有状态变更都经过一个统一的记录中间件。这样采集是自动的、无侵入的不会因为采集逻辑影响教师行为。我见过有团队直接在 prompt 里让模型顺便输出决策理由这种方式采集到的数据质量参差不齐因为模型输出的理由未必是它真实的决策依据。采多少这取决于任务复杂度和模型规模。经验值是简单任务3 步以内每个场景 500 到 1000 条轨迹中等任务3 到 10 步每个场景 2000 到 5000 条复杂任务10 步以上每个场景 5000 条以上。当然这不是硬性标准关键看轨迹的多样性——如果所有轨迹都长得差不多那再多也没用模型学不到泛化能力。任务复杂度建议轨迹量每场景重点采集内容简单≤3 步500 - 1000工具选择、参数填充中等3 - 10 步2000 - 5000规划、纠错、状态跟踪复杂10 步5000长程规划、子目标分解、异常恢复3.3 教师信号的构造从原始轨迹到可学习样本原始轨迹不能直接拿来训练得先加工成教师信号。这一步是 Harness-Zero 的技术核心也是最容易做砸的地方。我的做法是分三步走。第一步轨迹切分。把一条完整轨迹切成多个状态-动作对。每个对的输入是当前状态输出是教师在这个状态下采取的动作。这样一条 10 步的轨迹就能变成 10 个训练样本。第二步动作归一化。把不同格式的动作统一成标准表示比如工具调用统一成工具名 参数 JSON文本生成统一成意图 内容。第三步软标签构造。对于同一个状态如果教师在不同轨迹里采取了不同动作不要简单取一个而是保留动作分布让模型学到这个状态下大概率该做什么小概率可以做什么。这里有个细节很关键要不要把教师的思考过程也作为学习目标。我的建议是如果教师有显式的推理步骤比如 chain-of-thought那一定要学因为这是过程知识的核心载体。但如果教师的推理是隐式的、事后编的那就别学学了反而引入噪声。判断标准很简单这个推理步骤是不是真的影响了后续动作如果是学如果只是装饰不学。3.4 蒸馏训练损失函数与训练策略训练阶段Harness-Zero 的损失函数通常是行为克隆损失 蒸馏损失的组合。行为克隆损失负责让模型学会在什么状态下做什么动作蒸馏损失负责让模型的输出分布逼近教师的输出分布。训练策略上我推荐分阶段训练。第一阶段用大量简单任务的轨迹做预热让模型先学会基本的工具调用格式和决策模式。第二阶段混入中等和复杂任务让模型学会长程规划和纠错。第三阶段用高质量的成功轨迹做精调提升最终表现。这种课程学习Curriculum Learning的方式比一上来就混着训要稳得多。学习率方面蒸馏训练通常比常规微调要小。因为教师信号本身带有噪声学习率太大会让模型过拟合到噪声上。我一般从 1e-5 到 5e-5 之间起步根据 loss 曲线调整。batch size 尽量大一些因为行为克隆对 batch 内的多样性比较敏感。注意蒸馏训练最容易出的问题是灾难性遗忘——模型学会了脚手架行为但把原有的通用能力忘了。解决办法是在训练数据里混入一定比例的通用指令数据比例大概 10% 到 20%让模型在学新行为的同时保持旧能力。4. 实操过程与核心环节实现从零搭一条 Harness-Zero 管线4.1 环境准备与工具链选型动手之前先把工具链理清楚。Harness-Zero 这条管线涉及四个环节教师智能体运行、轨迹采集、数据加工、蒸馏训练。每个环节都有对应的工具选择。教师智能体运行我建议用支持细粒度日志的框架。Dify 的工作流模式很适合因为每个节点的输入输出都能导出。如果你用代码框架LangChain 的 callback 机制也能拿到详细轨迹。轨迹采集自己写一个中间件最灵活拦截所有工具调用和模型生成统一写到一个结构化存储里JSONL 格式最方便。数据加工用 Python 脚本处理pandas 加自定义的切分逻辑就够了。蒸馏训练主流方案是 HuggingFace 的 Trainer 加自定义 loss或者用 LLaMA-Factory 这类集成工具。硬件方面蒸馏训练对显存的要求取决于模型规模。7B 级别的模型全参数蒸馏大概需要 4 张 40G 显存的卡如果用 LoRA单张 24G 就能跑。13B 以上建议用 LoRA 或者 QLoRA否则成本太高。4.2 教师智能体的搭建与调试教师智能体的搭建核心是把任务流程拆成清晰的步骤。以订单退款这个场景为例一个典型的教师智能体流程是这样的接收用户请求 → 解析订单号 → 查询订单状态 → 判断是否符合退款条件 → 执行退款 → 返回结果。每一步都要有明确的输入输出方便后续采集。调试阶段重点验证三件事。行为一致性同样的输入跑十次行为是否基本一致。边界处理遇到异常输入订单号不存在、状态不允许退款时教师是否能优雅处理。成功判定每个任务是否有明确的成功信号比如退款成功的返回。我踩过的一个坑是教师智能体调得太聪明用了很多隐式的、依赖模型直觉的决策。结果采集到的轨迹里决策依据不明确蒸馏出来的模型学得似是而非。后来我把教师的 prompt 改成显式规则优先把能写成 if-else 的逻辑都写清楚轨迹质量立刻上来了。4.3 轨迹采集中间件的实现中间件的核心逻辑是拦截和记录。下面是一个简化的 Python 示例展示怎么拦截工具调用并记录轨迹。import json import time from datetime import datetime class TrajectoryRecorder: def __init__(self, output_path): self.output_path output_path self.current_trajectory [] self.trajectory_id None def start_trajectory(self, task_input): self.trajectory_id ftraj_{int(time.time() * 1000)} self.current_trajectory [{ type: task_start, input: task_input, timestamp: datetime.now().isoformat() }] def record_state(self, state): self.current_trajectory.append({ type: state, content: state, timestamp: datetime.now().isoformat() }) def record_action(self, action_type, action_content): self.current_trajectory.append({ type: action, action_type: action_type, content: action_content, timestamp: datetime.now().isoformat() }) def record_tool_result(self, tool_name, result): self.current_trajectory.append({ type: tool_result, tool_name: tool_name, result: result, timestamp: datetime.now().isoformat() }) def end_trajectory(self, success, final_output): self.current_trajectory.append({ type: task_end, success: success, output: final_output, timestamp: datetime.now().isoformat() }) with open(self.output_path, a, encodingutf-8) as f: f.write(json.dumps({ trajectory_id: self.trajectory_id, steps: self.current_trajectory }, ensure_asciiFalse) \n)这个中间件要挂在教师智能体的关键路径上。工具调用前后各记一次模型生成前后各记一次状态变更时记一次。采集到的数据是 JSONL 格式每行一条完整轨迹。提示采集时一定要记录失败轨迹。很多人只采成功轨迹结果模型学不会纠错。失败轨迹里包含了什么路走不通的信息对模型学会避坑极其重要。成功和失败的比例我一般控制在 7:3 左右。4.4 数据加工从轨迹到训练样本采集到的原始轨迹要经过加工才能用于训练。加工流程分四步。第一步清洗。去掉不完整的轨迹比如中途中断的、去掉明显异常的轨迹比如工具返回了错误但教师没处理就结束的。第二步切分。把每条轨迹切成状态-动作对。切分粒度要适中太细会让模型学不到长程依赖太粗会让样本太少。我一般按决策点切也就是每次工具调用或每次文本生成作为一个决策点。第三步标注。给每个样本打上任务类型、难度、成功与否的标签方便后续按需采样。第四步格式化。把样本转成模型训练需要的格式通常是输入 prompt 目标输出。这里有个参数选择很关键上下文窗口取多长。取太短模型看不到足够的历史学不会长程规划取太长样本冗余大训练效率低。我的经验是取当前决策点往前 5 到 10 个决策点作为上下文基本能覆盖大部分任务的长程依赖。4.5 蒸馏训练的实施与监控训练实施时我建议先用小规模数据跑通流程再放大。具体步骤是先用 1000 条样本跑 1 个 epoch看 loss 是否正常下降看模型输出是否开始有脚手架行为的影子。确认没问题后再上全量数据。监控指标要盯三个。训练 loss正常应该是先快速下降然后缓慢收敛。如果 loss 震荡剧烈可能是学习率太大或数据噪声太多。验证集行为准确率也就是模型在验证集上决策是否正确的比例。这个指标比 loss 更直观。通用能力保持度用一组通用指令测试模型看它的基础能力有没有退化。训练过程中我习惯每隔一定步数存一个 checkpoint然后人工抽检几个样本看模型的实际输出。有时候 loss 降得很好但输出一看就是学歪了——比如学会了工具调用的格式但调用的时机完全不对。这种问题只能靠人工抽检发现。5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 模型学会了格式但学不会时机这是最常见的问题。模型能把工具调用的格式模仿得惟妙惟肖但什么时候该调、什么时候不该调完全没学会。根本原因是训练数据里决策时机的信号不够强。解决办法有两个。一是在样本里强化时机信号比如在输入里显式标注当前是否处于需要决策的状态让模型学会区分。二是增加负样本也就是这个状态下不应该调工具的样本让模型学会克制。我试过在数据里混入 20% 的无需动作样本效果立竿见影。5.2 长程任务上表现断崖式下跌短任务表现好一上长任务就崩这是行为克隆的经典问题。原因是训练时的上下文窗口有限模型没见过足够长的依赖链。我的解法是课程式地拉长上下文。先用短上下文训练让模型学会局部决策再逐步拉长上下文让模型学会长程依赖。同时在数据里刻意增加长任务的样本比例让模型多见见长什么样。5.3 蒸馏后模型变得死板有些模型蒸馏后行为变得极其刻板只会照搬教师的行为遇到新情况就懵。这是因为蒸馏过度模型把教师的行为当成了唯一正确答案失去了泛化能力。对策是引入多样性。一方面用多个不同配置的教师同时蒸馏让模型学到共识行为而不是单一行为。另一方面在训练数据里保留一定的随机性比如同一个状态下保留教师的多种合理动作让模型学到分布而不是点。5.4 常见问题速查表问题现象可能原因排查方向解决思路格式对但时机错时机信号弱检查样本是否标注决策状态增加负样本、显式标注时机长任务崩溃上下文窗口不足检查训练时上下文长度课程式拉长上下文、增加长任务样本行为死板蒸馏过度检查教师是否单一多教师蒸馏、保留动作多样性通用能力退化灾难性遗忘测试通用指令表现混入通用数据、降低学习率loss 震荡学习率过大或数据噪声检查 loss 曲线和数据质量降学习率、清洗数据工具调用参数错参数填充信号弱检查参数是否从上下文推导强化参数推导的样本5.5 几个独家避坑技巧技巧一教师智能体要故意犯错。听起来反直觉但让教师在可控范围内犯一些典型错误然后展示怎么纠正能让模型学会纠错能力。纯成功的轨迹教不出会纠错的模型。技巧二蒸馏前先做行为聚类。把采集到的轨迹按行为模式聚类看看有几种典型模式。如果发现某些模式样本极少要么补充采集要么在训练时加权否则模型学不到这些少数但重要的行为。技巧三保留教师置信度。如果教师框架能输出决策的置信度一定要保留。训练时可以用置信度加权让模型更关注教师有把握的决策忽略教师瞎猜的决策。技巧四定期做行为回放测试。把模型放到和教师相同的环境里跑一批任务对比两者的行为轨迹。差异大的地方就是蒸馏没学好的地方针对性补数据。6. 影响范围与延展思考Harness-Zero 会改变什么6.1 对智能体开发范式的影响Harness-Zero 这套思路如果跑通对智能体开发的影响是结构性的。现在的开发范式是模型 脚手架开发者大量精力花在写编排逻辑上。未来可能变成蒸馏模型 轻量适配脚手架被大幅简化开发者更多精力花在任务定义和数据采集上。这意味着智能体开发的门槛会变化。写复杂脚手架的技能可能没那么重要了但设计高质量教师行为和构造蒸馏数据的能力会变得关键。换句话说从写代码编排转向设计行为和数据。6.2 对推理成本和延迟的改善这是最直接的收益。脚手架撤掉后每一轮交互不再需要框架的解析和路由延迟能降一大截。我做过粗略估算一个原本需要 5 轮框架交互的任务蒸馏后可能 2 到 3 轮模型生成就能完成延迟降低 40% 到 60%。对于高频调用的场景这个改善非常可观。成本方面脚手架撤掉后token 开销也会下降因为不再需要把框架的指令、格式约束反复塞进 prompt。长期看蒸馏模型的推理成本可能只有原方案的几分之一。6.3 对模型能力边界的拓展更深层的影响是Harness-Zero 提供了一条把外部能力内化的通用路径。不只是脚手架行为任何外部系统帮模型做的事理论上都可以通过类似方式蒸馏进模型。比如检索增强RAG的检索决策、多智能体协作的协调逻辑都有可能被内化。当然这不意味着外部系统会消失。复杂任务、需要实时数据的任务、需要严格可控的任务还是得靠外部系统。但那些高频、模式固定的任务内化是更优解。未来的架构可能是内化处理常规外挂处理例外的混合模式。6.4 我个人的判断说实话Harness-Zero 这个方向我觉得是对的但落地难度不小。最大的挑战不在训练技术而在数据采集的工程量和质量。教师智能体要调好、轨迹要采全、数据要加工干净每一步都是脏活累活。很多团队可能卡在数据这一环。另外蒸馏模型的可解释性会下降。脚手架时代你能看到每一步的决策逻辑蒸馏之后决策逻辑藏在权重里出了问题不好排查。这对一些对可控性要求高的场景是个障碍。但长期看我倾向于认为这条路会越走越宽。因为模型能力在涨外部脚手架的边际收益在降。当模型本身足够强时把脚手架内化就是自然选择。Harness-Zero 只是把这个趋势提前具象化了。最后分享一个我在实操中的体会别指望一次蒸馏就完美。我做过的最成功的一次是迭代了三轮——第一轮学基本行为第二轮补长尾场景第三轮做精调和通用能力保持。每一轮都基于上一轮的实际表现来补数据、调策略。这个过程很像带徒弟急不得得一轮一轮磨。