WIN-JHFT4D3SIVT\caoxiaozhu
21c869db62
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
113 lines
3.3 KiB
Markdown
113 lines
3.3 KiB
Markdown
# 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 输入
|