ollama v0.33.2更新：深色模式回归、macOS 多开接力修复、Claude Desktop 请求不中断

2026 年 8 月 31 日，Ollama 发布 v0.33.2 最新版本。本次更新虽然聚焦在应用体验与 Claude Desktop 代理稳定性，但涉及 macOS 应用启动接力、进程同步、系统外观适配、云模型目录刷新、退出时配置恢复等多个关键环节。

从变更信息来看，本次版本共包含 6 次提交，涉及 21 个文件，共有 3 位贡献者参与，代码改动规模为 898 行新增、481 行删除。更新重点可以概括为三项：

• Ollama 应用重新跟随系统外观，深色模式支持恢复。

• macOS 应用启动时，能够正确交接给已经运行的实例，不再错误启动第二个实例。

• Claude Desktop 代理在模型目录更新时，不再中断正在进行中的请求。

此外，v0.33.2 还补充了 Claude 的账户云端模型列表能力，并完成了部分无效代码清理与代码规范修复。

一、更新概览：v0.33.2 解决了哪些问题

此次更新的发布说明明确列出了三个用户可直接感知的变化。

第一，Ollama 应用重新遵循系统外观设置。

此前应用的深色模式支持出现缺失或未能正确跟随系统设置的情况。本次更新恢复了应用对系统外观的响应能力。当系统切换到深色模式时，Ollama 应用能够再次呈现对应的深色界面；系统处于浅色模式时，应用也会与系统整体视觉保持一致。

第二，修复 macOS 应用实例交接问题。

此前 macOS 上如果 Ollama 已经在运行，再次启动应用时，可能会启动第二个实例，或者原有实例与新实例之间无法正确完成交接。本次更新改进了已有实例的处理逻辑：新启动的应用会识别现有运行实例，并根据进程状态完成接力、关闭和退出控制，避免重复启动带来的冲突。

第三，Claude Desktop 代理刷新模型目录时不再打断请求。

Claude Desktop 代理会使用模型目录来处理可用模型、模型映射和云端模型信息。此前，当模型目录发生更新时，可能会导致正在进行中的请求被中断。v0.33.2 调整了模型目录刷新与代理请求之间的处理方式，使目录更新不会再干扰已经在执行的请求。

二、提交记录：6 项变更覆盖应用、代理与代码维护

本次更新包含 6 次提交，时间集中在 2026 年 8 月 27 日与 8 月 28 日。

8 月 27 日完成的提交包括：

• 应用恢复系统深色模式支持，变更编号 18049。

• 代理在模型目录变化时继续处理请求，变更编号 18058。

• 同步 macOS 应用交接流程，变更编号 18056。

8 月 28 日完成的提交包括：

• 为 Claude 列出账户云端模型，变更编号 18077。

• 清理无效代码，变更编号 17381。

• 修复代码检查问题，变更编号 18081。

从提交主题可以看到，v0.33.2 并非单纯进行视觉调整，而是围绕“应用是否只运行一个正确实例”“Claude Desktop 是否能稳定使用模型目录”“退出和接力时是否会影响已有代理配置”等问题进行了系统性修复。

三、应用启动逻辑变化：启动前先判断已有实例是否可处理

在应用主入口中，已有实例的处理逻辑发生了关键变化。

原有流程中，应用会直接调用已有实例处理函数。更新后，处理函数会返回一个布尔结果，主流程会根据结果决定是否继续启动：

if !handleExistingInstance(startHidden) {
    return
}

这一调整意味着，已有实例的检测不再只是一次无返回值的处理动作，而是正式参与应用启动决策。

如果已有实例处理后判断当前进程不应该继续启动，应用会立即返回，不再继续执行后续初始化流程。这样可以避免多个实例同时继续启动，降低重复运行、资源竞争和应用状态冲突的可能性。

该逻辑尤其与 macOS 平台的实例接力机制相关。更新后，当当前启动实例发现有一个更新的实例已经拥有交接控制权时，当前实例会停止继续启动。

四、macOS 多实例问题修复：从“直接杀掉其他实例”升级为进程同步屏障

本次版本中，macOS 应用实例处理部分的改动规模较大。原有逻辑相对直接：处理已有实例时，会调用原生层的逻辑关闭其他实例。

更新后，这一部分引入了更完整的应用同步屏障机制。

新的机制不再仅仅是“发现其他实例后关闭它们”，而是将整个过程拆分为：

• 识别当前进程身份。

• 发现其他 Ollama 应用进程。

• 判断哪个实例更新。

• 决定当前实例是否有权接管。

• 向旧实例发送交接信号。

• 等待旧实例退出。

• 在必要时发送正常终止信号。

• 在仍未退出时进行强制终止。

• 确认没有其他实例残留后再完成启动。

这套机制的核心目标是：在 macOS 上存在已有 Ollama 应用实例时，确保应用能够完成稳定交接，而不是简单地再启动一个新实例。

五、进程身份识别：不只看进程号，还要看启动时间

更新中新增了应用进程身份结构，用于识别一个具体的 Ollama 应用进程。进程身份包含两个字段：

字段

含义

pid

进程号

startedAt

进程启动时间

仅凭进程号无法完全可靠地判断是否为同一个进程，因为进程退出后，其进程号未来可能被其他进程重新使用。因此，新的逻辑会同时比较进程号和启动时间。

新增的同一进程判断逻辑要求两个条件同时成立：

• 进程号相同。

• 启动时间相同。

同时，代码也新增了“是否启动得更晚”的判断规则：

• 如果启动时间不同，则启动时间更晚的进程被视为更新实例。

• 如果启动时间相同，则进程号更大的实例被视为更新实例。

这一规则用于解决多个 Ollama 应用实例重叠启动时的归属问题。只有被判定为较新的实例，才可以继续承担接力与终止旧实例的工作。

六、新实例选举：较新的启动者拥有接力控制权

新的同步屏障逻辑中有一个明确原则：多个重叠启动的实例，需要按进程启动时间排序，只有最新启动的候选实例可以终止已有实例。

当当前实例发现其他进程比自己更新时，会返回“更新的应用实例拥有交接权”的错误状态。

这意味着当前实例会被判定为较旧实例，不能继续关闭其他进程，也不应继续自己的启动流程。

代码将这一情形定义为专门的错误：

var errNewerAppInstance = errors.New("newer app instance owns the handoff")

当出现该错误时，日志会记录“更新的 Ollama 应用实例拥有交接权”，随后当前实例停止启动。

这种设计避免了两个同时启动的实例都认为自己应当关闭对方的问题。通过对进程启动时间和进程号进行排序，应用可以确定单一的交接控制者。

七、同步屏障的完整退出策略：交接、正常终止、强制终止

为了让旧实例可靠退出，v0.33.2 将关闭过程分成三种模式。

关闭模式

使用信号

作用

交接关闭

SIGUSR1

告知旧应用进行接力退出

正常终止

SIGTERM

在交接超时后请求正常结束

强制终止

SIGKILL

在正常终止仍超时后强制结束

整个流程的时间配置如下：

阶段

时长

交接等待时间

5 秒

正常终止等待时间

30 秒

强制终止等待时间

5 秒

进程状态轮询间隔

50 毫秒

空进程快照确认间隔

100 毫秒

也就是说，新的实例接力流程首先给旧实例 5 秒时间处理交接；若旧实例没有退出，再给予最长 30 秒的正常终止阶段；如果依然无法退出，则再进行最长 5 秒的强制终止等待。

这种顺序体现出应用优先尝试交接与正常退出，而不是一开始就直接终止进程。

八、为什么需要两次确认“没有其他进程”

更新中的同步屏障并不会在第一次发现“没有其他应用进程”时立刻认为交接完成。

代码要求连续两次获得空的进程快照，才认为其他实例已全部退出。

这一机制是为了应对 macOS 工作区进程快照并非原子操作的情况。某个进程在系统进程列表中出现的时机可能存在延迟，如果只依赖一次空快照，就有可能让尚未完全被发现的实例绕过同步屏障。

因此，逻辑会先记录已经看到一次空快照，然后等待一个稳定时间，再进行一次检查。只有第二次仍然为空，才返回成功。

这样做可以提高多实例交接过程中的稳定性，降低旧实例刚好在系统中延迟出现的风险。

九、代码明确保留的边界：两个并发启动实例可能同时通过

虽然同步屏障机制已经明显增强，但代码中也明确说明了一个仍未处理的边界情况。

由于 macOS 的工作区快照不是原子操作，如果两个应用实例几乎同时启动，且两者在检测时都还没有出现在对方的可见进程列表中，那么两个实例都有可能通过屏障。

也就是说，这个极端并发启动窗口被明确标注为暂未处理。

这一说明反映出本次更新对已知限制保持了明确边界：它处理了已发现实例的交接、退出与接管问题，但没有宣称完全消除所有极端并发启动时序问题。

十、进程存活检查更严格：防止误操作被复用的进程号

在停止 macOS 应用进程前，新的代码不会直接根据进程号发送信号，而是先确认目标身份仍然匹配。

处理流程包括：

• 根据目标进程号读取系统进程信息。

• 如果进程不存在，则视为已经退出。

• 如果进程存在，则比较当前读取到的进程身份与此前记录的身份。

• 只有进程号与启动时间都一致时，才认为该目标仍是原来的 Ollama 应用进程。

• 只有确认目标仍在运行时，才发送对应的关闭信号。

这种做法避免了一个重要问题：旧进程退出后，系统可能重新分配同一个进程号。如果仅依赖进程号，就有可能将信号发送给并非原来的目标进程。

更新后通过进程号加启动时间的双重校验，确保强制终止等操作只作用于预期的存活身份。

十一、交接信号到达后：先停止 Claude 代理，再进行退出

应用运行期间会监听交接信号。

当收到交接信号时，逻辑会依次执行：

• 记录收到应用交接信号并准备关闭。

• 停止 Claude 应用代理。

• 执行用于交接的退出流程。

原有流程中，接收到交接信号后会停止 Claude 应用代理、调用原生退出逻辑，并执行交接退出。更新后不再在该处直接调用原生退出，而是进入统一的交接退出路径。

新增的交接退出函数会先将一个全局原子状态设置为真，标识“应用交接正在进行”，再调用通用退出流程。

这一变化的重要点在于：应用退出不再只依赖实时检测是否有另一个 Ollama 实例运行，而是通过明确的交接状态保存当前退出的原因。

十二、Claude Desktop 配置恢复逻辑调整：接力退出时不再被后续信号干扰

本次 macOS 交接修复中，还涉及 Claude Desktop 配置恢复逻辑。

更新前，应用退出时会调用原生层逻辑检查是否存在其他 Ollama 实例运行，并将结果作为是否处于交接状态的依据。

更新后，退出逻辑不再通过该方式动态判断，而是读取全局原子状态：

appHandoffInProgress.Load()

该状态会在执行交接退出时提前设置。

代码注释指出，一旦替换交接已经开始，之后到来的关闭信号不应使 Claude 配置在新应用运行期间被重新恢复。

换句话说，当旧实例已经确认要交接给新实例时，退出过程必须维持这一状态，避免后续关闭流程错误地将 Claude Desktop 从 Ollama 网关配置恢复回原状态，从而影响新实例的工作。

这也是此次 macOS 多实例修复的重要配套调整：不仅要确保旧应用退出，还要确保退出过程中的 Claude 代理配置不会破坏新应用接管后的状态。

十三、Claude Desktop 退出恢复逻辑简化

本次更新还简化了 Claude Desktop 退出前恢复配置的函数参数。

原先的恢复判断函数会接收两个状态：

• 是否正在交接。

• 是否已经配置。

更新后，该函数只保留“是否已经配置”这一项。

新的逻辑变为：

• 如果未配置 Claude Desktop 网关，则不执行恢复。

• 如果已经配置，则执行恢复操作。

交接状态不再由该函数自行判断，而是通过前面提到的应用交接全局状态统一控制退出流程。

这使配置恢复的职责更加集中：恢复函数只负责根据是否配置决定是否恢复；是否属于交接退出，则由应用的退出状态来管理。

十四、Claude Desktop 云模型：账户模型会被纳入可用模型列表

v0.33.2 增加了 Claude 的账户云端模型列表能力。

在 Claude Desktop 启动目录解析流程中，应用会尝试加载账户云端模型。如果加载失败，会记录调试日志；如果加载成功，则将云端模型库存并入当前可用模型集合。

更新前，合并云端模型时存在不同的参数控制方式，例如是否追加缺失模型。更新后，这一参数被移除，合并逻辑统一为：

mergeClaudeDesktopCloudInventory(available, cloudModels)

新的合并逻辑会：

• 根据云端模型库存验证已有模型。

• 记录已出现的模型名称。

• 遍历账户云端模型。

• 对于当前列表中还不存在的云端模型，将其加入结果。

• 返回包含可用模型与账户云端模型的统一列表。

这意味着，账户中可使用的云端模型会被补充到 Claude Desktop 的可用模型目录中。

十五、模型目录刷新时：可用模型与可选模型统一处理

在 Claude Desktop 启动时，原先逻辑会根据是否存在显式云端模型名称，决定可选模型集合是否需要采用不同的合并方式。

更新后，逻辑被统一：

• 加载到账户云端模型后，先合并至可用模型列表。

• 可选模型列表直接使用合并后的可用模型列表。

也就是说，不再区分“仅验证已有模型”与“追加缺失模型”的两条分支，而是统一使用完整合并后的模型目录。

在模型目录刷新流程中，也进行了相同调整。

当云端库存已知时，应用会将云端模型统一合并到可用模型中。

当当前模型与账户模型在名称或 Ollama 模型字段上匹配时，也会将对应账户模型以统一方式合并到可用模型中。

这使 Claude Desktop 对账户云端模型的识别与展示逻辑更加一致。

十六、模型合并函数变化：不再保留“是否追加缺失项”开关

原有的云端模型合并函数带有一个布尔参数，用于控制是否追加当前列表中缺失的云端模型。

更新后，这个参数被移除。

新的函数始终执行以下两步：

• 使用云端模型库存校验已有模型。

• 将未出现在已有结果中的云端模型补充进去。

因此，账户云端模型不再只在某些特定分支中被追加，而是统一进入模型合并结果。

这一修改影响了以下场景：

• Claude Desktop 启动时的模型目录解析。

• Claude Desktop 运行过程中的模型目录刷新。

• 当前模型与账户模型匹配时的更新。

• Claude Desktop 模型选择时的可选模型生成。

十七、Claude Desktop 模型选择：统一使用账户云模型后的可选集合

在 Claude Desktop 模型映射应用流程中，如果成功获取到账户云端模型，新的逻辑会将现有可用模型与云端模型进行统一合并，并将合并结果作为可选模型集合。

之后，系统会根据当前模型、已知本地模型和映射配置，执行已知 Claude Desktop 模型映射。

完成映射后，验证流程也发生了变化。

原先验证函数会同时考虑访问状态、本地模型名称以及本地模型加载是否成功等条件。

更新后，映射后的模型会进入一个新的可用性保障流程：

ensureClaudeDesktopModelsAvailable(context.Background(), selected)

这一变更将模型可用性确认放入专门的保障函数中处理。

从变更关系看，模型选择流程不再直接使用原有的综合验证调用，而是通过新的可用性确认步骤处理已选择模型。

十八、代理目录更新不中断请求：本次版本的重要稳定性修复

发布说明中明确指出：Claude Desktop 代理在模型目录更新时，不再中断正在进行中的请求。

模型目录更新通常涉及以下内容：

• 可用模型列表变化。

• 账户云端模型信息加载。

• 本地模型与云端模型的合并。

• Claude Desktop 模型映射刷新。

• 当前模型目录的验证与更新。

本次更新将云端库存合并、当前模型匹配和模型可用性保障等逻辑进行调整，使模型目录更新能够与已经在进行中的代理请求更好地共存。

对于 Claude Desktop 代理而言，这意味着模型目录刷新不再需要以打断当前请求为代价。正在执行的请求可以继续完成，而模型目录变化则在后续流程中生效。

十九、深色模式恢复：应用重新跟随系统外观

v0.33.2 的另一项直接可见更新是应用恢复系统外观跟随能力。

发布说明中指出，Ollama 应用现在再次遵循系统外观，从而恢复深色模式支持。

这项更新的核心内容并不是增加新的主题配置入口，而是恢复应用根据系统外观自动适配的行为。

当系统使用深色外观时，应用能够使用对应的深色模式；当系统采用其他外观时，应用也恢复与系统保持一致。

这一调整使应用界面行为重新符合系统级外观设置。

二十、代码维护：清理无效代码与修复代码检查问题

除了功能修复外，本次版本还包含两项维护类提交：

• 清理无效代码。

• 修复代码检查问题。

这两项改动在发布记录中被单独列出，说明 v0.33.2 也同步进行了代码层面的整理。

无效代码清理有助于减少不再使用的实现残留；代码检查修复则用于使代码符合现有检查规则。它们与应用启动、代理稳定性和模型目录能力一起构成了本次版本的完整更新内容。

二十一、v0.33.2 变更总结

代码地址：github.com/ollama/ollama

Ollama v0.33.2 的更新重点集中在三个方向：应用界面适配、macOS 实例管理、Claude Desktop 代理稳定性。

更新方向

本次变化

系统外观

应用再次跟随系统外观，恢复深色模式支持

macOS 启动

修复已运行实例的交接问题，避免错误启动第二个实例

进程同步

引入进程身份、启动时间排序、交接与终止阶段控制

退出处理

通过交接状态避免退出时错误恢复 Claude 配置

Claude 云模型

支持列出账户云端模型，并统一合并到可用模型目录

模型选择

模型映射后改为执行可用性保障流程

代理稳定性

模型目录更新不再中断正在进行中的 Claude Desktop 请求

代码维护

清理无效代码，修复代码检查问题

整体来看，v0.33.2 对 macOS 应用交接进行了较完整的流程重构：从简单处理其他实例，升级为带有进程身份校验、最新实例选举、多阶段退出、双重空快照确认和交接状态控制的同步屏障。

我们相信人工智能为普通人提供了一种“增强工具”，并致力于分享全方位的AI知识。在这里，您可以找到最新的AI科普文章、工具评测、提升效率的秘籍以及行业洞察。 欢迎关注“福大大架构师每日一题”，发消息可获得面试资料，让AI助力您的未来发展。