这项由北京航空航天大学未来区块链与隐私计算高精尖创新中心人工智能学院与清华大学联合开展的研究，于2026年6月1日以预印本形式发布，编号为arXiv:2606.01779，研究成果被命名为HarnessForge框架。有兴趣深入了解的读者可以通过该编号在arXiv平台查阅完整论文。
**一个让AI干活的难题**
假设你雇了一位助手，你给他一本操作手册（告诉他该按照什么步骤工作），然后让他去完成各种任务。问题来了：当任务越来越复杂、越来越多样时，手册里的步骤可能根本跟不上需要，而助手本身的能力也未必能完全执行手册里要求的那些复杂操作。更糟糕的是，手册和助手之间可能存在"代沟"——手册写得很好，但助手根本没办法照着做；或者助手很聪明，但手册太简陋，导致他发挥不出来。
这正是当今AI助手（也就是"大语言模型智能体"，简单理解成能执行复杂任务的AI程序）面临的核心困境。北航和清华的研究团队发现，以往的方法要么只改进"手册"（专业上叫"外部执行框架"或"harness"），要么只训练"助手"（专业上叫"策略"或"policy"），从没有人认真考虑过把这两者**一起**进化——让手册和助手相互磨合、彼此适应。HarnessForge就是为了解决这个问题而生的。
**一、AI助手为什么总是"换个场景就不行了"**
回到那个雇员的比喻。当你的助手只需要在一家公司做固定工作时，一本写好的操作手册就够了。但现代AI助手面对的挑战远不止于此——它既要搜索网页查资料，又要调用各种工具和API接口，还要记住上下文、分解复杂任务、与多个系统交互。每换一个场景，对"手册"的格式要求就完全不同。
研究团队把这种困境概括为三种典型失败模式。第一种是"动作说明书写错了"，也就是手册规定的工具调用格式和步骤根本不对，AI按照手册操作只会不断出错。第二种是"任务拆解方式不对"，手册没有教AI如何把一个复杂问题拆成可以逐步解决的小问题，导致AI在面对多步骤任务时束手无策。第三种是"记忆没被正确利用"，手册没有告诉AI什么时候该记住什么、该回忆什么，导致AI在执行过程中遗忘了关键信息。
以往的解决方案就像在修一辆车时，有人专门负责换引擎，有人专门负责调方向盘，但从来没有人把整台车放在一起统筹考虑——引擎换了，方向盘还是旧的，两者不配套，跑起来照样出问题。
**二、HarnessForge的核心思路：让手册和助手一起进化**
HarnessForge的核心洞察非常直接：与其分别优化手册或助手，不如把"手册+助手"这个组合作为一个整体来优化。研究团队把这个组合正式定义为一个"智能体系统"，用公式表达就是：智能体系统 = （执行手册，推理助手）。
执行手册由三个部分组成。第一部分是"规划模块"，负责任务分解、重新规划和何时停止；第二部分是"动作模块"，负责工具调用的格式规范、角色分配和协作规则；第三部分是"记忆模块"，负责什么信息该被存储、什么时候该被调取、如何被整理后呈现给AI。推理助手则是在手册定义的框架内实际执行推理的AI模型，它有一个可以微调的"适配器"，可以在不改变基础模型的情况下学习新技能。
整个HarnessForge框架分成多轮进化，每一轮都像是给这对"搭档"进行一次深度磨合训练。具体来说，每轮进化包含两个互相促进的阶段：先改进手册，再让助手适应改进后的手册。两者不断螺旋上升，直到这对搭档越来越默契。
**三、"故障诊断+档案参考"：手册是怎么被改进的**
手册的改进过程有点像医院的会诊制度。当AI在执行任务时出了问题，HarnessForge不会笼统地说"这个AI出错了"，而是会仔细分析：到底是手册的哪个部分导致了失败？是规划模块没有正确分解任务？是动作模块的工具调用格式出了问题？还是记忆模块没有及时提供关键信息？
这个诊断工作由一个专门的"元智能体"（可以理解成一个专门负责分析和改进的高级AI，本研究中使用的是GPT-5.5）来完成。元智能体会同时查看当前手册的设计、失败轨迹的具体过程以及整体表现数据，然后输出一份详细的"故障报告"，明确指出是规划、动作还是记忆出了问题。
诊断完成后，系统并不会从零开始重新写一本手册，而是会先查阅一个"历史档案库"。这个档案库存储了之前所有版本的手册及其表现数据。元智能体会从中找出那些在类似故障情况下表现良好的历史手册，提炼出可复用的改进方向，形成一份"改进建议书"。
有了改进建议书，系统才开始生成新版本的手册候选方案。每一轮会生成8个候选手册，然后通过一个"半淘汰赛"机制逐步筛选：先用200个任务测试，淘汰一半；再用200个任务测试，再淘汰一半，最终留下2个最优手册进入下一阶段。这种分阶段筛选的好处是节省计算资源，不需要把所有候选手册都在全量数据上跑一遍。
筛选标准并不只看任务完成率，而是同时考虑三个维度：任务完成质量、消耗的token数量（相当于AI的"思考成本"）以及响应延迟。这种多目标权衡的方式，保证了最终留下来的手册不只是"能完成任务"，还要"高效地完成任务"。
**四、"量身定制的训练"：助手是怎么适应新手册的**
手册升级之后，老助手可能一时半会儿适应不了新的操作流程。这就好比公司换了一套全新的工作规范，老员工还在用旧习惯干活——手册再好，执行起来也会打折扣。HarnessForge的解决方案是为每一本手册专门训练一个配套的"适配器"。
这里的"适配器"是一种轻量级的微调技术（学名叫LoRA，低秩自适应），可以在不改动基础AI模型的前提下，给模型附加一层专门针对特定手册的行为习惯。这样做的好处是灵活——基础模型只有一个，但可以搭配不同的手册配上不同的适配器，就像同一个人可以根据不同岗位的操作规范调整自己的工作方式。
训练数据的来源非常聪明：直接复用手册筛选阶段已经收集到的成功执行轨迹，而不需要额外再跑一批任务来收集数据。只有那些成功完成任务的轨迹才会被保留，然后被分解成一个个"输入-输出"对：输入是当前任务描述、手册接口规范、已积累的观察记录、当前记忆状态和可用动作；输出是在这个手册框架下应该做出的下一步行为。通过这种方式训练出来的适配器，能让助手更准确地按照新手册的规范行事——不管是调用工具的格式、规划任务的步骤还是管理记忆的方式，都会更符合新手册的要求。
这种训练方式使用的是监督微调（SFT），相当于"照着成功案例模仿"。研究团队还探索了更强力但更耗资源的强化学习方法（GRPO和RLOO），发现它们可以进一步提升效果，但代价是需要更多计算资源——这个权衡关系在后续实验中有详细验证。
**五、五个考场、两种AI规模的全面检验**
研究团队在五个各具特色的测试场景中验证了HarnessForge的效果，使用了两种规模的基础模型：Qwen3-4B（40亿参数，较小）和Qwen3-8B（80亿参数，较大）。
第一个场景是ToolHop，专门测试多跳工具使用能力。什么叫"多跳"？就是为了回答一个问题，AI需要先调用工具A得到中间结果，再用中间结果去调用工具B，再把工具B的结果用于工具C……就像解一道需要多个步骤的数学题，每一步都依赖上一步的结果。第二个场景是SearchQA，由HotpotQA和2WikiMultiHopQA两个数据集组成，考验AI在本地文档库中检索信息并回答多跳问题的能力。第三个场景是RestBench-TMDB，模拟调用电影数据库的REST风格API接口，测试AI能否正确选择API端点并组合调用。第四个场景是API-Bank，测试AI面对各类用户需求时能否准确调用结构化API接口。
实验结果显示，与所有竞争方法相比，HarnessForge在绝大多数测试指标上都达到了最优水平，平均比最强的单一竞争方法高出3.56个百分点。最亮眼的结果出现在TMDB场景：在4B规模的模型上，成功率比最强基线提升了12个百分点；在8B规模的模型上，提升幅度也有6个百分点。在API-Bank场景，API调用准确率平均提升了近5个百分点。在ToolHop场景，最终答案正确率平均提升了约3.3个百分点。SearchQA的总体得分也达到了所有方法中的最高值42.83%。
值得关注的是，那些专门做策略训练的竞争方法（RLOO和GRPO）消耗的计算资源比HarnessForge多得多，但大多数指标仍然不如HarnessForge——这说明联合进化的效果并不只是靠"烧更多计算资源"换来的。
**六、缺哪一半都不行：拆开看看才知道**
为了证明手册进化和助手训练这两个部分缺一不可，研究团队做了一组对照实验：分别去掉手册进化（只训练助手）和去掉助手训练（只改进手册），然后对比三轮进化后的效果差距。
结果非常清晰。去掉手册进化之后，ToolHop的正确率在第三轮下降了6.15个百分点，SearchQA下降了5个百分点——而且随着轮数推进，差距越来越大，说明手册进化的价值是累积性的，越往后贡献越重要。去掉助手训练之后，第三轮的ToolHop下降了2.56个百分点，SearchQA下降了3个百分点。两者相比，手册进化对最终效果的贡献更大，但助手训练的缺失也会带来不可忽视的损失。
这个结果很好地回答了一个可能有人会质疑的问题：既然手册进化贡献更大，为什么不干脆只做手册进化？答案是，手册再好，如果助手没有经过专门适应性训练，执行质量仍然会打折扣——两者是相辅相成的关系，缺一不可。
**七、留几本手册备选，还是只留一本？**
在每轮进化中，最终留下多少本备选手册，会对效果产生多大影响？研究团队专门测试了留1本、2本和3本三种设置。
只留1本手册往往太过保守，会错过可能更优的探索方向。从第三轮的结果来看，从1本增加到2本，ToolHop提升了3.6个百分点，TMDB提升了6个百分点，API-Bank提升了2.6个百分点，SearchQA提升了0.7个百分点，平均提升约3.2个百分点。但继续从2本增加到3本，大多数场景的提升就微乎其微了，有时候反而略有下降。背后的逻辑是，保留太多手册会稀释选择压力——相当于你在选拔优秀员工时，留的人太多，就失去了筛选的意义。2本这个数字在"保留足够多样性"和"保持足够高的选拔标准"之间找到了一个平衡点。
**八、手册和助手到底有没有"专属搭档效应"？**
研究中最有说服力的一组实验，是把所有进化过的手册和所有进化过的助手两两配对，测试每种组合的效果。这就像是把所有版本的操作手册和所有版本的员工随机搭配，看看哪些组合表现好、哪些表现差。
在API-Bank场景，最基础的手册+基础助手组合的成功率是69.30%。沿着对角线（也就是手册和助手始终保持配套的进化路径），最终版本的配对成功率达到了77.19%。但如果把最终版手册配上早期助手，平均成功率只有71.93%；把最终版助手配上早期手册，平均成功率也只有71.06%。这种差距非常清楚地说明了一件事：HarnessForge的进步不是靠着独立打造了一个"超强手册"或一个"超强助手"，而是靠着让手册和助手在相互磨合中形成了专属的配合默契。把它们拆开来，效果就会大打折扣。
在ToolHop场景，类似的矩阵分析也显示出同样的规律：配套组合始终优于错配组合，并且随着进化轮次增加，配套效果的提升幅度也在累积增长。
**九、用更强的训练方法，效果还能再提升**
HarnessForge默认使用的是最简单的监督微调（SFT），也就是"照着成功案例模仿"。研究团队还测试了用强化学习方法（GRPO和RLOO）来替换这个环节。
在第三轮，使用GRPO时ToolHop的答案准确率从50.77%提升到了52.31%；使用RLOO时API-Bank的成功率从71.05%提升到了72.80%。但代价是计算资源的大幅增加——第三轮使用强化学习需要消耗45600次模型调用，而使用SFT只需要12000次。这个对比揭示了一个很实际的选择逻辑：如果计算资源充裕，强化学习可以进一步挖掘潜力；如果计算资源有限，SFT已经能在相对低的成本下获得大部分收益。HarnessForge的框架设计对两种方式都兼容，使用者可以根据实际需求灵活选择。
**十、三轮进化的具体故事：手册改了什么**
研究团队通过一个具体的ToolHop场景，展示了手册在三轮进化中究竟经历了什么样的改变。
第一轮进化主要改善了两件事：一是任务分解变得更细致，把大目标拆成了更清晰的子目标；二是记忆管理变得更有规律，会把重要的上下文更一致地注入给AI。这轮改进带来了2.14%的性能提升，随后配套的助手训练又额外贡献了1.57%的提升。
第二轮进化的重点转向了规划的可靠性和动作执行的稳定性：加入了"证据台账"机制（让AI明确记录每个中间步骤的证据来源），并改进了工具调用的验证逻辑（在提交最终答案前检查是否有足够的支撑证据）。这一轮的手册改进贡献了2.51%，助手训练贡献了2.10%。
第三轮进化聚焦于记忆检索：改进了如何根据当前任务阶段和问题结构来提取相关历史信息，避免把陈旧或无关的记录带入当前推理过程。最后一轮手册改进贡献了0.94%，助手训练贡献了1.11%。三轮累计下来，性能从最初的41%提升到了52.82%，每一步的积累都清晰可见。
**失败案例里藏着什么规律**
研究团队还系统分析了不同场景下失败的原因分布。在API-Bank和TMDB这类重度依赖API调用的场景中，大约四分之一的失败来自"动作模块"的问题——格式不对、接口调用顺序有误、工具反复调用陷入循环。在SearchQA这类多跳问答场景中，规划类失败占了相当大比例，主要表现为AI用了过时的查询词在重复搜索，而不是根据最新进展调整搜索方向。在ToolHop场景，多跳工具链的维护失败和最终答案的错误支撑是主要问题。记忆相关的修复虽然占比较小，但往往以"配合修复"的形式出现，稳定着规划和动作的执行。
研究团队通过五个具体的父子轨迹对比案例，更直观地展示了手册改进的效果。例如，在一个需要比较两位历史人物出生日期的任务中，改进前的AI会反复提交没有证据支撑的最终答案，改进后的手册要求AI必须找到有实际证据支撑的答案才能提交。在一个涉及账户删除的API任务中，改进前的AI会在认证步骤反复卡壳，改进后的手册明确了认证和删除操作的顺序规范以及输出格式要求，AI一次性就完成了任务。
**归根结底，这项研究说明了什么**
说到底，HarnessForge揭示了一个关于AI助手系统的本质规律：让一个AI系统真正好用，不是单独打磨某一个零件就能做到的，而是要让"操作手册"和"执行者"形成真正的默契配合。这听起来可能像是一句常识，但在AI领域，以前没有人把这对搭档作为一个整体来系统优化。
对于普通用户而言，这项研究意味着未来基于AI的智能助手和自动化工具可能会在多步骤、多工具的复杂场景中更加可靠——不管是帮你查询和整合多来源信息、调用各类应用接口完成复杂操作，还是在长时间对话中保持准确的上下文记忆。更重要的是，这种进步并不需要换用更大的AI模型，就连40亿参数这种相对"轻量"的模型，经过HarnessForge的联合进化，都能在多项测试中超过那些单独优化的更大模型。
当然，研究团队也坦诚地指出了这项工作的局限性。目前的测试主要在4B和8B规模的模型上进行，对于那些参数量大得多的顶尖模型，手册与助手联合进化能带来多大的改善空间还有待探索。此外，每轮进化都需要多次运行任务来收集数据，在非常复杂的长流程场景中，这个成本可能会相当可观。研究团队提出了几个潜在的改进方向，包括用更快的代理评估替代完整运行、自适应分配计算资源，以及引入更广泛的手册编辑操作（比如完整的代码重写或全新工具接口设计）。
这项研究还有一个更宏观的意义：它为如何在资源受限的条件下让小模型也能胜任复杂任务提供了一条清晰的路径，不是靠堆算力，而是靠让手册和助手彼此适应、互相成就。有兴趣深入了解技术细节的读者，可以通过arXiv编号2606.01779查阅完整论文。
Q&A
Q1：HarnessForge框架的"手册"（harness）具体指的是什么？
A：HarnessForge中的"手册"是指规定AI如何执行任务的外部结构，由三个部分组成：规划模块（负责任务分解和重新规划）、动作模块（负责工具调用格式和协作规则）以及记忆模块（负责信息的存储、调取和整理）。它不是AI模型本身，而是告诉AI"按什么步骤干活"的执行框架，类似于员工的操作手册。
Q2：HarnessForge和只训练AI模型的方法相比有什么优势？
A：单独训练AI模型（策略）的方法假设执行手册是固定不变的，AI只能在既有框架内优化。HarnessForge同时进化手册和AI适配器，让两者形成专属配合。实验显示，即使单独训练方法消耗了更多计算资源（如GRPO和RLOO需要的调用次数是HarnessForge的近4倍），在大多数测试指标上仍不如HarnessForge，最大差距可达12个百分点。
Q3：HarnessForge需要多大规模的AI模型才能有效运作？
A：HarnessForge在40亿参数（Qwen3-4B）和80亿参数（Qwen3-8B）两种规模的模型上都经过了测试，两种规模都取得了显著效果。研究表明，即使是相对轻量的4B模型，经过联合进化后也能在多项测试中超越单独优化的较大模型，说明这套方法并不依赖超大规模模型，在资源受限的场景下同样有效。