你的 OpenClaw “龙虾”AI Agent 终于不再’装死’了之案例008

当 AI Agent 调用工具时，你的聊天窗口是静默等待——还是实时看到进展？

从”黑箱”到”透明”

用过 AI Agent 的人，多半经历过这个场景：

你问了一个问题，Agent 决定去查资料。然后——沉默。

10 秒、20 秒、30 秒……聊天窗口一片死寂。你不知道它是在搜索、在思考，还是卡死了。

这个看似微小的问题，在用户体验上其实是个大坑。用户面对一个无声的聊天界面，最自然的反应就是疑虑：”它到底在不在工作？”

旧时代的解法

在 OpenClaw v2026.4.22 之前，AI Agent 在工具调用期间的交互是这样的：

用户提问 → Agent 调工具 → ……无尽沉默…… → Agent 输出完整回复                           ↑ 用户能看到的只有空白

这其实是 Agent 框架技术的”原生痛点”。模型的推理和工具调用，是在服务端一气呵成地完成的——模型决定调用工具 → 框架执行工具 → 拿到结果给模型 → 模型整合回复。这个过程里，框架没有向用户推送中间状态的机制。

为什么不拆开推送？因为过度推送状态更新反而可能导致被用户误以为机器在胡说八道。比如 Agent 先发了一句”我在搜索”，然后沉默 10 秒，用户可能更焦虑了。

更聪明的设计：Tool-Progress Preview Streaming

OpenClaw 在 v2026.4.22 引入的 Tool-Progress Preview Streaming，用了一种更优雅的方式来解决这个问题。

它的核心机制分三步：

第一步：Agent 决定调用工具

当模型在内部决定”我需要查一下 Hacker News”，框架开始介入。

第二步：框架实时推送状态

框架不等模型思考完，先把一条”正在工作”的状态推送到聊天窗口：

🔧 Using: web_fetch...

这不是模型输出的文字——这是 Agent 框架在用户端显示的进度预览。用户一眼就知道：它在查资料，没卡住。

第三步：工具执行 → 继续推送

每次工具调用完成后，框架把结果发给模型，同时继续推送给用户新的状态更新。如果 Agent 连续调用了 3 次 API，用户会看到 3 条逐步展开的进度提示：

🔧 Using: web_fetch...🔧 Using: web_search...🔧 Using: web_fetch...

直到模型输出完最终回复，这些进度状态才被正式回复替换。

这个设计妙在哪里？

1. 防止超时断开

很多聊天平台（比如飞书、Discord 的 Webhook）有超时限制——如果 Agent 超过 10 秒没输出，连接就会断开。Tool-Progress 在工具调用期间主动推送状态，保持连接活跃。

2. 让复杂任务”可见”

当 Agent 需要多次调用工具（搜索 → 查 API → 读文档 → 整合答案），用户能看到完整的执行路径。这不是废话，而是”我在做什么”的透明呈现。

3. 但不是模型在说话

关键区别：模型负责”想”和”写”，框架负责”让用户看到我在想”。

那些 🔧 Using: 的进度提示不是模型输出的自然语言，而是框架在消息最终成型前，先把中间状态推送出去。Claude、ChatGPT 的”我在思考…”是模型自己输出的 Token，而这里的是 Agent 框架的消息编排机制。

版本时间线

你能做什么？

如果你是 AI Agent 的用户：

• • 别再问”它是不是卡死了”——看到 🔧 Using: 就是它在工作
• • 习惯 Agent 的”逐步思考”节奏

如果你是 Agent 的开发者：

• • 在 OpenClaw 中，通过 streaming.preview.toolProgress 配置可以控制是否显示进度
• • 想关闭的话："streaming": { "mode": "partial", "preview": { "toolProgress": false } }
• • 想开箱即用？v2026.4.24+ 默认就是打开的

写在最后

AI Agent 不能只是一个”黑箱”——输入问题，吐出答案。好的设计让用户看到过程，这在 Agent 开发里是一个很重要的命题。

Tool-Progress Preview Streaming 只是 OpenClaw 在打磨 Agent 交互体验上的一步。当 Agent 替你跑十几个工具、爬几十个页面时，你会感谢它主动告诉你”我还活着，正在查资料”。