# H-0 Hermes 现状探测与 PoC 边界

## 1. 目标

在不影响现有 Jarvis 主流程的前提下，确认 Hermes 是否适合作为 Jarvis chat 的可嵌入 runtime。

本阶段只回答 4 个问题：

1. Hermes 更适合如何接入：Python API、单次 CLI、长驻 CLI、gateway，还是其他形式？
2. Hermes 是否支持 conversation 级别的长驻 session / resume？
3. Hermes 是否能在后端被程序化调用，而不是只能人工交互？
4. Hermes 的接入是否能保持 Jarvis 现有 chat 页面协议稳定？

## 2. 当前已知信息

### 2.1 来自 Hermes 仓库的直接结论

- Hermes 主入口是 CLI：`hermes`
- 提供 single query 模式：`-q` / `query`
- 提供 `resume` 机制
- 提供 gateway 模式
- README 明确说明：原生 Windows 不受支持，建议 WSL2
- `run_agent.py` 暴露了更直接的 Python 级 `chat(message, stream_callback=...)` 接口
- 内部有 SQLite session store，说明其本身有 session persistence 概念

### 2.2 对 Jarvis 的意义

这说明 Hermes **不是只能人手操作的纯 TUI**，而是具备：

- 单次 query 入口
- session 恢复能力
- Python 层 chat 接口
- streaming callback 可能性

因此它存在被 Jarvis 后端托管成 runtime 的现实基础。

## 3. 本阶段输出

### 3.1 必须验证的能力

1. **安装方式**
   - 是否能在当前环境隔离安装
   - 是否需要迁移到 WSL2 才具备稳定运行条件

2. **非交互调用能力**
   - 是否能用 CLI 单次 query 跑通
   - 是否能用 Python 直接调用 `run_agent.py` 的 chat 接口

3. **session 能力**
   - 是否能创建、恢复、复用 session
   - 是否适合绑定 `conversation_id`

4. **输出接法**
   - 是否能通过 callback / stdout 获取稳定文本流
   - 是否可被映射成 Jarvis 现有 SSE 事件

### 3.2 不在本阶段做的事

- 不改现有 Jarvis 默认运行链路
- 不重写前端 chat 页面
- 不直接删除或停用 LangGraph 主流程
- 不引入一次性大迁移

## 4. 推荐 PoC 边界

### 4.1 推荐优先级

1. **优先验证 Python chat 接口**
   - 理由：比解析 TUI 更稳
   - 若可行，首版桥接应优先走这个路径

2. **其次验证 CLI 单次 query + resume**
   - 作为备选方案
   - 若 Python 接口不可控，可退而求其次

3. **最后才考虑 TUI/PTY 桥接**
   - 成本高
   - 不适合作为 Jarvis chat 的第一接法

### 4.2 PoC 成功标准

- 能在隔离环境中启动 Hermes
- 能程序化发送一条消息并得到结果
- 能确认 session 可复用或可 resume
- 能形成一个后端 runtime adapter 可实现的最小桥接思路

## 5. 可能结论及后续影响

### 结论 A：Python chat 接口稳定
- 最优方案
- H-1/H-2 直接围绕 Python adapter + session manager 展开

### 结论 B：CLI `-q` + `resume` 稳定
- 可接受
- H-2 要更强调 session 句柄与进程生命周期管理

### 结论 C：只能稳定跑 TUI
- 风险显著升高
- 需重新评估是否值得继续集成

### 结论 D：当前环境无法稳定运行
- 可能需要 WSL2 或远程服务化托管
- 再决定是否继续推进

## 6. 验证清单

- [ ] 拉取 Hermes 仓库到隔离目录
- [ ] 明确 install 依赖与 Python 版本要求
- [ ] 确认单次 query 调用方式
- [ ] 确认 Python chat 接口是否可用
- [ ] 确认 session / resume 的可编程性
- [ ] 记录接入建议结论，作为 H-1 输入