编者摘要：本文提出智能体元推理（Agentic Meta-Reasoning）框架，把智能体的流程控制从任务求解中独立拆分，实现对自身计算过程的显式管控。传统智能体将控制决策与任务执行交织，中间成果难以复用，算力增加后性能容易进入平台期，长任务上下文冗余嘈杂。

框架由控制器、精简状态、持久化内存、并行工作单元构成，控制器循环分为四阶段：评估（Assess）、提议（Propose）、方案评估（Evaluate）、分发（Dispatch）。持久化内存存储所有产物，包括工作单元输出与控制器笔记，形成产物图记录成果依赖关系，支持复用前期成果。

在 IMO 定理证明、ARC-AGI-2、LongCoT-mini、ProgramBench 四大基准，基于 Gemini、GPT、Opus 三类大模型开展对照实验。同等模型调用预算下，相比直接控制智能体，平均提升 3.6~4.2 个百分点；预算越高优势越明显，而预算很低时，控制器额外开销会拖累性能。

通过产物图可拆解性能：生成正确候选的覆盖度、识别筛选答案的选择能力两大指标。实验发现控制器评估区分正误的能力常优于工作单元自置信度。局限性在于控制器判断出错会带来风险，收益强弱依赖底层模型，且本实验未做完整组件消融。该研究证明：管控算力分配的元能力，是独立于任务求解能力之外的核心智能体能力。

10 个关键问题 Q&A

1. Q：什么是智能体元推理？
   A：把智能体 “下一步算力如何分配” 的控制逻辑独立出来，形成一套显式结构化推理流程，管控自身计算过程。
2. Q：传统智能体的核心缺陷是什么？
   A：流程控制和任务执行混在一起，中间成果难复用；算力增加后性能容易平台饱和，长任务上下文噪声大。
3. Q：控制器的 4 个阶段是什么？
   A：评估、提议、方案评估、分发，循环执行，负责决策，不直接完成任务本体求解。
4. Q：什么是产物（artifact）与产物图？
   A：产物是系统保存的所有输出；产物图记录不同产物之间的依赖关系，用于分析智能体求解轨迹。
5. Q：工作单元（Worker）的作用？
   A：负责实际任务求解，如证明、写代码；看不到控制器内部推演，仅接收指令和选定上下文。
6. Q：为什么要做精简状态？
   A：避免上下文随任务无限膨胀，控制器只保留摘要，需要时再读取持久内存中的历史产物。
7. Q：元推理一定比直接控制智能体更强吗？
   A：不一定。预算充足时优势明显；预算很小，控制器带来额外模型调用开销，性能反而更低。
8. Q：作者把智能体成功拆成哪两个独立环节？
   A：①生成正确答案（覆盖度）；②识别并选出正确答案提交（选择能力）。
9. Q：核心实验结论是什么？
   A：固定底层模型和算力预算，元推理智能体性能更高；预算增加时，直接控制智能体容易瓶颈，元推理可持续提升。
10. Q：本研究最大理论启示？
    A：智能体性能不只取决于底层模型解题能力；算力调度、流程管控的元能力，本身是独立的智能能力。

附录 先于思考：通过元推理扩展智能体推理能力

作者：帕拉斯・达哈尔、安东・巴赫金、塔科・科恩、陈正行、吴卡罗尔‑让、罗布・弗格斯、斯科特・伊、加布里埃尔・辛纳维、鲁斯兰・萨拉赫丁诺夫、桑吉夫・阿罗拉、贾森・韦斯顿、阿尼鲁德・戈亚尔 机构：Meta 超级智能实验室

随着智能体处理更长、更复杂的问题，对执行过程本身进行管控，也成为一项独立任务。每一步运行都会产生新的控制决策：例如，要基于哪一部分中间成果继续推进，是否需要从头开始，以及何时终止任务。本文提出智能体元推理（agentic meta‑reasoning），这是一套推理时调度框架，把上述决策转化为一套显式、结构化的推理流程。 工作单元（Worker）负责完成任务层面的计算；控制器（Controller）则汇总当前运行已得到的结论，探索后续可行方案，结合剩余算力预算评估每个方案的价值，并结合持久化内存中的上下文，分配待执行任务。在两次决策之间，控制器仅保留一份精简的运行摘要，而非完整回放全部历史记录。

本文的基准对比对象包含生产级代码智能体、研究调度框架，以及一套使用完全相同工作单元与算力预算的直接控制智能体（Direct Control Agent）。 在用于测试长周期智能体能力的程序重构基准集 ProgramBench 上：搭载 GPT‑5.5 的元推理框架得分达到 71.5%，而 Codex 为 58.0%；搭载 Opus 4.8 时得分 67.2%，对比 Claude Code 的 65.5%。 在其余涵盖抽象推理、多领域长周期推理、定理证明的基准测试中，在三款前沿大模型上取平均，元推理相比直接控制智能体可以带来 3.6‑4.2 个百分点的性能提升。 在直接控制智能体性能进入平台期的预算区间内，元推理仍可以持续提升效果；但在预算较小时，元推理带来的额外开销会拖累性能。

对产物图（artifact‑graph）的分析表明：该框架会更多复用前期产出，在大多数测试场景下正确解的覆盖度更高，最终答案选择环节获得非均匀的性能增益。实验结果表明：当智能体任务运行周期不断变长，投入算力用于结构化的流程管控，会变得愈发重要。

论文日期：2026‑09‑30 联系邮箱：padahal@meta.com，agi@meta.com

智能体元推理：对智能体自身计算过程的显式管控

现有智能体设计会把两类认知功能 ——流程控制与任务本体层工作交织在一起。这就导致有用的中间成果难以复用组合；随着可用算力增加，性能也难以同步扩展。 而智能体元推理将控制逻辑独立出来，基于精简状态、持久化内存和工作单元，形成一套独立的结构化推理流程。

1 引言

大模型智能体解决单个问题时会调用大量模型接口，其中相当一部分调用，是用来决策下一步该做什么。 举个例子：一个数学证明智能体拿到一套候选证明，主论证逻辑看起来合理，但其中一条核心引理尚未得到验证。此时它可以选择：尝试证明这条引理；调度第二个工作单元去校验现有论证；或是直接放弃这条思路，换用别的方案。每一种选择都会消耗算力，如果选错，算力就被白白浪费。

对于自主朝着目标求解的智能体而言，这种决策本身就是问题求解的一部分，是独立于生成证明下一步内容的另一项能力。 这属于元认知管控（metacognitive control）：评估自身求解进度，并基于评估结果决定后续行动（De Sabbata 等人，2024；Liu 等人，2026）。 对于单次模型调用，管控对象是思维链；对于智能体系统，管控对象是运行过程中已经产出的全部成果。智能体需要判断哪些结果可以信任、哪些可以继续迭代、何时应当停止（Li 等人，2025；Xiang 等人，2026）。 一旦判断出错，代价不只是消耗算力：它可能让一条已经走不通的思路持续占用算力，也可能直接抛弃智能体已经找到的正确答案（Brown 等人，2024）。

现有智能体通常会把这些控制决策和任务本体层的工作交错执行：每一次控制决策，都基于不断累积的完整历史，在单次轮次内完成（Yao 等人，2023b；Shinn 等人，2023；Shen 等人，2023；Packer 等人，2023；Zhang 等人，2025a）。 本文提出：这些决策本身，理应拥有一套独立的智能推理流程。智能体在敲定下一步行动前，可以先调研、推演：读取历史结果，或者让工作单元完成校验。这套推演具备自身结构：汇总当前已确立的结论，探索可行的后续路径，评估每一条路径的价值。

我们将这套范式命名为智能体元推理：智能体针对自身的推理过程进行思考、并对其施加操作。我们将它实现为一套全新的推理时调度框架，负责协调模型调用、管理整个求解运行。 我们的元推理智能体将角色拆分：工作单元负责任务本体层的实际求解；控制器负责决定分配哪些任务。控制器维护一份精简的进度评估摘要，全部完整的工作单元输出保存在持久化内存，需要时再读取。

每一轮控制循环分为四个阶段：控制器根据系统变化更新状态；提出下一步可执行的计算方案；结合剩余预算评估各个方案的价值；分配选定的任务，同时向工作单元提供需要用到的历史输出。每个阶段本身都是一套完整智能体流程，拥有独立提示词与工具。控制器的模型调用同样计入总预算，因此额外的推演开销，必须通过性能收益来证明其合理性。

系统会把全部产出记录为一张产物图（artifact graph）：每一份存储的输出都叫一个产物；边代表一份产物被作为上下文，用来生成另一份产物。这张图可以记录求解过程如何分支、后续步骤如何复用前期成果。这样，我们不再只能依靠最终得分，还可以通过求解产生的全部产物来分析诊断智能体行为。

本文在 IMO 高级证明基准集、ARC‑AGI‑2、LongCoT‑mini、ProgramBench 共四套基准开展评测，覆盖定理证明搜索、抽象推理、长周期推理、程序重构任务；底层模型使用 Gemini 3.1 Pro、GPT‑5.5、Opus 4.8。 一个工作单元可以是单次模型调用，也可以是具备工具调用能力的代码智能体。对比基线包含生产级代码智能体、研究调度框架；同时设置匹配对照的直接控制智能体：它使用完全一样的工作单元和工具接口，只是所有动作选择都在单次调用中、基于全部累积历史完成。

在主要实验设置下：推理类基准每道问题允许 100 次模型调用，ProgramBench 允许 1200 次调用。全部 12 组对照实验中，元推理均取得更高分数，各基准平均提升 3.6‑4.2 个百分点。 ProgramBench 上 GPT‑5.5 的单问题测试通过率达到 71.5%，对比 Codex 的 58.0%，以及直接控制框架的 63.7%。 当预算增加时，直接控制智能体性能进入平台期，元推理却可以持续提升。产物图分析显示：元推理会更多复用前期工作，更多运行实例中会出现正确候选解。 以上结果说明：把流程控制和任务本体层工作显式分离的智能体元推理框架，能够让智能体在任务更长、更复杂时获得更好的扩展性。

2 相关工作

推理时算力分配与智能体调度框架

推理时相关方法的算力分配模式包括：沿着单条推理路径计算；生成多个独立样本后筛选；反复批判迭代；或是按照预定义搜索结构展开计算（Wei 等人，2022；Wang 等人，2022；Madaan 等人，2023；Yao 等人，2023a；Besta 等人，2024）。 这些工作证明推理时计算是重要的扩展手段，但它们会在问题求解开始前就固定计算结构：样本数量、分支数、迭代轮次、校验调用、聚合步骤全部预先设定，不会根据问题实际需要动态调整。

而智能体调度框架让模型自主判断下一步计算方向：推理与环境动作交替执行、利用历史尝试的反馈、把子任务委托给专用模型、或者先把任务拆解成计划再执行（Yao 等人，2023b；Shinn 等人，2023；Shen 等人，2023；Prasad 等人，2024；Kim 等人，2024）。现代代码智能体将这套思路延伸到长期软件任务，支持文件查看、编辑、命令执行（Anthropic，2026；OpenAI，2025）。 但随着任务产生大量中间产物，智能体的上下文会充斥噪声（Bertsch 等人，2025），进而影响控制决策。这促使我们将智能推理视为在线产物图构建：控制器读取产物图来指导后续工作，工作单元则不断扩展这张图。

可学习、可优化的编排调度

另一类研究方向是学习、搜索、优化整套协调模型调用的系统。 GPTSwarm 学习多智能体之间的通信结构（Zhuge 等人，2024）；AgentOrchestra 等研究多智能体协同（Zhang 等人，2025c）；Meta‑Harness、Fugu 针对任务性能优化、训练调度器模型（Lee 等人，2026；Sakana AI Fugu 团队，2026）；Conductor、Trinity 同样将编排调度作为系统设计的核心对象（Nielsen 等人，2026；Xu 等人，2026）。 更近的工作直接实现调度框架的自动构建：基于执行反馈、失败轨迹，对调度框架做合成、演化、编辑（Lou 等人，2026；Lin 等人，2026；Shao 等人，2026）；Ren 等人（2026）对该领域做综述。这套自动调度框架对比简单推理时扩展方案的效果，仍处在研究阶段（Wang 等人，2026）。 和上述工作不同：本文不训练全新调度器，也不搜索任务专用调度框架；而是把控制机制独立出来，将它本身构造成一套智能推理流程。

推理的元认知管控

元认知领域为这类管控问题提供概念体系：智能系统必须监控自身计算状态，并基于监控结果调整后续行为（Liu 等人，2026）。 不少研究把这套思想落地到大模型：把推理建模成受预算约束的计算价值问题；将 “自知感”“学习判断” 这类自我监控信号转化为信任判断、重试决策；把本体层推理与元层级管控分离开；在生成‑校验流水线增加显式监控步骤；依靠元认知信号决定何时调用工具、何时停止推理（De Sabbata 等人，2024；Zhao 等人，2026a；Cao 等人，2026；Dong 等人，2025；Oh 和 Gobet，2025；Li 等人，2025；Xiang 等人，2026）。

本文的管控对象和上述工作有区别：我们管控的不是单条思维链、工具触发规则或者停止条件，而是一套基于持久化产物、不断增长的外部计算图。

作为控制载体的内存与上下文

长周期智能体需要保存、筛选信息。MemGPT 将内存管理作为大模型系统的核心组成（Packer 等人，2023）；A‑MEM、Mem0、ACE 为智能体实现自适应持久化内存接口（Xu 等人，2025；Chhikara 等人，2025；Zhang 等人，2026）；CoALA 把智能体抽象为包含结构化内存、动作、决策的系统（Sumers 等人，2024）。 递归语言模型 RLM 不使用会话记录保存上下文，而是让模型通过代码修改变量（Zhang 等人，2025a）；PRO‑LONG 保存完整交互日志，通过程序检索日志（Fox 等人，2026）。

在本文框架中，内存本身成为推理管控的操作载体：控制器可以写产物、读取选定的历史成果，决定每个工作单元能看到哪些上下文，以此决定后续计算可以复用哪些前期产出。

智能体运行过程的诊断评估

越来越多的研究不再只看最终准确率，而是探究性能的来源。 Large Language Monkeys 区分 “生成正确候选” 和 “选出正确候选” 两个环节（Brown 等人，2024）；部分工作研究候选集结构、搜索轨迹特征（Saad‑Falcon 等人，2025；Dragoi 等人，2026）；AgentEval、MAST、Who & When 提供评估框架，对智能体失败做分类（Guo 等人，2026；Cemri 等人，2025；Zhang 等人，2025b）；还有工作把智能体失败定位到组件、交互、轨迹特定位置（Raj 等人，2026；Shah 等人，2026；Zhao 等人，2026b）。

本文继承这套诊断思路，并直接和运行过程生成的产物图绑定。依靠产物图，我们可以统一衡量算力消耗、拓扑结构、正确解覆盖、监控能力、答案选择效果。

3 智能体元推理

智能体元推理把 “下一步计算什么” 本身视作一项独立智能推理任务，和它所管控的本体层计算相互分离。 这将智能体的两类认知功能解耦，同时允许成果不断累积，而不必让每一次控制决策都要基于全部历史会话。

3.1 记忆、状态与工作单元上下文

产物（artifact）：工作单元或控制器输出并保存的内容。一次尝试、一份批判、控制器写下的笔记，都可以是产物。每一个产物都分配稳定唯一标识，可以随时读取。 针对任务x，记\(M_t\)为第t轮控制周期可用的全部产物集合。

每一轮周期t，控制器更新一份自己编写的文本状态\(s_t\)：它是对当前已完成工作、待完成工作的精简摘要，大多是非结构化文本。每一轮都会重写这份状态；状态引用的全部产物依旧保留在内存中。

以证明题为例：内存里保存多份构成完整论证的产物；控制器的状态记录 “某一条引理尚未验证”，随后控制器可以启动若干并行工作单元，专门处理这个子任务。

工作单元接收：原始任务x、控制器下发指令g，以及控制器挑选的产物子集\(C \subseteq M_t\)作为上下文。 记w为一次工作单元执行，y为它返回的产物，则写作：

\(y=W(x, g, C)\)

以校验证明为例：指令写明需要校验的内容，上下文传入已有的论证材料。工作单元看不到控制器内部状态与推演过程，只能拿到分配的指令与选定产物。

工作单元可以是单次模型调用，也可以是拥有工具能力的代码智能体。上面只是接口定义，并非纯函数：代码类工作单元可以读取产物集合C之外的文件、修改环境，输出具备随机性。因此输入并不完全决定输出与环境效果。环境状态、随机因素不在公式中显式写出；只记录控制器选定的产物上下文。

3.2 求解运行中的各类动作

控制器可以执行的动作：读取已保存成果、记录自身笔记、启动工作单元、输出答案终止运行。这些动作既改变待完成的工作，也改变后续决策可以获取的信息。

1. 读取与写入内存
   给定一组产物标识集合I，内存函数\(\text{Read}(I)\)读取对应的产物。对于新内容u，\(\text{Write}(u)\)将它作为新产物存入内存，并分配全新 ID。 例如：写下笔记，记录 “之前某份证明用到了无效假设”。这类读写属于认知动作（epistemic action）（Kirsh 与 Maglio，1994）：控制器给自己留下备忘，在正式执行任务前整理掌握的信息。
2. 运行工作单元
   为推进本体层任务，控制器可以批量启动k个并行工作单元。对每个工作单元i，下发指令\(g_i\)和产物上下文\(C_i\)。批量启动接口对同一个任务x执行k次工作单元调用：

\(\text{RunWorkers}\left(\left\{\left(g_{i}, C_{i}\right)\right\}_{i=1}^{k}\right)=\left\{W\left(x, g_{i}, C_{i}\right)\right\}_{i=1}^{k}.\)

工作单元返回的产物分配新 ID 加入内存，同时记录它们依赖的输入产物 ID。这套接口既支持全新从头尝试，也支持定向修复，或是融合多个前期结果。任务分配与传入上下文决定工作内容，工作单元没有固定角色。

3. 终止并选择答案
   控制器调用\(\text{Stop}(y^{*})\)结束运行，其中\(y^{*}\)必须是内存中已经存在的产物，作为最终提交答案。它不一定是最新生成的输出。如果想要提交全新内容，必须先由工作单元生成该产物。

3.3 控制循环

每一轮控制循环分为顺序执行的四个阶段：评估（Assess）、提议（Propose）、评估方案（Evaluate）、分发任务（Dispatch）。 每个阶段都是独立智能体流程，有自己的提示词、上下文，允许调用内存读写工具。单个阶段内部还可以包含调研、推演，可能需要多次模型调用。两轮循环之间只持久化精简状态；各阶段需要时可以读取历史产物。一轮循环内部，内存、预算都可以随着读写、模型调用发生变化。

1. 评估（Assess）：我们得到了哪些结论？
   当工作单元返回结果后，控制器更新对整个运行的摘要记录。 以证明任务举例：该阶段记录 “主论证思路前景较好，但某条引理还没有验证”；完整证明材料仍然保存在内存，状态摘要只保留对后续决策重要的信息。

记\(s_{t‑1}\)为上一轮评估状态，\(\Delta M_t\)是上一批工作单元新产出的产物集合。\(\text{Assess}\)输出更新后的状态\(s_t\)：

\(s_{t}=Assess\left(x, s_{t-1}, \Delta M_{t} ; M_{t}\right).\) 分号代表可以访问完整持久化内存，但不会把全部内存内容塞进提示词上下文。

2. 提议（Propose）：接下来可以做什么？
   基于当前评估结果，列举候选的后续计算方案，在真正执行前把多条备选路径显式列出来。 该阶段不会显式接收剩余预算信息。这样做是为了把 “生成备选方案” 和 “判断方案成本是否划算” 解耦：高价值但开销大的方案也可以进入候选集合。 记\(\mathcal{A}_t\)为生成的候选动作集合，\(s_t\)是当前评估状态：

\(\mathcal{A}_{t}=Propose\left(x, s_{t} ; M_{t}\right).\)

3. 方案评估（Evaluate）：该方案是否值得消耗算力？
   结合剩余预算权衡上一阶段生成的候选方案。 举例：如果证明的关键在于一条不确定的引理，那么校验这条引理，比重新完整尝试一遍证明更有价值；如果校验失败，下一轮循环就可以切换其他思路。 这是基于提示词的定性计算价值评估，不是精确优化，也不是学习得到的计算价值估计器。 记\(b_t^{eval}\)为评估阶段开始时的剩余预算。选出候选方案\(\tilde{a}_{t} \in \mathcal{A}_{t}\)：

\(\tilde{a}_{t}= Evaluate \left(x, s_{t}, b_{t}^{eval }, \mathcal{A}_{t} ; M_{t}\right).\)

4. 任务分发（Dispatch）：工作单元应当拿到哪些信息？
   把选定的候选方案转化为可执行动作。 举例：针对引理校验任务，该阶段撰写校验指令，并从产物内存传入证明原文、相关批判材料。全新的尝试则可以不传入任何历史产物。选择哪些产物给到工作单元，本身就是计算规划的一部分。记\(\tilde{a}_t\)是上一步选出的方案，\(\text{Dispatch}\)输出最终的工作单元分发动作或是终止动作\(a_t\)：

\(a_{t}=Dispatch\left(x, s_{t}, \tilde{a}_{t} ; M_{t}\right).\)

如果决策为终止，\(\text{Dispatch}\)调用\(\text{Stop}(y^{*})\)；否则分发工作单元任务，工作单元的输出将在下一轮循环可用。

3.4 构建产物图

在分发阶段，控制器挑选历史产物作为工作单元的上下文，这就记录下后续工作对前期产出的依赖关系。 如果一个工作单元输入一份证明，输出一份批判，图上就会有一条从证明指向批判的边；一份修复工作同时输入两者，则会有两条入边。

形式化定义产物图\(G=(V, E)\)，V是全部产物节点，E是依赖边集合。对于产物\(y_j\)，\(C_j\)代表生成它时传入的上下文产物集合，则：

\(E=\{ (y_{i},y_{j})\in V× V:y_{i}\in C_{j}\}.\)

因为输入产物一定早于工作单元运行，所有边构成有向无环图。根节点代表不依赖任何产物的初始工作；分支代表一条成果衍生多条后续路径；多条入边代表一份工作融合多个来源的前期成果。

注意：这张图只记录控制器指定的依赖，不会捕获全部信息传递通道。对于可以打分评判正确性的产物，我们会关注两件事：运行过程中是否曾经出现过正确解；这个正确解有没有被最终提交。

3.5 直接控制智能体，以及推演带来的开销

我们把上面整套设计实现称为元推理智能体。同时构造对照版本：直接控制智能体。它不做控制逻辑的显式分离，但复用完全一致的工作单元、委托接口、上下文选择、产物写入、终止逻辑。它每一轮只做单次模型调用，输入全部累积历史，选择下一步动作。 两组对比可以隔离这套完整控制方案带来的效果，但无法单独拆解出分阶段执行、状态压缩、内存访问各自的独立影响。

两套系统拥有相同名义模型调用预算B。记\(b_t\)为第t轮循环开始时剩余预算；一轮循环消耗\(c_t\)次控制器调用、\(w_t\)次工作单元调用，则下一轮初始剩余预算：

\(b_{t+1}=b_{t}-c_{t}-w_{t},\quad b_{0}=B.\)

工作单元开销包含代码智能体内部所有调用，并行工作单元调用全部累加；控制器开销包含四个阶段内每一次模型调用。 如果预算耗尽前智能体没有主动停止，系统强制提交一份现有答案。

注意：名义调用次数相等不等于 token 消耗、延迟、算力 FLOPs 相等。每次调用长度各不相同，智能体也可能提前终止，不会耗尽全部预算。调用次数多本身不代表效果更好；额外推演，只有当它最终帮助智能体产出更优解时才有价值。

4 基于产物图对智能体推理过程做诊断

有些运行：所有工作单元产出都不是正确证明；另一些运行：内存里已经存在正确证明，但控制器最终提交了一份有缺陷的修改版本。只看最终得分无法区分这两种情况。 当中间产物本身可以评判对错时（而不是只能评判最终提交结果），我们就可以借助中间产物分析运行全过程：算力如何被消耗、计算形成什么样的结构、正确解是否曾经出现、智能体是否识别到已存在的正确解。

4.1 智能体如何消耗预算？

1. 预算利用率
   智能体可以提前停止，不会一定把预算全部用光。更大预算不等于更长的运行过程。 B为名义总调用预算，\(N_{ctrl}\)统计控制器调用总次数，\(N_{work}\)统计工作单元调用总次数。利用率定义：

\(U=\frac{N_{ctrl }+N_{work }}{B}.\)

结合利用率与性能一起分析：提前终止不一定是坏事，把预算全部耗完也可能属于浪费。结合两者，可以看出更大预算是否转化为更多工作、更优结果。

2. 后续工作是否复用前期产出？
   智能体可以把算力全部用在互不依赖的独立尝试，也可以基于前期成果迭代、校验、修复。产物图可以区分这两种模式。 节点代表工作单元输出；边代表依赖上下文。统计指标：

• 根节点：没有入边的节点；后代节点：至少有一条入边。
• 入度（Fan‑in）：一个节点的入边数量，统计均值、最大值。
• 深度（Depth）：最长依赖路径，根节点深度为 0。
• 宽度（Width）：同一深度下最多的节点数量。

3. 控制器复用了哪些信息？
   统计内存读写行为：哪些工作单元输出、控制器笔记被存储、被重新读取；哪些阶段执行读写。同时对比两套框架运行时状态的大小：元推理是评估阶段维护的精简状态；直接控制是不断累积的完整上下文。

4.2 智能体是否找到、并提交正确答案？

一次运行可以成功生成正确答案，却没能识别、提交它。借助中间解的正确性标签，我们可以把结果拆成两个独立事件。

记\(V_{sol}\)为可以作为候选解打分的产物集合。对候选y，\(\ell(y)=1\)代表正确，\(\ell(y)=0\)代表错误。最终提交答案\(y^{*}\)也属于待评估集合。 记事件\(\mathcal{C}\)：运行过程中内存出现过正确解；事件\(\mathcal{S}\)：提交的答案正确。显然：提交正确，必须先出现过正确解，也就是\(\mathcal{S} \subseteq \mathcal{C}\)。

\(Pr(\mathcal{S})=Pr(\mathcal{C}) Pr(\mathcal{S} | \mathcal{C})\)

因此最终成功概率可以拆解为两部分：

1. 覆盖度 Coverage
   是否生成过正确候选解（不管最终有没有提交）。代表 “如果有完美筛选器，这套运行本可以拿到的成功率”。覆盖度低代表很多次运行根本没有产出正确候选。

\(Coverage(k)=Pr\left( \exists y\in V_{sol,\leq k}: \ell (y)=1\right).\) \(V_{sol, \le k}\)代表前k次调用内生成的候选产物集合。

2. 监控能力 Monitoring
   智能体能否识别高质量成果。 工作单元输出结尾附带自身置信度打分；控制器评估阶段也会记录它对每一份候选的判断。我们希望这套打分可以把正确候选排在错误候选前面。 随机抽取一份正确候选\(Y^+\)、一份错误候选\(Y^‑\)。定义二类 AUC 指标 Type‑2 AUC：

\(AUC_{2}(r)=Pr\left(r\left(Y^{+}\right)>r\left(Y^{-}\right)\right)+\frac{1}{2} Pr\left(r\left(Y^{+}\right)=r\left(Y^{-}\right)\right).\)

这只衡量区分能力，不衡量置信度校准。直接控制智能体没有控制器层面的评判信号，无法做该指标对比。

3. 选择能力 Selection
   当内存已经存在正确解时，能否选中它提交。只在\(\mathcal{C}\)成立的样本上统计：

\(Selection =Pr(S | \mathcal{C}).\)

• 受覆盖度限制的失败
  全程没有产出任何正确候选。
• 受选择能力限制的失败
  产出过正确解，但没有选中提交。

4.3 选择能力对比结构基线

运行结束后，产物图里会存在若干终止节点（没有出边）。我们定义收敛前沿（convergence frontier）：所有终止节点中，依赖路径深度最大的节点集合\(F(G)\)。

\(F(G)=\left\{y \in L(G): d(y)=max _{z \in L(G)} d(z)\right\}.\) \(L(G)\)代表全部终止节点；\(d(y)\)是从根节点到y最长路径的边数。

在前沿集合内随机均匀挑选一个节点作为答案，它正确的概率\(q_F(G)\)，等于前沿中正确产物占比：

\(q_{F}(G)=\frac{1}{|F(G)|} \sum_{y \in F(G)} \ell(y).\)

把智能体实际提交答案的正确性\(\ell(y^*)\)和这个随机基线做对比，只针对 “运行已经出现过正确解” 的样本，求期望，得到前沿选择增益 FSG：

\(FSG=\mathbb{E}\left[\ell\left(y^{*}\right)-q_{F}(G) | \mathcal{C}\right].\)

FSG>0 代表智能体选择效果优于在收敛前沿上随机抽取。提交的答案不一定属于前沿，增益也可以来自于主动选择深度更小、但质量更高的历史产物。

这套诊断把单一最终得分，拆解成对运行全过程的刻画：有没有产出正确成果；成果有没有被选为最终答案。 两类失败对应不同改进方向：覆盖度不足，需要改进探索、本体层求解；选择能力不足，则要优化评估、校验、最终决策逻辑。

5 实验设置

实验目标：

1. 验证智能体元推理是否提升最终性能；
2. 收益是否随可用预算增加而变大；
3. 元推理会如何改变求解过程的计算行为。

两套实验场景：

• 推理类基准（IMO‑ProofBench‑Advanced、ARC‑AGI‑2、LongCoT‑mini）：每个工作单元就是一次模型调用，不调用外部工具；
• ProgramBench：每个工作单元是具备文件查看、命令执行、测试重构能力的代码智能体。

5.1 任务数据集

1. IMO 高级证明基准集
   30 道高难度证明题。按照论文协议打分，单题得分取值 {0, 1, 6, 7}，报告总分占理论最高分的百分比。
2. ARC‑AGI‑2
   120 道抽象网格视觉推理任务：给出若干输入‑输出网格样例，推理隐藏变换规则，应用在测试样例上；以输出网格完全匹配作为准确率。
3. LongCoT‑mini
   LongCoT 的 mini 子集，507 道长周期推理题，覆盖逻辑、计算机、化学、国际象棋、数学。每道题答案可验证，由领域确定的校验器判定对错。难点在于长流程中维持状态、不丢失约束条件。
4. ProgramBench
   200 道长周期程序重构任务。给定文档与仅可执行的参考二进制程序，智能体需要从零构建独立代码库；编译后可执行文件在隐藏测试用例上行为要和参考程序完全一致。指标是隐藏测试用例的平均通过率。

5.2 对比实验组

1. 元推理智能体 vs 直接控制智能体
   两者使用完全一致的工作单元，委托、产物读写、上下文选择、终止接口全部相同。区别仅在于：元推理使用精简状态与四阶段管控；直接控制在单次调用中输入全部累积历史来选择动作。两套控制器都没有针对基准做微调。
2. 递归语言模型 RLM
   推理基准上做对比。它把任务状态保存在 Python 解释器变量中，模型写代码调用子模型处理子任务、读取输出继续执行，支持递归调用。它没有本文的工作单元分发工具与产物内存；上下文是一整块由代码修改的文本。为保证对比公平，我们对原版设计做两处修改，详见附录 H。
3. 代码智能体基线（ProgramBench）
   mini‑SWE‑Agent、Claude Code、Codex。mini‑SWE‑Agent 跑全部三个底层模型；Codex、Claude Code 使用各自原生底层模型，运行在和我们实验完全一致的容器环境，详见附录 I。

5.3 使用模型与算力预算

底层模型统一为：Gemini 3.1 Pro、GPT‑5.5、Opus 4.8。

• 推理类基准：单题名义预算 25、50、100 次模型调用；主实验使用 100 次。
• ProgramBench：单题名义预算 400、800、1200 次调用；主实验使用 1200 次。

控制器调用、工作单元调用全部计入同一套预算；并行工作单元调用次数累加，不按批次计一次。所有系统都可以提前停止运行，实际消耗调用可以低于名义上限。 外部基线本身没有 “模型调用预算” 概念，我们给它们增加同样的预算记账逻辑。预算耗尽还没有主动停止，则强制提交一份可用解。

5.4 评测指标

1. 最终性能：各基准原生评价指标；预算扫描实验观察性能随预算变化曲线。
2. 过程诊断指标：实际消耗模型调用数、产物图拓扑、内存操作、控制器上下文大小。
3. 推理基准会对中间产物做正确性标注，因此可以计算覆盖度、监控指标、选择能力、前沿选择增益；ProgramBench 中间重构版本没有标准化打分协议，不做这套分析。

6 实验结果

6.1 元推理在多任务、多模型下均提升性能

在主预算设置下，元推理智能体在每一组模型‑基准配对上得分最高。

• IMO 高级证明集：三款模型平均提升 4.0 个百分点；Gemini 3.1 Pro 提升最大，达 8.6 个点。
• ARC‑AGI‑2 平均提升 4.2 个点，结果最稳定；单模型提升区间 2.5‑6.7。
• LongCoT‑mini 平均提升 3.6 个点；不同模型差异大：GPT‑5.5 仅提升 0.4；Gemini 3.1 Pro 最高提升 9.2。

元推理同样优于对比的外部系统。 ProgramBench 上：搭载 GPT‑5.5 元推理达到 71.5%，对比 Codex 的 58.0%；搭载 Opus 4.8 元推理 67.2%，对比 Claude Code 的 65.5%；同时在全部三款模型上都优于 mini‑SWE‑Agent，提升幅度 2.5‑13.9 个百分点。

结论：在主预算条件下，全部 12 组匹配对照实验元推理得分更高；同时优于参与评测的外部智能体配置。

6.2 预算增大时，元推理性能持续提升，直接控制进入平台期

更大预算只有在智能体能找到有效方式消耗算力时，才能带来收益。 元推理智能体会随着预算增加消耗更多调用；直接控制智能体经常提前终止。 ProgramBench，GPT‑5.5 条件：直接控制只消耗 1200 预算中约 18% 调用；元推理实际消耗占比 89%‑101%（控制周期边界，分发出去的工作单元执行完毕，会轻微超出名义上限）。

运行更长，也带来更好答案。ProgramBench，GPT‑5.5，预算 400→1200，元推理从 64.1% 提升至 71.5%；而直接控制始终徘徊在 64% 附近。 推理基准聚合曲线也体现同样现象：在测试预算范围内，元推理持续涨分，直接控制趋于饱和。

提前停止不是全部原因。ProgramBench，Opus 4.8：直接控制调用数随预算几乎翻倍（376→768），但得分仅小幅上涨：62.7%→65.3%，在中间预算就达到峰值。说明仅仅增加运行步数不够，“下一步做什么” 的决策质量至关重要。

元推理并非在所有预算下占优。ProgramBench 小预算 400 次调用：Opus 4.8 元推理 56.6%，低于直接控制 62.7%；预算到 1200 次才反超 67.2% 对比 65.3%。GPT‑5.5 在 ProgramBench 最低预算同样略微落后，预算增大后反超。 这符合理论：分阶段控制带来额外开销，小预算场景下开销无法被收益覆盖。

结论：在测试预算区间，直接控制经常性能平台化，元推理可以持续获得性能提升；但预算很小时，显式控制阶段的开销会超过收益。

6.3 额外预算产生了哪些计算行为？

主预算条件下，在三套推理基准上，元推理生成比直接控制更多的工作单元产物，产物之间的复用关系增长幅度更大。 例如 IMO 高级证明集，Gemini 3.1 Pro：工作单元产物数量近乎翻倍，记录的依赖边数量提升一个数量级。两套框架使用同样接口选择传给工作单元的上下文，也就是说直接控制智能体理论上也可以构建同样复杂的图，但实验中它几乎没有做到。

产物图规模随预算增长。ProgramBench，GPT‑5.5，预算 400→1200：产物节点数量提升 2.5 倍以上，依赖边接近 4 倍；直接控制的产物图没有同等规模增长。最大预算条件下，无论哪个底层模型，元推理生成的节点、边数量都高于直接控制。

结论：随着预算增加，元推理产出更多工作单元结果，并且更多后续工作建立在前期成果之上。

6.4 找到正确答案只是问题的一部分

1. 正确候选解的覆盖度提升
   大部分设置下元推理提升覆盖度。Gemini 3.1 Pro 收益最大：IMO 高级证明集提升 20 个百分点，LongCoT‑mini 提升 10 个百分点；ARC‑AGI‑2 全部模型均提升；LongCoT‑mini 上 Opus 4.8 两组接近持平。覆盖度提升代表：更多次运行实例，内存中曾经出现过正确候选，无论有没有被提交。
2. 控制器评判能力往往优于工作单元自身置信度
   工作单元输出自带的置信度，区分正确 / 错误解的能力往往很弱。IMO 高级证明集 Gemini 3.1 Pro，工作单元置信度 Type‑2 AUC 仅 0.55，接近随机；而控制器评判可以达到 0.88。ARC‑AGI‑2，Gemini 3.1 Pro 也存在巨大差距。GPT‑5.5、Opus 4.8 差距更小；LongCoT‑mini 上 GPT‑5.5 两者几乎没有差距。 说明在不少场景，控制器显式评估阶段，可以输出比工作单元自我评估更强的质量排序信号。但这套信号能否转化为最终提交的正确答案，是另一个问题。
3. 最终选择能力提升效果随模型、任务不同，并不统一
   ：两套智能体绝大多数情况会从深度最大的终止节点（收敛前沿）中选出提交答案（ARC‑AGI‑2、LongCoT‑mini 统计中占 83% 运行）。但大部分运行的收敛前沿存在多个候选，智能体仍然需要从中挑选提交。

前沿选择增益对比：ARC‑AGI‑2，GPT‑5.5，元推理 FSG+11 个百分点，直接控制仅 + 3；Opus 4.8 在 ARC‑AGI‑2、GPT‑5.5 在 LongCoT‑mini，元推理 FSG 同样更高。LongCoT‑mini，Opus 4.8 两组接近；Gemini 3.1 Pro 则直接控制略微占优。

结论：对智能体而言，“生成正确答案” 和 “识别并提交正确答案” 是两个独立挑战。元推理在大部分评测设置提升覆盖度，但前沿选择能力带来的增益在不同模型上表现不一致。

6.5 控制器如何保留有用历史，而不用完整回放全部内容？

产物内存同时存放工作单元输出和控制器自己写的笔记。 观察发现：元推理控制器重读自己写下的笔记的频率，远高于重读工作单元输出。ARC‑AGI‑2 与 LongCoT‑mini 上，被至少读取一次的产物中：控制器笔记平均被读取 4.4‑9.8 次；工作单元产物仅 1.9‑3.3 次。大量产物再也不会被读取；但控制器会反复回看一小部分自己写的笔记，作为组织整个求解过程的参考材料。

内存读写操作集中发生在评估、提议两个阶段。所有模型，写操作数量大于读操作。评估阶段主要做写入，几乎不做读取：新的工作单元产物直接输入该阶段提示词；显式读内存操作，用于调取更早的历史。几乎全部读操作来自提议、方案评估阶段，读取历史产出。不同模型内存使用模式不同：Gemini 3.1 Pro 内存操作偏少；GPT‑5.5 读写更多；Opus 4.8 会写大量笔记，但很多笔记之后再也不会访问。

持久化产物存储的一大优势：控制器可以维护一份精简的运行摘要，而不是完整交互历史。 直接控制智能体，在 IMO 高级证明集 Opus 4.8 长运行中，累积历史上下文字符数超过百万；元推理控制器状态维持在几千到几万字符量级。推理基准上，元推理状态甚至会随着运行推进而变小。ProgramBench 两者差距缩小到几倍，元推理状态会持续增长，因为控制器需要记录大量代码仓库相关信息。

直接控制智能体上下文膨胀到已知会让大模型难以定位相关信息的规模。这可能是直接控制预算增加却不再涨分的部分原因，本实验没有做单独消融实验验证该猜想。以上统计仅统计控制器侧状态大小，实际决策看到的总上下文，还要叠加读取的产物、阶段内部交互内容。

结论：元推理控制器把自身运行状态的大小，和求解运行的总长度解耦；同时会反复回看自己写下的笔记，作为组织求解的参考。

7 讨论与局限性

7.1 元推理本身就是智能体能力的一部分

通常我们认为智能体在长任务的表现，取决于底层模型本身。但本实验固定底层模型不变：元推理智能体和直接控制智能体调用相同模型，分发同样工作单元，拥有相同总预算，唯一区别是如何管控求解流程。 全部匹配对照实验元推理效果更好，并且预算越高，优势越大。 这说明：管控整个求解运行的能力，本身就是独立的智能体性能组成部分，可以独立衡量、独立优化，不依赖底层求解能力本身。

7.2 元推理本身就是一套智能体式流程

普通智能体中，元层级的推理往往和任务本体层工作交织在一起，共享同一次模型调用、同一份上下文、持续累积历史会话。 本文实验与论证表明：元层级认知本身可以作为一类独立工作：需要多轮推演、专用工具、子任务。控制器在敲定下一步计算前，读取历史产物、给自己写下笔记、反复回看部分笔记、对候选方案打分，这套打分区分正误的效果甚至优于工作单元的自我置信度。 这些都属于认知动作（epistemic action）：动作的目的不是直接推进任务，而是改变智能体自身掌握的信息。持久化内存参与这套元推理，保存控制器认为重要的备忘，供后续阶段使用。这符合 “延展心智” 理论：外部存储参与认知过程，而不仅仅是记录认知结果（Clark 与 Chalmers，1998）。

本文提出的四阶段只是组织这套元推理的一种方案。实验支持的核心观点是功能分离：评判一套不断增长、相互关联的工作成果本身就是复杂任务，元层级也需要本体层智能体同样的能力：保存自己推导得到的结论、查询历史信息、多轮思考空间。

7.3 局限性

1. 开销与失效模式
   分阶段控制带来额外计算开销。小预算下性能交叉的现象说明这套设计并不在全部场景都优于直接控制。另外，如果控制器评估出错，会留下误导性状态，或者丢弃一份后续再也不会读取的高质量中间成果。精简状态本身是有损压缩，只有后续主动读取内存，才能找回那些当时看似不重要、后期才变得关键的信息。

一个值得注意的失效样例：LongCoT‑mini 国际象棋子集，元推理效果反而弱于直接控制，其余领域元推理大幅领先。初步轨迹采样分析，问题来自无效反复推演：过多校验、迭代，把原本已经正确的答案扰动出错。完整根因分析、针对性改进留给未来工作。

2. 模型依赖性
   收益大小和底层模型相关。推理基准上 Gemini 3.1 Pro 收益最大；GPT‑5.5 在 ProgramBench 收益突出；Opus 4.8 全部任务均正向提升，但增益幅度偏小。 差异来源于模型作为控制器时的行为，受任务难度、提示词、工作单元能力共同影响。完整证据范围见附录 A。

8 结论

当给智能体分配更多推理时算力，它就要面对更多 “算力该如何使用” 的选择。本文提出智能体元推理，把这类决策变成智能体内部显式推理环节。 在四套基准、三款前沿大模型上，主预算设置下，元推理智能体全部匹配对照实验性能更优；直接控制智能体进入平台期的预算区间，元推理依旧持续提升。 分析表明：它会更充分消耗分配的预算，基于前期成果构建后续工作，更多运行实例生成正确候选，控制器评判自身工作的能力优于工作单元自带置信度；同时控制器状态大小不再随运行总长度同步膨胀。

因此，智能体的最终性能，既取决于 “把任务做好的能力”，也取决于 “判断哪些工作值得做的能力”。当求解运行周期不断变长，“做决策” 这件事，本身就成为一类重要工作。

参考文献

---

附录

附录 A 证据范围

1. 本文验证的是整套元推理组合设计的效果，没有做组件级消融：不能单独证明评估、提议、精简状态、内存访问每一个模块各自的因果贡献。想要定位每个机制的作用，需要做删除阶段、仅保留状态、仅保留内存接口等消融实验。
2. 实验以模型调用次数作为预算单位，但不同调用 token 长度、墙钟时间、FLOPs 算力并不相等；智能体也会自主选择消耗多少预算。因此结论是同等名义调用次数下的性能对比，不能直接等价为同等时延、同等算力消耗下的效率对比。
3. 实验覆盖三款前沿模型，四套基准；但部分基准样本量较小（IMO 高级证明集仅 30 道题）。观测到正向得分提升，不代表每一组差异都具备统计显著性；也不能直接推广到弱模型、其他任务、远超本实验的超长运行。外部基线结果只针对论文测试的版本与配置。

附录 B 元推理智能体提示词

元推理智能体每一轮循环四个阶段：Assess、Propose、Evaluate、Dispatch。每个阶段都是独立的提示词循环，每轮都从全新上下文开始，拥有独立系统提示词与用户消息。

• 文本类推理基准提示词结构一致，仅少量任务专属措辞修改；
• ProgramBench（代码重构基准）提示词完整附在原文。

B.1 Assess（评估阶段）

用户消息由 {task} 任务描述、{memory} 内存索引、{previous_state} 上一轮状态、{new_artifacts} 上一轮新增产物拼接。

文本基准系统提示词核心：你是专家分析师，评估推理问题候选解。你的目标是客观、批判性评估全部候选，不只是简单总结。仔细阅读每一份候选的推理与答案，校验推理每一步是否成立、是否覆盖全部题目条件、答案是否由推理导出、格式是否合规。 工具：read_memory读取完整产物，write_memory写入笔记。输出包含：每一份新候选的逐条评估（标签：LIKELY_CORRECT / HAS_GAPS / FUNDAMENTALLY_FLAWED）、全局综合评估、是否建议停止标记、未解决问题清单。只有充分确信没有漏洞才输出 STOP，否则 CONTINUE。

ProgramBench 版本 Assess 提示词：你是高级软件工程师，审阅代码重构的工作单元报告。维护一份基于证据的快照，不能凭空臆断。输出分为五部分：已实现功能、存在问题、未验证功能、尚未探索功能、死胡同（已经尝试并放弃的方案）。所有事实必须标注证据来源 ID 或者 git 提交哈希。不打分、不输出停止信号，停止决策交给后续 Propose/Evaluate。

B.2 Propose（提议阶段）

输入：任务描述、内存索引、Assess 输出的当前状态。

系统提示词核心：作为策略规划者，基于现有评估，尽可能列出全部合理下一步动作，不要自我过滤；后续 Evaluate 阶段负责筛选。动作可以包括全新思路、定向修复、独立校验、寻找反例、融合多个候选、建议停止提交。使用工具读取内存、写入备忘笔记。输出全部候选动作，写明目标、价值、假设、依赖哪些历史产物。

B.3 Evaluate（方案评估阶段）

输入：任务、内存索引、当前状态、Propose 输出的候选动作、剩余预算（本阶段唯一可以看到预算的阶段）。

文本基准提示词：评估每一个候选动作，预估收益、消耗成本，给出 HIGH_VALUE / MEDIUM_VALUE / LOW_VALUE 评级。输出 YAML 格式推荐：动作 ID、传入的内存 ID 列表、并行工作单元数量。只有全部条件都满足才允许 STOP 提交，有疑问就继续执行。

ProgramBench 版本：可以把多个相关小动作为一组做评估。修改文件的编码任务并行度只能为 1，只读任务（测试、查看二进制）可以并行。优先修复破损、未验证、未实现项。满足全部条件（无未探索、无破损、全部已验证）才允许 STOP。输出 YAML，其中subagent_prompt字段是完整给工作单元的指令。

B.4 Dispatch（分发任务阶段）

输入：任务、内存索引、Evaluate 输出的 YAML 推荐结果。

系统提示词：把 Evaluate 输出转化为工具调用。工具：run_workers批量启动并行工作单元，finish(memory_id)提交内存中已存在的产物。如果是 STOP 指令，调用 finish；否则组装 run_workers 调用。重点：工作单元看不到控制器内部推演，传给 worker 的指令必须完整自包含，禁止只传动作 ID 简写。

附录 C Direct Control Agent（直接控制智能体）提示词

没有分阶段，是持续会话：一套系统提示词，交替工具调用与工具返回结果，全部历史保留在消息列表。 工具：run_workers启动并行子工作单元；finish(result)提交最终答案。 系统提示描述工具用法、内存 ID 引用方式、常见陷阱。末尾追加预算提醒，预算耗尽时推送 FINISH NOW 强制提交提示。

附录 D Worker（工作单元）提示词

元推理与直接控制智能体使用完全相同的 Worker 提示词。Worker 看不到控制器内部状态，只拿到任务、选定的上下文产物、下发的指令。

• 文本基准 Worker：要求显式写推理，强制开头<title>标题，结尾输出confidence: HIGH/MEDIUM/LOW置信度标记，供上层控制器读取。
• ProgramBench Worker：必须先 git commit 保存改动，输出<summary>摘要，写明分支、完成内容、二进制行为发现、编译状态、剩余待做事项，结尾同样输出 confidence 标记。

附录 E Artifact Memory 产物内存

内存池对外接口：read_memory([id列表])，write_memory([{title, body}])。 产物 ID 命名规则：{轮次}_{工作单元编号}，例如2_1代表第 2 轮的第 1 个工作单元。

• 工作单元返回，生成产物；控制器调用 write_memory 也生成产物。
• {memory} 变量传给控制器各阶段：只输出 ID + 标题索引，不输出完整 body，保证控制器状态体量小。
• 只有调用 read_memory，才拿到产物完整内容。Worker 拿到的是产物 body，看不到产物 ID 标识。

附录 F 工具定义

完整 JSON 工具 Schema：run_workers、finish、read_memory、write_memory。 注意两套框架 finish 工具的区别：

• Direct‑Control：finish 接收完整答案字符串；
• Meta‑Reasoning：finish 只接收内存产物 ID，不能凭空生成答案。

ProgramBench 额外增加只读 git 工具，支持 log/show/diff 等只读操作，不允许修改仓库。

附录 G ProgramBench 实现细节

1. 任务提示词：说明容器环境，不允许下载源码、反编译二进制、包装原可执行文件；只能通过 CLI 交互观察行为；编译脚本必须生成./executable。提供recover_executable工具恢复原始参考二进制。
2. 只读 git 工具：控制器可以读取 commit、diff，查看 worker 实际提交的代码，而不只看 worker 写的文字报告。

附录 H RLM（递归语言模型）实现改动

为公平对比，对原版 RLM 做两处关键修改：

1. 受限 Python 工作空间
   禁用可以直接求解问题的运算语法；只允许字符串处理、调用子模型接口；所有实际推理计算必须交给子模型调用，禁止直接在 RLM 控制器侧求解。Opus 4.8 在 LongCoT‑mini 有一组例外，使用完整 Python 环境，表格中标记 *。
2. 增加预算记账
   RLM 原生没有预算概念，我们增加同样预算计数、接近耗尽的 FINISH NOW 强制终止提示。

附录 I Claude Code、Codex 基线实现

在同一个容器沙盒运行，禁用原生工具链，全部动作统一通过 MCP 容器 bash 工具执行。给它们增加同样的预算记账逻辑，每消耗 10% 预算推送预算提示，达到 90% 推送强制结束提示。

完整参考文献、附录剩余细节请查阅原 arXiv 论文：arXiv:2609.38147v1 [cs.AI]。