3 · 每个选择的代价

前两章讲了差异和共识。这一章讲一件更少被谈论的事：每一个设计选择放弃了什么。

为什么必须单独讲代价？

技术文章通常只讲「这个设计好在哪」。但在真实的架构决策里，你要判断的从来不是「这个设计好不好」，而是「它的代价我能不能承受」。

一个你付不起代价的好设计，等于一个坏设计。

3.1 Claude Code 的代价

代价 1 · 固定的上下文策略换不掉

得到失去
五级阶梯针对编程场景做到了极致优化，配合私有的 cache_edits 能力，能在压缩的同时保住缓存前缀如果你的工作负载不是编程，你没有出路。五级阶梯的每一级都对「什么信息可以丢」有隐含假设 —— 而那个假设是围绕代码工作流建立的

举个具体的：五级阶梯里的「剪裁」优先丢弃最老的工具结果。在编程场景这通常没问题（你读过的文件内容，需要时可以再读一遍）。但如果你的场景是长期的、有状态的对话（比如一个持续几周的项目管理助手），最老的信息可能恰恰是最重要的约束条件。

代价 2 · 编译期特性开关的双刃

89 个 feature() 开关 + 死代码消除
→ 关掉的功能【物理上不进二进制文件】
得到失去
体积更小、攻击面更小、没有「关掉的功能还残留代码」的风险。而且有「排除字符串检查」这样的构建时验证，确保被禁用的功能真的没漏出来用户不能在运行时开启任何东西。要一个不同的功能组合，就要重新构建一个二进制文件。

而且这套机制本身有复杂度成本 —— 源码里能看到「排除字符串检查」逼出了一个奇怪的回调注入（snipReplay），只为了绕过构建时校验

代价 3 · 单一入口形态

Claude Code 是终端工具。它有 4 种启动形式，但都在终端里。没有聊天平台集成、没有 webhook、没有定时任务。

这换来的是：整套交互设计可以假设「有一个 TTY、有一个人在看、支持 ANSI 转义序列、支持 Ctrl-C」。那 347 KB 的输入框组件之所以能存在，正是因为它只需要服务一种终端。

代价 4 · 闭源

这是最实际的一条：你不能在自己的产品里用它的实现。

本系列的分析基于泄漏的源码，性质是架构学习，不是可复用的代码资产。你能学到设计思路，但要自己重新实现。

而且其中一些关键能力（比如 cache_edits）是 Anthropic 的私有服务端能力，外部开发者根本拿不到。照着抄一个「压缩时不破坏缓存」的实现，是做不到的。

3.2 Hermes 的代价

代价 1 · 抽象层的重量

ContextEngine 抽象基类：490 行接口定义
内置 compressor 实现：   419 KB

→ 接口与实现的比例：490 行 : 419 KB

490 行接口不是「一堆方法签名」，它包含了大量必须遵守的契约说明：

· 生命周期是「不是每轮一次」
· select_context() 的输出必须在所有校验器之前
· 缓存不变式：你的实现不能破坏前缀
· usage 字典的版本演进规则
· protect_first_n 的语义在某个版本变过

一个第三方要写出一个正确的上下文引擎，需要读懂并遵守全部这些约定。这个门槛非常高 —— 高到实践中可能几乎没有人真的换掉默认实现。

那么这 490 行的抽象成本值不值？这是一个真实的、没有标准答案的问题。

代价 2 · 默认不安全

得到失去
本机执行最快、最简单、没有文件同步问题。开箱即用默认安装等于给模型一个完整权限的终端。审计报告的头号「严重」问题

而且这个风险是隐性的 —— 用户不会主动去改一个「已经能正常工作」的默认配置

「安全的默认值」和「好用的默认值」在这里直接冲突。

如果默认是 Docker：新用户第一次跑要等镜像下载，要处理文件同步，可能因为 Docker 没装而直接失败。大量用户会在第一次尝试时流失。

如果默认是本机：所有人都能立刻跑起来，代价是所有人默认处在无隔离状态。

这个权衡没有正确答案，只有明确的取舍。但至少应该在首次运行时明确告知用户当前处于无隔离模式 —— 让风险是「用户知情后接受的」，而不是「用户不知道的」。

代价 3 · 22 个平台的持续维护负担

每个平台适配器要跟进： · API 变更（平台方随时可能改） · 新功能（平台加了新的消息类型） · 废弃（平台下线了某个接口） · 限流规则变化 · 认证方式变化 22 个平台 × 每年若干次变更 = 持续的维护成本 ★ 而且这个成本【永远不会结束】。 它不是一次性的开发投入，是一条永久的负债。

相关的还有一条隐性成本：测试。22 个平台每一个都需要真实的测试账号、测试工作区、测试凭据。全量回归测试的成本极高，实践中很可能做不到。

代价 4 · Python 的分发问题

Claude CodeHermes
Bun 编译成单个可执行文件（296 MB）。下载即用，没有依赖问题Python 包。用户要有正确版本的 Python、要装依赖、要处理虚拟环境、要面对依赖冲突

296 MB 听起来很大，但它换来的是「一个文件，双击就跑」。而任何做过 Python 应用分发的人都知道，「在我机器上是好的」这句话有多常见。

3.3 两边共有的代价

共同代价 1 · 复杂度是不可逆的

Claude Code 的 10 步权限级联、Hermes 的 5,802 行红线 —— 这些复杂度一旦加进去，就再也拿不出来了。

因为每一条规则都对应一个曾经发生过的问题。删掉它，那个问题就会回来。而且删规则的人通常不知道它为什么存在（写它的人可能已经离职了）。

结论：加规则要慎重，因为你是在给系统加一笔永久负债。每一条规则最好都带上「它防的是什么」的注释 —— Hermes 那条记录了 gh pr create --title 事故的注释就是正面例子。

共同代价 2 · 对模型行为的强依赖

两个系统都在提示词里写了大量「你必须这样做」的约束：

这些约束是「劝说」，不是「强制」。

模型可能不听。而且换一个模型版本，服从度就会变化 —— 一段在旧版本上 99% 有效的提示词，在新版本上可能只有 90% 有效，而那 10% 会变成线上事故。

Claude Code 的源码里能看到这个演进痕迹：那条「不许调用工具」的指令原来放在结尾，后来移到了开头，因为发现模型对开头指令的服从度明显更高。

这类依赖是智能体系统特有的技术债：它不在你的代码里，而在模型的权重里，你无法测试也无法控制。

共同代价 3 · 可观测性的成本

Claude Code 有 660 个事件类型、1,093 个埋点。这些代码本身要写、要维护、要在重构时同步更新。Hermes 有事件系统、投递台账、技能使用统计、执行历史。

但这个代价是必须付的 —— 因为智能体系统的失败往往是「行为不对」而不是「报错了」，没有埋点就完全无法排查。

3.4 代价对照总表

维度Claude Code 付出的Hermes 付出的
灵活性上下文策略换不掉；只服务终端场景—
复杂度编译期开关体系（89 个 + 死代码消除 + 排除检查）抽象基类矩阵（6 类扩展点，每个都有完整契约）
安全—默认无隔离（审计头号问题）
维护—22 个平台的永久负债
分发—Python 依赖地狱
可复用闭源 + 依赖私有服务端能力—
共有复杂度不可逆 · 依赖模型服从度 · 可观测性成本

看完这张表你会发现一件事：两边的代价几乎是互补的。

Claude Code 用「灵活性」换「极致优化和分发便利」。
Hermes 用「安全默认值和维护成本」换「无处不在和可替换」。

没有一个选择是免费的，也没有一个是错的 —— 只有「跟你的约束匹配」和「不匹配」。下一章讲怎么判断你的约束是什么。