yuqei/ai-exchange

Fork 0

Files

T

Codex e4538de522 Close decision assistant cockpit loop

2026-05-13 08:04:26 +08:00

17 KiB

Raw Blame History

AI_ICT + TradingAgents 融合实施方案 v1

1. 文档目标

本方案用于明确以下问题：

为什么应当选择“以 AI_ICT 为基础，把 TradingAgents 的能力加进来”
TradingAgents 的哪些能力值得引入，哪些能力不应直接引入
融合后的系统边界、数据流、模块落点、阶段顺序分别是什么
如何在不破坏当前 Real-time Assisted Trading V1 主线的前提下推进融合

本方案是实施方案，不是概念讨论稿。默认以当前仓库现状为前提：

D:\ai-exchange 继续作为主系统
TradingAgents 作为“多智能体研究与解释子层”被接入
不默认开启真实自动下单
不允许新引入的智能体层绕过现有风控、信任分层、人工确认边界

2. 结论先行

结论明确如下：

选择 AI_ICT / ai-exchange 作为主干系统，把 TradingAgents 改造成其下游的多智能体研究委员会能力层，而不是反过来。

原因不是“哪个更先进”，而是谁更适合做系统主骨架：

ai-exchange 已具备真实市场真值、真实账户只读同步、运行时调度、决策包、告警、风控、执行确认、研究复盘闭环
TradingAgents 的长板是多角色分析、辩论、结构化输出、检查点恢复、经验记忆
前者更适合做生产主干，后者更适合做分析增强层

因此，正确的融合方向不是“换底座”，而是：

AI_ICT 负责事实、规则、边界、执行安全
TradingAgents 负责分析、辩论、解释、补充视角

3. 当前主系统定位

当前 ai-exchange 的系统定位应保持不变：

实时市场与账户真值
-> 盘前计划 / 盘中候选
-> 风控与信任分层
-> 决策包与提醒
-> 人工确认 / paper / semi-auto
-> journal / weekly review / trust feedback

当前仓库里已经存在并应继续作为主锚点的模块包括：

src/services/market_state/
src/services/runtime/trading_runtime_service.py
src/services/decision/decision_packet_service.py
src/services/trust/model_trust_service.py
src/services/execution/
src/services/operator/operator_workspace_service.py
src/services/journal/
src/services/alerts/
src/services/visual_watch/
src/api/server.py
src/web/app.js

这条主干已经与当前产品边界一致：

analysis_only
restricted_decision_support
decision_support_only
trade_inside_framework
observe_only

融合 TradingAgents 时，不能破坏这条边界。

4. TradingAgents 真正值得借的能力

4.1 应借入的能力

应优先借入以下能力：

多角色分析编排
- Market Analyst
- News Analyst
- Social/Sentiment Analyst
- Fundamentals Analyst
对抗式研究结构
- Bull Researcher
- Bear Researcher
- Research Manager
风险辩论层
- Aggressive
- Neutral
- Conservative
结构化输出
- ResearchPlan
- TraderProposal
- PortfolioDecision
长链路恢复能力
- checkpoint / resume
决策记忆机制
- decision log
- reflection memory

这些能力对 ai-exchange 的价值是：

让当前决策包更会解释
让同一候选在不同视角下被交叉审视
让人工操作台看到“支持理由 + 反对理由 + 风险质询”
让 weekly review 的反馈真正回流到下一轮决策

4.2 不应直接借入的能力

以下能力不应作为当前阶段的主线引入：

以 yfinance / alpha_vantage 为主的外部数据层
TradingAgents 原生的“模拟交易框架替代执行主线”
直接让 TradingAgents 生成可越权执行的交易决定
直接复制其 CLI 作为主产品入口

原因很明确：

ai-exchange 已有更贴近当前目标的真值层和执行边界
TradingAgents 的原生数据源和研究场景偏股票研究框架
当前系统需要的是“增强解释层”，不是“替换生产主线”

5. 融合后的目标系统定位

融合后的系统不应变成“另一个 TradingAgents”，而应变成：

一个具备多智能体研究委员会能力的 AI_ICT 实盘辅助决策系统

其目标形态如下：

真实市场 / 账户 / 风控事实
-> AI_ICT 生成 trading plan / candidate / signal / trust / risk
-> 研究委员会对当前机会做多视角分析与辩论
-> 输出委员会结论、分歧点、风险提示、观察清单
-> 写回 decision packet / review packet / operator workbench
-> 仍由 AI_ICT 的风险边界决定是否允许后续动作

这意味着：

TradingAgents 只增强“解释与判断质量”
AI_ICT 继续掌管“事实与执行边界”

6. 核心设计原则

6.1 AI_ICT 是 system of record

以下事实只能以 ai-exchange 为准：

市场状态
账户状态
风险结果
trust classification
candidate executable status
execution ticket status
journal / weekly review

TradingAgents 子层只能读取这些事实，不能自行定义一套平行真相。

6.2 TradingAgents 是研究委员会，不是执行引擎

TradingAgents 子层允许：

解释
质疑
总结
对比
形成委员会观点

TradingAgents 子层不允许：

直接下单
直接确认 ticket
直接改写 risk governor 结论
直接改写 trust bucket

6.3 先接入“事实消费”，后接入“结果影响”

推进顺序必须是：

先读取 AI_ICT 输出
-> 再生成委员会结论
-> 再把结论显示出来
-> 最后才决定是否让结论参与 decision packet 排序或提醒

不要一开始就让委员会输出参与执行路径。

6.4 先影子运行，后受控影响

P0 阶段只允许：

影子运行
不影响现有 action recommendation
不影响 execution gate

P1 才允许其进入决策包展示与优先级提示层。

6.5 不引入第二套产品主入口

当前产品入口仍应保持：

/
/training
/trading/*

不把 TradingAgents CLI 直接当作产品主入口；最多只保留为内部调试工具或后台适配层。

7. 总体架构

建议新增一个新的服务域：

src/services/research_council/

建议结构如下：

src/services/research_council/
  __init__.py
  council_context_builder.py
  council_orchestrator.py
  council_schema.py
  council_memory_service.py
  council_checkpoint_service.py
  council_mapper_service.py
  tradingagents_adapter.py

各模块职责

council_context_builder.py
- 从 ai-exchange 当前事实构建委员会输入上下文
tradingagents_adapter.py
- 适配 TradingAgents 的分析/辩论流程
- 替换其原始数据工具输入，改为消费 AI_ICT 已有事实
council_schema.py
- 定义委员会输出结构
- 不直接复用 TradingAgents 原始 markdown 作为系统契约
council_mapper_service.py
- 将委员会结果映射为 decision packet / review packet 可消费的字段
council_memory_service.py
- 将 journal / weekly review / backtest / trust 反馈转为委员会的经验记忆
council_checkpoint_service.py
- 管理长链路 LLM 运行的恢复能力
council_orchestrator.py
- 提供统一入口，例如 run_once() / build_preview() / persist_run()

8. 输入输出契约

8.1 委员会输入

委员会的输入必须来自 AI_ICT 当前已存在的结构化结果，而不是让 TradingAgents 自己去抓市场。

输入至少包括：

market_state
latest_trading_plan
latest_candidate
latest_signal
risk_result
trust_policy
broker_snapshot_summary
recent_journal_entries
weekly_review_summary
recent_alerts
session_focus_summary

其中，市场和账户事实由以下现有模块提供：

src/services/market_state/
src/services/broker/
src/services/reconciliation/
src/services/journal/
src/services/trust/
src/services/operator/

8.2 委员会输出

建议定义统一输出结构 CouncilDecision，最少包含：

overall_stance
committee_confidence
market_view
bull_case
bear_case
risk_challenges
operator_summary
agreement_points
disagreement_points
missing_information
follow_up_checks
recommended_watch_items
execution_veto_signals
source_snapshot_meta

说明：

这个输出是解释层契约
不是新的执行契约
execution_veto_signals 只能作为提醒参考，不能直接代替 Risk Governor

9. 与现有模块的落点关系

9.1 `DecisionPacketService`

落点文件：

src/services/decision/decision_packet_service.py

计划变更：

新增 research_council_summary
新增 committee_confidence
新增 agreement_points
新增 disagreement_points
新增 follow_up_checks
新增 operator_questions

规则：

若委员会运行失败，不影响当前 DecisionPacket 主体生成
why_allowed / why_blocked 仍以现有风险与信任逻辑为准
委员会只能增强解释，不得覆盖现有 action_recommendation

9.2 `TradingRuntimeScheduler`

落点文件：

src/services/runtime/trading_runtime_service.py

计划变更：

在 watch 之后、decision_packet 之前增加新任务 research_council

建议顺序：

plan
-> market_state
-> broker_sync
-> reconciliation
-> watch
-> research_council
-> decision_packet
-> alert_dispatch

规则：

只在存在 active plan 或 recent candidate 时触发
runtime 失败只记 warning / blocker，不直接改动执行边界
初期允许关闭开关运行

9.3 `ReviewPacketService`

落点文件：

src/services/operator/operator_workspace_service.py
scripts/run_review_packet.py

计划变更：

在 review packet 中加入委员会摘要
支持查看最近一次委员会分歧
支持查看“本次为何仍建议观察 / 为何不建议执行”

9.4 `Workbench`

落点文件：

src/web/app.js
src/web/index.html

计划变更：

在 decision packet 区域新增“委员会视角”
新增 bull / bear / risk 三栏或折叠区
新增“分歧点”和“补充检查项”
不新增第二套独立大页面，优先融入现有 operator console

9.5 `ModelTrustService`

落点文件：

src/services/trust/model_trust_service.py

计划变更：

短期不让委员会改写 trust bucket
中期允许委员会结果被记录为 trust 观察素材
长期才考虑引入“委员会质量反馈”作为 trust 附加维度

规则：

analysis_only_allowed
restricted_decision_support_allowed
decision_support_allowed
execution_allowed

仍由现有 ModelTrustService 决定。

10. 数据持久化建议

建议新增以下表或等价持久化对象：

research_council_runs
- 一次委员会运行的主记录
research_council_messages
- 各角色输出片段
research_council_checkpoints
- 长链路恢复锚点
research_council_lessons
- 从 journal / weekly review 提炼出的结构化经验
research_council_links
- 将一次委员会运行关联到
  - trading_plan_id
  - candidate_id
  - signal_id
  - decision_packet_id
  - execution_ticket_id

注意：

不建议把 ~/.tradingagents 直接当正式生产存储
TradingAgents 的 memory/checkpoint 设计可以借鉴
正式系统记录仍应写回 ai-exchange 自己的数据库与 review/journal 体系

11. P0 / P1 / P2 实施计划

P0：影子接入，不影响现有决策

目标

把 TradingAgents 作为只读研究委员会接入，能够围绕 AI_ICT 当前事实生成一份委员会结论，但不影响现有执行路径。

范围

新增 research_council 服务域
做 AI_ICT -> Committee 的上下文构建
跑通最小委员会链路：
- Market view
- Bull case
- Bear case
- Risk debate
- Operator summary
持久化委员会结果
新增手动触发入口
新增只读查看入口

建议新增接口

POST /trading/research-council/run
GET /trading/research-council/latest
GET /trading/research-council/runs

落点

src/services/research_council/*
src/api/server.py
src/services/operator/operator_workspace_service.py
scripts/run_review_packet.py

验收

没有委员会结果时，现有系统行为不变
有委员会结果时，review packet 能展示委员会摘要
runtime 不依赖委员会成功才可继续
任何委员会异常都不能导致 ticket / execution 主链路失效

本阶段禁止事项

禁止委员会改写 action_recommendation
禁止委员会改写 risk_result
禁止委员会改写 execution_allowed

P1：受控进入决策包与运行时

目标

让委员会结果成为当前决策包与 operator workbench 的正式解释层组成部分，但仍不替代风控和 trust。

范围

在 runtime 中增加 research_council 任务
在 DecisionPacket 中加入委员会摘要字段
增加分歧显示与 follow-up 检查项
增加委员会 checkpoint / resume
增加委员会 memory 回流：
- 来自 journal
- 来自 weekly review
- 来自 trust 的 session recommendations

关键设计

委员会结果在这一阶段可以影响：

operator 注意力分配
决策包展示优先级
alert 文案丰富度
visual watch 触发建议

但不能影响：

execution gate
live readiness
operator confirmation protocol

落点

src/services/runtime/trading_runtime_service.py
src/services/decision/decision_packet_service.py
src/services/visual_watch/visual_trigger_policy_service.py
src/web/app.js

验收

decision packet 中能看到委员会结论
review packet 中能看到支持与反对意见
council 运行失败时系统自动降级，不阻塞现有任务
visual watch 可选地引用委员会的 follow-up checks

P2：经验回流、评估闭环、研究竞技场

目标

把委员会从“会说”推进到“会从历史里学”，并建立内部评估机制，判断其是否真的提高了辅助决策质量。

范围

建立 setup / session / symbol 级别的委员会经验回流
将 journal / weekly review / plan replay 结果映射为委员会 lesson
增加委员会效果评估：
- 单层决策 vs 委员会决策
- 有分歧提示 vs 无分歧提示
- 不同 analyst 组合对结果的影响
建立内部 challenge 机制

说明

这一阶段可以借鉴 AI-Trader-main 的两个思路，但只借内部研究能力，不借平台化产品方向：

challenge
team mission

建议用途：

做内部模型赛马
做多分析策略对比
做不同委员会编排方式对比

不建议用途：

对外社区化
跟单平台化
积分和 follower 经济

验收

能客观比较委员会模式是否提升 operator 决策质量
能识别哪些 session / setup 最适合启用委员会
能从失败案例里提炼新的 follow-up checks

12. 明确不做的事

当前阶段明确不做以下事情：

12.1 不以 TradingAgents 取代 AI_ICT 主干

不做：

用 TradingAgents 重写 market truth
用 TradingAgents 重写 runtime scheduler
用 TradingAgents 重写 risk governor
用 TradingAgents 重写 execution ticket

12.2 不把 TradingAgents 原生数据层当主数据源

不做：

用 yfinance 替代 OKX 主真值
用 alpha_vantage 替代当前真实市场/账户事实

12.3 不把研究输出直接当执行指令

不做：

委员会直接下单
委员会直接确认 ticket
委员会直接开启 live

12.4 不引入 AI-Trader-main 的平台化社区主线

当前不做：

copy trading
follower economy
rewards / points
signal marketplace

这些能力只有当产品目标改成“外部平台化交易社区”时才讨论。

13. 推荐执行顺序

推荐顺序如下：

先完成当前 AI_ICT 主线的 N4 收尾与外部环境恢复
再推进本方案 P0
P0 稳定后再进入 P1
P1 验证其对 operator 有真实帮助后，再考虑 P2

换句话说：

先稳住 AI_ICT 主骨架
-> 再接入委员会影子层
-> 再让委员会参与解释层
-> 最后再做经验回流和内部评估闭环

14. 最终结论

最终建议可以压缩成一句话：

保留 AI_ICT 的事实层、规则层、执行边界层，把 TradingAgents 改造成其下游的多智能体研究委员会，而不是反向重构底座。

这条路线的优点是：

保住当前仓库已经形成的生产主干
最大化吸收 TradingAgents 的高价值能力
不引入第二套平行真相
不把研究框架误用成执行框架
能按 P0 -> P1 -> P2 逐步验证收益，而不是一次性大重构

如果后续继续推进，下一份文档应直接落到：

P0 任务清单
数据表草案
API 草案
research_council 目录脚手架说明

17 KiB Raw Blame History

AI_ICT + TradingAgents 融合实施方案 v1

1. 文档目标

2. 结论先行

3. 当前主系统定位

4. TradingAgents 真正值得借的能力

4.1 应借入的能力

4.2 不应直接借入的能力

5. 融合后的目标系统定位

6. 核心设计原则

6.1 AI_ICT 是 system of record

6.2 TradingAgents 是研究委员会，不是执行引擎

6.3 先接入“事实消费”，后接入“结果影响”

6.4 先影子运行，后受控影响

6.5 不引入第二套产品主入口

7. 总体架构

各模块职责

8. 输入输出契约

8.1 委员会输入

8.2 委员会输出

9. 与现有模块的落点关系

9.1 DecisionPacketService

9.2 TradingRuntimeScheduler

9.3 ReviewPacketService

9.4 Workbench

9.5 ModelTrustService

10. 数据持久化建议

11. P0 / P1 / P2 实施计划

P0：影子接入，不影响现有决策

目标

范围

建议新增接口

落点

验收

本阶段禁止事项

P1：受控进入决策包与运行时

目标

范围

关键设计

落点

验收

P2：经验回流、评估闭环、研究竞技场

目标

范围

说明

验收

12. 明确不做的事

12.1 不以 TradingAgents 取代 AI_ICT 主干

12.2 不把 TradingAgents 原生数据层当主数据源

12.3 不把研究输出直接当执行指令

12.4 不引入 AI-Trader-main 的平台化社区主线

13. 推荐执行顺序

14. 最终结论

17 KiB

Raw Blame History

9.1 `DecisionPacketService`

9.2 `TradingRuntimeScheduler`

9.3 `ReviewPacketService`

9.4 `Workbench`

9.5 `ModelTrustService`