第 09 章 · 工具设计与上下文经济学

本篇目标：把每个工具的成本算清楚，并把多步骤任务的上下文占用压到十分之一量级。 核心事实：工具描述是系统提示词的一部分，你每次对话都在为它付费。

9.1 先算一笔账

原文 标准模式下跟 Agent 说一句「你好」，上下文面板约 1 万+ token；极简模式约 1 千+。差约 10 倍。差额来自哪里？

判据 12（固定成本）：每轮输入 token = 常驻工具与提示词开销 + 本轮对话与工具结果。前者是你为「能力可能性」预付的固定税，后者才是任务本身。Harness 设计的第一条经济学就是压低固定税，同时不砍掉真正需要的能力。

原文给的体检动作很实在：说一句「你好」，看上下文面板。若是一万多，你有两个选择——日常切极简省 10 倍，或勤用 /compact。但这两个都是战术；结构性方案是让能力按需出现（9.3）和让中间结果不回灌（9.4）。

9.2 工具设计的六条规则

社区 Cat Wu 原则：除非一个工具被证明能提升效果或准确率，否则不要加。

官方 DSH 的对应机制：core/tools 维护 scoped tool registry 与 guarded execution pipeline，ctx.tools.execute() 接收 raw batches 与并发限制；每一轮的 step-admitted tool schemas 是按 step 准入的，不是一次性全量塞进提示词。这给「按需工具集」留了正规入口。

Schema 歧义是环境 bug，不是模型 bug。 第 06 章的二分法：极简里能做对、标准里做不对，第一嫌疑就是 schema。

9.3 按需加载：Skills 与 MCP

社区 arXiv 对 11 个 coding agents、约 400 万行源码的研究（Barbaste 等，2026-07-15）识别出 29 个 recurring patterns，其中 Skills 采用率 9/11，MCP 为 8/11。

社区 Skills 的关键性质：启动时模型只看到名称 + 描述（约 200 token），需要时才加载全文。这与「把 3000 行 API 文档贴进系统提示词」形成鲜明对比。

官方 当前推荐布局：CLAUDE.md（项目记忆）、SKILL.md（按需 skills，优先于 legacy commands）、.claude/agents/*.md（子 Agent）、.claude/workflows/*.js（编排脚本）——全部可随仓库进 git。

判据 13：把「可能用得上」的内容从常驻上下文移到按需层，是零风险的优化；把「必须生效」的约束从常驻上下文移到 hook，是零成本的安全性提升。

9.4 PTC：结构性压缩，不是技巧

第 05 章讲了机制，这里讲清楚省下的到底是什么。

标准模式跑批量流水线：

读 csv1 → 结果回上下文 → 读 csv2 → 结果回上下文 → … → 清洗结果回上下文
→ 聚合结果回上下文 → 搜索基准（N 次，每次结果回上下文）→ 写报告

每一步的中间产物都进入模型历史并被反复重读。PTC 把整个中间过程放进托管进程：

run_code(一次提交) → 进程内完成 18 步 → return 聚合表 + 基准对比 → 模型

原文 可直接复制的批量流水线指令：

用 PTC 编排一个数据流水线：
1. 读取 data/ 下所有 csv，合并成一份数据集
2. 清洗：去空值、统一日期格式、剔除异常值
3. 按 category 分组，计算 count、sum、mean
4. 用 web_search 查一下每个 category 的行业基准值
5. 把对比结果写成 reports/benchmark.md

要求：
- 第 1-3 步用一个程序里完成，不要分多次调用
- 第 4 步的搜索可以并行发起
- 只把最终的聚合表和基准对比结果返回给我
- 中间失败的话，把失败的 csv 文件名列出来跳过，不要中断整体流程

最后两条要求才是精髓：限定 return 的内容、规定失败不中断。把它们写进指令，等于把上下文预算与容错策略显式化了。

PTC 不是「更快的标准模式」，是「把控制流从模型上下文搬到进程里」。 这个迁移思路可以脱离 DSH 复用：任何「步骤固定、中间结果无需人看」的流程，都值得写成一个程序而不是一串 tool call。

9.5 帕累托前沿：能力 vs 固定开销

把四个模式放到同一张图上理解（定性，非实测）：

上下文固定开销
  高 │  Standard ●        Creator ●
     │        ╲            ╱
     │         ╲    PTC ●         ← 单轮高、总量低
     │          ╲  ╱
  低 │     Minimal ●                ← 能力最少，噪声最低
     └──────────────────────────→  可用能力
         少                    多

选型的本质不是在「强/弱」里挑，是在这条前沿上挑一个与任务匹配的点：

9.6 本章产出与验收

核心产出：一张本项目的「工具成本表」（每个工具的 schema token 估算 + 使用频次 + 是否可按需化），外加一个跑通的 PTC 数据流水线。

验收点：

• 能量化说出「你好」这一轮的常驻开销由哪几块构成
• 至少把 1 个大文档从常驻上下文迁到 Skill，并测出前后 token 差
• 能写出一个 return 只回传聚合结果的 PTC 程序
• 能解释 PTC 下审批与钩子为何仍然生效
• 能说出至少 2 个「该删掉的工具」及其依据

延伸阅读