企业官网建设流程全解析

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多自然贵。无效重试则是说，模型输出格式不对就重试，但如果提示词本身有问题，重试多少次都是白搭。所以重试要有上限，超过上限就报错，让人来介入，而不是无限烧钱。

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投研里尤其适用。

最后分享一个我觉得特别有用的习惯：给系统建一个"错误博物馆"。每次发现系统出错，不管是数据错误、逻辑错误还是模型幻觉，都把案例记录下来，分析根因，然后看能不能加一条规则或一个检查来防止类似错误。时间长了，这个博物馆就成了系统最宝贵的资产，因为它记录了所有踩过的坑，也见证了系统一步步变可靠的过程。