Hermes配置计划

1. 目标

在一台全新 2c2g 服务器上，部署一个用于日常对话、工作协作和日志复盘的 Hermes 个人系统。系统以 单一通讯软件 Slack 作为入口，以 四个独立角色 提供不同职责，并通过 用户隔离、目录隔离、Docker sandbox、系统服务隔离 控制风险。

2. 总体结论

已敲定的核心原则：

• 服务器系统：Ubuntu 24.04 LTS
• 系统用户：单独 hermes
• Hermes 本体：直接安装在 hermes 用户下运行，不把 Hermes 本体也装进 Docker
• 执行隔离：所有工具执行、任务执行、命令执行走 Docker sandbox
• 通讯入口：Slack
• Slack 形态：一个私人 workspace，四个 bot，四个 DM 私聊入口，不以群聊为主
• Profiles：companion、mentor、work-simple、work-deep
• 记忆：四角色完全隔离
• 通用配置：使用一份手工维护的 shared_profile.md 作为四角色共享只读低敏配置
• 服务形式：四个独立 systemd 服务
• 定时能力：仅 mentor 允许 cron / timer / 主动提醒

3. 角色划分

3.1 companion

用途：日常聊天、角色扮演、情绪陪伴。

原则：

• 不执行命令
• 不碰真实项目
• 只读共享配置和自己的记忆
• 以对话体验为优先
• 允许多模态输入理解图片
• 可联网查询搜索

建议模型：Gemini 3.1 Pro。

3.2 mentor

用途：日志导师、复盘、提醒、追问、纠偏。

原则：

• 可定时主动提醒
• 可生成日复盘、周复盘、月复盘（以md格式存储）
• 不执行服务器命令
• 不碰真实项目文件
• 只读共享配置 + 自己的日志库/记忆
• 风格偏严格教练型，但禁止羞辱。需实事求是

建议模型：Claude Opus 4.8。

3.3 work-simple

用途：简单任务、整理文本、轻量工具调用、低成本快速处理。

原则：

• 不改真实项目
• 可以读 Hermes 用户可读内容
• 只能写自己的 workspace
• 不自动升级到复杂助手
• 不直接接触高风险操作

建议模型：DeepSeek V4 Flash。

3.4 work-deep

用途：复杂工作、代码、多步骤任务、重构、调研、深度分析。

原则：

• 可碰 Hermes 用户可碰的所有内容
• 可访问互联网
• 可 git clone、拉依赖、查文档、运行构建测试
• 所有执行仍在 Docker sandbox 中
• 高风险操作需要确认
• 默认作为复杂工作的执行主力

建议模型：

• 默认：GPT-5.5
• 非多模态文本/代码替代：GLM-5.2
• 审稿/反驳/第二意见：Claude Opus 4.8

4. 模型映射

4.1 默认映射

• companion -> Gemini 3.1 Pro
• mentor -> Claude Opus 4.8
• work-simple -> DeepSeek V4 Flash
• work-deep -> GPT-5.5

4.2 work-deep 的切换策略

work-deep 不是单一模型，而是一个模型池。

• GPT-5.5：复杂工作的默认执行主力，尤其适合多模态、工具链、跨文件任务
• GLM-5.2：在不涉及多模态时，可作为 GPT-5.5 的高性价比替代
• Claude Opus 4.8：用于反驳、审稿、架构质询、第二意见

建议规则：

• 默认先用 GPT-5.5
• 非多模态任务时可切 GLM-5.2
• 只在用户明确提到时切 Opus 4.8
• 不自动在多个模型之间频繁跳转

5. 共享记忆与隔离

5.1 私有记忆

四个角色的长期记忆默认完全隔离。

每个角色只维护自己的：

• memory
• sessions
• logs
• workspace
• profile 配置

5.2 共享配置

建立一份手工维护的 shared_profile.md，作为四角色共用的低敏配置源。

建议放入：

• 你的称呼
• 语言偏好
• 时区
• 通用安全要求
• 通用输出偏好
• 长期目标的低敏摘要
• “允许反驳、不要阿谀奉承、先问清楚再执行”等原则

不应放入：

• 角色私密记忆
• 日志原文
• 项目密钥
• SSH 私钥
• token
• 任何敏感身份信息

6. 通讯入口

6.1 选择 Slack

选择 Slack 作为唯一通讯入口。

原因：

• 支持 Windows 和 Android 双端，且支持网页版
• Slack Bot / DM 机制适合“四个像独立对象一样分别沟通”
• Hermes 对 Slack 支持成熟
• Socket Mode 不要求服务器暴露公网 webhook
• 比较适合单一软件承载四个角色

6.2 Slack 组织方式

建议：

• 一个私人 Slack workspace
• 四个独立 Slack App / Bot
• 四个 bot 分别对应四个 Hermes profile
• 以 DM 私聊为主，不以群聊为主
• 频道只保留系统通知或归档用途

6.3 角色与入口的关系

• companion -> 独立 bot DM
• mentor -> 独立 bot DM
• work-simple -> 独立 bot DM
• work-deep -> 独立 bot DM

7. 目录结构

建议每个 profile 一个完整目录树，避免串台。

/home/hermes/hermes/
  shared/
    shared_profile.md
  profiles/
    companion/
      config.yaml
      .env
      SOUL.md
      memory/
      sessions/
      skills/
      workspace/
      logs/
    mentor/
      config.yaml
      .env
      SOUL.md
      memory/
      sessions/
      skills/
      workspace/
      logs/
      journals/
    work-simple/
      config.yaml
      .env
      SOUL.md
      memory/
      sessions/
      skills/
      workspace/
      logs/
    work-deep/
      config.yaml
      .env
      SOUL.md
      memory/
      sessions/
      skills/
      workspace/
      logs/
      projects/

7.1 目录原则

• shared/shared_profile.md：四角色只读共享
• 每个 profile 的 .env：只允许该 profile 读取
• 每个 profile 的 workspace：彼此隔离
• mentor/journals：只给导师用
• work-deep/projects：用于真实项目入口或白名单项目入口

8. 权限边界

8.1 companion

• 只读 shared 配置
• 只读自己的记忆
• 不执行命令
• 不接触真实项目

8.2 mentor

• 只读 shared 配置
• 可读写自己的日志库和复盘资料
• 可定时运行
• 不碰项目文件
• 不执行命令

8.3 work-simple

• 只读 shared 配置
• 可读 Hermes 用户可读内容
• 不能改真实项目
• 只能写自己的 workspace
• 不自动升级到 work-deep

8.4 work-deep

• 只读 shared 配置
• 可碰 Hermes 用户可碰的所有内容
• 允许联网
• 允许拉依赖、查文档、运行构建和测试
• 所有执行仍在 Docker sandbox 中
• 高风险操作仍需确认

9. 服务与运行形态

9.1 Hermes 本体

建议直接安装在 hermes 用户下运行，不把 Hermes 本体容器化。

原因：

• 更容易排错
• 更容易看日志
• 更容易升级
• 更容易维护 profile 和 gateway

9.2 执行隔离

命令执行、工具执行、任务执行统一放到 Docker sandbox。

这是系统安全边界的重点，不是 Hermes 本体本身。

9.3 systemd

采用四个独立 systemd 服务：

• hermes-companion.service
• hermes-mentor.service
• hermes-work-simple.service
• hermes-work-deep.service

原因：

• 某个角色挂了不会影响其他角色
• 重启、升级、停用更清楚
• 日志更容易定位
• 资源控制更容易分开做

10. 主动性规则

10.1 只有 mentor 允许主动

• 每天提醒写日志
• 每天做反馈
• 每周生成周复盘
• 每月生成月复盘
• 可以追问偷懒、逃避或缺失信息

10.2 其他角色不主动打扰

• companion 不主动催促
• work-simple 不主动开工
• work-deep 不主动找活

11. 安全与风险控制

11.1 默认原则

• 默认不启用 YOLO
• 默认不自动放行高风险操作
• 默认不把 token、密码、私钥写入普通记忆
• 默认不把真实项目暴露给低权限角色

11.2 需要确认的行为

• 访问私有仓库
• 上传文件
• 发送密钥
• 部署生产服务
• 改生产配置
• 影响真实项目状态的高风险命令

11.3 允许联网但分级

均可联网，但网络权限应在工具层和审批层继续约束。

12. 不纳入此配置的内容

以下暂时不做：

• 备份策略
• 角色命名
• 头像设计
• 更细的人格风格讨论
• 复杂跨角色共享记忆设计
• 多通讯软件方案

13. 当前结论

Hermes v1 的最终方案是：

• 单一系统用户：hermes
• 单一通讯软件：Slack
• 四个独立角色：companion、mentor、work-simple、work-deep
• 四个独立 systemd 服务
• 四套完全隔离的 profile 目录
• 一份四角色共享的 shared_profile.md
• mentor 独享主动提醒与复盘能力
• work-deep 是唯一允许联网和复杂执行的角色
• work-simple 只做轻量任务，不改真实项目
• companion 只做聊天和陪伴
• work-deep 默认 GPT-5.5，必要时可切 GLM-5.2 或 Opus 4.8

14. 备注

这份文档的目的是先把 Hermes 的 v1 结构定死，避免后续在部署时反复重谈边界。人格细节、命名、头像、交互风格都留到下一轮单独讨论。