工具库有 5,000 个 MCP server，平均每轮查询要调用 5 次工具，一次会话连续跑 100 轮；实验中统一的 128 工具上限很快会被撑爆。MemTool 用自治、工作流、混合三种模式决定「谁来决定删工具」：GPT-o3 自治模式的 3 轮移除率是 94.1%，Claude 3.5 Sonnet 只有 6.2%；工作流把 12 个有结果的模型（Claude 3.7 Sonnet 未报告 Workflow）的移除率全部压在 90.4% 以上，但任务完成度的上限也随之下降。
MemTool 把「工具上下文」当成短期记忆来管理，给出三种自主性不同的架构。Autonomous：agent 自己持有两个元工具 Search_Tools 与 Remove_Tools，在回答问题的循环里自行增删。Workflow：每轮用户查询后先做两次独立 LLM 调用——一次剪除无关工具，一次搜索新工具——之后 agent 在固定的工具集里回答，不再持有元工具。Hybrid：剪除仍由独立调用完成，但 agent 保留 Search_Tools，可以在循环里继续检索。
论文在 ScaleMCP 的 5,000 个 MCP server 上做了 100 轮连续查询，评测 13 个 LLM（Workflow 只有 12 行结果）。自治模式把模型能力差距放大：推理模型 3 轮移除率约 90–94%，中型模型只有 0–60%；工作流模式把 12 个模型全部拉到 90.4% 以上（Claude 3.7 Sonnet 未报告 Workflow），跨度只有 3.4 个点；混合模式介于两者之间，移除率 86.9–94.3%，任务完成度最高 0.88。代价是工作流和混合模式每轮要多一次（或两次）LLM 调用，而论文没有给出 token、延迟或费用的量化。
读完这节你应该知道：动态工具调用为什么会把上下文撑爆，以及 128 这个数字从哪来。
论文把 LLM 比作 CPU、把上下文窗口比作 RAM：模型能调用的工具不是初始化时固定的一小组，而是按需从工具库里搜索、装载。实验用的 ScaleMCP 有 5,000 个 MCP server，平均每轮用户查询要调用 5.0 次工具；一次会话连续跑 100 轮。工具一旦装进 API 请求的 tools 字段，就会一直占着上下文，除非有人显式删除。
问题在于 LLM 的默认行为是「加」而不是「减」：它会在需要时搜索新工具，却很少主动判断哪些旧工具已经没用了。论文把工具上限统一设为 128 并作为 API error limit：Gemini 2.5 Pro、Claude Opus 4 的 API 本身支持 256–512 个工具，但为了横向比较，所有模型都按 128 计。Figure 2 里，LLaMA 3 70B 与 Claude 3.5 Sonnet 在第 20 轮左右就撞上 128；一旦撞线，再搜索新工具会返回错误，agent 只能先删再搜。
工具库来自 ScaleMCP，按每轮工具调用数分层抽样 100 个实例，构成 100 轮连续对话。§3.2
用户查询之间可以相关，也可以完全无关；每轮平均触发 5 次工具调用，工具集跨轮持久化。§4.1
统一设定为 128；论文注明 Gemini 2.5 Pro / Claude Opus 4 的 API 可容纳 256–512 个工具，但实验中不用满。§4.1
读完这节你应该知道：MemTool 与工具检索、上下文压缩、长期记忆三条线各自的分工。
ScaleMCP 这类工作把工具或 MCP server 建成向量库，按用户查询检索 top-k 工具并注入上下文，解决的是「在成千上万个工具里找到当下要用的那几个」。它默认一次查询结束就结束，不处理工具在多轮对话里持续堆积的问题。
§2.2
摘要与截断主要压缩对话历史，省的是消息 token，不会主动移除已经注入 tools 字段的工具 schema；Mem0、Zep、Letta 等长期记忆框架关注跨会话持久化，也不是「本次会话内工具集怎么增删」。
§2.1
MemTool 把这两条线之间空出来的问题定义成「短期工具记忆」：工具集 T 本身是一个需要被读写的状态，每轮都要决定保留谁、删除谁、检索谁。论文的三种模式，本质上是在「谁来执行删除」上给出三种答案：agent 自己、固定工作流、或两者各做一半。
读完这节你应该知道：三种模式的调用结构、各自能做什么与不能做什么，以及论文对「模型能力」的判断。
| 模式 | 谁移除工具 | 谁添加工具 | 自主性 | 主要风险 |
|---|---|---|---|---|
| Autonomous | agent 调 Remove_Tools | agent 调 Search_Tools | 最高 | 不会删或忘了删，工具数撞上 128 |
| Workflow | 独立的 prune LLM 调用 | 独立的 search LLM 调用 | 最低 | 进入回答循环后无法再检索新工具 |
| Hybrid | 独立的 prune LLM 调用 | agent 调 Search_Tools | 部分 | agent 看不到删除，可能加得过多；再剪除可能误删 |
Autonomous 模式给 agent 两个额外工具：Search_Tools(keywords) 负责向向量库检索并加入工具，Remove_Tools(tool_names) 负责把不再相关的工具从 API 调用里移除。agent 在同一个 while 循环里边回答边管理工具，删除与搜索的调用和结果都会写回消息历史。论文报告了一个关键工程细节：如果 system prompt 不注入「当前工具数量」这个动态变量，agent 的移除率会变得很差；把数量显式告诉它之后，删除行为才稳定。§3.1.1
搜索结果的检索深度是 top-5，工具上限 L=128；如果一次 Search_Tools 让工具总数超过 128，系统返回错误并提示 agent 先删除。消息历史本身可以用截断或摘要管理，但这只压缩对话，不影响工具集。Algorithm 1
Workflow 模式把工具管理从 agent 循环里拿出来，固定在每轮用户查询之后：第一次独立 LLM 调用读取当前消息与工具列表，决定删除哪些工具；第二次独立调用判断现有工具是否够用，不够就生成检索关键词；向量检索取 top-5 后并入工具集。之后 agent 进入与自治模式相同的回答循环，但它不再持有 Search_Tools 或 Remove_Tools，无法在循环中自行增删。Algorithm 2
这个设计的确定性最强：同一套 prune-then-search 管线约束所有模型，工具数不容易失控。代价是「进入回答循环后没有回头路」——如果第一次检索选错工具，agent 不能在循环里重新搜索；论文也明确说，限制自主性会阻止自我纠错，而把自纠错步骤塞进工作流会让流程过于复杂。§3.1.2
论文观察到 LLM 在「搜索和添加工具」上表现较好、在「移除工具」上普遍较弱，于是把两者拆开：每轮开始先做一次独立的 prune LLM 调用，删掉不再相关的工具；随后 agent 拿到 Search_Tools（但不含 Remove_Tools），可以在回答循环里继续检索。agent 对「删除」这件事是被抽象掉的——它看不到 prune 调用，也不参与删除决策。§3.1.3
风险也随之而来：如果 agent 在循环里加得太多、越过 128，Hybrid 仍会触发一次紧急 prune；若这次 prune 找不到可删的工具，就返回错误。论文在局限里说，误删关键上下文时，一个缓解办法是临时退回 Autonomous 模式——但这又把「会不会删」的问题交还给了模型。结论后的 Limitations 段
读完这节你应该知道：实验的每个数字是怎么量出来的，哪些设置是人为固定的。
从 5,000 个 MCP server 中按「每轮工具调用数」分层抽样 100 个实例，拼成 100 轮连续用户查询；每轮平均 5.0 次工具调用，相邻查询可以相关也可以无关。工具知识库用 text-embedding-ada-002 建索引，检索深度 top-5。§3.2
GPT-o3、GPT-4o、GPT-4o Mini、GPT-4.1、GPT-4.1 Mini、GPT-4.1 Nano、Gemini 2.5 Pro、Gemini 2.5 Flash、Claude Opus 4、Claude Sonnet 4、Claude 3.7 Sonnet、Claude 3.5 Sonnet、LLaMA 3 70B。任务完成度由 GPT-4o mini 作为 judge 打分。§4.1
论文用两个指标刻画「记忆管理」，两个指标刻画「任务做得怎么样」：
Rt 是第 t 轮删除的工具数，At 是第 t 轮加入的工具数。这个比值衡量「加进来的工具有多少后来被删掉」，但会被早期未清理的堆积稀释，所以论文又定义了 3 轮滚动窗口的 Avg Removal Ratio 3T：对每个连续 3 轮窗口分别算删除/加入比，再对所有窗口取平均。
Avg Residual 3T 看的是每个工具数峰值之后连续 3 轮的平均工具数（Table 2 caption：「average number of tools remaining after three turns」；§4.1：「how many tools remain shortly after each peak tool count」），直接反映「内存泄漏」有多严重。Task Completion 用 LLM-as-judge 比较 agent 最终回答与基准期望答案的对齐程度，judge 固定为 GPT-4o mini；Tool Correctness 是正确工具调用数除以总调用数。论文未提及人工复核。§4.1
「3 轮」是论文设定的观察窗口：残留量不是在工具加入满 3 轮后做一次统计，而是在每个工具数峰值之后连续取 3 轮的工具数求平均（Eq. 3）；移除率同样按连续 3 轮窗口计算删除/加入比。这个窗口同时用于 Avg Removal Ratio 3T 和 Avg Residual 3T。论文没有报告 2 轮、5 轮或 10 轮窗口的敏感性实验；因此所有关于「谁清理得更干净」的结论，都限定在这个 3 轮口径下。推断（依据：全文只出现 3-turn / 3-window 定义，未检索到窗口大小的消融）。
读完这节你应该知道：三种模式在同一轮里的调用顺序，以及 128 上限在哪里兜底。
读完这节你应该知道：三种模式各自的强项与代价，以及「哪个模式最好」为什么没有统一答案。
正文 Table 1 只列了 11 个模型；13 个模型（去重）的完整结果在附录 A 的 Table 2（Claude 3.7 Sonnet 与 GPT-4o Mini 只在后者出现）；其中 Workflow 只有 12 行——Claude 3.7 Sonnet 没有 Workflow 结果。下表按 Table 2 转录，数值是原始小数；图中的百分比是 ×100 后的显示值。
| 模式 / 模型 | Avg Removal 3T | Avg Residual 3T | Tool Correctness | Task Completion |
|---|---|---|---|---|
| Autonomous Agent | ||||
| GPT-o3 | 0.941 | 7.44 | 0.75 | 0.90 |
| Gemini 2.5 Pro | 0.924 | 6.51 | 0.81 | 0.80 |
| Claude 3.7 Sonnet | 0.905 | 14.25 | 0.86 | 0.89 |
| Gemini 2.5 Flash | 0.905 | 5.08 | 0.74 | 0.65 |
| Claude Opus 4 | 0.878 | 13.85 | 0.86 | 0.84 |
| Claude Sonnet 4 | 0.840 | 24.44 | 0.80 | 0.83 |
| GPT-4.1 | 0.834 | 48.12 | 0.86 | 0.88 |
| GPT-4.1 Mini | 0.733 | 58.93 | 0.78 | 0.80 |
| GPT-4o | 0.713 | 37.48 | 0.68 | 0.76 |
| GPT-4o Mini | 0.449 | 121.06 | 0.78 | 0.88 |
| LLaMA 3 70B | 0.244 | 123.33 | 0.42 | 0.72 |
| Claude 3.5 Sonnet | 0.062 | 124.00 | 0.38 | 0.59 |
| GPT-4.1 Nano | 0.000 | 0.00 | 0.13 | 0.60 |
| Workflow | ||||
| GPT-4o | 0.938 | 7.19 | 0.71 | 0.70 |
| GPT-4.1 | 0.934 | 7.48 | 0.82 | 0.83 |
| LLaMA 3 70B | 0.932 | 8.64 | 0.51 | 0.71 |
| Gemini 2.5 Pro | 0.929 | 6.90 | 0.69 | 0.66 |
| Gemini 2.5 Flash | 0.928 | 6.60 | 0.50 | 0.60 |
| GPT-o3 | 0.925 | 7.59 | 0.88 | 0.84 |
| GPT-4.1 Mini | 0.922 | 7.72 | 0.72 | 0.81 |
| Claude 3.5 Sonnet | 0.917 | 7.83 | 0.82 | 0.82 |
| Claude Opus 4 | 0.917 | 7.92 | 0.71 | 0.78 |
| Claude Sonnet 4 | 0.917 | 8.00 | 0.77 | 0.81 |
| GPT-4o Mini | 0.916 | 8.43 | 0.74 | 0.72 |
| GPT-4.1 Nano | 0.904 | 8.96 | 0.64 | 0.66 |
| Hybrid | ||||
| GPT-4o | 0.943 | 7.15 | 0.77 | 0.76 |
| GPT-4.1 | 0.941 | 7.29 | 0.82 | 0.80 |
| LLaMA 3 70B | 0.938 | 7.52 | 0.60 | 0.76 |
| Gemini 2.5 Pro | 0.938 | 6.52 | 0.74 | 0.75 |
| Claude 3.5 Sonnet | 0.935 | 7.32 | 0.81 | 0.83 |
| GPT-4o Mini | 0.934 | 7.77 | 0.81 | 0.80 |
| GPT-o3 | 0.932 | 9.33 | 0.82 | 0.87 |
| Gemini 2.5 Flash | 0.932 | 6.15 | 0.59 | 0.66 |
| GPT-4.1 Mini | 0.929 | 7.26 | 0.81 | 0.79 |
| Claude 3.7 Sonnet | 0.921 | 7.97 | 0.83 | 0.88 |
| Claude Opus 4 | 0.920 | 10.46 | 0.82 | 0.81 |
| Claude Sonnet 4 | 0.912 | 10.27 | 0.82 | 0.81 |
| GPT-4.1 Nano | 0.869 | 6.94 | 0.48 | 0.63 |
柱高按固定上限 100 满格；数值保留一位小数。切换模式与排序只改变这张图的呈现，不改变 Table 2 的原始数值。
Autonomous（13 行，按移除率或完成度排序，读数相同）：Table 2 给 GPT-o3 的移除率 0.941，0.941 × 100 = 94.1；GPT-4.1 Nano 是 0.000，0.000 × 100 = 0.0；跨度 94.1 − 0.0 = 94.1。完成度最高是 GPT-o3 的 0.90 × 100 = 90.0。JS 输出：最高 GPT-o3 94.1，最低 GPT-4.1 Nano 0.0，跨度 94.1，完成度最高 GPT-o3 90.0。
Workflow（12 行）：最高 GPT-4o 的 0.938 → 93.8；最低 GPT-4.1 Nano 的 0.904 → 90.4；跨度 93.8 − 90.4 = 3.4。完成度最高是 GPT-o3 的 0.84 → 84.0。JS 输出：最高 GPT-4o 93.8，最低 GPT-4.1 Nano 90.4，跨度 3.4，完成度最高 GPT-o3 84.0。
Hybrid（13 行）：最高 GPT-4o 的 0.943 → 94.3；最低 GPT-4.1 Nano 的 0.869 → 86.9；跨度 94.3 − 86.9 = 7.4。完成度最高是 Claude 3.7 Sonnet 的 0.88 → 88.0。JS 输出：最高 GPT-4o 94.3，最低 GPT-4.1 Nano 86.9，跨度 7.4，完成度最高 Claude 3.7 Sonnet 88.0。
排序按钮只改变柱子的上下顺序；读数始终对整份模型列表取最大值与最小值，因此同一模式下两种排序的读数字段相同。
Autonomous：能力差距被放大。推理模型集中在 90–94%：GPT-o3 是 94.1%，Gemini 2.5 Pro 92.4%，Claude 3.7 Sonnet 与 Gemini 2.5 Flash 都是 90.5%。中型与小型模型掉到 0–60%：LLaMA 3 70B 只有 24.4%，Claude 3.5 Sonnet 只有 6.2%，GPT-4.1 Nano 是 0.0%。残留量把差距写得更直白：GPT-o3 的 Avg Residual 3T 是 7.44，Claude 3.5 Sonnet 是 124.00，相差 116.56 个工具。Figure 2 里，LLaMA 3 70B 与 Claude 3.5 Sonnet 在第 20 轮左右撞上 128 上限，撞线后新增工具会返回错误，需先删除。这里有一处原文冲突需要并列：Table 2 给 GPT-4.1 Nano 的移除率 0.000、残留 0.00（几乎不删），Figure 2 图注却把 GPT-4.1 Nano 与 Claude 3.5 Sonnet、LLaMA 3 70B 并列为 “fail to remove unused tools, exceeding the 128-tool API limit”；两处说法不一致，页面并列，不替原文取舍。
Workflow：可靠性来自结构，不来自模型。12 个有 Workflow 结果的模型移除率全部 ≥ 90.4%（Claude 3.7 Sonnet 未报告 Workflow），最高 GPT-4o 93.8%，跨度只有 3.4 个点。LLaMA 3 70B 从自治的 24.4% 拉到 93.2%（+68.8 点），Claude 3.5 Sonnet 从 6.2% 拉到 91.7%（+85.5 点）。工具调用正确率最高的是 GPT-o3 的 0.88；任务完成度最高的是 GPT-o3 的 0.84，仍低于它自治模式的 0.90——确定性管线压住了工具数，也压住了 agent 在循环里补救的机会推断（由 Table 2 的完成度对比归纳）。
Hybrid：折中的收益与代价都写在表里。移除率在 86.9–94.3% 之间，跨度 7.4 个点；GPT-4o 最高 94.3%，GPT-4.1 Nano 最低 86.9%。任务完成度最高的是 Claude 3.7 Sonnet 0.88，GPT-o3 是 0.87，低于它自治模式的 0.90。Claude 3.5 Sonnet 是混合模式的最大受益者：移除率从 6.2% 到 93.5%（+87.3 点），任务完成度从 0.59 到 0.83（+24 点）。但对强模型，Hybrid 并不免费推断（由 Table 2 完成度对比归纳）：GPT-4.1 的完成度从自治的 0.88 降到 0.80，Claude Opus 4 从 0.84 降到 0.81。
把三张视图放在一起，论文的推荐就可以读成条件句：追求最高任务完成度、且手里有推理模型，用 Autonomous；追求稳定可控、模型能力参差，用 Workflow；想在两者之间取平衡，用 Hybrid。没有哪个模式在四个指标上同时占优。
读完这节你应该知道：论文没有回答哪些问题，以及这些空白会怎样影响模式选择。
Workflow 每轮多 2 次 LLM 调用，Hybrid 多 1 次（超限时再加 1 次）；论文在 §4.3.2 只按成本效率给出定性建议，没有报告额外调用的 token 数、延迟或费用推断（依据：全文未检索到相关量化）。在线场景里，这可能是比移除率更硬的约束。§4.3.2
剪除依据是当前查询与工具的相关性，判断者仍是 LLM；一个当下无关、但几轮后要用的工具可能被提前删掉。论文没有给出相关性的形式化定义，也没有测「误删后恢复」的代价。§3.1.2
100 个样本全部来自 ScaleMCP 这一个 benchmark，模型也只在这个 benchmark 上评测；换到工具依赖复杂、或需要创意联想的域，三种模式的排序是否保持，论文没有回答。§3.2
另外三点值得单独记下。第一，任务完成度由 GPT-4o mini 作为 judge 打分，论文没有报告与人类评分的一致性；更换 judge 后，0.90 与 0.88 这类接近的数值是否仍能分开，未知。第二，Hybrid 的「删除对 agent 不可见」是一把双刃剑：它避免了模型不擅长删除的问题，也让 agent 无法判断自己是否刚被剪掉了关键工具；论文建议在误删时临时退回 Autonomous，但这就重新引入了「模型会不会删」的依赖。第三，3 轮窗口是固定设定，没有敏感性分析；如果业务允许工具在上下文里多留几轮，残留量的绝对值会整体上移，模式之间的相对排序未必不变。推断（依据：§4.1 只定义 3 轮口径；§4.4.2 未报告窗口消融）。
论文自己的定位也是「短期记忆」：它不处理跨会话的长期记忆，也不处理工具之间的依赖关系推断（依据：全文没有讨论工具依赖图或调用顺序约束）。把 MemTool 与长期记忆框架拼接，是论文在结论里留下的下一步；而「用低成本模型专职做 prune、更强的模型面向用户」是 §4.3.2 的部署建议（原文举例 GPT-4.1 Mini、Gemini 2.5 Flash 充当 memory controller），不是已经验证的结果。