---
title: "Quant OS 从 60 到 80：独立项目、三平面新架构与上手路线（2026-07-30）"
canonical: "https://gomars.fun/pages/7/"
updated: "2026-07-30T15:31:07Z"
---

> **先说结论**
>
> 这次升级不是“Quant OS 已经达到 80 分”，而是系统第一次拥有了一把能够客观判断何时达到 80 分、并阻止代码自行给自己发证的尺子。Quant OS 已经从 `quants-strategies` 拆成独立项目，标准、架构、运行入口、公开状态页和迁移边界都已建立；当前资格仍是 `NOT_BASELINE_60` 和 `BLOCKED_FROM_LIMITED_LIVE`。

这篇文章是 [7 月 28 日学习文](https://gomars.fun/pages/6/) 的架构与成熟度升级篇。前一篇回答“为什么回测只是一份证词”，这一篇集中回答四个新问题：

1. 为什么 Quant OS 必须成为独立项目？
2. 80 分和 60 分到底差在哪里？
3. 新的三平面架构怎样约束数据、决策、券商和证据？
4. 我现在应该怎样亲手运行、观察和验证？

## 一、先把当前状态说死

截至 2026-07-30，本轮可复核状态如下。

| 项目 | 当前事实 |
| --- | --- |
| 独立项目 | 已建立并公开 |
| 本机目录 | `~/boat-workspace/Code/quant-os` |
| 远端仓库 | [git.gomars.fun/boat/quant-os](https://git.gomars.fun/boat/quant-os) |
| 公开状态页 | [gomars.fun/quant-os/status/](https://gomars.fun/quant-os/status/) |
| 代码快照 | `f81c116`，本地、远端与状态发布一致 |
| Baseline 60 | `NOT_BASELINE_60`，G1—G10 为 0/10 |
| Production 80 | `BLOCKED_FROM_LIMITED_LIVE`，0/100 |
| 生产 Hard Gate | 21 项尚未取得规定等级的外部证据 |
| 领域最低分 | 七个领域均未取得生产证据 |
| 券商写权限 | `disabled` |
| 投资价值声明 | `false` |
| 工程回归 | 315 tests 通过，6 项可选 runtime 测试跳过 |
| 实际支持市场 | 沪深；北交所 `excluded / fail closed` |

这里最容易误读的是“315 项测试通过”和“80 分为 0”为什么能同时成立。

测试证明代码在受控环境中符合合同，属于 E1 本地工程证据；80 分要求完整 PIT、真实平台、真实 QMT、券商确认、持续 shadow、生产运维和受限资金 canary 等 E2—E4 证据。代码数量、测试数量和文档数量都不能兑换成生产资格分。

公开状态页也不是实时交易健康页。它是经过脱敏、随代码构建的静态验收快照，不包含账号、持仓、成交、行情数据或凭据。

## 二、为什么要从 strategies 中独立出来

过去 Quant OS 位于 `quants-strategies/quant-os`。目录看起来方便，却混淆了两个生命周期：

- Strategy 回答“用什么特征、模型和组合逻辑产生决策”；
- Quant OS 回答“数据何时可知、决策如何冻结、怎样跨平台执行、如何风控、怎样留下证据、什么时候有资格动用资金”。

一个操作系统不应该从属于某一个策略。它必须能承载多个策略，也必须在任何策略试图绕过数据、风险、执行或证据边界时拒绝继续。

现在的责任边界是：

```text
quants-strategies
  策略、实验假设、StrategySpec

quant-os
  数据合同、研究流水线、组合与风险、执行合同、平台适配、证据与发布

Boat Obsidian
  学习文章、验证手册、决策记录
```

OB 只保存文档，不保存源码、原始数据、回测 artifact、账号、密码、Token、Cookie、QMT userdata 或券商文件。代码以独立 Git 仓为准，本机数据以被 Git 忽略的资产目录为准。

拆分之后获得了四个直接收益：

1. Quant OS 有自己的版本、CI、发布、回滚和 Issue 边界；
2. 状态页的每个能力和缺口都能回指同一个项目；
3. `quant-os` / `quant_os` 成为长期入口，`quant60` 只作为 V1 兼容内核保留至少两个发布周期；
4. 策略以后通过版本化 port 接入，不能自行读取券商秘密、调用交易端口或修改审计证据。

旧目录已经只保留迁移指针；迁移前完整目录和旧虚拟环境仍在本机保留为可恢复备份，没有直接删除。

## 三、60 到 80，不是“再多做 20 分功能”

一句话概括：

- 60 分回答：同一策略研究链能否在受控数据、跨引擎和只读 shadow 中被运行、重放和审计？
- 80 分回答：同一个已经报告、版本冻结的系统，是否在真实券商链路下完成了受限资金验证，而且故障时会自动停机？

| 责任 | Baseline 60 | Production 80 |
| --- | --- | --- |
| 系统定位 | research-to-shadow baseline | 个人自有资金的受限生产验证 |
| 资本权限 | 无资金发送权 | 仅在授权 hard caps 内的小额 canary |
| 数据 | PIT 合同、不可变快照、真实抽样重放 | 完整生产 PIT、许可、SLO、质量告警、恢复和回填 |
| 研究 | purge/embargo OOS、冻结模型、成本后结果 | 再加容量、registry、drift、选择治理和 challenger |
| 跨引擎 | local/JQ/QMT 同输入层级 parity | L1—L5 strict peer、订单/成交 difference ledger |
| QMT | bundle、只读入口、至少 20 个交易日 Baseline shadow | 同一冻结候选至少 60 个交易日真实 QMT shadow |
| 对账 | 影子计划与 broker snapshot 有合同 | 每个交易日现金、持仓、可卖、订单、成交 100% 对账 |
| 实盘 | 明确禁止 | 独立授权后至少 10 个交易日受限 E4 canary |
| 运维 | runbook、停机条件和恢复设计 | 真实监控、P0/P1 清零、RPO/RTO 与故障演练 |
| 合规 | 知道需要程序化交易报告和券商确认 | 已确认，且实际账户、策略、流量和软件版本与报告一致 |
| 结果标签 | `BASELINE_60_VERIFIED` | `LIMITED_LIVE_VERIFIED` |

80 以 60 全部通过为前置。它仍不代表有投资收益、获得机构牌照、可以管理第三方资金或可以向他人提供代客交易。系统成熟度、策略证据和实际收益是三套不同指标，不能互相替代。

## 四、真正的 80 分是一台状态机

Production 80 分为七个领域、25 个控制项。21 个生产 Hard Gate 的权重正好合计 80；其余 20 分描述数据冗余、champion/challenger、真实 TCA 和未来治理等成熟度余量。任一 Hard Gate 都不能用软项补偿。

```mermaid
flowchart LR
    A["NOT_BASELINE_60"] -->|"G1—G10 全部通过"| B["BASELINE_60_VERIFIED"]
    B -->|"20 个 Hard Gate + 至少 77 分<br/>真实 QMT、60 日 shadow、券商确认"| C["PRE_CANARY_AUTHORIZED"]
    C -->|"授权仍有效"| D["CANARY_RUNNING"]
    D -->|"至少 10 个交易日<br/>21 个 Hard Gate + 至少 80 分"| E["LIMITED_LIVE_VERIFIED"]
    C -. "到期或越权" .-> F["FAIL CLOSED"]
    D -. "breach" .-> F
```

为什么中间需要 77 分，而不是从 60 直接开始小资金？

因为 canary 本身就是第 21 个 Hard Gate。在还没有发生受限资金交易时，系统不可能预先拥有它的 E4 观察证据。于是标准只在 `D6-CANARY` 这一项上建立受控入口：其余 20 个 Hard Gate 全部通过、至少 77 分后，由独立的 E3 authority 签发 pre-canary 授权。

授权必须冻结并绑定：

- candidate、release、model、dataset、账户 pseudonym 和 material-change epoch；
- 有效期；
- 最大资本与 gross notional；
- 标的白名单；
- 每秒、每日“申报 + 撤单”流量；
- breach 后的停机条件；
- 禁止自动扩容。

完成 canary 后，E4 claim 必须反向引用这份授权，并报告真实最大资本、notional、标的集合、流量峰值，以及每个 breach 是否关联到明确的 fail-closed stop event。授权过期后不能开始或继续新的 canary；如果历史 canary 已经在有效期内合法完成，之后仍可复核那段历史证据。

当前仓库没有 production trust provider 和 issuer registry。因此，手工把 JSON 改成 `passed` 不会生效；测试 verifier 最多只能产生 `TEST_ONLY_*` 结果，不能给系统签发正式 60/80 资格。

## 五、证据不是文件存在，而是可信程度

新的标准把证据分成五层：

| 等级 | 例子 | 可以证明 | 不能证明 |
| --- | --- | --- | --- |
| E0 | 设计文档、源文件 | 意图和边界 | 代码可运行 |
| E1 | 单测、synthetic、fixture、mock | 本地算法和故障路径成立 | 真实数据、平台或券商行为 |
| E2 | 授权真实数据、冻结 OOS、外部权威原始材料 | 数据/研究可重放或来源可核验 | 真实券商执行 |
| E3 | 真实平台/QMT shadow、生产控制观察、独立 canary 授权 | 平台和控制链在真实环境中工作 | 已发生受限资金行为 |
| E4 | 有 hard caps 的真实资金 canary | 小范围真实生产行为 | 自动扩容、机构化或未来收益 |

Evidence plane 的关键作用，就是阻止“代码给自己写一份通过报告”。每个正向 claim 都必须绑定同一 subject、标准 hash、profile hash、证据来源 hash 和可信 verifier；最终晋级还要有绑定整个 assessment hash 的 attestation。

## 六、三平面新架构

Quant OS 选择“严格边界的模块化单体 + 专有 runtime 隔离”，而不是微服务。

个人系统不需要承担网络调用、服务发现和分布式一致性的成本；但 JQData、Qlib、聚宽、QMT 和 XtTrader 的 Python/SDK 环境互不兼容，必须在 runtime 上隔离。核心仓库则继续保持一个可审计的决策身份和证据链。

```mermaid
flowchart LR
    R["Composition root<br/>CLI / runtime wiring"] --> C
    R --> A
    C["Control plane<br/>RunSpec / orchestration / release policy"] --> U["Application use cases"]
    U --> D["Data plane<br/>PIT → research → portfolio → execution intent"]
    A["Adapters / proprietary runtimes<br/>JQData / Qlib / JoinQuant / QMT"] --> P["Ports"]
    D --> P
    C --> E
    D --> E
    A --> E
    E["Evidence plane<br/>manifest / claim / parity / maturity"] --> V["Verifier / promotion policy"]
```

三平面的责任很严格：

- Control plane 只选择 RunSpec、编排 use case 和判断发布，不计算 Alpha，也不直接调用券商 SDK；
- Data plane 只消费不可变输入，产生模型、权重和 execution intent，不读取网页分数；
- Evidence plane 只记录已经发生的事实，不能回头修改 target、order 或 broker fact。

另外还有四条架构硬边界：

1. adapter 通过 port 向内实现供应商和平台 SDK，core 不 import `jqdatasdk`、`qlib`、`xtquant` 或 hosted 全局 API；
2. `ReadBrokerPort` 与 `TradeBrokerPort` 分离，能查询不等于能下单；
3. `composition` 是唯一能够同时装配 application/control 和 adapters 的位置；
4. 新 namespace 由 AST checker 检查依赖方向，也禁止新层绕回根级 legacy 模块。

目前要诚实承认：checker 只覆盖 `src/quant_os/` 的 18 个新文件；`src/quant60`、根级 adapters、platforms 和 tools 仍有 55 个 Python 文件、约 26,476 行位于 checker 之外。准确说法是“新边界和迁移路线已经建立”，不是“26k 行旧内核已经完成重写”。

## 七、现在真正跑通了什么

| 路径 | 当前能力 | 证据边界 |
| --- | --- | --- |
| 本地 core | synthetic execution、五层 research、ledger、manifest、ModelBundle、TargetPackage、重放 | E1；不证明真实 Alpha |
| Tushare → Qlib | completed 文件校验、不可变 provider、native momentum、Alpha158/LightGBM fixture、MLflow/Recorder 产物 | 技术链可运行；镜像不完整，不得作为生产 PIT |
| Colab | 默认 notebook 可在本地执行，独立仓可在 Colab clone | 默认 smoke 不需要账号；真实 JQData/Qlib 需要授权与独立环境 |
| 聚宽 | 单文件 bundle、真实 hosted 动量 smoke、一次 synthetic TargetPackage execution consumer 观察 | 只证明对应 runtime 与 execution 边界，不证明上游四层、G9、60 或 80 |
| QMT/XtTrader | bundle、fake contract、只读 shadow 和对账框架 | 没有真实账号、回调、重连、跨日或券商证据 |
| 机器成熟度 | 80 分 profile、hash 绑定、77→canary→80 状态机、fail-closed evaluator | 能诚实给出负向结论；生产信任根仍待实现 |
| 静态状态页 | 独立 URL、不可变 release、原子切换、旧地址 302 | 公开脱敏快照，不是实盘监控 |

当前还有一个最重要的技术债：存在两个上游决策权威。

```text
真实 provider snapshot → portable-momentum compatibility path
synthetic research      → Ridge ModelBundle / TargetPackage path
```

最终必须统一为：

```text
授权且不可变的真实 PIT snapshot
→ 冻结 feature / model
→ portfolio + independent post-risk
→ TargetPackage（权重，不含账户股数）
→ JoinQuant / QMT 薄执行消费者
```

平台不再现场重算 Alpha。TargetPackage 只保存权重，是因为真实股数取决于执行时的账户净值、已有持仓、可卖量和价格；这些事实应在券商边界绑定，而不是由研究回测伪造。

## 八、本地数据资产已经怎样迁移

迁移前后对 `data/`、`artifacts/`、`mlruns/` 做了逐文件 SHA-256 清单比对：

| 目录 | 文件数 | 内容字节 |
| --- | ---: | ---: |
| `data/` | 3,904 | 4,411,104 |
| `artifacts/` | 161 | 2,120,720 |
| `mlruns/` | 216 | 1,740,779 |
| **合计** | **4,281** | **8,272,603** |

清单 hash：

```text
d18774756d56eb89239643bd91792feb5e1c7b5ab8fd804bf52f6d429c448e91
```

这三类目录全部被 Git 忽略。旧的约 941 MB `.venv-qlib312` 没有搬进新项目，因为虚拟环境包含旧绝对路径，目录移动不等于环境可复现；它随迁移备份保留，新仓应按照固定 requirements 重建。

Tushare 早期 provider 和既有 Qlib/MLflow 证据现在可以继续用于技术复现。但数据仍缺复权、真实指数、历史成分、ST、停牌和涨跌停等生产要素，所以 `production_ready=false`、`investment_value_claim=false` 的结论不变。详细盘点见 [Tushare 与 Qlib 数据记录](https://gomars.fun/pages/8/)。

## 九、第一遍上手：先用十分钟看懂系统状态

新机器从独立仓开始：

```bash
git clone https://git.gomars.fun/boat/quant-os.git
cd quant-os

python3.12 -m venv .venv-core
source .venv-core/bin/activate
python -m pip install -e .
```

先运行四个体检命令：

```bash
quant-os doctor
quant-os architecture check
quant-os standard validate
quant-os standard evaluate
```

应该看到：

- `doctor.ok = true`：工程入口和新 namespace 边界有效；
- `architecture.violations = []`：18 个新文件没有越层；
- `standard evaluate.ok = true`：评估过程有效；
- `qualified = false`、`effective_score = 0`：这是当前正确答案。

没有 editable install 时可以使用：

```bash
PYTHONPATH=src:. python -m quant_os doctor
```

## 十、第二遍上手：跑完整本地闭环

```bash
make local
```

它会运行架构检查、标准校验与评估、315 项测试、平台 bundle、synthetic execution/research、manifest 验证、mock parity、secret scan、状态生成和 Colab notebook 本地执行。

完成后重点看：

```text
artifacts/local-smoke/manifest.json
artifacts/local-smoke/events.jsonl
artifacts/research-smoke/model_bundle.json
artifacts/research-smoke/target_package.json
artifacts/research-smoke/manifest.json
```

不要先看收益，先回答五个问题：

1. `data_version`、model、config 和 source hash 是否都被冻结？
2. `signal_as_of` 和 `next_session` 是否明确区分？
3. TargetPackage 为什么是权重，而不是账户股数？
4. 哪些结果属于 synthetic，哪些属于真实平台？
5. 任意 artifact 被修改后，verifier 是否会拒绝？

## 十一、第三遍上手：按 Qlib → 聚宽 → QMT 的顺序

### 1. 验证本机资产

```bash
python tools/inventory_local_assets.py . \
  --include data \
  --include artifacts \
  --include mlruns \
  --output /tmp/quant-os-local-assets.json
```

在独立的 Python 3.12 Qlib 环境安装 `requirements/research-py312.txt` 后，可以验证现有 provider：

```bash
PYTHONPATH=src:. python tools/tushare_qlib.py verify \
  data/qlib/tushare-early-1990-1993-v4
```

再运行已有早期数据的技术回测：

```bash
PYTHONHASHSEED=0 PYTHONPATH=src:. python -m platforms.qlib_runner \
  --provider-uri data/qlib/tushare-early-1990-1993-v4 \
  --market tushare_a \
  --benchmark SH999999 \
  --start 1992-01-02 \
  --end 1993-10-28 \
  --feature-start 1991-01-02 \
  --lookback 20 \
  --topk 10 \
  --n-drop 2 \
  --rebalance weekly \
  --output-json artifacts/tushare-qlib-recheck.json
```

这次运行只验证数据桥、Qlib runtime 和重放，不解释收益。Qlib 是研究引擎，不是原始数据仓库，也不是券商 OMS；在当前 candidate 中，它只参加声明层级的比较。

### 2. 本地执行 Colab notebook

```bash
python tools/run_colab_notebook.py notebooks/quant_os_colab.ipynb
python tools/run_colab_notebook.py notebooks/quant_os_colab.ipynb --execute
```

默认 cell 不需要账号。真正放到 Colab 时，可以直接 clone 独立仓；只上传供应商许可范围内的脱敏研究数据，绝不上传券商凭据、账户号、持仓、成交或 QMT userdata。

### 3. 生成聚宽 bundle

```bash
python tools/bundle_platforms.py

python tools/bundle_platforms.py \
  --target-package artifacts/research-smoke/target_package.json \
  --output-dir dist/target-package
```

上传 `dist/target-package/joinquant_strategy.py` 后，需要保留平台参数、日志、订单、成交和输入 hash。聚宽账号只在实际运行时登录，不写进代码、OB 或 artifact。

### 4. 等取得真实 QMT 后再启用下一层

正确顺序是：

1. QMT built-in 历史回测；
2. qmttools 回测与逐层导出；
3. XtTrader 只读 contract probe；
4. broker snapshot 与 shadow plan；
5. callback、拒单、部分成交、撤单、重连、重启和跨日对账；
6. Baseline 20 日只读 shadow；
7. 同一冻结候选继续累计到 Production 60 日；
8. 完成券商程序化交易报告确认后，才讨论 TradeBrokerPort。

账号、userdata 路径和账户标识只通过本地 secret source 或无回显登录注入。当前项目没有任何面向 operator 的实盘下单命令，这是有意的安全边界。

## 十二、从现在到 80 的正确施工顺序

1. 消除双决策权威，把授权真实 PIT snapshot 接入 Ridge 主链；
2. 建立 golden vectors 和 V1/V2 schema registry；
3. 冻结真实长样本 OOS、容量、成本、风险和 model registry 证据；
4. 完成本地与聚宽多期同输入的逐层 difference ledger；
5. 取得真实 QMT，先做只读合同探针和 Baseline 20 日 shadow；
6. 让同一冻结候选累计 60 日 Production shadow，并完成每日 100% 对账和恢复演练；
7. 通过全部 60 Gate、券商确认、P0/P1 清零和 E3 pre-canary 授权；
8. 在 hard caps 内完成至少 10 个交易日 E4 canary，再接受最终 promotion attestation。

任何时候出现“代码已经能下单，但数据、规则、证据或券商确认还没到”的情况，正确行为都是让系统保持停机。

## 十三、你怎样判断这一轮工作是否真的完成

可以按下面的清单逐项验收：

- [ ] 独立仓可以匿名 clone；
- [ ] `origin/master` 与本地 HEAD 相同；
- [ ] `make local` 完成，且 `qualified=false`；
- [ ] 4,281 个数据/证据文件的 inventory hash 一致；
- [ ] 旧仓 `quant-os/` 只有迁移指针；
- [ ] Cash Layer 的本地未提交改动仍然保留；
- [ ] [新状态页](https://gomars.fun/quant-os/status/) 返回 200；
- [ ] 旧 Quant OS 地址返回 302 到新地址；
- [ ] 状态页明确显示 0/100、broker disabled 和无投资价值声明；
- [ ] OB 中只有文章，不包含源码或秘密；
- [ ] Pages 公开文章可匿名阅读。

## 延伸阅读

- [Production 80 机器标准](https://git.gomars.fun/boat/quant-os/src/branch/master/docs/standards/QUANT_OS_80_STANDARD.md)
- [Baseline 60 与 Production 80 边界](https://git.gomars.fun/boat/quant-os/src/branch/master/docs/standards/BASELINE_60_VS_PRODUCTION_80.md)
- [三平面目标架构](https://git.gomars.fun/boat/quant-os/src/branch/master/docs/architecture/ARCHITECTURE_80.md)
- [新架构上手手册](https://git.gomars.fun/boat/quant-os/src/branch/master/docs/getting-started/GETTING_STARTED_80.md)
- [独立仓迁移记录](https://git.gomars.fun/boat/quant-os/src/branch/master/MIGRATION.md)

> **最后再强调一次**
>
> 这份 80 分标准是 Quant OS 对“个人自有资金、受限生产验证”的内部工程门槛，不是监管机关评分，也不是法律意见。80 分不证明有 Alpha，更不授权管理第三方资金。