ContentMRS物理与逻辑架构说明

以下按 「物理怎么摆 → 逻辑怎么分 → 是否连贯/对齐 → 哪里还散」 说明当前 ContentMRS 体系（以你工作区 E:\My Project\ContentMRS 和 2026-05-21 的 CONVERGENCE.md / MANIFEST.yaml 为准）。

1. ContentMRS 是什么层？

ContentMRS 不是一个大 Git 仓，而是一个 编排壳（meta-workspace）：

E:\My Project\ContentMRS\
├── 治理文档（无独立 .git，跟「My Project」根仓或本地约定）
│   README / CONTRACT / STACK / CONVERGENCE / ACCEPTANCE / MANIFEST.yaml
│   scripts/          # 跨仓运维：克隆、同步密钥、验收、Tier-1.5 部署
│   deploy/systemd/   # 124 单元文件
│   docs/             # 如 web-evidence-tavily
│
├── 多个独立 Git 子仓（平行同级）
│   DataBase/
│   ContentBase/
│   ContentAdmin/
│   fanqie-service/
│   OpenList/
│   MyBlog/
│
└── 卫星目录（在 ContentMRS 文件夹里，但不在 MANIFEST 主清单里）
    sub2api/           # 物理副本在 ContentMRS 内（非 junction）
    CozeOpenAIProxy/
    remotion-project/ # 视频/TTS 管线，与正文主链不同域

和 E:\My Project 根目录 的关系：link-workspace-roots.ps1 会把 DataBase、ContentBase 等 junction 到根目录，方便老路径习惯；MyBlog 不在 junction 列表里，开发时要认准 ContentMRS\MyBlog。

连贯性：逻辑上「一个内容栈」；物理上「一个文件夹里多套 git + 若干未入 MANIFEST 的旁路项目」——这是 组织层仍偏散 的第一来源。

2. 逻辑分层（目标架构）

文档里已经收成 四层能力 + 三层运行时，比早期的「Tier-2 全冻结」更清晰：

flowchart TB
  subgraph human [人类操作层]
    CA[ContentAdmin<br/>Directus + workbench]
    CBshell[ContentBase console-web<br/>总览 + 重定向]
  end
 
  subgraph runtime [生成运行时层 Tier-1]
    CB[ContentBase product/novel<br/>runtime.generate.*]
    KG[key-guard on 124]
  end
 
  subgraph truth [真相与证据层 Tier-1]
    GW[DataBase Gateway]
    WEB[web-evidence-provider Tavily]
    DB[(CynosDB MySQL)]
  end
 
  subgraph llm [模型层 外置]
    S2[sub2api server-170]
  end
 
  subgraph tier15 [扩展层 Tier-1.5]
    NC[NocoDB 表浏览]
    RF[RAGFlow 深度检索]
    DU[Directus 8055]
  end
 
  subgraph publish [发布层 Tier-2 生命周期]
    FQ[fanqie-service]
    MB[MyBlog 静态站]
    OL[OpenList 文件真源]
  end
 
  CA --> GW
  CA --> CB
  CBshell --> CA
  CB --> GW
  CB --> KG
  KG --> S2
  GW --> DB
  GW --> WEB
  GW -.-> RF
  CA -.-> NC
  CB --> FQ
  MB -.-> OL
  GW --> OL

2.1 按职责分（「谁拥有什么」）

连贯性（逻辑）：CONTRACT.md ↔ CONVERGENCE.md ↔ STACK.md 基本一致——「一条正文链、一个 Gateway 写口、一个主后台」说清楚了。

3. 各子仓内部分层

3.1 DataBase（数据基础设施）

DataBase/
├── apps/
│   ├── gateway/              # 生产核心：/health, /evidence/search, /creative/*, /writes/*
│   └── web-evidence-provider/  # :19091，Tavily/DuckDuckGo（部署在 124，代码在 DataBase 仓）
├── packages/                 # schema、gateway-client、creative-contracts
├── services/gateway-mcp/     # MCP 暴露
├── evidence/                 # 声明、inventory、timeline
├── scripts/                  # 导书、smoke、deploy-gateway
└── docs/                     # operations（nocodb/directus/ragflow）

角色：ContentMRS 的 「南墙」——所有 Tier-1 读写的合同出口。

对齐：ContentBase 只 消费 Gateway；web 证据也在 DataBase 仓里实现、124 上跑进程——实现与文档对齐。

3.2 ContentBase（工作流运行时）

ContentBase/
├── product/novel/           # ★ 唯一正文生成真源
│   ├── app/article/         # capability、topic-preset、context
│   ├── core/manuscript/     # content-craft、llm-client、creative-contract
│   └── tools/               # generate-zhenghe、mvp、验收脚本
├── infrastructure/content-runtime/  # 宿主/配置（对接 server.mjs）
├── apps/console-web/        # 系统总览；/novel → ContentAdmin（已删 novel-manager UI）
├── packages / schemas / vendor
└── .runtime/                # key-guard、acceptance 产物（生产在 124 同路径）

角色：「发动机」——合同驱动的一次性模型写全文。

对齐：

• 与 CONVERGENCE：已删 console-web/components/novel-manager，生成只在 product/novel —— 代码分工与文档一致（若你本地已合入该收敛）。
• 与 DataBase：database-gateway-generated-client + creative contracts —— 边界清晰。
• 未对齐点：project.json 里仍写 E:\My Project\MRS\ContentBase，实际在 ContentMRS\ContentBase —— 路径叙事滞后。

3.3 ContentAdmin（Tier-1.5 人类主 UI）

ContentAdmin/
├── Directus 扩展 + public-workbench
└── SDK 适配器 → Gateway + ContentBase runtime

角色：「驾驶室」（目标态），不是第二套生成器。

对齐（设计 vs 落地）：

连贯性：架构对齐，运维未完全对齐（Tier-1.5 与 Tier-1 验收分开）。

3.4 fanqie-service / MyBlog / OpenList（Tier-2）

• fanqie：执行番茄发布自动化；真相在 ContentBase/Gateway。
• MyBlog：构建 → /srv/myblog/site；与生成进程解耦。
• OpenList：文件面；进 EvidencePack 前必须 import → chunks / semantic_units。

连贯性：边界在 README/合同里清楚；未纳入 verify-production.ps1 端到端（只验生成，不验发布）——生命周期故意断开，但体感仍「散」。

3.5 ContentMRS 内「未入 MANIFEST」的卫星

这些目录让 ContentMRS 文件夹看起来比「内容主链」更大，需要 mentally 划掉。

4. 运行时 Tier 划分（124 / 170）

改进点：相对你之前问的「离散」，现在 验收也分层了——Tier-1 窄、Tier-1.5 宽，文档与脚本比半年前更对齐。

仍不齐处：

• README.md 表里 fanqie 仍写 Tier-1，CONVERGENCE/MANIFEST 更倾向 发布 = Tier-2 —— 小文档冲突。
• ACCEPTANCE.md LLM 失败仍写「查 ~/.codex/auth.json」，而 sync-production-secrets-124.ps1 已改为 ~/.codex-secrets/contentmrs/sub2api-novel.env —— 运维文档滞后。

5. 配置与密钥分层（单真源 vs 多入口）

CONVERGENCE.md 声明的 单真源（目标）：

对齐结论：生产链 正在向单真源收敛；本机开发配置（llm.json、控制台选项）仍可能造成 「我配了千问，生产却是别的」 的体感——属于 配置层离散，不是架构双写。

6. 外置生态（不在 ContentMRS 文件夹内）

E:\My Project\
├── ContentMRS\     ← 主栈（本文）
├── OpenClaw\       ← MCP/飞书/密钥；novel-manager 已政策删除
├── Startup-Hub\    ← 本机守护/计划任务（与 124 运维相邻）
└── （无根级 sub2api；已收进 ContentMRS/sub2api）

连贯性：OpenClaw 不再占正文生成 —— 逻辑收敛。OpenClaw 仍占认知空间（MCP、别的技能），和 ContentMRS 并行但不应再抢「写文章」。

7. 总评：分层是否清晰？是否连贯？是否对齐？

分层清晰度：7/10

• 清楚：真相（DataBase）→ 生成（ContentBase runtime）→ 人（ContentAdmin）→ 发布（fanqie/MyBlog）；Tier-1 / 1.5 / 2 有命名。
• 糊：ContentMRS 文件夹 = 主链 + sub2api + remotion + Coze；MRS vs ContentMRS 路径；fanqie 在 README 与 CONVERGENCE 的 Tier 标注不一致。

逻辑连贯性：8/10（主链）

• 数据流、API 边界、退役 OpenClaw novel、删除重复 UI 的 故事线一致。
• 生成内核（合同 → Evidence → brief → model body → trace）在 ContentBase/README 与实现 同向。

工程对齐度：6/10（全栈）

是否还「离散」？

相对「多套生成器、多套后台」时期：已明显收束。

相对「一个产品、一个文件夹、一次验收全绿」：仍离散，主要体现在：

1. 多 Git 仓 + 卫星目录（物理）
2. Tier-1 与 Tier-1.5 能力分裂（联网/RAG/后台不在主冒烟必过）
3. 发布与生成两条生命周期（有意为之，但未用脚本接起来）
4. 文档/路径/密钥说明 个别条目未跟上 sub2api-novel.env 和 CONVERGENCE

8. 若要「更连贯」的优先顺序（仅建议）

1. 统一命名与路径：project.json 的 runtimeLocation 改为 ContentMRS\...；README 里 fanqie Tier 与 MANIFEST 一致。
2. 跑通 Tier-1.5 最小集：Directus 迁移修掉 → CONTENTADMIN_PUBLIC_URL → 人类只打开 ContentAdmin。
3. 验收合并视图：verify-production 摘要 + 可选 verify-tier2（你已有），避免「主链过了但后台仍不能用」。
4. MANIFEST 显式列出卫星：sub2api（in-tree）、remotion-project（out-of-band），避免 ContentMRS 被当成「全是 Tier-1」。
5. 发布一条 smoke：fanqie dry-run / MyBlog build 进 verify-tier2 或单独 verify-publish.ps1。

一句话：ContentMRS 在 逻辑分层和主链契约上已经连贯、且正在对齐；在 物理布局（多仓+卫星）、Tier-1.5 落地、发布闭环和旧路径文档 上仍显离散。主链是 DataBase → ContentBase → sub2api；人机与深度证据在 ContentAdmin / NocoDB / RAGFlow 层，需要 Tier-1.5 部署完成后才和文档里的「集中态」完全一致。

如果你希望，我可以下一步只做 文档对齐审计（列出所有仍写 MRS\、auth.json、fanqie Tier-1 的文件清单），不改代码。