Mac mini AI 中枢 + 双 VPS Hermes
解决方案调研报告

01一、执行摘要（TL;DR）

1.1 一句话结论

1.2 核心发现

1.3 四个待决策问题的推荐答案（详见第三部分）

1.4 与原文档的关键差异

02二、现状诊断：设计文档的假设 vs Hermes 实际能力

2.1 逐条核对

2.2 结论

原文档把「任务管理系统」当作需要从零构建的组件，但实际上 Hermes 的 Kanban 已经实现了它——这是本调研最重要的发现。设计重心应从「搭建任务基础设施」转移到「三件事」：

这也解释了原文档核心痛点之一：「第二个 Hermes 闲置」——因为第一个 Hermes 把所有事都干了，没有用 profile 分工。解决方案不是「造一个调度系统」，而是「把 Hermes 的多实例能力用起来」。

03三、待决策问题 ①：Steward 与 Curator 是否拆分？

3.1 问题本质

Steward（任务管家：接收需求→结构化→分发→验收）和 Curator（知识图谱维护者：抽取事实→维护图谱→提供上下文）是两个职责不同的角色。问题是：它们一开始就用两个独立 Hermes 实例跑，还是同一个实例兼任？

3.2 方案对比

3.3 推荐：初期兼任，设计上预留拆分

04四、待决策问题 ②：知识图谱技术栈

4.1 场景定义

• 规模：几百到几千个实体（项目/任务/决策/事实/人员/文档），远小于 1 万
• 运行环境：Mac mini（8-16GB RAM）
• 维护者：个人用户，非专业 DBA
• 硬约束：低运维、易备份（NAS/云）、未来可加向量 RAG

4.2 七个候选方案对比

4.3 推荐：SQLite + FTS5 + sqlite-vec 为主存储，Obsidian/git 可选为人机界面层

数据模型建议（邻接表 + 业务表）：

knowledge.db
├── entities      (id, type[project/task/decision/fact/person/document], name, properties_json, visibility, created_at, updated_at)
├── relations     (id, source_id, target_id, type[depends_on/assigned_to/mentions/decided_in], properties_json)
├── tasks         (业务实体：项目任务，与 kanban 任务可互引)
├── decisions     (决策：what, why, when, by_whom, alternatives)
├── notes         (自由笔记/事实)
├── fts5 虚拟表    (全文索引 entities+notes)
└── vec0 虚拟表    (预留，sqlite-vec，存 embedding)

权限分层实现：entities.visibility 字段（private/family/team）+ 查询时过滤。Mac mini 单机场景不需要数据库级 ACL，应用层过滤即可（家庭共享 = 同一设备上的另一个 profile 查询时传 visibility 参数）。

05五、待决策问题 ③：VPS Worker 如何安全访问知识图谱

5.1 三个候选方案

5.2 推荐：方案 A（上下文打包）为主，方案 B（只读 API）为进阶

06六、待决策问题 ④：试点任务类型

6.1 评估矩阵

6.2 推荐：探索调研类 + 一个真实场景试跑

07七、跨机器架构：两条可行路线对比

Mac mini（唯一真相源）
├─ Kanban 板 + Dispatcher（gateway 内嵌）
├─ Steward profile（orchestrator：拆任务、路由、验收）
├─ Curator profile（图谱维护）
├─ worker-local profile（terminal.backend: ssh → VPS-A）
└─ worker-remote profile（terminal.backend: ssh → VPS-B）
        │ SSH (密钥登录)
        ▼
VPS-A / VPS-B（不装 Hermes 或只装轻量执行环境）
├─ 工具链：Playwright、PlantUML、浏览器等
└─ 执行：命令由 Mac 的 worker profile 通过 SSH 发起

Mac mini                              VPS-A / VPS-B
├─ Steward profile                    ├─ Hermes + API Server（独立 key）
├─ 用 OpenAI SDK 调 /v1/runs 下发任务  ├─ Tailscale/WireGuard 内网
├─ SSE 盯进度 / stop 中止              ├─ profile: worker-a（hermes profile install 分发）
├─ /v1/runs/{id}/approval 人工审批     └─ 完整工具链 agent
└─ 反向调 VPS 的 /v1/chat/completions

7.3 推荐：路线 B 为主（贴合现状），路线 A 为补充

架构图集（PlantUML 渲染）

以下三张图是本方案的核心视图。图 1 展示目标架构全貌，图 2 展示任务从需求到验收的完整生命周期（映射到 Hermes Kanban 原生机制），图 3 展示 Mac mini 与 VPS 之间的跨机桥接通道。

08八、子项目落地路线（细化版）

原文档建议 4 个子项目，本调研确认其拆分合理，但顺序和内容需要调整——因为 Kanban/Profiles 已内置，子项目 3（任务管家）和子项目 4（Worker 改造）的工作量大幅缩小，核心变成「配置 + 桥接」而非「开发」。

8.1 子项目 1：Mac mini 基础环境（前置，必须最先）

目标：让 Mac mini 成为可 7x24 运行的中枢。

8.2 子项目 2：个人知识图谱（可与子项目 1 并行，或在跑任务中沉淀）

目标：建立 SQLite 事实单一来源。

8.3 子项目 3：任务管家工作流（核心价值验证）

目标：让 Steward 能从「辅助结构化」演进到「代为验收」。

关键机制（全部用 Hermes 原生）：

• 任务包 = Kanban task body（目标/范围/验收标准）+ --skills 注入专用技能
• Worker 自评 = kanban_complete(summary, metadata{criteria_met, confidence})
• 升级 = kanban_block(reason) → 用户手机 /kanban 处理
• 依赖编排 = kanban_create(parents=[...])
• 审计 = task_events 自动记录，无需额外开发

8.4 子项目 4：VPS Worker 改造（视实际任务类型而定）

目标：让两个 VPS Hermes 成为可被调度的 Worker。

8.5 启动顺序（调整后）

09九、风险与应对（更新版）

10十、Mac mini 硬件选型速查

要点：

• 32GB 相比 24GB 的唯一新增能力是能跑 32B 稠密模型；MoE 档位两者体验一致
• 万兆网口是加分项：家中 NAS 备份、大模型文件传输、未来本地文件服务都用得上
• 内存已到位（不可升级），硬盘 512GB 装系统+4-5 个模型略紧——模型库建议放外接雷雳 NVMe 盒（2TB ≈ ¥1,000）
• 电费可忽略：M4 平均 12W，7x24 一年 ≈ ¥60-80

10.2 其他配置档位参考（未选购时的备选认知）

你的 32GB 配置介于「核心推荐」和「M4 Pro」之间：本地推理能力接近 M4 Pro 的 24GB 档（MoE 体验一致），只是速度受 120GB/s 带宽限制。

11十一、决策清单与下一步

11.1 需要用户拍板的决策

11.2 下一步行动

1. 确认 D1（买不买 Mac mini）——✅ 已确认：M4 32GB/512GB 已购，全新未开机，可直接启动子项目 1
2. 若确认购买：启动子项目 1（Mac mini 基础环境，1-2 天）
3. 子项目 1 完成 1.10 步（跨机最小实验）后，确认 D5（跨机主路线）
4. 并行启动子项目 2（图谱 schema + 首批数据）和子项目 3 阶段一（Steward 辅助结构化）
5. 用第一个真实调研任务跑通全链路，验证「用户提需求 → Steward 结构化 → Worker 执行 → 验收」闭环

11.3 原文档待决策问题的最终答复汇总