Hermes Agent 从旧版本更新到新版本时，如果卡在：
Updating Python dependencies...
× Failed to build `python-olm==3.2.16`
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 3.5 has been removed from CMake.很多人第一反应是：是不是 Python 版本错了、uv 坏了、Hermes 更新脚本坏了？但在 macOS 上，这个问题更像是 Matrix 端到端加密依赖 python-olm 的上游构建兼容性问题。
这篇文章基于 NousResearch/hermes-agent issue #4178，整理 Hermes hermes update 时 python-olm==3.2.16 构建失败的现象、临时绕过方案，以及为什么长期修复应从可选依赖拆分入手。
先判断：这是安装依赖失败，不是模型 API 故障
典型现场是：
⚕ Updating Hermes Agent...
→ Fetching updates...
→ Pulling updates...
→ Updating Python dependencies...
× Failed to build `python-olm==3.2.16`这发生在 Hermes 更新依赖阶段，还没进入模型调用。
所以它和这些问题无关：
- API Key；
- Base URL；
- OpenRouter / DeepAI / OpenAI provider；
- 模型 ID；
- 401 / 404 / 429；
- 工具调用 JSON。
如果错误里出现 python-olm、CMakeLists.txt、Apple Clang、include/olm/list.hh，请先按本地编译依赖处理。
第一类报错：CMake 4 不再接受过旧 policy baseline
issue 里最先出现的是这个错误：
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 3.5 has been removed from CMake.
Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.意思是：python-olm vendored 的 libolm 代码里，CMake 配置太旧，而你本机的 CMake 版本太新，不再兼容 < 3.5 的旧 policy。
临时绕过方法是设置 CMake 参数：
export CMAKE_ARGS="-DCMAKE_POLICY_VERSION_MINIMUM=3.5"
hermes update如果 hermes update 已经显示 Already up to date，它可能不会重新安装依赖。此时可以强制重装：
export CMAKE_ARGS="-DCMAKE_POLICY_VERSION_MINIMUM=3.5"
pip install --no-cache-dir --force-reinstall python-olm如果使用 poetry：
export CMAKE_ARGS="-DCMAKE_POLICY_VERSION_MINIMUM=3.5"
poetry run pip install --no-cache-dir --force-reinstall python-olm第二类报错：Apple Clang 直接拒绝 vendored libolm 的 C++ 代码
更麻烦的是，后续评论提到，即使绕过 CMake policy，macOS 新编译器仍可能失败：
include/olm/list.hh:106:13: error: cannot assign to variable 'other_pos' with const-qualified type 'T *const'
++other_pos;这里不是 warning，而是 C++ 类型错误。
代码类似：
T * const other_pos = other._data;
++other_pos;T * const 表示指针本身是 const，不能再 ++other_pos。旧编译器可能放过了，新 Apple Clang 会严格拒绝。
这说明问题不只是“缺 cmake / gmake / make”，而是 python-olm vendored 的 libolm 源码在现代 macOS 工具链上本身不稳定。
为什么安装 Homebrew libolm 不一定有用？
一个容易踩坑的点：你可能会尝试：
brew install libolm但评论里提到，python-olm 会构建它 vendored 的 libolm copy，不一定自动使用系统安装的 Homebrew libolm。
所以即使系统里有 libolm，python-olm 仍可能继续编译自带源码，然后在 CMake 或 Apple Clang 处失败。
这也是为什么“我明明装了 cmake / libolm，为什么还是不行”会反复出现。
根本问题：Matrix E2EE 依赖不该阻断所有用户更新
python-olm 主要和 Matrix 端到端加密相关。
但很多 Hermes 用户并不使用 Matrix gateway，更不一定需要 Matrix E2EE。若 hermes update 安装 .[all]，把 Matrix / E2EE 依赖也一起拉进来，就会出现一个尴尬结果：
> 不用 Matrix 的用户，也被 Matrix E2EE 的原生编译依赖卡住。
issue 讨论里的建议包括：
- 从
[all]extras 中移除matrix； - 让需要 Matrix 的用户显式安装
.[matrix]； - 或从
matrix-nio[e2e]改成不带 E2EE 的matrix-nio； - 长期迁移到 Matrix 官方后续方向，例如
vodozemac绑定。
事件记录显示该 issue 后续被 commit 引用并 closed/completed，说明项目层面已经意识到“可选平台依赖不应阻塞主安装”的问题。
你应该怎么处理？按是否使用 Matrix 分流
情况 A：你不使用 Matrix
如果你只是用 Hermes CLI、本地工具、Discord/Feishu/Telegram 等其他通道，不需要 Matrix E2EE，那么优先目标是：避免 python-olm 阻断主程序更新。
建议：
1. 升级到已调整 extras / optional dependency 的 Hermes 版本； 2. 不要主动安装 Matrix E2EE extra； 3. 如果项目仍默认装 .[all]，关注是否有配置可跳过 Matrix； 4. 不要为了不用的 Matrix 依赖反复修 C++ 工具链。
情况 B：你确实需要 Matrix
如果你需要 Matrix，尤其是 E2EE，那么要准备原生构建环境：
brew install cmake make
export CMAKE_ARGS="-DCMAKE_POLICY_VERSION_MINIMUM=3.5"
pip install --no-cache-dir --force-reinstall python-olm如果仍然遇到 Apple Clang 的 T * const 错误，说明已经不是简单环境缺包，可能需要：
- 使用较旧/兼容的编译器环境；
- 等待 Hermes 依赖调整；
- 使用不带 E2EE 的 Matrix 配置；
- 或等待上游替代方案。
更新脚本里的 stash 提醒也要看
issue 原始日志里还有一段：
Local changes detected — stashing before update...
Restore local changes now? [Y/n]
y
Restoring local changes...这和 python-olm 不是同一个问题，但更新后要注意：
git status
git diff因为本地改动被恢复到新代码上，可能会引入额外冲突。不要把所有异常都归因给 python-olm。
和 DeepAI API 中转站有什么关系？
这类问题发生在 Hermes 的本地依赖安装阶段，和 DeepAI API 中转站没有直接关系。
DeepAI API 中转站解决的是 OpenAI-compatible 模型接入问题，例如：
Base URL: https://api.deepai.wang/v1
API Key: 你的 DeepAI Key
Model: 以控制台为准但如果 Hermes 本体更新失败、依赖没装好、CLI 无法启动，那么还没到调用 DeepAI 或任何模型 API 的阶段。
所以分层排查很重要：
python-olm/ CMake / Clang：本地安装依赖层；- Matrix callback / gateway：消息接入层；
- Base URL / API Key / model：模型 API 层；
- DeepAI API 中转站：模型 API 统一入口层。
不要把本地 C++ 编译问题误判成 API 中转站问题。
FAQ
python-olm 构建失败会影响 Hermes 聊天吗？
如果 Hermes 主程序和你使用的通道不依赖 Matrix E2EE，可能不影响核心聊天。但如果安装流程因此中断，仍可能导致环境不完整。
设置 CMAKE_ARGS 一定能解决吗？
不一定。它能绕过 CMake policy baseline 问题，但不能修复 Apple Clang 报出的真实 C++ 类型错误。
安装 Homebrew libolm 有用吗？
不一定。python-olm 可能编译 vendored libolm，而不是使用系统 libolm。
为什么这个依赖会被装上？
可能是 Hermes 更新时安装了 .[all]，把 Matrix / E2EE 相关 extra 一起拉进来。
不用 Matrix 怎么办？
优先升级到不让 Matrix E2EE 阻塞默认安装的版本，或避免安装 Matrix extra。
总结
Hermes 更新时报：
Failed to build python-olm==3.2.16
CMake compatibility with < 3.5 has been removed不要先查 API Key，也不要把它当成模型 provider 问题。这是本地原生依赖构建问题，主要和 Matrix E2EE 的 python-olm / vendored libolm / macOS 工具链有关。
短期可以尝试：
export CMAKE_ARGS="-DCMAKE_POLICY_VERSION_MINIMUM=3.5"
pip install --no-cache-dir --force-reinstall python-olm但如果遇到 Apple Clang 的 C++ 类型错误，最实际的长期方向是：让 Matrix E2EE 成为真正可选依赖，不要让不用 Matrix 的用户被 python-olm 阻塞 Hermes 更新。