mirror of
https://github.com/open-jarvis/OpenJarvis.git
synced 2026-07-28 14:07:55 +00:00
4218258486
`jarvis serve` constructed every heavy component inline (engine discovery + instrumentation, telemetry, memory, agent manager, per-agent tools) and then called `SystemBuilder(config).build()` a second time inside the scheduler block purely to feed `AgentExecutor.set_system()`. That second build re-discovered and re-connected the engine, re-instrumented it, re-resolved tools, re-opened the configured channel and re-created the agent manager — ~30-40s of fully redundant startup work (the headline remaining cost in #263 after engine probes were parallelised and the version check moved off the hot path in #470). Fix: assemble the executor's `JarvisSystem` from the components already built inline instead of rebuilding from scratch. `AgentExecutor` only reads `engine`, `model`, `config`, `memory_backend`, `tool_executor`, `session_store` and `channel_backend` off the system; all are wired here. The memory backend is now constructed just before the scheduler block (it was built later) so the executor's system can reference it, and the primary agent's resolved tool list is reused to build the scheduler's `ToolExecutor` (preserving the MCP-discovered-tool pool the executor reads via `tool_executor._tools`). `skill_manager` / the learning orchestrator are only consumed by the orchestrator's `system.ask()` path, which the executor never invokes, so they are intentionally omitted. Tests: new `tests/cli/test_serve_single_build.py` patches `SystemBuilder.build` and asserts it is never called during `jarvis serve` startup, and that the executor still receives a system exposing `tool_executor` / `session_store` / `memory_backend` (plus engine/model/config). Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>