如果你在真实业务里部署过开源大模型大概率经历过这种尴尬模型文件不小推理速度也还行但一遇到复杂任务就开始一本正经地输出错误答案。换大模型单次成本翻十几倍私有化部署还不一定放行。做蒸馏微调垂直领域连高质量标注数据都凑不齐更不用说训练 GPU 的预算。于是近一年越来越多的团队把目光从“训练时”移向“测试时”。与其花大力气把强模型的能力写进弱模型的参数不如在推理阶段给弱模型套上一套辅助系统让强模型以“教练 裁判”的身份动态介入。这条思路可以概括为 AI4AIAI for AI在测试时的一种落地形态论文标题里给出了更精确的表达AI4AI at Test-Time: Strong-to-Weak Capability Transfer via Harnesses。先给出一个明确判断这类方法把“模型的单点能力”和“系统解决问题的能力”解耦了。弱模型负责主干生成强模型负责验证、纠错和沉淀记忆Harness 则是连接两者的外部脚手架。它不能完全替代蒸馏但在模型快速迭代、场景要求私有化部署、数据又没有富余到能微调的今天它是性价比极高的过渡方案。读完这篇文章你会理解Harness 到底是什么Strong-to-Weak 能力迁移为什么可以从训练时挪到测试时以及如何用几十行代码搭出一个最小 Harness 原型。文章不依赖任何私有框架核心思路在任何大模型 API 上都能复现。1. 这篇文章真正要解决的问题很多团队选型开源小模型本质原因是三点成本、隐私、可控性。小模型可以私有化部署请求费用几乎为零权限边界自己说了算。但它也有三个非常现实的问题。第一复杂推理任务的上限不够。简单问答没问题一旦涉及多步推理、数学计算、代码排错小模型经常“流畅地犯错”。第二错误很难被发现。它不会直接告诉你“我不会”而是给一个看起来很合理的错误答案导致业务侧很难自动拦截。第三质量提升路径不清晰。所有主流方案都指向训练蒸馏、SFT、DPO而这些都要数据、算力、时间和大量的工程投入。如果你正在做 RAG 应用、Agent 工具链或者垂直领域的私有化助手这三个问题几乎每天都会遇到。传统解决方式很直接砸钱换大模型或者砸时间做微调。但有没有可能在不动模型参数的前提下让弱模型在真实任务中的表现明显上一个台阶这就是测试时 AI4AI 的切入点。它不改变弱模型本身而是改变弱模型完成任务时“身边有什么”。论文标题里使用 Strong-to-Weak Capability Transfer强调的正是这个动作强模型的能力通过外部机制流向弱模型而不是通过梯度更新写入模型权重。因此这篇文章真正想解决的问题是当你不具备训练条件又无法全部换成大模型时如何用工程手段把强模型的能力“借”给弱模型。2. Strong-to-Weak 能力迁移从训练时到测试时的转变先解释 Strong-to-Weak 这个概念。过去几年大家更熟悉的是 Weak-to-Strong用弱监督信号去训练强模型。OpenAI 的超对齐研究里提到过这个思路因为未来可能出现的超级模型人类自己未必能完全理解需要用相对弱的人类监督去引导强模型。而 Strong-to-Weak 方向相反强模型在某个任务上已经很强了现在要把这种能力迁移给弱模型。最经典的实现是知识蒸馏用强模型生成大量数据然后训练弱模型模仿强模型的输出分布。这个过程发生在训练时本质是“参数迁移”强模型的身份是教师弱模型的身份是学生。但蒸馏有三个绕不开的代价。其一数据成本。要让弱模型真正学到强模型的推理能力需要大量高质量轨迹数据不只是最终答案还要有中间推理链。垂直领域里这类数据的获取和清洗成本常常高到项目无法立项。其二训练资源。一张 H 系列 GPU 卡运行几十个小时起步对很多中小团队来说光是排队和预算就足够劝退。其三迭代周期长。强模型更新了或者业务场景变了蒸馏流程要全部重跑。强模型是 GPT-5 了弱模型还停留在模仿 GPT-4 的水平。测试时迁移则完全不同。它不更新任何权重而是在推理阶段动态引入强模型的参与。默认情况下弱模型完成任务是“输入 → 生成 → 输出”一步走。引入测试时迁移后流程变成弱模型先尝试 → 强模型检查 → 不通过 → 强模型给出修改建议 → 弱模型再尝试。弱模型仍然是执行的主角但强模型变成了教练、裁判和记忆库。这背后的核心变化不是“能力流向了哪里”而是“能力以什么形式存在”。训练时迁移让能力固化在参数里测试时迁移让能力存在于一次次的交互和验证中。前者是一次性投资后者是按次计费的租赁。用一张表对比两种路径对比维度训练时迁移蒸馏 / 微调测试时迁移Harness是否更新弱模型权重更新不更新是否需要标注数据大量且要质量无需标注数据是否需要训练 GPU需要不需要强模型升级后重新蒸馏替换接口即可单次推理成本弱模型本身成本低增加强模型调用成本上升延迟低单次生成多轮交互延迟增加弱模型可替换性换模型等于重训即插即用适用阶段长期稳定的核心场景快速迭代、冷启动、私有化受限场景从这个表能看出Harness 不是蒸馏的替代品而是蒸馏之前的“先导方案”。它解决的是训不动、没数据、要快速上线的问题。3. Harness 机制它到底是什么“Harness”这个词在英文里原意是马具、安全带。用到 AI 系统里它表达的是“外部约束 辅助装置”的含义把弱模型放进一个结构化的作业环境里让它借助外部系统完成任务。用类比理解最直观。弱模型是驾驶员Harness 是坐在副驾的教练加辅助驾驶系统。方向盘和油门还是驾驶员自己控制但副驾会提醒你路况、纠正你的错误、帮你记录走过哪些弯路。它不是接管驾驶而是让驾驶员在不出事故的前提下开得更远。Harness 不是普通的 RAG。RAG 是从外部文档库里检索知识给模型作参考检索对象是静态文本。Harness 的参考对象是另一个动态的 AI 模型它可以根据弱模型的输出实时反馈具有交互性。Harness 也不是普通的 Agent 框架。Agent 框架侧重给模型装工具、定义行动空间Harness 的核心是强模型对弱模型的监督循环。从论文标题的关键词来看这套系统的设计意图可以拆成五层AI4AI用 AI 来增强 AIAI 本身成为另一个 AI 的基础设施。At Test-Time应用阶段在推理时强调“不训练”。Strong-to-Weak能力的流向是从强模型到弱模型方向明确。Capability Transfer强调转移的是“完成任务的能力”不是“复制参数”。Harnesses实现这一切的载体是外部脚手架而不是模型内部的改动。一个完整的 Harness 通常包含五个核心组件组件职责类比任务分析器将复杂任务拆解为可执行的子目标领航员生成器弱模型产生候选步骤或候选答案驾驶员验证器强模型判断候选答案是否正确、是否完成子目标裁判反馈器强模型说明失败原因并给出具体的修改建议教练记忆库存储成功轨迹、失败教训和中间结果行车记录仪值得注意的是验证器和反馈器一般可以合并成一个角色都由强模型承担只是输出形态不同。验证器输出的是结构化判断结果比如{passed: false, reason: ...}反馈器输出的是自然语言建议供弱模型二次生成时参考。这里有一个新手容易误解的地方Harness 是不是就是“让弱模型调用强模型 API”不完全是。如果只是让弱模型把问题抛给强模型那是“改成了用强模型回答问题”跟直接调用强模型没有本质区别。Harness 的关键在于循环弱模型先自己尝试强模型只做“检查”和“提示”尝试权仍然在弱模型手里。这样既保留了强模型的知识又能让弱模型逐步学会处理这类任务同时把强模型的调用次数控制在一个合理范围内。4. Harness 在测试时如何工作核心流程拆解把一个真实任务交给 Harness 系统完整流程大致如下。第一步任务分析。任务分析器读入用户输入判断任务的类型、复杂度和所需能力。如果任务太简单可以直接交给弱模型完成不需要进入 Harness 循环这样可以节省成本。如果任务复杂则拆解为多个子目标。第二步弱模型首轮生成。弱模型独立生成第一版答案。这一步和普通推理没有区别但它生成的答案可能是错的而且往往“错得很有道理”。第三步强模型验证。强模型扮演裁判把弱模型的答案和任务目标放在一起检查。验证不是简单对错判断而是要看答案是否真正解决了任务、推理过程有没有漏洞。第四步条件分支。如果验证通过流程结束返回答案。如果验证不通过进入第五步。第五步反馈与再生成。强模型生成反馈信息说明失败原因和修改建议。弱模型带着这些建议重新生成答案然后回到第三步形成循环。第六步记忆沉淀。任务结束后无论成功还是失败把完整轨迹写入记忆库。下次遇到相似任务时Harness 可以从记忆库中检索到以往的成功路径直接引导弱模型。可以用下面这段伪代码描述主循环输入任务 task 弱模型输出 candidate weak.generate(task) for round in 1..max_rounds: check strong.verify(task, candidate) if check.passed: memory.save(task, history, successTrue) return candidate hint strong.feedback(task, candidate, check.reason) candidate weak.improve(task, hint) history.append(candidate) memory.save(task, history, successFalse) return candidate这个流程里有两个关键设计决定了系统的表现。一个是验证器的质量。如果强模型误判了弱模型的答案整个循环就失去了意义。因此验证器的 prompt 需要明确评分标准必要时还可以让验证器同时输出理由和建议而不仅是“通过/不通过”。另一个是反馈的粒度。反馈信息如果太抽象比如只写“你的答案不对”弱模型无法据此改进如果太具体又相当于把答案直接告诉弱模型失去了让弱模型练习的意义。实际项目中反馈至少要包含三部分失败原因、正确的推理方向、下一步要检查的要点。从工程视角看Harness 的本质是把“一次高质量生成”拆成“多次低质量生成 高质量验证与修正”。这是在用推理时计算换取模型能力和前两年 Test-Time Compute测试时计算的研究思路一脉相承。区别在于它引入的不只是“多采样几条路径再选一个”而是真正意义上的多智能体协作。5. 最小示例用 Python 搭建 Harness 原型理论讲完下面的重点是动手跑通一个最小 Harness。这里我们不依赖任何特定厂商的 API先把结构搭出来。5.1 环境准备本文示例需要 Python 3.9 以上版本依赖库只有标准库。真实项目中你只需要把LLMClient替换为你自己的大模型 SDK 或 HTTP 调用。先建立一个项目目录mkdir harness_demo cd harness_demo5.2 定义弱模型与强模型的 Mock为了让你无需 API Key 也能直接运行我们先用 Mock 模型演示流程。弱模型模拟一个计算能力较弱、会犯减法错误的模型强模型模拟一个能发现错误并给出反馈的验证器。# 文件路径harness_demo/mock_models.py 演示用 Mock 模型弱模型经常出错强模型能够纠错。 class MockWeakModel: 模拟一个计算能力偏弱的模型做减法时会算错。 def generate(self, task: str) - str: # 第一次独立尝试算成了 6 return 2 3 - 1 6 def improve(self, task: str, hint: str) - str: # 根据强模型提示修正答案 if 减法 in hint and 5 - 1 in hint: return 2 3 - 1 4 return 2 3 - 1 6 class MockStrongModel: 模拟能力较强的验证器与反馈器。 def verify(self, task: str, candidate: str) - dict: if candidate.strip() 2 3 - 1 4: return {passed: True, reason: } return {passed: False, reason: 第二步减法错误5 - 1 不等于 6。} def feedback(self, task: str, candidate: str, reason: str) - str: return f你的计算过程有误{reason} 请重新计算先算 2 3再算 5 - 1。5.3 实现 Harness 主循环# 文件路径harness_demo/basic_harness.py 最小 Harness 原型弱模型负责生成强模型负责验证和反馈。 class Harness: def __init__(self, weak_model, strong_model, max_rounds5): self.weak weak_model self.strong strong_model self.max_rounds max_rounds def run(self, task: str) - dict: history [] candidate self.weak.generate(task) history.append(candidate) for round_idx in range(self.max_rounds): check self.strong.verify(task, candidate) if check[passed]: return { success: True, answer: candidate, rounds: round_idx 1, history: history, } hint self.strong.feedback(task, candidate, check[reason]) candidate self.weak.improve(task, hint) history.append(candidate) return { success: False, answer: candidate, rounds: self.max_rounds, history: history, }5.4 运行入口# 文件路径harness_demo/main.py from basic_harness import Harness from mock_models import MockWeakModel, MockStrongModel if __name__ __main__: task 计算 2 3 - 1 的结果 harness Harness( weak_modelMockWeakModel(), strong_modelMockStrongModel(), max_rounds5, ) result harness.run(task) print(f任务{task}) print(f是否成功{result[success]}) print(f最终答案{result[answer]}) print(f迭代轮数{result[rounds]}) print(历史轨迹) for i, step in enumerate(result[history], 1): print(f 第 {i} 次{step})运行命令cd harness_demo python main.py预期输出任务计算 2 3 - 1 的结果 是否成功True 最终答案2 3 - 1 4 迭代轮数2 历史轨迹 第 1 次2 3 - 1 6 第 2 次2 3 - 1 4从这个最小示例可以看到 Harness 的核心流程弱模型先犯错强模型验证并指出原因弱模型根据反馈修正。虽然示例很简单但它已经具备了完整的三要素验证、反馈、循环。把MockWeakModel和MockStrongModel换成真实模型就是可用的生产原型。这里真正容易踩坑的地方是improve方法里弱模型不一定能理解反馈。真实场景中弱模型可能反复犯错或者干脆把强模型的建议理解偏了。所以max_rounds必须设置上限避免无限循环导致成本失控。6. 记忆库与验证器Harness 的两个关键强化最小原型跑通后要让 Harness 真正可用还需要两个关键组件记忆库和可结构化的验证器。6.1 记忆库让 Harness 越用越聪明没有记忆库的 Harness每来一个新任务都是从零开始。弱模型犯过的错误下次还会犯强模型给出的反馈也没有沉淀下来。引入记忆库之后Harness 可以把历史任务的完整轨迹保存下来。当新任务与历史任务相似时直接检索出当时成功的路径让弱模型一开始就循着正确方向走。设计记忆库时存储格式可以很简单推荐 JSONL按行追加。# 文件路径harness_demo/memory_store.py 基于 JSONL 的轨迹记忆库。 import json import os from datetime import datetime from typing import List, Dict class TrajectoryMemory: def __init__(self, path./memory.jsonl): self.path path os.makedirs(os.path.dirname(os.path.abspath(self.path)), exist_okTrue) def save(self, task: str, history: List[str], success: bool) - None: record { task: task, history: history, success: success, ts: datetime.now().isoformat(), } with open(self.path, a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n) def load(self) - List[Dict]: if not os.path.exists(self.path): return [] records [] with open(self.path, r, encodingutf-8) as f: for line in f: line line.strip() if line: records.append(json.loads(line)) return records检索策略在演示阶段可以用简单的关键词匹配生产环境建议换成向量检索。除了轨迹本身记忆里还应保存“最终为什么成功”的摘要。这个摘要可以由强模型在任务结束后生成例如“这个任务的关键是提醒弱模型先算加法再算减法”。摘要比原始轨迹更适合被检索出来放进 prompt。6.2 验证器用结构化输出约束强模型验证器决定整个循环能否收敛。如果验证器只是输出“对/错”弱模型拿不到足够信息如果输出一篇长文弱模型又容易“迷失重点”。最佳实践是让验证器输出 JSON字段固定为passed、reason、suggestion。# 文件路径harness_demo/verifier.py 用强模型构造验证器的通用模板。 import json from typing import Callable def build_verifier(strong_client) - Callable: 输入强模型客户端返回验证器函数。 强模型需要按照固定 JSON 格式输出 {passed: true/false, reason: 不通过时的原因, suggestion: 修正建议} def verify(task: str, candidate: str) - dict: prompt ( 你是一个任务验证器。请判断以下候选答案是否正确解决了任务。\n f任务{task}\n f候选答案{candidate}\n 请只输出 JSON不要输出其他内容JSON 格式\n {passed: true/false, reason: 不通过时的原因, suggestion: 修正建议} ) # 真实项目中替换为真实强模型调用 # response strong_client.chat( # [{role: user, content: prompt}], # temperature0 # ) # return json.loads(response) raise NotImplementedError(请替换为真实的强模型调用) return verify验证器的 prompt 有几个细节值得注意。一是温度要设为 0 或接近 0保证结构化输出的稳定性。二是要限制输出格式必要时用 JSON Mode 或函数调用Function Calling功能。三是对于复杂任务验证器也应该“先思考后判断”建议 prompt 里加入一个analysis字段让强模型先分析再下结论能有效降低误判率。四是不要把验证器当“神仙”它本身也会有误差。在生产环境中你可以并行调用多个验证器或者对高风险任务引入人工复核。7. 效果验证与评估思路Harness 的效果到底怎么样需要从几个维度来评估。这里不给出某个具体指标的原因在于不同基座模型、不同任务类型、不同强模型选择结果差异很大。但评估框架是通用的。7.1 对比基线评估 Harness 时最少要和三个基线对比第一弱模型裸跑。这是最底线的对照验证 Harness 是否真的有增益。第二弱模型 自一致性Self-Consistency。让弱模型多次采样再投票选出答案本质是测试时计算的一种轻量应用。第三弱模型 Best-of-N 强模型挑选。让弱模型生成 N 个候选用强模型从中选出最好的那个这是“验证但不反馈”的案例可以和“验证 反馈 多轮迭代”的 Harness 对比。四种方案的对比可以这样记录方案是否更新权重强模型调用次数预期效果适用场景弱模型裸跑否0基准线简单任务Self-Consistency否0高于裸跑但提升有限答案可投票的任务Best-of-N 强模型挑选否1 次 / 任务明显提升验证容易反馈困难的任务Harness 多轮循环否多次 / 任务最大提升成本最高复杂推理、代码排错、长流程任务7.2 评估指标建议至少统计四个指标任务成功率Success Rate最直接的效果指标。平均迭代轮数多轮循环下轮数越多成本越高。如果三轮内成功率能覆盖 80% 的需求就不必追求所有任务都收敛。单任务成本把弱模型和强模型的 token 量都算进去。这里有一个容易被忽略的成本项强模型的输入里包含弱模型的错误答案越长越贵。有效反馈率统计强模型的反馈信息是否真的让弱模型下一轮答案变好了。这个指标可以帮助你优化反馈器的 prompt。7.3 成本方程Harness 的成本可以用一个简单的式子估算单任务总成本 弱模型生成成本 × 平均轮数 强模型验证成本 × 平均轮数 强模型反馈成本 × (平均轮数 - 1) 记忆检索成本如果弱模型选的是开源模型私有化部署弱模型生成成本可以近似忽略。绝大部分成本集中在强模型的验证与反馈调用上。因此控制轮数、提高验证器准确率、合理选择哪些任务需要进入 Harness 流程是控制总成本的关键。这里的一个工程建议是Harness 入口先加一个任务分级器。简单任务直接走弱模型裸跑中等任务走 Best-of-N只有高复杂度任务才走完整 Harness 循环。这样可以避免“杀鸡用牛刀”。8. 常见问题与排查思路在实际工程中Harness 的调试往往比写主循环更耗时。下面整理几个高频问题。问题现象可能原因排查方式解决方案弱模型始终不按反馈修改反馈信息太抽象或太长查看每次反馈文本观察弱模型是否理解把反馈拆成 1-3 个具体行动点用编号列出强模型误判正确答案验证器 prompt 没有给出明确评分标准抽样检查验证器输出和原因在 prompt 中加入评分细则、示例和“先分析后判断”要求多轮循环后成本飙升不设截止条件或轮数上限过大查看平均轮数和 token 消耗日志设置 max_rounds3 到 5并在入口加任务分级器上下文窗口被历史轨迹塞满每一轮都把完整历史传给弱模型检查 prompt 拼接逻辑只保留上一轮答案 最新反馈或对历史做摘要压缩强模型返回 JSON 解析失败未启用结构化输出模型输出夹杂解释文本直接查看强模型原始返回使用 JSON Mode 或 Function Calling并做异常重试引入记忆后效果反而变差检索到不相关轨迹干扰弱模型检查记忆检索的相似度阈值降低 top_k增加任务类型标签过滤只召回同类型成功轨迹线上延迟过高串行多轮调用强模型打印每轮耗时分布并行生成多个候选一次性验证或对验证器模型进行加速部署排查的第一原则是先看日志。每个环节的输入输出都要记录尤其是强模型的验证结果和反馈内容。很多时候问题不是出在框架逻辑上而是出在 prompt 质量上。你可以抽象思考一下把验证器换成一位有经验的同事他能根据你写的 prompt 完成同样质量的判断吗如果不能说明 prompt 还需要补充规则和示例。9. 最佳实践与工程建议9.1 什么场景适合用 HarnessHarness 最适合三类场景。第一冷启动阶段。新业务开始时没有训练数据但又必须快速上线。先上 Harness让弱模型在强模型辅助下跑业务同时在后台沉淀成功轨迹。等轨迹数据积累到万级之后再考虑用这些数据做一次蒸馏或微调逐步降低对强模型的依赖。第二多模型并存阶段。同一套系统里既有强模型也有弱模型强模型负责关键节点弱模型负责大批量执行。Harness 天然适合这种架构因为它本来就是“弱模型干活强模型把关”的设计。第三动态任务环境。任务类型经常变化如果每次都重新微调模型成本太高。Harness 可以通过调整验证器和反馈器的 prompt 来快速适配新任务不需要重新训练。9.2 什么场景不适合 Harness有几个场景应该谨慎使用。一是超高并发、强实时场景。Harness 的多轮交互会增加延迟如果业务要求首 token 响应在 200ms 内Harness 循环就很难满足。二是弱模型能力过弱的场景。如果弱模型连基础的信息抽取都做不好强模型的反馈它也“听不懂”这种情况下不如直接换更大的模型。三是强模型本身不可用或者调用受限的场景。Harness 把核心质量押在强模型验证上如果强模型不稳定整个系统都会受影响。9.3 工程化建议轮数与预算上限。任何 Harness 循环都必须有硬性上限建议同时设置轮数上限和 token 预算上限超限后走降级分支。记忆先小后大。启用记忆库之前先小流量验证记忆是否会带来正向收益。如果检索噪声太大可以先关闭记忆只做验证和反馈循环。关注安全边界。强模型的反馈内容会直接进入弱模型的上下文如果业务涉及敏感数据必须对强模型调用链路做脱敏和权限校验。同时验证器不应对下游执行系统具有写权限避免模型错误导致的级联故障。可观测性。每个环节都要有 trace任务标识、每轮输入输出、强模型验证耗时、轮次、成本。生产环境的 Harness 本质上是一条异步工作流没有 trace 会非常痛苦。结构化中间产物。验证器的 JSON、反馈器的建议、记忆库的轨迹都用结构化格式存储方便后续做分析和微调数据生成。从 Harness 到蒸馏的演进。这是最重要的工程策略。Harness 不应该是一个永久架构而应该是数据生产装置。把 Harness 跑成功的轨迹筛选、清洗、去重后交给下游做 SFT 或 LoRA 微调。这样做的收益是先用 Harness 解决“没有好数据”的问题再用蒸馏解决“Harness 成本高”的问题最终把弱模型训练成不需要 Harness 也能完成任务的模型。9.4 一个推荐的演进路径第一阶段纯弱模型裸跑收集基线数据和任务类型分布。第二阶段接入 Harness优先覆盖 20% 的高复杂度任务观察质量、成本和延迟数据。第三阶段用 Harness 积累的成功轨迹构建微调数据集对弱模型做一次低成本的 LoRA 微调。第四阶段验证微调后的弱模型是否能在部分任务上脱离 Harness把强模型调用频率逐步降低。这四步完成后你的系统会处于一个很健康的状态日常任务交给微调后的小模型复杂任务仍然由 Harness 兜底。10. 总结与下一步这篇内容的核心其实是一个判断模型能力不够时不一定要立刻换模型或者训模型测试时的外部脚手架是一条更轻、更快、更可控的路径。Harness 把强模型从“昂贵的回答者”变成了“高效的监督者”把弱模型从“单打独斗的执行者”变成了“在指导下改进的学习者”。这中间的架构成本不高但需要你对验证质量、反馈粒度、成本预算和记忆策略做精细设计。如果这篇文章对你有一点点帮助建议先把它收藏起来。下一步可以做的实践是用文中的最小 Harness 原型替换成你手头的真实模型接口先跑通一个你日常最头疼的任务类型然后加上记忆库跑 100 个任务看看整体成功率、平均轮数和成本数据。有了这组数据你再决定是继续优化 Harness 的各组件还是开始积累数据做下一轮微调。值得继续深入的方向至少还有三个一是验证器的自校准如何让强模型自己判断“我这次的验证是否可靠”二是记忆库的压缩与检索策略如何从上千条轨迹中快速找到最相关的一条三是多智能体的协作模式当弱模型不是一个而是多个时Harness 如何调度它们相互验证。每个方向单拿出来都够写一篇长文后续可以慢慢展开。技术选型这件事本质上是在资源约束下寻找最优解。Harness 给我们的启发是在参数之外架构和流程同样可以“迁移能力”。这句话或许比模型本身更值得思考。
