这篇教程解决什么问题
Hermes 能启动，不代表配置适合长期运行。很多问题来自配置边界不清：模型配置写在一个 Profile，环境变量却只存在于另一个 Shell；SOUL.md 里混入密钥；修改了配置但旧会话仍在使用旧快照。本教程给出一套不依赖特定供应商的整理方法。
一、先理解四类配置
- 运行根目录：决定配置、记忆、会话、技能和定时任务的归属。命名 Profile 应视为独立运行单元。
- 模型与供应商配置：决定请求发往哪里、使用哪个模型以及超时策略。
- 环境变量：适合放密钥和部署环境差异，不应写进文章、Skill 或仓库。
- 行为文件：
SOUL.md定义人格与边界，AGENTS.md更适合放项目级协作规则。
配置时先画出“谁读取什么”的关系，再改值，避免同时修改多个层而无法定位问题。
二、建立最小配置基线
先确认命令、Profile 和运行目录：
hermes profile list
printf 'HERMES_HOME=%s\n' "${HERMES_HOME:-<default>}"
hermes tools
然后只配置一个模型和一个最小行为规则，先不要同时接入 MCP、Discord、Telegram 和复杂 Cron。最小基线的验收标准是：能启动、能完成一个短问题、能安全读取一个无敏感信息的本地文件。
三、密钥与配置分离
检查变量是否存在时只输出状态，不输出值：
for name in MODEL_API_KEY OPENAI_API_KEY ANTHROPIC_API_KEY; do
if [ -n "${!name}" ]; then printf '%s=set\n' "$name"; else printf '%s=missing\n' "$name"; fi
done
不要把真实密钥放入 SOUL.md、SKILL.md、Git、截图或聊天记录。若怀疑泄露，应立即在供应商侧撤销并重新生成，而不是只删除本地文本。
四、让行为规则可验证
一条好的规则必须能通过一个小任务验证。例如“长任务先拆分”可以用多步骤文件分析测试；“不泄露凭据”可以用包含 [REDACTED] 的脱敏样例测试。规则应写清触发条件、例外和验收方式，避免使用“尽量”“适当”这类无法检查的词。
五、配置变更流程
- 记录修改前的 Profile 和配置文件路径。
- 一次只改一个变量或一个行为规则。
- 开启新会话，避免旧会话继续使用旧配置快照。
- 先做最小请求，再恢复工具和后台任务。
- 记录错误码、时间和脱敏日志，不记录密钥。
遇到认证问题可参考API Key 排查指南，遇到技能索引问题可参考Skill 未加载排查。
配置验收清单
- 当前 Profile 与预期一致；
- 密钥来自安全环境变量或安全配置；
SOUL.md和 Skill 不含真实凭据；- 新会话能完成最小请求；
- 工具、MCP、Cron 均按需逐项启用；
- 配置变更有可回滚记录。
这套流程的重点不是追求配置项最多，而是让每个配置项都有明确归属、触发条件和验证方式。