WinClaw血泪史：一次"写博客"请求如何让AI陷入工具滥用的死亡螺旋？

本系列是AI agent中高级开发者非常受益的开发经验，新鲜火辣出台，献给开发者马年的礼物！

摘要：当OpenClaw在macOS上优雅地处理复杂任务时，我们在Windows平台打造的WinClaw却遭遇了一场噩梦——一个简单的"写博客"请求，竟让AI调用了天气、图片生成、文档组装等完全无关的工具，并陷入无限循环。本文深度剖析这场"工具滥用灾难"的始作俑者：全量Schema传递机制。本文为系列5篇中的第一篇。

关于 WinClaw

WinClaw 是一款基于大语言模型的轻量级 Windows 桌面 AI 助手，能够通过自然语言指令帮助用户完成各种 Windows 操作任务。支持多模型接入（DeepSeek、OpenAI、Claude 等），提供 CLI 终端模式和 GUI 图形界面模式。

🔗 项目地址：https://github.com/wyg5208/WinClaw.git

WinClaw vs OpenClaw：两条不同的路

核心差异：OpenClaw 通过成熟的 tool-display.json 配置层实现了工具的分层管理和权限过滤，而 WinClaw 在追求轻量化的过程中，采用了全量 Schema 传递的简化方案——这正是本次灾难的根源。

一、一个"诡异"的测试案例

1.1 噩梦般的真实对话

某天，我们向WinClaw提出了一个简单的请求：

用户：“用 mcp_browserbase-csdn 帮我在 CSDN 写一篇博客”

预期行为：调用 mcp_browserbase-csdn 工具，打开CSDN编辑器，写入博客内容，发布。

实际发生的情况却让我们目瞪口呆——AI完全陷入了"工具滥用"的恶性循环：

AI: 我来帮您在 CSDN 写一篇博客。首先，我需要创建一个浏览器会话并登录 CSDN。
    [调用: mcp_browserbase_session_create]
    
AI: 现在让我导航到 CSDN 网站...
    [调用: browser_navigate]
    
AI: 让我观察一下页面，看看登录按钮在哪里...
    [调用: browser_observe]
    
AI: 看起来 API 有问题。让我先截图看看当前页面状态...
    [调用: screen_capture] ← 偏离主线
    
AI: 我来帮你创建一个包含天气、诗歌和图片的文档...
    [完全偏离用户意图！开始执行"文档组装"任务]
    
AI: ## 第一步：分解任务
    我需要：
    1. 查询北京今天的天气信息
    2. 创作一首关于春天的诗歌
    3. 生成一张春天的图片
    4. 将所有内容组合成Word文档
    
    [调用: weather_get_weather] ← ？？？
    [调用: image_generator_generate] ← ？？？
    [调用: doc_generator_generate] ← ？？？

AI完全"失忆"了！ 它忘记了用户只想"在CSDN写博客"，反而开始执行完全不相关的"文档组装"任务，而且陷入了无限循环——同样的"分解任务→并行执行"流程重复了3次！

1.2 工具调用日志分析

查看后台日志，情况更加触目惊心：

[Step 1] 调用: mcp_browserbase_browserbase_session_create
[Step 1] 调用: cron_create_job           ← ？？？
[Step 1] 调用: screen_capture             ← ？？？
[Step 2] 调用: mcp_browserbase_stagehand_navigate
[Step 2] 调用: notify_send                ← ？？？
[Step 3] 调用: weather_get_weather        ← 完全无关！
[Step 3] 调用: image_generator_generate   ← 完全无关！
[Step 4] 调用: doc_generator_generate     ← 完全无关！
...（循环重复）

AI同时调用了4-5个工具！ 其中 cron_create_job（定时任务）、screen_capture（截图）、weather（天气）、image_generator（图片生成）与"写博客"毫无关系。

1.3 问题有多严重？

更糟糕的是，这种现象并非个例。我们收集了一周的运行数据：

约28%的工具调用与当前任务无关！

二、追根溯源：全量Schema的"诱惑"

为什么AI会乱调工具？我们深入分析后发现，问题的根源在于：全量工具Schema传递。

2.1 什么是全量Schema传递？

每次用户发请求时，系统会将所有可用工具的完整定义发送给模型：

# 典型的工具Schema结构
tools = [
    {"type": "function", "function": {
        "name": "browser_open_url",
        "description": "打开指定URL...",
        "parameters": {...}
    }},
    {"type": "function", "function": {
        "name": "cron_create_job", 
        "description": "创建定时任务...",
        "parameters": {...}
    }},
    # ... 还有58个工具
]

2.2 Token消耗惊人

我们测算了一个典型请求的Schema开销：

15,000 tokens！ 相当于白白消耗了整个对话的1/4上下文窗口。

2.3 心理学视角：选择悖论

更隐蔽的问题在于AI的"决策心理"。当模型看到60个工具时：

这就像一个人走进超市，面对60种酱油，反而更难做出选择——甚至可能拿错。

三、问题的连锁反应

全量Schema传递不仅导致工具滥用，还引发了一系列连锁问题：

3.1 上下文窗口压力

3.2 意图识别的浪费

WinClaw已经有完善的意图识别系统（detect_intent），但识别结果只用于构建System Prompt，从未用于过滤工具Schema：

# 当前流程（问题所在）
intent = detect_intent(user_input)  # 识别出"浏览器任务"
system_prompt = build_prompt(intent)  # 构建相关提示词
tools = get_all_tools()  # ❌ 仍然返回所有60个工具！

意图识别的价值被完全浪费了。

3.3 错误恢复困难

当AI调用错误工具后，错误信息往往是模糊的：

[错误] MCP工具调用失败: Connection refused

模型不知道：

• 是哪个工具出了问题？
• 应该用什么替代方案？
• 下一步该做什么？

四、从数据看问题：TaskTrace追踪报告

我们在Phase 7实现了TaskTrace全链路追踪系统，收集了一周的实际运行数据：

📊 总计: 6 条记录
📅 时间范围: 2026-02-16

🔧 工具使用分析
  总调用次数: 45
  唯一工具数: 18
  使用频率:
    - browser_open_url: 12 次 (成功率: 1.0)
    - browser_get_text: 12 次 (成功率: 1.0)
    - browser_type_text: 2 次 (成功率: 0.0) ← 超时失败
    - browser_use_run_task: 1 次 (成功率: 0.0) ← 超时失败

❌ 失败分析
  常见错误:
    - Page.fill: Timeout 30000ms exceeded: 2 次
    - "ChatOpenAI" object has no field "provider": 1 次

关键发现：浏览器操作工具占主导（24/45次调用），但同时存在无关工具调用和超时失败。

五、问题本质：架构层面的缺失

通过深入分析，我们识别出三个核心问题：

5.1 Schema传递策略缺失

5.2 工具管理规范缺失

新增工具时，没有标准化的流程确保：

• 意图-工具映射表更新
• Schema描述优化
• 依赖关系定义

5.3 反馈追踪缺失

没有系统化的方式收集：

• 哪些工具被错误调用
• 意图识别准确率
• 任务完成率

六、下一步：寻找解决方案

面对这些问题，我们开始了艰难的方案探索之旅。核心矛盾在于：

如何减少工具选择空间，又不影响模型完成复杂任务的能力？

这个问题的答案，我们将在后续文章中逐步揭晓。

总结

本文揭示了一个看似简单但影响深远的问题：工具数量与决策质量的负相关关系。

核心洞察：

1. 全量Schema传递是工具滥用的根本原因
2. 意图识别与工具选择之间存在架构断裂
3. 需要系统化的追踪机制来量化问题

下一篇，我们将介绍团队提出的第一个解决方案——"硬过滤"策略，以及它为何引发了更大的争议。

系列文章预告：

• 第2篇：《激进方案遭遇滑铁卢——全量过滤的风险警示》
• 第3篇：《再评估：当方案暴露出隐藏漏洞》
• 第4篇：《第三次评估：渐进式暴露的艺术》
• 第5篇：《落地实战：TaskTrace追踪与工具纳入规范》