Deep Thought: 实现架构与工程设计
本文档定义 Deep Thought 系统的三层实现架构：代码层（SOP 固化）、Agent 层（认知设计）、人机界面层（人工介入），以及系统长期运行必须关注的核心问题。
一、核心原则
代码做确定性的事，Agent 做判断性的事，人做战略性的事。
可靠性要求: 代码 > Agent > 人
灵活性要求: 人 > Agent > 代码
执行频率: 代码: 秒/分 Agent: 小时/天 人: 周/月一旦搞混这三层——比如让 Agent 做本该代码做的数据清洗，系统就会不稳定；让人做本该 Agent 做的叙事分析，系统就不可扩展。
二、代码层（SOP 固化）
这些必须用代码写死，不能交给 LLM，否则系统不可靠。
2.1 数据管道（Data Pipeline）
python
# 确定性操作，必须代码化
- API 认证和连接管理（token 刷新、重连、限流处理）
- 数据格式标准化（不同源的时间戳对齐、单位统一）
- 数据质量校验（缺失值检测、异常值标记、数据源故障降级）
- 存储写入（时序数据库 / 向量数据库）
- 增量更新逻辑（避免重复拉取，保证幂等性）为什么不能交给 Agent：数据管道一旦出错，下游所有分析全部垃圾化。API 超时、格式变更、数据缺失——这些情况必须有确定性的错误处理和降级策略，LLM 的不确定性在这里是致命的。
2.2 指标计算引擎
python
# 数学计算必须代码化，不能让 LLM 算
- 收益率曲线斜率（2s10s, 3m10y）
- 利差计算（IG spread, HY spread）
- Z-score / 百分位（当前值相对于历史的位置）
- 移动平均 / 动量 / 波动率
- 资金费率统计（均值、极值、趋势）
- Cross-asset 相关性矩阵为什么不能交给 Agent：你不会想让 LLM 去算 2s10s 利差——它可能算错，而且每次调用都有随机性。指标计算必须是确定性的、可复现的、可回测的。
2.3 状态持久化和记忆管理
python
# 数据结构和存储逻辑必须代码化
- 叙事图谱的 CRUD 操作（创建/读取/更新/删除叙事节点和边）
- 判断历史的写入和查询
- Persona 权重的更新公式（基于历史准确率的贝叶斯更新）
- 数据过期和清理策略
- 快照和回滚机制（系统状态可恢复）2.4 调度和监控
python
# 运行时基础设施
- Cron 调度（定时触发数据采集、分析任务）
- 任务队列（重试、超时、优先级）
- 健康检查（API 可用性、数据新鲜度、Agent 响应时间）
- 告警机制（数据源故障、Agent 异常、错配信号触发）
- 日志和审计（每次判断的完整记录，可追溯）2.5 执行和风控
python
# 如果系统涉及实际交易
- 订单执行逻辑（限价单、止损单、仓位管理）
- 风控规则（单笔最大仓位、总敞口限制、回撤熔断）
- 资金管理（Kelly 公式的代码实现，不让 LLM 决定仓位大小）
- 执行记录和绩效归因代码层总结
┌─────────────────────────────────────────────┐
│ 代码层 (SOP) │
│ │
│ 数据管道 → 指标计算 → 状态存储 → 调度监控 │
│ │
│ 原则: 确定性、可复现、可测试、可回测 │
│ 失败模式: 代码 bug → 可以修 │
│ 不允许: 任何 LLM 随机性进入这些管道 │
└─────────────────────────────────────────────┘三、Agent / Skill / Prompt 层
系统的"认知核心"，需要精心设计但不能写死逻辑。
3.1 Prompt 分层架构
System Prompt（不可变）
↓ 定义 persona 的世界观、分析框架、输出格式
↓ 类比：宪法，几乎不改
Analysis Template（可调优）
↓ 定义分析步骤、推理链、检查清单
↓ 类比：法律，偶尔修订
Dynamic Context（每次变化）
↓ 当前叙事状态、数据快照、历史判断
↓ 类比：案情事实，每次都不同关键设计：System Prompt 用代码写死，Analysis Template 存在配置文件里可热更新，Dynamic Context 由代码层组装后注入。
3.2 Persona Skill 设计
每个 Persona 是一个 Skill，包含：
persona_skill/
├── system_prompt.md # 核心世界观（代码锁死，修改需人工审批）
├── analysis_framework.md # 分析框架（可调优，修改需回测验证）
├── scoring_rubric.md # 打分标准（可进化，由元学习模块调整）
└── metadata.json # 准确率、权重、擅长场景Persona 进化机制：
不是让 Persona 自己改自己的 prompt（会导致退化）
而是:
1. 代码层记录每次判断 vs 实际结果
2. 元学习模块分析哪些 Persona 在什么场景下准确率高
3. 调整 ensemble 权重（代码化）
4. 如果某个 Persona 连续表现差 → 人工审查其 prompt 是否过时3.3 叙事分析 Agent
python
# 这部分需要 LLM，但要结构化约束
任务:
- 从新闻中提取叙事命题（自由度高，必须用 LLM）
- 情绪判断（自由度中，LLM + 规则结合）
- 叙事分类（自由度低，可用 few-shot 固化）
输出约束:
- 必须输出 JSON，字段类型代码校验
- 情绪打分范围 [-1, 1]
- 叙事强度范围 [0, 1]
- 不允许自由文本输出进入下游系统3.4 合成分析 Agent
最需要 LLM 能力的部分：
输入: 叙事状态 + 数据快照 + 各 Persona 独立判断
任务:
- 识别矛盾点（叙事 vs 数据、Persona vs Persona）
- 评估每个矛盾的严重程度
- 推演可能的演化路径
- 输出 regime 判断 + 置信度 + 情景分析
关键约束:
- 必须引用具体的叙事和数据来支撑判断（防止幻觉）
- 置信度校准：长期来看，标记为 70% 置信度的判断应该 70% 正确
- 必须输出"什么证据会让我改变判断"（可证伪性）3.5 元学习 Agent（周期性运行）
频率: 每周/每月
任务:
- 回顾本周期所有判断 vs 实际结果
- 分析哪些 Persona 在什么 regime 下表现好
- 分析哪些叙事类型容易误判
- 输出优化建议（但不自动执行，提交人工审批）
这是唯一允许"自我审视"的 Agent
但它的输出是建议，不是指令——修改权在人Agent 层总结
┌─────────────────────────────────────────────┐
│ Agent / Skill / Prompt 层 │
│ │
│ 叙事分析 → Persona 辩论 → 合成判断 │
│ │
│ 原则: 结构化输入/输出，有约束的自由度 │
│ 失败模式: 幻觉/偏见 → 通过约束+人工审查控制 │
│ 进化方式: 权重自动调，Prompt 人工审 │
└─────────────────────────────────────────────┘四、人机界面层（人工介入点）
人不参与日常运行，但在关键节点必须介入。
4.1 战略层介入（低频，高影响）
| 介入点 | 频率 | 原因 |
|---|---|---|
| 新增/删除 Persona | 季度 | 市场范式变化时需要新的分析视角 |
| 修改 System Prompt | 季度 | 世界观框架需要跟随市场演变 |
| 调整风控参数 | 月度 | 仓位限制、回撤阈值需要根据市场环境调整 |
| 审批元学习建议 | 月度 | 防止系统自我强化偏见 |
4.2 监督层介入（中频，中影响）
| 介入点 | 频率 | 原因 |
|---|---|---|
| 高置信度信号确认 | 事件触发 | 系统给出极端判断时，需要人确认后才执行 |
| 新叙事注册确认 | 事件触发 | 候选新叙事需要人工确认后才正式纳入追踪 |
| 异常检测审查 | 日度 | 数据异常、Agent 输出异常需要人工判断是信号还是噪音 |
4.3 学习层介入（中频，中影响）
| 介入点 | 频率 | 原因 |
|---|---|---|
| 错误复盘 | 周度 | 系统判断错误时，人工分析原因并记录到记忆系统 |
| 市场范式变化识别 | 事件触发 | 当市场结构发生根本变化时，需要人工调整系统假设 |
4.4 不需要人工介入的部分
这些必须全自动，人工介入反而会引入延迟和偏见：
- 数据采集和清洗
- 指标计算
- 叙事提取和情绪打分（结构化输出）
- Persona 独立分析
- ensemble 权重计算
- 错配评分
- 常规信号生成五、长期运行的核心问题
5.1 过拟合陷阱
最大风险: 系统在历史数据上表现很好，在未来失效
原因:
- Persona 权重过度拟合过去的准确率
- 叙事模式库过于依赖历史案例
- 错配阈值根据历史最优设定
对策:
- 权重更新使用贝叶斯方法，设置先验（不完全相信历史）
- 定期用 walk-forward 验证（只用过去数据训练，用未来数据验证）
- 保留"无知先验"——新 Persona 初始权重不能太低
- 关注 regime 变化时的衰减：市场结构变了，历史权重就贬值了5.2 叙事污染（Narrative Poisoning）
风险: 故意制造虚假叙事来误导系统
案例: 某机构通过媒体释放"看多"信号，实际在出货
对策:
- 来源可信度加权（不是所有新闻等同）
- 叙事需要多源交叉确认
- 区分"市场叙事"和"事实数据"——叙事可以被操纵，数据较难
- Persona 对抗辩论机制天然有抵抗力（不同世界观的 Persona 不会同时被骗）5.3 LLM 一致性问题
风险: 同样的输入，LLM 给出不同的判断
对策:
- temperature 设为 0 或极低
- 关键判断做多次采样取众数/均值
- 结构化输出约束（JSON schema 强校验）
- 记录每次 LLM 调用的完整输入输出，可审计5.4 系统性失败模式
场景: 所有 Persona 同时犯同一个错误
原因: 所有 Persona 都基于 LLM，LLM 有共同的知识截止日期和偏见
对策:
- 保留至少一个"反共识"Persona（专门唱反调）
- 引入纯规则-based 的基础信号作为锚点（不经过 LLM）
- 设计"紧急刹车"机制：当所有 Persona 高度一致时，反而触发额外审查5.5 可解释性和可审计性
每个判断必须能回答:
1. 基于什么叙事？（来源、时间、强度）
2. 基于什么数据？（具体数值、历史分位）
3. 各 Persona 分别怎么看？（独立判断 + 分歧点）
4. 为什么最终判断是这个？（合成逻辑）
5. 什么证据会推翻这个判断？（可证伪条件）
这不是锦上添花——没有可解释性，你无法信任系统的判断，
不信任就不会执行，不执行就没有盈利。六、三层分工总表
┌──────────┬───────────────────────┬──────────────────┬────────────┐
│ │ 代码层 (SOP) │ Agent 层 │ 人 │
├──────────┼───────────────────────┼──────────────────┼────────────┤
│ 数据 │ 采集、清洗、存储、 │ │ │
│ │ 指标计算 │ │ │
├──────────┼───────────────────────┼──────────────────┼────────────┤
│ 叙事 │ 存储、索引、匹配 │ 提取、分类、 │ 新叙事 │
│ │ │ 情绪打分 │ 注册确认 │
├──────────┼───────────────────────┼──────────────────┼────────────┤
│ 分析 │ 输出格式校验 │ Persona 辩论、 │ 极端判断 │
│ │ │ 合成推理 │ 人工确认 │
├──────────┼───────────────────────┼──────────────────┼────────────┤
│ 学习 │ 权重更新公式、 │ 元学习分析、 │ 审批优化 │
│ │ 绩效统计 │ 优化建议 │ 建议 │
├──────────┼───────────────────────┼──────────────────┼────────────┤
│ 执行 │ 订单管理、风控规则、 │ │ 战略配置 │
│ │ 仓位计算 │ │ 调整 │
├──────────┼───────────────────────┼──────────────────┼────────────┤
│ 运维 │ 调度、监控、告警、 │ │ 故障处理 │
│ │ 日志 │ │ │
└──────────┴───────────────────────┴──────────────────┴────────────┘关联文档：系统架构总览创建时间：2026-05-24