AT-AT：基于智能体轨迹的自动工具优化

1. 问题与价值

这篇论文解决的核心问题是：当多个 LLM 智能体共享同一套工具（API、MCP server）时，如何在不修改任何智能体本身的前提下，自动改进这套共享工具，从而提升所有使用它的智能体的任务成功率。

问题的重要性来自一个现实约束：在企业环境中，工具通常由提供方维护，而调用这些工具的智能体由不同的团队或用户控制。工具提供方无法修改那些智能体的模型、提示词或执行框架，但任何对工具的改动会自动到达所有调用者。这构成了一个“环境侧学习”的入口。

论文提出的机制叫 feedback shaping（反馈塑造）：工具的描述（description）决定智能体在调用前如何理解和使用工具；工具的实现（implementation）决定智能体在调用后收到什么结果和错误信息。由于工具返回的内容会进入智能体的上下文，更可操作的错误提示、更相关的输出字段可以直接改变智能体后续的决策质量，而不需要动智能体本身。

受益方式具体体现在论文的三个实验场景中：

• 在 τ²-bench-verified 的 Telecom 域，AT-AT 把任务完成率从 29.50% 提升到 36.75%，提升 7.25 个百分点，配对置换检验 p=0.0033，是统计显著的。
• 在三个 Netflix 生产 MCP server 上，AT-AT 在全部三个 server 上降低了工具调用错误数或会话成本；在 Eng. Context server 上把 held-out 任务通过率从 54.5% 提升到 72.7%，提升 18.2 个百分点。
• 在 TerminalBench-2 上，held-out pass@1 从 49.32% 提升到 51.36%，提升 2.04 个百分点；TBLite 的 held-out pass@1 从 75.60% 提升到 77.20%，提升 1.60 个百分点。

受益方是工具提供方和所有下游智能体用户：工具提供方可以把积累的执行日志转化为工具改进，而不需要协调任何智能体侧的变更。

2. 已有工作的不足

在 AT-AT 之前，最接近的工作可以分成几类，每类都有明确的缺口。

文档与 schema 优化方法，如 EasyTool、PA-Tool、DRAFT、Play2Prompt、ToolObserver、DocsChisel，主要优化工具的“提示可见表面”——描述、schema、使用示例。它们的共同局限是：不改变工具的可执行行为。论文明确指出，这“仍然让可执行工具行为保持固定”。也就是说，如果一个工具返回的信息本身缺失了智能体需要的字段，或者错误信息不可操作，仅改描述无法修复。

Harness 优化方法，如 Meta-Harness、Self-Harness、AutoSaddler，可以编辑工具代码，但它们的优化对象是单个智能体的整个 harness，包括系统提示、执行循环、内部工具等。论文指出 Meta-Harness“迭代搜索的是 agent harness，其中包括 harness 的内部工具，而不是单独的工具集”。这与论文的核心场景不匹配：工具提供方通常不拥有调用工具的智能体，无法修改其 harness。

Trace-driven 工具优化方法，如 ToolObserver 和 DocsChisel，虽然也从轨迹中学习，但有两个不足：第一，它们使用固定的 LLM 流水线，只修订文档，不能做实现编辑；第二，它们需要在优化过程中反复重跑被优化的智能体来收集新轨迹。AT-AT 的设计目标之一就是只做一次离线 pass，不产生新的智能体 rollout。

Joint context optimization 和 JTPRO 同时优化智能体指令和工具描述，但它们的优化对象包含智能体侧组件，仍然不适用于“工具提供方不能改智能体”的设定。

总结起来，已有工作的不足可以精确表述为：没有方法能在固定智能体、只使用历史已评估轨迹、不新增 rollout 的条件下，同时编辑共享工具的描述和实现，并保留调用者依赖的接口契约。

3. 重建作者的思考路径

假设我面对第 2 项里的缺口：工具提供方手里有一堆历史执行日志，日志里记录了智能体调用工具后失败的过程，但提供方不能改智能体。最自然的起点是问：这些失败里，哪些是工具本身造成的，而不是智能体判断错误造成的？

我首先会想到去翻失败轨迹，找“智能体选错了工具”“智能体传错了参数”“工具返回了错误信息但智能体没恢复”“智能体反复调用同一个工具做本应一步完成的事”这些模式。这不需要什么复杂方法，就是人工审轨迹。Anthropic 的手动工具设计工作流就是这么做的：开发者看 transcript，然后用 coding agent 改工具描述和实现，再在 held-out 任务上检查泛化。AT-AT 的论文也明确说它“自动化了这样一个工作流”。

但手动审轨迹有两个问题：轨迹很长，而且失败模式可能分散在很多文件里。于是我会想：能不能让一个 coding agent 来做这件事？ 它本来就能读文件、搜索、做多轮编辑。给它失败轨迹、工具源码、一个“让工具而不是智能体的判断成为障碍的地方”的指令，让它自己找问题、自己改。这里有一个分叉：是只让它改描述，还是也允许改实现？如果只改描述，很多失败——比如工具返回缺少关键字段、错误信息含糊——是改不掉的。所以应该允许改实现，但要加约束：不能改工具名和签名，不能把任务特定答案硬编码进去，否则会破坏调用方依赖的接口，也会过拟合。

接下来撞上一个矛盾：如果 optimizer 看到的是失败轨迹，它可能会针对这些具体任务做过度拟合的修改。 比如它可能把某个任务 ID 对应的正确答案写进工具。这在共享工具场景下尤其危险，因为一个过拟合的修改会影响所有智能体。怎么缓解？我会想到两点：一是给 optimizer 一个明确的“泛化指令”，要求它修的是轨迹揭示的一般缺陷，而不是具体案例；二是让它同时看到成功轨迹，避免改坏已经能跑通的东西。

还有一个更隐蔽的问题：智能体执行本身有随机性。 同一个任务、同一个工具集，跑 30 次可能得到不同的结果。那么，怎么知道优化后的工具集真的更好，而不是碰巧这次跑得好？这不能靠单次 benchmark 分数的差值判断。我会想到用配对置换检验：对每个 held-out 任务，把原始工具集和优化工具集的 30 次结果配对，在“工具集无效果”的原假设下，两个条件标签在每对内可交换，置换这些标签得到差值的零分布，再看观测到的提升是否超出这个分布。论文正是这么做的。

再往下，我会问：这个 coding agent 的 harness 本身重要吗？ 如果只用一个单轮 LLM，把截断的轨迹塞进 prompt，让它直接输出新的 tools.py，会怎样？单轮 LLM 不能自己搜索文件系统，不能读完整轨迹，不能多轮修正。我猜测它的表现会差。论文的消融“Without coding agent harness”验证了这一点：在 Airline 上 52.50% 对比 AT-AT 的 59.17%，在 Telecom 上 30.50% 对比 36.75%。

还有一个分叉：历史轨迹到底有没有用？ 如果 optimizer 只拿到工具源码和任务描述、没有失败轨迹，它还能改进工具吗？我猜测不能，因为失败模式是改进信号的主要来源。论文的“Without past traces”消融支持这一点：Airline 上 50.33% 对比 59.17%，Telecom 上 30.42% 对比 36.75%。

最后我会意识到一个边界：这个方法的价值取决于失败中有多少是工具可修复的。 如果大部分失败是智能体推理错误，即使工具返回了正确信息，改工具也没用。论文在 Retail 域的分析正好撞上这个边界：Retail 基线已经 77.00%，LLM 审计发现大部分失败是智能体推理错误，工具实现可修复的失败只占约 3.1%，而 Telecom 是 8.9%。所以 Retail 上所有优化方法都没有显著提升。

与论文实际路径的差异：我上面的推理把“允许改实现”当作一个自然的选择，但论文实际上把它作为一个核心假设来验证，专门做了“Edit descriptions only”消融，并且把 feedback shaping 作为贡献点之一单独强调。这说明作者在方法设计时可能更谨慎地考虑了“改实现是否真的必要”这个问题，而不是像我这样直接假定它必要。另外，我在推理中没有提前想到“跨智能体泛化”这个维度——即工具编辑是否对不同 LLM 都有效——而论文专门做了跨五个客服智能体 LLM 的实验。这可能是作者从“共享工具服务异构智能体群体”这一企业场景出发才产生的动机，而不是从方法内部推出来的。

4. 核心 intuition

用一个日常类比：共享工具集像一栋办公楼里的电梯系统，智能体是每天使用电梯的租户，工具提供方是大楼物业。

电梯的“描述”是按钮上的标签和楼层指引：如果按钮标得不清楚，租户会按错楼层。电梯的“实现”是它到达后的反馈：如果电梯到了不亮灯、不开门、或者只显示一个含糊的故障码，租户就不知道该等还是该走楼梯。物业不能重新训练租户（不能改智能体），但可以改进电梯的标签和反馈机制（改工具描述和实现），让所有租户都受益。

这个类比对应的机制是：智能体的每一次工具调用都是一个“选择—反馈”循环。描述影响选择：智能体根据描述决定调用哪个工具、传什么参数。实现影响反馈：工具返回的结果和错误进入智能体的上下文，决定它下一步是恢复、重试还是放弃。论文里的 Telecom 例子精确对应这个机制：原工具返回数据用量和套餐上限，让智能体自己判断是否超量；改后的实现直接返回剩余数据量和超量标志，智能体就能直接行动。这不是让智能体变聪明，而是让环境把智能体需要的判断提前算好、直接给它。

为什么这有效？因为 LLM 智能体的一个已知弱点是在长上下文中做多步推理和状态比较。把“比较时间戳判断是否在 24 小时内”这种计算从智能体侧挪到工具侧，减少了智能体出错的机会。论文 Airline task 48 的例子就是证据：原工具只返回 created_at 时间戳，智能体错误地接受了用户“10 小时前预订”的说法；改后的工具返回 hours_since_booking=320.95 和 within_24h_of_booking=False，智能体直接拒绝了退款请求。

5. 方法 pipeline 举例

我编一个具体输入，走一遍 AT-AT 的完整流程。场景用论文里的 Telecom 域，因为那里有清晰的失败模式。

输入：τ²-bench-verified Telecom 域的训练集轨迹。假设有三条失败轨迹和两条成功轨迹。其中一条失败轨迹的任务是：用户手机号 555-123-2002，说数据用不了。智能体调用 get_customer_by_phone("555-123-2002")，工具返回 line_ids=[L1001, L1002, L1003]，没有标明哪个 line 对应这个手机号。智能体选了第一个 L1001，调用 get_data_usage("L1001")，返回 3.2/5.0 GB，智能体判断没超量，转人工。实际正确答案是 L1002 的数据用完了。最终 reward=0。

第一步：准备文件系统。 AT-AT 把工具源码 tools.py 和所有训练轨迹写成文件，放进 Pi coding agent 的沙箱工作区。每条轨迹文件带一个索引，记录任务 ID、结果（PASS 或 FAIL）、reward。在论文的主实验中，每条失败轨迹各取前 4000 字符，加上最多三条成功轨迹，一起放进 optimizer 的第一个 user message 作为 digest；完整轨迹仍在文件系统里可读。

第二步：Pi agent 读取和搜索。 Pi agent 先读索引文件，发现多条失败轨迹都涉及“从手机号找 line”这个步骤。它用文件工具打开相关轨迹，看到失败模式：get_customer_by_phone 返回多个 line ID，智能体反复选错。它再读 tools.py 里这个工具的实现，发现工具内部其实有手机号到 line 的映射，但返回时只给了 line ID 列表，没给每个 line 对应的手机号，也没有提供直接的 phone-to-line 查询。

第三步：Pi agent 做编辑。 它决定做两件事。第一，修改 get_customer_by_phone 的实现，让返回结果里每个 line ID 旁边带上对应的 phone_number，这样智能体可以核对。第二，新增一个工具 get_line_by_phone，直接接受手机号、返回 customer_id 和 line_id。它用 edit 工具改 tools.py，保持所有现有工具的名字和签名不变，新工具遵循 @is_tool 装饰器的格式。

第四步：验证。 编辑完成后，harness 检查 tools.py 能否正常 import，所有 @is_tool 方法签名是否保持，有没有新增或删除不允许的文件。假设第一次编辑因为新工具的参数类型声明有误而验证失败，Pi agent 的 session 被恢复，收到“validation failed”的提示，它重新读文件、修正类型声明，第二次通过。论文允许最多五次尝试。

第五步：输出优化后的工具集。 优化后的 tools.py 被用于重跑 Telecom 测试集。在论文的实际结果中，这个域的 held-out 完成率从 29.50% 升到 36.75%。在我编的这条轨迹对应的任务上，新工具 get_line_by_phone("555-123-2002") 直接返回 customer_id=C1001, line=L1002，智能体调用 get_data_usage("L1002") 看到 15.1/15.0 GB，判断超量，执行 refuel_data，任务完成。

6. 核心数学推导

论文的核心数学是问题形式化，不是算法内部的推导。我拆解第 3.1 节的目标函数。

符号解释：

• A 表示一个智能体，由固定的 harness H 和固定的语言模型 M 组成，写成 A = (H, M)。
• x 表示一个任务，从任务分布 X 中抽取。
• TE 表示环境工具集，拆成两部分：TED 是工具描述，TEC 是工具可执行代码。
• τ 表示一条轨迹，包含 LLM 输出、用户消息、工具调用和工具结果。
• pA(τ ∣ x, TE) 表示给定智能体 A、任务 x、工具集 TE 时，轨迹 τ 的分布。论文说明这个分布等价于 pM(τ ∣ H, x, TE)，因为 harness 和模型共同决定轨迹。
• r(τ, x) 是奖励函数，衡量任务成功程度。

目标：选择工具集 TE = (TED, TEC)，最大化在智能体群体 A ~ A、任务分布 x ~ X、轨迹分布 τ ~ pA(· ∣ x, TED, TEC) 上的期望奖励。写成公式就是论文的 Eq. 1：

T*ED, T*EC = argmax_TED,TEC E_{A~A, x~X, τ~pA(·∣x,TED,TEC)} [r(τ, x)]

逐步推导：

第一步，固定一个智能体 A 和一个任务 x，给定工具集 TE，执行会产生一条随机轨迹 τ。随机性来自 LLM 解码和环境。这一步给出 pA(τ ∣ x, TE)。

第二步，对这条轨迹评估奖励 r(τ, x)。因为 τ 是随机的，所以对固定的 A 和 x，奖励也是随机的。取期望 E_{τ~pA(·∣x,TE)} [r(τ, x)]，得到固定智能体、固定任务下的平均表现。

第三步，任务也是从分布 X 中抽取的，所以再对 x ~ X 取期望，得到固定智能体在任务分布上的平均表现。

第四步，智能体群体是异构的，A ~ A。工具提供方不能选择智能体，所以要对智能体分布取期望。这一步是关键：它把“优化单个智能体”推广到“优化共享工具服务所有智能体”。

第五步，现在期望值只依赖 TED 和 TEC。优化问题就是选 TED 和 TEC 让这个期望最大。这就是 Eq. 1。

这个公式在算什么：它在算“给定一个异构智能体群体和一个任务分布，哪套工具描述和工具实现能让平均任务奖励最高”。它把工具优化定义为一个分布上的期望最大化问题，而不是单个轨迹上的拟合问题。这个形式化的意义在于：它明确排除了“改智能体”的选项，把 H 和 M 固定在期望内部，只让 TED 和 TEC 成为决策变量。

论文的 Eq. 2 是 Eq. 1 的特例：当工具实现在 harness 内部时，工具优化是 harness 优化的受限形式。设 TH = (THD, THC) 是 harness 内部待优化的工具，H - TH 是 harness 的其余部分，目标变成：

T*HD, T*HC = argmax_THD,THC E_{x~X, τ~pM(·∣H-TH,x,THD,THC)} [r(τ, x)]

这里智能体群体退化为单一模型 M，但 harness 中除工具外的部分 H - TH 保持固定。这个公式在算：在 OpenCode 这类把工具实现在 harness 里的场景中，只允许编辑工具部分时的最优工具集。

7. 实验设计

数据集：

• τ²-bench-verified：客服智能体 benchmark，三个域 Airline、Retail、Telecom。使用默认 train/test 划分和默认 evaluator。客服智能体 LLM 是 GPT-4.1，用户模拟器是 GPT-5.1。
• TerminalBench-2 和 TBLite：终端智能体和编码 benchmark。优化对象是 OpenCode harness 内的 TypeScript 工具。OpenCode 智能体用 Claude Opus 4.5。
• 三个 Netflix 生产 MCP server：Core Developer Tools、Observability Collaboration Toolbox、Enterprise Engineering Context and Best Practices。任务从每个 server 前两周的生产流量中随机抽取，train/test 划分分别为 10/10、5/5、11/11。执行智能体用 DeepSeek V4 Flash，用户模拟器用 Claude Sonnet 4.6。

基线：

• DRAFT：离线适配版，只应用一次 Analyzer 和 Rewriter 阶段。
• ToolObserver：离线适配版，只应用一次 minibatch reflection 和 consensus merging。
• GEPA：把工具集当作 prompt 优化，用 1 个 exploration/reflection step。
• 三个消融：Edit descriptions only（只改描述，不改实现）、Without past traces（不给历史轨迹）、Without coding agent harness（单轮 LLM 优化器，无文件系统搜索能力）。
• 另有跨智能体泛化实验：五个客服 LLM（GPT-4.1、GPT-4.1-mini、Inkling、Claude Sonnet 5、GLM-5.2）生成轨迹并评估。

指标：

• τ²-bench-verified：held-out test reward（pass@1 百分比），每个任务 30 次试验；test cost（每次模拟的 agent 加 user-simulator 成本，USD）；optimizer cost（一次性成本，USD）；配对置换检验 p 值。
• TerminalBench-2 和 TBLite：原生 evaluator 的 pass@1、pass@3、pass@10，分 train 和 held-out test。
• 生产 MCP server：task pass rate（LLM judge 二值判断）、mean reward（部分信用公式，见下）、content score（LLM judge 按 3–7 条 rubric 打分）、tool calls 总数、tool errors 数、session cost、optimizer cost。

生产 MCP 的 reward 公式在提取文本中部分损坏，但可辨认的结构是：任务成功时 reward=1；否则 reward 等于 1/2 · naccepted / max(1, neligible)，其中 neligible 是排除 harness-blocked 和环境调用后剩余的工具调用数，naccepted 是其中未返回错误的调用数。这个公式给“工具调用失败更少”的失败轨迹部分信用，上限 0.5。

消融：

• Edit descriptions only：隔离实现编辑和 feedback shaping 的贡献。
• Without past traces：隔离历史轨迹作为学习信号的价值。
• Without coding agent harness：隔离 coding agent 多轮文件搜索能力。
• 跨智能体泛化：检验工具编辑是否对不同 LLM 都有效。
• 优化器 LLM 鲁棒性：用 GPT-5.6 Sol 和 Kimi K3 替换 Claude Opus 4.7。
• 泛化指令和完整文件系统轨迹：同时移除两者，检验其联合贡献。

实验能否支撑结论：

能支撑核心结论，但有几个缺口。第一，τ²-bench-verified 上只有 Telecom 的提升是统计显著的；Airline 的 7 个百分点提升（52.17% 到 59.17%）p=0.2305，不显著。论文在正文里把 Airline 的 7 点提升与 Claude 模型代际提升相提并论，但统计检验并不支持这个域的提升是可靠的。第二，Retail 上所有优化方法都低于基线，论文用“headroom 有限”解释，但这同时说明方法在已经较好的工具集上可能没有收益甚至轻微有害。第三，生产 MCP 实验的样本量很小（n=5 到 11），且只有一个 server 的 task pass rate 提升，没有统计检验。第四，论文自己承认只评估了单次优化运行，没有刻画 optimizer 自身的随机性——重复跑 AT-AT 可能得到不同的工具编辑和不同的下游效果。

缺什么：

• 缺少对 optimizer 噪声的量化：多次运行 AT-AT，报告工具编辑和下游指标的方差。
• 缺少对“工具编辑是否真的泛化到未见过的智能体”的更强证据：跨智能体实验的提升不显著。
• 缺少对“实现编辑是否破坏接口契约”的系统性检查：论文只要求语法和签名验证，没有验证行为等价性或调用方兼容性。
• 缺少 continual learning 的评估：论文声称可以随日志积累反复运行，但只评估了单次更新。

8. take-aways

• 实现编辑比只改描述更强，但只在失败确实源于工具实现时成立。 在 Telecom 域，AT-AT 的 36.75% 显著高于 descriptions-only 的 31.17%，差 5.58 个百分点；但在 Retail 域，两者都低于基线 77.00%，且无显著差异，因为 LLM 审计估计 Retail 失败中仅约 3.1% 可通过工具实现修复，而 Telecom 是 8.9%。

• 历史轨迹是必要的学习信号。 在 Airline 域，去掉历史轨迹后 reward 从 59.17% 跌到 50.33%，跌 8.84 个百分点；在 Telecom 域从 36.75% 跌到 30.42%，跌 6.33 个百分点。没有轨迹，optimizer 只能凭工具源码猜测，无法定位实际失败模式。

• Coding agent harness 对优化质量有实质贡献。 在 Airline 域，单轮 LLM 优化器得 52.50%，AT-AT 得 59.17%，差 6.67 个百分点；在 Telecom 域，单轮 LLM 得 30.50%，AT-AT 得 36.75%，差 6.25 个百分点。文件系统搜索和多轮编辑能力让 optimizer 能读完整轨迹和工具源码，而不是只看截断的 prompt digest。

• 统计显著性不能只看分数差。 Airline 域 AT-AT 提升 7.00 个百分点但 p=0.2305，不显著；Telecom 域提升 7.25 个百分点但 p=0.0033，显著。同样的百分点幅度，因为任务内方差不同，结论完全不同。评估工具优化必须用重复试验和配对检验，单次 benchmark 分数不可靠。

• 工具优化可能增加推理成本。 在 Airline 域，AT-AT 的 test cost 从 0.0618 升到 0.0675 USD/sim，p=0.002155，显著增加。论文归因于工具文件变长导致 executor agent 处理更多 token。优化工具的收益需要和增加的每次调用成本一起权衡。

9. 最脆弱的假设

最脆弱的假设是：失败轨迹中观察到的错误模式可以归因于工具，而不是智能体的推理缺陷，并且针对这些模式的工具编辑能泛化到 held-out 任务和未见过的智能体。

这个假设一倒，整个方法的核心主张就崩了。如果大部分失败是智能体推理错误——即使工具返回了正确且完整的信息，智能体仍然做错——那么改工具描述和实现就没有 headroom。论文在 Retail 域实际上撞上了这个假设的边界：基线已经 77.00%，所有优化方法都略低于基线，LLM 审计发现大多数 Retail 失败是“智能体推理错误，尽管工具已返回必要信息”。论文估计工具实现可修复的失败在 Retail 只占约 3.1%，而 Telecom 是 8.9%。这解释了为什么只有 Telecom 有显著提升。

论文给出的支持证据是间接的：

• 定性分析（App. B）展示了两个具体案例，其中工具编辑直接改变了智能体行为：Airline task 48 中，返回 within_24h_of_booking=False 让智能体拒绝了错误退款；Telecom 任务中，新增 get_line_by_phone 让智能体不再选错 line。这些案例支持“工具是失败原因”的归因，但它们是挑选过的。
• 跨智能体泛化实验（Tab. 2）显示 AT-AT 在五个 LLM 上平均提升了 Airline 和 Retail，但提升不显著，Telecom 还略微下降。这给“编辑泛化到未见过的智能体”提供了弱证据。
• 论文没有做系统性的失败归因分析来量化“多少失败是工具可修复的”，只在 Retail 的讨论中提到了一个 LLM 审计的估计。这个审计的方法细节没有给出。

这个假设的脆弱之处还在于：它依赖 LLM 优化器（Pi agent + Claude Opus 4.7）能正确判断哪些失败是工具造成的。如果优化器误判，它可能做出针对特定轨迹的过拟合编辑，这些编辑在 held-out 任务上不仅无益还可能有害。论文用“泛化指令”和“同时看成功轨迹”来缓解，但没有直接验证优化器归因的准确率。

10. 一周最小复现

只有一张 24GB 消费级显卡和一周时间，目标是复现最核心的结论：AT-AT 的 coding agent 优化器能从历史失败轨迹中提取工具改进，且实现编辑比只改描述更强。

步骤：

1. 选场景：不要用 τ²-bench-verified 全量，太大且需要 GPT-4.1/GPT-5.1 API。改用论文里的 TBLite 或 TerminalBench-2 的一个小子集，或者更实际地，自己构造一个 20–30 个任务的迷你工具集。推荐用 TBLite，因为它设计为 TerminalBench-2 的轻量替代，迭代快。如果 API 预算有限，用 OpenCode 的本地工具集和一个小型开源模型（如 Qwen 或 DeepSeek 的 7B–14B 模型）做 executor。

1. 生成基线轨迹：在 train split 上跑 OpenCode，每个任务跑 3–5 次，记录轨迹和 pass/fail。目标是有至少 10–15 条失败轨迹和 5 条成功轨迹。24GB 显卡可以跑 14B 以下的模型，或用 API 跑 executor 而本地只跑优化器。

1. 搭 AT-AT 优化器：优化器 LLM 用 API（Claude 或 GPT 均可，论文用 Claude Opus 4.7，但复现可以用更便宜的模型）。Pi agent 是开源的，论文给了 GitHub 链接。把工具源码（OpenCode 的 TypeScript 工具文件）和轨迹文件放进 Pi 的工作区。系统提示直接用论文 App. G 的文本，包括优化目标、编辑规则、泛化指令。

1. 跑优化：让 Pi agent 读轨迹、改工具描述和实现。验证只检查语法和签名不变。记录优化器 cost 和编辑内容。

1. 评估：在 held-out test split 上，用原始工具和优化后工具各跑 10–20 次，算 pass@1。如果时间允许，做一个简化版的配对检验：对每个任务，比较两个工具集在相同试验次数下的通过率差。

预期指标：论文在 TBLite 上 held-out pass@1 从 75.60% 提升到 77.20%，提升 1.60 个百分点。复现时如果任务子集更小，方差会更大，不要期待统计显著。更现实的判据是：优化后的工具集在 held-out 上不低于基线，且至少有一个具体的工具编辑能在定性上追溯到某条失败轨迹的失败模式。如果只改描述的消融和完整 AT-AT 的差距能复现出来（哪怕不显著），就抓住了核心机制。

数据规模：train 20–30 个任务，test 10–15 个任务，每个任务 10 次试验。总 executor 调用量大约 (20+10)×10×平均每次任务 5–10 次工具调用，约 1500–3000 次工具调用，一周内可完成。

11. 反例设计

设计一个实验，若成功即可推翻本文核心主张“工具优化能从历史轨迹中提取可泛化的改进，且实现编辑优于只改描述”。

实验设计：构造一个任务分布，其中失败轨迹的表面模式与真实失败原因系统性脱钩。具体做法：创建一个工具集，包含一个 lookup 工具和一个 compute 工具。lookup 返回一个字典，compute 接受两个参数做计算。在训练任务中，所有失败轨迹都表现为智能体调用 lookup 时传错了参数格式，导致工具返回错误。但真实原因是：任务本身要求智能体做一步超出其能力的推理，即使 lookup 返回了正确结果，智能体也无法完成后续推理。换句话说，工具返回的信息是充分的，失败在智能体侧。

操作：把训练轨迹喂给 AT-AT，让它优化工具。预期它会看到“参数格式错误”的表面模式，然后修改 lookup 的描述或实现来“修复”这个模式——比如放宽参数解析、返回更详细的错误提示。

判据：在 held-out 任务上，优化后的工具集的任务完成率不高于原始工具集，甚至可能更低。如果 AT-AT 的核心主张成立，它应该能区分“工具造成的失败”和“智能体造成的失败”，只在前者存在时做出有效编辑。如果在这个反例中，AT-AT 仍然做出了编辑但 held-out 表现没有提升或下降，说明它无法可靠地做失败归因，其“从轨迹中提取工具改进”的主张在失败归因模糊的场景下不成立。

更强的版本：在训练任务中注入虚假相关——所有失败轨迹恰好都涉及某个特定工具参数，但该参数与失败无因果关联。如果 AT-AT 编辑了这个参数相关的描述或实现，且 held-out 表现下降，就证明它会过拟合轨迹中的表面模式，推翻“泛化指令足以防止过拟合”的隐含假设。

这个反例实验的关键在于：它直接攻击第 9 项里最脆弱的假设——失败归因的可靠性。如果 AT-AT 在这个实验上失败，说明它的优化器只是在做模式匹配，而不是真正的因果归因。

12. 落地判断

能否用于“抢占式 GPU 自托管 27B 模型做多智能体脚手架”？

可以用，但需要适配，且最大的价值点和最大的坑都很明确。

怎么用：这个场景里的“工具”是脚手架暴露给 27B 模型的内部工具——比如文件读写、代码执行、搜索、消息传递。这些工具实现在 harness 内部，对应论文 Eq. 2 的设定。AT-AT 可以直接优化这些工具的描述和实现。具体做法：收集脚手架在真实任务上的执行轨迹，记录每次工具调用的输入输出和最终任务成功与否；把工具源码和轨迹喂给 Pi agent；让优化器编辑工具描述和实现；在 held-out 任务上验证。由于是自托管，优化器 LLM 可以用 API，也可以用本地的另一个模型实例。

成本量级：论文里 optimizer cost 在 τ²-bench-verified 上是 1.93 到 10.69 USD 一次，生产 MCP 上是 1.34 到 7.684 USD 一次。这是用 Claude Opus 4.7 的价格。如果用更便宜的优化器模型，成本可以降到 1 USD 以下。Executor 侧的重复评估成本是主要开销：论文用 30 次试验每任务，这在自托管场景下意味着大量 GPU 时间。对于 27B 模型，一次任务可能消耗几万到几十万 token，30 次试验的成本需要按本地推理吞吐估算。如果只做 5–10 次试验，成本可控，但统计功效会下降。

最大的坑：抢占式 GPU 意味着执行可能随时被中断。这带来两个问题。第一，轨迹里会混入“基础设施失败”——任务不是因为工具或智能体的问题而失败，而是因为 GPU 被抢占、进程被杀。论文在 App. C 里提到 infrastructure crashes 是评估噪声的一个来源，但没有处理它。如果把这些失败轨迹喂给 AT-AT，优化器可能误把基础设施故障归因于工具，做出有害编辑。落地时必须先过滤掉因抢占导致的失败轨迹，或者给轨迹打上“基础设施失败”标签并排除。第二，抢占式环境下的重复评估方差更大，论文的配对置换检验框架在这里更重要，但 30 次试验的成本也更高。

另一个坑：27B 模型的能力边界。论文的实验用的是 GPT-4.1、Claude Opus 4.5 等级别的强模型。27B 模型对工具描述中的细微差别可能更敏感，也可能更不敏感——它可能无法利用优化器添加的丰富反馈字段，或者更容易被长描述分散注意力。论文引用的 PA-Tool 工作表明小模型需要 schema 对齐其预训练命名习惯。在落地时，AT-AT 的优化器需要知道 executor 是 27B 模型，可能需要在系统提示里加入“目标模型能力较弱，描述要简洁、避免歧义”的约束。论文没有评估这种弱模型场景，这是一个需要自己验证的盲区。