Agentic Reasoning and Tool Integration for LLMs via Reinforcement Learning

Paper: arXiv:2505.01441

1. Motivation (研究动机)

现有 RL 增强 LLM 虽然在 Chain-of-Thought 上已经展现出更强的推理深度，但核心能力仍然主要依赖模型参数中的静态知识与纯文本推理。这在两类任务上很快暴露瓶颈：一类是复杂数学题，这类任务往往需要精确符号计算、程序执行或多步验证；另一类是 multi-turn function calling，这类任务要求模型不仅知道调用哪个工具，还要在多轮状态演化中决定何时调用、如何修正失败调用、如何把工具返回值接回到后续推理中。仅靠 prompt 提示模型“可以用工具”通常只能带来浅层使用，无法稳定学会时机选择、失败恢复和多步协同。

这篇论文要解决的具体问题是：如何让 LLM 在没有中间步骤监督的情况下，仅通过 outcome-based reinforcement learning，自主学会把内部推理、外部工具调用和环境反馈交织成统一的 agentic reasoning 轨迹，并在数学推理与函数调用两类任务上泛化。作者提出的目标不是“给模型一个工具接口”，而是让模型学会在推理链内部动态决定 whether / when / how / which tool to use。这个问题值得研究，因为真实世界中的 agent 任务几乎都要求模型与外部环境交互，而不是只在封闭上下文里生成一段文本。

一旦这种能力成立，LLM 就能从“只会想”提升到“能想、能查、能算、能调用 API 并依据反馈修正策略”的统一决策体。作者把这视为从静态文本智能走向 agentic intelligence 的关键一步。

论文在 Introduction 中把这个矛盾说得很具体。对于 Olympiad 级数学题，传统 RL reasoning model 即使愿意写长 CoT，也仍然需要靠自然语言手工维持符号一致性；一旦某一步代数变形或积分展开出错，后续整条 reasoning chain 都会被污染。ARTIST 的动机之一就是把这类“文本推理很擅长提出计划，但不擅长保证数值与符号执行精确性”的弱点，转化成“文本推理负责制定求解路径，外部工具负责执行精确计算”的协作关系。另一条动机来自 function calling。现有 function-calling benchmark 早已不再是单轮 JSON schema 填空，而是要求模型在多轮状态演化中持续决策。

例如用户没有给齐参数时，模型需要先追问；环境返回失败消息时，模型需要判断是参数错误、工具选择错误，还是根本不存在可调用函数；若上下文很长，还要在长对话中记住前文约束。作者认为，这种任务的难点不是“会不会输出某个 API 名”，而是“能否在交互闭环里维持策略一致性”。这也解释了为什么 prompt engineering 不够。只靠系统提示词声明“你可以用 Python”或“你可以调用这些 functions”，最多只能让模型在少数容易识别的场景里触发工具；一旦问题需要多次调用、失败重试、或者在内部推理与工具结果之间来回切换，手工 prompt 就会变得脆弱。

论文把这类 brittleness 归因于：prompt 只能注入行为偏好，却不能通过 trial-and-error 学出长期 credit assignment。

作者对已有 SFT 路线的批评也很明确。若用人工标注的 tool-use trajectories 做监督微调，确实可以教会模型模仿某种调用格式，但这种做法有两个限制。第一，构造高质量中间轨迹代价高，特别是数学和 agent task 的“正确过程”本身可能不唯一。第二，模仿式训练容易把模型绑定到示例轨迹，而不是学到“面对未知状态时如何决策”的策略。ARTIST 试图绕开这两个瓶颈，只用最终任务结果作为信号，让策略自己搜索有效的交互模式。从研究价值上看，这篇工作瞄准的是 LLM 从 static completion engine 向 interactive decision-maker 的过渡。

数学推理和 multi-turn function calling 在表面上是两个 benchmark family，但作者把它们当作同一种底层能力的两个投影：前者强调“推理过程中按需借助精确执行”，后者强调“在环境反馈中做多步 API 规划”。如果同一种 RL recipe 能同时提升这两类任务，就说明 tool integration 并不是某个 domain-specific trick，而可能是一类更普适的 agent training principle。论文还隐含回答了一个更现实的问题：为什么要用 RL，而不是在 inference 时外挂一个规则系统？原因在于规则系统只能编码“如果看到某种模式，就调用某个工具”，却很难覆盖未知错误、边界条件和长程交互依赖。

ARTIST 把工具调用的成功与失败都纳入 rollout，让模型在训练时亲身经历“调用有用时带来回报、调用错误时拖累整条轨迹”的后果，因此学到的是策略而非规则库。

因此，这篇论文的 motivation 不是单纯追求 benchmark 分数更高，而是试图回答一个更基础的问题：如果未来 LLM 要成为真正的 agent，那么“推理”和“行动”是否应该在同一个学习目标下被联合优化。ARTIST 给出的答案是肯定的，并且选择了两个最容易验证又最具代表性的任务族，作为这一命题的第一步实证。 从这个角度看，ARTIST 的动机也可理解为对“reasoning-only scaling 是否足够”的反问。论文立场很明确：当任务需要外部计算、外部 API 或环境反馈时，单纯把 CoT 拉长并不能替代真实交互；只有把交互策略本身纳入学习目标，模型才可能稳定跨过从 thinker 到 agent 的门槛。

2. Idea (核心思想)

ARTIST 的核心 insight 是：不要把工具使用看成 inference-time 的外接插件，而要把“思考 token、工具调用、工具返回、下一步思考”统一成一个可被 RL 直接优化的 rollout。只要 reward 只看最终任务是否成功，模型就会逐渐学到何时调用工具、何时继续内部推理，以及工具失败后如何恢复。作者的关键创新是把 agentic reasoning 作为一个统一策略学习问题来建模。具体地，模型在 rollout 中交替输出自然语言思考片段和结构化工具调用片段，环境执行工具后把结果作为新观察返回，再继续生成；训练时用 GRPO 仅凭 outcome reward 来优化整条轨迹，而不提供 step-level demonstration。

它与已有方法的根本差异在于：prompt-based tool use 只是把“你可以调用工具”写进系统提示词，tool-augmented SFT 则依赖人工构造中间轨迹；ARTIST 则直接把工具使用决策本身作为 RL 可学习策略的一部分。与 ToRA、PAL 这类工具增强推理方法相比，ARTIST 学的是自适应的策略，而不是固定模板下的推理加代码执行。更具体地说，ARTIST 重新定义了“一个 action 是什么”。在普通 RLHF / reasoning RL 里，模型的 action 主要体现为生成一串文本 token；

而在 ARTIST 里，生成文本只是 action 的一部分，另一个同样关键的 action 是“是否把当前 reasoning 分支提交给环境执行”。也就是说，策略空间从纯语言生成，扩展成了“语言生成 + 工具调用编排”的联合空间。

这个 insight 带来的直接好处是统一性。数学场景中的 <python>...</python> 和函数调用场景中的 <tool>...</tool> 在表面格式上不同，但在训练视角里都是“模型发出结构化外部动作，环境返回 observation，再继续 rollout”。作者没有为两个任务分别设计两套 RL 目标，而是把它们都折叠为同一种交互式序列建模问题，这使得 ARTIST 更像是一种 agent training recipe，而不是数学特化方法。论文还强调，真正新的地方不是“模型能调工具”，因为 ToRA、PAL、ReAct 风格方法已经展示过工具增强推理的价值；

真正新的地方在于这些方法大多把工具调用写成 prompt template、固定程序骨架或少量 demonstration 诱导出的行为，而 ARTIST 让工具调用本身接受 outcome-driven policy improvement。换句话说，先前方法往往假设“工具调用模式大致已知，只需让模型遵守”；ARTIST 则假设“最优调用模式未知，应该让策略在环境中自己学出来”。作者的第二个关键观察是：tool output 不应被当成要模仿的 token。环境返回的结果往往是 deterministic 的，例如 Python 执行打印值、函数调用返回 JSON、错误消息或缺参提示。

如果把这些 token 和模型自己生成的 reasoning token 一样纳入 loss，模型会被鼓励去“复现工具输出表面形式”，而不是学会“为了得到有用反馈而做对调用决策”。因此 ARTIST 在 GRPO 中引入 tool-output masking，让梯度只更新模型自己负责的决策部分。

从直觉上看，这让 ARTIST 的学习目标更接近真正的 agent optimization。模型不需要为 SymPy 算出的结果负责，也不需要为 API 返回的字符串内容负责；它只需要为“自己有没有在合适的时机发起合适的调用、有没有读懂返回值并据此改变计划”负责。这个设计把 credit assignment 从“模仿环境”转成了“利用环境”，是全文最重要的 technical insight 之一。如果用一句更凝练的话概括，ARTIST 的核心思想不是“让 LLM 会用工具”，而是“把工具作为 RL 环境的一部分，让 reasoning 与 acting 在同一条 rollout 里共同优化”。

这也是它与纯 prompt tool-use、纯 supervised trajectory learning、以及单步 function calling 系统的根本区别。这一定义还有一个更深的含义：在 ARTIST 里，“是否调用工具”本身就是 reasoning 的一部分，而不是 reasoning 完成后的附属步骤。模型不是先得到一个完整结论、再顺手验证一下；很多时候恰恰是因为尚未得到完整结论，所以需要借助工具把局部不确定性消掉，再回到文本推理里整合结果。论文把这种循环式分工视为 agentic intelligence 的核心特征。

因此，ARTIST 的 novelty 既不是更强的工具本身，也不是更复杂的 prompt，而是把“调用外部世界获得新证据”纳入了策略学习闭环。对数学来说，新证据是可执行计算结果；对 function calling 来说，新证据是 API 返回值与失败原因。两者形式不同，但在策略层面都扮演同一种角色：帮助模型缩小当前不确定性，并决定下一步该想什么、做什么。

3. Method (方法)

3.1 整体框架

ARTIST 将推理过程建模为一个多轮 rollout：模型先输出内部推理，再决定是否发起工具调用；工具执行后返回结果；模型把该结果纳入新的上下文继续推理与决策，直到输出最终答案或完成函数调用任务。这个流程统一覆盖了数学问题中的 Python 执行，以及 function-calling 场景中的结构化 API 组合。 论文把这一过程表述为 reasoning-action-observation 的闭环，而不是一次性生成答案。对同一道题，模型会先根据当前上下文生成一段 reasoning，再视情况选择是否生成 <python> 或 <tool> 片段；环境执行之后返回新的 observation，这个 observation 不只是“额外文本”，而是会改变下一步策略分布的状态变量。也因此，ARTIST 训练的对象不是某个最终答案字符串，而是一条包含多次状态更新的交互轨迹。 在任务统一上，作者刻意避免把数学与 function calling 分成两类完全不同的 pipeline。数学任务里的外部环境是 Python executor，尤其支持 exec() 执行代码，并将成功输出、空输出、异常信息三种反馈都显式回传；函数调用任务里的外部环境则是 API sandbox，会把函数返回值或失败原因放进 <tool_result> 标签。两者都满足同一个抽象接口：策略发出结构化动作，环境返回结构化观察。

Figure 1 解读：这张图给出 ARTIST 的最外层 agent 架构。核心不是“模型外面挂了个工具箱”，而是 reasoning、tool query、tool output 被串成一个循环闭环。模型并非先一次性思考完再调用工具，而是在多步过程中按需交替生成与调用，因此环境反馈会实质性改变后续轨迹。

Figure 2 解读：这张图展示训练视角下的方法总览。每个 rollout 都由内部思考、工具使用和环境交互交替组成，最终只根据 outcome reward 优化。作者强调这意味着工具调用策略、调用时机与失败恢复行为，都是在统一 RL 目标下自然涌现出来的，而不是事先监督出来的。

从方法直觉上看，ARTIST 成功的关键在于把工具输出当作“可改变后续 token distribution 的外部状态”，而不是把工具视为单次辅助模块。这样 RL 优化的不是某段固定 CoT，而是一个在环境反馈驱动下不断更新策略的过程。也因此，模型能够学到自我纠错、上下文感知的多步工具调用，以及在简单题上保持简洁、在难题上主动拉长 reasoning trace。

论文实际上把 LLM 放进了一个轻量级 POMDP 里。当前 observation 由用户问题、历史 reasoning、历史 tool calls 与历史 tool outputs 共同组成；当前 action 是继续 reasoning、提交工具调用、或者终止并输出答案；转移函数由外部环境决定，即 Python executor 或 API sandbox 如何返回反馈。作者没有正式使用 POMDP 记号，但整个框架已经具备 agent learning 的基本要素，这也是它能自然覆盖多步交互任务的原因。

3.2 轨迹结构与环境接口

数学推理场景中，模型会在 <think>...</think> 中思考，在需要精确计算时输出 <python>...</python> 代码片段，并由外部 Python executor 执行。工具返回可能有三类结果：成功且有输出、成功但没有 print 输出、执行失败并返回编译错误。作者特别把这三种反馈都明确返回给模型，使其有机会在后续轨迹里补上 print、修正代码或改变求解策略。函数调用场景中，模型先在 <reasoning>...</reasoning> 中给出推理，再在 <tool>...</tool> 中输出一个或多个结构化函数调用。

环境将返回值封装在 <tool_result>...</tool_result> 里，并把失败原因显式暴露给模型。与简单单轮 function calling 不同，这里每个 rollout 可能包含多次工具交互，因此任务成败强依赖上下文维护、参数补全和错误恢复。这一节最值得注意的点是，ARTIST 并没有把环境设计成“只要工具调用失败就立刻结束 episode”的脆弱接口。相反，失败本身也是 observation。比如数学代码里漏写 print，系统不会直接判整个 rollout 失败，而是把“no output”当作可见反馈返回；函数调用里若参数缺失，环境也会把缺少的 slot 或失败原因明确告诉模型。

作者希望模型在训练中学会把错误消息当作下一步推理输入，而不是把错误视为无法恢复的终止状态。这使得 ARTIST 学到的不是静态工具模板，而是 recovery policy。尤其在 BFCL v3 的 Missing Parameters、Missing Function、Long Context 三类子任务里，真正困难的部分常常发生在第一次调用之后：模型必须根据失败反馈决定追问用户、换用其他函数、或者明确声明当前工具集合无法完成请求。把这些交互过程显式纳入 rollout，是论文区别于 schema-filling function-calling 系统的关键。

从表示角度看，标签化格式也承担了 credit assignment 的辅助作用。<think>、<python>、<reasoning>、<tool>、<tool_result>、<answer> 这些段落标签把“模型自主生成部分”和“环境返回部分”清晰分开，使训练时可以精确做 token masking，也让 reward function 可以检查输出是否遵守预期交互顺序。这种结构化模板既是 interface contract，也是 RL 训练时的可计算约束。 这一设计还有一个容易忽视的收益：它让“调用工具前是否已经形成足够明确的子目标”变得可观测。若模型在 <think> 或 <reasoning> 中没有先形成清楚计划，往往会在下一步生成模糊、参数缺失或目标错误的调用；而一旦环境返回失败信息，这个失败又会显式写回轨迹。换言之，ARTIST 不只是训练工具使用，还在训练“把内部计划外化成可执行动作”的能力。 对于数学场景，作者选择 Python 而不是更特化的 symbolic solver 也有意义。Python executor 同时支持一般程序执行、数值检查和符号库调用，因此策略不需要先学会“该选哪类数学工具”，而是统一通过一个入口探索不同求解方式。这降低了 action space 的接口复杂度，让学习重点更多落在何时执行与如何读取结果，而不是在多个工具之间硬切换。

这也解释了 ARTIST 为什么能把“工具调用时机”学成一种连续决策，而不是离散规则列表。因为从模型视角看，Python executor 不是某个只在特定题型下才使用的专用模块，而是一个随时可访问的外部推理伙伴。模型需要持续判断：当前不确定性是否已经高到值得切换到程序执行；执行之后得到的证据是否足以支持收束到 <answer>；若仍不足，则是否继续思考还是再次调用工具。这个决策链条本身就是 agentic reasoning 的主体。

3.3 强化学习目标

GRPO objective

论文采用 Group Relative Policy Optimization (GRPO) 作为核心训练算法。每个问题会采样多条 rollout，然后依据最终结果计算 reward，再在同组样本内部进行相对优势比较。论文没有引入中间 supervision，也没有单独标注正确工具调用序列，因此 credit assignment 完全由最终 outcome 驱动。 作者选择 GRPO 而不是带 critic 的 PPO，主要考虑 sample efficiency 和实现复杂度。GRPO 通过同一 prompt 下的 groupwise comparison 直接构造相对优势，不需要额外训练 value function。对 ARTIST 这种每条 sample 都可能很长、而且中间穿插工具调用的 rollout 来说，省掉 critic 不只是工程简化，还能避免 value estimation 进一步放大长轨迹上的噪声。 其标准目标可以写成： $ \mathcal{L}_{\text{GRPO}}(\theta) =

• \mathbb{E}{(x, y_i) \sim \pi{\theta_{\text{old}}}} \left[ \frac{1}{G}\sum_{i=1}^{G} \min\left( r_i(\theta)\hat{A}i,; \operatorname{clip}(r_i(\theta), 1-\epsilon, 1+\epsilon)\hat{A}i \right) \right] $其中$G$是同一个prompt采样出的rollout数，$r_i(\theta)=\frac{\pi\theta(y_i|x)}{\pi{\theta_{\text{old}}}(y_i|x)}$，$\hat{A}_i$ 是组内相对优势。ARTIST 的创新并不在于重新发明 RL loss，而在于把工具交互后的完整轨迹作为优化对象，因此 reward 可以自然鼓励“正确使用工具后的正确答案”。论文正文进一步说明，ARTIST 的 advantage 来自同组 rollout 的相对奖励，而不是某个外部估计器。

Group-relative credit assignment

直观上，如果同一题的 6 条或 8 条轨迹里，只有部分轨迹在恰当时机调用了工具并顺利完成任务，那么这些轨迹会在组内获得更高优势，策略就会提高生成相应 reasoning-action pattern 的概率。这种“同题多轨迹相对比较”尤其适合 agent setting，因为它天然比较了不同工具调用策略的后果。更关键的是，作者专门讨论了 token-level loss 在 agentic setting 下的副作用。若把工具返回值也当作普通 target token 参与 GRPO 更新，模型会被鼓励拟合 deterministic tool output，例如记住某类错误消息或复制某种 JSON 返回格式。

Masking tool-output tokens

这会污染学习目标，让模型把环境输出误当成自己应该负责生成的内容。为避免这一问题，ARTIST 在 loss 计算时 mask 掉所有 tool-output tokens，只对模型自己生成的 reasoning、tool call 和 final answer token 反向传播。这个 masking 设计看似细节，实际上决定了方法是否真正学到“策略”。因为 agent 训练的目标是提高决策质量，而不是提高复述环境反馈的能力。作者给出的 Algorithm 1 可以概括为：对每个问题采样多条含工具交互的 rollout，执行环境、计算 rollout-level reward、对 tool output 做 mask、再按 GRPO 更新策略。

方法的 novelty 很大程度上就体现在这一步对 standard reasoning RL 的 agentification。

Agent-environment boundary

从优化稳定性看，masking 还有一个隐含收益：它把超长轨迹里的不可控 token 区段排除出梯度路径，降低了环境返回格式变化对训练的干扰。特别是在函数调用任务中，API 返回值长度和内容分布可能高度不稳定；如果不 mask，这些返回值会放大 sequence-level variance。ARTIST 通过只学习“如何提问环境”，而不学习“环境会说什么”，把问题转成更干净的 policy optimization。如果把这一点和普通 reasoning RL 对比，会更容易看出 ARTIST 的不同。在没有工具的 setting 里，整条输出几乎都来自模型本身，因此 token-level policy gradient 默认是合理的；

而在有环境反馈的 setting 里，trajectory 已经混入外部系统生成的 observation，训练必须显式区分 “agent token” 与 “environment token”。ARTIST 对 GRPO 的主要改造，实质上就是补上这层 agent-environment boundary。论文虽然没有给出更复杂的 credit decomposition，但它依靠 groupwise comparison 已经足以区分“正确但不使用工具”“正确且高效使用工具”“错误且乱用工具”等多种行为模式。对于数学题，这种比较能偏好那些在关键步骤调用 Python 做验证的轨迹；对于函数调用任务，它则会偏好那些较快完成任务、且正确调用次数更多的轨迹。

Sequence-level advantage effect

换言之，优势函数虽是 sequence-level 的，却能通过组内对比隐式塑造中间策略。

3.4 Reward 设计

Task-level reward signals

数学任务里，reward 本质上围绕最终答案是否正确展开，因为训练集中的每道题都带 ground-truth final answer。工具是否被使用、调用次数多少，并不是显式监督目标；但只要调用工具能提升正确率，策略优化就会倾向于保留这些行为。函数调用任务里，reward 来自任务是否被正确完成，尤其考察在缺失参数、缺失函数、长上下文等子任务中是否能输出合理的调用序列并管理对话状态。作者在图中还分析了 reward score 与工具调用、response length 的共同变化，说明 ARTIST 学到的是更高质量的 agentic rollout，而非单纯更长输出。

Composite reward components

不过 ARTIST 的 reward 不是单一 binary signal，而是 composite reward。论文在 2.4 Reward Design 中明确给出三部分：answer reward、format reward 和 tool reward。其中 answer reward 负责最终任务是否完成；format reward 检查 rollout 是否遵守规定的交互模板，例如 reasoning、tool call、tool output、final answer 的顺序是否正确，以及答案是否包在 <answer> 标签中；tool reward 则鼓励有意义、符合任务需求的工具使用，而不是无约束地乱调工具。

这种设计体现了作者对“纯 outcome reward 是否过于稀疏”的折中处理。ARTIST 不需要 step-level expert trajectory，但仍然通过 format / tool 相关奖励为搜索空间加入弱结构先验。尤其在早期训练阶段，如果没有 format reward，模型可能连合法的 <python> 或 <tool> 交互模板都学不稳；如果没有 tool-related reward，策略也可能退化成“尽量少调用工具以降低格式出错风险”的保守解。

Tool reward：鼓励有效调用

数学场景中的 tool reward 重点不是鼓励更多调用次数，而是鼓励有效调用。论文从结果分析中反复强调，ARTIST 提高的是 reward score 与 Pass@1，而不是简单把 response length 或 tool-call count 拉高。也就是说，训练信号并未把“多用工具”本身当成目标，而是让工具调用在能改善 correctness 时自然涌现。函数调用场景中的 reward 则更贴近 environment success。

Function-call evaluation

论文把 BFCL v3 训练期间的 correctness reward 拆成 state reward 与 function reward，并在 τ-bench 上额外观察 reasoning length per tool call、total correct tool calls、steps to task completion。这样的评测对应着三种不同失败模式：不会规划、会规划但调错函数、能调对函数但效率低。ARTIST 的 reward 设计和后续结果分析正是围绕这三种失败模式展开的。从方法直觉上看，reward 设计承担的是“把成功 agent 行为定义清楚”的角色。

Format / tool reward 的结构先验

正确答案当然重要，但对 agent 来说，正确的交互协议、可恢复的失败处理、以及把工具输出真正接回后续 reasoning，同样是成功的一部分。ARTIST 之所以能跨数学和函数调用泛化，部分原因就在于它把这些要素抽象成了可共享的 reward 组件。还要注意，format reward 在这篇论文里不是简单的“输出格式美观约束”，而是 training curriculum 的一部分。只有先学会稳定地产生可执行的 <python> / <tool> block，后续的 correctness reward 才有机会把搜索集中到“哪些调用真正有效”。

因此 format reward 的作用更接近把 agent 行为限制在一个合法 action manifold 上，而不是单纯惩罚标签缺失。

Avoiding degenerate tool policies

tool reward 则承担了避免 degenerate policy 的角色。若只有最终 answer reward，模型可能会出现两种坏解：一种是完全不调用工具，退回纯文本猜测；另一种是频繁调用工具但并不真正读取结果，只把工具当作增加轨迹长度的装饰。作者通过 reward design 和后续 metrics analysis 共同说明，ARTIST 学到的是“有针对性的工具使用”，而不是盲目增大调用频率。

3.4.1 任务特定实现细节

数学训练中，作者对每个问题采样 6 条 reasoning rollouts，temperature 设为 1.0，并给到 8,000 token 的高生成预算，以容纳长链推理与多次 Python 交互。这个配置反映出方法预期模型会主动探索不同解法，而不是只在短答案空间里做局部微调。外部工具只提供一个 Python interpreter，但由于支持 SymPy、NumPy 等库，单一接口已经足以覆盖符号代数、方程求解和数值验证。函数调用训练则使用 8 条 rollouts、temperature 1.0，并把单任务 user turn 数固定为 1，以控制 rollout 复杂度但保留多次 tool interaction。

最大 context window 为 16,384，单次 response 上限为 2,048 tokens，说明作者预期真正的复杂度主要来自多轮工具-反馈循环，而不是超长用户输入本身。环境把每次函数执行结果都写入 <tool_result>，包括显式失败信息，为恢复策略提供可学习信号。这两套配置也体现出作者对两个 domain 的不同判断。数学任务需要更长 token budget，因为难点主要在长链 reasoning 与程序验证；函数调用任务需要更大的上下文窗，因为难点在多轮交互历史与 API 状态跟踪。

虽然两者共享同一 RL recipe，但 rollout budget 的侧重点并不相同，这说明 ARTIST 是统一训练框架，而不是要求所有任务遵守完全一致的 decoding regime。

3.4.2 典型成功与失败模式

从论文的分析逻辑看，ARTIST 主要在三类行为上优于 prompt baseline。第一类是“该调用时调用”：遇到需要精确计算的数学子问题时，策略会更主动地触发 Python，而不是继续在自然语言里硬算。第二类是“调用后能利用结果”：拿到执行值、错误消息或函数返回后，后续 reasoning 会围绕这些 observation 更新，而不是把它们原样复述一遍。第三类是“失败后可恢复”：当第一次调用不完整或不正确时，模型更常进行修正而非直接放弃。相应地，论文也暗示了 ARTIST 仍可能失败的边界。

若任务本身需要极长 horizon 的规划，或者环境反馈过于噪声化、无法清楚指示错误原因，那么仅靠 rollout-level reward 的 credit assignment 仍然可能不足。函数调用训练集规模也只有 100 个任务，这意味着策略泛化更多依赖 RL 学到的交互先验，而非大规模任务覆盖。换言之，ARTIST 证明了“RL 能学出工具使用策略”，但还没有彻底解决开放世界 agent training 的数据效率问题。这一点也帮助理解作者为什么把实验重点放在数学和结构化 function calling，而不是更开放的 WebAgent 场景。

前两者已经足够展示 reasoning-tool-feedback 闭环，又能提供相对可验证的 outcome reward；如果一开始就跳到开放网页环境，环境随机性和 reward design 难度会更高，反而不利于隔离 ARTIST 的核心贡献。换句话说，ARTIST 论文更像是在建立一个最小可验证的 agent RL 配方：先在 reward 可定义、工具接口可控、错误反馈可解释的环境里证明“策略能学会何时与如何交互”，再谈向更开放环境扩展。这个定位也解释了全文为何如此强调方法抽象，而不是只展示某个单一 benchmark trick。

3.5 关键组件伪代码

虽然论文没有公开仓库，但从论文给出的 prompt template、环境协议和 GRPO 描述，可以把方法重建为如下组件。

def rollout_math(policy, question, python_env, max_steps):
    context = [{"role": "user", "content": question}]
    trajectory = []
    for _ in range(max_steps):
        response = policy.generate(context)
        trajectory.append(response)
        context.append({"role": "assistant", "content": response})
        code = extract_between(response, "<python>", "</python>")
        if code is None:
            if "<answer>" in response:
                break
            continue
        tool_result = python_env.exec(code)
        obs = f"<output>{tool_result}</output>"
        trajectory.append(obs)
        context.append({"role": "tool", "content": obs})
    return trajectory

def rollout_function_call(policy, user_query, tool_env, max_turns):
    context = [{"role": "user", "content": user_query}]
    trajectory = []
    for _ in range(max_turns):
        response = policy.generate(context)
        trajectory.append(response)
        context.append({"role": "assistant", "content": response})
        calls = parse_tool_list(response)
        if not calls:
            break
        tool_outputs = []
        for call in calls:
            result = tool_env.execute(call)
            tool_outputs.append(result)
        obs = wrap_tool_results(tool_outputs)
        trajectory.append(obs)
        context.append({"role": "tool", "content": obs})
    return trajectory

def grpo_train_step(policy, ref_policy, batch, reward_fn, group_size, epsilon):
    grouped_rollouts = []
    for sample in batch:
        group = [policy.sample(sample) for _ in range(group_size)]
        rewards = [reward_fn(sample, y) for y in group]
        advantages = normalize_group_rewards(rewards)
        grouped_rollouts.append((group, advantages))
 
    loss = 0.0
    for group, advantages in grouped_rollouts:
        for y, adv in zip(group, advantages):
            ratio = policy.logprob_ratio(y, ref_policy)
            unclipped = ratio * adv
            clipped = ratio.clamp(1 - epsilon, 1 + epsilon) * adv
            loss += -torch.minimum(unclipped, clipped)
    loss = loss / len(batch)
    loss.backward()
    return loss

3.6 代码到论文映射

论文明确说明代码、超参数和配置“will be released soon / upon publication”，当前未给出公共 GitHub 仓库。因此本节只能映射到论文中可观察到的实现接口，而不能映射到 released code 文件。

代码搜索未找到开源实现。

论文概念	当前可映射来源	说明
ARTIST 总体框架	introduction.tex, overview.tex	定义 reasoning / tool / environment 交替结构
数学任务 prompt 协议	appendix.tex Prompt Template for Complex Math Reasoning	定义 <think>, <python>, <output>, <answer>
函数调用 prompt 协议	appendix.tex Prompt Template for Multi-turn Function Calling	定义 <reasoning>, <tool>, <tool_result>
训练算法	overview.tex, experiment.tex, appendix.tex	说明使用 GRPO、多 rollout 采样和 outcome reward
工具反馈类型	appendix.tex Implementation Details	给出成功、有无输出、失败三类 Python 反馈

4. Experimental Setup (实验设置)

4.1 数据集

数学推理训练集由 20,000 道 math word problems 构成，主要来自 NuminaMath。评测集包括 4 个标准 benchmark：MATH-500（500 题）、AIME、AMC 和 Olympiad Bench。论文把这组评测设计成覆盖从常规竞赛题到高难度 olympiad 题的不同层级。 函数调用训练数据来自 BFCL v3 base multi-turn 类别中的 100 个标注任务，另有 100 个任务作为验证集。评测时使用两类 benchmark：τ-bench 的 Airline 和 Retail 两个 domain，以及 BFCL v3 中的 Missing Function、Missing Parameters、Long Context 三个子集。 这些数据集的组合有明确分工。NuminaMath 负责提供大规模 outcome-supervised math 训练样本；MATH-500、AIME、AMC、Olympiad Bench 负责测试从常规竞赛题到高难度题目的泛化。函数调用部分则反过来：训练集本身很小，只用 BFCL v3 的 100 个多轮任务，因此 τ-bench 更像是在测试 ARTIST 是否能把在有限 API 环境里学到的交互策略迁移到更真实的 airline / retail 对话环境。

4.2 Baselines

作者比较了四类基线。

第一类是 Frontier LLMs，例如 GPT-4o，以及 frontier open-source 模型如 DeepSeek-R1、DeepSeek-R1-Distill-Qwen-7B、Llama-3-70B、Qwen2.5-72B-Instruct。第二类是 open-source tool-augmented LLMs，例如 NuminaMath-TIR-7B、ToRA-7B、ToRA-Code-7B、PAL。第三类是 base LLMs，即 Qwen2.5-7B-Instruct 和 Qwen2.5-14B-Instruct。第四类是带 prompt 修改或 reasoning token 的 base 模型，例如 Qwen2.5-7B-Instruct + Python Tool 和 Qwen2.5-7B-Instruct + Reasoning。

4.3 评测指标

数学任务使用 Pass@1 accuracy，衡量单次尝试中最终答案与标准答案精确匹配的比例。函数调用任务同样报告 Pass@1 accuracy，但其“正确”对应整条多轮 function-calling 任务是否在给定环境中顺利完成，因此它同时覆盖参数补全、错误恢复、长上下文状态维护等能力。

除了主指标，论文还额外记录 reward score、tool-call count、response length、reasoning length per tool call、total correct tool calls、steps to task completion。这些分析指标的意义在于区分“结果变好是因为真正学会策略”，还是“只是输出更长、碰巧多试几次工具”。ARTIST 在实验部分反复用这些辅助指标证明，它学到的是更高效也更有效的 agentic behavior。

4.4 训练配置

数学任务中，基础模型为 Qwen/Qwen2.5-7B-Instruct 和 Qwen/Qwen2.5-14B-Instruct。训练算法为 GRPO，batch size 为 8，learning rate 为 $10^{-6}$，优化器为 Adam，${\beta }_1=0.9$、${\beta }_2=0.99$、weight decay 为 0.01。每个问题采样 6 条 rollout，temperature 为 1.0，最大响应长度 8,000 tokens，训练到 100 steps。硬件为 4 张 A100 80GB，总训练时长约 20 小时。这些数字来自论文附录 Implementation Details -> Complex Mathematical Reasoning，不是泛化默认值。

函数调用任务中，基础模型为 Qwen/Qwen2.5-7B-Instruct。训练同样使用 GRPO，batch size 为每 GPU 8，使用 3 张 GPU 训练，并每 4 步做一次 gradient accumulation；learning rate 为 $10^{-6}$，Adam 参数同上，学习率日程为 constant with 20 warm-up steps。每个问题采样 8 条 rollout，temperature 为 0.9，最大 context window 为 16,384 tokens，最大 response length 为 2,048 tokens。硬件为 4 张 A100 80GB，总训练时长约 34 小时。这些数字来自附录 Implementation Details -> Multi-Turn Function Calling。

5. Experimental Results (实验结果)

5.1 数学推理主结果

Figure 3 解读：这张图可视化了 7B 基座下 ARTIST 与其他方法在数学 benchmark 上的差异。可以看到 ARTIST 相比 base、prompt+tool 和既有 tool-augmented 方法都有更稳定的整体提升，尤其在 AIME、AMC、Olympiad 这类更依赖多步求解与精确计算的任务上更明显。

Figure 4 解读：14B 版本延续了相同趋势，但也暴露出一个值得注意的点：更大模型并不自动保证所有 benchmark 都提升。ARTIST-14B 在 MATH-500、AMC、Olympiad 上继续变强，但在 AIME 上低于 7B ARTIST，说明 agentic RL 与工具使用收益并不是简单随参数规模单调增加。

主表结果如下：

方法	MATH-500	AIME	AMC	Olympiad
GPT-4o	0.630	0.080	0.430	0.290
DeepSeek-R1-Distill-Qwen-7B	0.858	0.211	0.675	0.395
DeepSeek-R1	0.850	0.300	0.810	0.460
NuminaMath-TIR-7B	0.530	0.060	0.240	0.190
ToRA-7B	0.410	0.000	0.070	0.130
ToRA-Code-7B	0.460	0.000	0.100	0.160
Qwen2.5-7B (PAL)	0.100	0.000	0.050	0.020
Qwen2.5-7B-Instruct	0.620	0.040	0.350	0.210
Qwen2.5-14B-Instruct	0.700	0.060	0.330	0.240
Qwen2.5-7B-Instruct + Python Tool	0.629	0.122	0.349	0.366
Qwen2.5-14B-Instruct + Python Tool	0.671	0.100	0.410	0.371
Qwen2.5-7B-Instruct + ARTIST	0.676	0.156	0.470	0.379
Qwen2.5-14B-Instruct + ARTIST	0.726	0.122	0.550	0.420

从比较上看，7B ARTIST 相比 7B base model 在四个 benchmark 上分别提升 5.6、11.6、12.0、16.9 个百分点；相比 prompt+Python 工具版本，在 AIME、AMC、Olympiad 上也仍明显领先，说明收益并非仅来自“可以执行工具”，而来自 RL 学到的更好使用策略。论文还强调 ARTIST-7B 全面超过 GPT-4o，而 14B 版本在 MATH-500、AMC、Olympiad 上进一步扩大优势。

5.2 数学过程分析

Figure 5 解读：这张图分析 average reward、tool call 和 response length 等过程指标。作者借此论证 ARTIST 并不是靠偶然采样获胜，而是在困难题上更频繁、也更有效地调用工具，同时生成更长、更有层次的 reasoning trace。

论文给出的解释是：ARTIST 在高难数据集上 tool usage 明显增加，并伴随 reward 提升；response length 在 AIME 上最高可达到 baseline 的两倍，说明模型学会在难题上展开更多中间推理，而在 MATH-500 上长度与 baseline 接近，说明它没有机械地把所有问题都拉成长输出。

5.3 多轮函数调用结果

Figure 6 解读：这张图展示 ARTIST 在 τ-bench 和 BFCL v3 上的总体结果。最明显的提升出现在 τ-bench Airline/Retail 以及 BFCL v3 的 Long Context 子集，说明 RL 训练特别有助于跨多轮交互维持状态、恢复失败调用和完成复杂任务链。

函数调用主结果如下：

方法	Airline	Retail	Missing Function	Missing Parameters	Long Context
GPT-4o	0.460	0.604	0.410	0.355	0.545
Llama-3-70B*	0.148	0.144	0.130	0.105	0.095
DeepSeek-R1	—	—	0.155	0.110	0.115
Qwen2.5-72B-Instruct	—	—	0.245	0.200	0.155
Qwen2.5-7B-Instruct	0.120	0.180	0.085	0.060	0.040
Qwen2.5-7B-Instruct + Reasoning	0.120	0.200	0.105	0.055	0.055
Qwen2.5-7B-Instruct + ARTIST	0.260	0.240	0.105	0.065	0.130

这里最值得注意的是 Long Context：ARTIST 达到 0.130，相比 base model 的 0.040 提升 9.0 个百分点，相比 prompt reasoning 的 0.055 也提升 7.5 个百分点。τ-bench 上，Airline 从 0.120 提升到 0.260，Retail 从 0.180 提升到 0.240，显示 agentic RL 学到的是任务级工具使用策略，而不是纯粹 prompt trick。

5.4 训练曲线与误差分析

Figure 7 解读：该图给出 BFCL v3 上训练步骤与平均 reward 的关系。作者用它说明随着 RL 继续推进，模型对多轮函数调用任务的策略质量在稳步提升，尤其不是只优化某个静态分类头，而是在 rollout 层面持续变强。

Figure 8 解读：这张分析图聚焦 τ-bench 的细粒度指标，帮助解释为什么 ARTIST 在主结果上获益。作者的结论是，ARTIST 在正确工具调用总数、推理深度和多步任务完成效率之间取得了更好的平衡，因此能更稳定地完成真实对话型任务。

5.5 Ablation、局限与结论

这篇论文没有像很多系统论文那样给出大规模模块消融表，而是更多通过 process metrics、不同 benchmark、不同模型规模以及工具调用行为分析来侧面论证方法有效性。因此严格意义上，“关键组件去掉后下降多少”这类精确 ablation 数值在文中并未系统报告，相关证据主要体现在 base / prompt+tools / ARTIST 的对比，以及 response length、tool use、reward 等中间指标变化上。作者也没有系统写出独立的 limitations section。根据正文与结果可以提炼出两点客观限制。

第一，ARTIST 虽然在多数场景优于 prompt-based 工具使用，但与 GPT-4o、DeepSeek-R1 这类更大 frontier 模型相比，在函数调用任务上仍有明显差距，例如 GPT-4o 在 Airline、Retail、BFCL 三个子集上都显著更高。第二，14B 版本在 AIME 上低于 7B ARTIST，说明更大基座与 agentic RL 的组合仍存在训练稳定性或任务适配问题，当前规律还不够清晰。总体上，论文证明了一个清晰结论：把外部工具调用纳入 outcome-based RL 统一优化，可以显著提升 LLM 在复杂数学与多轮函数调用上的表现。

ARTIST 的贡献不只是提升了若干 benchmark 分数，更重要的是展示了一种从“工具接入”走向“策略化工具使用”的训练范式。