WIN-JHFT4D3SIVT\caoxiaozhu
4972b4e6b1
Align the L3 graph, agent service, and sync tool shims on one canonical continuity contract so clarification resumes and persisted snapshots behave consistently. Add targeted regressions and hardening notes covering system-message coalescing, async bridge usage, and continuity rehydration.
58 lines
5.4 KiB
Markdown
58 lines
5.4 KiB
Markdown
# Notes: Jarvis Knowledge Brain Blueprint
|
|
|
|
## Current-State Findings
|
|
- Existing source domains already exist separately: conversations, documents, todos, tasks, forum posts.
|
|
- Current long-term memory only comes from conversation extraction via `UserMemory`.
|
|
- Current graph build path only uses indexed document chunks.
|
|
- Scheduler infrastructure already exists and can host daily brain-learning jobs.
|
|
- Frontend already exposes a `知识大脑` navigation entry, but it currently points to the graph page.
|
|
|
|
## Synthesized Findings
|
|
|
|
### What can be reused
|
|
- `memory_service` as a seed for conversation extraction and recall.
|
|
- `scheduler_service` as the base for daily learning workflows.
|
|
- `tag_service` as an early foundation for brain tags.
|
|
- Existing business tables as authoritative raw source records.
|
|
|
|
### What is missing
|
|
- Unified event layer across all source systems.
|
|
- Candidate memory layer between raw events and durable brain memory.
|
|
- Timeline-aware memory model with reinforcement / archival states.
|
|
- Retrieval path that combines long-term memory with recent relevant events.
|
|
- Brain-specific APIs and a dedicated frontend dashboard module.
|
|
|
|
### Phase 1 objective
|
|
- Build the minimum architecture needed for a real event-driven brain:
|
|
- BrainEvent
|
|
- BrainCandidate
|
|
- BrainMemory
|
|
- BrainTag and link tables
|
|
- ingestion services
|
|
- daily learning job
|
|
- retrieval integration
|
|
- brain dashboard APIs
|
|
|
|
## Additional Findings: Knowledge Parsing Normalization
|
|
- Current document ingestion parses each format separately and builds chunks directly from ParsedNode items.
|
|
- Current chunks already carry structural metadata, but there is no explicit parent-child chunk graph.
|
|
- The agreed direction is to use MinerU for PDF only, keep existing parsers for DOCX/XLSX/CSV/MD/TXT, and converge all outputs into structured markdown.
|
|
- normalized_content should be persisted on documents so preview, rebuild, and future chunking can reuse the same canonical text.
|
|
- Lightweight hierarchy should be represented in chunk metadata first, not in a new relational tree schema.
|
|
- Current DOCX upload failure in the running environment is caused by a missing python-docx installation in the active backend environment.
|
|
|
|
## Additional Findings: L3 Merge Progress
|
|
- `backend/app/agents/state.py` has been expanded to the newer L3 runtime state shape so graph/runtime code can rely on structured continuity, tool-round, retry, routing-hop, and datetime-reference fields.
|
|
- `backend/app/agents/graph.py` no longer contains merge markers and the phantom `EXECUTOR_ACCOUNTING` branch has been removed from graph registration and routing.
|
|
- Accounting-style prompts are currently normalized onto `AgentRole.EXECUTOR` instead of a separate executor-accounting role, which avoids dangling enum/runtime references while keeping those intents routable.
|
|
- `backend/tests/backend/app/agents/test_graph.py` has been reconciled onto the newer L3 runtime test branch and stale `EXECUTOR_ACCOUNTING` expectations were updated to `AgentRole.EXECUTOR`.
|
|
- Tool execution now uses a shared async bridge in `backend/app/agents/tools/async_bridge.py`, and `search.py`, `schedule.py`, `task.py`, plus `forum.py` all route synchronous tool entrypoints through that same bridge to keep runtime behavior consistent inside and outside active event loops.
|
|
- Current task/schedule canonicalization remains intentionally narrow for L3: task aliases (`content`, `date`, legacy priorities) and reminder aliases (`datetime`, `at`, `remind_at`, `time`, timezone variants) are normalized; deferred domains such as weather/accounting-specific tool routing remain outside this stabilization slice.
|
|
- Targeted verification now covers async bridge behavior plus task/schedule alias persistence tests; local pytest invocation still depends on resolving environment-level startup issues when the interpreter exits before running the selected files.
|
|
- L3 runtime/service integration now persists continuity snapshots in a single canonical envelope (`kind`, `version`, `state`) on both assistant message attachments and `Conversation.agent_state`, so streaming and sync chat entrypoints rehydrate the same shape.
|
|
- The continuity rehydration path is also tolerant of older `Conversation` rows/models that do not expose `agent_state`, falling back to assistant message attachments instead of failing before graph execution.
|
|
- The finalized L3 continuity contract persists a canonical `agent_continuity_state` snapshot: `turn_context.active_sub_commander`, `pending_action.type|owner_agent|owner_sub_commander|status`, `clarification_context.owning_agent|owning_sub_commander|target_action|question|status`, and `continuity_state.status|mode`.
|
|
- `backend/app/services/agent_service.py` normalizes legacy persisted snapshots (`active_sub_flow`, `agent`, `sub_flow`, `action_type`, `awaiting_user_input`, `awaiting_clarification`) into that canonical shape on both save and rehydration so older brain-ingestion records still resume correctly.
|
|
- Edge cases: explicit new requests may keep stale continuity in memory for override-aware routing, but only `continuity_state.status == fresh` participates in active continuation; clarification resumes use `continuity_state.mode = resume_after_clarification`.
|
|
- `memory_service.build_memory_context(...)` remains the shared retrieval join point for conversation summaries, user memory, and BrainMemory recall, while `document_service` continues emitting BrainEvent records from upload flow without changing the graph runtime contract.
|