PREPING：无需任务即可构建 Agent 记忆 PREPING: Building Agent Memory without Tasks

PREPING 算法（Algorithm 1）按以下步骤执行：第 1 步，初始化 Mprop=∅、Msol=∅。第 2-12 步，对 t=1..T（本实验 T=10）轮迭代。第 3 步：Proposer Aprop 基于当前 proposer memory Mprop(t) 和文档 D 采样 N=10 个合成任务 Xt={x1..x10}。第 5 步：对每个 xit，调用 Solver Asol 在环境 E 中执行得到轨迹 τit，Solver 执行时已可访问 Msol(t)。第 6 步：Validator Aval 对 (xit, τit) 评估，得到可行性评分（feasibility 1-5）和任务完成评分（completion 1-5）及理由。第 7 步：无论可行性如何，proposer memory 更新 Mprop ← Uprop(Mprop, xit, τit, vit)；Uprop 用规则解析器抽取轨迹中调用的工具/API，结合 validator 反馈更新「实践历史视图」（含 aggregate usage summary 识别 over-practiced / under-practiced 工具）和「落地环境视图」（用 LLM 把当前轨迹观察到的实体、状态、前置条件总结为 2-5 条 bullet，供未来提案参考）。第 8-10 步：仅当 feasibility=5 时执行 Msol ← Usol(Msol, xit, τit, vit)；Usol 复用 ACE 的 reflector-curator 流水线，把任务-轨迹-validator 反馈蒸馏为 playbook 形式（strategies / code_snippets / pitfalls 三类条目），不是简单追加原始日志。validator 输出信号有两层用途：feasibility 是硬门控，completion 评分作为 reflector-curator 的「ground_truth_result」字段，让 memory 更新能区分成功/失败/部分完成轨迹。第 13 步：返回最终的 solver memory Msol 供部署期 agent 使用。

PREPING 的技术新颖性体现在三个层面：第一，双记忆非对称更新机制——Mprop 与 Msol 共享同一观察流但角色不同，前者是构造期控制状态、后者是部署期程序性记忆，所有经验更新前者但仅可行对更新后者，这种设计避免把「被拒任务、重复工具失败」等控制信号混入 playbook；第二，proposer memory 的双视图结构——实践历史视图（聚合工具使用频次、识别过/欠练习区域）解决冗余问题，落地环境视图（从轨迹抽取的具体实体与状态）解决不可行问题，二者结合使提案既广覆盖又可执行；第三，validator 的双重评分（feasibility + completion）让同一信号既能门控 memory 插入，又能引导反射器-策展人流程中的内容选择。实验上，这是首个在零目标任务经验设置下，在 AppWorld、BFCL v3、MCP-Universe 三类异构工具环境上同时验证的程序性记忆构建方法，且 cost 显著低于 ACE-Online。

独立分析的第一个弱点是 validator 的二元门控过于粗糙。当前只接受 feasibility=5 的轨迹进入 Msol（AppWorld 上仍有 16.0% 被拒），但 partial feasible 的轨迹也可能包含有价值的策略片段（如前半段对、后半段错）。改进方向是引入软门控：按 feasibility 评分加权让 partial feasible 轨迹以低权重进入 playbook，同时在 reflector-curator 中标注不确定性，避免高信心错误。第二个弱点是 proposer memory 的双视图是「对当前环境的局部观察」，缺乏跨环境抽象层——相同失败模式（如「API 返回页数不一致」）在不同 MCP 服务器上会重复学习。改进方向是引入「跨环境抽象 playbook」层作为 Mprop 的元结构，把高频通用策略（如分页循环、过滤优于拉全量）抽离出来作为下一次构造的初始化种子，类似 transfer learning 中的预训练范式。第三个弱点是 100 个合成任务的预算固定，没有依据环境复杂度自适应——AppWorld 有 250+ API，而 BFCL 函数空间小，相同 budget 在小函数空间可能冗余、大空间可能不足。改进方向是依据初次迭代的 unique tool 增长曲线动态判断何时停止构造（entropy 饱和点或 weighted recall 收敛）。第四个弱点是实验仅在 DeepSeek-V3.2、GPT-5.1、GPT-OSS-120B、Qwen3-235B-A22B 四个模型上验证，对开源小模型（如 7B/13B）下 proposer 生成任务的可行性边界没有测试，对实际部署成本敏感的场景参考有限。

作者在 Conclusion 中暗示了几个方向：一是把 pre-task memory 推广到文档噪声更大的环境，研究在缺失/不准确 API 描述下 proposer 如何退化；二是把构造期 memory 构建与在线更新更深度融合，让部署期新观察反哺 proposer memory（目前只支持反哺 solver memory）。基于论文成果还可延伸的方向包括：第一，把 PREPING 范式应用到 RL 训练数据合成——把 verifier 信号当作 RL reward，训练一个能针对新环境自动生成高质量练习任务的 proposer 模型；第二，扩展到多 agent 协作环境，让不同 agent 角色（如 challenger、critic、executor）协同构造 practice，每个 agent 的 memory 分别沉淀；第三，研究 memory 可迁移性——把构造的 playbook 蒸馏为环境无关的策略表示（如「永远先验证前置条件」），使其在新环境中作为 warm-start；第四，结合用户任务分布的先验（如用户画像、常见 query 类型）做条件化 pre-task memory，让构造期 proposal 偏向即将到来的真实任务分布。

复现评估整体良好但有一定门槛。算法层面：Algorithm 1（Sec. A.1）给出了完整伪代码（13 行），Proposer/Solver/Validator/Reflector/Curator 的所有 meta prompt 都在 Sec. A.2-A.4 中完整公布（Fig. 6-13），包含 BFCL 任务生成 prompt、validator prompt、环境信息总结 prompt、ACE reflector/curator prompt、AppWorld/BFCL/MCP-Universe 任务执行 prompt，prompt 中关键占位符（如 {environment_info_section}、{task_history_section}、{coverage_summary}）的语义也在正文明确。数据层面：三个基准（AppWorld、BFCL v3、MCP-Universe）均为开源公开数据集，AppWorld 的训练/测试 split、BFCL 的多类别划分、MCP-Universe 的四个类别都直接可用。模型层面：实验用 DeepSeek-V3.2（非推理模式）、GPT-5.1、GPT-OSS-120B、Qwen3-235B-A22B 四个模型，已在 Table 4 验证可迁移性；成本按 DeepSeek-V3.2 价格（输入 cache hit $0.028/M、cache miss $0.28/M，输出 $0.42/M）公开。算力层面：作者声明「全部使用 API 推理、无本地 GPU 训练」，主要成本是 token；Table 12 给出了精确的 USD 拆分（Gen/Val/Syn solve/Mem update/Eval solve），AppWorld 总构造+评估成本约 $10、BFCL 约 $6.5。复现难度中等偏低：最大障碍是 100 任务×3 轮重复运行的 API 调用成本（约 $30-50/benchmark），以及需要在 DeepSeek-V3.2 上维持非推理模式的稳定行为。代码仓库链接未在正文给出（论文标注「Project page」但未直接附 URL），需要查作者主页（KAIST）获取。整体而言，工程上 1-2 名研究员配 API 预算可在 1-2 周内复现主表，构造 ablation 与 prompt 工程可能再加 1-2 周。