如果你的角色是“科研工作者 + 算法工程师”，而研究方向集中在LLM、Agent，那么 Hermes 最适合承担的不是泛娱乐问答，而是“论文阅读—实验设计—代码分析—结果整理—技能沉淀”的长期研究协作者角色。
这也是为什么我建议你把配置重点放在 SOUL 定义、多模型分工、三层记忆、Docker 执行和研究技能模板上，因为好的AI助手都应该：让 Agent 从“会回答”升级成“会长期协作”。
整体目标
最终应该得到的是一套“研究型 Hermes 工作站”，它具备以下特征：
明确知道你的身份、领域、输出偏好和研究边界。
能区分高质量推理任务和低风险整理任务，并交给不同模型处理。
能长期记住你常用的方法论、写作风格、实验框架和项目习惯。
默认在隔离环境中执行代码，降低误操作风险。
可以把论文分析、实验总结、复现记录沉淀为反复复用的技能模板。
定义 SOUL
“灵魂定义”为 Hermes 安装后建议优先处理的核心步骤之一，因为你的 Agent 一旦没有明确角色，它后面所有搜索、记忆、路由和技能都容易跑偏。
对研究用户来说，SOUL 不是一句“你是一个有帮助的助手”，而应该是一份明确规定身份、目标、工作原则、输出格式和禁区的文件。
很多人一上来就先接浏览器、加模型、装各种技能，最后发现 Agent 并不真正“懂自己”；本质原因不是工具不够，而是默认人格太泛化。
所以，第一步不是功能增强，而是先给 Hermes 一个稳定且专业的研究人格。
下面这份 SOUL 模板，适合“科研工作者 + 算法工程师 + RL/LLM/Agent 方向”的设定：
# SOUL.md
你是我的研究型 AI 协作助手，服务对象是一名科研工作者与算法工程师。
## 用户画像
– 用户主要方向：强化学习（RL）、大模型（LLM）、Agent
– 用户常见任务：论文阅读、算法比较、实验设计、代码分析、复现、训练诊断、研究总结
– 用户偏好语言：中文为主，关键术语保留英文
– 用户偏好风格：先结论，后分析；结构化；不空泛
## 你的核心角色
– 不是泛用聊天机器人
– 是研究协作 Agent、实验助手、论文分析助手、代码阅读助手、技术写作助手
## 工作目标
– 提高研究效率
– 帮助形成更严谨的实验设计
– 输出可验证、可复现、可落地的建议
– 帮助沉淀长期可复用的方法和模板
## 回答原则
– 遇到研究问题，优先明确任务定义、约束条件、评价指标
– 遇到论文，默认从问题、方法、实验、局限四个维度分析
– 遇到代码，默认从目录结构、核心入口、关键模块、潜在风险四个维度分析
– 遇到实验方案，默认补充 baseline、metrics、ablation、failure cases
– 不把猜测说成事实
– 不夸大“最新模型”的价值
– 不默认一个方案适用于所有算力与数据条件
## 输出要求
– 先给结论
– 再给理由
– 优先表格、清单、实验计划
– 涉及技术概念时尽量给中英对照
– 涉及不确定内容时标出假设与验证路径
多模型路由，不要一个模型全包
“多模型路由”同样是高优先级配置之一，这对研究型用户尤其重要，因为任务复杂度差异很大，不同任务的最优模型通常不是同一个。
简单说，论文推理、算法比较、实验设计、复杂代码改造，和网页摘要、格式清洗、日志归档、文件重命名，根本不是一类任务，硬让一个模型全做，成本高、效果也未必稳定。
可以把模型路由理解成“前台总调度 + 后台工种分工”。
对于科研用户，我建议至少拆成下面三类：
主推理模型：负责复杂研究问题、论文解读、代码理解、方案设计。
检索/整理模型：负责网页摘要、资料整理、长文本分段归纳、表格抽取、格式修正。
执行/脚手架模型：负责低风险命令、模板填充、样板代码、批量重命名、简单转换。
对应的思路可以写成这样：
# ROUTER.md
## 路由原则
### 使用主模型的任务
– 论文阅读与综述
– 强化学习方法比较
– LLM/Agent 系统设计
– 复杂代码逻辑分析
– 实验方案设计
– 研究写作与论证
### 使用副模型的任务
– 网页内容摘要
– 日志与笔记整理
– 参考资料分类
– Markdown / YAML / JSON 格式修正
– 批量归档与低风险改写
### 升级条件
– 若副模型连续两次输出结构混乱或遗漏关键约束，则切回主模型
– 若任务涉及研究结论、方法论比较、实验设计，必须优先主模型
这样做的最大价值在于：你能把高成本模型真正用在“需要思考的地方”，而不是让它浪费在机械整理上。
对一个长期做科研的人来说，这会直接影响稳定性、成本和使用体验。
或者直接在Hermes里面输入：
压缩会话的辅助模型帮我配置成 deepseek-v4-flash
支持配置的 8 个辅助任务
辅助模型 | 用途说明 |
vision | 截图 / 验证码 / 图片分析 |
web_extract | 网页内容抓取与提炼 |
compression | 上下文压缩摘要（节省 Token） |
session_search | 历史会话搜索与摘要 |
approval | 高危命令审批决策 |
skills_hub | 技能市场搜索与安装 |
mcp | MCP 服务调用辅助 |
flush_memories | 记忆系统清理与重组 |
三层记忆
“三层记忆系统”是 Hermes Agent 的关键配置之一，这非常重要，因为研究型用户的上下文跨度远大于普通聊天用户。
如果把所有内容都塞进一种记忆里，用不了多久就会出现两个问题：该长期保留的没留下，不该长期保留的垃圾却越来越多。
我建议把记忆分成三层：
长期记忆：稳定身份与偏好
这一层存的是长期稳定不太变的内容，比如你的研究方向、术语偏好、写作风格、代码习惯、常用框架、常见实验模板。
这些内容应该在长期使用中持续影响 Hermes 的行为，因此可以放 memory/long_term/ 或一个专门的 USER_PROFILE.md。
示例：
# USER_PROFILE.md
## 基本身份
– 科研工作者
– 算法工程师
– 主方向：RL / LLM / Agent
## 稳定偏好
– 中文输出，术语保留英文
– 先结论后展开
– 喜欢表格、清单、流程图式结构
– 重视可复现性、边界条件、失败案例
## 常用技术栈
– Python
– PyTorch
– Transformers
– RLlib / CleanRL
– 常见推理服务与模型接口
## 默认工作方式
– 论文：问题 / 方法 / 实验 / 局限
– 代码：目录 / 入口 / 模块 / 风险
– 实验：baseline / metrics / ablation / error analysis
项目记忆：某个课题或仓库的上下文
这一层适合存具体项目的长期上下文，比如某个 benchmark、某篇要复现的工作、一个正在维护的 Agent 系统、一个论文综述任务。
它不一定长期有效，但在一个阶段内很重要，因此建议按项目建立独立目录，比如 memory/projects/project_x/。
例如：
# memory/projects/agent-benchmark/PROJECT.md
## 项目目标
– 构建面向工具使用型 Agent 的评测框架
## 当前约束
– 优先支持本地模型与 OpenAI-compatible API
– 评测对象包含 planning、tool use、memory use
## 当前基线
– ReAct
– Plan-and-Execute
– Toolformer-like workflow
## 当前评价指标
– Success rate
– Tool call efficiency
– Latency
– Recovery after failure
## 暂存结论
– 现有 baseline 在多步工具恢复上表现不稳定
临时记忆：当前会话的短期工作区
这一层只适合存临时上下文，比如今天的 bug、当前 shell 命令输出、某次网页检索结果、一次性的任务拆解。它的重点是“帮助当前任务顺利完成”，而不是永久保存。
你可以把它理解成草稿纸。凡是“一周后大概率没必要看”的东西，就别让它进长期记忆。
记忆系统最常见的坑：
第一个坑，是把每次聊天内容都当宝贝塞进长期记忆；这样做的后果是越用越脏，Agent 后面会经常引用一些早就过期的上下文。
第二个坑，是完全不存项目记忆，导致每次继续一个研究任务时都要从头解释背景，长期效率反而很低。
所以最稳妥的方式不是“记得越多越好”，而是记对东西、放对层级。
编辑内置记忆： ~/.hermes/config.yaml ：
memory:
memory_enabled: true # MEMORY.md — 事实、记录
user_profile_enabled: true # USER.md — 用户画像与偏好
memory_char_limit: 4000 # 默认 2200，重度使用建议调到 4000
user_char_limit: 1375 # 用户画像字符上限
nudge_interval: 5 # 每 5 轮提醒存记忆（默认 10，调小更积极）
flush_min_turns: 6 # 至少 6 轮才触发退出时的记忆刷新
所有历史对话都会自动持久化到本地 SQLite，作为记忆系统的兜底机制。
存储位置：
~/.hermes/state.db检索方式：基于 FTS5 的关键词全文搜索，并结合 LLM 进行二次摘要
兜底保障：当 LLM 调用失败时，系统会返回原始文本的前 500 个字符，确保功能不会因故障而完全失效
默认开启：无需额外配置，Session Search 默认启用
智能检索：Agent 会根据当前问题自动判断是否需要检索历史记录
Web 搜索与浏览器
Hermes 不只是回答你已有上下文里的问题，而是应该具备到外部世界检索资料和阅读页面的能力。
但重点不是“能打开网页”，而是“能稳定地服务论文、GitHub、文档和技术博客研究”。
直接告诉 Hermes：
帮我配置 CAMOFOX 及 CAMOFOX_URL
Hermes 会自动完成相应docker的安装，并在需要高危操作时申请权限。
Hermes 原生支持 4 个搜索提供商：Exa、Tavily、Parallel、Firecrawl。直接告诉 Hermes：
帮我配置 exa 搜索
执行环境默认 Docker，本地执行只在必要时开
Hermes 支持多种执行后端，包括 local、docker、ssh、singularity 等。
对于算法工程师和科研用户来说，会频繁让 Agent 读代码、写脚本、处理文件，默认放在隔离环境里，能减少很多误操作风险。
可以这样理解执行后端：
docker：默认首选，适合日常代码分析、脚本试跑、文件转换、低风险自动化。local：仅在你非常确认目录、权限和命令范围时使用，适合少量本地深度集成。ssh：适合连接远程实验机、GPU 服务器。singularity：适合 HPC 集群或更规范的科研计算环境。
建议把默认策略写得保守一些：
# SAFETY.md
## 默认执行策略
– 默认在 Docker 中执行
– 需要访问远程实验机时使用 SSH
– 只有经过明确确认时才允许本地执行
## 高风险命令需确认
– rm / mv 覆盖类操作
– git push / force push
– docker run 新容器
– 长时间训练任务
– 网络下载并执行脚本
– 修改系统级配置
多 Agent
直接告诉agent：请使用三个 subagent 来相互讨论 Hermes 与龙虾各自的优缺点。
技能沉淀
论文拆解 skill
输入：
– 论文标题 / 链接 / PDF / 摘要
输出结构：
1. 研究问题是什么
2. 核心方法是什么
3. 和现有方法相比的差异
4. 实验怎么做
5. 哪些结论可信，哪些要谨慎
6. 对 RL / LLM / Agent 有什么启发
实验设计 skill
输入：
– 研究目标
– 数据与环境
– 算力约束
输出结构：
1. baseline
2. 指标 metrics
3. ablation 设计
4. 训练设置建议
5. 潜在 failure cases
6. 风险与优先级
代码阅读 skill
输入：
– 仓库路径 / 压缩包 / GitHub 链接
输出结构：
1. 仓库做什么
2. 入口在哪里
3. 核心模块如何流转
4. 配置项在哪
5. 改哪里最安全
6. 哪些地方容易踩坑
benchmark 对比 skill
输入：
– 多个方法名 / 多个模型 / 多篇工作
输出结构：
1. 比较维度
2. 适用场景
3. 优势与代价
4. 关键实验差异
5. 哪类结论不能直接横比
Agent 评测 skill
输入：
– Agent 系统设计
– 任务定义
– 工具列表
输出结构：
1. 任务拆分
2. 工具调用链
3. 规划能力测试
4. 记忆能力测试
5. 错误恢复能力测试
6. 评测指标与日志格式