AI财富管家
让长任务可见、可停,也能接着跑。
一个可中断续跑的控制室,覆盖多角色研究、策略与仓位。
- FORM
- System integration prototype
- ROLE
- 独立完成架构、控制台与服务集成
- TECHNOLOGY
- Vue / NestJS / FastAPI / Redis / CCXT
- CORE FLOW
- 多角色研究 → 暂停续跑 → 策略执行 → 仓位复盘

把一次投研,交给一支十二个角色的团队
让单个模型直接输出"看多还是看空"很容易,但这样的结论没法检查:看不到依据,看不到分歧,更看不到模型替你跳过了哪些环节。而一次认真的多角色研究动辄十几分钟,中间还会遇到断线、暂停与服务重启。
这个项目的 AI 部分,因此不是一个更聪明的聊天框,而是一支分工明确、全程留痕的投研团队。

每次分析由十二个角色接力:市场、情绪、新闻、基本面四类分析师带着各自的工具环完成取数与判读;多空研究员围绕结论正面交锋,轮数由发起时选择的研究深度决定——浅、中、深对应一、三、五轮;研究经理裁决辩论、形成投资计划,交易员把它翻译成提案,激进、保守、中立三位风控再轮转质疑一轮,最后由组合经理给出结构化终审:评级、摘要、关键论点、目标价与期限。模型也分了两档,一线角色使用快速模型,只有研究经理与组合经理两个"裁决位"使用深度模型。
过程与结论同样是一等公民。每个角色的发言、每次工具调用的数据、两场辩论的往来,都以事件流落库并经 SSE 推送;浏览器断线后凭最后事件位置续传,暂停停在节点边界,恢复后从最后成功的角色分析续跑。分析结束后,这个标的的历史决策与真实涨跌的对照会沉淀为记忆,注入下一次分析的提示词——团队记得上一次它怎么看这个资产,以及后来对错如何。
轻问题走轻入口:一个带着实时数据的对话助手
不是每个问题都值得开一场十二个角色的研究。"BTC 现在什么价?""这枚币的 RSI 在什么位置?""我这样的收入该怎么配置资产?"——日常问题要的是即时、有数据支撑的回答。
聊天助手要补的就是这个入口:让模型能自己取数,但取到的每个数字必须来自工具调用,而不是模型现编。

后端是一个 LangChain Agent,配三个工具:实时行情经 CCXT 直连交易所;技术指标覆盖 RSI、MACD 与长短均线,跨四小时、日、周、月四个周期;财经新闻来自外部搜索。系统提示词把请求分成三条路:资产配置类先追问职业、储蓄规模与年龄,再给方案;单资产诊断类调工具得出方向结论;与投资无关的话题直接拒答。回复经 SSE 流式返回,会话与消息逐条归属登录用户并持久化,刷新之后对话还在。
这条链路与交易团队是两条独立的入口:一个处理轻量即时问题,一个承担深度研究。分工的价值在于,轻问题不必假装成研究报告,而研究也不必退化成一次问答。
四个账户,一张风险视图
合约交易者很少只待在一家交易所。OKX、币安、Gate、Bybit 各自一个 App,仓位、杠杆、保证金各讲各的口径——风险敞口被切成四块,要逐个点开才能拼出全貌。
聚合要做的不是把四个界面摆在一起,而是先把风险讲清楚:哪个账户连不上、哪个仓位在恶化,一眼可见;处理动作再进入单个账户执行。

四个交易所适配器实现同一个接口,底层统一走 CCXT;张数、保证金模式、止损触发价这些各所字段差异,全部收敛在适配器内部。聚合持仓按账户并行拉取、不做缓存——每个数字都来自当次请求;单个账户失败不连累其余,失败账户单独标记并提示,而不是让整页空转。账户页把交易所、运行环境、绑定策略与启停状态放在一起:API 密钥以 AES-256-GCM 加密存储,任何列表返回都剔除敏感字段。

实盘可控,是先定义故障时还允许做什么
SuperTrend 这类趋势策略在回测里总是干脆的:信号出现,下单,反转,离场。实盘真正的难题在别处——交易所临时拒绝、行情拉取失败、策略状态意外丢失。这些时刻策略还允许做什么,决定了它是交易系统,还是事故现场。
所以执行层的核心规则先于功能:运行态不完整时,只减险,不加点。
策略被拆成决策与执行两层:决策模块是纯函数,接收快照、输出意图,不碰交易所;执行服务读齐行情、仓位与运行态,把五类意图——开仓、平仓、同步止损、清除止损、停用配置——翻译成订单调用。由此得到几条硬约束:运行态存储不可用时,平仓与止损同步照常,开仓加仓全部禁止;持仓存在但运行态丢失时,置禁止加仓标志,防止基于空记账继续加仓;交易所权益缺失或可用保证金为零时,本周期禁开仓。止损是灾难止损,并按棘轮单向移动——多头只升不降、空头只降不升,与交易所现存止损单对齐后再回写为事实。加仓按递减阶梯缩放并设上限,越加越少,而不是越加越多。

每根 K 线收盘驱动一次决策,十五分钟、一小时、四小时与日线四个周期各有调度。从开仓到平仓的动作按仓位回合归档,决策价与实际成交价、手续费一并落库,并经 SSE 实时推送;一笔趋势行情的完整进出,因此可以在同一页里从信号回看到执行。
权限与数据归属,按 SaaS 的地基来造
研究、对话、策略、账户,最终都长在同一个控制台上。只要系统要交给第二个用户,两个问题就必须先回答:谁能看到哪些模块?每条数据归谁?
这一层的答案不是一道登录墙,而是完整的 RBAC 加逐条归属:功能按角色裁剪,数据按用户隔离。

用户、角色、菜单、权限四张表构成 RBAC 骨架。两个全局守卫让所有接口默认要求 JWT,再由权限码逐一声明——策略管理、账户操作、行情查看、定时任务控制各持独立权限码,管理员角色直接旁路。前端路由同样来自后端:非管理员用户只会收到其角色绑定的菜单树,无权模块从源头就不被渲染。数据侧,交易账户、策略配置、对话会话、分析运行全部携带用户归属,查询强制带上当前用户;凭证加密存储,返回视图统一脱敏。
结果是:每个用户登录后看到的只是自己角色的模块和自己的数据。当前的隔离粒度是单用户,但"归属字段 + 强制过滤"的模式已经就位,向组织与租户模型演进时,这是已经铺平的地基。
下一步
当前控制台已经把研究、对话、执行与复盘串在一条链路上,并且按角色与用户划清了边界。下一轮的重点是把 SaaS 化的最后一段补齐:按钮级权限与密钥托管,组织与租户模型,以及在沙盒环境验证完整的实盘执行链路。能力可以继续增加,但前提不变——每一条数据都有主人,每一次执行都有边界。