智能体学习其运行时：解释器持久性作为训练时语义

摘要

工具增强的 LLM 越来越多地被部署为将自然语言推理与可执行的 Python 操作交织在一起的代理，就像在 CodeAct 风格的框架中一样。在部署中，这些代理依赖于跨步骤持续存在的运行时状态。相比之下，常见的训练管道将代理跟踪视为token序列，并隐含执行语义。这就提出了一个以数据为中心的问题：状态持久性仅仅是一个推理时间支架，还是当训练数据公开相应的执行语义时模型可以学习利用它？我们将状态持久性隔离为训练时间变量。我们引入了 Opaque Knapsack，这是一种程序生成的部分可观察优化任务系列，旨在防止一次性解决方案。项目属性和约束隐藏在预算工具调用后面，强制进行多轮控制流和迭代状态修订。保持任务实例、提示、工具、模型和监督固定，我们生成配对轨迹，其区别仅在于解释器状态是否跨步骤持续存在或在每个操作后重置。然后，我们在每个跟踪变量上微调相同的基本模型 (Qwen3-8B)，并评估所有四种列车运行时组合。我们的 2x2 交叉评估表明，执行语义主要影响代理如何获得解决方案，而不是它们是否这样做：解决方案质量在统计上在不同条件下是无法区分的，但token成本和稳定性却有很大差异。无状态运行时中的持久训练模型会在大约 80% 的情节中触发缺失变量错误；持久运行时中的无状态训练模型会使用大约 3.5 倍的token冗余地重新导出保留状态。解释器持久性应被视为代理跟踪的一流语义。将微调数据与部署运行时保持一致可以提高效率并减少脆弱的列车运行时不匹配。

智能体学习其运行时：解释器持久性作为训练时语义 — 图1：解释器持久性作为工具增强型智能体的一种执行语义。（上）Opaque Knapsack 将物品属性与可行性约束隐藏在一个带预算限制的工具API之后，迫使进行多轮检查与计划修订，而非一次性的单发脚本。（下）同一任务实例在两种部署运行时下的示例rollout。在持久解释器下（左），先前动作定义的变量保持存活，智能体可以跨轮次积累并复用可执行状态（例如 items、inspect_data）。在无状态解释器下（右），每一步之后全局变量被清空而文本历史保留；在持久性下训练出的策略仍可能引用先前的绑定，导致变量缺失（NameError）错误与代价高昂的重构循环。我们在一个受控的 2 × 2 2{\times}2 研究中量化这些行为对训练–运行时对齐的依赖（持久 vs. 无状态轨迹 × \times 持久 vs. 无状态运行时）。