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. 默认切换有灰度与回滚路径。