前两篇文章分别讲了 Claude Code 和 Hermes 各自的架构。这一篇只做一件事：把它们放在一起，看同一个问题的两种答案。
先声明一件重要的事，避免误读整篇文章。
本文不评判「谁更好」。这两个系统解的不是同一道题。把它们的设计选择直接对比，就像比较一辆越野车和一辆城市通勤车的离地间隙 —— 数字上有高低，但那个高低本身没有意义，有意义的是「为什么在各自的用途下，这个数字是对的」。
这篇文章要提取的是那个「为什么」。因为在你自己的项目里，你要做的也是同样的推导：先想清楚约束，再选设计。
| Claude Code | Hermes | |
|---|---|---|
| 是什么 | 一个命令行编程助手。你在终端里跑它，它帮你读代码、改代码、跑测试 | 一个可以住在任何地方的个人智能体。它在 22 个聊天平台上活着，也在定时任务里活着 |
| 一句话 | 把一件事（写代码）做到极致 | 把一个东西（智能体）放到所有地方 |
| 技术栈 | TypeScript，编译成单个可执行文件 | Python，插件化的运行时 |
| 开源状态 | 闭源（本文分析基于泄漏的源码） | 开源 |
| 用户在场 | 几乎总是在场 —— 你盯着终端 | 经常不在场 —— 半夜的定时任务、群里的自动回复 |
上表最后一行，是理解两个系统全部差异的钥匙。
这一条差异会向下传导，改变几乎每一层的设计。后面几章逐个展开，但你会发现绝大多数分歧最终都能回溯到这里。
看两个系统各自最大的文件，能直接看出它们把力气花在哪：
| Claude Code 的重头戏 | Hermes 的重头戏 |
|---|---|
PromptInput.tsx —— 347 KB终端里的那个输入框 |
delegate_tool.py —— 5,071 行多智能体委派 |
| 上下文治理五级阶梯 工具结果预算 → 剪裁 → 微压缩 → 坍缩 → 自动压缩 |
审批红线 —— 5,802 行 命令危险性判定 |
| 权限系统的 10 步级联 含 4 步「绕过免疫」检查 |
scheduler.py —— 367 KB定时任务 |
| 提示词缓存优化 分叉子智能体做到字节级前缀一致 |
7 种执行环境 + 22 个平台适配器 抽象基类矩阵 |
一个输入框 347 KB，一个委派工具 5,071 行 —— 这两个数字放在一起，比任何架构图都能说明问题。
Claude Code 把最大的力气花在「人和智能体之间那 5 厘米」：输入体验、渲染性能、中断响应、状态展示。因为用户全程盯着这块屏幕。
Hermes 把最大的力气花在「智能体自己活下去」：怎么派活、怎么定时、怎么判断危险、怎么跨平台。因为没人在旁边看着。
| 章节 | 内容 |
|---|---|
| 第 1 章 | 机制对照 —— 同一个问题（上下文、权限、多智能体、扩展），两套解法逐条对比 |
| 第 2 章 | 共识 —— 两个团队独立地得出了哪些相同的结论。这些是最有价值的部分 |
| 第 3 章 | 代价 —— 每个选择放弃了什么。没有免费的设计 |
| 第 4 章 | 决策指南 —— 你自己做系统时，怎么在这两条路之间选 |
这两个系统的很多设计，在你的项目里可能是错的。
举例：Hermes 的 5,802 行红线规则、里面那个 _CMDPOS 命令位置锚定，还有 Claude Code 权限系统里的「影子规则检测」—— 这些都是被真实事故逼出来的。Hermes 源码的注释里就明确写了触发 _CMDPOS 的那次事故：一条 gh pr create --title "block rm -rf / spellings" 命令，因为标题里含有 rm -rf / 字样而被误拦 —— 那明明只是一个字符串参数，不是要执行的命令。
你的系统没有经历过那次事故，直接抄一个 5,802 行的规则库，得到的是五千行你不理解、不敢改、也不知道为什么存在的代码。
正确的做法是：理解每条规则回答的是什么问题，然后在你的系统里判断这个问题存不存在。