如果自我进化只是一个“反思循环”，为什么几乎没有人做对？
相传，在很久很久以前，我用 3000 行 Rust 实现了自我进化的 Agent，项目名叫 small-Hermes。但那篇文章回避了一个更根本的问题：为什么这件事这么难？ 市面上有无数的 Agent 框架，但真正能“越用越聪明”的寥寥无几。大多数 Agent 今天什么样，三个月后还是什么样。
这篇文章要拆解这个问题。我们先分析 Agent 自我进化的核心困难，然后给出一个科学的设计框架——不是理论推演，而是 Hermes 在实践中验证过的路径。
一、先搞清楚：一个 Agent 到底由什么组成
在讨论进化之前，我们需要先定义“Agent”本身。剥离所有营销术语，一个可用的 Agent 至少需要以下组件：
┌──────────────────────────────────────────────────────────────┐
│ Agent 全景图 │
├──────────────────────────────────────────────────────────────┤
│ │
│ 1. Agent Loop（智能体循环） │
│ 用户输入 → LLM 推理 → 工具调用 → 结果反馈 → 继续推理 │
│ │
│ 2. Tool System（工具系统） │
│ 工具发现 · 工具调用 · 结果解析 · 错误处理 │
│ │
│ 3. Context Management（上下文管理） │
│ 系统提示组装 · 上下文压缩 · 优先级排序 · 窗口控制 │
│ │
│ 4. Long-term Memory（长期记忆） │
│ 事实存储 · 偏好记录 · 冲突检测 · 衰减机制 │
│ │
│ 5. Skill System（技能系统） │
│ 技能提炼 · 触发匹配 · 技能执行 · 技能组合 │
│ │
│ 6. Safety Guardrails（安全围栏） │
│ 路径沙箱 · 操作审批 · 资源限制 · 行为约束 │
│ │
│ 7. Sub-Agent / Delegation（子智能体 / 委托） │
│ 任务分解 · 并行执行 · 结果聚合 · 错误隔离 │
│ │
│ 8. Persistence（持久化） │
│ 会话存储 · 状态恢复 · 原子写入 · 崩溃恢复 │
│ │
└──────────────────────────────────────────────────────────────┘
每一个组件单独实现都不算太难。真正的困难在于组合——这些组件之间有复杂的交互关系，而“自我进化”要求在运行时动态修改其中多个组件的行为。
自我进化的七重困境
困境一：进化的方向由谁决定？
这是最根本的问题。一个 Agent 可以往无数个方向“进化”——变得更谨慎、更激进、更健谈、更沉默、更擅长代码、更擅长写作，但哪个方向是“更好”？这可不是 Agent 自己说了算，这应该由用户来衡量。
大多数系统回避了这个问题，把进化等同于“积累更多数据”。 但数据不等于智慧。一个记住了 1000 条用户偏好的 Agent，不一定比一个只记住 3 条核心偏好的 Agent 更好用，反而可能因为信息过载而变得更差。
Hermes 的解法：人类始终在回路中。 每一个反思产生的候选（技能、记忆、冲突）都必须经过用户确认。这不是技术限制，这当然是刻意为之的设计选择。进化的方向由人类定义，Agent 只负责发现进化的机会。
困境二：上下文窗口是有限的
Agent 的“工作记忆”受限于 LLM 的上下文窗口。即使你有 1M tokens 的窗口，也不可能把所有记忆和技能都塞进去。这就产生了一个残酷的权衡：
- 塞太多 → 上下文被无关信息淹没，推理质量下降
- 塞太少 → Agent 忘记了它应该知道的东西，重复犯错
更糟糕的是，这个权衡是动态的——不同的对话需要不同的上下文。一个关于 Rust 的对话不需要加载 Python 相关的记忆，反之亦然。
Small Hermes 的解法：三层上下文架构。
第一层：Pinned Memory（始终加载）
→ 核心偏好、关键约束，永远在系统提示中
第二层：Active Memory Index（索引加载）
→ 所有活跃记忆的一行摘要，让 LLM 知道"我知道什么"
→ 需要时可以主动查询详情
第三层：Triggered Skills（按需加载）
→ 只注入与当前查询相关的技能全文
→ 用 token overlap 匹配，不依赖嵌入模型
这种分层策略让 Agent 在有限的窗口内拥有最大的“认知灵活性”。
困境三：记忆会冲突
随着 Agent 积累越来越多的记忆，冲突不可避免：
- 用户上周说“我喜欢用 Python”，这周说“我现在主要用 Rust 了”
- 项目 A 的约定和项目 B 的约定矛盾
- 旧的记忆基于过时的信息
如果不对冲突进行处理，Agent 会同时持有矛盾的认知，行为变得不可预测。如果简单地用新记忆覆盖旧记忆，又会丢失重要的上下文（比如“为什么改变了偏好”）。
small Hermes 的解法：Supersedes 链 + 冲突检测。
# 旧记忆
---
id: mem_001
tags: [preference, language]
---
用户偏好使用 Python 进行数据分析。
# 新记忆（supersedes 旧记忆）
---
id: mem_002
supersedes: [mem_001]
tags: [preference, language]
---
用户已转向 Rust，不再使用 Python。
旧记忆不会被删除——它保留在文件系统中作为审计轨迹。但 list_active() 会自动过滤掉被 supersede 的记忆。当反思发现冲突时，系统提供五种解决策略：
- 保留新记忆（keep_new）——旧认知被推翻
- 保留旧记忆（keep_old）——新信息不可靠
- 合并（merge）——打开编辑器，人工融合
- 作用域拆分（scope_split）——两个都对，只是场景不同
- 跳过（skip）——暂时不处理
困境四：技能的质量无法自动保证
一个“技能”本质上是 Agent 对某个工作流的压缩——把多步操作提炼为可复用的模板，或者说是一份操作说明书，这都对。但 LLM 生成的技能质量参差不齐：
- 过于具体的技能（“在项目 X 的 Y 分支上执行 Z 命令”）没有复用价值
- 过于抽象的技能（“写好代码”）没有可操作性
- 包含过时信息的技能（依赖已变更的 API）会导致错误
更危险的是，低质量的技能一旦进入系统，会在后续对话中被反复触发，产生连锁错误。
small Hermes 的解法：三层防线。
防线一：反思提示词的保守设计
→ "宁可漏掉一个值得提炼的技能，也不要产生一个低质量的技能"
→ 要求 LLM 给出 rationale 和 confidence
→ confidence 为 "high" 应该是罕见的
防线二：人工审批
→ 每个技能候选都必须经过用户确认
→ 用户可以看到技能的名称、描述、触发词、正文和理由
防线三：反思日志的元分析
→ 每次审批结果（接受/拒绝/推迟）都记录到 reflect-log.jsonl
→ 如果某个类型的候选持续被拒绝，说明反思提示词需要调整
→ 这是"对进化的进化"——元反思
困境五：进化本身有成本
反思需要调用 LLM，而 LLM 调用是有成本的——不仅是金钱成本，还有延迟成本。如果在每次对话结束后都做一次全量反思，用户需要等待额外的 5-10 秒。如果在每轮对话中都做反思，成本和延迟会更高。
但如果不做反思，Agent 就不会进化。这是一个时间/成本/质量的三维权衡。
small Hermes 的解法：双轨反思。
全量反思（Session End）
→ 处理完整对话记录
→ 成本：~2000-5000 tokens in, ~500-1000 tokens out
→ 时机：对话结束时
→ 产出：技能候选 + 记忆候选 + 冲突候选
微反思（Per-Turn）
→ 只看最近一轮交互
→ 成本：~500 tokens in, ~200 tokens out
→ 时机：满足启发式条件时，异步执行
→ 产出：最多 1 个记忆 + 1 个技能，confidence ≤ medium
微反思的启发式触发条件：
fn should_micro_reflect(turns_since_last, messages) -> bool {
if turns_since_last < 3 { return false; } // 太频繁
// 显式意图词：记住/以后/偏好/remember/always/prefer
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
}
这样，大部分对话不会触发反思（因为大部分对话确实不需要产生新知识），但那些“值得记住的瞬间”不会被遗漏。
困境六：安全与进化的矛盾
自我进化的本质是“Agent 修改自身的行为”。这天然与安全性冲突：
- 如果 Agent 可以自动修改自己的系统提示，它可能绕过安全约束
- 如果 Agent 可以自动接受新的技能，恶意技能可能被注入
- 如果 Agent 可以自动修改记忆，它可能“忘记”安全规则
这是一个经典的“谁来看守看守者”问题。
small Hermes 的解法：不可变核心 + 可变外围。
不可变核心（硬约束，代码层面强制）：
→ 工具的路径沙箱：所有文件操作必须在 workspace 内
→ 反思候选永不自动生效：必须人工确认
→ API key 永不记录到日志
→ unsafe code 被 forbid
可变外围（软约束，可被进化修改）：
→ 记忆和技能：通过反思机制增删改
→ 系统提示中的记忆/技能注入：动态组装
→ 工具列表：通过 MCP 动态扩展
关键洞察：安全约束必须在代码层面强制执行，不能依赖 LLM 的“理解”。 系统提示里写“请不要访问 workspace 外的文件”是软约束——LLM 可能忽略它。但 safety::resolve() 函数在路径规范化后检查前缀，这是硬约束——LLLM 无法绕过。
困境七：组合爆炸
这是最隐蔽的困境。单独看每个组件，设计都不复杂：
- Agent Loop：一个 while 循环
- 工具调用：一个 trait + 实现
- 上下文管理：消息列表 + 压缩
- 记忆：文件读写
- 技能：文件读写 + 关键词匹配
- 安全：路径检查
但当这些组件组合在一起，交互的复杂度是 O(n²) 级别的：
- 记忆影响系统提示 → 系统提示影响 LLM 推理 → LLM 推理影响工具调用 → 工具调用产生新记忆
- 技能被触发 → 改变了工具调用序列 → 产生了不同的结果 → 触发了不同的微反思
- 上下文压缩丢弃了某些消息 → LLM 基于不完整信息推理 → 产生了错误的反思候选
这就是为什么很多 Agent 框架“每个模块单独看都很好，组合起来就不work”。
small Hermes 的解法：最小接口 + 单向数据流。
组件间的数据流（严格单向）：
User Input
│
▼
Context Assembly ──←── Memory Store (只读)
│ ──←── Skill Store (只读)
▼
Agent Loop
│
├──→ Tool Host (无状态调用)
│
├──→ Micro Reflection ──→ 候选 (需审批)
│
▼
Session End
│
▼
Full Reflection ──→ 候选 (需审批)
│
▼
User Approval ──→ Memory Store (写入)
──→ Skill Store (写入)
关键约束：
- Agent Loop 运行时，Memory 和 Skill Store 是只读的——不会在对话中途修改自身
- 反思只产生候选，不直接修改存储——审批是唯一的写入路径
- 工具调用是无状态的——每次调用独立，不依赖前次调用的副作用
- 上下文组装是纯函数——同样的输入永远产生同样的系统提示
这些约束消除了循环依赖，让每个组件可以独立理解和测试。
那么，我是如何设计框架的，从而实现，从 0 到 1 构建可进化 Agent
基于以上分析，我们提炼出一个科学的设计框架。它绝对不是“最佳实践”的罗列，我固化了一组有严格依赖关系的设计决策。
第一步：定义 Agent Loop 的核心抽象
不要从“进化”开始，要从“循环”开始。一个不能稳定运行的 Agent 谈不上进化。没错，这是我的核心底座。
// 核心循环只需要两个抽象
trait LlmProvider {
async fn complete(&self, req: CompletionRequest) -> Result<CompletionResponse>;
async fn stream(&self, req: CompletionRequest) -> Result<BoxStream<StreamEvent>>;
trait ToolHost {
async fn list_tools(&self) -> Result<Vec<ToolSpec>>;
async fn call(&self, name: &str, args: Value) -> Result<ToolCallOutcome>;
}
两个 trait，四个方法。这就是 Agent Loop 需要的全部外部依赖。LLM 负责推理，Tool 负责行动，Loop 负责协调。
常见错误： 在这一步引入过多的抽象——事件总线、插件系统、配置 DSL。这些是“未来可能需要”的东西，但它们增加了当前的复杂度，而当前你连基本循环都没跑通。
第二步：实现上下文管理
Agent Loop 能跑之后，第一个瓶颈一定是上下文窗口。你需要：
- 动态系统提示组装——不是写死一个 system prompt，而是根据当前状态动态拼接
- 上下文压缩——当消息超过阈值时，用 LLM 总结旧消息
- 优先级机制——哪些信息必须保留，哪些可以丢弃
系统提示组装顺序：
基础提示（角色定义 + 安全约束）
+ Pinned 记忆（始终加载）
+ 活跃记忆索引（一行摘要）
+ 可用技能列表（名称 + 描述）
+ 触发技能正文（与当前查询匹配的技能）
关键决策： 记忆和技能在系统提示中的呈现方式不同。记忆是“你知道什么”，技能是“你会什么”。记忆用索引 + 按需详情，技能用触发匹配 + 全文注入。这种不对称设计是因为记忆通常是被动参考，而技能是主动执行。
第三步：实现持久化
在引入进化之前，Agent 必须能持久化——会话可以恢复，状态可以重建。
持久化要求：
→ 会话记录：JSONL 格式，每行一个事件，崩溃可恢复
→ 原子写入：先写临时文件，再 rename，避免半写状态
→ 人类可读：用 Markdown + YAML frontmatter，不用二进制格式
为什么强调人类可读？因为可进化的 Agent 必须是可审计的。如果用户不能直接查看和编辑 Agent 的记忆和技能，进化过程就是黑箱——你不知道 Agent “学”了什么，也无法纠正它的“误解”。
第四步：实现安全围栏
在 Agent 能够修改自身之前，必须确保它不能突破安全边界。
安全围栏的层次：
硬约束（代码强制）：
→ 文件操作路径沙箱
→ Shell 命令超时
→ 名称验证（防止路径遍历）
→ 反思候选永不自动生效
软约束（提示词引导）：
→ 系统提示中的 workspace 约束
→ 工具描述中的安全提示
→ 反思提示词中的保守倾向
原则：硬约束是底线，软约束是引导。 永远不要只依赖 LLM 的“理解”来执行安全策略。
第五步：实现反思机制
现在，终于可以谈“进化”了。是的，没有之前的那些基础保证，直接说这一步，我认为就是空中楼阁，所以，我把它放在这里来讲解。
反思机制的核心不是技术实现，而是提示词设计，与一套工程化机制的保障。一个糟糕的反思提示词会让 Agent 产生大量低质量候选，浪费用户的审批时间，最终让用户放弃审批——而一旦用户习惯性地点击“全部接受”，安全围栏就形同虚设。
好的反思提示词的特征：
1. 保守倾向
"如果没有发现值得提炼的技能，返回空数组。
宁可漏掉一个值得提炼的技能，也不要产生一个低质量的技能。"
2. 结构化输出
不要让 LLM 写散文，要求它返回 JSON。
每个候选必须有 rationale（为什么值得提炼）和 confidence。
3. 上下文感知
把现有的技能和记忆列表传给 LLM，让它知道"已经知道什么"。
避免产生重复的候选。
4. 冲突检测
明确要求 LLM 检查新候选与已有知识的冲突。
冲突比新知识更重要——未解决的冲突会导致不可预测的行为。
第六步：实现记忆系统
记忆系统需要回答三个问题：
- 存什么？ —— 事实、偏好、约定、踩坑经验
- 怎么取？ —— 索引 + 按需加载，不是全量注入
- 怎么变？ —— supersedes 链，不删除旧记忆
一个记忆文件：
---
id: mem_a1b2c3d4
created: 2026-05-01T10:30:00Z
source: reflection
confidence: medium
pinned: false
tags: [rust, testing]
supersedes: []
---
用户偏好在写新功能前先写失败的测试，遵循 TDD 流程。
设计决策：一条记忆 = 一个短陈述。 不要把多个事实塞进一个记忆文件。粒度越细，冲突检测越准确，supersedes 链越清晰。
第七步：实现技能系统
技能是 Agent 对工作流的压缩。一个好的技能应该：
- 有明确的触发条件（什么时候用）
- 有清晰的步骤描述（怎么用）
- 有合理的抽象层级（不太具体，也不太抽象）
一个技能文件：
---
name: create-pr-with-tests
description: 创建 PR 前自动运行测试并附上结果
triggers: [pr, pull request, 提交]
---
1. 运行 `cargo test --workspace`
2. 如果测试通过，执行 `git push -u origin <branch>`
3. 使用 `gh pr create` 创建 PR，将测试结果附在描述中
技能匹配：用最简单的方案。 small Hermes 用 token overlap 做技能匹配——把用户查询和技能的触发词/名称/描述分词，数重叠的 token 数量。不需要嵌入模型，不需要向量数据库，零延迟，在每次用户输入时运行。
这不是因为嵌入模型不好，而是因为在这个规模下（一个人的 Agent 不会有几千个技能），简单方案足够好，而且没有额外依赖。
第八步：实现元反思
这是最容易被忽略的一步。反思机制本身也需要进化——如果反思持续产生低质量候选，说明反思提示词需要调整。
元反思的数据源：reflect-log.jsonl
每条记录：
→ 候选类型（skill / memory / conflict）
→ 候选内容摘要
→ 用户决策（accept / reject / defer）
→ 时间戳
分析维度：
→ 接受率：如果 < 30%，反思提示词太激进
→ 拒绝原因分布：如果大多是"太具体"或"太抽象"，提示词需要调整粒度引导
→ 冲突解决方式分布：如果大多是 scope_split，说明记忆的作用域设计有问题
small Hermes 的完整架构
把以上所有设计决策组合起来，就是 small Hermes 的架构：
┌─────────────────────────────────────────────────────────────┐
│ hermes-cli / tui / gui │
│ （交互层，共享 run_turn） │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌──────────────┐ ┌──────────────────┐ │
│ │ hermes-core │ │ hermes-llm │ │ hermes-mcp │ │
│ │ Session │ │ Anthropic │ │ rmcp stdio/HTTP│ │
│ │ LlmProvider │ │ OpenAI │ │ McpToolHost │ │
│ │ ToolHost │ │ DeepSeek │ │ │ │
│ │ Compaction │ │ │ │ │ │
│ └──────┬───────┘ └──────────────┘ └──────────────────┘ │
│ │ │
│ ┌──────┴───────────────────────────────────────────────┐ │
│ │ hermes-turn │ │
│ │ run_turn() · 微反思 · 取消机制 │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │
│ │ hermes-store │ │hermes-skills │ │ hermes-memory │ │
│ │ JSONL 会话 │ │ 触发匹配 │ │ supersedes 链 │ │
│ │ Frontmatter │ │ 作用域覆盖 │ │ 冲突检测 │ │
│ │ 原子写入 │ │ │ │ │ │
│ └──────────────┘ └──────────────┘ └──────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ hermes-reflect │ │
│ │ 全量反思 · 微反思 · 反思日志 · 元反思 │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ hermes-tools │ │
│ │ read/write/edit/bash/glob/grep/web · 路径沙箱 │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
数据流（严格单向）：
用户输入 → 上下文组装（← 记忆 + 技能，只读）
→ Agent Loop（LLM 推理 + 工具调用）
→ 微反思（异步，产生候选）
→ 会话结束 → 全量反思（产生候选）
→ 用户审批 → 写入记忆/技能存储
常见的反模式
在构建可进化 Agent 的过程中，有一些反复出现的反模式：
反模式一：RAG 即进化
很多人认为“给 Agent 加一个 RAG 管道就是自我进化”。不是。RAG 是检索，进化是修改。RAG 让 Agent 能访问更多外部信息，但不改变 Agent 自身的行为。一个有 RAG 的 Agent 和一个没有 RAG 的 Agent，在处理相同查询时的推理方式是一样的——只是前者能查到更多资料。
真正的进化是：Agent 在第 N 次对话中，因为前 N-1 次对话的反思，产生了不同的推理方式。
反模式二：自动接受一切
为了“用户体验”，有些系统会自动接受反思产生的所有候选。这等价于让 Agent 无监督地修改自己的行为。短期看很酷——“看，我的 Agent 自己学会了新技能！”——长期看是灾难——低质量技能累积，冲突记忆未解决，行为越来越不可预测。
人类审批不是摩擦，是特性。 每次审批都是一次对齐——确认 Agent 的进化方向与你的期望一致。如果你觉得审批太频繁，正确的做法是提高反思的质量（减少低质量候选），而不是跳过审批。
反模式三：过早引入向量数据库
“记忆多了之后线性扫描太慢，需要向量数据库。”——这是过早优化。一个人的 Agent 在正常使用中，一年可能积累几百条记忆和几十个技能。线性扫描这些数据的延迟是微秒级的。向量数据库引入了：嵌入模型的依赖、维度选择的问题、相似度阈值调参、额外的运维成本。
Hermes 的 token overlap 匹配在 50 个技能下的延迟 < 1ms。当技能数量真的增长到需要向量检索时（>1000？），再引入不迟。到那时你对问题的理解会比现在深刻得多。
反模式四：把进化等同于微调
“让 Agent 进化的最好方式是用对话数据微调模型。”——这在理论上有道理，但在实践中有严重问题：
- 数据质量：大部分对话不值得学习。微调不会区分好对话和坏对话。
- 灾难性遗忘：微调后的模型可能丢失通用能力。
- 不可审计：你无法查看微调后的模型“学到了什么”。
- 不可逆：微调后的模型无法轻松回滚。
- 成本：微调需要 GPU 时间和专业知识。
small Hermes 的方式（Markdown 文件 + 人工审批）在所有这些维度上都更优：数据质量由人工保证，通用能力不受影响，完全可审计，可逆（删除文件即可），零成本。
反模式五：忽视组合效应
“我的 Agent 有记忆、有技能、有反思，所以它能进化。”,呵呵，这还真不一定。如果这些组件之间有循环依赖，进化可能产生意想不到的副作用：
- 记忆影响技能触发 → 技能执行产生新记忆 → 新记忆改变了其他技能的触发条件 → ……
- 上下文压缩丢弃了关键信息 → 基于不完整上下文的反思产生错误候选 → 错误候选被接受 → ……
small Hermes 通过严格的数据流单向性来避免这些问题：Agent Loop 运行时，存储是只读的；反思只产生候选，不直接修改存储；审批是唯一的写入路径。
进化成熟度模型
基于以上分析，我们可以定义一个 Agent 进化能力的成熟度模型：
Level 0：无进化
→ Agent 每次对话都是全新的，不保留任何跨会话状态
→ 大多数 ChatGPT wrapper 处于这个级别
Level 1：被动记忆
→ Agent 可以存储和检索用户偏好
→ 但记忆是用户主动告诉它的，不是它自己发现的
→ 相当于一个带配置文件的聊天机器人
Level 2：主动反思
→ Agent 能从对话中主动提炼技能和记忆
→ 有冲突检测机制
→ 人类审批是必须的
→ Hermes 当前处于这个级别
Level 3：元认知
→ Agent 能评估自己反思的质量
→ 能根据审批反馈调整反思策略
→ 反思日志的元分析是自动化的
→ 这是 Hermes 的下一步
Level 4：自主进化（理论级别）
→ Agent 能自主修改自己的行为，不需要人工审批
→ 需要极强的安全保证和可验证性
→ 当前没有任何系统可靠地达到这个级别
→ 我怀疑在 LLM 架构下是否可能安全地实现
重要提醒： Level 4 听起来很酷，但 Level 2 已经能解决 90% 的实际问题。一个能从对话中学习、有冲突检测、有人类审批的 Agent，已经比 99% 的“AI 助手”更强大了。不要为了追求更高的成熟度级别而牺牲安全性和可审计性。
写在最后
Agent 自我进化之所以难，不是因为某个单独的技术问题，恰恰是因为多个维度的困难相互纠缠：
- 方向问题：进化往哪里走？
- 容量问题：有限窗口内如何管理无限知识？
- 一致性问题：如何处理记忆冲突？
- 质量问题：如何保证进化的质量？
- 成本问题：进化的代价如何控制？
- 安全问题：进化与安全如何共存？
- 组合问题：组件间的交互如何管理？
Small Hermes 的答案不是某个银弹，它是一组相互支撑的设计决策：
- 人类在回路中 → 解决方向问题
- 三层上下文架构 → 解决容量问题
- Supersedes 链 + 五种冲突解决策略 → 解决一致性问题
- 保守提示词 + 人工审批 + 元反思 → 解决质量问题
- 双轨反思（全量 + 微） → 解决成本问题
- 不可变核心 + 可变外围 → 解决安全问题
- 最小接口 + 单向数据流 → 解决组合问题
这些决策不是独立的——它们构成一个连贯的系统。去掉任何一个，其他的效果都会打折扣。
最后，一个反直觉的真相：自我进化的关键不是“进化得多快”，恰恰相反，是“退化得多慢”。 一个不会退化的 Agent，即使进化速度很慢，长期来看也会超越一个进化快但经常退化的 Agent。这就是为什么安全围栏、人工审批、冲突检测这些“减速带”不是障碍，而是进化的保障。
少即是多。慢即是快。
本文基于 Small Hermes 项目的实践经验。项目地址：small-rust-hermes
如果你对这类硬核实践感兴趣，欢迎到 云栈社区 的 技术文档 板块查阅更多避坑指南与项目解析。
发表于 3 小时前
|
查看: 4|
回复: 0
