ScholarEvolve 靠读论文升级智能体，不重训模型

加州大学圣塔芭芭拉分校（UC Santa Barbara）和微软研究院的研究人员发布了一个名为 ScholarEvolve 的框架，它改进的是 AI 智能体周围的软件 —— 而不是模型本身 —— 做法是阅读已发表的研究论文，并把其中的技术实现为可运行的代码。据一篇2026 年 9 月 30 日提交到 arXiv 的预印本介绍，该系统把一个冻结的 Qwen3.5-27B 模型在 AppWorld Challenge 基准上的任务完成率从 49.6% 提高到 63.6%，没有改动任何一个模型权重。

这 14 个百分点的提升，挑战了智能体 AI 部署中的一个常见假设：更好的智能体表现需要更好的模型。ScholarEvolve 的结果表明，包裹模型的软件 —— 它如何访问工具、接收什么上下文、如何检索过往经验、决策如何组织 —— 可能是比模型能力本身更大的性能杠杆。在两个成熟的基准上，这个框架都胜过了一条只用执行失败日志来改进同一套 harness 的基线。

延伸阅读：Dream-RSI：智能体自己改进搜索策略

智能体 harness：决定模型看到什么的软件

在现代的智能体部署中，模型处在一个软件脚手架 —— 即 harness —— 之内，由它决定哪些工具可用、哪些记忆和上下文片段进入模型的窗口，以及由什么决策流程支配下一步动作。harness 不改变模型权重；它改变的是模型在每一轮所处的信息环境。

随着生产环境中的智能体部署显示出，同一个模型的表现会因环境的组织方式不同而差别很大，harness 工程已经成为一门独立的学科。有精心整理的过往经验可用的模型，会少做冗余的 API 调用；被赋予多阶段决策工作流的模型，会少出格式错误。

ScholarEvolve 把 harness 分解为五个可独立替换的模块 —— 工具接口、上下文、技能、记忆和工作流 —— 并把已发表的 AI 研究论文作为每个模块候选改进的主要来源。这篇论文由 Jingbo Yang、Kwei-Herng Lai、Xiaowen Wang、Yaar Harari、Evgeniy Gabrilovich 和 Shiyu Chang 撰写，可在 arXiv 上获取，并附有 开源代码。

ScholarEvolve 如何把已发表的论文转化为 harness 代码

这条流水线从失败分析开始。ScholarEvolve 在训练任务上运行当前的 harness，阅读执行轨迹，找出反复出现的能力缺口，并剥离与具体应用相关的细节，使失败描述可以迁移 —— 把一次具体的查询遗漏，转化为「未能保留中间检索结果」这样的一般性描述，从而可以通过记忆架构、上下文过滤或技能提取来解决。

随后，一个研究智能体为每个模块生成搜索查询，并从 arXiv 检索候选论文。通过 TopicGPT 做主题建模，把结果组织成每个模块内彼此不同的改进策略，避免多个名额被几乎相同的论文占去。AppWorld 的主要实验为五个模块各分配四个候选 —— 每轮演化共二十个候选。

被选中的论文会被转化为修改蓝图 —— 该方法做了哪些假设、针对哪个模块、需要哪些额外的状态或模型调用，以及如何与现有接口衔接。一个编程智能体每次实现一个模块。任何修改后的 harness 版本在参与竞争之前，都必须能运行、接口兼容，并且能生成和重新加载经验材料；随后它在留出的验证任务上运行，由一项置信度 90% 的任务配对自助法（bootstrap）比较来决定这项改动是否保留。在 AppWorld 的二十个候选中，有三个使性能下降，两项上下文模块的改动让任务完成率下降了 40 多个百分点 —— 自动化的代码改动带有实实在在的回退风险。

该系统还会搜索有益的模块组合，因为单独表现良好的组件，与其他组件之间可能相互作用不佳。在 AppWorld 实验中，一个单独得分 75.4% 的技能候选，在完整的组合 harness 中被一个单独得分只有 73.7% 的候选超过，后者的组合结果是 84.8%，前者是 80.7% —— 这说明模块之间的交互效应可以压过单个组件的表现。

有三个模块值得细看。技能模块 采用 Skill-as-Pseudocode（技能即伪代码）：它从轨迹中提取反复出现的成功 API 调用序列，把它们存成带有触发线索和出现次数的带注释流程，并在推理时通过把任务描述与已存的触发线索相匹配来检索。记忆模块 存储完整的任务经验 —— 要求是什么、采取了哪些步骤、调用了哪些 API、任务是否完成 —— 并在模型开始新任务之前检索相关的摘要。上下文模块 在检索到的技能、记忆摘要和当前交互历史之间分配字符预算，按相关性和时效性过滤，同时保留时间顺序，让模型按事件实际发生的顺序收到有用的信息。

基准显示了什么 —— 以及它们衡量的是什么

AppWorld 包含 750 个任务，覆盖九个应用环境、457 个不同的 API 操作，采用基于状态的单元测试来评估，要求智能体执行正确的 API 调用序列以产生正确的系统状态 —— 而不只是产出听起来合理的输出。

ScholarEvolve 把两个应用 —— Amazon 和 Gmail —— 排除在演化和验证之外，然后在需要这两个应用的 417 个 Challenge 任务上测试。在这个留出的划分上，使用演化后 harness 的 Qwen3.5-27B 达到 63.6%；Meta Harness 基线（只用执行反馈，不读论文）达到 54.6%；初始 harness 为 49.6%。场景级指标要求一个场景的全部三个任务变体都成功，它从 28.3% 升至 44.8%。

在 τ²-Bench Telecom 上 —— 它测试智能体通过查阅支持手册、解读工具输出并与模拟用户协调来处理电信服务请求的能力 —— ScholarEvolve 把 GPT-5.4-mini 的单次通过成功率从 72.7% 提高到 81.9%，四次全对的一致性从 49.2% 提高到 58.3%。所有数字均由机构自行报告，尚未经过独立复现。

反方观点：harness 演化 vs. 更简单的替代方案

最有力的质疑来自一篇2026 年 7 月由艾伦人工智能研究所（Allen Institute for AI）和华盛顿大学研究人员发表的批评文章。这篇论文发表于 ScholarEvolve 提交之前，它认为，harness 演化带来的增益，并不总是大于给同一个模型更多推理算力所能达到的效果 —— 更多的采样次数、更大的搜索预算，或测试时的自我批评循环。如果采样五个答案而不是一个就能达到同样的表现，那么对多数从业者来说，一条读文献的流水线在工程上的复杂度可能并不划算。艾伦研究所和华盛顿大学的团队还质疑了泛化性：在验证划分上校准出来的 harness 改进，可能过拟合于那个任务分布，而不是广泛迁移。

ScholarEvolve 的持续演化实验从另一个角度回应了泛化问题：不是看改进在单轮之内能否跨任务类型成立，而是看随着新文献的发表，这个框架能否持续改进。把 arXiv 论文划分为三个互不重叠的时间窗口 —— 截至 2025 年 12 月、2026 年 1 月至 4 月、2026 年 5 月至 8 月 —— 每次运行一轮新的演化，AppWorld Normal 的任务完成率从 69.0% 升至约 81.5%，场景成功率从 48.8% 升至约 66.7%，其间 Qwen3.5-27B 的权重和累积的经验保持不变。每一波新研究被转化为 harness 改进之后，都与此前的增益叠加 —— 这提示了一种可能替代反复微调模型的路径。

成本上的取舍仍然缺乏量化。多角色工作流（规划者、求解者、批评者、验证者）在每个任务上都增加了模型调用。演化流水线用 GPT-5.4 同时充当论文阅读者和编码者，需要大量算力，而论文没有给出端到端的量化 —— 这使得难以评估，相对于直接运行更大的模型或增加推理预算，基准上的改进在经济上是否高效。

在研究文献与运行中的智能体之间，架起一条开放的流水线

ScholarEvolve 最深层的贡献可能是架构上的：一个把五类不同关注点分开的模块化 harness，加上一条把已发表的研究转化为接口兼容的代码改动、并在部署前做统计验证的自动化流水线。该框架已在 GitHub 上开源，其模块化设计允许替换单个组件，而无需重建周围的系统。

延伸阅读：英伟达开源 SoL-Pi：面向编程智能体的自主 harness 优化器

它所参与的 harness 演化领域，如今也有了自己内部的争论。同期的论文包括 HarnessEvolve 的分层反思方法、EvolveNet 对 harness 变体的进化搜索，以及 Evo-HARNESS 把反馈与规划结合的系统。ScholarEvolve 的不寻常之处，在于系统性地把学术文献作为候选改进的主要来源 —— 从而绕开了纯执行反馈的根本局限：后者只能在当前系统已知的失败词汇范围内提出解决方案。

独立团队能否复现这些增益，以及这种方法能否扩展到其他基准，将决定 ScholarEvolve 的最终贡献。而更直接的问题 —— 一个组织的智能体基础设施，能否跟着已发表的文献同步改进，而不是等待下一次模型发布 —— 如今已经足够可信，值得认真投入工程上的关注。