1. 从能跑到敢用AI投研系统到底难在哪做投研的人这两年应该都有同感让一个大模型帮你读财报、写摘要、拉数据这件事早就没有门槛了。真正让人头疼的是当你把一套AI系统真正接进投研流程让它每天自动跑、自动出结论、自动给信号的时候你会发现它错得离谱而且错得毫无规律。今天它把某家公司的毛利率算错了明天它把两个季度的数据张冠李戴后天它干脆编了一个根本不存在的公告出来。你盯着屏幕心里只有一个念头这东西我敢拿它做决策吗这就是AI投研系统最核心的矛盾——生成能力过剩可靠性严重不足。投研这个场景和写文案、做客服完全不是一回事。写文案错了改一改就行客服答偏了用户顶多骂两句。但投研的每一个数字、每一条结论背后都连着真金白银的仓位。一个数据错误可能导致一次错误的买入一次错误的买入可能吃掉半年的收益。所以投研系统对AI的要求从来不是聪明而是稳、准、可追溯、可复现。我见过太多团队的做法是拿一个通用大模型套一个提示词模板接几个数据接口就号称做了一套AI投研系统。这种系统在演示的时候光鲜亮丽一旦进入实盘环境问题会像潮水一样涌出来。数据源格式不统一、模型幻觉无法约束、多步推理中间态丢失、结论无法回溯到原始数据、并发一上来就崩、成本失控……每一个问题单独看都不致命叠在一起就是灾难。所以这篇文章我想聊的不是怎么调用大模型API这种入门话题而是如何从工程架构层面设计一套真正能在投研场景下扛住压力的AI系统。核心会围绕几个关键词展开Agent、LLM、Multi-Agents、Alpha。我会把踩过的坑、做过的取舍、验证过的方案都摊开讲尽量让不同基础的读者都能拿到能直接抄的东西。如果你正在做或者准备做AI投研相关的系统这篇应该能帮你少走至少半年的弯路。2. 投研场景对AI系统的真实需求拆解2.1 投研不是问答是一条有状态的流水线很多人对AI投研的想象是我问一个问题AI给我一个答案。这个想象从根上就错了。真实的投研工作是一条有状态、多阶段、可回溯的流水线。它大致长这样先确定研究标的和范围然后拉取多源数据财报、公告、行情、研报、新闻接着做数据清洗和结构化再做多维度分析财务、估值、行业对比、事件驱动最后形成结论和信号并且这个结论要能被复盘。注意这里的关键词是有状态。第二步的分析依赖第一步清洗后的数据第三步的结论依赖第二步的分析结果。如果中间任何一步的状态丢了整条链路就断了。而通用大模型的对话是无状态的你每次调用它它都是失忆的。这就是为什么直接把大模型塞进投研流程会出问题——它记不住上下文也管不了流程。所以设计AI投研系统的第一原则是把流程编排和数据状态管理从模型里剥离出来交给专门的编排层去做。模型只负责它最擅长的事——在给定上下文下做推理和生成。流程怎么走、状态怎么存、数据怎么传这些是工程问题不该让模型操心。2.2 数据源异构是绕不过去的第一道坎投研数据源的异构程度没做过的人很难想象。财报是PDF公告是HTML行情是结构化表格研报是长文本新闻是流式数据。同一个财务指标不同数据源的字段名、单位、口径可能都不一样。更麻烦的是很多关键信息藏在非结构化文本里比如管理层讨论、风险提示、关联交易说明。我踩过的一个典型坑是早期系统直接让模型去读原始PDF结果模型把表格里的数字读串行了把营业收入和营业成本搞混。后来我们改成先用专门的解析工具把PDF转成结构化数据再让模型基于结构化数据做分析准确率立刻上了一个台阶。这个教训很朴素但很重要不要让模型做它不擅长的事数据预处理该用传统工具就用传统工具。具体来说数据层要做三件事。第一是统一schema把所有数据源映射到一套标准字段上比如统一用revenue、net_profit、gross_margin这样的字段名。第二是保留原始出处每一条结构化数据都要记录它来自哪个文件、哪一页、哪个段落这是后面可追溯的基础。第三是做数据质量校验比如同比环比是否合理、单位是否一致、缺失值怎么处理这些校验规则要前置不能等模型分析完了才发现数据是错的。2.3 可追溯性不是加分项是生死线在投研场景里一个结论如果无法追溯到原始数据那它就没有任何价值。因为投研的本质是基于证据做判断你告诉基金经理这家公司值得买他第一反应一定是凭什么。如果AI给不出证据链这个结论就是废的。可追溯性要求系统在每一个环节都留下痕迹这条结论用了哪些数据、经过了哪些分析步骤、每一步的中间结果是什么、模型在每一步的输入输出是什么。这听起来简单做起来非常繁琐因为它要求整个系统是可观测的。我们后来的做法是给每个研究任务分配一个全局ID所有相关的数据、中间态、模型调用、结论都挂在这个ID下形成一个完整的执行树。复盘的时候顺着这棵树就能还原整个推理过程。提示可追溯性要在系统设计的第一天就考虑不要等系统跑起来了再补。补的成本是重做的成本。3. Agent架构选型单Agent、Multi-Agents还是工作流3.1 单Agent看起来很美好但很快会撞墙刚开始做的时候最容易想到的方案是搞一个全能Agent给它一堆工具读财报、拉行情、算指标、写报告让它自己决定什么时候用哪个工具。这个方案在demo阶段确实很惊艳Agent会自己规划步骤、自己调用工具、自己总结结论。但一旦任务变复杂单Agent的问题就暴露了。第一是上下文爆炸投研任务动辄要处理几十份文档、上百个数据点全塞进一个上下文里模型要么超长截断要么注意力涣散。第二是工具选择混乱工具一多模型经常选错工具或者该用A工具的时候用了B工具。第三是错误累积单Agent是一条链走到底前面错一步后面全错而且很难定位是哪一步错的。我实测下来的结论是单Agent适合处理边界清晰、步骤少、工具少的任务比如帮我查一下某公司最新的市盈率。但投研的核心任务——综合分析一家公司——远远超出了单Agent的能力边界。3.2 Multi-Agents不是万能药分工方式才是关键既然单Agent扛不住自然就想到Multi-Agents。但这里有个巨大的误区很多人以为Multi-Agents就是多开几个Agent让它们聊天结果搞出来的系统比单Agent还乱。Agent之间互相甩锅、重复劳动、结论冲突最后你都不知道该信谁。Multi-Agents能不能work核心不在数量而在分工方式。我总结下来投研场景下有效的分工方式有三种。第一种是按数据维度分工。一个Agent专门负责财务数据分析一个专门负责行情和估值一个专门负责新闻和事件驱动一个专门负责行业对比。每个Agent只处理自己那一块数据输出结构化的中间结论。这种分工的好处是每个Agent的上下文都很干净专注度高错误不容易跨域传播。第二种是按分析阶段分工。数据清洗Agent、指标计算Agent、逻辑推理Agent、结论生成Agent、事实核查Agent各管一段。这种分工适合流程标准化程度高的场景每个阶段的输入输出都有明确契约。第三种是按角色分工也就是常说的辩论式架构。一个Agent扮演多头一个扮演空头一个扮演中立裁判让它们基于同一份数据从不同角度论证最后裁判Agent综合各方观点给出结论。这种架构在投研里特别有价值因为投研本身就是一个多空博弈的过程单一视角很容易有盲区。分工方式适用场景优势风险按数据维度多源数据综合分析上下文干净、专注度高跨维度关联分析弱按分析阶段流程标准化任务契约清晰、易调试阶段间传递损耗按角色辩论需要多视角判断减少单一视角盲区成本高、可能僵持3.3 我的实际选择工作流为主Agent为辅经过几轮迭代我们最终采用的架构是以确定性工作流为骨架在关键节点嵌入Agent。什么意思呢就是整个投研流程的步骤是预先定义好的、确定性的比如拉数据→清洗→算指标→分析→生成结论→核查这个骨架不交给模型去规划。但在每个节点内部用Agent来处理那些需要灵活推理的部分。这么设计的原因很实在投研流程本身是相对固定的没必要让模型去重新发明流程。让模型规划流程既不稳定又浪费token。而流程中真正需要模型智能的地方是给定这些数据怎么分析这个异常怎么解释这个结论是否站得住脚这些才是Agent该发力的地方。这个架构还有个好处是可调试。因为骨架是确定的出问题的时候你能快速定位是哪个节点出的问题。如果是纯Agent自主规划出了问题你连从哪查起都不知道。4. LLM在投研链路中的正确打开方式4.1 别让LLM做算术让它做它擅长的这是我最想强调的一点。大模型做算术是不可靠的尤其是多步计算和涉及大数字的计算。你让它算营收增长率它可能给你一个看起来合理但完全错误的数字。这不是模型不够强而是它的本质是概率生成不是精确计算。正确的做法是所有数值计算交给确定性代码LLM只负责理解、推理和表达。比如计算财务比率用Python写死公式输入原始数据输出精确结果。LLM拿到这个精确结果后负责解释这个比率说明了什么和同行比处于什么水平可能的原因是什么。我们内部有个原则叫数字不过模型手。意思是任何要进入最终结论的数字都必须来自确定性计算不能是模型生成的。模型可以引用数字但不能创造数字。这条原则执行下来数据错误率下降了九成以上。4.2 结构化输出是约束幻觉的第一道防线LLM的输出是自由文本但投研系统需要的是结构化数据。如果你让模型自由发挥它每次输出的格式都不一样下游根本没法处理。所以必须强制模型输出结构化格式比如JSON。但光说请输出JSON是不够的模型经常会在JSON外面包一层解释文字或者字段名对不上。我们的做法是用schema约束输出明确告诉模型每个字段的名称、类型、含义并且用工具做输出校验格式不对就重试。重试的时候把校验错误信息一起喂回去模型通常第二次就能改对。这里有个细节schema要尽量简单。我见过有人设计了几十个字段的复杂schema结果模型根本填不对。字段越少、层级越浅模型输出越稳定。如果确实需要复杂结构拆成多次调用每次输出一小块。4.3 上下文管理给模型喂它真正需要的东西投研任务的上下文很容易失控。一份年报几万字十份年报就是几十万字全塞进去模型直接懵。所以上下文管理是必须做的功课。我们的策略是分层检索按需注入。先把所有文档切片、建索引然后根据当前任务的需要检索出最相关的片段注入上下文。比如分析毛利率的时候只注入和成本、收入相关的段落而不是整份年报。这样既控制了上下文长度又提高了信噪比。还有一个技巧是中间结论的压缩。多步推理的时候前面的中间结论不要原样传递而是压缩成简洁的结构化摘要再传给下一步。这样既保留了关键信息又避免了上下文膨胀。注意上下文不是越多越好。无关信息会稀释模型的注意力反而降低准确率。宁可少而精不要多而杂。4.4 用LLM as Judge做质量兜底投研结论生成之后怎么保证质量我们的做法是加一道LLM as Judge的核查环节。用一个独立的模型最好是不同厂商的模型避免同源偏差来审查生成的结论检查几个维度结论是否有数据支撑、数据引用是否准确、逻辑是否自洽、是否有明显的遗漏或偏见。这个Judge不是万能的它自己也可能出错。但实测下来它能拦下相当一部分明显的问题比如结论和数据对不上、逻辑跳跃、遗漏关键风险。关键是Judge的提示词要设计得足够严格让它扮演一个挑剔的审稿人而不是一个和事佬。5. 让系统扛住并发与成本的双重压力5.1 并发不是加机器就能解决的投研系统的一个特点是任务突发性强。开盘前后、财报季、重大事件发生时任务量会瞬间暴涨。如果系统扛不住并发要么任务排队排到天荒地老要么直接崩掉。但AI系统的并发和传统Web系统不一样瓶颈往往不在服务器而在模型API的速率限制和单次调用的延迟。一个复杂的投研任务可能要调用模型几十次每次几秒到几十秒串行跑下来一个任务就要几分钟。如果同时来一百个任务那就是几十分钟的等待。我们的解法是任务分级异步编排。把任务按紧急程度和复杂度分级紧急的走快速通道用更小的模型、更少的推理步骤不紧急的走批量通道可以慢慢跑。同时整个流程异步化任务提交后立即返回结果通过回调或轮询获取。这样用户不会干等系统也能更平滑地调度资源。5.2 缓存能省下的钱超出你想象AI投研系统的成本大头是模型调用。但你会发现很多调用是重复的。比如同一份财报今天分析过了明天可能又要分析同一个指标多个任务都要算。如果不做缓存就是在烧钱。我们的缓存策略分三层。第一层是数据缓存原始数据和清洗后的数据缓存起来避免重复拉取和解析。第二层是计算缓存确定性计算的结果缓存起来同样的输入直接返回结果。第三层是模型缓存相同或高度相似的模型调用直接复用之前的输出。第三层要小心因为模型输出有随机性完全相同的输入也可能有不同输出。我们的做法是对确定性任务比如结构化信息抽取做缓存对生成性任务比如写分析报告不做缓存或只做短期缓存。5.3 成本控制要细化到每个任务光做缓存还不够你得知道钱花在哪了。我们给每个任务都做了成本追踪记录它调用了多少次模型、用了多少token、花了多少钱。这样你就能清楚地看到哪些任务成本高、哪些环节是成本大户。实测下来成本大户往往是上下文过长和无效重试。上下文过长好理解喂的token多自然贵。无效重试则是说模型输出格式不对就重试但如果提示词本身有问题重试多少次都是白搭。所以重试要有上限超过上限就报错让人来介入而不是无限烧钱。成本优化手段预期节省实施难度注意事项数据缓存20-30%低注意数据时效性计算缓存10-20%低输入需完全一致上下文压缩30-50%中别压掉关键信息模型分级20-40%中小模型质量要验证重试上限5-15%低上限后要告警6. 从数据到Alpha信号生成与验证的闭环6.1 Alpha不是模型拍脑袋拍出来的聊到投研绕不开Alpha这个词。很多人对AI投研的期待就是让AI帮我找到Alpha。但这里有个根本性的误解Alpha不是模型生成的是模型从数据里发现的。模型本身不产生超额收益它只是一个更高效的信息处理工具。所以设计信号生成模块的时候思路要摆正不是让模型想出一个信号而是让模型基于结构化的数据和明确的分析框架输出可验证的判断。比如模型可以基于财务数据判断这家公司的盈利质量在改善但盈利质量改善能不能转化为Alpha需要回测来验证不是模型说了算。6.2 信号必须可回测、可归因一个信号如果没法回测那它就是玄学。所以信号生成模块的输出必须是结构化的、可回测的。具体来说每个信号要包含信号方向看多/看空/中性、信号强度、触发依据哪些数据、哪些逻辑、有效期、以及历史类似信号的表现。可归因同样重要。当信号失效的时候你要能分析出是哪个环节出了问题——是数据错了、逻辑错了、还是市场环境变了。如果信号是个黑盒失效了你只能干瞪眼。我们的做法是给每个信号建立完整的证据链从原始数据到中间分析到最终信号每一步都可追溯。这样信号失效的时候可以逐层排查快速定位问题。6.3 人机协同AI给判断人做决策最后想说一个态度问题。AI投研系统的定位应该是决策支持不是决策替代。AI可以处理海量数据、可以不知疲倦地扫描、可以给出多角度的分析但最终的决策必须由人来做。因为投研不只是数据处理还涉及对市场情绪、政策环境、管理层能力等难以量化的因素的判断这些是AI的短板。所以好的AI投研系统应该是把AI的判断和证据清晰地呈现给人让人在充分信息的基础上做决策。而不是给一个黑盒结论让人盲从。我们系统里所有的AI结论都会附带置信度、证据链和反方观点让使用者能自己判断该信多少。7. 几个我踩过的坑和对应的解法7.1 模型版本升级导致的静默失效这个坑很隐蔽。我们系统上线后跑得挺稳结果某天模型厂商悄悄升级了模型版本输出风格变了导致下游的解析逻辑全部失效。更坑的是系统没有报错只是结论质量悄悄下降了过了好几天才发现。解法是锁定模型版本并且在系统里加输出质量监控。锁定版本好理解就是明确指定用哪个版本的模型不自动升级。质量监控则是定期用一组标准测试用例跑一遍系统对比输出是否稳定一旦发现异常立即告警。7.2 数据源的脏数据污染整条链路有一次系统给出的结论明显离谱排查了半天发现是某个数据源的一个字段单位错了把万元当成了元导致数值放大了万倍。这个错误一路传到了最终结论中间没有任何环节发现。解法是在数据入口做严格校验。我们后来加了一套数据质量规则比如数值范围检查、同比环比合理性检查、单位一致性检查任何数据进系统前都要过这一关。校验不通过的数据直接拦截并告警让人工介入。7.3 多Agent之间的踢皮球早期做Multi-Agents的时候遇到过Agent之间互相推诿的情况。一个Agent说这个该另一个Agent处理另一个说这不是我的职责范围结果任务卡住了。解法是明确每个Agent的职责边界和输入输出契约。每个Agent只接受特定格式的输入只输出特定格式的结果职责之外的事情直接报错不允许转交。同时加一个总控Agent负责调度和兜底当某个Agent无法处理时由总控决定下一步怎么办。7.4 上下文丢失导致的失忆多步推理的时候如果中间态没保存好后面的步骤就失忆了。比如分析到第三步的时候模型忘了第一步的数据是什么开始胡编。解法是显式传递上下文。不要指望模型自己记住每一步都把需要的前置信息明确地注入到当前步骤的上下文里。同时用结构化的方式组织上下文让模型能清楚地看到已知什么、要做什么、输出什么。8. 一些关于工程实践的个人体会做AI投研系统这两年最大的体会是这活儿的难点不在AI在工程。模型能力每年都在涨很多今天需要费劲解决的问题明年可能模型自己就解决了。但工程架构、数据治理、流程编排、质量保障这些东西是模型进步替代不了的必须自己扎扎实实做。另一个体会是不要追求一步到位。我见过太多团队想一开始就搭一个完美的Multi-Agents系统结果陷在架构里出不来。更务实的做法是先用最简单的方式跑通闭环哪怕就是一个工作流加几个模型调用先让它能出结果然后再逐步优化。系统是迭代出来的不是设计出来的。还有就是保持对模型的怀疑。不管模型多强在投研这种高 stakes 的场景下永远要假设它可能出错永远要有核查和兜底机制。信任但要验证这句话在AI投研里尤其适用。最后分享一个我觉得特别有用的习惯给系统建一个错误博物馆。每次发现系统出错不管是数据错误、逻辑错误还是模型幻觉都把案例记录下来分析根因然后看能不能加一条规则或一个检查来防止类似错误。时间长了这个博物馆就成了系统最宝贵的资产因为它记录了所有踩过的坑也见证了系统一步步变可靠的过程。
AI投研系统架构实战：从单Agent到Multi-Agents的工程化落地
1. 从能跑到敢用AI投研系统到底难在哪做投研的人这两年应该都有同感让一个大模型帮你读财报、写摘要、拉数据这件事早就没有门槛了。真正让人头疼的是当你把一套AI系统真正接进投研流程让它每天自动跑、自动出结论、自动给信号的时候你会发现它错得离谱而且错得毫无规律。今天它把某家公司的毛利率算错了明天它把两个季度的数据张冠李戴后天它干脆编了一个根本不存在的公告出来。你盯着屏幕心里只有一个念头这东西我敢拿它做决策吗这就是AI投研系统最核心的矛盾——生成能力过剩可靠性严重不足。投研这个场景和写文案、做客服完全不是一回事。写文案错了改一改就行客服答偏了用户顶多骂两句。但投研的每一个数字、每一条结论背后都连着真金白银的仓位。一个数据错误可能导致一次错误的买入一次错误的买入可能吃掉半年的收益。所以投研系统对AI的要求从来不是聪明而是稳、准、可追溯、可复现。我见过太多团队的做法是拿一个通用大模型套一个提示词模板接几个数据接口就号称做了一套AI投研系统。这种系统在演示的时候光鲜亮丽一旦进入实盘环境问题会像潮水一样涌出来。数据源格式不统一、模型幻觉无法约束、多步推理中间态丢失、结论无法回溯到原始数据、并发一上来就崩、成本失控……每一个问题单独看都不致命叠在一起就是灾难。所以这篇文章我想聊的不是怎么调用大模型API这种入门话题而是如何从工程架构层面设计一套真正能在投研场景下扛住压力的AI系统。核心会围绕几个关键词展开Agent、LLM、Multi-Agents、Alpha。我会把踩过的坑、做过的取舍、验证过的方案都摊开讲尽量让不同基础的读者都能拿到能直接抄的东西。如果你正在做或者准备做AI投研相关的系统这篇应该能帮你少走至少半年的弯路。2. 投研场景对AI系统的真实需求拆解2.1 投研不是问答是一条有状态的流水线很多人对AI投研的想象是我问一个问题AI给我一个答案。这个想象从根上就错了。真实的投研工作是一条有状态、多阶段、可回溯的流水线。它大致长这样先确定研究标的和范围然后拉取多源数据财报、公告、行情、研报、新闻接着做数据清洗和结构化再做多维度分析财务、估值、行业对比、事件驱动最后形成结论和信号并且这个结论要能被复盘。注意这里的关键词是有状态。第二步的分析依赖第一步清洗后的数据第三步的结论依赖第二步的分析结果。如果中间任何一步的状态丢了整条链路就断了。而通用大模型的对话是无状态的你每次调用它它都是失忆的。这就是为什么直接把大模型塞进投研流程会出问题——它记不住上下文也管不了流程。所以设计AI投研系统的第一原则是把流程编排和数据状态管理从模型里剥离出来交给专门的编排层去做。模型只负责它最擅长的事——在给定上下文下做推理和生成。流程怎么走、状态怎么存、数据怎么传这些是工程问题不该让模型操心。2.2 数据源异构是绕不过去的第一道坎投研数据源的异构程度没做过的人很难想象。财报是PDF公告是HTML行情是结构化表格研报是长文本新闻是流式数据。同一个财务指标不同数据源的字段名、单位、口径可能都不一样。更麻烦的是很多关键信息藏在非结构化文本里比如管理层讨论、风险提示、关联交易说明。我踩过的一个典型坑是早期系统直接让模型去读原始PDF结果模型把表格里的数字读串行了把营业收入和营业成本搞混。后来我们改成先用专门的解析工具把PDF转成结构化数据再让模型基于结构化数据做分析准确率立刻上了一个台阶。这个教训很朴素但很重要不要让模型做它不擅长的事数据预处理该用传统工具就用传统工具。具体来说数据层要做三件事。第一是统一schema把所有数据源映射到一套标准字段上比如统一用revenue、net_profit、gross_margin这样的字段名。第二是保留原始出处每一条结构化数据都要记录它来自哪个文件、哪一页、哪个段落这是后面可追溯的基础。第三是做数据质量校验比如同比环比是否合理、单位是否一致、缺失值怎么处理这些校验规则要前置不能等模型分析完了才发现数据是错的。2.3 可追溯性不是加分项是生死线在投研场景里一个结论如果无法追溯到原始数据那它就没有任何价值。因为投研的本质是基于证据做判断你告诉基金经理这家公司值得买他第一反应一定是凭什么。如果AI给不出证据链这个结论就是废的。可追溯性要求系统在每一个环节都留下痕迹这条结论用了哪些数据、经过了哪些分析步骤、每一步的中间结果是什么、模型在每一步的输入输出是什么。这听起来简单做起来非常繁琐因为它要求整个系统是可观测的。我们后来的做法是给每个研究任务分配一个全局ID所有相关的数据、中间态、模型调用、结论都挂在这个ID下形成一个完整的执行树。复盘的时候顺着这棵树就能还原整个推理过程。提示可追溯性要在系统设计的第一天就考虑不要等系统跑起来了再补。补的成本是重做的成本。3. Agent架构选型单Agent、Multi-Agents还是工作流3.1 单Agent看起来很美好但很快会撞墙刚开始做的时候最容易想到的方案是搞一个全能Agent给它一堆工具读财报、拉行情、算指标、写报告让它自己决定什么时候用哪个工具。这个方案在demo阶段确实很惊艳Agent会自己规划步骤、自己调用工具、自己总结结论。但一旦任务变复杂单Agent的问题就暴露了。第一是上下文爆炸投研任务动辄要处理几十份文档、上百个数据点全塞进一个上下文里模型要么超长截断要么注意力涣散。第二是工具选择混乱工具一多模型经常选错工具或者该用A工具的时候用了B工具。第三是错误累积单Agent是一条链走到底前面错一步后面全错而且很难定位是哪一步错的。我实测下来的结论是单Agent适合处理边界清晰、步骤少、工具少的任务比如帮我查一下某公司最新的市盈率。但投研的核心任务——综合分析一家公司——远远超出了单Agent的能力边界。3.2 Multi-Agents不是万能药分工方式才是关键既然单Agent扛不住自然就想到Multi-Agents。但这里有个巨大的误区很多人以为Multi-Agents就是多开几个Agent让它们聊天结果搞出来的系统比单Agent还乱。Agent之间互相甩锅、重复劳动、结论冲突最后你都不知道该信谁。Multi-Agents能不能work核心不在数量而在分工方式。我总结下来投研场景下有效的分工方式有三种。第一种是按数据维度分工。一个Agent专门负责财务数据分析一个专门负责行情和估值一个专门负责新闻和事件驱动一个专门负责行业对比。每个Agent只处理自己那一块数据输出结构化的中间结论。这种分工的好处是每个Agent的上下文都很干净专注度高错误不容易跨域传播。第二种是按分析阶段分工。数据清洗Agent、指标计算Agent、逻辑推理Agent、结论生成Agent、事实核查Agent各管一段。这种分工适合流程标准化程度高的场景每个阶段的输入输出都有明确契约。第三种是按角色分工也就是常说的辩论式架构。一个Agent扮演多头一个扮演空头一个扮演中立裁判让它们基于同一份数据从不同角度论证最后裁判Agent综合各方观点给出结论。这种架构在投研里特别有价值因为投研本身就是一个多空博弈的过程单一视角很容易有盲区。分工方式适用场景优势风险按数据维度多源数据综合分析上下文干净、专注度高跨维度关联分析弱按分析阶段流程标准化任务契约清晰、易调试阶段间传递损耗按角色辩论需要多视角判断减少单一视角盲区成本高、可能僵持3.3 我的实际选择工作流为主Agent为辅经过几轮迭代我们最终采用的架构是以确定性工作流为骨架在关键节点嵌入Agent。什么意思呢就是整个投研流程的步骤是预先定义好的、确定性的比如拉数据→清洗→算指标→分析→生成结论→核查这个骨架不交给模型去规划。但在每个节点内部用Agent来处理那些需要灵活推理的部分。这么设计的原因很实在投研流程本身是相对固定的没必要让模型去重新发明流程。让模型规划流程既不稳定又浪费token。而流程中真正需要模型智能的地方是给定这些数据怎么分析这个异常怎么解释这个结论是否站得住脚这些才是Agent该发力的地方。这个架构还有个好处是可调试。因为骨架是确定的出问题的时候你能快速定位是哪个节点出的问题。如果是纯Agent自主规划出了问题你连从哪查起都不知道。4. LLM在投研链路中的正确打开方式4.1 别让LLM做算术让它做它擅长的这是我最想强调的一点。大模型做算术是不可靠的尤其是多步计算和涉及大数字的计算。你让它算营收增长率它可能给你一个看起来合理但完全错误的数字。这不是模型不够强而是它的本质是概率生成不是精确计算。正确的做法是所有数值计算交给确定性代码LLM只负责理解、推理和表达。比如计算财务比率用Python写死公式输入原始数据输出精确结果。LLM拿到这个精确结果后负责解释这个比率说明了什么和同行比处于什么水平可能的原因是什么。我们内部有个原则叫数字不过模型手。意思是任何要进入最终结论的数字都必须来自确定性计算不能是模型生成的。模型可以引用数字但不能创造数字。这条原则执行下来数据错误率下降了九成以上。4.2 结构化输出是约束幻觉的第一道防线LLM的输出是自由文本但投研系统需要的是结构化数据。如果你让模型自由发挥它每次输出的格式都不一样下游根本没法处理。所以必须强制模型输出结构化格式比如JSON。但光说请输出JSON是不够的模型经常会在JSON外面包一层解释文字或者字段名对不上。我们的做法是用schema约束输出明确告诉模型每个字段的名称、类型、含义并且用工具做输出校验格式不对就重试。重试的时候把校验错误信息一起喂回去模型通常第二次就能改对。这里有个细节schema要尽量简单。我见过有人设计了几十个字段的复杂schema结果模型根本填不对。字段越少、层级越浅模型输出越稳定。如果确实需要复杂结构拆成多次调用每次输出一小块。4.3 上下文管理给模型喂它真正需要的东西投研任务的上下文很容易失控。一份年报几万字十份年报就是几十万字全塞进去模型直接懵。所以上下文管理是必须做的功课。我们的策略是分层检索按需注入。先把所有文档切片、建索引然后根据当前任务的需要检索出最相关的片段注入上下文。比如分析毛利率的时候只注入和成本、收入相关的段落而不是整份年报。这样既控制了上下文长度又提高了信噪比。还有一个技巧是中间结论的压缩。多步推理的时候前面的中间结论不要原样传递而是压缩成简洁的结构化摘要再传给下一步。这样既保留了关键信息又避免了上下文膨胀。注意上下文不是越多越好。无关信息会稀释模型的注意力反而降低准确率。宁可少而精不要多而杂。4.4 用LLM as Judge做质量兜底投研结论生成之后怎么保证质量我们的做法是加一道LLM as Judge的核查环节。用一个独立的模型最好是不同厂商的模型避免同源偏差来审查生成的结论检查几个维度结论是否有数据支撑、数据引用是否准确、逻辑是否自洽、是否有明显的遗漏或偏见。这个Judge不是万能的它自己也可能出错。但实测下来它能拦下相当一部分明显的问题比如结论和数据对不上、逻辑跳跃、遗漏关键风险。关键是Judge的提示词要设计得足够严格让它扮演一个挑剔的审稿人而不是一个和事佬。5. 让系统扛住并发与成本的双重压力5.1 并发不是加机器就能解决的投研系统的一个特点是任务突发性强。开盘前后、财报季、重大事件发生时任务量会瞬间暴涨。如果系统扛不住并发要么任务排队排到天荒地老要么直接崩掉。但AI系统的并发和传统Web系统不一样瓶颈往往不在服务器而在模型API的速率限制和单次调用的延迟。一个复杂的投研任务可能要调用模型几十次每次几秒到几十秒串行跑下来一个任务就要几分钟。如果同时来一百个任务那就是几十分钟的等待。我们的解法是任务分级异步编排。把任务按紧急程度和复杂度分级紧急的走快速通道用更小的模型、更少的推理步骤不紧急的走批量通道可以慢慢跑。同时整个流程异步化任务提交后立即返回结果通过回调或轮询获取。这样用户不会干等系统也能更平滑地调度资源。5.2 缓存能省下的钱超出你想象AI投研系统的成本大头是模型调用。但你会发现很多调用是重复的。比如同一份财报今天分析过了明天可能又要分析同一个指标多个任务都要算。如果不做缓存就是在烧钱。我们的缓存策略分三层。第一层是数据缓存原始数据和清洗后的数据缓存起来避免重复拉取和解析。第二层是计算缓存确定性计算的结果缓存起来同样的输入直接返回结果。第三层是模型缓存相同或高度相似的模型调用直接复用之前的输出。第三层要小心因为模型输出有随机性完全相同的输入也可能有不同输出。我们的做法是对确定性任务比如结构化信息抽取做缓存对生成性任务比如写分析报告不做缓存或只做短期缓存。5.3 成本控制要细化到每个任务光做缓存还不够你得知道钱花在哪了。我们给每个任务都做了成本追踪记录它调用了多少次模型、用了多少token、花了多少钱。这样你就能清楚地看到哪些任务成本高、哪些环节是成本大户。实测下来成本大户往往是上下文过长和无效重试。上下文过长好理解喂的token多自然贵。无效重试则是说模型输出格式不对就重试但如果提示词本身有问题重试多少次都是白搭。所以重试要有上限超过上限就报错让人来介入而不是无限烧钱。成本优化手段预期节省实施难度注意事项数据缓存20-30%低注意数据时效性计算缓存10-20%低输入需完全一致上下文压缩30-50%中别压掉关键信息模型分级20-40%中小模型质量要验证重试上限5-15%低上限后要告警6. 从数据到Alpha信号生成与验证的闭环6.1 Alpha不是模型拍脑袋拍出来的聊到投研绕不开Alpha这个词。很多人对AI投研的期待就是让AI帮我找到Alpha。但这里有个根本性的误解Alpha不是模型生成的是模型从数据里发现的。模型本身不产生超额收益它只是一个更高效的信息处理工具。所以设计信号生成模块的时候思路要摆正不是让模型想出一个信号而是让模型基于结构化的数据和明确的分析框架输出可验证的判断。比如模型可以基于财务数据判断这家公司的盈利质量在改善但盈利质量改善能不能转化为Alpha需要回测来验证不是模型说了算。6.2 信号必须可回测、可归因一个信号如果没法回测那它就是玄学。所以信号生成模块的输出必须是结构化的、可回测的。具体来说每个信号要包含信号方向看多/看空/中性、信号强度、触发依据哪些数据、哪些逻辑、有效期、以及历史类似信号的表现。可归因同样重要。当信号失效的时候你要能分析出是哪个环节出了问题——是数据错了、逻辑错了、还是市场环境变了。如果信号是个黑盒失效了你只能干瞪眼。我们的做法是给每个信号建立完整的证据链从原始数据到中间分析到最终信号每一步都可追溯。这样信号失效的时候可以逐层排查快速定位问题。6.3 人机协同AI给判断人做决策最后想说一个态度问题。AI投研系统的定位应该是决策支持不是决策替代。AI可以处理海量数据、可以不知疲倦地扫描、可以给出多角度的分析但最终的决策必须由人来做。因为投研不只是数据处理还涉及对市场情绪、政策环境、管理层能力等难以量化的因素的判断这些是AI的短板。所以好的AI投研系统应该是把AI的判断和证据清晰地呈现给人让人在充分信息的基础上做决策。而不是给一个黑盒结论让人盲从。我们系统里所有的AI结论都会附带置信度、证据链和反方观点让使用者能自己判断该信多少。7. 几个我踩过的坑和对应的解法7.1 模型版本升级导致的静默失效这个坑很隐蔽。我们系统上线后跑得挺稳结果某天模型厂商悄悄升级了模型版本输出风格变了导致下游的解析逻辑全部失效。更坑的是系统没有报错只是结论质量悄悄下降了过了好几天才发现。解法是锁定模型版本并且在系统里加输出质量监控。锁定版本好理解就是明确指定用哪个版本的模型不自动升级。质量监控则是定期用一组标准测试用例跑一遍系统对比输出是否稳定一旦发现异常立即告警。7.2 数据源的脏数据污染整条链路有一次系统给出的结论明显离谱排查了半天发现是某个数据源的一个字段单位错了把万元当成了元导致数值放大了万倍。这个错误一路传到了最终结论中间没有任何环节发现。解法是在数据入口做严格校验。我们后来加了一套数据质量规则比如数值范围检查、同比环比合理性检查、单位一致性检查任何数据进系统前都要过这一关。校验不通过的数据直接拦截并告警让人工介入。7.3 多Agent之间的踢皮球早期做Multi-Agents的时候遇到过Agent之间互相推诿的情况。一个Agent说这个该另一个Agent处理另一个说这不是我的职责范围结果任务卡住了。解法是明确每个Agent的职责边界和输入输出契约。每个Agent只接受特定格式的输入只输出特定格式的结果职责之外的事情直接报错不允许转交。同时加一个总控Agent负责调度和兜底当某个Agent无法处理时由总控决定下一步怎么办。7.4 上下文丢失导致的失忆多步推理的时候如果中间态没保存好后面的步骤就失忆了。比如分析到第三步的时候模型忘了第一步的数据是什么开始胡编。解法是显式传递上下文。不要指望模型自己记住每一步都把需要的前置信息明确地注入到当前步骤的上下文里。同时用结构化的方式组织上下文让模型能清楚地看到已知什么、要做什么、输出什么。8. 一些关于工程实践的个人体会做AI投研系统这两年最大的体会是这活儿的难点不在AI在工程。模型能力每年都在涨很多今天需要费劲解决的问题明年可能模型自己就解决了。但工程架构、数据治理、流程编排、质量保障这些东西是模型进步替代不了的必须自己扎扎实实做。另一个体会是不要追求一步到位。我见过太多团队想一开始就搭一个完美的Multi-Agents系统结果陷在架构里出不来。更务实的做法是先用最简单的方式跑通闭环哪怕就是一个工作流加几个模型调用先让它能出结果然后再逐步优化。系统是迭代出来的不是设计出来的。还有就是保持对模型的怀疑。不管模型多强在投研这种高 stakes 的场景下永远要假设它可能出错永远要有核查和兜底机制。信任但要验证这句话在AI投研里尤其适用。最后分享一个我觉得特别有用的习惯给系统建一个错误博物馆。每次发现系统出错不管是数据错误、逻辑错误还是模型幻觉都把案例记录下来分析根因然后看能不能加一条规则或一个检查来防止类似错误。时间长了这个博物馆就成了系统最宝贵的资产因为它记录了所有踩过的坑也见证了系统一步步变可靠的过程。