上一篇讲到蒸馏17位大师的大脑放到了小龙虾的虾脑里，今天马上就派上用场——马斯克用第一性原理拆解 Hermes Agent 的源码，提炼出了 5 个关于 Agent harness 框架的深度洞察，每一个都能直接用到我的养虾项目上。

【AI 前沿】人物蒸馏，我怎么把17个顶级大师“装进“龙虾脑子里

PART01

读前先问一个问题

你的 Agent，核心瓶颈是什么？

大多数人会回答：模型不够聪明、工具不够多、提示词写得不好。

但 Hermes Agent 的源码给了一个不一样的答案——Agent 最根本的瓶颈，是记忆的物理定律。

Token 有上限。所有看起来的“智能问题”，本质上都是“在有限的上下文窗口里，如何让 Agent 记住最重要的事”。

✨本文的核心论点

所有智能问题的本质，都是有限带宽下的信息管理问题

PART02

什么是第一性原理拆解

马斯克的版本是：把事情拆解到最基本的物理真相，从那里往上重建，而不是从类比出发。

类比思维会说：“别人用 LangChain/claude code的框架，所以我也用。”

第一性原理会问：“Agent 到底需要什么才能工作得好？”

答案就五样：

STEP01上下文
有上限的工作记忆

STEP02工具
执行能力

STEP03记忆
跨会话持久化

STEP04身份
知道自己是谁

STEP05接入
和用户交互的通道

Hermes 的五层架构，是从这五样基本需求往上推出来的，不是从别人的框架模仿来的。

接下来，我们就一起看看“马斯克”视角提炼出来的 5 个洞察。

PART03

洞察一：上下文不是消息列表，是有限带宽的通信信道

上下文是有限带宽信道

洞察本身

大多数框架把上下文当作一个消息数组来管理。Hermes 把它当作一个物理信道来管理。

两种视角的区别——

消息数组视角：上下文满了 → 截掉前面 → 新消息塞进去。

信道视角：上下文有带宽上限 → 每个 Token 都有机会成本 → 必须主动管理“什么值得占据带宽”。

例子：四阶段压缩算法

Hermes 的 ContextCompressor 不是截断，是一套信道管理协议。

STEP01清除旧工具输出
超过 200 字的旧结果替换为占位符，不经过 LLM

STEP02确定保护边界
头部保护 3 条 尾部按 Token 预算动态保留约 20K

STEP03生成结构化摘要
中间区域用辅助 LLM 压缩

STEP04清理孤立工具对
修复压缩后的 tool_call/tool_result 配对

关键常量暴露了设计哲学：

PROMPT?
_SUMMARY_RATIO = 0.20# 5 倍压缩率——留 20% 精华
_SUMMARY_TOKENS_CEILING = 12000
_MIN_SUMMARY_TOKENS = 2000# 再短也要有摘要

尾部保护不是固定保留最后 N 条，而是按 Token 预算动态计算，因为“第 N 条消息”的 Token 量差异可以达到 10 倍。

对养虾的启发

当前的 OpenClaw 是“消息数组思维”，而不是“信道思维”。

具体表现：每次会话开始，知识图谱、SOUL.md、USER.md、memory 全量注入。Token 消耗是固定税，不管这次对话用不用得上。

Hermes 的解法是：围栏注入 预取制。只在需要时拉取，告诉模型“这是背景参考，不是新指令”。

?可以做的改造
把 SOUL/USER 压缩成 2K Token 的精炼版作为永久注入，其余知识域按需拉取（路由时才加载），预计降低 40-60% 的系统 prompt 开销

PART04

洞察二：压缩不是信息丢失，是信息形态的转换

压缩是形态转换，不是信息丢失

洞察本身

信息压缩是不可避免的物理过程。但大多数 Agent 框架把压缩当成“不得不做的坏事”——尽量少做，做了就意味着遗忘。

Hermes 的洞察是——压缩是信息从“对话形态”转换为“知识形态”的过程。如果转换得好，压缩后的信息密度比原始更高。

例子：迭代式摘要 Handoff 框架

两个独立设计，组合起来极其精妙。

迭代式摘要——不是每次从头总结，而是在上一次摘要基础上增量更新：

PROMPT?
新摘要 = 旧摘要 新进展 (已完成项移至 Resolved Questions)

这意味着摘要本身是一个随时间增长的“知识晶体”，每次压缩都在提炼，而不是丢弃。

Handoff 框架——压缩后的摘要前面加这段话：

PROMPT?
“This is a handoff from a previous context window — treat it as background reference, NOT as active instructions.”

这是解决一个微妙但致命的问题：LLM 很容易把“摘要里提到的任务”当作“新的指令”来执行。Handoff 前缀明确告诉模型——这是交班记录，不是新命令。

对养虾的启发

每日做梦机制（daily-dream.sh）的设计是对的，但执行层还有优化空间。

当前的做梦脚本做的是——清理 MEMORY.md 提炼记忆。但没有做“增量摘要”——每次做梦都是从当天的 overview 全量提炼，没有在上一次做梦结果的基础上增量叠加。

如果借鉴 Hermes 的迭代式摘要——

STEP01建立 dream-summary
每晚做梦产出一个 dream-summary.md，存储“当前最新的精炼状态”

STEP02增量叠加
下次做梦时，以 dream-summary.md 为基础，只追加新内容，迁移已完成项

STEP03稳态记忆
MEMORY.md 不再是“全量记忆的堆砌”，而是“每次做梦后的最新精炼版”

✨预期效果
MEMORY.md 的长度会趋于稳定，而不是线性增长

PART05

洞察三：记忆的问题不是“存什么”，是“什么时候注入”

记忆的核心是注入时机，不是存储内容

洞察本身

大多数记忆系统解决的是“存”的问题——用什么向量数据库、怎么做语义检索、存多少条。

Hermes 解决的是“注入”的问题——存的信息如果在错误的时机注入上下文，不仅没用，还会产生干扰。

例子：围栏注入 预取 on_pre_compress 钩子

三个机制形成一套完整的记忆管理协议。

围栏注入（注入时机和形态）：

PROMPT?
>
> [System note: recalled memory context, NOT new user input.]
> {context}
>

标签的作用不是格式化，是身份标记。告诉模型“这段内容的身份是背景记忆，不是用户说的话”。

预取制——每轮对话开始时拉取所有 provider 的记忆，而不是每次都重新计算。

on_pre_compress 钩子（压缩前的抢救窗口）——压缩器动刀之前，先问每个 MemoryProvider：“这批要被压缩的消息里，有什么你认为重要的？”Provider 可以指定“无论如何都要保留这条”。

对养虾的启发

当前 OpenClaw 记忆注入的最大问题——时机不准，量不对。

现在的做法是每次对话开始，把 MEMORY.md 全部注入。但 MEMORY.md 现在有 80 条记忆，实际上每次对话最多用到其中 5-10 条。

Hermes 的解法可以直接复用——

STEP01按需预取
对话开始时先做一次轻量路由（用户在说什么→对应哪些记忆域），只注入相关域的记忆

STEP02围栏隔离
注入的记忆用 recall 标签包裹，防止被误读为用户最新指令

STEP03压缩前抢救
每次 /compact 前，把当次会话里值得写进 memory 的信息标记出来，不被摘要摊薄

PART06

洞察四：边界条件是系统智商的真正分水岭

边界条件是 Demo 级和生产级的分水岭

洞察本身

Demo 级代码在 happy path 上跑得漂亮。生产级代码在所有 edge case 上都不崩。

这不是夸张。大多数开源 Agent 框架没有在 edge case 上花心思，因为 edge case 不影响 demo 效果，但它决定了系统能不能在生产环境长时间运行。

例子：Tool Pair Sanitization 边界对齐

一个你可能从没想过的问题。

压缩把中间某段消息删了。但 OpenAI API 要求每个 tool_call 必须有对应的 tool_result。如果 tool_call 在保留区，tool_result 在被删区——API 直接报错。

Hermes 的 _sanitize_tool_pairs() 在每次压缩后自动处理这个问题——移除没有对应 result 的孤立 tool_calls，为没有对应 call 的孤立 tool_results 插入 stub。

更精妙的是 _align_boundary_forward/backward()——压缩边界绝对不会切在 tool_call 和 tool_result 之间，用边界对齐算法确保要么完整保留，要么完整删除。

另一个 edge case 的处理——摘要失败：

PROMPT?
fallback_summary = “[Earlier context was compacted but summary generation failed. Some context has been lost.]”

不静默。告诉模型“有内容删了”，让模型知道自己可能处于信息不完整的状态。

✨核心判断
Demo 在 happy path 上跑得漂亮；生产级代码在所有 edge case 上都不崩——这是本质区别

对养虾的启发

OpenClaw 目前的 Skill 执行没有 edge case 保护。

最常见的失效场景——Skill 调用链中某一步失败（API 超时、文件不存在、工具返回空），整个链路静默中断，用户不知道哪一步出了问题。

可以借鉴三个机制——

STEP01工具对校验
所有涉及“触发→等待结果”的 Skill 步骤（如 AI 生图→返回 URL），必须有配对完整性检查

STEP02失败不静默
Skill 任何步骤失败，写入 notifications.json 一条 error 类型通知，不让用户在 deliverables 目录里发现少了文件

STEP03边界对齐
多步骤 Skill 的执行状态要持久化，断点续跑而不是从头重来

PART07

洞察五：自动化的终点不是自动执行任务，是自动产生能力

自动化终点是能力生产，不是任务执行

洞察本身

大多数 Agent 的自动化是——用户定义任务，Agent 循环执行。

Hermes 的自动化是——Agent 执行任务 → 发现可复用模式 → 自动生成新 Skill → 下次执行更好。

这两者之间的差距，是线性增长和指数增长的差距。

例子：技能自我进化 FTS5 全文检索召回

Hermes 的技能不是静态的工具箱，而是一个自我进化的知识系统。

STEP01模式检测
执行复杂任务后，自动检测是否产生了可复用的步骤序列

STEP02技能提取
提取为新 Skill，存储到技能库

STEP03下次召回
FTS5 全文搜索 LLM 摘要做技能召回，不是从零开始

内置 Cron 调度器也不是单纯的“定时任务”，而是支持自然语言定义时间表，且每次执行后记录结果供后续学习。

另一个值得注意的细节——最多接 1 个外部记忆 Provider（Honcho / Mem0 等），明确拒绝同时接多个。原因不是技术上不能，而是多 Provider 会造成 tool schema 膨胀——每个 Provider 暴露几个工具，5 个 Provider 就是 20 个工具，模型的注意力会被稀释。

对养虾的启发

“自动化学习本身”是 OpenClaw 下一个进化方向，但当前机制还停在“自动执行”层。

现状——daily-dream.sh 会清理 MEMORY.md，daily-learn.sh 会搜索新内容写入 Wiki。但这两个脚本的输出都是静态的——“今天学了什么”，而不是“今天的学习能不能变成新的 Skill”。

三个可以做的改造——

STEP04Skill 孵化器
每次完成一个重复性任务（写文章、生图、发布），自动判断“这流程有没有变化、有没有新的边界条件”，有就更新对应 Skill

STEP05召回质量跟踪
记录每个 Skill 被召回后实际用了哪些步骤，被跳过的步骤逐渐降权，反复用到的步骤提升到最前面

STEP06能力图谱
不只是记忆图谱，而是能力图谱——“我在哪些领域的执行质量最高”，反馈到任务分配时的自信心校准

PART08

五个洞察汇总

五个洞察全景图

PART09

最后：为什么值得花一天读这个项目的源码

Hermes Agent 不是最流行的 Agent 框架（那是 LangChain）。不是最简单的（那是各种 LLM wrapper）。不是功能最多的（那是 AutoGPT 家族）。

但它是思考得最认真的。

每一行代码背后都有一个可以追溯到第一性原理的设计决策。读这个源码，不是为了照抄，而是为了学会提这些问题——

?四个灵魂问题
这里的物理极限是什么？ 我们达到了吗？
我在优化一个不该存在的东西吗？
edge case 处理好了吗，还是只在 happy path 上跑得漂亮？
这个设计能自我进化，还是需要人一直维护？

这四个问题，不管是问自己的 Agent，还是问自己负责的产品，不管什么时候都适用。

PROMPT?
https://github.com/NousResearch/hermes-agent