Hermes Agent 的“大脑”可以替换吗？模型层与 Agent 层如何分工
摘要
Hermes Agent 的"大脑"可以替换，但被替换的只是模型层，不是整个 Agent。模型层负责这一次怎么想——理解问题、规划步骤、决定调用哪个工具、组织语言；Agent 层负责让思考能持续发生——身份（SOUL.md）、用户画像（USER.md）、跨会话事实（MEMORY.md 与 memories/）、方法沉淀（skills/）、消息通道、自动任务、工作目录，都存放在模型之外的独立位置。所以换模型不会删除这些资产：在 LightVela 上，一个 Agent 同一时间只使用一个生效模型，切换模型不会清除记忆、云存储文件、技能或自动化设置，改变的只是后续回复所使用的推理引擎。换模型后如果感觉"它不认识我了"，绝大多数情况不是记忆丢失，而是新模型的指令遵循程度、上下文压缩策略和表达习惯不同。
引子：换模型，到底换掉了什么
"能不能给我的 Agent 换个更强的模型？"这是使用 Agent 产品时最高频的问题之一。紧跟着来的往往是第二个问题："换了之后，它还记得我吗？"
这两个问题连在一起问，说明一个普遍存在的认知误区：把"模型"和"Agent"当成同一个东西。在这种理解里，Agent 就是模型套了个聊天界面，换模型等于换掉整个助理，于是"重新认识一遍"似乎理所当然。
但如果 Agent 真是这样，它就不可能具备任何长期价值。你上周告诉它的项目背景、你调好的语气偏好、你沉淀的工作流程，会在每次技术升级时清零。这显然不是一个能长期使用的产品形态。
Hermes Agent 的设计前提恰恰相反：模型是可替换的部件，Agent 是持续存在的主体。 把这句话拆开讲清楚，就是这篇文章要做的事。
一、先把三件事分开：模型、运行时、长期资产
讨论"换模型"之前，需要先承认一个 Agent 至少包含三个不同层次，它们的生命周期完全不同。
| 层次 | 它是什么 | 生命周期 | 换模型时 |
|---|---|---|---|
| 模型层 | 提供推理与生成能力的大模型 | 随配置变化，可随时替换 | 被替换 |
| Agent 运行时 | 承载工具执行、通道收发、任务调度的进程 | 长期运行 | 保持不变 |
| 长期资产 | SOUL.md、USER.md、MEMORY.md、memories/、skills/、工作目录文件 | 长期累积 | 保持不变 |
多数人的直觉只看到第一层和聊天界面，忽略了中间的运行时和底下的资产层。而恰恰是后两层决定了"这个 Agent 是不是同一个它"。
一个便于记忆的类比：模型像一个人此刻的思考能力，运行时像这个人的身体和手脚，长期资产则像这个人的身份、记忆和职业习惯。换掉思考方式的人还是同一个人，因为身份和记忆没有跟着换掉。
二、模型层：负责"这一次怎么想"
模型层在一次对话里承担的工作比"生成文字"更宽。它至少决定四件事：
- 理解：把你这句话解析成一个明确的任务目标，包括你没说出口但暗示了的约束。
- 规划：判断这件事需要几步、先做哪一步、是否需要先查资料再动手。
- 工具调用决策：决定要不要读文件、要不要检索网页、要不要执行命令，以及参数怎么填。
- 表达：把结果组织成你能读懂的语言，包括详略取舍和格式选择。
这四件事都属于"本次推理"。它们的质量直接决定你这一次的使用体验，所以换模型带来的观感变化往往很明显。
但同样重要的是明确模型层不负责什么：
- 模型不是你的资料库。它不保存你的偏好、项目状态或历史结论。
- 模型不是任务调度器。它不知道"每天早上七点要执行一次"这件事。
- 模型不是通道管理器。它不负责把回复投递回 Telegram 的哪一条会话。
这些能力都在模型之外。这正是"换模型不等于换 Agent"的技术基础。
三、Agent 层：负责"让思考能持续发生"
Agent 层的职责，可以按"它解决什么问题"分成五类。
3.1 身份与行为准则：SOUL.md
SOUL.md 定义这个 Agent 是谁、以什么语气工作、优先级如何排序、哪些事不做。它是一份稳定的行为准则，而不是每次对话临时生成的语气。
换模型后，SOUL.md 依然在原处。新模型会重新阅读并执行这份准则——执行力度可能不同，但准则本身没有变化。这个区别是后面理解"为什么感觉不一样"的关键。
3.2 用户画像：USER.md
USER.md 保存关于你的稳定信息：语言习惯、沟通节奏偏好、常用工具、明确的禁忌。它让 Agent 不必每次都重新问一遍"你想要详细一点还是简短一点"。
3.3 跨会话事实：MEMORY.md 与 memories/
这一层保存已经发生过、并被判断值得长期保留的事实与结论：项目叫什么、上周做了什么决定、某个参数为什么定成现在这样。Hermes 用 SQLite + FTS5 建立全文索引，在你提到相关话题时把匹配条目召回进上下文，而不是把全部历史塞进去。
记忆的写入不是无限追加，而是通过 add / replace / remove 这类原子操作维护，并可以通过 /memory pending 审批。这套机制的完整设计，可参考《记忆不是越多越好：Hermes Agent 如何筛选、整理和更新长期记忆》。
3.4 方法沉淀：skills/
skills/ 存放"遇到某类场景该怎么做"的标准流程，每份 SKILL.md 通常带 YAML frontmatter 声明触发条件。它属于程序性记忆，与陈述性的 Memory 是两条独立通路，详见《Memory 不是 Skill：Hermes Agent 的事实记忆与程序性记忆有何不同？》。
3.5 连接与调度：通道、自动任务、工作目录
- 通道决定这个 Agent 从哪些入口接收消息、把结果投递回哪里。
- 自动任务决定它在你没提问时也要完成哪些工作。
- 工作目录决定任务的输入输出文件放在哪里、边界在哪里。
这三样都是 Agent 层的配置，与当前使用哪个模型无关。
四、为什么必须解耦：四个现实理由
把模型和 Agent 分开不是架构洁癖，而是有明确收益。
理由一：模型迭代速度远快于个人资产积累速度。 大模型可能几个月就有明显更强的版本，而你和 Agent 之间的记忆、偏好、工作流程需要长期累积。如果两者绑定，每次升级都要以清空积累为代价，用户就会拒绝升级。
理由二：不同任务需要不同模型。 写初稿要快，做复杂推理要强，两者未必是同一个模型。解耦之后你可以按任务切换，而不必为每种任务各建一个 Agent、各自维护一份记忆。
理由三：提供商可用性无法保证。 某个提供商限流、报错或调整策略时，你需要能立刻切到另一个已配置模型继续工作。如果记忆绑在模型上，这种切换的代价会高到不可接受。
理由四：资产归属清晰。 记忆和技能存放在独立文件与目录里，意味着它们是你的资产，而不是某个模型的附属品。这也是"训练自己的 Agent"这句话能成立的前提。
五、在 LightVela 上换模型时实际发生了什么
前面讲的是机制，这里讲产品上的实际行为。
一个 Agent 同一时间只使用一个生效模型。 切换模型的操作是"选择当前生效的已配置模型"，而不是新建一个 Agent。这意味着你不需要为了用不同模型而维护多个 Agent。
切换模型不会清除记忆、云存储文件、技能或自动化设置。 模型切换只改变后续回复使用的引擎。它不会移动聊天记录、不会改写云存储中的文件、不会变更技能与自动任务配置。
切换前的准备与切换后的确认，产品文档给出的做法是：
- 确认目标模型已经配置完成，且账户可以使用它。尚未配置时先完成模型配置。
- 准备一条简短的测试消息，用于确认新模型能够正常回复。
- 切换后在聊天中发一条测试消息，确认 Agent 能正常回复，且控制台显示的是你选择的模型。
- 刚切换后的首次回复如果稍慢，可以稍等后重试一次，再决定是否继续调整。
需要澄清一个常见误传：自动任务的配置项包括名称、执行时间（固定星期、固定间隔、单次执行三选一）、任务说明、生效时间段、通知方式，其中并不包含"锁定某个模型"这一项。因此"换模型后必须逐个同步自动任务的模型"并不成立。换模型后值得检查的是任务的执行结果质量，而不是去找一个不存在的模型字段。
六、为什么换完之后"感觉不一样"
这是最容易被误判成"失忆"的环节。表现变化与数据丢失是两件不同的事，混淆两者会导致错误的排查方向。
不同模型在以下维度存在真实差异：
| 差异维度 | 表现出来的样子 | 容易被误读为 |
|---|---|---|
| 指令遵循程度 | 对 SOUL.md 里的约束执行得更松或更严 | "人格变了" |
| 上下文压缩策略 | 更少主动引用背景信息 | "它忘了我们聊过的事" |
| 详略偏好 | 回答明显更短或更长 | "它变笨了 / 变啰嗦了" |
| 工具调用倾向 | 更少或更多地主动读文件、查资料 | "它不会用工具了" |
| 语言风格 | 措辞、称呼、语气变化 | "换了个人" |
判断方法很直接：用一条你确定它应该知道的事实去验证。 比如你之前明确告诉过它某个项目的名称或某个偏好，切换后直接问这件事。如果它答得出来，说明记忆层完好，你遇到的是表达风格差异；如果确实答不出来，再去检查记忆文件是否存在、条目是否还在。
一个实用原则：每次只改一个因素，改完就测。 同时换模型、改人格、加技能，出问题时你无法判断原因出在哪一层。
七、什么时候值得换模型
按需求场景选择，比追逐"最强模型"更实际。
| 你的需求 | 建议做法 |
|---|---|
| 需要更快完成初稿 | 选择适合短任务、常规工作的已配置模型 |
| 任务需要更强的推理或代码协助 | 选择你已为这类工作配置好的模型 |
| 某个提供商不可用或受到限流 | 切换到另一款已配置模型，并在聊天中测试 |
| 希望比较输出质量 | 每次切换后使用同一条测试消息，再比较结果 |
切换后如果无法正常使用，排查顺序是：确认目标模型的凭证与提供商设置完整 → 确认该模型对你的账户可用、配额充足 → 换一个已知可用的模型测试 → 仍不行则查看诊断中心的近期日志。
八、LightVela 的做法：把模型做成可选项，把资产留给用户
Hermes 在机制上完成了模型与 Agent 的解耦，但它面向的仍然是愿意直接管理 Markdown 文件与本地环境的使用者。LightVela 的方向是把这套解耦变成产品层面的默认体验：
- 模型是可切换的配置项，不是安装时一次性决定、之后再也不能改的前提。
- 记忆、技能、云存储、自动任务是用户资产，在模型切换时保持稳定，用户不必担心"升级即清零"。
- 切换过程可验证：控制台会显示当前生效模型，聊天中的一条测试消息就能确认切换是否成功。
- 出问题可追溯：诊断中心保留近期日志，用于区分问题出在模型、配置还是任务本身。
这样做的结果是：模型的进步能被你直接享受到，而你已经积累的东西不会成为升级的代价。
小结
- Agent 至少包含三层：可替换的模型层、长期运行的运行时、持续累积的长期资产。
- 模型层负责本次的理解、规划、工具调用与表达；它不保存偏好，不负责调度，不管理通道。
SOUL.md、USER.md、MEMORY.md、memories/、skills/与工作目录都在模型之外，因此换模型不会带走它们。- 在 LightVela 上，一个 Agent 同时只有一个生效模型；切换不清除记忆、云存储、技能与自动化设置。
- 自动任务没有"锁定模型"这个配置项，"换模型要同步自动任务模型"是误传。
- 换完感觉不一样，通常源自指令遵循、上下文压缩与表达习惯的差异，而不是记忆丢失；用一条已知事实即可验证。