超越下一个词元预测：面向Atlassian工作流程中工具使用智能体的RLVR概念验证

# 超越下一个词预测：针对 Atlassian 工作流的工具使用代理的 RLVR 概念验证  
来源：https://arxiv.org/html/2607.01465  

## 超越下一个词预测：针对 Atlassian 工作流的工具使用代理的 RLVR 概念验证（2026）  

###### 摘要。大型语言模型被训练来预测下一个词，而不是在某个特定 API 内行动。在利基企业 SaaS 工作流中——成功意味着以正确的顺序、带正确的嵌套参数命中正确的端点——这种目标不匹配表现为静默失败：遗漏必填字段、幻觉工具、或者在单次读取后提前停止。我们探究直接在目标环境中应用带可验证奖励的强化学习（RLVR）是否能弥合这一差距。作为概念验证，我们构建了一套五个合成环境，以模式保真度模拟 Jira REST v3 和 Confluence v2 API；奖励完全从工具调用轨迹计算得出，无需实时 API、无需学习评判器、无需人工标注。在驱动 GRPO 训练的相同检查器上对 Qwen3-1.7B 和 Qwen3.5-4B 进行评分，我们发现，在奖励非退化的四个场景中，RL 训练的策略将平均奖励从 4B 基线的 0.35–0.92 范围提升到 0.95–1.00，其中单个最大增益出现在 Confluence 页面创建（0.35→1.00）。我们将此定位为针对利基企业 API 的、以结果优化的小模型的第一步，并强调会议读者应权衡的两个局限性：手工艺可验证奖励无法扩展到此处报告的少数端点之外，而我们的五个场景之一（工单流转）的奖励形状已经饱和，被提示的 4B 已经达到了最大值。  
强化学习、工具使用、可验证奖励、GRPO、合成环境、代理评估、Jira、Confluence  
††版权：无  
††会议：KDD 2026 AI 代理研讨会；2026年8月；  
††期刊年份：2026  

用户提示（6–12 / 场景）→ Qwen3 策略（1.7B / 4B, BF16）→ 合成 API（Jira v3 + Conf v2）→ 工具调用轨迹（调用 + 参数）→ 可验证奖励（R1 参数 + R2 顺序 + R3 惩罚）→ GRPO 更新（组相对）→ 工具调用、响应、标量奖励、参数更新  

图 1. RLVR 训练循环。用户提示进入 Qwen3 策略，该策略将工具调用发射到 Jira REST v3 / Confluence v2 API 的、模式保真的合成副本中；生成的工具调用轨迹由手工设计的可验证奖励（每个参数的正确性、验证—修改—验证的结构性奖金、幻觉和超额调用惩罚）评分；GRPO 根据每个提示的 rollout 组更新策略。循环中没有实时 API、学习评判器或人工标注。  

一个由五个框组成的水平流程：用户提示、Qwen3 策略、合成 API、工具调用轨迹、可验证奖励。奖励将标量反馈给 GRPO 更新框，该框将参数更新发送回 Qwen3 策略，形成闭环。  

## 1. 引言  

由 LLM 驱动的代理正在从聊天转向工作流：开单、流转问题、更新 wiki。越来越多的文献将工具调用视为需要通过监督微调或在真实 API 上进行 RL 来激发的一流能力（Qin 等，2024；Schick 等，2023；Wang 等，2024；Yao 等，2023），然而面向代理的公开 RL 基准测试针对的是开放网络（Zhou 等，2024）、软件工程（Jimenez 等，2024）或广泛的代理套件（Liu 等，2024；Trivedi 等，2024）。利基企业 SaaS 工作流——狭窄、模式密集、以“检查资源然后修改它”的模式为主——相对较少受到关注。更深层次的问题是目标不匹配：LLM 针对互联网规模文本的下一个词似然进行优化，而不是在特定的 API 表面内行动。在我们的套件中，当要求创建 Jira 子任务或 Confluence 页面时，被提示的 Qwen3.5-4B 知道调用的大致形状，但填错槽位、遗漏必填字段，或者在第一次读取后就停止——这些行为在词预测目标下看起来流畅，但在任何将输出与环境进行验证的检查下得分都很低（我们第 6 节中的提示基线分数证实了这一点）。  

带有可验证奖励的强化学习（RLVR）（Cobbe 等，2021；DeepSeek-AI，2025；Lambert 等，2024；Shao 等，2024）放弃了奖励建模，转而采用程序化检查器，只要正确性可被检查。工具使用天然适合这种做法：代理的输出是一系列结构化的工具调用，其参数值和顺序可以直接检查。我们利用这一观察结果，在目标环境的合成副本中针对结果级奖励训练代理，全程无需实时 API、学习评判器或人工标注。  

#### 贡献。我们呈现了一套五个合成、模式保真的 Atlassian 环境、对它们评分的可验证奖励、在同一奖励上的提示基线，以及端到端的 RL 训练结果。具体来说：  

- • **环境**：模拟 Jira REST v3 和 Confluence v2 端点，这些端点用于常见的自动化流程（问题读取/创建、页面读取/创建、流转、标签），具有有状态的父–子约束和每批次重置（第 3 节）。  
- • **可验证奖励函数**：分解为每个参数的正确性、对验证–修改–验证模式的结构性奖金，以及对幻觉或重复调用的惩罚——全部可从工具调用轨迹计算（第 4 节）。  
- • **提示基线**：对 Qwen3-1.7B 和 Qwen3.5-4B，通过 HuggingFace 推理路由器运行，针对与训练时相同的奖励检查器（第 6 节）。  
- • **端到端 RLVR 训练配方**：使用 GRPO（Shao 等，2024）对 Qwen3 模型（Yang 等，2025）通过 TRL（von Werra 等，2020）进行训练，并带有基于收敛的早停回调（第 5 节），在数十到数百个生成批次中达到每个非退化场景的平均奖励 ≥0.95，并在模式密集型创建任务上产生对提示 4B 基线最大的绝对提升（例如，Confluence 页面创建提升 +0.65）。  

结果是一个概念验证：该配方在这个廉价的底板上有效，而第 7 节强调了它尚未确立的内容——主要是手工制作的可验证奖励无法扩展到完整的 Atlassian 公共表面，并且我们的五个场景之一具有饱和的奖励形状，提示的 4B 已经达到了最大值，我们将其保留为透明控制而非标题性声明。  

## 2. 相关工作  

#### 工具使用代理。Toolformer（Schick 等，2023）和 ToolLLM（Qin 等，2024）训练模型调用真实 API；ReAct（Yao 等，2023）和 CodeAct（Wang 等，2024）将推理与行动交织。这些工作证明了 LLM 可以使用工具，但主要依赖于监督数据；我们专注于 RL 阶段以及避免实时调用的训练时环境。  

#### 带可验证奖励的强化学习。DeepSeek-R1（DeepSeek-AI，2025）、DeepSeekMath（Shao 等，2024）和 Tülu 3（Lambert 等，2024）表明，程序可检查的奖励能驱动强大的推理增益，主要集中在数学和代码领域。同时期的工作将配方扩展到工具使用和代理设置：ToolRL（Qian 等，2025）认为奖励设计是工具使用 RL 的承重部分，而 Agent-RLVR（Da 等，2025）使用环境奖励和指导训练软件工程代理。我们的贡献属于同一方法家族，但环境与奖励设计针对的是不同的表面：狭窄的企业 SaaS API，其中验证器检查嵌套参数值和调用顺序而不是最终的数字答案，延迟在亚秒级，并且训练循环中没有实时 API。  

#### 代理基准测试与合成世界。WebArena（Zhou 等，2024）、AgentBench（Liu 等，2024）和 SWE-bench（Jimenez 等，2024）在渲染的网页和真实的 GitHub 仓库上评估代理。AppWorld（Trivedi 等，2024）和 ToolSandbox（Lu 等，2024）提供了跨许多应用的有状态合成世界。我们的工作在表面范围上更窄，但为训练量身定制：每个奖励信号从工具调用轨迹以亚秒级延迟计算，环境仅用几百行 Python 代码实现，适合 RL 的内循环。  

## 3. 环境设计  

### 3.1. 设计原则  

环境针对以下四个属性：  

#### (P1) 模式保真度。工具签名和响应载荷镜像公开的 Jira REST v3 和 Confluence v2 合约（例如，POST /rest/api/3/issue 期望 fields.project.key、fields.parent.key 和 fields.issuetype.id="10003" 用于子任务），因此在此训练的模型说与其实时对应物相同的连线格式。  

#### (P2) 有状态但可重置。每个环境暴露一个可变的资源池（问题、页面），使得 create_* 调用的副作用可被后续的 get_* 调用观察到；在每次奖励计算之前调用 reset_synthetic_data() 挂钩以恢复初始状态，防止跨 rollout 的状态污染。  

#### (P3) 确定性。环境中没有随机性：相同的工具调用序列产生相同的响应。这使得奖励分配精确，且底板可作为回归测试夹具。  

#### (P4) 可验证性。每个提示的 ground-truth 解决方案是一个小的期望参数值字典，因此奖励函数永远不需要调用 oracle LLM 或访问实时服务。  

### 3.2. 场景  

我们实例化了五个场景，涵盖 Jira、Confluence 和跨产品（表 1）。所有场景共享一个共同的交互模式：用户提示按键名指定一个资源，代理应验证该资源存在，通过写调用改变状态，并可选择通过最终读取验证结果。  

表 1. 合成 Atlassian 套件的场景。工具通过 OpenAI 兼容的函数调用接口暴露给模型；合成数据层为每个场景持有 6–12 个提示，并附有手工编写的 ground-truth 参数。

| 场景 | 工具 | 提示数量 | 黄金参数 |
|------|------|----------|----------|
| 工单流转 | get_issue, transition_issue | 6 | 1 |
| 子任务创建 | get_issue, create_issue | 8 | 5 |
| 页面创建 | get_page, create_page | 8 | 4 |
| 页面标签 | get_page, set_label, get_page (验证) | 12 | 每个标签 |
| 跨产品 | get_issue, get_page, create_issue, create_page | 6 | 9 |

### 3.3. 示例任务  

每个场景一个用户提示，直接取自训练集：  

- • **工单流转**：“请解决工单 ISK1。”  
- • **子任务创建**：“在 ABC-123 下创建一个子任务‘编写 QA 测试用例’，并分配给 admin123。”  
- • **页面创建**：“在空间 PAY 的父页面 789 下创建一个页面‘Oncall Runbook - Payments’。”  
- • **页面标签**：“你能正确标记页面 10001 吗？”  
- • **跨产品**：“在 ABC-123 下创建一个子任务‘编写发布说明’，并分配给 admin123。同时在空间 PAY 的父页面 789 下创建一个 Confluence 页面‘发布说明 1.0’。”  

在跨产品场景收敛时，代理读取命名的父问题和父页面，然后发出两个创建调用，带有正确的嵌套参数；奖励函数（第 4 节）为每个正确参数和读前写后的顺序分配信用。收敛后的工具调用序列在附录 A（列表 3）中重现。  

## 4. 可验证奖励函数  

对于每个场景，我们手工设计了一个密集奖励函数，将 rollout 中的工具调用列表映射到 [0,1] 中的标量。奖励分解为三个加性组：  

#### (R1) 每个参数的正确性。对于黄金字典中的每个期望参数，如果代理发出的参数匹配，则授予一个小的常数（跨产品奖励中为 0.10；单一产品创建奖励中为每个槽 0.10–0.15）。这是主要信号：例如，在子任务场景中，五个字段（summary、parent.key、project.key、assignee、issuetype.id）各贡献 0.10，正确性上限为 0.50。对于 Confluence 页面标签，R1 改为每个标签的召回项：代理最终添加的每个黄金标签得 0.10（表 1）。  

#### (R2) 结构性奖金。我们奖励验证–修改–验证模式：在任何 create_* 调用之前有一个 get_* 调用，然后是正确写入，最后是一个可选的 get_* 以确认创建。跨产品奖励为每个步骤奖励 0.05；单一产品创建奖励将这些调得更高（通常每个步骤 0.05–0.20），以便当每个参数的上限较小时，孤立的结构信号仍能驱动学习。奖金由每个平台的“有效状态”谓词门控，因此如果没有产生可用的修改，就无法获得奖金。  

#### (R3) 惩罚。我们对那些在真实 API 中会成本高昂或具有破坏性的行为进行扣分：缺失必需的 create_* 调用、无效载荷形状、重复创建、幻觉工具名称，以及超出每个场景预算的过多调用次数。惩罚幅度按场景调整（例如，跨产品奖励中缺失创建扣 -0.25，子任务奖励中扣 -0.30）；跨产品的值列于表 2。最终奖励被钳位到 [0,1]。  

表 2 分解了最复杂的跨产品奖励；单一产品奖励遵循相同的 R1/R2/R3 模板，具有每个场景的幅度，而工单流转是已知的异常值（第 7 节）。  

表 2. 跨产品奖励分解。钳位前的最大正预算为 1.35；在钳位到 [0,1] 之前减去惩罚。

| 组件 | 值 |
|------|-----|
| Jira 每个参数正确性（5×0.10） | 0.50 |
| Confluence 每个参数正确性（4×0.10） | 0.40 |
| Jira 结构：创建前读取、创建后验证 | 0.15 |
| Confluence 结构：创建前读取、创建后验证 | 0.15 |
| 跨平台完成奖金（两者门控） | 0.15 |
| 缺少 create_issue/create_page | 各 -0.25 |
| 无效的 Jira / Confluence 载荷 | 各 -0.25 |
| 重复的 create_issue/create_page | 各 -0.15 |
| 幻觉工具名称 | 各 -0.15 |
| 超出预算的额外调用（>6） | 各 -0.05 |

## 5. 训练设置  

我们训练 Qwen3-1.7B（Yang 等，2025）（工单流转）和 Qwen3.5-4B（Qwen Team，2026）（其余场景）。训练使