# 自动化信任的边界在哪里

## Hermes 和 Claude Code：同一个问题的两种回答

前面四篇从知识标准化、记忆注入、自动改进到多 agent 协作，一路讨论的都是 Hermes 怎么让 agent 变得更强。现在该问一个更根本的问题：这些越来越强的能力，应该被赋予多大的自主权？

Hermes 和 Claude Code 在这个问题上走了两条路。

Hermes 支持 200 多个模型和 16 个以上的平台，设计取向是让系统在运行中自主学习和进化。背后的工程假设是：系统通过积累经验会变得更好，人工干预的成本会随复杂度增长变得不可持续。这个假设在系统规模足够大的场景中是成立的。当一个系统每天处理数万个任务时，人工逐一审核确实不可行。

Claude Code 强调上下文工程和沙箱隔离，把可预测性作为首要目标。系统行为边界提前定义好，运行时的自主决策空间被刻意收窄。背后的假设是：可预测性比自适应性更有价值，工程师需要能理解和审计系统的每一步。这个假设在错误代价高、系统规模可控的场景中是成立的。

在《人机协作是光谱》中我们讨论过，从 human-in-the-loop 到 human-on-the-loop 是一个渐进的信任交付过程。Hermes 和 Claude Code 的分歧本质上是这个光谱上的位置选择。一端是更大自主权和更高潜在上限，另一端是更强可控性和更低风险下限。两个位置都是合理的，区别在于它们各自适合的场景不同。

## 自动生成配置的反面证据

ETH Zurich 的一项研究提供了一个值得注意的数据点：LLM 自动生成的配置在某些场景下反而损害系统性能，同时多消耗了 20% 的 token。

这个结果让人警惕。它说明自动化改进的方向可能是错的，而且这种错误在短期内不一定能被检测到。系统可能在一个错误方向上持续优化，消耗资源的同时让性能逐步退化。每次提交都通过了单元测试，但累积起来性能逐步变差。这种"渐进退化"跟软件工程里的性能回归问题有相似的特征，只有趋势图才能揭示。

我认为这个研究结果的深层含义是：自动化改进系统需要一个独立于改进过程本身的"健康度监控"。仅仅检查每次改动是否通过测试是不够的，还需要追踪长期趋势。一个系统可能在每次局部改动都是"改善"的情况下，整体走向退化。这跟登山时总是选择局部最陡的方向前进，最终却到达了一个局部最大值而非全局最优的情况是同构的。

这也解释了为什么"可预测性优先"的设计取向在某些场景下更有吸引力。如果自动优化的可靠性还不能被充分验证，保持人工控制至少能避免系统朝错误方向演化。这跟《约束让 Agent 更好用》的核心论点是一脉相承的：有时候限制比自由更有工程价值。

## 安全模型的两条路

安全约束的设计也反映了光谱上的位置选择。

Hermes 生态中的 CaMeL 项目用了五层安全模型，核心是数据流信任边界：不同来源的数据有不同信任等级，处理低信任数据时自动提升安全约束。205 个测试用例覆盖了主要场景。精细度很高，可以针对不同数据和操作设置差异化安全策略，但维护成本也高。每种新的数据类型和操作模式都需要补规则。我认为 CaMeL 的设计哲学本质上是"显式建模信任"：把通常只存在于工程师脑中的信任判断编码成可执行的规则。这种显式化有巨大的审计价值，代价是规则库的增长速度可能跟不上新场景的出现速度。

Claude Code 的沙箱隔离走粗粒度路径。不管 agent 在沙箱内做什么，影响被限制在边界以内。维护成本低，不用为每种操作定义细粒度规则。灵活性也相应低：沙箱内的 agent 无法访问沙箱外资源，即使访问是安全且必要的。粗粒度的优势是它的安全保证不依赖规则的完整性。即使有人忘了为某种新操作写规则，沙箱边界仍然有效。

这两种模型在实践中更可能互补而非替代。高信任环境下用细粒度的数据流模型，允许 agent 在较大范围内自主操作。低信任或高风险环境下用沙箱兜底，用物理边界来防止最坏情况。一个成熟的部署可能会同时使用两者：沙箱作为最外层的硬性边界，CaMeL 式的数据流模型在沙箱内部提供更细致的权限控制。

## 桥接在技术上可行，但安全标准还没对齐

evey-bridge-plugin 证明了 Hermes 和 Claude Code 之间的双向桥接在技术上是可行的。agentskills.io 的标准格式为桥接提供了共享的知识表示层。

但技术可行不等于工程可靠。桥接意味着两个框架的执行边界变得模糊：一个自主进化的系统可以调用受控系统的能力，反过来也行。调用跨越信任边界时，需要额外检查确保信任等级不会通过桥接传递。具体来说，如果 Hermes 侧一个低信任的自动生成 skill 通过桥接调用了 Claude Code 侧的高权限操作，整个安全模型就可能被绕过。

目前的状况是：能力标准通过 agentskills.io 有了初步统一，安全标准还没有对应的跨框架协议。两家各有完善的内部安全制度，但 API 对接时"对方安全等级是否可信、出事谁负责"这些问题还缺一个双方认可的协议。我认为这个问题的解决路径不是技术性的，而是生态治理层面的。它需要的是框架之间的互信建立和责任划分协议，类似于互联网早期 ISP 之间的对等互联协议。

## 监控成本：一个容易被低估的变量

信任边界的讨论往往集中在"允许做什么"上，但"监控成本有多高"同样重要。自主权越大，监控越必要。但监控本身消耗资源：审计日志占存储，行为分析消耗算力，人工审查消耗工程师时间。

很多关于自动化信任的讨论低估了监控成本。概念论证阶段默认监控免费。到了实际部署才发现，维持有意义的监控所需投入，有时候跟被监控系统本身的运行成本在同一量级。如果监控系统本身也用 LLM 来分析日志和检测异常，监控的 token 消耗可能跟被监控系统的 token 消耗差不多。

这形成了一个有意思的困局：系统越自主→监控越重要→监控越贵。到某个点上，监控成本超过自主化带来的效率收益。这意味着自主权的扩大有一个经济上的天然上限。我认为很多团队在规划 agent 自动化时没有把监控成本纳入 ROI 计算。如果把监控成本加进去，很多看起来有正 ROI 的自动化方案会变成负数。

一个务实的推论是：与其追求更高程度的自主化（然后承担更高的监控成本），不如在当前自主权水平上优化效率。也就是说，在信任边界固定的情况下，让 agent 在已有权限内做得更好，比扩大权限范围的性价比更高。

## 没有通用最优解

从前面四篇的讨论可以看到，从知识标准化到记忆注入，从多层改进到多 agent 协作，每一层都涉及"给系统多大自主权"的取舍。这些取舍高度依赖场景，没有一个位置对所有情况都最优。

一个可能的操作框架是根据任务的可逆性来设定边界。可逆操作（生成报告草稿、建议配置修改方案）给较大自主空间，错误可以回退。不可逆操作（删除数据、修改生产环境配置）需要人工审核门控，错误代价没法撤销。

这个框架听起来简单，实践中有个困难：很多操作的可逆性是模糊的。一个看似可逆的配置修改，如果修改和回退之间有外部状态变化，可能就没法完全恢复。更隐蔽的情况是：操作本身可逆，但操作期间产生的影响不可逆。比如一个 agent 自动发出的邮件，邮件内容可以更正，但"客户已经读了错误版本"这个事实无法撤回。

更现实的路径可能是：从保守的信任边界开始，随着对系统行为的观察和理解逐步积累，有选择性地扩大自主权范围。每次扩大都需要对应的监控和回滚机制。这个渐进式的信任建立过程没有终点。它会随系统能力和应用场景的变化持续调整。

我认为这个"渐进式信任建立"的核心原则是：扩大自主权的决策应该基于证据而非信念。不是"我相信这个系统能处理好"，而是"过去 N 次操作的数据表明这个系统在这类场景中的失败率低于 X%"。这种基于证据的信任扩大，速度可能比直觉判断慢，但每一步都有可验证的基础。

Hermes 选择了光谱上"更自主"的位置，Claude Code 选择了"更受控"的位置。对于大多数团队，答案可能是两者的组合：用 harness 工程的原则约束 agent 的自主边界，同时在明确的安全约束内利用 learning loop 来持续改进特定能力。具体的边界在哪里，取决于你的场景风险、团队能力和监控预算。