Small Hermes 自我进化 Agent 架构¶

Ch04.109 Small Hermes 自我进化 Agent 架构¶

📊 Level ⭐⭐ | 15.3KB | entities/small-hermes-self-evolving-agent-architecture.md

核心洞察¶

Agent自我进化之所以难，是因为七个维度的困难相互纠缠，而非某个单独技术问题。Small Hermes（Rust）的解法是一组相互支撑的设计决策，缺一不可。

七重困境 → 设计决策映射¶

三层上下文架构¶

Pinned Memory（始终加载）
  → 核心偏好、关键约束，永远在系统提示中

Active Memory Index（索引加载）
  → 所有活跃记忆的一行摘要，让LLM知道"我知道什么"
  → 需要时可主动查询详情

Triggered Skills（按需加载）
  → 只注入与当前查询相关的技能全文
  → 用token overlap匹配，不依赖嵌入模型

反思机制设计¶

保守提示词原则："宁可漏掉一个值得提炼的技能，也不要产生一个低质量的技能"

微反思启发式：

fn should_micro_reflect(turns_since_last, messages) -> bool {
    if turns_since_last < 3 { return false; }
    if has_intent_keywords(messages) { return true; }  // 记住/以后/偏好
    if tool_call_count(messages) >= 2 { return true; }
    if has_write_ops(messages) && output_length > 1500 { return true; }
    false
}

单向数据流约束¶

1. Agent Loop运行时，Memory和Skill Store是只读的
2. 反思只产生候选，不直接修改存储——审批是唯一的写入路径
3. 工具调用是无状态的
4. 上下文组装是纯函数——同样的输入永远产生同样的系统提示

反模式警示¶

• RAG ≠ 进化：RAG是检索，进化是修改Agent自身行为
• 自动接受 = 灾难：人类审批不是摩擦，是特性
• 过早向量化：50技能下token overlap延迟<1ms，不需要向量数据库
• 微调 ≠ 进化：不可审计、不可逆、数据质量不可控
• 忽视组合：循环依赖导致意想不到的副作用

成熟度模型¶

反直觉真相：自我进化的关键不是"进化得多快"，而是"退化得多慢"。安全围栏、人工审批、冲突检测这些"减速带"是进化的保障。

深度分析¶

七重困境的相互纠缠性¶

七重困境并非独立存在，而是相互耦合：

• 方向×成本：没有清晰方向→无效反思→浪费算力
• 容量×组合：容量越大→组合爆炸越严重→需要最小接口
• 安全×进化：安全收紧→进化受限→不可变核心是解耦手段
• 一致×质量：记忆冲突→反思素材质量下降→需要冲突解决策略

Small Hermes的核心贡献在于同时给出七个解法，且七个解法相互支撑，形成自洽的设计体系。

三层上下文架构的工程价值¶

三层上下文架构解决了LLM Agent的上下文经济学问题：

token overlap匹配的精妙之处：不需要额外的嵌入模型，在50个技能下延迟<1ms，同时保持了精确性。当技能规模超过阈值后，才需要考虑向量检索升级。

双轨反思的成本控制逻辑¶

全量反思（Session End）和微反思（Per-Turn）的本质区别：

// 全量反思：~2000-5000 tokens in
// 产出：技能候选 + 记忆候选 + 冲突候选
// 触发：会话结束，累积数据充分

// 微反思：~500 tokens in
// 产出：最多1个记忆 + 1个技能
// 触发：启发式（intent keywords / 工具调用≥2 / 大文件写入）

双轨设计让反思成本与信息价值匹配：高频轻量×低频重量，避免每次交互都付出全量反思的代价。

不可变核心的哲学意义¶

"安全约束必须在代码层面强制执行，不能依赖LLM的理解"——这个原则划清了工程约束和提示工程的边界：

• 工程约束（forbid unsafe code、路径沙箱、API key隔离）→ 确定性保证
• 提示工程（"请不要做X"）→ 概率性保证，在对抗场景下不可靠

不可变核心将安全关键的约束与业务逻辑分离，确保核心行为不被"进化"破坏。

单向数据流与系统可靠性¶

单向数据流是Small Hermes的系统稳定性保障：

用户输入 → 上下文组装（只读）→ Agent Loop → 反思候选 → 用户审批 → 写入

关键性质： - 上下文组装是纯函数：同样的记忆+技能+输入 → 同样的系统提示（可重现性） - 写入路径唯一：只有审批后才能修改存储（可控性） - 工具调用无状态：工具调用不产生副作用（隔离性）

这三条性质使得系统行为可预测、问题可定位、故障可回滚。

与其他Hermes篇章的关系¶

实践启示¶

Self-Evolving系统设计原则¶

1. 先解耦再进化：先有纯函数上下文组装和单向数据流，再引入进化机制
2. 进化必须有方向：人类在回路中，进化方向由用户定义，不是Agent自主决定
3. 容量管理优先于检索优化：三层上下文架构优先于RAG/向量检索
4. 安全约束工程化：安全关键约束必须在代码层面强制，不可依赖提示词

判断系统是否真正自进化的标准¶

小规模优先策略¶

Small Hermes的经验：50个技能下不需要向量数据库，token overlap匹配足够。具体来说： - 触发匹配：基于token重叠率，不需要嵌入模型 - 延迟：<1ms（50技能规模） - 精度：对于技能命名良好的场景足够

过早引入向量数据库是技术债务，在规模尚小时徒增复杂度。

反模式警示（详细版）¶

→ 原文存档