TL;DR

本文核心观点：

  1. PROGRA 精准命中了 Agent 落地的核心痛点 — 真实业务场景（客服、订单处理）需要多轮交互，现有方案在多轮场景下经常「忘了前面做到哪了」
  2. 两阶段训练框架将进度感知显式融入 RL — PAG 自动构造进度感知数据，模型先形成「当前进度」表示，再决定下一步动作
  3. 「先想清楚再动手」的设计哲学 — 在理解进度和决定动作之间加入显式思考层，将两个认知步骤解耦，显著提升复杂工具链路的稳定性
  4. 获 ACL 2026 SAC Highlight Award — 社区认可「多轮交互中的状态感知」是 Agent 从 demo 走向生产的关键瓶颈

一个被 benchmark 掩盖的问题

大家在讨论 Agent 能力的时候，大多数 benchmark 都是单轮任务：写一段代码、回答一个问题、生成一篇文章。

这些 benchmark 夸大了 Agent 的真实能力。

真实业务场景——机票改签、旅行规划、客服对话、审批流程——都是多轮交互，每轮涉及不同的工具调用和信息确认。前一轮的输出，可能是后一轮的输入。

Agent 在 benchmark 上表现得好，不等于在多轮场景下表现得好。恰恰相反：在单轮场景下表现越好的 Agent，在多轮场景下可能越容易迷失——因为它被优化得太擅长「即时反应」，而不是「持续追踪任务状态」。

PROGRA（ACL 2026 SAC Highlight Award）精准地指出了这个 gap，并给出了一个结构化的解法。

问题根源：端到端模式的固有缺陷

现有大多数 Agent 是「端到端」模式：

输入：冗长的上下文（包含历史对话、历史工具调用结果） 输出：下一个函数调用

这个模式的问题在于：上下文越长，模型越容易在中间某个位置迷失。

比如一个五步的客服对话：

  1. 用户说「帮我改签机票」→ 调用 get_booking()，返回航班信息
  2. 用户说「改成后天」→ 调用 search_flights()，返回可选航班
  3. 用户说「选第二个」→ 调用 change_flight()，返回新预订信息
  4. 用户说「还要改座位」→ ?

第四步的问题在于：用户说「还要改座位」时，Agent 需要知道是改哪张机票的座位（当前进行中的那笔改签订单）。但如果上下文很长，或者中间有其他并行操作，Agent 可能张冠李戴。

这是「状态追踪」问题，不是「工具选择」问题。传统端到端模式无法显式建模「当前任务的进度」。

PROGRA 的两阶段框架

PROGRA 提出了两阶段训练框架，专门解决多轮函数调用中的进度感知问题：

第一阶段：Progress Awareness Generation（PAG）

自动构造高质量的进度感知训练数据。

核心是教会模型在每步行动前先总结两件事：

  • 历史摘要：已经发生了什么（任务进度追踪）
  • 未来计划：接下来还需要做什么（目标维护）

这两个总结不是给人类看的参考信息，而是模型生成下一步动作之前必须完成的显式思考步骤。

PAG 自动构造的数据包含：原始多轮对话轨迹 → 插入历史摘要和未来计划 → 形成新的训练样本。模型在这个过程中学会把「冗长上下文」压缩为「紧凑的任务状态表示」。

第二阶段：PAG-RL

将进度感知显式融入多轮强化学习。

与标准 RL 不同，PAG-RL 的奖励信号不仅包括任务是否完成，还包括：

  • 进度表示的准确性
  • 历史摘要与实际历史的一致性
  • 未来计划与最终目标的相关性

这让模型在连续交互中学会：不只是调用正确的工具，还要知道当前在整个任务链条中的什么位置。

核心洞察：「先想清楚再动手」

PROGRA 最启发性的设计哲学，是把「理解进度」和「决定动作」这两个认知步骤显式解耦。

传统 Agent：看到上下文 → 直接输出动作（端到端）

PROGRA：看到上下文 → 先形成任务状态表示（历史摘要 + 未来计划） → 再决定下一步动作

「先想清楚再动手」这个原则，在人类认知里是有充分证据支撑的。System 2 thinking 的核心就是：先分析，再决策。

对 Agent 来说，这个设计的好处是：

  • 状态表示是压缩的，不随对话轮数线性增长
  • 进度感知是可检验的，可以单独评估历史摘要的准确性
  • 错误可定位，如果任务失败，可以检查是哪一步的进度判断出了问题

ACL 2026 SAC Highlight 的意义

ACL 是自然语言处理领域的顶会， SAC Highlight Award 是高级别论文奖，表彰在特定方向上有显著突破的工作。

PROGRA 获奖说明：多轮交互中的状态感知，已经成为 Agent 从 demo 走向生产的公认瓶颈。

在此之前，学术界和工业界的关注点都在单轮工具调用能力—— function calling benchmark、tool use accuracy。但 PROGRA 和它获得的认可，把社区的注意力拉向了另一个方向：

单轮能力是必要条件，多轮状态追踪才是充分条件。

迁移到企业级场景

PROGRA 的框架思路可以直接迁移到以下企业级多轮任务场景：

客服对话：用户请求复杂业务操作（报修 + 改预约 + 退款），Agent 需要在多轮中追踪当前处理到哪一步、哪些子问题已解决、哪些还需要继续。

订单处理：用户说「帮我取消上个月的订单，顺便看看有没有优惠」——两个子任务，优先级不同，Agent 需要知道「取消」进行到哪一步、「查优惠」可以并行还是必须串行。

审批流程：多级审批、跨部门协调，Agent 需要追踪每级的状态、哪级已通过、哪级被拒绝、拒绝原因是什么。

这些场景的共同点是：任务不是单轮完成的，但 Agent 必须像一个连续执行的人一样，保持对进度的感知。

局限与开放问题

PAG 数据构造的质量：PAG 自动构造的进度感知数据，是否能覆盖真实世界的全部任务类型？如果某些任务类型没有被覆盖，模型在这些类型上的进度感知能力可能是空白的。

推理成本：在每轮调用前都生成历史摘要和未来计划，会增加 token 消耗。对于极长对话（比如 50 轮以上的客服对话），这个成本可能需要权衡。

与其他框架的组合：PROGRA 解决了进度感知，但 MIA 解决了记忆进化，Strat-Reasoner 解决了战略推理——这三个方向并不互斥，组合起来可能是更完整的 Agent 能力框架。

写在最后

PROGRA 回答了一个看似简单但极其重要的问题：

Agent 怎么知道自己做到哪了？

不是靠记住所有历史上下文——那是存储，不是认知。

是靠形成任务状态的压缩表示——这是一个认知操作，需要被显式训练。

「进度条」这个比喻很贴切：人类在完成任务时，心里有一个进度条，知道已经完成多少、还剩多少。给 Agent 装上这个进度条，是它从「反应式工具」走向「主动式助手」的关键一步。

论文链接：待补充（ACL 2026）

AI-Native Engineering 系列 深度阅读时间：约 10 分钟