用途
Tool Budget Audit 用于审计一个智能体的工具究竟消耗了多少上下文，并据此判断应当精简工具目录、引入工具搜索，还是改用程序化工具调用。文档指出工具带来两类上下文成本和一个副作用：
- 定义成本：每个工具的名称、描述和参数 schema 无论本轮是否使用都占据上下文。
- 中间结果成本：每次调用都把完整输出放回对话，且每次往返都是一次完整的模型请求。
- 副作用：相似的名称和含糊的描述会导致模型选错工具或传错参数。
文档同时说明，工具搜索主要节省第一类成本，程序化工具调用主要节省第二类成本。
主要能力
该方法提供一套分阶段的检查与决策流程：
- 先测量。基于目标项目的代码和真实请求，而不是凭猜测：列出暴露给模型的每个工具并按来源分组（内置、各 MCP 服务器、插件）；用分词器估算每个工具定义的 token 大小并求和，说明所用分词器（这是相对度量）；对一到两个代表性任务记录工具调用次数、由此产生的模型请求次数和工具结果大小；标注几乎每轮都用和很少使用的工具；报告实测数字，无法测量的要说明而不是估算。
- 第 0 步：做减法。按用户意图合并，而非 API 一一对应（例如「列出议题」「按标签过滤」和「按作者过滤」可以合并为一个带参数的工具）；让名称与描述可区分，并写明返回格式；按领域分组并保持每组规模小；决定哪些常驻——几乎每轮都用的读取、编辑、搜索、执行命令类工具应始终加载。
- 第 1 步：延迟加载与工具搜索。在工具多且大多很少使用时考虑；保留核心高频工具常驻，把低频工具改为可检索；如果搜索未命中就意味着工具「不存在」，要回头检查描述，含糊描述会破坏召回；在自有工具集上测试搜索召回，干净基准上的结果不能迁移到杂乱的现实目录；每轮都要从网络拉取目录的工具可能拖慢首 token，可考虑保持常驻；调试时检查模型当时实际看到的内容，而不只是请求里列出的内容。
- 第 2 步：程序化工具调用。在需要过滤或聚合大量数据、存在三个及以上相互依赖的调用、或有可并行的批量操作时考虑；要真正把工具移入程序内部，仅在常规工具旁提供一个代码工具往往不会被使用；顶层保留与用户交互、改变会话状态、需要先读结果再决定下一步（工具搜索、加载技能）、浏览器与发布类工具，以及派生子智能体；程序内部发起的调用必须经过与直接调用相同的校验、钩子、权限提示和界面；工具失败应返回错误结果而非抛出异常，避免一次失败丢弃整个程序；优先使用结构化工具输出以便程序选取需要的字段，返回原始输出的程序没有节省；搜索代码库中依赖工具名称的逻辑（提醒、计数器、分析），工具移入程序后这些逻辑会静默失效。
决策对照
文档给出的瓶颈与首选动作对应关系：
- 工具太多或太相似：做减法、合并、重命名、分组。
- 定义占用上下文过多：工具搜索。
- 结果占用上下文过多、往返次数过多：程序化工具调用。
- 参数经常出错：改进描述与示例。
各步骤是叠加的：干净的目录让工具搜索生效，可用的工具搜索让程序化调用生效。每一步前后都应做端到端评测，同时看分数、请求数和 token（参见 harness-experiment）。
输出
最终产出一份简短报告：实测数字、主要瓶颈、建议的下一步（含具体工具名称）以及之后要测量什么。