共计 1568 个字符，预计需要花费 4 分钟才能阅读完成。
四个月前被一招封死的功能,换了个姿势回来了。近期,Ollama 在 v0.33.0 版本里悄悄上线了一个新实现: 为 Claude Desktop 提供专用本地代理。8 月 26 日, 官方博客正式官宣——Claude Desktop 可以把 Ollama 配置为“第三方网关提供商”,Qwen、DeepSeek、Kimi、GLM 这些开放模型, 从此能直接在 Anthropic 自家应用的界面里跑。
📌 事件回顾: 四个月前的第一次尝试
- 1 月:Ollama 支持 Anthropic Messages API,Claude Code 可以指向 Ollama 跑本地或云端模型——终端这条路先通了。
- 4 月:Anthropic 在 Claude Desktop 里悄悄加了一个开发者设置, 允许连接第三方推理网关。Ollama 立刻跟进, 推出
ollama launch claude-desktop命令, 一键把桌面应用接到自己身上。 - 数日后: 集成被封杀,Ollama 下架功能。
- 8 月 21 日:v0.33.0 携本地代理方案回归。
中间那几天发生了什么?Claude Desktop 一次更新后, 用户发现: 网关照常接受连接, 但拒绝所有非 Anthropic 的模型 ID。GitHub 上有用户贴出了当时的日志——网关的 /v1/models 接口明明返回了 39 个模型, 可用数却是 0; 应用发消息时固执地调用 claude-sonnet-4-6, 然后报错“模型不存在或无权访问”。
🔍 新方案的核心: 本地代理与槽位重映射
为什么本地代理能解开四月的死结? 关键在信任边界的位置。四月的方案里,Claude Desktop 直连网关, 模型名单的校验权握在应用手里, 它看到陌生模型 ID 就拒付。新方案中, 应用连接的是本机回环地址上的代理, 对 Claude Desktop 来说, 对话对象看起来就是一个“合法”的本地端点; 请求出了应用之后往哪走、由哪个模型承接, 全部由 Ollama 在本机决定。校验的那一关, 被搬到了攻击者——准确说是用户自己——可控的一侧。
最有意思的设计是 槽位重映射 。Claude Desktop 的界面围绕 Anthropic 自家模型构建, 模型选择器里是 Opus、Sonnet 这些名字。Ollama 干脆允许用户自定义每个槽位背后的真实模型: 选“Opus 5”, 请求路由到 Kimi K3; 选“Sonnet 5”, 实际跑的是 DeepSeek V4 Pro。界面还是那个界面, 引擎已经换了。Claude Desktop 内置的 Auto mode(应用自行决定是否征求用户许可) 也被完整保留。
💡 为什么要在 Claude 里跑别的模型?
X 上被问最多的问题就是这个: 既然有 Claude, 何必绕一圈?Ollama 给的答案是四个词:成本、速度、可移植性、自定义。本地模型零调用成本、无网络延迟; 用自有数据微调过的模型可以塞进日常工作流; 重活交给 Ollama Cloud 的大模型, 轻活本地跑, 随时切回 Anthropic 前沿模型。
📊 行业观察: 壳与引擎的解耦趋势
合理推演有两层。其一,这类“壳与引擎解耦”的玩法会扩散——Claude Code 生态里早就有了 LiteLLM、Bifrost 等网关把 Sonnet/Opus/Haiku 三个槽位重映射到任意模型的成熟实践, 桌面应用只是下一个被解耦的界面。其二, 猫鼠游戏未必结束。Anthropic 四月已经演示过一次“协议放行、名单拦截”, 公开资料中没有看到 Anthropic 对本次集成的任何表态; 如果它再次在应用层收紧校验,Ollama 的本地代理能扛多久, 仍是一个开放问题。
🚀 总结与展望
围绕“Claude Desktop 被 Ollama 偷梁换柱”，这一部分可从背景、现状与影响三个角度理解其关键信息。结合已公开内容来看，核心结论是趋势已较为明确，但细节仍需结合后续进展持续观察。
