摘要：WorkBuddy 有 46 个本地工具，另有 5 个连接器提供的 33 个方法。这些工具不是平等地摆在模型面前的：常驻上下文、延迟加载、外部连接三层，加载方式不同，占的 token 也不同。这篇文章按层逐个过一遍，讲清每个工具干什么、什么时候会被用到，以及分层背后的代价判断：为什么最常用的那批留在上下文里，为什么方法最多的一层反而最省，第 2 层那条调用路径又省掉了哪一步。
这篇文章把 WorkBuddy 提供的工具过一遍。不是 API 手册，重点在「这个工具干什么、什么时候会被用到」。自己接的 MCP 服务器不在其中，那取决于你接了什么服务，写不成通用清单。
先说一个容易被忽略的事实：这些工具不是平等地摆在模型面前的。它们分三层，加载方式完全不同。理解这个分层，比记住工具名有用得多。
一、三层结构
| 层级 | 数量 | 加载方式 | 代价 |
|---|---|---|---|
| 第 1 层 直接可用 | 23 | 常驻上下文，随时可调 | 每个工具的完整定义都占 token |
| 第 2 层 延迟加载 | 23 | 先用 ToolSearch 取 schema，再执行 | 只在需要时占 token |
| 第 3 层 MCP 连接器 | 5 个连接器 / 33 个方法 | 由外部服务提供，按连接状态可用 | 取决于连接器是否启用 |
分层的逻辑很直白：常用、轻量、判断路径短的放第 1 层；重、贵、低频的放第 2 层；需要外部系统和授权的是第 3 层。
一个反直觉的点：第 3 层有 33 个方法，比前两层各自都多，却最不占常驻上下文。因为工具定义挂在服务端，本地只需要知道「有这么个连接器」。
二、第 1 层：直接可用（23 个）
这一层常驻上下文，随时可调，不用先查定义。
文件与代码（5）
Read— 读文件。纯文本、代码、图片、PDF、Jupyter 笔记本都能读。大文件可以指定起始行和行数，读图片时内容会以视觉形式进入上下文。
Write— 写文件，整文件覆盖。新建文件用它；改已有文件不要用它。
Edit— 精确字符串替换。改已有文件的标准动作，要求原文完全匹配，匹配不上就失败。可以指定全局替换。
Glob— 按文件名模式找文件，比如**/*.tsx。结果按修改时间排序。
Grep— 按文件内容检索，底层是 ripgrep。支持完整正则、按类型过滤、多种输出模式（只给文件路径、给匹配行、给匹配计数）。
找文件用 Glob，找内容用 Grep，改文件用 Edit。这三件事不要拿 Bash 里的 find、grep、sed 代替：功能一样，但这几个工具的结果在界面里可读，权限也可控。
执行（4）
Bash— 跑 shell 命令。当前环境是 Git Bash。工作目录在多次调用之间保持，shell 状态不保持。长任务可以后台运行，完成时会收到通知。
PowerShell— 跑 Windows PowerShell 命令。当前是 5.1 语法，&&、?:、??这些 7.0 才有的写法不能用，逻辑或也一样。非交互模式运行，所以Read-Host、Get-Credential这类会阻塞的命令不能用。
Agent— 派生子代理。子代理有独立的上下文窗口，做完把结论交回来，中间过程不进主上下文。上下文快满的时候，把探索类工作交给子代理是标准解法。可选类型有通用的 general-purpose、勘探代码的 Explore、做方案设计的 Plan、处理表格的 sheet-agent 等。
<
