0 · 两个系统在解什么题0 · What Problem Each System Is Solving第 0 章 · 5 章Chapter 0 of 5
本章目录In this chapter

0 · 两个系统在解什么题

前两篇文章分别讲了 Claude Code 和 Hermes 各自的架构。这一篇只做一件事：把它们放在一起，看同一个问题的两种答案。

先声明一件重要的事，避免误读整篇文章。

本文不评判「谁更好」。这两个系统解的不是同一道题。把它们的设计选择直接对比，就像比较一辆越野车和一辆城市通勤车的离地间隙 —— 数字上有高低，但那个高低本身没有意义，有意义的是「为什么在各自的用途下，这个数字是对的」。

这篇文章要提取的是那个「为什么」。因为在你自己的项目里，你要做的也是同样的推导：先想清楚约束，再选设计。

0.1 两句话的定位

Claude CodeHermes
是什么 一个命令行编程助手。你在终端里跑它，它帮你读代码、改代码、跑测试 一个可以住在任何地方的个人智能体。它在 22 个聊天平台上活着，也在定时任务里活着
一句话 把一件事（写代码）做到极致 把一个东西（智能体）放到所有地方
技术栈 TypeScript，编译成单个可执行文件 Python，插件化的运行时
开源状态 闭源（本文分析基于泄漏的源码） 开源
用户在场 几乎总是在场 —— 你盯着终端 经常不在场 —— 半夜的定时任务、群里的自动回复

0.2 「用户在不在场」是所有分歧的源头

上表最后一行，是理解两个系统全部差异的钥匙。

用户在场（Claude Code） ↓ · 危险操作可以弹确认框 —— 有人会看到并回答 · 出错了用户立刻发现，按 Ctrl-C 就行 · 上下文长了可以提示用户"要不要压缩" · 界面可以很复杂 —— 有人在读 · 响应速度极其重要 —— 有人在等 用户不在场（Hermes） ↓ · 危险操作没人能确认 → 必须有【自动决策规则】 · 出错了没人发现 → 必须有【告警和事件系统】 · 上下文长了没人管 → 必须【自动处理】 · 界面不重要 → 输出是给聊天工具看的 · 响应速度不那么重要 → 但【可靠性】极其重要

这一条差异会向下传导，改变几乎每一层的设计。后面几章逐个展开，但你会发现绝大多数分歧最终都能回溯到这里。

两种架构的对照全图
全文一图速览 — 最上面那条轴是分水岭（用户在场 / 不在场），中间是本文第 1 章要逐条展开的四组对照，最下面绿框里的八条是第 2 章的重点：两个团队独立得出的相同结论。注意轴中间那个灰色标签 ——「大多数真实系统落在这里 → 按触发源分层」，这是第 4 章的核心建议点击放大

0.3 从代码体量看重心

看两个系统各自最大的文件，能直接看出它们把力气花在哪：

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 把最大的力气花在「智能体自己活下去」：怎么派活、怎么定时、怎么判断危险、怎么跨平台。因为没人在旁边看着。

0.4 本文的结构

章节内容
第 1 章机制对照 —— 同一个问题（上下文、权限、多智能体、扩展），两套解法逐条对比
第 2 章共识 —— 两个团队独立地得出了哪些相同的结论。这些是最有价值的部分
第 3 章代价 —— 每个选择放弃了什么。没有免费的设计
第 4 章决策指南 —— 你自己做系统时，怎么在这两条路之间选

0.5 一个提醒：不要照抄

这两个系统的很多设计，在你的项目里可能是错的。

举例：Hermes 的 5,802 行红线规则、里面那个 _CMDPOS 命令位置锚定，还有 Claude Code 权限系统里的「影子规则检测」—— 这些都是被真实事故逼出来的。Hermes 源码的注释里就明确写了触发 _CMDPOS 的那次事故：一条 gh pr create --title "block rm -rf / spellings" 命令，因为标题里含有 rm -rf / 字样而被误拦 —— 那明明只是一个字符串参数，不是要执行的命令。

你的系统没有经历过那次事故，直接抄一个 5,802 行的规则库，得到的是五千行你不理解、不敢改、也不知道为什么存在的代码。

正确的做法是：理解每条规则回答的是什么问题，然后在你的系统里判断这个问题存不存在。

0 · What Problem Each System Is Solving

The previous two articles covered the architecture of Claude Code and Hermes, each on its own. This one does exactly one thing: it puts them side by side and looks at two answers to the same question.

One important thing up front, so the rest of the article isn't misread.

This article does not judge which is “better.” These two systems are not solving the same problem. Comparing their design choices head-on is like comparing the ground clearance of an off-road truck and a city commuter car: one number is higher, but that by itself means nothing. What matters is “why, given what each one is for, that number is the right one.”

What this article is after is that “why.” Because in your own project you'll be running the same derivation: get clear on the constraints first, then pick the design.

0.1 Each in Two Sentences

Claude CodeHermes
What it is A command-line coding assistant. You run it in your terminal, and it reads code, edits code, and runs tests for you A personal agent that can live anywhere. It lives on 22 chat platforms, and it also lives inside scheduled tasks
In one line Do one thing (writing code) as well as it can possibly be done Put one thing (an agent) in every place it could possibly be
Tech stack TypeScript, compiled into a single executable Python, a plugin-based runtime
Open source? Closed (this analysis is based on leaked source) Open
Is the user present? Almost always — you're watching the terminal Often not — a scheduled task at 3 a.m., an auto-reply in a group chat

0.2 “Is the User Present?” Is Where Every Disagreement Starts

The last row of that table is the key to every difference between the two systems.

The user is present (Claude Code) ↓ · Dangerous actions can pop a confirmation — someone will see it and answer · When something breaks, the user notices immediately; Ctrl-C and done · When context gets long, you can ask the user "compact now?" · The UI can be elaborate — someone is reading it · Response speed matters enormously — someone is waiting The user is absent (Hermes) ↓ · Nobody can confirm a dangerous action → there must be [automatic decision rules] · Nobody notices a failure → there must be [alerting and an event system] · Nobody manages long context → it must be [handled automatically] · The UI doesn't matter → output goes to a chat app · Response speed matters less → but [reliability] matters enormously

This one difference propagates downward and reshapes the design at almost every layer. The following chapters unpack it piece by piece, but you'll find that the vast majority of disagreements trace back to right here.

The full comparison of the two architectures, in one diagram
The whole article in one picture — the axis at the top is the dividing line (the user is present / absent); in the middle are the four groups of comparisons Chapter 1 works through one by one; the eight items in the green box at the bottom are the focus of Chapter 2: the same conclusions two teams reached independently. Note the gray label in the middle of the axis — “most real systems land here → layer by trigger source.” That is the core recommendation of Chapter 4Click to enlarge

0.3 Where the Weight Is, by Code Volume

Look at the single largest file in each system and you can see directly where the effort went:

Claude Code's heavy hittersHermes's heavy hitters
PromptInput.tsx — 347 KB
The input box in the terminal		 delegate_tool.py — 5,071 lines
Multi-agent delegation
The five-rung ladder of context management
Tool-result budget → trimming → micro-compaction → collapse → auto-compaction		 Approval red lines — 5,802 lines
Judging how dangerous a command is
The 10-step permission cascade
Including 4 “bypass-immunity” checks		 scheduler.py — 367 KB
Scheduled tasks (cron)
Prompt-cache optimization
Forked subagents keep a byte-identical prefix		 7 execution environments + 22 platform adapters
A matrix of abstract base classes

An input box at 347 KB, a delegation tool at 5,071 lines — those two numbers side by side say more than any architecture diagram.

Claude Code spends its biggest effort on “the two inches between the human and the agent”: input experience, rendering performance, interrupt handling, status display. Because the user is staring at that screen the whole time.

Hermes spends its biggest effort on “the agent keeping itself alive”: how to hand out work, how to run on a schedule, how to judge danger, how to span platforms. Because nobody is standing there watching.

0.4 How This Article Is Organized

ChapterContents
Chapter 1Mechanism by mechanism — the same problems (context, permissions, multi-agent, extensibility), two sets of solutions compared one at a time
Chapter 2Consensus — which conclusions the two teams reached independently. This is the most valuable part
Chapter 3Cost — what each choice gave up. There is no free design
Chapter 4The decision — when you build your own system, how to choose between these two roads

0.5 A Warning: Don't Copy

Many of the designs in these two systems may be wrong for your project.

For example: Hermes's 5,802 lines of red-line rules, the _CMDPOS command-position anchoring inside them, and the “shadow rule detection” in Claude Code's permission system — all of these were forced into existence by real incidents. A comment in the Hermes source spells out the incident that produced _CMDPOS: a gh pr create --title "block rm -rf / spellings" command got blocked by mistake because the title contained the text rm -rf / — when it was plainly just a string argument, not a command about to run.

Your system never lived through that incident. Copy a 5,802-line rulebook wholesale and what you get is five thousand lines you don't understand, don't dare change, and can't explain the existence of.

The right move is: understand what question each rule answers, then decide whether that question even exists in your system.