1. 为什么我要把投资逻辑交给AI智能体来跑
先说结论:这套框架不是让大模型直接告诉你“买哪只”,而是把投资流程拆成可验证、可回溯、可迭代的智能体工作流,让机器负责信息处理、逻辑校验和纪律执行,人负责最终决策。我从2024年下半年开始折腾这件事,最初只是想用大模型帮我读财报,后来发现单点工具解决不了根本问题——信息是散的,逻辑是断的,情绪是反复的。于是我把整个投资流程重新拆解,用多个AI智能体分工协作,形成了一条从宏观逻辑推演到个股筛选的完整链路。
这套东西适合谁?如果你是有一定投资经验、懂基本财务指标、愿意花时间搭建工具链的从业者或资深散户,它能帮你把信息处理效率提升一个量级。如果你期待的是“输入代码就自动赚钱”,那可以直接关掉页面了,没有任何框架能保证收益,AI智能体也不例外。它解决的核心问题是:在信息过载的市场里,如何用工程化手段保持逻辑一致性和执行纪律性。
关键词里提到的AI智能体、投资框架、大模型、算力、AI安全,这五个词基本勾勒出了整套系统的骨架。AI智能体是执行单元,投资框架是业务逻辑,大模型是推理引擎,算力是物理约束,AI安全是风控底线。接下来我会把这五个部分逐一拆开,讲清楚每个环节的设计思路、实操细节和我踩过的坑。
2. 整体架构设计与核心思路拆解
2.1 为什么选择多智能体而不是单一大模型
最开始我试过用一个通用大模型包打天下,把财报、新闻、研报全部塞进上下文,让它直接输出投资建议。实测下来问题很明显:上下文窗口有限,信息一多就丢细节;单一模型既要理解财务数据又要做逻辑推理还要生成报告,角色冲突导致输出质量不稳定;最关键的是,你没法定位错误出在哪个环节。
多智能体架构的核心优势在于职责分离。我把整个投资流程拆成五个独立智能体:宏观逻辑智能体、行业比较智能体、个股筛选智能体、风险校验智能体、组合监控智能体。每个智能体只负责一个环节,有自己的系统提示词、工具集和输出格式。这样做的好处是,当最终结果出问题时,我可以逐个环节排查,而不是面对一个黑箱。
从工程角度看,多智能体还带来了并行处理的可能性。宏观逻辑和行业数据可以同时跑,个股筛选依赖前两者的输出但内部可以并行处理多只标的。在算力有限的情况下,这种架构比单模型串行处理效率高得多。
2.2 算力约束下的模型选型策略
热词里反复出现算力、RTX3090、INT8、FP16这些词,说明大家都很关心成本问题。我的主力设备是一台配了RTX3090的工作站,24GB显存,在本地部署大模型时这个配置算是入门到中端的水平。经过反复测试,我最终采用的方案是:推理用量化模型,微调用云端算力。
具体来说,日常推理跑的是INT8量化的70亿参数模型,显存占用大约8GB,推理速度在每秒30个token左右,处理一份财报的时间可以接受。为什么不用FP16?因为FP16下同样的模型要占14GB显存,留给上下文缓存的空间就很少了,处理长文档时容易爆显存。INT8量化会带来一定的精度损失,但在财务数据抽取和逻辑推理任务上,实测差异在可接受范围内。
这里有个关键细节:量化不是一刀切的。我试过把整个模型全部INT8量化,结果发现涉及数值计算的任务(比如计算复合增长率、估值倍数)误差明显变大。后来改成混合精度——注意力层和嵌入层保持FP16,前馈网络层用INT8,在显存和精度之间找到了平衡点。这个配置下,模型占用约11GB显存,数值计算精度基本无损。
如果你没有本地GPU,纯靠云端API也不是不行,但成本会随调用量线性增长。我的建议是:高频调用的轻量任务走本地量化模型,低频的重推理任务走云端。比如每天的新闻摘要和公告筛选用本地模型,季度财报的深度分析用云端大模型。这样一个月下来,云端成本能控制在可接受范围内。
2.3 智能体工作流的设计原则
搭建智能体工作流时,我遵循了三条原则,这些原则是从多次失败中总结出来的。
第一条:每个智能体必须有明确的输入输出契约。宏观逻辑智能体的输入是经济数据和政策文本,输出是结构化的逻辑链条,格式固定为JSON,包含逻辑节点、置信度、依赖关系。行业比较智能体的输入是宏观逻辑输出和行业数据,输出是行业排序和理由。没有这个契约,智能体之间的数据传递就会变成一团乱麻。
第二条:关键决策点必须有人工确认。智能体可以生成候选股票池,可以给出评分和理由,但最终买入决策必须由人来做。这不是技术限制,而是风控要求。我试过让智能体全自动执行,结果在一次市场剧烈波动中,智能体因为训练数据中的滞后性做出了错误判断,幸好当时只是模拟盘。
第三条:所有输出必须可追溯。每个智能体的输出都要附带数据来源、推理步骤和置信度。比如个股筛选智能体给出“某股票评分85分”,必须同时给出评分依据:财务健康度30分、行业景气度25分、估值合理性20分、技术面10分。这样当结果不符合预期时,我能快速定位是哪个维度的判断出了问题。
3. 核心智能体的详细拆解与实操要点
3.1 宏观逻辑智能体:从信息噪声中提取信号
宏观逻辑智能体的任务是把碎片化的宏观信息转化为可操作的逻辑链条。它的输入包括:央行公开市场操作数据、PMI、CPI、PPI、社融数据、政策文件摘要。输出是一个逻辑图谱,标明当前经济处于什么阶段、哪些行业可能受益、哪些风险需要关注。
实操中最大的难点是信息去噪。大模型很容易被新闻标题带偏,把短期波动当成长期趋势。我的解决方案是在系统提示词中强制要求区分“事实”和“观点”,并且对每个逻辑节点标注时间维度——是短期(1个月内)、中期(1-6个月)还是长期(6个月以上)。
具体操作上,我用了这样的提示词结构:
你是一名宏观经济分析师。请基于以下数据,输出当前经济状态的逻辑图谱。 要求: 1. 区分事实性数据和观点性判断,事实用[F]标注,观点用[O]标注。 2. 每个逻辑节点标注时间维度:短期/中期/长期。 3. 输出格式为JSON,包含节点ID、描述、类型、时间维度、置信度、依赖节点。 4. 置信度低于0.6的节点必须说明原因。这个智能体我每天跑一次,输出结果存入本地数据库。每周做一次趋势对比,看逻辑链条是否发生变化。实测下来,它对政策转向的捕捉比人工阅读快1-2天,但需要人工复核置信度较低的节点。
3.2 行业比较智能体:用数据说话而不是拍脑袋
行业比较智能体的核心任务是在宏观逻辑的约束下,对各个行业进行排序。它的输入是宏观逻辑图谱和行业数据(包括行业指数走势、估值分位、盈利增速、资金流向),输出是行业排序和配置建议。
这里的关键是多维度加权。我设计了四个维度:景气度(40%权重)、估值(25%权重)、资金面(20%权重)、政策匹配度(15%权重)。每个维度下又有若干指标,比如景气度下面有营收增速、利润增速、产能利用率等。
权重的设定不是拍脑袋来的。我用过去五年的数据做了回测,发现景气度权重低于30%时,排序结果与市场实际表现的相关性明显下降;高于50%时,又容易追高。40%是回测下来比较均衡的值。当然这个权重需要根据市场环境动态调整,比如在流动性宽松期,资金面权重可以适当提高。
实操中有一个容易忽略的细节:行业分类标准要统一。我最初用申万分类,后来发现有些智能体输出用的是中信分类,导致数据对齐时出现偏差。现在我在所有智能体的系统提示词中都强制指定了分类标准,并且在数据预处理阶段做了映射表。
3.3 个股筛选智能体:从股票池到候选名单
个股筛选智能体是整个框架中最复杂的部分。它的输入是行业排序结果和全市场股票数据,输出是候选股票池,每只股票附带评分和详细理由。
评分体系我设计了五个维度:财务健康度(30%)、成长性(25%)、估值合理性(20%)、技术面(15%)、催化剂(10%)。每个维度下又有具体的量化指标。比如财务健康度包括资产负债率、流动比率、经营现金流/净利润、应收账款周转率等。
这里有个重要的实操心得:财务数据必须做异常值处理。我遇到过某只股票因为一笔一次性资产处置导致净利润暴增,如果直接按增速排序,它会排到前面,但实际上主营业务并没有改善。我的处理方式是,在智能体的提示词中要求识别非经常性损益,并在计算成长性指标时剔除这部分影响。
另一个细节是技术面指标的参数选择。我试过用默认参数(比如MACD的12/26/9),发现对A股市场的适配性一般。后来改成更适合A股波动特征的参数(比如缩短快线周期),信号质量有所提升。但技术面权重我只给了15%,因为过度依赖技术面容易陷入短期博弈。
3.4 风险校验智能体:最后一道防线
风险校验智能体的职责是对候选股票池进行风险筛查。它的输入是个股筛选结果,输出是风险标记和调整后的评分。
风险维度包括:财务风险(如商誉占比过高、大股东质押比例过高)、合规风险(如监管处罚记录)、流动性风险(如日均成交额过低)、集中度风险(如单一客户收入占比过高)。每个风险维度都有阈值,超过阈值就触发预警。
这个智能体最容易被忽视,但恰恰是最重要的。我踩过的坑是:早期版本没有做风险校验,结果选出了一只财务数据看起来很漂亮但大股东质押比例超过80%的股票,后来股价大幅波动,教训深刻。现在我的规则是:任何高风险标记的股票,必须人工复核后才能进入候选池。
风险校验智能体的输出格式我设计成风险矩阵,每只股票一行,风险维度一列,用红黄绿三色标记。这样一眼就能看出哪些股票需要重点关注。
4. 完整实操流程与关键环节实现
4.1 环境搭建与工具链配置
整套系统的运行环境分为本地和云端两部分。本地负责数据预处理、轻量推理和结果展示,云端负责重推理和模型微调。
本地环境我用的是一台配了RTX3090的工作站,操作系统是Ubuntu 22.04。为什么选Ubuntu而不是Windows?因为大模型推理框架对Linux的支持更好,CUDA驱动和cuDNN的配置也更顺畅。Windows下虽然也能跑,但遇到环境问题时排查成本更高。
核心工具链包括:
- 推理框架:我用的是vLLM的轻量替代方案,主要考虑是显存占用低、启动速度快。如果你追求极致性能,vLLM是更好的选择,但对显存要求更高。
- 数据存储:PostgreSQL用于结构化数据(财务数据、行情数据),Milvus用于向量数据(新闻摘要、研报摘要)。
- 工作流编排:我用的是自己写的一套轻量级调度器,核心逻辑是DAG(有向无环图),每个节点是一个智能体任务。为什么不用现成的编排工具?因为投资流程的依赖关系比较特殊,现成工具要么太重,要么不够灵活。
- 结果展示:Grafana用于监控智能体运行状态,Streamlit用于展示每日投资候选池。
配置过程中有几个坑值得提。第一,CUDA版本要和推理框架匹配,我最初装了最新版CUDA,结果推理框架不支持,回退到11.8才跑通。第二,Python虚拟环境一定要用,不同智能体可能依赖不同版本的库,混在一起容易出问题。第三,数据库连接池要配置合理,智能体并发跑的时候连接数不够会报错。
4.2 数据管道的搭建与维护
数据是智能体的燃料,数据管道的质量直接决定输出质量。我的数据管道分为三层:采集层、清洗层、存储层。
采集层负责从各个数据源获取原始数据。行情数据我用的是免费接口加本地缓存,财务数据从公开披露文件解析,新闻和研报通过RSS订阅和公开API获取。这里要注意频率控制,过于频繁的请求容易被封,我设置了合理的间隔和重试机制。
清洗层是最耗时的部分。原始数据往往有缺失值、异常值、格式不一致等问题。我的处理流程是:先做缺失值填充(财务数据用行业均值填充,行情数据用前值填充),再做异常值检测(用3σ原则和IQR方法),最后做格式标准化(统一日期格式、统一行业分类、统一货币单位)。
存储层我用了分区表设计,行情数据按日期分区,财务数据按报告期分区。这样查询效率高,也方便做历史回溯。向量数据存在Milvus中,用于语义检索。
数据管道我每天凌晨自动跑一次,跑完后会生成一份数据质量报告,包括缺失率、异常值比例、更新延迟等指标。如果某个指标超过阈值,会触发告警。这个机制帮我发现过好几次数据源异常,比如某次财务数据接口返回了空值,如果没有质量报告,智能体就会基于错误数据做判断。
4.3 智能体调度与结果聚合
智能体调度是整个系统的中枢。我设计的调度逻辑是:宏观逻辑智能体最先跑,输出结果触发行业比较智能体;行业比较智能体输出结果触发个股筛选智能体;个股筛选智能体输出结果触发风险校验智能体。每个智能体跑完后,结果存入数据库,同时触发下一个环节。
这里有个关键设计:每个智能体都有超时和重试机制。大模型推理有时会因为显存不足或网络问题失败,如果没有重试机制,整个流程就会卡住。我的设置是超时时间5分钟,重试3次,3次都失败就跳过该环节并记录日志。
结果聚合是把各个智能体的输出整合成一份可读的报告。我设计了一个聚合模板,包括:宏观逻辑摘要、行业配置建议、个股候选池、风险提示、数据质量说明。聚合过程本身也是一个智能体任务,它的职责是把结构化数据转化为自然语言报告。
实测下来,整个流程从数据采集到报告生成,大约需要40分钟。其中个股筛选智能体耗时最长,因为要对全市场股票逐一评分。如果算力充足,可以并行处理多只股票,时间能压缩到15分钟左右。
4.4 回测与迭代机制
没有回测的框架都是耍流氓。我设计了一套回测机制,用历史数据验证智能体的判断质量。
回测的基本逻辑是:取某个历史时点,用当时可获得的数据跑一遍智能体流程,得到候选股票池,然后看这些股票在之后1个月、3个月、6个月的实际表现。对比基准是同期行业指数。
回测结果我主要看三个指标:胜率(候选股票跑赢基准的比例)、盈亏比(平均盈利幅度/平均亏损幅度)、信息比率(超额收益/跟踪误差)。这三个指标比单纯的收益率更能反映框架的稳定性。
迭代机制是基于回测结果调整智能体的参数和提示词。比如如果发现某个行业的筛选胜率持续偏低,我会检查是该行业的财务指标权重设置不合理,还是数据质量有问题。每次调整后重新回测,确认改进有效后再上线。
这里要提醒一点:避免过拟合。我最初犯的错误是,根据回测结果反复调整参数,直到回测曲线看起来很漂亮。但实盘表现完全不是那么回事。后来我改用滚动回测——用前3年数据调参,用后1年数据验证,确保参数在不同时间段都稳定。
5. 常见问题与排查技巧实录
5.1 智能体输出不稳定的排查思路
智能体输出不稳定是最常见的问题。同样的输入,今天跑出来是A结论,明天跑出来是B结论。排查思路如下:
首先检查温度参数。大模型的温度参数控制输出的随机性,温度越高越随机。我的设置是宏观逻辑和行业比较用0.3,个股筛选用0.1,风险校验用0.0。如果温度设置过高,输出就会飘。
其次检查上下文长度。如果输入数据超过了模型的上下文窗口,模型会截断或丢失信息,导致输出不稳定。我的处理方式是,在数据预处理阶段就做摘要和压缩,确保输入长度在窗口的80%以内。
最后检查提示词的一致性。如果不同智能体的提示词风格差异太大,模型可能会困惑。我统一了提示词的结构:角色定义、任务描述、输入格式、输出格式、约束条件、示例。这个结构在所有智能体中保持一致。
5.2 算力不足时的降级方案
算力不足是常态,尤其是本地部署的时候。我的降级方案分三级:
一级降级:减少并行任务数。原本同时跑5只股票的评分,改成串行跑,时间换空间。
二级降级:降低模型精度。从FP16降到INT8,显存占用减少约40%,精度损失在可接受范围内。
三级降级:切换到云端API。本地完全跑不动的时候,把重推理任务发到云端,本地只做数据预处理和结果展示。
降级方案要提前配置好,不要等到算力不够了才临时找方案。我在调度器里设置了算力监控,当显存占用超过85%时自动触发降级。
5.3 数据质量问题的快速定位
数据质量问题往往表现为智能体输出异常,但根源在数据。快速定位的方法如下:
第一步,检查数据质量报告。我每天生成的数据质量报告会列出缺失率、异常值比例等指标,如果某个指标突然恶化,基本可以定位到数据源。
第二步,做数据抽样对比。从原始数据源随机抽几条记录,和数据库中的记录对比,看是否有偏差。
第三步,检查数据管道的日志。采集层、清洗层、存储层都有日志,看哪个环节报错或超时。
常见的数据质量问题包括:财务数据单位不一致(有的用万元,有的用元)、行情数据复权处理不一致、行业分类标准不统一。这些问题在数据预处理阶段就要解决,不要留给智能体。
5.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| 智能体输出为空 | 输入数据格式错误 | 检查输入JSON是否符合契约 | 修正数据格式,增加格式校验 |
| 输出结论前后矛盾 | 温度参数过高 | 检查温度设置 | 降低温度至0.1-0.3 |
| 推理速度突然变慢 | 显存不足触发交换 | 监控显存占用 | 启用量化或减少并行任务 |
| 财务指标计算错误 | 数据单位不一致 | 抽样对比原始数据 | 统一单位,增加单位校验 |
| 行业排序与预期不符 | 权重设置不合理 | 检查各维度权重 | 根据回测结果调整权重 |
| 风险校验漏报 | 阈值设置过宽 | 检查风险阈值 | 收紧阈值,增加人工复核 |
| 数据更新延迟 | 数据源接口异常 | 检查采集日志 | 增加备用数据源,设置告警 |
5.5 实操心得与避坑指南
第一条心得:不要追求一步到位。我最初想搭建一个全自动的智能体系统,结果发现每个环节都有坑,最后改成半自动——智能体负责信息处理和初步筛选,人负责最终决策和风险把控。这样既提高了效率,又保留了必要的控制权。
第二条心得:日志比结果重要。智能体的输出结果只是冰山一角,真正有价值的是日志——记录了每个环节的输入、输出、耗时、错误信息。我通过分析日志发现了很多隐藏问题,比如某个数据源在特定时间段会返回空值,某个智能体在处理特定行业时耗时异常。
第三条心得:定期做人工复核。即使智能体输出看起来很合理,也要定期做人工复核。我每周会随机抽取几只候选股票,人工检查智能体的评分依据是否合理。这个习惯帮我发现过几次智能体的系统性偏差,比如对某个行业的估值方法选择不当。
第四条心得:保持框架的简单性。我试过加入很多花哨的功能,比如情绪分析、另类数据、高频信号,结果发现大部分功能对最终结果的贡献很小,反而增加了系统的复杂度和维护成本。现在我的原则是:每个新增功能必须能通过回测证明其增量价值,否则不加。
6. AI安全与风控底线的工程化落地
6.1 提示词注入与数据投毒的防范
AI安全在投资场景下不是抽象概念,而是实实在在的风险。我遇到过两种情况:一是新闻数据中混入了带有引导性的文本,试图影响智能体的判断;二是财务数据被异常值污染,导致评分失真。
防范提示词注入的核心原则是输入隔离。所有外部数据在进入智能体之前,都要经过清洗和标记。我在数据预处理阶段会做三件事:去除HTML标签和特殊字符、识别并标记可能的引导性文本、对数值数据做异常值检测。智能体的系统提示词中明确要求:只基于标记为可信的数据做判断,忽略任何未标记的指令性文本。
数据投毒的防范更复杂。我的做法是多源交叉验证。同一份财务数据,至少从两个独立数据源获取,如果差异超过阈值,就触发人工复核。新闻数据也是类似,同一事件至少从两个来源确认后才纳入分析。
6.2 输出内容的合规校验
智能体的输出必须经过合规校验才能展示。我设计了一个合规校验智能体,它的职责是检查输出内容是否包含:具体的买卖指令、收益承诺、未经证实的信息、敏感表述。
合规校验的规则是硬编码的,不依赖大模型判断。比如,如果输出中包含“保证收益”“稳赚不赔”等词汇,直接拦截。如果输出中给出了具体的买入价格和仓位建议,标记为需要人工复核。
这个环节看似简单,但非常重要。投资相关的输出一旦出问题,后果可能很严重。我的原则是:宁可漏报,不可错报。合规校验的阈值设置得比较严格,确保输出内容安全可控。
6.3 系统权限与数据隔离
整套系统涉及大量敏感数据,权限管理必须到位。我的设计是:
- 数据层:不同智能体只能访问自己需要的数据表,通过数据库视图实现隔离。
- 应用层:智能体之间的通信通过消息队列,消息内容加密,防止中间人攻击。
- 展示层:最终报告只展示聚合结果,不展示原始数据和中间过程。
本地部署的好处是数据不出本地,安全性相对可控。如果使用云端API,要确保数据传输加密,并且仔细阅读服务商的隐私政策,确认数据不会被用于模型训练。
6.4 风控规则的人工兜底机制
无论智能体多智能,最终的风控底线必须由人来守。我设置了三条人工兜底规则:
第一条:单只股票仓位上限。无论智能体给出多高的评分,单只股票仓位不得超过总仓位的10%。这条规则硬编码在交易执行环节,智能体无法绕过。
第二条:单日最大回撤触发暂停。如果组合单日回撤超过3%,自动暂停所有智能体的买入建议,转为人工复核模式。
第三条:定期人工审查。每周日我会花2小时审查过去一周的所有智能体输出和实际交易记录,检查是否有异常模式。
这三条规则看起来简单,但它们是整个系统的安全网。我见过太多因为过度信任自动化系统而导致的亏损案例,保持人工兜底机制是长期存活的关键。
7. 框架的扩展方向与个人体会
这套框架目前跑了大半年,整体运行稳定,信息处理效率比纯人工提升了大概3-4倍。但我也清楚它的边界:它擅长处理结构化信息和逻辑推演,不擅长应对突发性事件和情绪驱动的市场波动。
后续我计划从两个方向扩展。一是多模态能力,把图表识别和语音纪要纳入输入范围,这样能处理更多类型的信息。二是个性化适配,根据不同的投资风格(价值、成长、趋势)调整智能体的权重和提示词,让框架更灵活。
最后分享一个我在实操中体会最深的原则:AI智能体是放大器,不是替代品。它能放大你的逻辑优势,也能放大你的逻辑缺陷。如果你本身的投资逻辑是混乱的,智能体只会让混乱来得更快。所以,在搭建框架之前,先把自己的投资逻辑想清楚、写下来、验证过,然后再用智能体去执行和优化。这个顺序不能反。