工具让 Agent 从“回答问题”变成“完成任务”。但工具也会带来风险：读错文件、改错配置、调用外部接口、重复执行昂贵操作。一个简短的工具清单可以避免很多低级错误。

1. 这一步真的需要工具吗

有些问题靠已有上下文就能回答，有些问题必须查实时状态。判断标准可以很简单：如果事实会变化，就尽量用工具确认；如果只是解释概念，就不必制造额外操作。

2. 先读后写

涉及文件、配置、数据库、远程服务时，优先做只读检查。先确认当前位置、当前版本、当前状态，再决定是否修改。

这能避免两类问题：

  • 对错误对象执行操作；
  • 用过期记忆覆盖真实状态。

3. 写操作是否可回滚

写操作之前需要想清楚回滚方式。可回滚的操作可以更果断；不可回滚的操作应该停下来确认。

常见回滚方式包括：

  • 备份原文件；
  • 保留旧目录；
  • 使用版本控制；
  • 记录执行命令；
  • 准备恢复脚本。

4. 验证是否足够小

完成任务后不一定要跑完整测试，但至少要有一个最小验证。例如网页部署后检查首页、关键资源、错误路径；代码修改后跑对应单测或构建。

验证不是形式，它是“任务已经完成”的证据。

5. 是否需要告诉用户

不是每个工具调用都需要汇报。但如果发生了外部变更、风险变化、失败或需要用户决策，就应该明确说明。

工具清单的价值在于让 Agent 稳定地慢半拍：不是拖延，而是在动手前确认方向。