Skip to main content

设计提炼：把 Hermes 的方法迁移到自己的 Agent

1. 先按生命周期画图，再按目录分包​

可迁移的起点不是“建一个 agent/ 目录”，而是列出：启动、turn、模型请求、工具执行、持久化、投递、关闭。每个阶段标出状态和副作用，再决定模块边界。

2. 让外部世界通过能力边界进入​

模型、工具、记忆、平台和执行环境都属于外部世界。它们应该通过 schema、transport、provider、adapter、environment、delivery ledger 进入，而不是在核心循环里直接 import 并散落 if/else。

3. 把“可见内容”和“发送内容”分离​

动态 memory、平台上下文、脱敏内容和 API sidecar 可能只对模型可见；显示 transcript 和长期历史应保持稳定。这个分离能同时改善安全性、重试一致性和会话搜索。

4. 失败要有语义​

错误至少要区分：可重试、可切换 credential、可切换 provider、需用户修复、需人工审批、不可恢复。只有分类之后，Loop 才能做正确的下一步。

5. 并发不应改变协议​

多个工具可以并发执行，但结果顺序、审批、checkpoint、取消和消息配对必须保持可预测。把“执行并发”和“协议顺序”拆成两个维度。

6. 记忆和技能要有 provenance​

任何会改变未来模型行为的自动写入，都需要记录来源、时间、作用域和回滚路径。自我改进不是取消控制，而是把控制从人工每次操作转为可审计的系统边界。

7. 长期运行依靠账本，不靠猜​

Session、turn lease、job claim、delivery ledger、compression cursor 和 relay call log 都是同一个思想的不同名字：把“正在负责什么”写下来，让崩溃后可以恢复或安全重试。

8. 最小可行实现可以很小，但边界不能缺​

若要从零实现一个简化版，可先做：

AIAgent
  ├─ ProviderTransport
  ├─ ToolRegistry + ToolExecutor
  ├─ ContextEngine
  ├─ SessionStore
  └─ Event/Delivery adapter

然后再逐步加入 memory、skills、cron、delegation、remote environment 和 ACP。不要先堆功能，再试图补生命周期；那通常会导致不可恢复的全局状态。

最后的判断标准​

一个 Agent 是否开始接近 Hermes 这样的“运行时”，不看它支持多少工具，而看它能否明确回答：

  • 这次请求现在处于哪个阶段？
  • 当前状态由谁拥有？
  • 这个副作用执行前能否授权/回滚？
  • 进程重启后如何恢复？
  • 上下文太长时保留什么？
  • 自动学习写入了什么、来自谁、如何撤销？