Files
JARVIS/development-doc/plan/hermes-update/phase-h4-product-shell-assembly.md

84 lines
2.2 KiB
Markdown
Raw Normal View History

# H4 Product Shell Assembly
## 1. 目标
固化 Jarvis 在 Hermes-first 架构中的角色Jarvis 不是 runtime 本体,而是 **pre-runtime product shell**
## 2. 为什么保留 Jarvis Product Shell
如果直接把 memory / skill / task graph 也推给 Hermes
- Jarvis 已有产品价值会丢失
- 业务能力会进入黑盒
- 回滚与可观测性会变差
所以 Hermes-first 不等于“Jarvis 退化成纯 UI”。
## 3. 保留的装配能力
### 3.1 Memory Assembly
- `backend/app/services/memory_service.py`
继续负责:
- recalled memory
- conversation summary
- user memory
- knowledge brain 注入
### 3.2 Skill Shortlist
- `backend/app/agents/skills/retriever.py`
继续负责:
- request 相关 skill shortlist
- 激活建议
### 3.3 Task Graph / Runtime Request Context
- `backend/app/agents/orchestration/task_graph.py`
- `backend/app/agents/schemas/orchestration.py`
继续负责:
- bounded task graph
- parallel worthiness
- runtime request summary
### 3.4 Retrospective / Product Guardrails
- `backend/app/agents/learning/*`
- `backend/app/agents/tools/time_reasoning.py`
继续负责:
- retrospective 注入
- 时间上下文
- 产品级指令与 guardrails
## 4. 目标数据流
```text
router
-> AgentService
-> load conversation/product continuity
-> assemble memory/skills/task graph/retrospective/time context
-> build RuntimePreparedContext
-> dispatch to Hermes runtime
-> map events and finalize persistence
```
## 5. 关键原则
1. Hermes 接收的是已组装好的 Jarvis product context。
2. Jarvis 保留用户级/产品级理解能力。
3. 不把 Hermes 当作唯一知识与策略拥有者。
4. 装配层必须可测试、可观察、可回滚。
## 6. 推荐文件变更
- `backend/app/services/agent_service.py`
- `backend/app/services/memory_service.py`
- `backend/app/agents/skills/retriever.py`
- `backend/app/agents/orchestration/task_graph.py`
- `backend/app/services/agent_runtime/base.py`
## 7. 完成标准
- [ ] Jarvis product shell 的装配职责被明确固化
- [ ] Hermes 收到的是统一的 prepared context
- [ ] memory / skills / task graph 不被直接塞回 Hermes 黑盒内部