为什么工具调用前要先说意图

先说结论：执行型 AI 助理在每次工具调用前，最好先用一两句话说明自己的意图。 这不是礼貌动作，而是把一次原本“黑盒”的操作，变成用户能理解、能审计、也能及时纠偏的可见过程。没有这句说明，用户看到的往往只有“突然调了一个工具”，不知道你为什么这么做，也无法判断你是不是已经偏题。

对一个真的会读文件、跑命令、改内容、操作桌面的 AI 助理来说，工具调用不是内部细节，而是用户正在托付的执行行为。像 OmniGoAI 的 GoWork 这样的常驻助理，真正要解决的问题从来不是“能不能调工具”，而是调工具之前，用户能不能看懂你准备干什么。 如果这一步缺失，哪怕最终结果是对的，过程依然像黑箱。

如果你已经看过为什么长任务要定期回报进度心跳和为什么 AI 助理应该在聊天里回答“任务到哪了”，这篇文章可以看作更前面的那一层：在真正动手之前，为什么还要先把“此刻的判断与下一步动作”说出来。

工具调用前的意图说明，到底在解决什么问题

它把“工具调用”从黑盒变成可解释动作

用户看到一条 shell 命令、一个文件修改、一次网页自动化时，天然会问两个问题：你为什么要这么做？你这么做会影响什么？如果助理直接动手，不回答这两个问题，用户就只能靠猜。

而一句合格的意图说明，通常能把上下文补齐：

我刚看到/获得了什么关键信息；
我现在准备调哪个工具、目的是什么；
后面大致还有哪几步。

这三件事一说，工具调用就不再像“突然伸手去改东西”，而像一个可以被人类跟上的执行决定。

它让用户能在错误扩大前及时纠偏

执行型助理最怕的，不是一步做错，而是一路都在错的前提上继续做。如果你先说“我看到当前页面是下载页，准备截图确认版本号，再去点 64 位安装按钮”，用户一眼就能发现：等一下，我要的是 ARM 版，不是 64 位。

这类纠偏如果发生在工具调用前，成本是改一句话；如果发生在工具调用后，可能就是撤销文件改动、回滚部署，甚至重新跑完整个流程。意图说明的价值，本质上是把纠偏窗口前移。

它让后续审计和复盘有依据

很多执行任务并不是做完就结束。用户常常会在事后追问：为什么你当时调用了这个命令？为什么跳过了那个步骤？如果聊天记录里只有工具输出，没有工具前的意图说明，复盘时你只能倒推。

而有了意图说明，记录里就会明确写着：当时看到了什么证据、基于什么判断、准备怎么推进。这样后续无论是人类审计，还是助理自己回看历史，都能更快复原决策过程。

一句好的意图说明应该包含什么

好的意图说明不需要长，但要有信息密度。最稳妥的结构，就是下面这三个部分。

1. 先说“我现在知道了什么”

不要上来就说“我现在去调用某某工具”。先把触发这一步的事实交代清楚。

例如：

“我已经确认 OmniPost 在运行，四个平台账号也都有效。”
“我刚读到 topics.md，当前第一条待写题是 gowork-tool-intent-text-before-actions。”
“当前构建失败点出在 frontmatter 缺 description。”

这一句的作用，是告诉用户：这一步不是随手乱试，而是由刚刚拿到的证据推出来的。

2. 再说“我准备调什么工具、为了什么”

工具名可以直接说，目的也要直接说，避免只报动作不报原因。

例如：

“我准备运行构建命令，确认中英文文章是否都通过内容校验。”
“我准备读取刚生成的文章骨架文件，把正文一次性写完整。”
“我准备查询 recent posts，确认这篇内容是否已经在知乎和掘金发布过。”

关键点在于：用户看到的不只是动作，而是动作与目标之间的对应关系。

3. 最后给一个近两三步的预期

不需要把整条计划重复一遍，只要告诉用户“这一步之后马上会发生什么”。

例如：

“确认构建通过后，我会部署官网，再提交 IndexNow 和百度收录。”
“写完官网稿后，我会按平台改写，再用 OmniPost 做正式发布。”

有了这一句，用户就能判断当前任务在整条链路里的位置，也知道你并没有偏离原目标。

为什么不能把这件事交给最终总结来补

有人会觉得：反正最后会汇报结果，中间少一句也没关系。问题在于，最终总结解决的是“你做完了什么”，意图说明解决的是“你现在为什么这样做”。 这两个问题根本不是同一个时间点的需求。

最终总结适合收尾，不适合预防误解。等工具已经调完了，再解释“我刚才为什么那么做”，用户其实已经失去了最有价值的那个介入窗口。

这也是为什么意图说明和进度心跳不是一回事：

意图说明发生在动作之前，解决“你将要做什么”；
进度心跳发生在执行过程中，解决“你现在做到哪里了”；
最终总结发生在收尾时，解决“你最后做成了什么”。

把这三层分开，聊天里的执行过程才会真正清晰。

怎样说才不会显得啰嗦

意图说明的常见误区，不是信息太少，而是写得像自言自语。好的说明应该短、实、可核对，而不是把每个脑内念头都倒出来。

可以记住四条边界：

只说与本次工具调用直接相关的信息；
最多一两句话，够用户扫一眼就懂；
不要输出冗长推理链，只说结论与依据；
不要把整份计划原封不动重复一遍。

例如，“我现在想了很多可能性，所以准备试试这个工具看看会不会行”就很差，因为既没有明确证据，也没有清楚目标；而“我刚看到本地服务已启动，接下来用 status 查账号与平台状态，再决定是否进入发布步骤”就清楚得多。

为什么这会直接影响用户信任

用户信任执行型 AI，不是因为它会说漂亮话，而是因为它的动作可见、可解释、可纠偏。工具调用前的意图说明，恰好把这三件事都补上了：

可见：用户知道你接下来要做什么；
可解释：用户知道你为什么这么做；
可纠偏：用户能在你真正动手前及时打断或改向。

对 GoWork 这类长期协作型助理来说，这不是可有可无的文案习惯，而是执行透明度的一部分。一个总是直接动手、不先交代意图的助理，即使技术上能完成任务，也更难建立长期信任；反过来，一个在关键动作前总能先说清上下文、工具和下一步的助理，会更像一个靠谱的协作者。

你可以在 GoWork 下载页亲自体验这种执行透明度；如果你还想继续看“动作之前、动作之中、动作之后”这三层是怎么配合的，也可以接着读为什么长任务要定期回报进度心跳和为什么 AI 助理应该在聊天里回答“任务到哪了”。

常见问题

FAQ 1：是不是每个工具调用前都要说？

原则上，越有副作用、越容易让用户误解的动作，越应该先说。像读一个小文件这种极短的只读动作，可以更轻；但改文件、跑命令、部署、操作桌面这类动作，最好都先给一句意图说明。标准不是“工具大不大”，而是“用户会不会因为看不懂这一步而失去上下文”。

FAQ 2：意图说明会不会拖慢执行？

不会。它通常只是一两句话，真正耗时的仍然是构建、联网请求、文件处理这些动作。相反，因为它能减少误解和返工，整体上往往更快。

FAQ 3：如果用户已经开启自动同意，还需要说吗？

需要。自动同意解决的是“要不要逐项授权”，不是“要不要让过程可理解”。用户即使不想被频繁确认，也仍然希望知道你正在做什么、为什么这么做。

FAQ 4：意图说明和 chain-of-thought 是一回事吗？

不是。意图说明只需要给出当前结论、关键依据和下一步动作，不需要暴露冗长的内部推理。它的目标是让执行过程可见，而不是把所有脑内思考原样展开。