Salesforce推出DarwinX框架：不改模型权重，AI智能体浏览器任务完成率从43.5%跃升至93%

能够自我改进的AI智能体可以检查自身失败案例，并修改提示词、工具、技能以及围绕底层模型（即“框架”）的工作流程。但要可靠地让这些改进持续累积却十分困难。某项对某一任务有益的修改，可能使智能体在另一任务上表现更差；而反复优化框架的同一版本，则可能导致系统走上最终趋于停滞的发展路径。

Salesforce AI Research与Salesforce Agentforce新推出的 DarwinX框架 针对该问题采用了一种进化式方法。它不持续重写单一版本的智能体框架，而是探索多个替代方案，保留有用的发现，并且仅当变更在提升能力的同时未导致其他任务性能退化时，才允许其推进。

实验表明，该框架层仍有大量性能潜力可被挖掘。演化框架后，智能体在研究人员测试的全部四项基准测试中得分均有所提升，提升幅度从SWE-bench Verified上的3.4分增至WebArena-Infinity上的49.5分。

DarwinX仅修改框架，从不修改模型权重。这使得该方法对基于托管模型构建应用的开发者具有相关性，他们无需自建微调或模型训练流水线。

为何现有自我改进循环会陷入停滞

许多自我改进智能体框架均采用某种形式的基本循环：在一批任务上运行智能体，检查执行轨迹，识别失败案例，提出对框架的修改，并在验证集或回归测试集上测试经修改后的智能体。

研究人员已将这一思路拓展至提示词优化之外。例如， Darwin Gödel Machine（DGM）允许智能体修改自身的源代码 并维护一个过往变体的存档。 HarnessX则直接作用于提示词、工具和控制流 并将不同任务族的变体相互隔离，以限制干扰。

但Salesforce的研究人员指出了这些方法存在的两个问题。

第一个问题是“路径依赖”。若每一轮迭代均基于当前表现最佳的智能体展开，则早期变更将决定后续所有发展的基础。一项局部有益的编辑可能将进化引向最终趋于停滞的分支，而另一条有前景的分支则可能在尚未充分发展前即被放弃。

设想一次早期编辑教会了一个编程智能体在执行任务前激进地安装所有依赖项。该修改修复了若干失败案例，因而成为新的基线。此后所有编辑均在此行为基础上构建。与此同时，系统可能错过探索另一种策略——即先检查环境，再仅安装所需依赖项。

第二个问题是“跨任务干扰”。某项有助于某一类任务的变更可能悄无声息地损害另一类任务。例如，要求执行详尽验证的指令可能提升复杂科学计算任务的表现，却导致较简单任务超出其时间预算。智能体的任务分布越广，就越难在不牺牲既有能力的前提下实现局部改进。

相同问题对企业团队而言早已司空见惯——他们常在失败后手动修补提示词和工作流程。在向VentureBeat提供的评论中，DarwinX论文高级作者Ran Xu表示：“手动框架工程极易收敛至局部最优：你针对某一种失败模式修正了提示词或工作流程，但若缺乏全面的回归测试，就可能在不知不觉中破坏原本正常运行的功能。”

智能体评估增加了另一重复杂性。结果具有随机性，因此同一智能体可能在某次运行中通过某项任务，而在另一次运行中失败。研究人员援引先前研究指出，行业基准测试在不同运行间测得的百分点波动可达多个点之多，其幅度甚至可能等同于单次框架编辑所呈现的表观收益。

因此，广泛的回归测试与修复触发框架变更的原始失败同等重要。

挑战在于，如何判断哪些改进是真实有效的，如何保持有用替代方案的活性，以及如何在整合新能力的同时不丢失旧有功能。

DarwinX让改进彼此竞争

DarwinX将此视为一个选择问题。它不维持一个持续重写的框架，而是生成不同变体并将其存储于存档中。有前景的版本可继续演化，而其他分支中发现的有用成果亦可保留在后期使用。底层大语言模型（LLM）保持不变。

首个关键机制是研究人员所称的“保留并扩展”（preserve and extend）。

候选框架需在提升某方面性能的同时，将此前已解决任务的性能退化控制在有界容差范围内。简言之，若同一修改导致任务A与C失败，则仅解决任务B所带来的提升价值有限。

DarwinX还将探索与确认分离。一项具有有限负面影响的有前景编辑可通过早期筛选阶段。但在被信任用于指导未来演化之前，系统将以更高保真度重新运行该编辑，并探测此前各版本已解决的任务。此举降低了单次幸运部署误导搜索方向的可能性。

DarwinX之所以能强制执行这种纪律，是因为其编码与浏览器实验的结果相对可靠地可被验证。这使得系统能够检验框架变更是否在增加新能力的同时，保留了此前版本已解决的任务。

对软件工程师而言，“保留并扩展”非常类似于智能体的持续集成：提出变更、测试新行为、重新运行此前已通过的用例，然后才允许该候选版本影响后续版本。正如Xu所言：“关键在于，DarwinX并非简单合并变更并假定结果更优。合并后的智能体仍须通过保留与确认两道关卡，在不退化此前已解决行为的前提下，保留互补性增益。”

第二项机制旨在应对路径依赖问题。DarwinX保留替代分支，包括在整体指标上表现较弱的变体。某一分支整体表现可能较差，却可能包含唯一能解决某类特定任务的变更。DarwinX不会丢弃此类工作，而是将其视为专家型分支。

当不同专家型分支具备互补优势时，该框架可将其加性变更合并为一个新的框架。合并后的版本必须证明其能保留父代的相关增益。这使得在不同进化路径上发现的改进得以再次交汇，而非永远困于各自独立的分支之中。

DarwinX还可从不同来源获取信息以提出下一次变更。它可分析失败轨迹，从更强教师智能体的成功轨迹中学习，或对比智能体自身在同一任务上的成功与失败尝试。这三种信号均导致对框架的编辑，而非对模型权重的更改。

研究人员还将反复出现的失败聚合到共享内存中。例如，如果多个任务因环境搭建耗时过长而失败，系统便可提议一种可复用的搭建能力，而非为每个任务单独创建补丁。

这正是 DarwinX 中‘自然选择’概念变得更加字面化的环节。该系统无需黄金标准解（gold solutions），研究人员也不需人工检查候选方案并手动选出优胜者。Harness 变体能否存续，取决于其在任务评估器下测得的适应度（fitness）。

这并不意味着 DarwinX 在没有评估信号的情况下即可运行。它仍需一种方式来判定某项任务是否成功。例如，在 WebArena-Infinity 的实验中，研究人员使用一个大语言模型（LLM）裁判对不同代理变体生成的执行轨迹（trajectories）进行评分。

这一选择过程也正是 DarwinX 与 DGM 和 HarnessX 等系统相区别的关键所在。DGM 已具备开放式档案（open-ended archive），但其每次仅对一个父代进行变异，且不具备 DarwinX 的跨谱系合并（cross-lineage merging）或显式保留契约（explicit preservation contract）。HarnessX 将各变体相互隔离以抑制干扰，而 DarwinX 则尝试安全地将互补能力重新整合。

DarwinX 实际运行示例

研究人员在 Salesforce 专有的代理 Monet 上测试了 DarwinX。在对照实验中，底层模型保持冻结状态。

评估难度逐步提升，以防止通过过拟合操纵结果。第一轮实验中，代理在相同基准上完成演化与评估；第二轮则在预留任务（held-out tasks）上测试代理；第三阶段在合成浏览器任务上演化代理 harness，并在未见过的真实任务上进行评估；最终实验则将一个在某一基准上演化出的 harness 迁移至一个完全不同的基准上。

在 Terminal-Bench 2.1 上，研究人员报告称，DarwinX 将 Monet 在冻结 GPT-5.5 上的得分从 75.5% 提升至 83.2%，若采用更强的基础模型，则进一步提升至 84.7%。最大幅度的提升来自机器学习与科学计算类任务（上升 14.8 分）以及数据与数据库类任务（上升 13.8 分）。

但比分数跃升更为重要的是促成这些提升的具体变更。演化出的 harness 新增了七项技能，用于指导代理明确定义正确结果应为何种形态、在任务结束前检查所生成文件与数值，并将输出结果锚定于真实工具执行过程。 

演化后的代理也并未在所有地方简单增加推理计算开销。对于两个版本均能解决的任务，中位轮次（median turns）仅从 12 次增至 13 次；相比之下，在六个新近解决的任务上，轮次则从 11 次翻倍至 22 次。这意味着 harness 已学会判断：在哪些场景下额外的验证与重试值得付出相应成本。

TerminalWorld 提供了一个更清晰的实例，说明 DarwinX 为何需维持多个分支。该 harness 在 94 个训练任务上完成演化后即被冻结，随后在 41 个独立任务上接受测试。根据论文，在 Opus 4.8 上，基础版本解决了 41 个任务中的 25 个（即 61%），而 DarwinX 解决了 28 个（即 68.3%）。

更有趣的是，四个专业型变体分别在不同但存在重叠的子集上解决了 24、25、26 和 27 个预留任务。经合并后的 harness 达成 28 个任务的解决率，超越了每一个专业型变体。研究人员将 Opus 4.8 作为 headline 结果予以报告，原因在于同一流程在 GPT-5.5 上仅达成 56.1% 的解决率，低于中性基线代理（neutral baseline agent）；他们将该结果描述为‘相较于最强现成代理（off-the-shelf agent）仅高出一个任务的边际优势’，具有提示性（suggestive）而非统计学意义上的决定性。

徐（Xu）将此结果视为证据，表明聚合分数可能掩盖了有用的能力。‘一个得分较低的变体，仍可能包含某一特定任务类别中唯一成功的行径，’他指出。

一个实际的企业级类比是事件响应代理（incident-response agent）。性能最佳的通用型版本或许能可靠地检查服务、运行标准诊断并准备安全的代码变更；而一个得分较低的专业型版本可能已开发出可靠的 Kubernetes 授权工作流，另一个则可能更擅长数据库恢复与制品验证（artifact verification）。这两个专业型版本均无需单独达到可部署水平，其 harness 变更即可产生实用价值。DarwinX 能够保留这些行为，将其与其他能力组合，并在推广前对合并版本执行相同的回归检查。

TerminalWorld 的结果正是该类比背后的实证依据。论文并未独立分离出重组（recombination）本身相较于 DarwinX 系统其他部分对整体提升的贡献比例。

在 WebArena-Infinity 实验中，DarwinX 基于从应用程序文档生成的 300 个合成意图（synthetic intents）演化浏览器 harness。最终测试包含 1,260 个未见过的任务，采用确定性验证器（deterministic verifiers）而非演化过程中用于对变体评分的 LLM 裁判。在 GPT-5.5 保持冻结的前提下，研究人员报告代理性能从 43.5% 提升至 93%——在未触碰模型权重的情况下，得分提升逾一倍；该数据经审计确认，已筛除轨迹中所有无效或利用式（exploit-style）行为。

最后，研究人员将基于 Terminal-Bench 演化出的 harness 直接迁移至 SWE-bench Verified 上运行，且未做任何修改。据论文所述，其达成 84.2% 的表现，高于参考 harness 的 80.8%，且在演化过程中未接收任何 SWE-bench 的反馈。该结果表明，部分习得的 harness 行为可迁移到其演化所依据的基准之外，尽管论文仅在单一方向上检验了这种迁移能力。 

DarwinX 对开发者的意义

DarwinX 的主要实际优势在于，其改进闭环运行于应用开发者本已掌控的层级之中，无需访问模型权重。

随着基础模型持续进步，这一外围层级的重要性或将日益凸显，而非减弱。Harness 必须适配每一模型的工具调用行为、上下文需求及失效模式；同时，它还承载着通用模型无法仅通过预训练便习得的企业特有信息：实时数据、工作流、权限、身份、治理规则、工具及操作界面（action surfaces）。

‘模型可能吸收更多通用推理能力，而 harness 则日益体现围绕模型的企业特有上下文、操作、治理及适配层，’徐（Xu）表示，‘这可能成为远比任何特定提示词更具持久性的差异化来源。’

更严峻的要求在于构建评估基础设施，以向演化闭环明确界定何谓‘更好’。与编程基准不同，真实企业工作流极少具备单一、清晰的二元验证器（binary verifier）。

徐指出，企业应通过捕捉真实工作过程中发生的情况，并逐步将这些痕迹转化为学习和评估信号，来应对这一问题。以客户服务代理为例：企业可记录该代理的操作、工单状态变更、人工修正、升级处理、政策检查、审批流程以及下游结果。其中部分信号可转化为确定性测试：例如，该案例是否达到了正确的状态？经批准的交易是否完成？数据库中是否包含预期值？其他信号则可能来源于人工修正、合规性检查、业务结果或多名评估者之间的一致意见。

徐表示：“企业未必需要一个单一且完美的奖励函数。它们真正需要的是一个基础设施层，能够持续地将真实工作转化为日益强大的企业智能。”

随着时间推移，该基础设施可生成一套持续更新的评估套件，其内容源自代理实际遭遇的工作流。此举解决了论文中指出的一项主要实践限制：生产环境中的任务极少附带可靠的验证器。团队无需直接针对实时请求演化代理，而是可定期在维护的代理套件上运行演化过程，并部署通过回归检验关卡的版本。

Salesforce 还已通过 Beagle发布了用于实验该方法的基础设施，这是一个在 GitHub 上以 Apache 2.0 许可证开源的框架。Monet 仍为专有技术，但团队可在 Beagle 中引入自有代理运行环境（agent harness）。DarwinX 是一种演化方法，负责搜索、评估并选择运行环境变体；而 Beagle 则提供更广泛的基础设施，支持跨代理、环境、数据集及演化方法开展 rollout 和实验。 

徐将 Beagle 描述为“面向代理演化的 Hugging Face Trainer”：“你提供代理、环境、评估信号以及演化算法，而基础设施负责可扩展的 rollout 和实验。”

从手动更新提示词转向此类自动运行环境持续集成（harness CI）存在成本。DarwinX 探索多个变体，重复执行评估以应对结果噪声，并在候选方案影响后续世代前运行保留性探测（preservation probes）。这比手动编辑提示词需要更多评估算力与更多基础设施。但若手动更新将投入生产，同样需进行回归测试。区别在于，自动化循环可系统性地运行这些实验，而非依赖工程师逐一检查并修复失败案例。

团队亦可控制成本。演化过程可在固定计算预算下运行，并于改进趋于平稳时停止。“目标是持续投入评估算力，直至边际改进不再值得相应成本，”徐表示。对企业而言，相关权衡因素不仅包括推理开销，还包括工程时间与回归风险：系统需多快达到所需质量水平？自动化测试与筛选循环又能防止多少次生产环境回归？

这也意味着 DarwinX 并不适用于所有代理。徐建议，仅对长周期任务采用演化式运行环境优化——这类任务的结果可被合理置信地评估，且具有较大的行为表面积（例如提示词、技能、工具、记忆、控制流或源代码）。 

相比之下，对于简单且稳定的工作流（例如将已知输入映射至固定 API 调用并返回结果），额外增加的机制难以证明其合理性。“我不会仅为追求形式而引入基于种群的演化，”徐表示。确定性工作流通常更易于理解、测试与治理。

此外还存在中间路径。一家企业的客户服务代理可能涵盖足够多变动的工作流，因而能从持续改进中获益，却无需实施完整的基于种群的演化搜索。团队仍可借鉴 DarwinX 的核心规范：将具代表性的失败案例与人工反馈转化为对提示词、工作流、数据库操作、函数调用或集成的拟议修改，并以回归套件作为这些修改的准入关卡。当任务本身不足以支撑维护完整变体种群时，更简单的线性搜索或最佳优先搜索即已足够。