AgenticSTS：长周期 LLM Agent 的"有界记忆"测试平台

  • 关联论文：2607.02255
  • 作者：spark
  • 更新：2026-07-23

一句话结论

提出一种 bounded-memory contract（有界记忆契约）：每次决策都基于一条由"类型化检索"组装出的"新鲜"用户消息，不再追加跨决策的原始历史，从而在 Slay the Spire 2（杀戮尖塔 2）这一长周期决策游戏中对 LLM Agent 的各记忆层做可隔离消融（A0 固定对照），并开源 298 条带条件标签的轨迹与完整分析脚本。

解决的真问题

"长周期 LLM Agent 的记忆该怎么设计"是 2025-2026 年最被热烈讨论、也最缺乏可复现实验的问题之一。当下的主流做法是 accumulating-context：把过去的观察、工具调用、反思统统拼到 prompt 里。问题有三：

  1. 混杂难归因：所有记忆形式被塞进同一个上下文，要回答"哪类记忆有用、哪类是噪声"，无法做干净消融；
  2. 成本与延迟爆炸：长 prompt 直接抬升 token 成本与推理延迟；
  3. 评测失真：一旦 prompt 长度随回合数增长，不同模型、不同回合数的对比就不可比——你分不清是模型能力差异还是上下文容量差异。

AgenticSTS 把这三件事一次性治了：用一份契约把"上下文大小"恒定下来，从而所有变量（memory 层、skill 层、检索策略）可以被独立消融。

核心方法

3.1 Bounded-memory contract（核心契约）

  • 定义：每一次决策的 prompt 是从零组装的，基于当前用户消息 + 类型化检索结果，不追加任何跨决策的原始 transcript。
  • 效果：
  • 任何回合的 prompt 长度都恒定在某个上限；
  • 任一记忆层都可以单独打开/关闭，互不干扰；
  • 跨回合、跨模型的对比"更干净"。

3.2 测试环境：Slay the Spire 2

  • 选择理由：闭合规则的随机化卡牌构筑游戏，一局需要数百次战术与战略决策；
  • 环境属性：状态空间巨大、随机性高、回合间强耦合——典型的长周期任务；
  • 既有基线：公开的前沿 LLM 在线基准在该游戏最低难度"全配置 0 胜率"；开发者公开的人类胜率约 16%——难度合适但未饱和。

3.3 实验设置

  • A0 固定消融：在契约框架内，把"触发的策略性 skill"这一层打开/关闭作单变量对比；
  • 结果：
  • no-store baseline：3/10 胜；
  • + skill layer：6/10 胜；
  • 统计性：在样本量 n=10 的情况下，Fisher exact p ≈ 0.37——差异方向性可观察但不具统计决定性。论文明确把这标注为"directional rather than statistically decisive"。
  • 跨骨架对照：报告了不同 LLM backbone 上的表现，作为 operational comparison 而非受控变量。
  • 公开基线：与 accumulating-context 公开基线做横向对比。

3.4 方法论贡献

论文的真正贡献不只一个分数，而是：

  1. 契约本身——bounded-memory 是一种 Agent 工程模式；
  2. 消融纪律——A0 固定、单变量对照、明确声明统计力不足；
  3. 可复现资产： - 298 条已完成轨迹，每条带条件标签； - 冻结的 memory / skill snapshot； - 完整 prompt 记录； - 分析脚本。

这些资产使后续研究者能直接复用同一个测试床，验证自己的记忆设计。

3.5 关键伪代码

Contract (Bounded-Memory):
  At each decision step t:
    msg_t = assemble(user_message_t,
                     typed_retrieve(t, MEMORY_LAYERS, SKILLS, SUMMARIES))
    # 注意：msg_t 不包含跨 t 的原始历史
    a_t = LLM.decide(msg_t)
    env.step(a_t)
    store_update(MEMORY_LAYERS, env.transition)

# 消融示例（A0 = fixed）：
  cfg_A = {memory: ON,  skill: OFF}
  cfg_B = {memory: ON,  skill: ON }
  wins_A, wins_B = run_game(cfg_A, n=10), run_game(cfg_B, n=10)

亮点

  1. 方法学价值 > 分数价值：在 Agent 评测普遍"叙事驱动、统计薄弱"的当下，明确承认 p≈0.37 并标注为 directional，是少见的诚实做法。
  2. prompt 长度恒定：解决了 Agent 评测里最隐蔽的混杂变量——上下文长度。
  3. 任务选得好：Slay the Spire 2 同时具备"高决策密度 + 强随机性 + 闭合规则"，是非常合适的 Agent 评测场。
  4. 可复现资产完整：298 条轨迹 + 冻结 snapshot + 脚本，等价于一个小型 benchmark。
  5. 与公开基线严格对比：能在同一个游戏上做"b 契约 vs 累积上下文"的横向比较。
  6. 跨骨架对照：不止一个 LLM，结论不局限于某一家。

局限

  1. 样本量小：n=10 的胜率对比难以支撑"显著优势"的强结论；论文自己承认这一点。
  2. 单任务单游戏：在 Slay the Spire 2 上的结论未必能迁移到工具调用类、网页 Agent 类任务——契约的迁移性需要进一步验证（原文未明确）。
  3. bounded-memory 是否真的"更好"未证：论文呈现的是 可消融性 的方法学优势，而非绝对意义上的"胜率优势"；公开 LLM 在该游戏仍是 0 胜，b 契约并没有"解决"这个游戏。
  4. 人类胜率 16% 与 Agent 6/10=60% 的对比看起来"超越人类"，但人类胜率是开发者自报，未必可与 10 次实验同口径（原文未明确人类胜率的口径细节）。
  5. 依赖 typed retrieval 的设计：契约把"原始历史不追加"换成"类型化检索"，但检索器的设计与质量本身就是一个新引入的变量，论文未在 abstract 给完整消融（原文未明确）。
  6. 零被引：2026-07 新工作，尚未被独立复现。

对工程落地的启发

  • Agent 架构层面：用"契约"代替"清单"来设计记忆——让 prompt 长度有界，让成本可预测，让消融可做；
  • 评测纪律：承认样本量限制、用 directional 而非 significant 表述结论，是工程与研究都该学的诚实做法；
  • 资产复用：298 条带标签轨迹是稀缺资产——企业内部 Agent 灰度时也可借鉴这种"轨迹 + 标签 + 冻结快照"的发布模式；
  • 任务选择：用闭合规则 + 高随机性 + 长决策链的游戏作为 Agent 评测场，比单一 QA 任务更能反映真实部署；
  • 避免累积上下文陷阱：当 Agent prompt 已经超过几万 token 时，工程上几乎可以确定"信噪比"是下降的——bounded-memory 是更稳的选择。

与同方向工作的关系

  • 长上下文 / RAG for Agents（如 MemGPT、MemoryBank、A-Mem 等）：这些工作尝试"在累积上下文之上加结构化记忆"，AgenticSTS 的契约提供一种对立的工程哲学——拒绝累积、靠检索重建；
  • Agent 评测基准（如 AgentBench、GAIA、SWE-bench）：偏向"任务完成度"打分；AgenticSTS 更偏架构层面的消融，与上述评测正交，可叠加；
  • Slay the Spire / NetHack / Crafter 等游戏环境：传统 RL 评测场；AgenticSTS 是把 LLM Agent 拉进这些环境、并解决评测可复现性的一个具体实例；
  • 过程监督 / 反思类工作（Reflexion、Self-Refine 等）：可作为 AgenticSTS 中"skill 层"的具体实现候选；
  • Memory-as-Contract 视角（关注 prompt 上限与契约式约束）：AgenticSTS 是这一视角的代表案例。

适合谁读

  • 做 Agent 架构、记忆系统、长期任务规划的工程师与研究者；
  • 关注 LLM Agent 评测方法学、benchmark 设计的同学；
  • 想把游戏 / 决策类环境用作 Agent 评测场的研究者；
  • 对 prompt 工程成本控制感兴趣的产品 / 平台同学。

不确定处

  • "typed retrieval" 中"type"的具体分类（如 observation / reflection / summary / skill）与检索器实现细节，原文未在 abstract 给出；
  • 跨骨架对照里具体用了哪些 LLM、各自版本与价格，原文未明确；
  • 与公开 accumulating-context 基线的具体胜率差，原文未明确；
  • 人类胜率 16% 的口径（玩家样本、自报数据 vs 统计）原文未明确；
  • 298 条轨迹的多样性（不同卡组、不同决策风格覆盖度）原文未明确。

工程落地与核查（Jay）

1. 契约模式向生产 Agent 的迁移路径

AgenticSTS 的 bounded-memory contract 本质是拒绝累积上下文，改用类型化检索重建。这在工程上有两种落地路径：

路径 A：纯检索（Retrieval-only） - 每轮决策只带当前状态 + 检索到的记忆/技能片段 - 优点：prompt 长度严格有界，延迟可预测 - 缺点：检索质量是瓶颈，漏检关键历史会致命

路径 B：分层缓存（Layered Cache） - 最近 N 轮完整历史保留在 KV cache 中（作为"短期记忆"） - 超过 N 轮的提炼为检索片段（作为"长期记忆"） - 优点：平衡了召回与成本 - 缺点：缓存失效逻辑需要仔细设计

工程行动：先在目标 Agent 场景上测量现有 accumulating-context 的实际 token 增长率，判断"在哪个时间点 prompt 开始显著影响质量"。该拐点是决定是否切换到契约模式的关键指标。

2. Typed Retrieval 的类型分类——需要明确设计

论文在 abstract 中提到 typed retrieval，但具体 type 体系未在摘要中给出。在工程实现时必须先定义清楚：

可能的 type 体系示例：

observation  # 当前环境的直接感知（卡牌、状态）
reflection   # 对历史的反思/总结
skill        # 专家规则或工具使用策略
summary      # 对长链互动的压缩摘要
goal         # 当前目标/子目标状态

关键工程问题： - 每个 type 的检索向量是否分开建立？ - 同一时刻不同 type 的检索结果如何加权合并？ - 某些类型（如 skill）是否总是被检索，而其他类型可按需触发？

建议在实现时参考 MemGPT 的分层记忆思路，但把"层"替换成"type"，使每类记忆的更新策略独立可控。

3. Slay the Spire 2 的工程复现门槛

Slay the Spire 2 是一个商业游戏，不是开源环境。这带来了一个关键工程障碍：

  • 游戏 API 获取：需要通过非官方 API 或逆向获取游戏状态，部署门槛高
  • 自动对战接口：论文说"instrumented"了这个游戏，但没有明确是否提供了公开的自动化接口

替代评测环境建议（工程迁移时考虑）： | 环境 | 类型 | 特点 | 可替代性 | |------|------|------|---------| | NetHack | 开源游戏 | 高随机性、强耦合，与 STS2 相近 | 高 | | Crafter | 开源游戏 | 决策密度中等 | 中 | | MiniWoB++ | 浏览器任务 | 短周期，不适合长周期评测 | 低 | | ToolEmpo / GAIA | 工具调用 | 真实感强，随机性低 | 中 | | 定制客户支持模拟 | 垂直领域 | 贴近生产，但需自建 | 高 |

工程行动：298 条轨迹是核心资产——优先基于这批轨迹做离线分析和记忆消融实验，而不是在短期内投入工程资源去自动化 Slay the Spire 2。

4. 6/10 胜率的统计不确定性——实验设计建议

p ≈ 0.37 意味着 skill layer 的开关对胜率的影响方向性存在但不具统计显著性。在工程验证时：

  • 不要把 6/10 当成确定性结论——在 n=10 的规模下，运气成分不可忽视
  • 需要的最小样本量：若想以 80% power 检测出 30% 绝对胜率差（3/10→6/10），至少需要 n≈40
  • 验证方法：在企业内部复现时，应设计至少 30-50 局来确认 skill layer 的真实贡献
# 统计检验建议
from scipy.stats import fisher_exact
# n=40 下的期望
table = [[3, 7], [6, 4]]  # 假设 cfg_A: 3胜/7负, cfg_B: 6胜/4负
oddsr, p = fisher_exact(table)
print(f"Odds ratio: {oddsr:.2f}, p={p:.3f}")  # 预期 p < 0.05

5. 298 条轨迹的复用框架

298 条带标签轨迹是这篇论文最直接可用的工程资产，建议这样复用：

阶段 1：离线记忆消融（立即可做） - 直接在轨迹数据上模拟不同的 retrieval policy - 不需要跑实际游戏，在日志级别做 controller-in-the-loop 即可

阶段 2：轨迹 + 真实环境混合验证（小规模） - 用少量真实游戏局验证离线结论是否迁移到在线

阶段 3：生产场景适配（按需） - 把 STS2 的 type 体系（card history、deck state、enemy intent）映射到目标领域的 entity types - 例如：客服 Agent 可以定义 conversation_history、product_knowledge、policy_rule 等类型

6. 人类 16% 胜率的口径问题

原文未明确"人类胜率 16%"的数据来源： - 是开发者自报的内部测试？ - 还是社区玩家的平均胜率？ - 玩家样本量是多少？是否有统计置信区间？

这是一个典型的「苹果比橘子」比较：10 次实验的 Agent 胜率 vs 大量玩家的长期统计胜率，粒度完全不同。工程验证时建议：

  • 收集同样本量的人类玩家胜率（例如让 10 位开发者各打 10 局）
  • 或者只比较「开发者自报胜率」与「Agent 单局胜率」作为定性参考

7. 核查清单

  • [ ] arXiv 2607.02255 摘要核实 ✅（bounded-memory contract、Slay the Spire 2、16% 人类胜率均与原文一致）
  • [ ] 298 条轨迹的实际规模与多样性：需查正文 Section 3
  • [ ] typed retrieval 的具体 type 分类：需查正文 Section 2/3
  • [ ] skill layer 贡献的统计显著性：需 n≥40 验证
  • [ ] Slay the Spire 2 自动化接口的可用性：需查论文或 GitHub repo
  • [ ] 人类 16% 胜率的数据口径：需论文补充或联系作者
  • [ ] accumulating-context 基线的具体配置（prompt 长度、记忆策略）：需查正文对比实验