先说结论
这次升级不是“Quant OS 已经达到 80 分”，而是系统第一次拥有了一把能够客观判断何时达到 80 分、并阻止代码自行给自己发证的尺子。Quant OS 已经从
quants-strategies拆成独立项目，标准、架构、运行入口、公开状态页和迁移边界都已建立；当前资格仍是NOT_BASELINE_60和BLOCKED_FROM_LIMITED_LIVE。
这篇文章是 7 月 28 日学习文 的架构与成熟度升级篇。前一篇回答“为什么回测只是一份证词”，这一篇集中回答四个新问题：
- 为什么 Quant OS 必须成为独立项目？
- 80 分和 60 分到底差在哪里？
- 新的三平面架构怎样约束数据、决策、券商和证据？
- 我现在应该怎样亲手运行、观察和验证？
一、先把当前状态说死
截至 2026-07-30，本轮可复核状态如下。
| 项目 | 当前事实 |
|---|---|
| 独立项目 | 已建立并公开 |
| 本机目录 | ~/boat-workspace/Code/quant-os |
| 远端仓库 | git.gomars.fun/boat/quant-os |
| 公开状态页 | 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 回答“数据何时可知、决策如何冻结、怎样跨平台执行、如何风控、怎样留下证据、什么时候有资格动用资金”。
一个操作系统不应该从属于某一个策略。它必须能承载多个策略，也必须在任何策略试图绕过数据、风险、执行或证据边界时拒绝继续。
现在的责任边界是：
quants-strategies
策略、实验假设、StrategySpec
quant-os
数据合同、研究流水线、组合与风险、执行合同、平台适配、证据与发布
Boat Obsidian
学习文章、验证手册、决策记录
OB 只保存文档，不保存源码、原始数据、回测 artifact、账号、密码、Token、Cookie、QMT userdata 或券商文件。代码以独立 Git 仓为准，本机数据以被 Git 忽略的资产目录为准。
拆分之后获得了四个直接收益：
- Quant OS 有自己的版本、CI、发布、回滚和 Issue 边界；
- 状态页的每个能力和缺口都能回指同一个项目；
quant-os/quant_os成为长期入口，quant60只作为 V1 兼容内核保留至少两个发布周期；- 策略以后通过版本化 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 都不能用软项补偿。
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 上隔离。核心仓库则继续保持一个可审计的决策身份和证据链。
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。
另外还有四条架构硬边界：
- adapter 通过 port 向内实现供应商和平台 SDK，core 不 import
jqdatasdk、qlib、xtquant或 hosted 全局 API； ReadBrokerPort与TradeBrokerPort分离，能查询不等于能下单；composition是唯一能够同时装配 application/control 和 adapters 的位置；- 新 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 | 公开脱敏快照，不是实盘监控 |
当前还有一个最重要的技术债：存在两个上游决策权威。
真实 provider snapshot → portable-momentum compatibility path
synthetic research → Ridge ModelBundle / TargetPackage path
最终必须统一为：
授权且不可变的真实 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：
d18774756d56eb89239643bd91792feb5e1c7b5ab8fd804bf52f6d429c448e91
这三类目录全部被 Git 忽略。旧的约 941 MB .venv-qlib312 没有搬进新项目，因为虚拟环境包含旧绝对路径，目录移动不等于环境可复现；它随迁移备份保留，新仓应按照固定 requirements 重建。
Tushare 早期 provider 和既有 Qlib/MLflow 证据现在可以继续用于技术复现。但数据仍缺复权、真实指数、历史成分、ST、停牌和涨跌停等生产要素，所以 production_ready=false、investment_value_claim=false 的结论不变。详细盘点见 Tushare 与 Qlib 数据记录。
九、第一遍上手：先用十分钟看懂系统状态
新机器从独立仓开始：
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 .
先运行四个体检命令：
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 时可以使用：
PYTHONPATH=src:. python -m quant_os doctor
十、第二遍上手：跑完整本地闭环
make local
它会运行架构检查、标准校验与评估、315 项测试、平台 bundle、synthetic execution/research、manifest 验证、mock parity、secret scan、状态生成和 Colab notebook 本地执行。
完成后重点看：
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
不要先看收益，先回答五个问题：
data_version、model、config 和 source hash 是否都被冻结？signal_as_of和next_session是否明确区分？- TargetPackage 为什么是权重，而不是账户股数？
- 哪些结果属于 synthetic，哪些属于真实平台？
- 任意 artifact 被修改后，verifier 是否会拒绝？
十一、第三遍上手：按 Qlib → 聚宽 → QMT 的顺序
1. 验证本机资产
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：
PYTHONPATH=src:. python tools/tushare_qlib.py verify \
data/qlib/tushare-early-1990-1993-v4
再运行已有早期数据的技术回测：
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
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
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 后再启用下一层
正确顺序是：
- QMT built-in 历史回测；
- qmttools 回测与逐层导出；
- XtTrader 只读 contract probe；
- broker snapshot 与 shadow plan；
- callback、拒单、部分成交、撤单、重连、重启和跨日对账；
- Baseline 20 日只读 shadow；
- 同一冻结候选继续累计到 Production 60 日；
- 完成券商程序化交易报告确认后，才讨论 TradeBrokerPort。
账号、userdata 路径和账户标识只通过本地 secret source 或无回显登录注入。当前项目没有任何面向 operator 的实盘下单命令，这是有意的安全边界。
十二、从现在到 80 的正确施工顺序
- 消除双决策权威，把授权真实 PIT snapshot 接入 Ridge 主链；
- 建立 golden vectors 和 V1/V2 schema registry；
- 冻结真实长样本 OOS、容量、成本、风险和 model registry 证据；
- 完成本地与聚宽多期同输入的逐层 difference ledger；
- 取得真实 QMT，先做只读合同探针和 Baseline 20 日 shadow；
- 让同一冻结候选累计 60 日 Production shadow，并完成每日 100% 对账和恢复演练；
- 通过全部 60 Gate、券商确认、P0/P1 清零和 E3 pre-canary 授权；
- 在 hard caps 内完成至少 10 个交易日 E4 canary，再接受最终 promotion attestation。
任何时候出现“代码已经能下单，但数据、规则、证据或券商确认还没到”的情况，正确行为都是让系统保持停机。
十三、你怎样判断这一轮工作是否真的完成
可以按下面的清单逐项验收：
- [ ] 独立仓可以匿名 clone；
- [ ]
origin/master与本地 HEAD 相同； - [ ]
make local完成，且qualified=false； - [ ] 4,281 个数据/证据文件的 inventory hash 一致；
- [ ] 旧仓
quant-os/只有迁移指针； - [ ] Cash Layer 的本地未提交改动仍然保留；
- [ ] 新状态页 返回 200；
- [ ] 旧 Quant OS 地址返回 302 到新地址；
- [ ] 状态页明确显示 0/100、broker disabled 和无投资价值声明；
- [ ] OB 中只有文章，不包含源码或秘密；
- [ ] Pages 公开文章可匿名阅读。
延伸阅读
最后再强调一次
这份 80 分标准是 Quant OS 对“个人自有资金、受限生产验证”的内部工程门槛，不是监管机关评分，也不是法律意见。80 分不证明有 Alpha，更不授权管理第三方资金。