连载13- 内部Tools，Claude Code 怎么真正"动"你的代码

工具层内核------Claude Code 怎么真正"动"你的代码

AI Coding 系列第 11b 篇 · 工具系统原理

用了一段时间 Claude Code，你大概率遇到过这些困惑：明明可以用 Read 读文件，Claude 有时候用 Bash cat。明明能用 Edit 改一行，它偶尔用 Write 覆写整个文件。你配了三个 MCP server，发现 Claude 变笨了------上下文塞满了你看不到的东西。

这些行为的答案不在你的操作里，在工具系统的设计里。它们都指向同一个核心事实。

工具定义了一个 AI Agent 的可作用范围。 你给 Claude 什么工具，它的世界就有多大。你收回什么工具，它的触手就缩回多远。工具的精度决定它每次动作的精准度。工具的数量决定它每次思考时需要过滤的噪音量。

这篇文章从源码层面拆开这套工具系统------读完你会获得三种能力：预测 Claude 的工具选择、用硬约束替代反复提醒、理解 MCP 为什么有时让你变强有时让你变慢。

MCP（第 11 篇）讲外部能力如何变成工具。本篇讲另一半------内置工具有哪些、它们怎样和 LLM 协作、这套机制对你的协作方式意味着什么。

一、你的 Claude 能碰什么

你以为 Claude Code 只有 Read、Write、Edit、Bash、Grep、Glob 这六个工具？肚子里还藏着二十多个------不是藏起来了，是它们只在特定条件下登场。

三层分类

每天必用的六件套

Read、Write、Edit、Bash、Grep、Glob 覆盖了 90% 的实际操作。官方文档已经讲清楚了每个工具的参数和用法------本篇不重复。本篇讲的是它们之间的选择逻辑和边界设计。为什么 Claude 有时候用 Bash cat 而不是 Read？为什么有时候用 Write 而不是 Edit？答案在第二节和第三节。

你该知道但可能没发现的------这些才是"指挥能力"

Agent 工具启动子进程处理独立任务。它的关键价值在上下文隔离：子 Agent 读 50 个文件做分析，那些内容留在独立上下文里，任务结束就释放，主会话不被污染。这让 Claude 从单兵作战变成了会派活的人。

Task 系列（Create/Get/List/Update）在上下文里维护结构化任务清单------LLM 没有持久记忆，Task 列表是它在窗口里的"现在到第几步了"。Skill 是工具的打包器：指令 + 权限 + 前置知识打包成一个专业模块。AskUserQuestion 让 Claude 在信息不足时反问你。PlanMode 让它先设计再动手。

特殊场景才登场的

EnterWorktree 创建 git 隔离环境。Cron 系列做定时提醒。WebSearch/WebFetch 赋予联网能力。NotebookEdit 处理 Jupyter。TaskStop/TaskOutput 管理异步任务。这些工具在你触发特定场景之前一直休眠。
📂 展开源码：工具注册中心------条件加载的三套机制

typescript 复制代码

// src/tools.ts ------ 不是所有工具每次都在

// 机制一：Feature Flag（编译时死代码消除 ------ feature() 返回 false
// 时，整个 require() 被 Bun 打包器在编译时移除）
const SleepTool =
  feature('PROACTIVE') || feature('KAIROS')
    ? require('./tools/SleepTool/SleepTool.js').SleepTool
    : null

// 机制二：环境检测
// ant-native 构建把 bfs/ugrep 嵌入 bun 二进制 → 不再加载 Glob/Grep
...(hasEmbeddedSearchTools() ? [] : [GlobTool, GrepTool])

// 机制三：运行时开关
...(isTodoV2Enabled()
  ? [TaskCreateTool, TaskGetTool, TaskUpdateTool, TaskListTool]
  : [])
...(isWorktreeModeEnabled() ? [EnterWorktreeTool, ExitWorktreeTool] : [])

你用的 Claude Code 和我用的，工具列表可能不一样------不是 bug，是按需装配。

这时候你可能会想：Bash 一个不就能做所有事吗？ 它能读（cat）、能搜（grep）、能改（sed）、能写（>）。为什么还需要十几个专用工具？

答案藏在"精度"两个字里。专用工具不是 Bash 的快捷方式------它们把 Bash 的能力域拆开，给每一块装上硬边界和精准的错误反馈。往下看。

二、它是怎么碰到的

先纠正一个几乎人人都有过但错误的心智模型。

Claude 不运行任何东西。

它输出一个结构化的"工具使用请求"------{name: "Read", input: {file_path: "/src/foo.ts"}}。Claude Code 的运行时（harness）拦截这个请求，执行真实的工具调用，把结果传回给 Claude。

复制代码

你以为的：Claude 读了 foo.ts
实际发生的：
  Claude 输出 tool_use → Harness 读文件 → Harness 传回内容 → Claude 继续推理

这条分界线是一切安全机制的基础。permissions 不是在"说服 Claude 别做某事"------它是在 harness 层拦截 tool_use 请求。如果你在 settings 里禁了 Bash，harness 在构建系统提示词时直接把 Bash 从工具名单里删掉------模型收到的提示词里根本没有 Bash 这个工具，它甚至不知道世界上存在 Bash。这和"知道有但不准用"是两种完全不同的机制。

一次工具调用的六步路径

scss 复制代码

Claude 模型推理 → 输出 tool_use 块
        ↓
[1] 工具可见性：这个工具在系统提示词里吗？不在 → 模型不可能请求它
        ↓
[2] PreToolUse Hook：有脚本要拦截吗？stdout 内容会传给 Claude 作为决策材料
        ↓
[3] 工具执行：调用工具的 call() 函数------这是唯一真正"做事情"的步骤
        ↓
[4] PostToolUse Hook：后置处理（格式化、lint、日志）
        ↓
[5] 格式化：包装成 tool_result，超大结果写入磁盘而非塞进上下文
        ↓
tool_result 追加到上下文 → Claude 读结果 → 决定下一步

注意步骤 $1$ 和运行时权限拒绝是两层不同的机制。allowed-tools 在提示词构建阶段过滤------工具根本不出现在模型的世界里。权限系统在调用阶段拦截------工具模型知道，但这次不让用。前者是地图上根本没有这条路，后者是这条路前面有个检查站。

每一步都是 harness 在把关。Claude 只做一件事：提议。Harness 决定允不允许、执不执行、结果怎么处理。理解了"提议-执行分离"，你就理解了为什么工具权限是不可绕过的------你不可能请求一个你不知道存在的东西。

工具定义长什么样------模型"看"到的和你不一样

工具定义（名称 + 描述 + 参数 JSON Schema）在每次 API 调用中都随系统提示词发送。Claude 看到的是：

vbnet 复制代码

Tool: Read
Description: Reads a file from the local filesystem. You can access any
file directly by using this tool...
Parameters:
  - file_path (string, required): The absolute path to the file
  - offset (integer, optional, minimum: 0): Start reading from this line
  - limit (integer, optional): Number of lines to read

它看不到 Read 的源码实现------call() 函数怎么处理路径、怎么截断长文件、怎么标记行号，全在 harness 侧。它只能通过描述和 JSON Schema 理解工具的能力。

工具描述的质量，直接决定 Claude 用工具的准确度。 来看一个对比：

arduino 复制代码

差的描述（Claude 不知道怎么用）：
  "查询用户"

好的描述（Claude 知道何时用、怎么用）：
  "查询用户表，按部门名称精确匹配。支持 admin/developer/viewer
   三种角色筛选。返回 JSON 数组，最多 500 条记录。"

差的描述只有 4 个字------Claude 不知道该在什么场景调用、能传什么参数、返回什么。好的描述把使用边界写进了工具定义本身。MCP server 质量参差不齐，根源往往不在代码逻辑------在工具描述写得敷衍。
📂 展开源码：buildTool ------ 所有工具的"Fail-Closed 出厂设置"

每一个工具都通过 buildTool() 工厂函数创建。默认值哲学是"假设不安全，直到被证明安全"：

typescript 复制代码

// src/Tool.ts ------ 所有工具的出厂默认值

const TOOL_DEFAULTS = {
  isEnabled: () => true,
  isConcurrencySafe: (_input?: unknown) => false,  // 默认：不能并行执行
  isReadOnly: (_input?: unknown) => false,          // 默认：会写入
  isDestructive: (_input?: unknown) => false,       // 默认：无破坏性
  checkPermissions: (...) => Promise.resolve({ behavior: 'allow', ... }),
  toAutoClassifierInput: (_input?: unknown) => '',  // 默认：跳过安全分类器
}

export function buildTool<D extends AnyToolDef>(def: D): BuiltTool<D> {
  return {
    ...TOOL_DEFAULTS,                    // 先铺"不安全的"默认值
    userFacingName: () => def.name,
    ...def,                              // 再让工具自己的声明覆盖
  } as BuiltTool<D>
}

设计意图：如果工具作者忘了声明"我是安全的"，系统默认当它不安全处理。 isConcurrencySafe: false 意味着除非工具明确说"我能并行"，harness 不会同时执行它的两个调用------即使模型同时请求了它们。

并行调用：不是 Claude 手快

当 Claude 在一个响应里输出多个 tool_use 时，harness 并行执行它们。你看到"同时读三个文件"------不是模型读得快，是三个 Read 请求同时发出、同时等结果。串行要三个 API 往返，并行只一个。但只有显式声明了 isConcurrencySafe: true 的工具才能享受并行；未声明的工具即使同时被请求，也会被 harness 串行化执行。

三、碰得多精准------每个工具的精度是设计出来的

Bash 一把瑞士军刀能做所有事。但瑞士军刀上的剪刀永远不会比一把真正的剪刀好用。剪刀只有一个功能，所以它可以把那个功能做到极致。

Claude Code 的专用工具同理------Bash 能力域里每一块被单独拎出来、加上硬边界、配上精准错误反馈。精度来自边界。

Read / Write / Edit：三条硬边界

Read 输出带行号。这不是为了"好看"------行号是给后续 Edit 准备的坐标系统。Read 的隐含语义更关键：零副作用 。给子 Agent 配 Read, Grep, Glob，它就物理上不可能修改任何东西------不是要求它别改，是它没有改的能力。

Write 是全量覆写。创建新文件或需要从零重写时最佳。但 Write 有一个隐藏危险：如果 Claude 上下文里只有前 100 行的内容，用它覆写整个文件会把没读到的那 400 行也抹掉。所以当你看到 Claude 修改大文件时用了 Write，要警觉------它可能没有完整读完那个文件。

Edit 是带安全锁的外科手术刀。锁在这里：

typescript 复制代码

// src/tools/FileEditTool/prompt.ts ------ 不遵守就直接报错

function getPreReadInstruction(): string {
  return `- You must use your Read tool at least once in the conversation
before editing. This tool will error if you attempt an edit without reading
the file.`
}

必须先 Read 才能 Edit。 这不是礼貌建议------Edit 工具会直接拒绝执行。为什么？防止 Claude 基于训练数据中可能已过期的代码做修改。LLM 的知识有截止日期，Read 确保它操作的是磁盘上的真实内容。

Claude 对三个工具的选择本身就是它对自己"确定性"的声明：

确定只改一小块 → Edit
整个文件需要重构 → Write
还没想清楚改什么 → 先 Read 再决定
不合理的 Write → 上下文信息不全，黄牌警告

Grep / Glob：比 Bash 干净不是运气

下面两段输出，哪段进入 LLM 上下文后对推理更有用？

Bash grep 的输出（带 ANSI 颜色码）:

bash 复制代码

[35m/src/foo.ts[0m:[1mconst[0m [32mx[0m = ...

Grep 工具的输出（干净格式）:

ini 复制代码

/src/foo.ts:  const x = ...

同样的搜索结果，进入上下文的信息量一样，但第一段有 40% 的字符是噪音。Grep 工具专门为进入 LLM 上下文优化了输出------去掉颜色码、去掉终端格式字符、每行"文件路径:内容"。这不是"碰巧更干净"，是刻意的设计。

更深一层：Claude 对工具的"偏好"根本不是训练中学会的。系统提示词写死了：
📂 展开源码：Bash 系统提示词------工具偏好的真正来源

typescript 复制代码

// src/tools/BashTool/prompt.ts ------ Claude 收到的 Bash 说明书

const toolPreferenceItems = [
  `File search: Use Glob (NOT find or ls)`,
  `Content search: Use Grep (NOT grep or rg)`,
  `Read files: Use Read (NOT cat/head/tail)`,
  `Edit files: Use Edit (NOT sed/awk)`,
  `Write files: Use Write (NOT echo >/cat <<EOF)`,
  'Communication: Output text directly (NOT echo/printf)',
]

不是模型"更聪明地选择了工具"------是系统提示词教它这么选的。当你发现 Claude 开始频繁用 Bash 替代专用工具时，通常意味着上下文太长，提示词指令被稀释了。

Agent / Skill：调度也是一种"碰"

Agent 工具启动子进程处理独立任务。核心价值如第一节所述------上下文隔离。子 Agent 读 50 个文件，那些内容释放后不污染主会话。这让 Claude 从操作员变成了工头：不是亲自做所有事，是判断什么任务该分派给谁。

Skill 是工具 + 指令 + 权限的预打包模块。Claude 调用 Skill 时不是"用一个新工具"，是"加载一套专业行为模式"。

这两个工具把 Claude 的能力边界从"我能直接做什么"扩展到了"我能调度和组织什么"。

Bash：瑞士军刀的另一面

回到瑞士军刀。它什么都能做------但如果刀片没有安全锁，它也是整把刀上最危险的部分。

Bash 是唯一能执行命令的工具。没有替代品。一行命令能读文件、写文件、删文件、联网、装包。每个专用工具都有硬边界------Read 只能读，Write 只能写，Edit 只能替换。Bash 没有边界。

去掉 Bash，Claude 就从"能做事的 Agent"变成"只能看和说的顾问" ------这是最粗粒度的开关。更精细的控制靠 PreToolUse Hook：拦截 npm install、git push --force 等特定模式，而不禁用整个 Bash。

四、碰得到多远------当 MCP 把外部也变成工具

内置工具让 Claude 碰到本地文件系统和 shell。MCP 让这个范围扩展到任意外部系统。（MCP 的完整机制、安全模型和决策框架见第 11 篇------本节只从"工具池统一"这一个角度补充一个细节。）

从 Claude 模型的视角看，Read（读本地文件）和 mcp__postgres__query（查远程数据库）没有任何区别。都是一个函数名，一组参数，一个返回值。不是设计偷懒------是刻意为之。

统一工具池意味着同一套权限模型管所有工具，同一套 Hook 机制拦截所有调用，同一个 Agent 分配逻辑对内置和 MCP 一视同仁。你不需要学两套规则。
📂 展开源码：assembleToolPool ------ 统一合并不是简单贴到一起

typescript 复制代码

// src/tools.ts ------ 内置工具和 MCP 工具的统一合并

export function assembleToolPool(
  permissionContext: ToolPermissionContext,
  mcpTools: Tools,
): Tools {
  const builtInTools = getTools(permissionContext)
  const allowedMcpTools = filterToolsByDenyRules(mcpTools, permissionContext)

  // 内置工具排前面 → 各自按字母排序 → 同名冲突内置优先
  const byName = (a: Tool, b: Tool) => a.name.localeCompare(b.name)
  return uniqBy(
    [...builtInTools].sort(byName).concat(allowedMcpTools.sort(byName)),
    'name',
  )
}

sort(byName) 不是为了好看------是为 prompt cache 稳定性。如果工具顺序每次随机变动，Anthropic 的 prompt cache 无法命中。按字母锁定顺序后，只要工具列表不变，cache key 就不变。

后果很直接：MCP 把 Claude 能碰到的世界扩展到了你配置的任意外部服务。不加 MCP，代码审查 Agent 永远碰不到 GitHub。配了 GitHub MCP，审查 Agent 就能直接读 PR。不加数据库 MCP，数据分析 Agent 只能分析你手动喂的 CSV。配了 Postgres MCP，它能直接跑 SQL。

但这个扩展不是免费的------第六节讲代价。

五、收紧触及范围------硬约束 vs 软约束

CLAUDE.md 里写一句"请勿修改 config 目录"------这是软约束。Claude 可能在长对话中遗忘、可能在上下文稀释后忽略、可能在复杂推理链中被绕过。

allowed-tools: Read, Grep, Glob------这是硬约束。子 Agent 收到的系统提示词里根本不出现 Bash、Write、Edit。模型不知道这些工具存在，就不可能请求调用它们。

CLAUDE.md 是建议。工具权限是物理定律。 建议可以被遗忘。物理定律不会。
📂 展开源码：Agent 工具权限的精确控制

typescript 复制代码

// src/constants/tools.ts ------ 工具权限在这里定义

// 所有子 Agent 绝对不能用的工具（黑名单）
export const ALL_AGENT_DISALLOWED_TOOLS = new Set([
  TASK_OUTPUT_TOOL_NAME,       // 防止递归
  EXIT_PLAN_MODE_V2_TOOL_NAME, // Plan 模式只给主线程
  ENTER_PLAN_MODE_TOOL_NAME,
  AGENT_TOOL_NAME,             // 禁止套娃（ant 用户除外）
  ASK_USER_QUESTION_TOOL_NAME, // 子 Agent 不能跟用户对话
  TASK_STOP_TOOL_NAME,         // 依赖主线程任务状态
])

// 异步 Agent 只给白名单上的工具------不在名单上的一律不存在
export const ASYNC_AGENT_ALLOWED_TOOLS = new Set([
  FILE_READ_TOOL_NAME, WEB_SEARCH_TOOL_NAME, GREP_TOOL_NAME,
  WEB_FETCH_TOOL_NAME, GLOB_TOOL_NAME, ...SHELL_TOOL_NAMES,
  FILE_EDIT_TOOL_NAME, FILE_WRITE_TOOL_NAME, ...
  // Agent、TaskOutput、AskUserQuestion ------ 全部不在名单上
])

异步 Agent 用的是白名单------只给约 15 个工具。不在名单上，模型的世界里就不存在这个东西。和"允许全部然后逐个禁止"（黑名单模式）是两种完全不同的安全哲学：白名单 = 只允许已知安全的。黑名单 = 只禁止已知危险的。

收紧范围的实践公式

想让 Claude 不联网 → 去掉 WebSearch、WebFetch。想让 Claude 不能写文件 → 去掉 Write、Edit。想让 Claude 不能装包 → PreToolUse Hook 拦截 npm install 和 pip install。想让子 Agent 只能看不能碰 → allowed-tools: Read, Grep, Glob。

每去掉一个工具，Claude 的可作用范围就缩小一块。同时：少了一份工具定义的 token 开销，少了一个可能被攻击的入口，少了一次 Claude 选错工具的机会。

能力的收束，往往也是安全的增益和性能的释放。

六、每一寸范围都有代价

工具不是免费的。两种成本都在暗处扣减你的实际体验。

工具定义本身的 token 税

每次 API 调用，所有可用工具的名称、描述、参数 JSON Schema 都原封不动地发送。以 Read 工具为例，其 description + 参数 schema 约 180 tokens。getAllBaseTools() 源码中定义了 54 个工具位（含 Feature Flag 控制、ant 专属等条件加载项），一个标准外部用户实际可见约 30-35 个内置工具。平均每个工具约 150-200 tokens 的定义开销，合计约 5,000-7,000 tokens。

加上 MCP：一个典型的 MCP server 暴露 30-50 个工具，每个工具的定义平均 200-300 tokens（MCP 工具的 JSON Schema 通常比内置工具更冗长）。3 个 MCP server × 35 个工具 × 250 tokens = 约 26,000 tokens。

内置工具 ~6,000 + MCP ~26,000 = 约 32,000 tokens 的工具定义开销。 在 200K 上下文中，这是 15%。Perplexity 在 2026 年 3 月宣布放弃 MCP 集成时的核心数据更极端：工具定义消耗了 72% 的上下文窗口。这就是为什么 /mcp disable 不用的 server 不是"整理配置"------是释放推理空间给真正的任务。

工具结果的上下文累积

每次工具调用，输出都追加进上下文。读 50 个文件 → 50 个文件的全量内容留在窗口里。这就是"把大量文件读取交给子 Agent"的技术理由------子 Agent 的上下文独立，任务完成就释放，主会话保持干净。

stdout 和 stderr 的区别------一个常踩的坑

Bash 执行后，stdout 的内容进入上下文给 Claude 看，stderr 的内容只在终端显示。写 PreToolUse Hook 时，如果你想让 Hook 的反馈成为 Claude 决策的材料------输出到 stdout。如果只是给人看的审计日志------输出到 stderr。

很多人写了 Hook 发现"Claude 没有按预期停下来"，根因是把拦截信息输出到了 stderr。Claude 没看到，自然没反应。

七、知道这些之后------从诊断到验证的五步行动链

前面六节建立理解。这一节不是五个并列建议------是从诊断到优化的递进行动链。每一步都因为"工具定义了可作用范围"这个核心事实。

第一步：通过工具选择诊断 Claude 的状态

因为你知道了工具的范围和精度是怎么设计的，所以你能从它的选择中读出状态。

Claude 选 Edit 改一个函数 → 它清楚改动范围，对文件内容有信心。Claude 选 Write 覆写一个只读了前 100 行的大文件 → 上下文可能不完整，黄牌警告。Claude 用 Bash cat 而不是 Read → 上下文可能太长，工具描述指令被稀释了。

同一个任务（"修改 foo.ts 的 getUser 函数"），三条工具路径对应三种状态：

理想路径：Read foo.ts → 确认目标区域 → Edit 精确替换（上下文充足、工具描述清晰）
防御路径：Read foo.ts → Grep 定位多处引用 → 逐块 Edit（改动点多、需验证影响面）
退化路径 ：Bash cat foo.ts → Bash sed 替换（上下文过长，提示词中的工具偏好指令被稀释）

学会读工具调用序列，就像老运维读系统日志------模式里藏着状态。

第二步：用反馈环让 Claude 自动修正

因为你知道了工具的输出会进入上下文成为 Claude 的决策材料，所以你知道：让 Claude 变聪明的最好方式不是更长的提示词，是让它的每个动作都能看到后果。

改完代码 → PostToolUse Hook 跑类型检查 → 错误进入上下文 → Claude 把它当新的输入信息 → 自动修正。这个过程不需要你干预。关键不是 Hook 自动跑了------是 Hook 的输出成了 Claude 无法无视的上下文事实。对 Claude 来说，tsc --noEmit 的错误输出和你说"这里有类型错误"是同一类东西。

如果你靠提示词写"请检查类型"------Claude 可能在 10 轮对话后忘记。但 PostToolUse Hook 的输出每一次 Write/Edit 后都被追加到上下文。构建 Hook，本质上是为你和 Claude 之间的信息通道增加一条自动化水管。

第三步：用硬约束替代反复提醒

因为你知道了工具权限是物理定律而 CLAUDE.md 是建议，所以你会优先用工具层解决问题。

想让 Claude 不碰敏感文件？三层递进：

子 Agent 级 ：allowed-tools: Read, Grep, Glob（文件完全不可写------最强）
Hook 级：PreToolUse Hook 拦截特定路径的 Write/Edit（精准拦截------次强）
CLAUDE.md 级：写规则（兜底------最弱）

第四步：管理"范围-成本"的平衡

因为你知道了每一个工具都在交 token 税，所以你不会无限扩张工具集。

内置工具集约消耗 5,000-7,000 tokens（源码定义了 54 个工具位，外部用户实际可见约 30-35 个）。每加一个 MCP server，额外消耗数千到数万 tokens 的工具定义。不常用的 MCP server 用 /mcp disable 关掉。大量文件阅读交给子 Agent------它的上下文独立，用完释放。MCP vs CLI 的决策参照第 11 篇第六节的速查表：如果只有你一个人偶尔用一次，CLI 通常更快；如果多人复用同一套接口，MCP 的标准化收益才能摊薄固定成本。

少一个工具，少一份上下文税。减一种能力，增一分推理空间。

第五步：亲手验证

打开 Claude Code，用三个微型实验亲眼看到这篇文章描述的现象：

让 Claude 改一个小函数------看它用 Edit 还是 Write
让 Claude 搜一个函数定义------看它用 Grep 还是 Bash grep
创建 allowed-tools: Read, Grep, Glob 的子 Agent，让它改一个文件------看它怎么回应

每个行为你现在都能解释为什么。不是 Claude 这次不一样了------是它可作用范围的边界在那里。

本篇实践任务

任务一：读一次工具调用序列（15 分钟）

回顾你最近一次用 Claude Code 完成的非平凡任务。列出它用了哪些工具、什么顺序、每次调用的结果有没有改变后续计划。识别它的工具路径属于第七节描述的"理想 / 防御 / 退化"中的哪一种。如果出现退化路径，检查你的 MCP 配置和上下文长度。

任务二：验证"硬约束"（10 分钟）

创建一个 allowed-tools: Read, Grep, Glob 的子 Agent，让它改一个文件。它会不会尝试调用 Edit？还是直接告诉你做不到？这直接验证了第五节的论点：不允许的工具在模型世界里根本不存在。

任务三：配一个即时反馈环（5 分钟配置 + 10 分钟观察）

给 Write/Edit 配一个 PostToolUse Hook：TypeScript 用 tsc --noEmit，Python 用 ruff check，Go 用 go vet。故意让 Claude 写一段有类型错误的代码。观察：错误输出进入上下文后，Claude 是不是自己就修正了？

任务四（进阶）：审计你的工具集

列出你启用和禁用的 MCP server。逐一用第二节的方法估算 token 开销：平均每个 MCP 工具约 200-300 tokens，乘以工具数量。禁用至少一个最近一周没用过的 server，感受 Claude 的反应速度和回答质量变化。

下篇预告

工具系统的内核已拆透------Claude 能碰什么、怎么碰、碰多精准、碰多远、怎么收紧、代价是什么。

下一篇讲日常工作中的操作模式------Sub-agent 在不同场景的最佳配置、怎么用 Task 清单组织复杂任务、工具权限的组合策略。从"理解工具系统"到"让这套系统每天为你工作"。

第 11 篇（MCP）→ 外部工具怎么变成 Claude 的手。第 11b 篇（本篇）→ Claude 的手怎么设计、怎么运作。第 12 篇 → 怎么用好这些手。

工具不是 AI 的附属品。工具是 AI 能触达真实世界的唯一介质。理解工具系统，就是理解 AI Agent 的能力边界------以及你在这个边界上拥有的控制权。