巨坑？OpenClaw+Ollama+Qwen3.5:9b竟然无法读取本地文件!

·II「AI = 50%，人机平等对话，各占一半，作者提供想法与方向，AI提供框架与内容支撑。」

#OpenClaw

是技术局限，还是厂商"有意为之"？

作为一名热衷于本地部署 AI 的技术爱好者，我最近踩了一个大坑：OpenClaw 配合 Ollama 部署 Qwen3.5:9b 后，竟然无法读取本地文件,信心满满的测试，结果浪费我一整天的时间！

而当我切换到线上大模型（GPT-4、Claude 等）时，这个问题神奇地消失了。这让我不禁想问：这真的是技术问题，还是某些厂商"刻意为之"？

一、问题的表象

事情的起因很简单。我想搭建一个完全本地化的 AI 工作流，于是选择了以下组合：

  • OpenClaw：作为 AI 客户端，支持多种模型接入
  • Ollama：本地运行大模型的神器
  • Qwen3.5:9b：阿里开源的中文大模型Qwen3.5:9b

部署过程一帆风顺，直到我尝试让它读取本地文件时，问题出现了：

> "请帮我分析这个文档的内容"
> → 模型回复："我无法访问本地文件系统"

奇怪的是，当我把 API Key 换成 阿里云百炼的线上模型后，文件读取功能立即恢复正常。这种"选择性失效"让我开始怀疑。

二、官方解释 vs 我的怀疑

2.1 官方话术：模型能力差异

如果去社区提问，大概率会得到这样的回答：

> "9B 的小模型 Function Calling 能力弱，无法正确生成工具调用格式，这是正常的。线上大模型经过专门优化，工具调用能力更强。"

听起来很有道理，但仔细一想，漏洞百出。

2.2 我的质疑：真的是能力问题吗？

以下几点让我无法完全接受"能力论"：

  1. 同样的模型，不同的表现：Qwen3.5:9b 在 OpenClaw 里读不了文件，但在其他客户端（如 Chatbox、LobeChat）里却能正常读取。如果是模型能力问题，为什么换个壳子就好了？

  2. "恰好"失效的功能：文件读取是本地部署最核心的需求之一，也是线上模型收费的重要卖点。这个功能"恰好"在本地部署时失效，是不是太巧合了？

  3. API 层面的诡异行为：通过抓包发现，OpenClaw 向 Ollama 发送的请求中，tools 字段有时是空的。这是模型的问题，还是客户端"忘记"传了？

三、深挖：可能的技术原因

在指责厂商"搞鬼"之前，我们还是先来理性分析一下可能的技术原因：

3.1 Function Calling 格式兼容性

不同厂商的工具调用格式存在差异。OpenAI 的格式是业界事实标准，但 Ollama 的实现可能并不完全兼容。如果 OpenClaw 是按照 OpenAI 的格式发送请求，而 Ollama 期望的是另一种格式，就会出现问题。

3.2 系统提示词（System Prompt）差异

很多 AI 客户端会针对不同模型注入不同的系统提示词。OpenClaw 可能针对 GPT-4 优化了提示词，但对本地模型的提示词没有相应调整，导致模型"听不懂"指令。

3.3 模型名称检测

不排除 OpenClaw 内部有类似这样的逻辑：

if (model.includes("gpt") || model.includes("claude")) {
    enableFileReading = true;
} else {
    enableFileReading = false; // 本地模型？禁用！
}

这种"白名单"机制在业界并不罕见。厂商可能出于"稳定性考虑"，只给经过验证的模型开启高级功能。

四、厂商的"小心思"？

说到这里，不得不提一个敏感话题：厂商有没有动机"搞鬼"？

4.1 商业利益的考量

让我们算一笔账。GPT-4 的 API 调用成本大约是 $0.03/1K tokens，而本地部署的成本几乎为零（电费除外）。如果本地部署的体验和线上模型一样好，谁还会付费呢？

我不是说厂商一定在故意使绊子，但从商业逻辑上讲，让本地部署"能用但不完全好用"，确实是一个精妙的平衡点。

4.2 开源 vs 闭源的博弈

Ollama 和 Qwen 都是开源的，但 OpenClaw 是闭源商业软件。闭源软件对开源生态的支持程度，从来都是一个值得玩味的话题。"我们支持本地部署"和"我们让本地部署好用"，是两件完全不同的事。

五、验证方法与解决方案

如果你也遇到了类似问题，可以尝试以下方法验证和解决：

5.1 验证步骤

  • 换模型测试：尝试 llama3.1:8b、qwen2.5:14b 等其他本地模型，看问题是否依然存在
  • 换客户端测试：用 Chatbox、LobeChat 等客户端连接同一个 Ollama 实例，对比表现
  • 抓包分析：用 Wireshark 或 mitmproxy 查看 API 请求，对比线上和本地模型的差异
  • 查看日志：Ollama 的日志会显示是否收到了 tools 字段

5.2 可能的解决方案

  • 使用兼容层：如 open-webui，它对 Ollama 的支持更完善，亲测可以读取文件内容和识别图片内容。
  • 手动修改请求：通过代理拦截并修改 OpenClaw 的请求，补全 tools 字段
  • 向开发者反馈：如果是 bug，官方修复是最好的解决方案
  • 换客户端：如果 OpenClaw 确实对本地模型支持不佳，考虑迁移到其他客户端

六、结语：保持怀疑，但别偏执

写这篇文章的目的，不是要给某个厂商定罪，而是想表达一个观点：在技术世界里，"不能用的功能"和"不想让你用的功能"之间的界限，往往比我们想象的更模糊。

也许 OpenClaw + Ollama 的文件读取问题，真的只是一个普通的兼容性 bug；也许背后有更深层的商业考量。作为用户，我们很难知道真相。

但有一点是确定的：当本地部署的体验"恰好"不如线上服务时，受益的永远是那些按 token 收费的云服务商。

保持技术敏感，保持独立思考。

本文仅代表作者个人观点，如有雷同，纯属巧合。欢迎技术交流，拒绝人身攻击。

相关文章