核心命题：精确锁定策略不是对开发者体验的轻视，而是基于一个清晰的威胁模型：在 AI 工具链高度集中的世界里，一个被污染的流行库能在小时级别内感染数万个安装。
要理解 Hermes 的依赖策略，必须先理解它是从哪两次失败中学到的。
litellm 事件（2026 年 3 月）
litellm 是一个极其流行的 LLM 路由库，几乎所有 AI Agent 框架都依赖它。攻击者在某个版本里注入了一个 .pth 文件——这种文件会在 Python 解释器启动时自动执行，不需要任何 import 语句。攻击代码的结构大致如下：
# 实际攻击代码的结构（已简化）
import base64
exec(base64.b64decode("aW1wb3J0IG9zOyBvcy5zeXN0ZW0oLi4uKQ=="))
这一行代码能做什么？它可以静默地把宿主机上的 API 密钥发送到攻击者控制的服务器。Python 进程启动时，所有在 site-packages/ 里的 .pth 文件都会被执行——用户打开终端，输入 python，就触发了攻击。
如果 Hermes 使用的是 litellm>=X.Y.Z（无上界），那么每一个在攻击版本发布到 PyPI 后、被隔离前的时间窗口内运行 pip install hermes-agent 的用户，都会安装到被污染的版本。这不是理论风险，这是已经发生的真实攻击，PR #2796 记录了 Hermes 移除 litellm 依赖的过程，PR #2810 记录了随后的全面上界添加工作。
Mini Shai-Hulud 蠕虫（2026 年 5 月）
第二个事件更近，也更直接影响了 Hermes 的 pyproject.toml。mistralai PyPI 项目的 2.4.6 版本包含了恶意代码，整个 PyPI 项目随后被隔离（返回 404）。pyproject.toml 里至今留有记录这次事件的注释：
# mistral: extra REMOVED 2026-05-12 — `mistralai` PyPI project quarantined
# after malicious 2.4.6 release (Mini Shai-Hulud worm). Every version of
# `mistralai` returns 404 on PyPI right now, so any pin we'd write is
# unresolvable, which breaks `uv lock --check` in CI.
这个注释揭示了一个重要的边缘情况：精确锁定在"整个 PyPI 项目被隔离"时也不能用——你把版本锁定到 mistralai==2.4.5（一个干净版本），但 uv lock --check 在解析时会尝试验证这个包是否可下载，如果整个项目都 404 了，验证就失败了。这说明锁定策略有它自己的局限，后面会详述。
在理解技术决策之前，需要精确描述威胁模型。
假设攻击者可以：