# 人机协同决策分层设计

> **更新日期**: 2026-04-24
> **适用范围**: AgomTradePro 决策链路、信号审核、持仓管理、AI 解释、人工复盘
> **核心定位**: 系统提供可复现的客观底盘，人负责显式输入判断并承担最终决策。

---

## 1. 设计背景

AgomTradePro 的目标不是把所有使用者训练成同一种投资结论，而是把投资决策中容易混在一起的部分拆开：

- 哪些是事实；
- 哪些是规则；
- 哪些是系统解释；
- 哪些是个人约束；
- 哪些是人的主观判断；
- 哪些是执行后的复盘证据。

如果不做分层，系统容易出现两个问题：

1. **伪客观**：把人的假设藏在配置、阈值或 Prompt 里，看起来像系统结论。
2. **结论趋同**：不同使用者在不同资金约束、风险偏好和认知判断下，被系统推向同一条操作路径。

因此，本系统采用“客观底盘可复现，主观判断可追踪”的设计原则。

---

## 2. 总原则

### 2.1 一句话原则

**同一数据、同一配置、同一模型下，事实和规则结果应当一致；最终投资决策应当允许因个人画像、情景权重和人工判断而不同。**

### 2.2 三条边界

1. **系统不能把主观判断伪装成事实**
   - “PMI 环比回升”是事实。
   - “政策会快速传导到盈利”是判断。
   - “因此我愿意提高权益仓位”是决策。

2. **人不能绕过证据直接覆盖系统**
   - 可以 Override 系统建议。
   - 但必须记录原因、证伪条件和复盘时间。

3. **AI 不能直接成为最终责任主体**
   - AI 可以总结、辩论、提问、生成反方观点。
   - 最终采纳、拒绝、调仓、加仓、减仓必须由用户确认。

---

## 3. 分层总览

| 层级 | 名称 | 主要问题 | 是否应可复现 | 主要责任方 | 典型输出 |
|------|------|----------|--------------|------------|----------|
| L0 | 数据与来源层 | 输入数据从哪里来，质量如何 | 是 | 系统 | Data Snapshot、Data Quality Report |
| L1 | 客观事实层 | 当前发生了什么 | 是 | 系统 | Fact Sheet、Regime、Policy、Pulse |
| L2 | 规则与信号层 | 按既定规则是否触发 | 是 | 系统 | Gate Decision、Signal、Candidate |
| L3 | 解释与情景层 | 这些事实可能意味着什么 | 半可复现 | 系统 + AI + 用户 | Scenario Set、Thesis Draft |
| L4 | 个人约束层 | 这个人适不适合做这笔交易 | 因人而异 | 用户 + 系统 | Investor Profile、Portfolio Constraints |
| L5 | 人工判断层 | 用户最终相信什么、承担什么 | 因人而异 | 用户 | Decision Memo、Approval / Rejection |
| L6 | 执行与复盘层 | 做了什么，后来是否被证伪 | 是 | 用户 + 系统 | Execution Record、Audit Review |

---

## 4. L0 数据与来源层

### 4.1 定义

L0 负责记录所有决策输入的来源、时间、版本和质量状态。它回答的问题是：

> 我们这次判断用的到底是哪一份数据？

### 4.2 包含内容

- 宏观数据：PMI、CPI、PPI、M2、社融等。
- 行情数据：指数、个股、基金、债券、商品价格。
- 政策与事件数据：政策事件、新闻、RSS、热点、情绪。
- 账户数据：持仓、现金、成本、历史交易。
- 模型输入：Alpha 特征、Qlib 推理输入、缓存快照。

### 4.3 设计要求

- 每次生成结论都应记录 `as_of_date`。
- 外部数据必须记录数据源，例如 Tushare、AKShare、Eastmoney。
- 数据质量必须有标记，例如缺失、延迟、异常、使用备用源。
- 不能在本层加入“我觉得这个数据更重要”这类判断。

### 4.4 典型产物

- `DataSnapshot`
- `DataSourceTrace`
- `DataQualityReport`
- `InputHash`

---

## 5. L1 客观事实层

### 5.1 定义

L1 将原始数据转成客观事实和状态。它回答的问题是：

> 当前环境、资产和组合处在什么状态？

### 5.2 包含内容

- Regime 象限：复苏、过热、滞胀、通缩。
- Policy 档位：政策偏紧、偏中性、偏宽松。
- Pulse 状态：增长、通胀、流动性、情绪的战术脉搏。
- 资产事实：估值分位、动量、波动率、成交、回撤。
- 组合事实：仓位、集中度、行业暴露、Beta 暴露、浮盈浮亏。

### 5.3 设计要求

- 同一数据快照下，L1 输出必须一致。
- L1 只描述状态，不直接输出“应该买入”。
- 指标口径必须明确，例如窗口长度、单位、标准化方式。
- 事实和数据质量必须一起展示，避免把低质量数据包装成强结论。

### 5.4 典型产物

- `RegimeState`
- `PolicyLevel`
- `PulseSnapshot`
- `AssetFactSheet`
- `PortfolioFactSheet`

---

## 6. L2 规则与信号层

### 6.1 定义

L2 在 L1 事实基础上应用系统规则。它回答的问题是：

> 按系统事先定义好的规则，这个机会是否出现、是否可行动、是否被证伪？

### 6.2 包含内容

- Beta Gate：资产是否通过宏观环境准入。
- Alpha Trigger：是否出现离散、可证伪的 Alpha 触发。
- Decision Rhythm：是否触发配额、冷却期、频率约束。
- 信号管理：生成、审核、失效、证伪。
- 仓位建议：按规则计算的建议区间，而非最终仓位。

### 6.3 设计要求

- L2 的规则应版本化，不能隐式漂移。
- 每个信号必须包含证伪条件。
- L2 可以给出“通过 / 不通过 / 警告”，但不能替代用户最终确认。
- 系统建议应表达为候选或建议，不应表达为命令。

### 6.4 典型产物

- `GateDecision`
- `AlphaCandidate`
- `InvestmentSignal`
- `PrecheckResult`
- `Recommendation`

---

## 7. L3 解释与情景层

### 7.1 定义

L3 将事实和信号组织成可理解的投资叙事。它回答的问题是：

> 为什么这个信号可能成立？它依赖哪些前提？有哪些反方观点？

### 7.2 包含内容

- 基准、乐观、悲观情景。
- 每个情景的触发条件和失效条件。
- 历史相似环境对比。
- 关键假设列表。
- 反方观点与风险清单。
- AI 生成的解释、摘要、辩论、质询。

### 7.3 设计要求

- L3 不是事实层，必须显式标记为“解释”或“假设”。
- AI 生成内容必须保留来源上下文，例如引用了哪些事实、信号和用户输入。
- 情景概率可以有系统默认值，但用户必须可以调整。
- 解释不能覆盖 L2 的硬约束，例如 Beta Gate 不通过不能被解释成通过。

### 7.4 典型产物

- `ScenarioSet`
- `InvestmentThesisDraft`
- `BearCase`
- `AssumptionList`
- `SensitivityAnalysis`

---

## 8. L4 个人约束层

### 8.1 定义

L4 描述某个用户、账户或组合的个性化约束。它回答的问题是：

> 即使这个机会客观上存在，它是否适合我？

### 8.2 包含内容

- 投资周期：短线、波段、中长期。
- 风险承受：最大回撤、单日波动、杠杆容忍度。
- 仓位约束：单资产上限、行业上限、现金底线。
- 资产偏好：A 股、港股、美股、ETF、基金、债券、商品。
- 禁投范围：行业、主题、个股、杠杆品种。
- 流动性约束：资金使用期限、赎回压力、交易成本。
- 当前持仓：已有风险暴露和相关性。

### 8.3 设计要求

- L4 必须是显式配置，不应散落在代码、Prompt 或临时备注里。
- 用户画像应版本化，便于复盘“当时为什么这样建议”。
- 同一个 L2 信号，在不同 L4 画像下可以得到不同处理。
- L4 不能篡改 L1 事实，只能影响适配性和执行方案。

### 8.4 典型产物

- `InvestorProfile`
- `AccountConstraint`
- `PortfolioConstraint`
- `RiskBudget`
- `RestrictionList`

---

## 9. L5 人工判断层

### 9.1 定义

L5 是用户作出最终判断的位置。它回答的问题是：

> 我最终相信哪个情景？愿意承担多少风险？如果我错了，什么条件说明我错了？

### 9.2 包含内容

- 采纳或拒绝系统信号。
- 调整情景概率。
- 写入个人 Thesis。
- 手动 Override 系统建议。
- 设置复盘时间。
- 明确证伪条件。

### 9.3 Override 规则

允许人工 Override，但必须记录：

| 字段 | 说明 |
|------|------|
| `override_target` | 覆盖的是哪个信号、建议、闸门或仓位 |
| `original_recommendation` | 系统原始建议 |
| `human_decision` | 用户最终决定 |
| `reason` | 为什么覆盖 |
| `assumptions` | 依赖哪些主观假设 |
| `invalidation_conditions` | 什么情况说明判断错了 |
| `review_at` | 何时复盘 |
| `risk_acknowledgement` | 是否确认理解风险 |

### 9.4 设计要求

- 人工判断必须留痕。
- 采纳、拒绝、延后、减仓、加仓都应有理由。
- 系统应主动追问含糊判断，例如“看好”“有机会”“感觉不错”。
- 人工判断不应直接修改历史事实和规则结果。

### 9.5 典型产物

- `DecisionMemo`
- `ApprovalRecord`
- `RejectionRecord`
- `OverrideRecord`
- `ReviewSchedule`

---

## 10. L6 执行与复盘层

### 10.1 定义

L6 记录决策是否落地、如何落地、后续是否被证伪。它回答的问题是：

> 我们实际做了什么？结果如何？当初的判断有没有被市场和数据验证？

### 10.2 包含内容

- 模拟盘执行。
- 账户持仓记录。
- 手动交易记录。
- 证伪条件监控。
- 归因分析。
- 复盘结论。

### 10.3 设计要求

- 执行记录必须关联到原始信号或人工决策。
- 未执行也应记录原因，例如错过价格、风险预算不足、等待确认。
- 复盘必须区分“过程正确但结果亏损”和“过程错误但结果盈利”。
- 系统应持续提醒证伪条件，而不是只在建仓时给建议。

### 10.4 典型产物

- `ExecutionRecord`
- `PositionRecord`
- `InvalidationCheck`
- `AuditReview`
- `AttributionReport`

---

## 11. 决策流程示例

### 11.1 标准流程

```text
L0 数据快照
  -> L1 客观事实
  -> L2 规则信号
  -> L3 系统解释与情景
  -> L4 个人画像与组合约束
  -> L5 人工采纳 / 拒绝 / Override
  -> L6 执行、监控、复盘
```

### 11.2 示例

1. L0：系统记录 2026-04-24 的宏观、行情、账户数据快照。
2. L1：Regime 显示增长改善、通胀回落，Pulse 显示流动性改善。
3. L2：Beta Gate 允许权益资产，Alpha Trigger 给出沪深 300 ETF 候选。
4. L3：系统生成三种情景：
   - 基准：盈利温和修复；
   - 乐观：政策传导加速；
   - 悲观：需求恢复弱于预期。
5. L4：用户账户已有较高权益仓位，单资产上限接近触发。
6. L5：用户认可基准情景，但决定只小幅加仓，并记录“政策传导比历史慢”的主观判断。
7. L6：系统记录模拟盘执行，并在 PMI 回落、成交缩量、回撤扩大时触发复盘提醒。

---

## 12. 产品与模块落地建议

### 12.1 近期可落地

- 在信号审核页增加“人工判断备注”和“证伪条件确认”。
- 在决策提交页显示 L0-L4 摘要，避免用户只看最终按钮。
- 为 Override 增加强制原因字段。
- 在复盘页区分系统原始建议和人工最终决定。

### 12.2 中期可落地

- 新增 `InvestorProfile` 或账户级约束配置。
- 新增情景权重配置：基准、乐观、悲观。
- 新增 Decision Memo 模板。
- 将 AI 解释输出绑定到事实、信号、画像和人工输入。

### 12.3 长期可落地

- 建立个性化决策回测：同一信号在不同用户画像下的表现。
- 建立人工判断质量复盘：哪些 Override 有价值，哪些是情绪化操作。
- 建立“反方观点引擎”：每个强建议都必须生成反例和证伪路径。

---

## 13. 与现有模块的关系

| 分层 | 相关模块 |
|------|----------|
| L0 数据与来源层 | `data_center`, `macro`, `realtime`, `policy`, `sentiment`, `account` |
| L1 客观事实层 | `regime`, `policy`, `pulse`, `equity`, `fund`, `sector`, `asset_analysis` |
| L2 规则与信号层 | `beta_gate`, `alpha_trigger`, `decision_rhythm`, `signal`, `strategy` |
| L3 解释与情景层 | `ai_provider`, `prompt`, `ai_capability`, `terminal`, `agent_runtime` |
| L4 个人约束层 | `account`, `strategy`, `setup_wizard` |
| L5 人工判断层 | `decision_rhythm`, `signal`, `share`, `terminal` |
| L6 执行与复盘层 | `simulated_trading`, `account`, `audit`, `task_monitor`, `events` |

---

## 14. 判断标准

后续新增功能时，可以用以下问题判断它属于哪一层：

1. **它是否描述输入数据？**
   - 是：L0。

2. **它是否描述客观状态？**
   - 是：L1。

3. **它是否按固定规则触发建议或约束？**
   - 是：L2。

4. **它是否在解释、归因、假设或生成情景？**
   - 是：L3。

5. **它是否与某个用户、账户、风险偏好有关？**
   - 是：L4。

6. **它是否代表用户最终选择？**
   - 是：L5。

7. **它是否记录执行、结果或复盘？**
   - 是：L6。

---

## 15. 结论

AgomTradePro 不应追求“所有人得到同一个最终答案”，而应追求：

- 数据事实一致；
- 规则信号一致；
- 系统解释透明；
- 个人约束显式；
- 人工判断留痕；
- 执行结果可复盘。

这样系统既不会退化成纯主观笔记，也不会变成僵硬的统一结论机器。它的价值在于让人的判断更清楚、更可追踪、更难自欺。
