JARVIS/development-doc/plan/hermes-update/phase-h-0-recon-and-poc.md

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 输入