JARVIS/development-doc/plan/hermes-update/adr-hermes-first-architecture.md

# ADR：Hermes-first 架构

## 状态

Accepted（进入实施规划）

## 背景

Jarvis 当前已经具备较强的自研 agent runtime 能力，但核心执行链路仍然偏自定义、偏集中式，导致：

- 执行 runtime 与产品层耦合过深
- Hermes 虽已接入真实 bridge，但仍只是 adapter 分支
- 长驻 session、恢复、执行循环等能力没有形成更清晰的 runtime ownership
- 前端虽然能切 runtime，但本质仍是 Jarvis-centered UX + backend branching

同时，用户明确表达：

- 更偏好 Hermes 的体系化能力
- 不希望继续扩展自研 agent 主链路
- 希望连续对话、常驻 session、不冷启动
- 要求先文档后开发

## 决策

采用 **Hermes-first architecture**：

- Hermes 成为默认 execution core
- Jarvis 保留为 product shell
- 旧 Jarvis graph 在迁移期保留为 fallback / specialist path
- 前端继续使用 Jarvis chat product shell，而不是直接暴露 Hermes 终端形态
- SSE 契约保持稳定，由 Jarvis 负责做 runtime event mapping

## 责任边界

### Hermes 负责
- session lifecycle
- runtime resume / restart / health
- execution loop
- chunk streaming
- runtime-internal tool orchestration

### Jarvis 负责
- conversation/message persistence
- memory / knowledge / retrospective assembly
- skill shortlist
- task graph shaping
- product continuity envelope
- SSE contract
- observability / metrics / attachments
- rollout / fallback / rollback policy

## 不采用的方案

### 方案 A：继续保持 adapter-first
不采用原因：
- Hermes 长期只会是支线 runtime
- `AgentService` 会继续膨胀
- 无法真正把架构中心从 Jarvis runtime 本体迁走

### 方案 B：直接删除 Jarvis，自上而下改成 Hermes 原生产品
不采用原因：
- 会丢失 Jarvis 已有的 conversation、memory、task、业务层价值
- 缺乏迁移和回滚路径
- 风险过高

## 影响

正向影响：
- runtime 职责更清晰
- 长驻 session 方向更明确
- 后续维护重心从“造 runtime”转向“做产品能力”

负向影响：
- 迁移期需要同时维护 Hermes default path 与 Jarvis fallback path
- 需要重构 `AgentService` 和 continuity state
- 需要补 durable lifecycle 和 rollout policy

## 验收标准

1. Hermes 成为默认 execution core。
2. Jarvis 仍保留 product shell 能力。
3. 多轮对话 continuity 不依赖每轮冷启动。
4. SSE 前端契约保持稳定。
5. 默认切换有灰度与回滚路径。