Substrate Overview

Status: active Scope: nexrur program-first substrate 总纲入口 Current hierarchy: 本文件是 Level 0 总纲；专题设计见 DESIGN_6STEP.md / DESIGN_SCHEMA.md / DESIGN_DIAGNOSIS.md / DESIGN_GOLDEN.md / DESIGN_MEMORY.md / DESIGN_LLM.md / DESIGN_CLI.md / DESIGN_ENGINES_CAMPAIGN.md / DESIGN_ENGINES_ORCHESTRATOR.md / DESIGN_ENGINES_TOOLLOOP.md / DESIGN_SKILL.md / APP_MIGRATION_HANDBOOK.md；生产运维指南见 DEPLOYER_NEXRUR.md

更新时间：2026-04（按当前代码现状重写）

范围：src/nexrur/ + docs/ 顶层设计总览

子系统：core/、llm/、mcp/、memory/、engines/

本文是 nexrur 的 总体架构单一真相源。它不替代各子目录下的 _DESIGN.md，而是提供统一的系统视角，回答：

1. nexrur 到底是什么。
2. 各子系统如何分层。
3. 运行时主链路如何流动。
4. 哪些是稳定底座，哪些是可插拔扩展。
5. 当前架构合理性与主要欠账在哪里。

Active 文档层级

如何使用 docs

1. 先读本文件，确认 nexrur 的 Level 0 架构与文档层级。
2. 按任务进入 Level 1：diagnosis / crossdomain / LLM / CLI / skill / app migration。
3. 需要操作说明、环境说明或历史比较时，再读 Level 2 reference。
4. 不要从 VScode-*、WQYI-vs-*、ai-runs/README.md 或 docs/archived/** 反推 active architecture。
5. 如果 Level 2/3 与 Level 0/1 冲突，以 Level 0/1 与当前 code/contracts 为准。

子系统详细设计见：

• ../src/nexrur/core/_DESIGN.md
• DESIGN_LLM.md
• DESIGN_CLI.md
• ../src/nexrur/mcp/_DESIGN.md
• ../src/nexrur/memory/_DESIGN.md
• ../src/nexrur/engines/_DESIGN_V2.md

消费者侧扩展设计参考：

• DESIGN_SKILL.md
• ../../quant/WQ-YI/.gemini/skills/_shared/_DESIGN.md

contracts 目录的定位

src/nexrur/**/contracts/ 是 app-facing API/contract 手册与参考样例目录，不是生产真值目录。

• *.md 定义 app 应提供的结构、字段语义、底座如何消费。
• *.yml 与 golden/ 下的 index.example.yml / full-asset examples 是参考样例、模板或 fixture。
• 旧 root-level patterns/ / examples/ / counterexamples/ contract samples 已归档为 _archived/legacy_classified_markdown/，history-only，不是 active contract shape。
• 生产真值必须来自 app 自己的 asset/config root，例如 WQ-YI 的 .gemini/skills/_shared/...。
• 底座 Python 不应因为 contracts/ 里的示例而硬编码某个 app 的业务语义。
• Diagnosis Golden contract samples should live under src/nexrur/engines/contracts/diagnosis/golden/ with index.example.yml plus positivecases/, counterexamples/, patterns/, and candidates/ examples. This mirrors the app-side contract shape only; active golden truth must come from the registered app diagnosis asset root.

命名体系

engines 当前目标采用 prefix-free core engine names。四个 active core engine 直接使用业务名，方便人类审计和 app 接入：

• campaign.py: lifecycle control / route / restart / halt / budget。
• diagnosis.py: diagnostic reasoning / evidence arbitration / golden A/B/C。
• orchestrator.py: execution graph / step entrypoints / dependency dispatch。
• toolloop.py: tool registry / ToolLoopRunner binding / router-batch execution。

orchestrator.py 内的 checkpoint/replay 区段与 campaign.py 第 5 块 State / Observability 是 engine-owned state helpers，不属于四个核心业务引擎。旧 ctl_* / reg_* / exe_* / sta_* 文件名只能作为迁移期实现名或 archived 历史名存在；新文档和新接入 不得再把前缀当作 active 设计口径。

1. 总体定位

nexrur 是一个 可嵌入消费者仓库的 AI 运行时底座。它的目标不是提供单一业务，而是提供一套可复用的：

1. 运行时原语：上下文、路径、审计、证据、清单、状态。
2. 协议接入能力：LLM、MCP、外部存储、凭据与韧性处理。
3. 记忆与检索能力：Embedding、VectorStore、RAG、ContentStore。
4. 编排能力：Orchestrator、Checkpoint/Replay、Tool Loop。

它适合的角色不是“业务应用本体”，而是：

让多个消费者仓库（如 WQ-YI、AGV、AUDIT）共享一套稳定 AI 执行底座，而把业务语义留在消费者仓库中。

2. 设计总原则

2.1 Program-first substrate

nexrur 的底座定位不是 Claude Code 式的 LLM-first interactive runtime，而是：

program-first substrate

也就是说：

• 核心控制权属于程序；
• LLM 是能力层，而不是统治层；
• 状态推进、halt、checkpoint、replay、budget、route 决策必须可测试、可复盘、可重放。

2.1.1 LLM-governed steps are contract-bounded cognition stages

LLM-governed steps are contract-bounded cognition stages over shared evidence and reviewed knowledge, not open-ended autonomous agents.

Canonical boundary:

Evidence / evidence substrate  -> facts, refs, current scope, upstream context
Golden reviewed cognition     -> approved cases, counterexamples, patterns
Schema / payload contract     -> IO shape, artifact refs, validity facts
Diagnosis                     -> explain failure from bounded evidence
Campaign                      -> execute restart / pivot / halt

Production, Diagnosis, and restarted Production all consume the same evidence/evidence substrate. They differ only by episode overlays:

• Production sees evidence facts, obligations, current scope, upstream feedback, and approved golden knowledge where registered.
• Diagnosis sees the same substrate plus the current production artifact, validation failure facts, runtime feedback, and upstream handoff evidence.
• Restarted Production sees the same substrate plus the previous artifact, validated diagnosis reason / suggestion, and campaign directive.

Golden is a shared reviewed cognition substrate. It must not be split into uncoordinated production_golden / diagnosis_golden truth stores. Apps may filter which approved golden assets a step reads, but promotion and validity belong to one review-gated golden contract.

Production and Diagnosis both use the same substrate pre-LLM selector surface. The prompt truth lives in src/nexrur/prompts/evidence.md under the pre_llm_selector section, not in each owner as a full standalone Prompt A. Apps provide selector profiles/goals and eligible golden assets; the substrate provides the runner, output schema, forbidden-field validation, approved index/full-asset resolution, and trace contract. Production owners inject the resulting selected_golden_context into their existing Production Prompt B. Diagnosis injects the same selector result into Diagnosis Prompt B. The selector must not output diagnosis or campaign verdict fields such as reason_code, target_step, campaign_control, or repair_plan.

Legacy skills/selector.md files are migration overlays for app-specific selection goals. They are not long-term prompt truth and should converge into schema-validated selector profiles consumed by the substrate evidence.md::pre_llm_selector section.

Program code may assemble, validate, cite, and budget this context. It must not turn those assets into local business arbitration, hidden route maps, or open-ended self-repair loops.

2.1.2 控制线不是 ToolLoop：与 LLM-first runtime 的本质区别

nexrur 的核心控制线保持 program-first import chain，不登记成普通 ToolLoop。这是它与 LLM-first interactive runtime（例如 Claude Code 风格） 的本质区别之一。

两条控制线必须咬死：

CLI -> campaign.py -> orchestrator.py -> leaf ToolLoop capabilities

fail2pivot.py -> diagnosis.py -> campaign.py

底座身份先定死：diagnosis.py、campaign.py、orchestrator.py 是 substrate engine，不是 tool。ToolLoop 可以调用这些 engine 暴露出来的 边界 callable，但不能把 engine 本体降格为普通工具，也不能让 LLM 自由选择 或重组这些控制面。

第一条线说明：

• nexrur.cli.nexrur 是 app-neutral 启动入口，负责解析 app、asset、 run-config 和 contract roots。
• campaign.py 是 campaign 控制面，负责 lifecycle / route / restart / halt / budget，不是普通 ToolLoop。
• orchestrator.py 是执行图调度器，负责 app/subagent/module graph、 dependency dispatch、checkpoint/replay 和 leaf phase 调度。
• 只有 orchestrator 触达的 leaf capabilities 才进入 toolloop.yml / ToolLoopRunner，例如 evidence、schema、production、active、LLM/MCP capability。

第二条线说明：

• fail2pivot.py 是 Step 6 复合 callable，可以作为 orchestrator leaf capability 被调用。
• fail2pivot.py 内部直接调用 diagnosis.py 和 campaign.py。
• diagnosis.py 负责 bounded cognition，可以在内部通过 LLM/ToolLoop LLM adapter 调用模型。
• campaign.py 只消费 diagnosis_result 和 app campaign assets，产出 deterministic campaign_control；它不变成 LLM toolloop。

因此，ToolLoop 的定位是 registered leaf capability execution layer， 不是整个底座的统一调用形态。LLM/MCP/memory/production/diagnosis 中的 agent operation 可以通过 registered capability 暴露；CLI、campaign、 orchestrator 是控制面，保留直接程序调用、可测试、可复盘、可重放。

禁止：

• 把 CLI / campaign / orchestrator 登记成普通 ToolLoop。
• 让 orchestrator 通过 ToolLoop 调自己。
• 让 campaign 像 agent loop 一样自由思考 route。
• 用 LLM 输出替代 campaign contract / orchestrator graph / checkpoint control。

2.2 LLM-native，但不 LLM-governed

nexrur 必须对 LLM 友好：

• llm/ 提供 provider-neutral LLM 能力；
• mcp/ 提供外部工具 / MCP / REST provider 能力；
• memory/ 提供 RAG/ContentStore；
• engines/toolloop/ 提供受控工具循环 contract、router 与 runner builder；
• 消费者仓库通过 contract/assets 注入业务语义，不通过 _shared 程序巨石扩展底座。

但这不意味着底座由 LLM 统治。

编程 agent 可以更偏向 LLM-first，因为有强外部 guard：

• 编译器

• 类型检查

• 单测

• 立即执行反馈

金融/研究型 agent 没有这种编译器级 guard，反馈：

• 慢
• 贵
• 统计性强
• 容易 symptom/root-cause 错位

因此 nexrur 的原则必须是：

LLM 可以提供建议、排序、诊断、解释；程序必须保有最终裁决与执行权。

2.3 消费者侧的正确模式

对于 WQ-YI 这样的消费者，推荐模式是：

• nexrur：稳定程序底座
• app contracts/assets：消费者业务语义与配置真值
• nexrur.cli.nexrur / nexrur-campaign：底座 app 启动入口与 contract 组装
• app run-config yml：消费者运行参数与预算覆盖
• app skill owner callable：每个 app step 的 explicit orchestrator entrypoint，例如 scripts/skill_<name>.py:run_<step>_orchestrator_tool
• app skill implementation：业务技能与工具调用

一句话：

底座 program-first，app 通过 contracts/assets/orchestrator step entrypoints/run-config yml 注入语义，不在 _shared 长期保留底座程序分叉。

2.4 Subagent Six-Step Execution Contract

nexrur 对 app 暴露的 subagent 执行模型以六步为 canonical contract。不同 app 可以按业务命名 phase，但语义必须能映射到下表：

硬约束：

• Step 5 的层名是 Validation (schema-driven)；schema.py 只是常见 wrapper 文件名。
• Step 5 的 canonical 字段命名与禁止边界见 DESIGN_SCHEMA.md；schema wrappers 产 facts，不产 diagnosis。
• Step 6 是常驻层，不是失败后才临时加的 prompt。
• 不存在独立 Step 7 repair。需要修复时，由 Step 6 产出 diagnosis result，再由 campaign 决定 route / halt / restart。
• stepsix/fail2pivot.py 是 Step 6 复合能力面，不是第五个核心 engine： 它只负责把 app 的 step6_evidence evidence packet 交给 diagnosis，再把 diagnosis result 交给 campaign。
• Owner 文件只能做 orchestration、artifact 汇总和 handoff；evidence/digest/obligation、validation、diagnosis 大脑都不应长期留在 owner。

2.5 Five-Bucket Evidence Model

Diagnosis 与 evidence 类 Step 1/2/3 能力统一以五桶 evidence 为输入模型：

nexrur owns the readers, bundlers, validators, and routing mechanisms. The app owns the source manifest and semantic truth, usually through app-owned assets such as evidence.yml, schema packs, diagnosis packs, and campaign packs.

Memory/cognition/crossdomain are no longer a separate diagnosis input hierarchy. They are evidence inside the memory bucket and must flow through the evidence bundle before diagnosis or campaign can use them.

2.6 Diagnosis/Campaign Restart Invariants

Diagnosis explains; campaign executes. This invariant applies across apps:

• diagnosis.py consumes evidence + app diagnosis assets and returns diagnosis_result.
• campaign.py consumes diagnosis_result + app campaign assets and returns campaign_control.
• Diagnosis must not directly mutate lifecycle state, restart a phase, or patch app artifacts.
• Campaign may request continue, reroute, or halt; when it reroutes, restart must begin at the target subagent's phase 1.
• Middle-phase restart, hot repair inside a failed phase, and prompt-level patch-and-continue are forbidden as canonical behavior.
• Target subagent enums are app-owned truth, but each app must normalize aliases before campaign routing. The substrate should treat target values as contract data, not hard-code app business target names.

3. 总体架构

┌────────────────────────────────────────────────────────────────────────────┐
│                          Consumer Repos / Skills                           │
│                                                                            │
│  WQ-YI / AGV / AUDIT / 其他消费者                                           │
│  - app/subagent/module orchestrator.yml contracts                           │
│  - ToolLoop registered production callables                                 │
│  - 业务技能、规则、资产语义、策略拓扑                                       │
└───────────────────────────────┬────────────────────────────────────────────┘
                                │ 提供 contracts / tools / app assets
                                ▼
┌────────────────────────────────────────────────────────────────────────────┐
│                               engines/                                      │
│                                                                            │
│  Campaign / ContractGraphOrchestrator / Checkpoint / ToolLoopRunner        │
│  - 递归解释 app/subagent/module 执行图                                     │
│  - 同 trace/cycle 的 checkpoint 与定向重启                                 │
│  - Tool Loop 受控工具循环                                                   │
└──────────────┬───────────────────────────────┬─────────────────────────────┘
               │ 调用运行时原语                  │ 调用协议客户端 / memory
               ▼                                ▼
┌────────────────────────────────────────────────────────────────────────────┐
│                                  core/                                      │
│                                                                            │
│  Audit / Evidence / Manifest / Outcome                                     │
│  Policy / Cache / Schema / Redact                                          │
│                                                                            │
│  负责：审计、证据、清单、outcome、策略读取、schema、脱敏                   │
└──────────────┬───────────────────────────────┬─────────────────────────────┘
               │ 延迟挂载                         │ 提供上下文给客户端/记忆层
               ▼                                 ▼
┌───────────────────────────────┐    ┌──────────────────────────────────────┐
│             llm/              │    │              memory/                 │
│                               │    │                                      │
│  llm.yml / LLMService         │    │  embedding / vectorstore            │
│  Gemini / Doubao / DeepSeek   │    │  RAGPipeline / ContentStore         │
│  credentials / resilience     │    │  cognition / crossdomain             │
└──────────────┬────────────────┘    └──────────────────┬───────────────────┘
               │                                           │
               ▼                                           ▼
┌───────────────────────────────┐    ┌──────────────────────────────────────┐
│             mcp/              │    │         外部依赖 / 持久化目标         │
│                               │    │                                      │
│  MCPClient / MCPGateway       │    │  Gemini API / MCP Gateway           │
│  ToolRegistry / Middleware    │    │  FAISS / SentenceTransformers       │
│                               │    │  docs/ai-runs / .memory/vectorstore │
└───────────────────────────────┘    └──────────────────────────────────────┘

3.1 架构解读

这张图表达六个关键事实：

1. 业务语义不在 nexrur 内核里，而在消费者仓库注入。
2. engines/ 是编排执行层，不直接实现路径/缓存/审计。
3. core/ 是真正的运行时底座。
4. llm/ 是 provider-neutral LLM 能力面，给 engines/ 提供统一 LLM 入口。
5. mcp/ 是外部能力接入层，既支持 MCP client/gateway，也承载 provider contract interpreter。
6. memory/ 是被 core/_archived/runtime.py（已退场） 延迟挂载的知识基础设施。

4. 分层原则

4.1 core/：运行时原语层

负责：

• RunContext
• 双根路径路由（business/shared）
• 审计与证据
• 清单与 outcome
• policy / cache / schema
• state shells / campaign metrics belong to campaign.py block 5 State / Observability

不负责：

• 业务编排
• provider 协议细节
• 业务规则

4.2 llm/ / mcp/：能力接入层

负责：

• llm/：统一 LLM profile、凭据、transport、usage、resilience。
• mcp/：统一外部 provider 声明、MCP/REST 调用、toolhost/toolloop 暴露。

不负责：

• 业务决策
• 路径路由
• app 业务语义

4.3 mcp/：协议接入层

负责：

• MCP client
• MCP gateway
• 工具注册表
• 网关中间件链

不负责：

• 业务工具实现
• 运行时上下文管理
• engines 编排

4.4 memory/：知识基础设施层

负责：

• Embedding
• VectorStore
• RAGPipeline
• ContentStore
• StepBrief / StepValidation cognition products
• Cross-domain lesson bridge

不负责：

• 业务记忆策略
• 编排决策
• provider transport

4.5 engines/：编排执行层

负责：

• Orchestrator
• Checkpoint / Replay
• Tool Loop
• 协议化 step execution

不负责：

• provider 实现
• 路径原语
• 业务拓扑定义

5. 五个子系统的角色

5.1 core/

core/ 是 nexrur 的 L0 底座。

关键对象：

• PlatformPolicy
• explicit audit ledger
• schema validator
• redaction/env boundary

核心价值：

没有 core，engines 只能是脚本；有了 core，engines 才能成为可恢复、可审计、可复盘的运行系统。

5.1.1 PlatformPolicy boundary

PlatformPolicy owns canonical App-policy path compilation from an explicit app_root, YAML parsing, layered reads, and generic shape validation. It does not search parent/current directories and does not own any App step hierarchy, provider default, or business policy path.

The only active path-level lint contract is App-declared:

policy_lint:
  enabled: true
  required_paths:
    - contracts.schema_index_path
    - boundaries.code_boundary

The substrate validates that each declared dotted path exists. It must not:

• read lint configuration from a particular App step or module;
• embed Dataset, L1/L2, Evaluate, report, or other App path names;
• infer required paths from an App name;
• treat strict_mode as authorization to apply a substrate-owned business schema.

If an App needs full value/type validation, its schema owner validates the policy artifact separately. PlatformPolicy only checks generic mapping shape and explicitly declared path presence.

5.1.2 Audit identity boundary

The Core audit callable accepts one explicit envelope: absolute runs_root, canonical campaign/trace/cycle/run identity, event, status, ok, and an optional payload. It rejects unknown or legacy fields and writes the redacted payload as one nested field. It does not expose an AuditBus, infer roots from contexts, or flatten payloads for old consumers.

5.2 llm/ 与 mcp/

clients/ Python package 已退场并归档到 src/nexrur/_archived/clients/。 当前 active 能力面是 llm/ 与 mcp/。

关键对象：

• NexrurCredentials
• GeminiClient
• LLMService
• ErrorClassifier / RetryPolicy
• MCPClient / MCPGateway
• ProviderCatalog / provider adapters

核心价值：

把 provider/协议差异隔离掉，让 engines 通过 toolloop/llm/mcp 面向稳定能力接口。

5.3 mcp/

mcp/ 是 MCP 协议的 client + gateway 双向接入层。

关键对象：

• MCPClient
• MCPGateway
• ToolRegistry
• MiddlewareChain

核心价值：

既能消费 MCP 工具，也能暴露 MCP 工具，形成统一协议面。

5.4 memory/

memory/ 是 知识索引与检索子系统。

关键对象：

• PlatformEmbeddingClient
• FAISSVectorStore
• RAGPipeline
• ContentStore
• StepBrief / StepValidation

核心价值：

让多轮、多步骤、多资产执行不再是“无记忆盲跑”。

golden.cognition 归属这一层：它从 evidence / audit / step outputs 派生 brief 与 validation 等跨步骤认知产物，供 diagnosis、routing 与 memory lesson 使用；它不是 core 存储/路径原语，也不是 engines 执行器。

5.5 engines/

engines/ 是 编排器与受控执行引擎。

关键对象：

• ContractGraphOrchestrator
• Checkpoint
• ToolLoopRunner
• run_contract_graph

核心价值：

把 app-owned contracts 与 ToolLoop tools 组织成 Campaign 治理的递归执行图。

边界约束：

• ToolLoopRunner 只提供加载协议与运行时能力；ToolLoop schema（tool specs/final schema/default config）必须由 consumer 显式注册注入。
• nexrur 内核不维护默认 toolloop.yml 业务契约文件。

6. 运行时主链路

一个典型调用链如下：

Consumer Repo
  -> provide orchestrator/toolloop contracts + app assets
  -> nexrur CLI builds ContractGraphOrchestrator factory
  -> Campaign owns run/resume/restart control
  -> ContractGraphOrchestrator.run()/resume()
  -> run_contract_graph() recursively resolves nested graphs
  -> ToolLoopRunner executes registered leaf callable
  -> ctx.llm_client() / ctx.mcp_client() / ctx.rag
  -> audit / evidence / schema 等底座记录持久化
  -> checkpoint.json 更新

6.1 LLM 路径

engine step
  -> ctx.llm_client()
  -> LLMService.generate_text()
  -> GeminiClient / provider transport
  -> resilience classify / retry
  -> audit + evidence + usage

6.2 MCP 路径

engine step
  -> ctx.mcp_client()
  -> nexrur.mcp.MCPClient.call_tool()
  -> provider/toolhost adapter
  -> MCP Gateway / external tool
  -> audit + evidence

6.3 memory 路径

engine step
  -> ctx.rag.retrieve() / index_document()
  -> PlatformEmbeddingClient
  -> VectorStore
  -> audit/evidence/持久化

7. 当前架构合理性

7.1 做得对的部分

A. 分层总体正确

当前五层：

• core
• clients
• mcp
• memory
• engines

是合理的，不是乱堆。

B. RunContext 作为统一挂载点是对的

这让：

• LLM
• MCP
• RAG
• 审计
• evidence

都能通过一套上下文进入，避免四处传对象。

C. 消费者注入模式是对的

业务逻辑留在 WQ-YI / AGV / AUDIT，nexrur 提供底座，这个边界总体成立。

D. memory / mcp / clients 已经基本模块化

这意味着未来还能继续演进，而不是只能靠复制粘贴修。

7.2 当前最大的结构性欠账

欠账 1：部分模块仍处在“迁移兼容态”

例如：

• 某些 _DESIGN.md 已经现代化
• 某些 API 仍带旧兼容壳
• client/gateway/engine 内部仍有双实现残留

欠账 2：clients 与 mcp 的边界有重复能力

例如：

• breaker
• retry
• auth

在 client 与 gateway 两边都各有一套，长期容易漂移。

欠账 3：部分 core / contract 文件命名与真实职责不完全一致

尤其是消费者侧 _shared/core 那类历史兼容结构会污染维护心智。

欠账 4：平台包装层有变胖趋势

clients.py、部分 campaign/diagnosis 代码都在向“策略 glue 层”膨胀，后续需要收敛。

欠账 5：跨层 failure escalation 还不成熟

ALRP/L2 这类案例说明：

• 系统能识别失败层
• 但还不总能升级到真正根因层

这不是 core 结构错，而是编排/诊断层设计还没完全闭环。

8. 当前版本下的合理边界

8.1 应继续保留在 nexrur 的

这些属于底座，应尽量留在 nexrur：

• core/_archived/runtime.py（已退场）
• core/_archived/runroot.py（已退场）
• core/audit.py
• core/_archived/manifest.py（已退场）
• core/_archived/outcome.py（已退场）
• llm/llm.py（resilience）
• mcp/gateway.py
• mcp/mcp.py
• memory/*
• engines/orchestrator.py
• engines/orchestrator.py checkpoint/replay 区段
• engines/toolloop/

8.2 应尽量留在消费者仓库的

这些不应继续上卷进 nexrur：

• 业务资产类型
• campaign 业务规则
• 行业/地域/数据集语义
• 消费者特定 skill prompt/contract
• 具体 alpha / paper / asset 领域逻辑

8.3 处于灰区、未来可能要收敛的

这些当前在 nexrur 里可以接受，但长期可能还要再收：

• provider credentials / side-client 逻辑已归 llm/ 或 mcp/providers.py
• 某些 campaign/domain contracts 若要进入 nexrur，需要先证明跨消费者可复用

9. 未来演进建议

9.1 短期

1. 把所有子系统 _DESIGN.md 补齐并统一风格。
2. 清理明显的 compatibility shell / 重复 handler / 过渡代码。
3. 对平台包装层（llm/mcp/campaign glue）做边界梳理，避免继续变胖。

9.2 中期

1. 收紧 clients 与 mcp 的重复语义。
2. 让更多错误分类进入统一 machine-readable contract。
3. 补齐 diagnosis/fail-pivot 的跨层升级能力。

9.3 长期

1. 明确 nexrur 是否要成为真正“多消费者 AI runtime SDK”。
2. 如果是，就继续收敛 provider abstraction / protocol abstraction。
3. 如果不是，就停止上卷业务语义，保持底座边界干净。

10. 子系统一句话判词

core/

最稳的底座层。 运行时原语、双根路由、审计证据已经形成系统骨架。

llm/

provider-neutral LLM 能力面。 负责凭据、模型 profile、transport、usage 与 resilience。

mcp/

协议接入层分层清楚，但 client/gateway 横切能力重复。

memory/

已经是完整知识基础设施，不再只是附件。

engines/

编排能力成熟，但 diagnosis/fail-pivot 闭环还没完全完成。

11. 一句话总结

nexrur 当前已经不是“几段工具脚本”，而是一套：

以 core 为运行时底座、以 llm/mcp 为能力接入层、以 memory 为知识基础设施、以 engines 为编排执行层的可嵌入 AI runtime。

它当前最大的价值不是某一个 provider 或某一个业务功能，而是：

让多个消费者仓库可以共享一套可审计、可恢复、可检索、可 replay 的 AI 执行系统。

当前最大的风险也不是“分层错误”，而是：

在迁移兼容态与业务快速演化中，平台 glue 层和 fail-pivot/diagnosis 层继续膨胀而失去边界。