1 · 机制逐条对照

这一章把四个核心问题拿出来，看两个系统各自怎么答。每一节的结构都是：问题是什么 → 两种解法 → 差异的根源。

1.1 上下文治理

问题

大语言模型有一个「上下文窗口」—— 一次能看多少文字，是有上限的。对话越长，占用越多，直到装不下。而且每一轮都要把全部历史重新发一遍，所以长上下文不只是「会满」，还是「每一轮都在烧钱」。

Claude Code：五级阶梯

五级的关键在于每一级的信息损失和执行代价都比上一级大。系统总是从最轻的手段开始，只有不够才升级。

此外还有一个 Anthropic 私有能力 cache_edits：在服务端删除缓存里的某些内容，而本地消息列表完全不动。这让「压缩」可以做到不破坏提示词缓存的前缀 —— 这是外部开发者拿不到的能力。

Hermes：可插拔引擎

class ContextEngine(ABC):        # 490 行的抽象基类
    def should_compress(...)      # 抽象方法：现在该压缩了吗
    def compress(...)             # 抽象方法：怎么压缩
    def select_context(...)       # 抽象方法：这一轮发哪些消息

Hermes 不规定压缩策略，它规定的是「压缩器要长什么样」。内置一个叫 compressor 的默认实现，用户可以在配置里换成自己的。

而且它把动作拆成了两个正交的动词：

差异的根源

1.2 权限与安全

问题

智能体会执行命令、改文件、发网络请求。怎么防止它做出不可挽回的破坏？

Claude Code：10 步级联决策

每一次工具调用都走一条 10 步的判定链。最重要的设计是「绕过免疫」：

Hermes：红线 + 环境隔离

第一层是 12 条硬编码红线（HARDLINE_PATTERNS），配合一套相当精密的解析：

第二层是执行环境：7 种后端（本机 / Docker / Modal / Vercel / Daytona / Singularity / SSH）。这是唯一真正的硬边界 —— 前面所有规则都是「猜测这条命令危不危险」，只有隔离是「就算危险也出不去」。

差异的根源

1.3 多智能体

Claude Code：三种形态

那 4 个分叉缓存技巧值得单独说：为了让子智能体的请求前缀和父级逐字节相同，系统必须保证系统提示词、工具定义、工具顺序、消息序列化方式全都完全一致。任何一个字节不同，整个缓存就失效，成本翻数倍。

Hermes：委派 + 看板

MAX_DEPTH = 1                          # 只允许一层
_DEFAULT_MAX_CONCURRENT_CHILDREN = 10  # 最多 10 个并发
_RECENT_SUBAGENTS_CAP = 200            # 历史记录上限

加上运行时控制：interrupt_subagent（中断）/ steer_subagent（注入指令）/ set_spawn_paused（停止派生但让现有的跑完）。

另一种模式是看板：多个对等的智能体共享一块任务板，各自认领。配合 kanban_heartbeat 心跳 —— 认领了但死掉的任务会自动回到待认领。

差异的根源

1.4 扩展机制

两个都用的模式：渐进式披露

1.5 一页速查表