模型判断该回答、该读文件，还是该执行动作。
Tool：Agent 真正执行动作的接口
约 1345 字大约 4 分钟
2026-05-25
Tool 是 Agent 把计划变成动作的接口。读文件、改代码、跑命令、查资料、调用 API，都通过工具完成。
TOOL LOOP
Tool 是 Agent 的手，能做事，也最容易把错误放大。
模型本身只会生成文本。真正会改动项目状态的是 Tool 调用，所以你要看的不是“它说了什么”，而是“它准备怎么做、做完看到了什么”。文件、Shell、浏览器、检索、Git 或外部 API。
路径、命令、URL、查询条件、目标文件。
真正产生副作用的一步，比如改文件、跑命令、点页面。
stdout、diff、截图、报错、页面变化。
继续修正、请求确认，或明确说明已经完成。
COMMON TOOLS
- 文件工具读文件、改文件、应用 patch容易误改无关文件或覆盖用户修改。
- Shell安装依赖、启动项目、跑测试容易执行高风险命令或污染环境。
- 浏览器打开页面、点击、截图、验证 UI容易碰登录态、隐私和误操作。
- Git / 外部 API看状态、提交、推送、调用业务接口容易带上无关改动、碰生产、泄露密钥。
HIGH RISK
- 删除文件或大范围移动目录
- git reset / 强制推送 / 覆盖工作区
- 全局安装依赖或改系统环境
- 访问网络、上传内容、调用生产接口
- 修改部署、CI、环境配置或密钥相关文件
为什么需要 Tool
模型只会生成文本。Tool 让它能观察环境、执行动作、看到结果，再根据结果调整下一步。没有 Tool，Agent 只能“建议”；有 Tool，Agent 才能真正“做事”。
也正因为这样，Tool 是 Agent 执行链里最需要被监督的一层。你不能只看它最后说了什么，还要看它准备用哪个工具、带什么参数、造成什么副作用，以及结果是否真的支持下一步判断。
常见工具类型
| 类型 | 典型动作 | 风险 |
|---|---|---|
| 文件工具 | 读文件、改文件、应用 patch | 误改无关文件、覆盖用户修改 |
| Shell | 安装依赖、启动项目、跑测试 | 执行危险命令、污染环境 |
| 浏览器 | 打开页面、点击、截图、检查布局 | 登录态、隐私、误操作 |
| 检索 | 搜索文档、读取官方资料 | 资料过期、来源不可靠 |
| 图像 | 生成图片、编辑素材、识别截图 | 版权、风格不一致 |
| Git | 查看状态、提交、推送 | 包含无关改动、错误分支 |
| 外部 API | 调业务服务或第三方接口 | 密钥、费用、生产影响 |
调用闭环
一个成熟的 Tool 调用不只是“执行命令”。它至少要经过这几个阶段：
- 模型先判断现在是该回答、该读文件，还是该执行动作。
- 选对工具，并准备清楚参数。
- 执行动作，接受真实副作用。
- 观察结果，包括 stdout、diff、截图、报错和页面变化。
- 决定下一步是继续修正、请求确认，还是明确交付。
少任何一步，Tool 都可能从“推进任务”变成“扩大错误”。
监督清单
当 Agent 发起 Tool 调用时，你最应该看的是下面几件事：
它为什么要用这个工具是真的需要读文件、跑命令，还是其实直接回答就够了？参数是不是清楚路径、命令、URL、目标文件、查询条件是否明确？副作用在哪里会不会改文件、碰网络、改 Git 状态、接生产系统？结果够不够支撑下一步它拿到的输出，能不能真正说明问题？
只要这四件事没看清，就不应该把 Tool 调用当成“正常推进”。
最小示例
下面这个例子比抽象解释更能说明 Tool 调用到底在干什么：
请检查 README 里的启动命令是否和 package.json 一致。
如果不一致，先解释差异，不要直接改文件。一次合理的调用过程通常会是：
- Agent 先判断：这不是单纯回答问题，必须读文件。
- 它选择文件读取类 Tool。
- 参数会落到
README.md和package.json这样的具体文件上。 - 读取结果回来后，它再比较命令是否一致。
- 如果发现差异，先解释；如果你允许修改，再进入下一步动作。
这个例子里，关键不是“它会不会比较字符串”，而是它有没有：
- 选对 Tool
- 读对文件
- 把结果解释清楚
- 在修改前停下来让你确认
高风险动作
有些 Tool 调用风险明显更高，应该默认提高审查强度：
- 删除文件或大范围移动目录
git reset、强制推送、覆盖工作区- 全局安装依赖或改系统环境
- 访问网络、上传内容、调用外部 API
- 修改部署、CI、环境配置或密钥相关文件
监督重点
当 Agent 准备删除文件、重置 Git、全局安装、访问网络、上传内容或修改部署配置时，应该要求它先解释影响和回滚方式。
调用失败时怎么处理
Tool 调用失败并不罕见，关键是不要让失败结果直接滑进下一轮，变成更大的误判。
遇到下面几种情况时，处理方式应该更明确：
输出不完整让 Agent 重新解释它刚才看到了什么，不要直接继续下一步。改动范围过大中断任务，要求缩到单文件、单模块或单命令级别。命令失败先看原始报错，再让 Agent 说明失败原因和可能修复路径。你看不懂参数或影响先拒绝执行，让 Agent 用中文解释会碰哪些文件、目录、环境或服务。
稳定协作不是“永远不失败”，而是失败时能及时停住，并把问题重新压回一个可判断的范围里。
Tool 与 MCP / Hook 的关系
Tool 负责动作，MCP 扩展动作来源，Hook 控制动作风险。
Tool是动作接口，本身负责读、写、查、跑。MCP让外部系统能力也能以 Tool、Resource 或 Prompt 的形式接进来。Hook在 Tool 调用前后加检查点，比如拦危险命令、补规则、跑验证。
如果把 Agent 比作一个执行者，Tool 是它的手，MCP 是它连接外部系统的接口层，Hook 是它动作前后的安全检查。
