RSI（Recursive Self-Improvement，递归自我改进）关注系统如何利用反馈改进自身，并让保留下来的变化参与后续改进。

本文回答三个问题：系统在改进什么、代表论文怎样改进、效果和成本如何验证。 第 1—2 章建立共同记法，第 3 章按方法路线展开，第 4 章讨论评测，第 5 章单列成本。论文完整解读与更多原始资料见资料目录。

1 改进对象、系统构成与技术路线

最终都希望得到更好的任务结果。 改进对象说明这次改哪里；F/H/R/A 说明系统各部分的作用；四个环节说明怎样完成一次改进。

1.1 改进对象与验证方式

最终都希望得到更好的任务结果，区别在于反馈用来改什么。 可以先记住三句话：重做这次任务、改进系统、改进给系统做优化的方法。 反馈可以是失败，也可以是质量、耗时或成本不够理想。

1. 带着反馈重做任务：改好这次的结果

例如，AI 写出的函数测试失败，把报错交回给它，再修改这份代码。反馈可以由用户、自动测试或模型自检提供，修改也可以进行多轮。

论文例子：Self-Refine: Iterative Refinement with Self-Feedback（Aman Madaan 等；CMU、Allen Institute for AI 等，2023）。

它让同一个模型先生成答案，再对答案提出反馈，最后根据反馈改写：生成 → 自评 → 改写当前答案。这个循环可重复，反馈与改写的规则保持固定；变化的是本次输出。作者在文本和代码等任务中比较改写后的输出与一次生成的输出。

验证重点： 这次交付的代码、报告或答案是否更好。单次结果变好，并不说明系统本身已经改进。

2. 用反馈改进系统

修改的是系统中的通用 Prompt、Skill、工具、上下文处理或工作流程。改动保留为新版本，供后续任务使用。

论文例子：A Self-Improving Coding Agent（SICA）（Maxime Robeyns 等；University of Bristol、iGent AI，2025）。

Agent 阅读历史日志与评测，修改自身代码，再评测新版本。论文观察到，它从只能整文件覆盖，发展出按 diff 或行区间局部编辑的工具。这次改的是编辑工具，后续任务可以继续使用，不只是修好某一份业务代码。

验证重点： 在可比任务与条件下，新系统是否比旧系统做得更好，成本如何变化。

3. 改进优化方法：让后续优化更会找问题、提改法和选方案

修改的是“怎样改进系统”的规则。例如，原来看到失败就追加提示词，现在先判断问题出在提示词、工具还是上下文，再决定改哪里。

论文例子：HyperAgents（Jenny Zhang 等；UBC、Meta 等，2026）。

它允许负责改进系统的 Agent 修改自己的实现。论文附录 E.3.1 记录了一个变化：改进者给自己新增评测分析程序，先汇总历史成功、失败和错误，再将分析结果用于提出下一轮修改。改变的是产生改法的步骤，后续系统优化会沿用这个新步骤。

验证重点： 在相同起点、任务与预算下，新优化方法产生的改动是否带来更好的效果，整个优化过程的成本是否合理。

Prompt、Skill 按用途区分。 临时补充本轮指令，可以帮助重做当前任务；修改后续任务复用的通用规则，属于改进系统；修改“如何优化系统”的规则，属于改进优化方法。

这三类按具体改动区分，可以同时发生。SICA 的工具改动也可能帮助它后续修改自己，HyperAgents 同时允许修改任务执行部分，不能给整篇论文只贴一个类别。是否形成 RSI，还要看系统是否参与自身改进，以及保留的变化是否继续参与后续自改进。

1.2 四类系统对象

前一节区分这次直接改什么；下面用 F/H/R/A 说明系统中各部分的作用，帮助定位改动。它们是本文对照论文的记法，不要求部署成四个服务。

Systemt=(F,Ht,Rt,At)\mathrm{System}_t=(F,H_t,R_t,A_t)

对象 作用 典型内容
F：模型配置 提供推理与生成能力 执行和改进所用模型及关键调用设置；本文比较时固定
H：执行框架（Harness） 组织一次任务怎样完成 Prompt、Skill、工具、上下文、编排、重试与自检
R：改进策略 分析反馈，提出和安排跨版本修改 诊断、候选生成、搜索、经验检索与停止规则
A：经验档案 保存下一轮可以使用的依据 候选版本、运行结果、修改记录、成功和拒绝经验

y 是一次任务的产物，例如报告、业务代码补丁或计算内核。它由 H：执行框架 调用 F 完成任务后产生，因此单独列出；需要时也能作为证据存入 A。

对象按作用区分。同样是代码，修用户项目得到的补丁是产物 y，修改 Agent 的执行工具属于 H：执行框架，修改“怎样生成下一版 Agent”的逻辑属于 R：改进策略。任务内的反思属于 H：执行框架；分析多次执行并生成系统改动的策略属于 R：改进策略。

1.3 对象、路线与流程的对应

改进对象、系统构成与改进流程

改进对象决定比较什么，技术路线说明怎样改，四个环节说明怎样执行并验证改动。

  • 本次产物： 主要评价 y，例如更快的计算内核。生成器可以完全不变。
  • 任务执行系统： 在本文固定模型的范围内，主要评价 H：执行框架，例如更可靠的工具调用与上下文管理。
  • 改进方法： 主要评价 R：改进策略 产生有效修改的能力，不能只看一次提议或最终最高分。
  • 共同支撑能力： 经验、评估、观测、隔离和版本管理可服务上述多种改进。

例如，使用固定的 R：改进策略 自动优化 Prompt，直接改善的仍是 H：执行框架；只有比较新旧 R：改进策略 如何产生改进，才能评价改进方法。模型训练与 Harness 联合演进还会改变 F，超出本文固定模型的主要范围。

2 一轮改进的执行与验证

Sₜ 表示当前系统状态。下面以修改执行框架 H 为例，模型配置 F 保持固定。

2.1 提议

Ct=ProposeF(St,Φt;Bt)C_t=\mathrm{Propose}_F(S_t,\Phi_t;B_t)

S(c)=St⊕Δ(c)S^{(c)}=S_t\oplus\Delta^{(c)}

输入是当前状态 Sₜ、历史反馈 Φₜ（如失败测试、被拒理由）和本轮预算 Bₜ；输出是有限个候选状态，或可作用到当前状态上的补丁 Δ。

例如，R：改进策略 读到“反复跑全量测试消耗大量 token”的记录，提出候选流程：先跑全量测试定位失败，修改期间只重测失败文件，最后再做完整回归。这里的候选修改的是执行框架 H；候选尚未通过验证，也不是已发布版本。

2.2 运行

u=(τ,y,o,k)=RunF(H(c),x,e)u=(\tau,y,o,k)=\mathrm{Run}_F(H^{(c)},x,e)

输入是候选执行框架 H⁽ᶜ⁾、任务实例 x 与环境初态 e；输出四项：轨迹 τ、产物 y、最终环境状态 o、成本记录 k。

例如，y 是修好某个 Bug 的补丁，H⁽ᶜ⁾ 是后续任务也能沿用的测试流程。这里优化的是 H：执行框架，y 是衡量它效果的任务产物。轨迹要保留，因为“减少无效重试”这类变化需要从执行过程中判断。

2.3 评估

z=Eval(τ,y,o,x,k)z=\mathrm{Eval}(\tau,y,o,x,k)

评估输出一组信号：单元测试、隐藏测试、静态检查、模型或人工评分，以及 token、时延与金额。评估读取最终状态 o 中的完整 diff 和回归结果，不能只采信模型自己的描述。

候选与基线使用相同条件。 在同一快照的两份独立副本上运行，各用单独容器，避免状态互相污染。模型输出有随机性，一次 A/B 对比不足以下结论，需要重复运行。

外部评价协议保持固定。 H：执行框架 内部的自检、重试和校验可以随候选改变，但对外打分的协议不能由被评对象改动，否则可能靠降低标准获得表面收益。

2.4 更新

St+1=Update(St,Ct,Zt)S_{t+1}=\mathrm{Update}(S_t,C_t,Z_t)

Zₜ 汇总本轮所有候选、任务与重复运行的评估结果。更新有三个出口：保留、拒绝、暂存。无论哪个出口，结果和原因都写入经验档案 A，供后续改进使用。

保留候选与发布上线是不同决定；需要上线时另做部署验收，并保留恢复旧版本的能力。

2.5 策略与经验的验证

修改 H：执行框架 时，让新旧框架完成相同任务，比较产物、过程与成本。下面用简写只表示产物 y，省略轨迹等输出与环境参数：

y=RunF(H,x)y=\mathrm{Run}_F(H,x)

修改 R：改进策略 时，让新旧策略从可比的 H₀、可读档案 A₀ 和相同预算出发，实际产生并验证改动，再比较改进效果与总开销：

H′=ImproveF(R,H0,A0;B)H'=\mathrm{Improve}_F(R,H_0,A_0;B)

A 新增经验，可能让固定的 R：改进策略 提出不同修改；这不等于 R：改进策略 的规则改变。H：执行框架 与 R：改进策略 可以位于同一份代码中，区分它们是为了说明改动的作用。

搜索使用开发反馈，独立验收材料与搜索隔离。验收结果一旦参与后续修改，就不能继续当作独立证据。采纳标准事先确定，总成本包括失败候选与评分。

3 方法路线与代表成果

3.1 路线总览

本章按每篇论文的主要贡献分组。多数论文会同时覆盖多个环节，也可能同时改动多个对象。例如：

  • Promptbreeder 同时演化任务提示（属于 H：执行框架）和变异提示（属于 R：改进策略）。
  • DGM 的 Agent 代码既用于执行任务，也用于修改自己，但外层的父代选择逻辑是固定的。

因此，分组只说明阅读重点，不表示一篇论文只对应一个流程节点。以下结果均来自各论文的实验，模型、任务和指标各异，不用于跨论文排名。

以下条目按解释机制、比较基准或检验边界的作用入选，完整解读保留原论文条件。资料库中的候选与扩展阅读不自动进入本章。

3.2 提示策略优化

这一路线不改模型权重，只改写提示文本。两篇论文的区别在于“改写依据从哪里来”：GEPA 依靠执行轨迹中的诊断信息，Promptbreeder 让“如何改写”本身也进入演化。

  • GEPA：从执行轨迹和文字反馈中诊断问题，改写提示并保留互补候选。 入选理由：用文字反馈驱动提示优化，是理解提示路线的直接案例。
  • Promptbreeder：同时演化任务提示和负责改写任务提示的变异提示。 入选理由：作为提示演化的早期对照，区分改进对象与产生改动的方法。

3.3 Agent 执行框架优化

这一路线的优化对象从提示扩展到工具、上下文处理和控制流程代码。

  • SICA：让编码 Agent 修改自己的工具和执行流程，保存各版代码与评测结果，再选择下一轮的改进起点。 入选理由：具体的编辑工具变化说明系统改进可以发生在模型权重之外。
  • RRSI：约束候选提议与选择，检验框架优化的泛化和复杂度增长。 入选理由：同时处理演化集过拟合和执行开销，连接方法、评测与成本。

3.4 跨任务经验与组件复用

新的任务可能没有现成真值验证器，改进中积累的经验也需要跨任务保留。

  • Harness²：通过行为对比适配新任务，保存执行框架与经验供后续任务复用。 入选理由：展示搜索期没有真值验证器时的反馈与跨任务经验复用。

3.5 改进策略自身优化

评价改进策略的难点在于：必须让它完整运行一次改进过程，再看它产出的结果好不好。

  • HyperAgents：共同修改任务系统与改进程序，并检验改进策略能否在新领域产生收益。 入选理由：给出改进策略迁移的具体协议，也保留 task/meta 同时迁移的限制。

3.6 改进收益的验证

这两篇论文不提出新的优化算法。它们检验的是“改进”这一结论本身能否成立，因此只报告检验发现，不换算成优化收益。

  • Elicitation or Expansion：用不同尝试预算和任务难度检验成功率提高是否意味着可解范围扩大。 入选理由：关键反例：更高的单次成功率不能独自证明能力范围扩大。
  • 评估证据审计：将 RSI 论文的产物主张和过程主张与各自的评估证据对应。 入选理由：区分产物改善、过程可重复与改进器增强所需的证据。

更多方法包括 DGM、MaD-RSI、STOP 与 HSI，见全部相关资料。

4 评测目标、任务集与改进验证

评测为演化提供方向，也决定我们能证明什么。 系统要比较任务效果；优化方法还要比较：在可比投入下，能否反复产出更好的系统。详细任务集对照见评测文章；这里保留优化方法的验证原则。

4.1 目标、开发反馈与最终验收

要判断演进是否有用，需要先明确改善目标；评测不一定是一套静态题库。

“有没有评测集”实际上混了三件事，它们的作用不同：

环节 回答的问题 示例：改进一个修 Bug 的 Agent
目标 往哪个方向改 提高真实仓库 Issue 的修复率，同时控制功能回归、费用与耗时
开发反馈 候选改得怎样，用于提议和选版 一批开发 Issue 的测试结果、失败日志、耗时与费用
最终验收 冻结后的系统是否真的更好 另一批未参与修改和选版的 Issue，用官方测试判定

目标的来源可以有三种：

  • 任务本身，例如基准的通过标准；
  • 环境后果，例如测试通过、游戏得分、文件是否正确生成；
  • 人类要求，例如审阅者偏好、业务约束。

开发反馈也可以来自持续到来的任务流、环境后果或人工评价，不必是固定题库。如果只有模型自评、没有任何外部后果，产出只能算”待验证候选”。

两类证据的分工：

  • 开发反馈：允许优化器看到，甚至反复看到。正因如此，分数会自然偏向这批任务。
  • 最终证据：离线优化可复用系统时，应冻结候选，再用未参与提议、调参、选版的任务验收。在线适配则按预先约定的可见反馈和适配预算评价，见 4.4。

离线研究还常把开发侧分成搜索集和选版集：前者用于产生改动，后者用于挑选候选；最终测试再检查收益。验证集一旦反复用于选版，也不能当作完全独立的最终证据。

如果同一批任务既提供反馈又用于报告结果，结论只能是”系统适应了这批任务”，不能说明系统在新任务上更好。

4.2 Harness 类型与评测集对照

改动对象与任务类型分开看。 train/val/test 通常表示训练或搜索、验证、测试，实际用途以各论文协议为准；OOD 指分布不同的域外任务。

候选数量不是题数；同一任务换随机种子再跑一局（episode），不等于增加了新任务；把成品重测多次，也不等于把整个优化过程重跑多次。

详细的任务、交付物与判分对照见评测文章。其中补充了不同类型 Harness 的原始研究；本综述不把每篇补充资料自动列为精选代表作。

4.3 优化方法的对照验证

评价优化方法，要先让它产生改动，再检验改出来的系统。

这里有两个不同的问题：

  • “最终系统更好”：比较冻结的新旧系统在相同任务、评分标准与资源条件下的表现。
  • “优化方法更好”：让新旧方法在可比投入下各自完成优化，再比较产出的系统与整个搜索过程。

离线优化的建议协议

  1. 同起点：两种方法从相同的初始任务系统出发，可读到相同的经验，使用相同的模型和环境。

  2. 同开发条件：相同开发任务、预算上限与外部验收标准。内部的分析、提议、筛选和提前停止策略允许不同，这些正是被比较的方法。相同候选数不等于相同计算预算。

  3. 冻结：两种方法在预算内各自产出候选，冻结后进入验收；最终测试反馈不参与这一选择。冻结范围包括代码、提示、工具配置及允许带入验收的经验。

  4. 独立验收：在没有参与提议、调参、选版的任务上验收。原始 Harness 也一起验收，作为参照。

  5. 分开记账：

    • 执行侧：比较收益、回归、失败和执行成本；
    • 搜索侧：另记提议、试跑、评分、失败重试的费用，以及达到目标所用的时间。

  6. 重复完整优化：重复整轮优化，报告全部运行结果，而不是只挑最好的一次。

新旧优化方法的对照验证

“测 5 遍”与”优化 5 遍”不是一回事：

  • 把同一个最终 Agent 测 5 遍，衡量的是执行随机性；
  • 把优化过程完整重跑 5 遍，衡量的是优化过程的随机性。

只有后者能回答”这种方法是否稳定地产出更好的系统”。

4.4 对抗测试与评测可信度

对抗测试的定位。 对抗、鲁棒性和评分漏洞测试，用来检查系统是否脆弱、分数是否可信，是验收的补充。它不能代替正常任务上的端到端收益。正常任务衡量实际收益，对抗测试检查特定风险、脆弱性和评分漏洞。

优化器相互对战时，需要两条约束：

  • 固定胜负标准；
  • 保留一个固定的参考基线，并校准胜负与真实任务表现之间的对应关系。

否则优化器可能只学会赢当前对手，而不是在任务上变得更好。

分数也可能来自泄漏。 Anthropic 对 BrowseComp 的审计发现，部分成功答案来自基准材料本身，而不是真正解题。另一篇评测方法文章给出了三组值得采用的区分：

  • 只看轨迹，还是看环境的最终状态；
  • 能力评测，还是回归评测；
  • pass@k（至少成功一次），还是 pass^k（每次都成功）。

Harness² 的搜索反馈与最终判定

Harness² 在搜索期没有能核验任务正确性的真值验证器（ground-truth verifier）。它通过对照试跑观察行为变化与回归，但其中的 Probe 不能验证任务是否做对。最终结果仍然依靠基准隐藏测试、文件检查或独立的语言/视觉模型评分。因此，它是”搜索期无真值”，不是”完全无评估”。

DuoDiscover 的代理指标校准

DuoDiscover 面对的是另一类问题：真实评估存在，但太贵，缺少廉价可靠的代理指标。它自行构造快速代理指标（yardstick），并周期性地与真实评估校准；一旦代理失真，就废弃重建。确认收益仍然依赖真实评测。

测试期适配的协议边界

测试期适配不应一概视为数据泄漏，关键在于把协议写清楚：

  • 评测阶段允许系统看到哪些输入和反馈；
  • 评分标签是否对系统可见；
  • 用什么规则选择版本；
  • 对照组是否拥有同样的适配预算。

Rethinking v4 中游戏上的正结果，就应当按”同任务在线适配”来报告，而不是写成跨任务泛化。

开放任务的最终判定

把评价拆成两部分：

  • 可测约束：格式、测试、合规检查等，用机械方式判定；
  • 开放质量：交给人工盲评、专家评审，或后续的真实后果（例如补丁合并后是否被回滚）。

多个模型意见一致不等于正确；代理审查也不能当作人类验收。

编程 Agent 的补充验收

在 4.3 的对照中，正常 Issue 检验真实修复与功能回归；另加诱导忽略需求、修改评分脚本或削弱测试断言的对抗样例。合理补测试可以是有效修改，不能只因“碰了测试文件”就判作弊；最终验收仍由评测侧保管的标准和真实终态决定。

同时报告正常任务收益、对抗失败和完整搜索成本。若新方法只是更会绕过评分，而真实结果没有改善，就不能算目标上的改进。这份协议的下一步是选定实际任务与预算，再开展对照，不把建议写成已经得到的收益。

5 成本、降本技术与预算

RSI 的开销来自生成候选、运行任务、评估结果、执行环境和人力准备。 运行次数会随候选数、任务数、重复次数和搜索轮数增加；单次模型或工具调用的消耗同样重要。

5.1 成本构成

开销 为什么发生 需要记录
候选生成 模型读日志、代码和历史，提出修改 提议次数、输入输出 token
任务执行 基线和候选分别完成任务 每任务的模型调用、工具调用、token 和耗时
评估 判分、回归、独立验收与人工复核 评分调用、完整评估次数及资源费用
运行环境 沙箱、计算、存储、网络 资源规格、计费时间和账单
人力与排程 准备任务、接入调试、复核结果 人时及步骤之间的依赖

主要开销取决于任务。 Agent 多步执行可能主要花在模型调用；系统或芯片优化可能主要花在昂贵评估；接入初期还要单列工程人力。下面先看论文如何降低这些开销，再估算一轮实验的预算。

5.2 降本技术与对比证据

技术方向 代表工作 主要节省什么
用廉价反馈筛选，再做真实评估 DuoDiscover 昂贵的完整评估次数
按质量与成本共同选择版本 HarnessPro 部署后每任务的执行费用
复用已确定的决策，跳过重复推理 HarnessMM 完整任务中的模型 token
限制无效增长、复用多模型优化 RRSI、MaD-RSI 执行 token 或多次优化的总消耗

各行统计的是不同成本，不能直接按节省百分比排名。以下结果来自论文原实验。

DuoDiscover 展开代理度量与真实校准；HarnessMM 展开模型—工具边界的决策复用。两者分别节省评估次数与执行 token，不能混成同一种成本。

其他路线中的成本证据

第 3 章的 RRSI 与 MaD-RSI 也涉及费用，但它们的对照口径不同：

工作 比较对象 原文结果与限制
RRSI 同一 workspace 设置的无正则演化与 RRSI 每任务 3.80M → 2.42M token；原始 H₀ 为 1.56M。因此是相对无正则演化更省，并非低于原始系统。
MaD-RSI 共享优化与四次独立单模型优化的总账 训练 token 在 LawBench、MBPP+、MedXpertQA 分别减少 18.3%、55.9%、52.4%；安全任务增加 15.2%。不能读成所有场景都节省，也不能当作一次单模型优化的比较。

5.3 各项开销的估算

下面的金额沿用 5.4 的统一预算参数，用于说明各项如何计费。

候选生成

提议次数按本例的“每轮提议数 × 轮数”计算，不乘任务数和重复数，在 5.4 的预算示例中，它占已列现金费用的 1.8%。但每多一个候选，就要多跑 20 道开发任务 × 每题重复 2 次 = 40 次。按本例单价，执行、可选评分和沙箱合计每次约 0.1166 USD，40 次约 4.66 USD，另加提议本身的 0.15 USD。在本例假设下，多一个候选的现金开销主要来自后续执行、评分与沙箱。

任务执行

任务执行量会被多个因素共同放大：版本、任务、重复、轮数都会把它放大。在本算例中，输入 token 的费用高于输出。agent 多步交互会不断累积上下文，本例中 30k 输入占单次 0.08 USD 里的 0.06。估算时建议先用少量任务实测真实的 token 用量，再乘运行次数，不要只凭经验估一个数。

论文中的每任务 token 和整次搜索费用不可混算；预算应先用自己的任务实测单次消耗，再按计划规模估计。

结果评估

评估可以用程序化测试或模型判分。程序化测试无需新增模型评分调用，但仍消耗执行环境资源；需要 GPU 或特定环境时，费用应单列。用 LLM 评分器判分，每次 run 都要多一次调用，本例为 280 × 0.009 = 2.52 USD。任务本身有可靠测试时，可以去掉这一项。

注意功能与计费的区别：独立验收在功能上属于评估，但那 80 次运行在算例中计入了“任务执行”。

运行环境

本算例按固定沙箱规格的计费存活时间估算环境费用。本例中每次 run 计费 10 分钟，折合约 0.0276 USD，大约是单次 token 成本的三分之一。乘上 280 次后，它成为第二大项。

估算方式是：运行次数 × 每次计费时长 × 时价。计费时长可能包含模型生成之外的时间：安装依赖、等待工具返回、run 结束后没有及时销毁环境，是否计费取决于服务规则，估算时要按实际账单口径核对。另外要注意，缩短超时或降低规格并不是单纯的节省，它会改变测量条件（见 5.6）。

5.4 单轮实验预算示例

这是一份按假设参数计算的预算，不是已发生的项目费用。 先固定任务、基线、修改范围和成功标准，再比较候选；未参与修改的任务用于最后一次独立验收。

参数 取值 说明
开发任务数 N 20 搜索阶段用来比较候选
候选数 C 4，另加 1 个基线 本轮由模型提出 4 个新版本
重复数 r 2 每个版本在每道题上跑两次
轮数 K 1 只做一轮搜索
独立验收任务数 N_test 20 留出集，不参与搜索；只让最终候选与基线各跑 r 次
正式运行总数 280 开发 (4+1)×20×2×1 = 200；验收 2×20×2 = 80

在每轮重跑基线和候选、最后只做一次独立验收的设置下，计数公式为 (C+1)×N×r×K + 2×N_test×r。

单次用量假设如下：每次 run 输入 30k token、输出 2k token，不做缓存；每个候选提议输入 50k、输出 5k；可选的 LLM 评分器每次 run 输入 2k、输出 500。采用下列演算单价：输入 2 USD/MTok、输出 10 USD/MTok（平台定价）。沙箱采用 E2B 的 2 vCPU + 4 GiB 规格，0.1656 USD/h（E2B）。两项单价都是 2026-10-28 核对后的演算假设，不代表当前报价。

项目 算式 金额（USD） 占比
任务执行 280 × (30k×2 + 2k×10)/1e6 = 280 × 0.08 22.40 67.4%
沙箱运行时 280 × 10 分钟 = 46.67 h，× 0.1656 7.728 23.2%
可选模型评分 280 × (2k×2 + 500×10)/1e6 = 280 × 0.009 2.52 7.6%
候选提议 4 × (50k×2 + 5k×10)/1e6 = 4 × 0.15 0.60 1.8%
合计 33.248 ≈ 33.25 100%

规模扩展示例： 其他假设不变，搜索增至三轮，每轮仍提出 4 个候选并重跑基线；最后只做一次独立验收。正式执行为 5×20×2×3＋80＝680 次，提议 12 次，API 62.32 USD、沙箱 18.768 USD，现金小计约 81.09 USD。若增加验收次数，要重新计数；验收结果一旦参与后续选择，其独立性也随之改变。

单轮预算的现金开销分布

在这些参数下，任务执行与沙箱合计约占现金小计的90.6%；不同任务的占比需要实测。

5.5 人力与项目历时

规划假设如下（不是对论文团队工时的陈述）：

  • 准备任务：40 题（开发 20 + 验收 20）× 6 分钟 = 4 小时
  • 复核轨迹：50 条 × 3 分钟 = 2.5 小时
  • 工程预留：16 小时，用于接入 harness、调试环境

合计 22.5 人时。本文不设时薪，也不折算成美元，因此人力不进入现金占比。

执行排程与项目历时

在 5 路并发下，280 次 run 分 56 批，每批 10 分钟，共 9 小时 20 分。这个数依赖两个假设：每次 run 连续占用一个并发槽 10 分钟，且 5 路全程满载。

它只是执行排程，不含提议、等待依赖和人工复核的时间。22.5 人时也不能直接加到 9h20 上当作历时，人时说的是工作量，历时取决于步骤之间的依赖：提议要等上一轮结果，验收要等候选收敛，人工复核要等轨迹落盘。真实历时应按依赖关系排程得出。

5.6 预算边界与结果判定

类别 内容
已计入 33.25 USD 280 次正式执行、4 次候选提议、280 次可选模型评分、执行所用沙箱运行时
另记（会发生，但未估算） 正负对照、接入预检、异常重试
尚未知（未进小计） GPU 评估、存储、网络、订阅、税；人力折现；真实项目历时

可考虑的节省方式包括：缓存、复用已完成的 run、减少无效重复、用便宜的代理指标初筛。但最终验收必须在固定条件下重跑。调小单个 trial 的资源或缩短超时，会改变测量条件；即使只调整排队并发，也要记录服务负载和运行时段的变化。

采用候选时同时检查效果、回归与费用。预算不足或评分失败应如实记录；不能只保留成功尝试，也不能为了通过验收而修改评分标准。

更新于 2026-11-09 · 研究方法