
1. 虚拟投资机构到底在解决什么问题第一次听到“虚拟投资机构”这个词很多人会以为是那种模拟炒股软件或者是一个给散户练手的沙盒环境。但我这两年跟踪下来它真正的内核要硬核得多用多智能体系统搭出一个完整的投研团队让不同角色的AI agents各司其职完成从信息采集、基本面分析、估值建模到组合再平衡的全链路工作。说白了就是把一家投资机构里研究员、分析师、风控、交易员的活儿拆解成若干个可编排的智能体由大语言模型作为推理内核来驱动。这件事为什么现在值得做因为传统投研有个绕不开的矛盾覆盖广度与挖掘深度天然互斥。一个人类分析师再勤奋一天能精读的研报、财报、公告、产业链数据是有限的通常覆盖二三十家公司就已经接近极限。而市场里有几千个标的大量信息不对称就藏在这些被忽略的角落里。大语言模型的出现改变了一个关键变量——阅读和初步归纳的边际成本被压到了接近于零。你可以让一个agent一夜之间把某条产业链上所有公司的招股书都过一遍提取出产能、客户集中度、毛利率变化这些结构化字段第二天早上直接给你一张对比表。但这里有个常见的误解需要先澄清虚拟投资机构不等于“AI选股神器”。我见过太多项目一上来就宣称能预测涨跌这方向本身就偏了。真正有价值的定位是投研流程的自动化与增强把人类从重复的信息搬运中解放出来专注于判断和决策。人机协同才是关键词AI负责“把材料摆到桌面上”人负责“拍板”。这个边界如果一开始不划清楚项目很容易做成一个花架子。适合读这篇内容的人我大致分三类一是对AI agents感兴趣、想找个真实场景练手的开发者二是金融从业者想理解这套东西到底能帮自己省多少事三是做技术选型的产品或团队负责人需要判断自建虚拟投资机构的可行性和坑在哪里。下面我会按“整体设计思路—核心细节—实操落地—问题排查”这条线把我知道的东西尽量摊开讲。2. 整体架构设计与多智能体角色拆解2.1 为什么是“多智能体”而不是“一个大模型包打天下”刚开始做的时候我也想过偷懒搞一个超长上下文的大模型把一堆资料塞进去让它直接输出投资结论不就完了实测下来这条路走不通原因有三个。第一上下文窗口再大也有注意力衰减。你把几十份财报塞进一个prompt模型对中间部分的细节召回率会明显下降这在需要精确引用数字的场景里是致命的。第二单一模型难以同时兼顾多种推理风格。基本面分析需要严谨的财务逻辑舆情分析需要语义敏感度宏观判断需要长链条推演这些能力用同一个system prompt去约束效果会互相打架。第三可解释性和可调试性差。一个黑盒输出“买入”你根本不知道它是基于哪个数据点得出的出了问题无从排查。多智能体系统的思路是把复杂任务按职能切分每个agent有独立的角色设定、工具集和记忆最后通过一个协调层汇总。这就像真实机构里的分工研究员不会去干交易员的活各管一摊责任清晰。2.2 一个可落地的角色划分方案我目前验证下来比较稳的角色配置是五个核心agent加一个协调器具体分工如下表Agent角色核心职责主要工具/数据源输出物信息采集Agent抓取公告、财报、新闻、行业数据网页解析、PDF抽取、结构化API原始素材库基本面分析Agent财务指标计算、同业对比财务计算库、向量检索分析备忘录估值建模AgentDCF、相对估值、敏感性分析估值模板、参数表估值区间舆情与事件Agent情感分析、事件影响评估文本分类、时间序列事件影响评级风控Agent集中度、波动率、回撤约束风险指标库风险提示清单协调器Agent任务分发、结果汇总、冲突仲裁工作流引擎综合投研报告这个划分不是拍脑袋定的而是照着人类投研团队的实际协作流程反推出来的。你去看任何一家机构的研究报告产出过程基本都逃不开这几个环节。把每个环节抽象成一个agent最大的好处是可以单独迭代——比如你觉得估值环节不准只需要调估值agent的prompt和参数不用动其他部分。2.3 协调器的设计是成败关键很多人做多智能体把精力全花在单个agent的能力上结果协调器做得很粗糙最后输出一锅粥。我的经验是协调器至少要解决三个问题任务依赖排序、结果冲突消解、以及失败重试。任务依赖排序好理解估值必须在基本面分析之后做因为估值要用到基本面算出来的财务预测。冲突消解则更微妙舆情agent可能给出“负面”评级但基本面agent认为财务很健康这时候协调器不能简单取平均而要根据预设的权重和场景规则来仲裁。我的做法是给每个agent的输出附一个置信度分数协调器按置信度加权同时对分歧过大的情况打上“需人工复核”的标记。失败重试这块实际跑起来你会发现数据源不稳定是常态。某个财报PDF解析失败、某个API限流都会导致单个agent卡住。协调器需要有能力检测超时、重新分配任务甚至在多次失败后降级处理——比如用简化版的分析替代完整版保证整体流程不中断。3. 核心技术点拆解与选型考量3.1 大语言模型的选择本地部署还是调用接口这是绕不开的第一个决策。热词里“本地部署大语言模型”出现频率很高说明很多人有这个诉求。我的建议是分场景混合使用不要一刀切。涉及敏感持仓数据、未公开的研究逻辑时优先本地部署。开源模型里70B参数级别的模型在财务文本理解上已经够用量化后单张消费级显卡也能跑起来虽然速度慢点但胜在数据不出域。而通用信息抽取、舆情分类这类任务调用云端接口的性价比更高因为这类任务对模型能力要求相对低用大参数模型是浪费。这里有个参数选择的经验财务数字抽取任务模型的参数量比上下文长度更重要。我试过用一个小参数但超长上下文的模型去抽财报里的科目错误率明显高于中等参数标准上下文的模型。原因是数字抽取考验的是模型的精确记忆和格式遵循能力这跟参数量强相关。3.2 记忆系统的搭建向量库不是万能药多智能体要协同就得有共享记忆。很多人第一反应是上向量数据库把所有资料embedding进去做检索。但实测下来纯向量检索在投研场景有两个硬伤一是财务数字的精确匹配很差你搜“2023年营收”可能召回一堆语义相近但数字不对的段落二是时间敏感信息容易混淆去年的公告和今年的公告在向量空间里可能挨得很近。我的方案是混合记忆架构结构化数据财务科目、日期、金额走关系型数据库或键值存储保证精确查询非结构化文本新闻、研报叙述走向量库负责语义召回。两者通过一个统一的查询接口暴露给agentagent根据任务类型自己选择走哪条路。这个设计多花了一点工程成本但把准确率拉上来了。3.3 工具调用能力的边界AI agents要干活必须能调用外部工具。但这里有个坑不是工具越多越好。我见过一个项目给agent配了三十多个工具结果模型在工具选择上频繁出错该用A的时候用了B。后来砍到八个核心工具准确率反而上去了。核心工具清单我建议控制在十个以内网页抓取、PDF解析、财务计算、向量检索、结构化查询、图表生成、文件读写、以及一个通用的代码执行环境。代码执行环境特别重要因为很多财务计算逻辑用自然语言描述容易有歧义直接让agent写一段Python算出来既准确又可复现。4. 实操落地从零搭一个最小可用版本4.1 环境准备与依赖安装先说明下面这套是我自己跑通的方案基于Python生态。你需要准备的东西不多一台带显卡的机器本地模型推理用Python 3.10以上环境以及一个工作目录。# 创建虚拟环境 python -m venv venv source venv/bin/activate # Windows下用 venv\Scripts\activate # 核心依赖 pip install langchain langgraph chromadb pypdf pandas numpy pip install fastapi uvicorn # 如果要暴露成服务模型这块如果你走本地部署可以用主流的开源推理框架加载量化模型如果调接口就装对应的SDK。我建议先用接口跑通流程再考虑本地化因为流程调试阶段频繁改prompt本地模型每次加载太耗时。4.2 定义第一个Agent信息采集信息采集agent是整个系统的入口它的输出质量直接决定后面所有环节的天花板。我的做法是给它一个明确的任务模板而不是让它自由发挥。# 信息采集agent的任务定义示例伪代码结构 task_template 你的任务从给定来源中提取以下字段 - 公司名称 - 报告期 - 营业收入元 - 净利润元 - 同比增速 - 主要风险提示原文摘录 要求 1. 数字必须精确到原文一致不得四舍五入 2. 如果某字段缺失标注为未披露 3. 风险提示必须原文摘录不得改写 这里的关键是约束输出格式。早期我让agent自由输出结果每个agent返回的格式都不一样协调器解析起来极其痛苦。后来统一用JSON schema约束所有agent的输出都走结构化格式协调器的负担一下子轻了。4.3 搭建协调工作流用LangGraph这类工作流框架可以把agent之间的依赖关系画成图。核心逻辑是信息采集完成后并行触发基本面分析和舆情分析这两个都完成后触发估值建模最后风控agent做一遍检查协调器汇总。# 工作流的核心结构示意 workflow StateGraph(AgentState) workflow.add_node(collector, collector_agent) workflow.add_node(fundamental, fundamental_agent) workflow.add_node(sentiment, sentiment_agent) workflow.add_node(valuation, valuation_agent) workflow.add_node(risk, risk_agent) workflow.add_node(coordinator, coordinator_agent) # 定义依赖 workflow.add_edge(collector, fundamental) workflow.add_edge(collector, sentiment) workflow.add_edge(fundamental, valuation) workflow.add_edge(sentiment, valuation) workflow.add_edge(valuation, risk) workflow.add_edge(risk, coordinator)并行执行是提升效率的关键。基本面分析和舆情分析之间没有依赖让它们同时跑整体耗时能砍掉将近一半。但要注意并行agent如果共享同一个模型实例可能会有资源竞争需要做好并发控制。4.4 参数计算与阈值设定估值建模agent里涉及大量参数我挑一个最典型的DCF折现率设定来讲。折现率不是随便填的它由无风险利率、市场风险溢价和个股beta决定。我的做法是让agent从结构化数据库里拉取这三个数然后按CAPM公式计算def calculate_discount_rate(risk_free_rate, market_premium, beta): 按CAPM计算折现率 risk_free_rate: 无风险利率取十年期国债收益率 market_premium: 市场风险溢价通常取5%-7% beta: 个股相对市场的波动系数 return risk_free_rate beta * market_premium这个计算过程必须让agent显式输出中间步骤而不是直接给结果。因为一旦最终估值偏离预期你需要能回溯到是哪一步的参数出了问题。我踩过的坑就是早期让模型直接给折现率结果它经常凭空编一个数跟市场实际情况对不上。5. 常见问题与排查技巧实录5.1 数字幻觉最危险也最常见大语言模型在财务数字上的幻觉是头号杀手。我遇到过agent把“营收12.3亿”写成“营收123亿”小数点错一位整个估值全废。排查这类问题的核心思路是交叉验证让两个独立的agent分别从不同来源提取同一个数字如果结果不一致就标记出来人工复核。另一个技巧是强制引用原文位置。要求agent在输出每个数字时附带该数字在原文中的页码或段落编号。这样你抽查的时候可以直接定位而不是大海捞针。5.2 Agent卡死与超时处理多智能体系统跑起来最怕的就是某个agent卡住不动整个流程挂起。我的处理方案是三层超时机制单次工具调用超时比如30秒、单个agent任务超时比如5分钟、整个工作流超时比如30分钟。任何一层超时都触发降级或跳过逻辑保证流程能走完。注意降级处理一定要记录日志标明哪些环节被跳过了。否则你拿到一份看似完整的报告实际上关键数据是缺失的这比直接报错更危险。5.3 常见问题速查表问题现象可能原因排查方向解决手段输出数字与原文不符模型幻觉检查是否强制引用原文加交叉验证双agent提取Agent频繁选错工具工具描述不清查看工具定义文档精简工具数量优化描述流程中途卡死某agent超时查看各环节耗时日志加超时降级机制估值结果波动大参数不稳定检查折现率等输入固定参数来源加校验报告前后矛盾协调器仲裁失效检查冲突消解逻辑引入置信度加权5.4 几个我踩过的坑第一个坑是过度依赖单一数据源。早期我只从一个渠道抓数据结果那个渠道改版后整个系统瘫痪。后来改成多源冗余主源失败自动切备源稳定性好了很多。第二个坑是prompt越写越长。我一度觉得prompt写得越详细越好结果模型被一堆约束绕晕了反而抓不住重点。后来学会分层写prompt核心约束放最前面细节要求放后面并且用明确的标记分隔。第三个坑是忽视成本核算。多智能体系统跑一次完整流程如果全用大参数模型token消耗相当可观。我的做法是按任务难度分配模型简单抽取用小模型复杂推理用大模型整体成本能降一半以上。6. 人机协同的边界与后续扩展方向6.1 哪些环节必须留给人跑了一段时间后我越来越确信虚拟投资机构的价值不在于替代人而在于重新分配人的注意力。具体来说有三个环节我坚持留给人来做最终判断。第一是假设的设定。估值模型里最关键的假设比如未来五年的增长率、行业渗透率天花板这些涉及对产业趋势的定性判断AI目前给不出有洞察力的答案它只能基于历史数据外推。第二是异常信号的解读。当系统检测到某个指标异常比如毛利率突然跳升AI能告诉你“这里异常”但为什么异常、是机会还是陷阱需要人来判断。第三是组合层面的取舍。单个标的分析得再好放到整个组合里可能因为相关性过高而不该买这种全局视角目前还是人的强项。6.2 从单次分析到持续跟踪最小可用版本跑通后下一步自然是从“一次性分析”升级到“持续跟踪”。这需要给系统加一个调度层定期比如每天收盘后自动跑一遍关注列表检测是否有重大变化。这里的关键是变化检测不是每次全量重跑而是只对发生变化的字段触发重新分析这样能把算力消耗控制在合理范围。6.3 评估体系的建立没有评估系统就没法迭代。我目前用的评估指标分两类准确性指标数字抽取准确率、事件分类F1值和时效性指标从数据发布到报告生成的时间差。准确性靠人工抽样标注来算时效性靠日志自动统计。这两个指标每周看一次趋势就能知道系统是在变好还是变差。最后分享一个我在实际使用中的体会虚拟投资机构这套东西最大的门槛不在技术而在对投研业务本身的理解。你如果不知道一份合格的投研报告应该长什么样、哪些数据是关键、哪些逻辑必须自洽那再强的多智能体架构也搭不出有用的东西。技术是放大器业务理解才是信号源。我见过太多团队技术很强但业务理解薄弱做出来的东西看着热闹实际没法用。反过来如果你本身就在投研一线待过知道痛点在哪那这套技术能帮你把效率提升一个数量级。