1. 为什么“AI投研系统”不是把研报丢给大模型那么简单做投研的人这两年大概都经历过一个阶段看到大模型能读财报、能写摘要、能回答“这家公司毛利率为什么下滑”第一反应就是——那我是不是可以做一个系统把全市场的公告、研报、新闻、行情数据全喂进去然后每天自动出投资建议我一开始也是这么想的。2023年那会儿我用最朴素的方式搭过一版把上市公司公告PDF批量转文本切块塞进向量库然后用一个Prompt让模型回答“这家公司最近有什么风险”。结果跑了两周就发现这东西根本没法用。不是模型不够聪明而是整个系统的设计思路错了。AI投研系统的核心不是“问答”而是“决策支持”。这两者之间有本质区别。问答追求的是“你问什么我答什么”而决策支持追求的是“在信息不完整、时间有限、噪声极大的情况下帮你把关键变量找出来把逻辑链摆清楚把不确定性标出来”。前者是一个检索增强生成RAG问题后者是一个系统工程问题。我后来复盘发现大多数人对AI投研的误解集中在三个地方第一以为数据越多越好。实际上投研场景里信噪比比数据量重要得多。一份年报里真正影响决策的可能就那三五个数字和两段管理层讨论剩下的都是合规性废话。你把整份年报塞给模型它反而容易被无关信息带偏。第二以为一个Prompt就能解决所有问题。投研涉及的工作流很长信息采集、数据清洗、财务建模、可比公司分析、催化剂梳理、风险排查、组合监控。每个环节需要的推理方式不一样用一个通用Prompt去套效果一定稀碎。第三以为模型输出就是终点。实际上模型输出只是中间产物真正的价值在于把模型输出嵌入到一个可验证、可追溯、可迭代的工作流里。你需要知道这个结论是从哪份文件的哪一段推出来的需要知道如果某个假设变了结论会怎么变需要知道模型在哪些地方可能犯错。所以这篇文章我想聊的是怎么从工程角度设计一个真正能用的AI投研系统。不是Demo不是PPT里的架构图而是你明天就能动手搭、下周就能跑起来、下个月就能迭代的东西。我会围绕Agent架构、LLM选型、Prompt工程、Multi-Agents协作、容错机制这几个核心点展开中间会穿插我自己踩过的坑和目前跑得比较稳的方案。适合谁看如果你是有一定编程基础的投研从业者想自己搭一套辅助工具这篇文章可以直接抄作业。如果你是纯业务背景想理解AI投研系统到底能做什么、不能做什么也能从里面的设计思路里拿到一些判断依据。如果你已经在做类似项目欢迎对照着看看有没有可以互相印证的地方。2. 整体架构设计从“单模型问答”到“多Agent流水线”2.1 为什么我最终放弃了“一个大模型包打天下”最早那版系统失败之后我花了大概两个月时间试各种方案。中间试过用GPT-4直接读长文本试过用Claude做财务分析试过用本地部署的开源模型做数据提取。结论很明确没有任何一个单一模型能在投研全流程上都表现良好。原因不复杂。投研任务可以粗略分成几类信息抽取类从公告、财报、新闻里提取结构化数据。这类任务要求模型对格式敏感、对数字准确、对上下文长度有容忍度。逻辑推理类比如“营收增长但现金流恶化可能的原因是什么”。这类任务要求模型有较强的因果推理能力和领域知识。文本生成类写摘要、写风险提示、写投资逻辑。这类任务要求模型语言流畅、风格可控。数值计算类估值模型、财务比率、敏感性分析。这类任务其实不该让LLM做应该交给代码。你让一个模型同时干这四件事它一定会在某个环节掉链子。我实测下来GPT-4在逻辑推理上强但做长文档信息抽取时容易漏字段Claude在长文本理解上稳但数值计算经常出错开源模型做文本生成还行但复杂推理就差一截。所以架构设计的第一原则是按任务类型拆分让合适的模型干合适的事用Agent来编排。2.2 我目前用的三层架构现在跑的系统大致分三层第一层是数据层。这一层不做任何AI相关的事就是老老实实把数据搞干净。包括公告PDF解析、财报表格提取、新闻去重、行情数据对齐。这一层的关键是结构化和可追溯。每一条数据都要能回答“你从哪来的、什么时候来的、原始文件在哪”。第二层是Agent层。这一层是核心。我把投研流程拆成了若干个Agent每个Agent负责一个相对独立的子任务。比如采集Agent监控指定信息源发现新公告或新闻时触发下游流程。抽取Agent从原始文档中提取关键字段输出结构化JSON。分析Agent基于结构化数据做财务分析、可比分析、风险识别。写作Agent把分析结果组织成可读的投研笔记或报告。校验Agent对前面Agent的输出做交叉验证标记可疑结论。每个Agent有自己的Prompt、自己的工具集、自己的输出格式。Agent之间通过一个共享状态对象来传递信息而不是靠自然语言对话。这一点很重要后面会展开讲。第三层是交互层。这一层是给人用的。包括一个简单的Web界面可以查看Agent的运行状态、中间产物、最终输出也包括一个反馈机制让人可以对Agent的输出打标这些标注数据后续用来做Prompt迭代。2.3 为什么用Multi-Agents而不是一个大Workflow有人可能会问你把这些步骤串成一个Workflow不就行了吗为什么要搞Multi-Agents我试过Workflow方案。用LangChain或者类似框架把步骤串起来每一步调一个模型输出传给下一步。这个方案在流程固定的时候没问题但投研场景有两个特点让它很别扭第一流程不是线性的。比如分析Agent发现某个财务指标异常它可能需要回头让抽取Agent重新提取某个字段或者让采集Agent去查一份补充公告。Workflow里做这种回环很麻烦而Agent架构天然支持这种“按需调用”。第二不同任务需要的上下文不一样。抽取Agent只需要看原始文档分析Agent需要看结构化数据加历史数据写作Agent需要看分析结论加模板。如果用一个统一的Workflow你要么把全部上下文传给每一步浪费Token且引入噪声要么做复杂的上下文管理。Agent架构下每个Agent自己管理自己的上下文干净很多。当然Multi-Agents也不是没有代价。最大的代价是调试难度上升。一个Agent输出错了你可能要追好几层才能找到根因。所以我在设计时加了一个原则每个Agent的输出必须可独立验证。也就是说任何一个Agent的输出我都能单独拿出来看判断它对不对而不需要跑完整条链路。2.4 共享状态对象的设计这是我觉得整个系统里最关键的一个设计决策。Agent之间不通过自然语言对话来传递信息而是通过一个结构化的共享状态对象。这个对象大概长这样{ task_id: xxx, company: 某公司, trigger: 新公告, raw_docs: [...], extracted_fields: { revenue: ..., net_profit: ..., cash_flow: ... }, analysis_results: { financial_health: {...}, risk_flags: [...] }, draft_report: ..., validation: { passed: true, warnings: [...] } }每个Agent读取这个对象里自己需要的部分处理完之后把结果写回去。这样做的好处可追溯任何一个结论都能追溯到它是基于哪些字段、哪些原始文档产生的。可测试我可以单独给某个Agent喂一个构造好的状态对象看它输出对不对不需要跑全流程。可替换如果我想换掉分析Agent的模型只要保证输入输出格式不变其他Agent完全不受影响。我踩过的一个坑是早期版本里Agent之间用自然语言传递信息结果上游Agent说“营收增长约15%”下游Agent理解成“营收增长15%左右”再下游变成“营收增长”最后写作Agent写出来的是“营收有所增长”。信息在传递过程中不断损失。改成结构化状态对象之后这个问题彻底消失了。3. 核心Agent的Prompt设计与实操要点3.1 抽取Agent怎么让模型稳定输出结构化数据抽取Agent的任务是从非结构化文档里提取结构化字段。这是整个系统里最基础也最容易出问题的一环。我最早的做法是直接让模型输出JSONPrompt大概是这样“请从以下公告中提取营收、净利润、毛利率以JSON格式输出。”结果模型有时候输出Markdown代码块有时候输出纯JSON有时候字段名对不上有时候数字带单位有时候不带。下游解析经常报错。后来我改成了一套更严格的方案核心是三点第一用JSON Schema约束输出。现在很多模型API支持结构化输出Structured Output你给它一个Schema它保证输出符合这个Schema。如果用的模型不支持就在Prompt里把Schema写清楚并且加一句“只输出JSON不要输出任何其他内容”。第二字段定义要精确到单位和小数位。比如不要写“营收”要写“营业收入单位万元保留两位小数”。不要写“增长率”要写“同比增长率单位百分比保留一位小数”。模型对模糊指令的容忍度比你想象的低。第三加一个“未知处理”规则。如果文档里没有某个字段要求模型输出null而不是瞎编一个数。这一点极其重要。我见过太多次模型在找不到数据时编一个看起来合理的数字出来如果不做校验这种错误会一路传到最终报告里。下面是我现在用的抽取Prompt模板简化版你是一个财务数据抽取助手。请从以下文档中提取指定字段。 要求 1. 只输出JSON不要输出任何解释性文字。 2. 如果某个字段在文档中找不到值设为null不要猜测。 3. 数字字段统一转换为数值类型不要带单位符号。 4. 百分比字段输出小数形式如15.3%输出0.153。 字段定义 - revenue: 营业收入单位万元数值类型 - net_profit: 归母净利润单位万元数值类型 - gross_margin: 毛利率小数形式 - yoy_revenue_growth: 营收同比增长率小数形式 文档内容 {document}实测下来这套Prompt在GPT-4和Claude上的字段准确率能到95%以上。剩下的5%主要是文档格式特别奇葩的情况比如表格跨页、数字被水印遮挡等这些需要在前面的数据层做处理。注意抽取Agent的Prompt不要经常改。每次改完都要用同一批测试文档跑一遍回归确认没有引入新的错误。我一般会维护一个包含50份典型文档的测试集每次改Prompt都跑一遍。3.2 分析Agent怎么让模型做有逻辑的推理而不是瞎编分析Agent是投研系统的核心价值所在。它要做的事情是基于结构化数据回答“这家公司财务健康吗”“这个变化意味着什么”“风险在哪里”。这里最大的挑战是幻觉。模型很擅长编造看起来合理的因果解释。比如你给它一个“营收增长20%净利润增长5%”的数据它可能会说“这是因为公司加大了研发投入”——但实际上文档里根本没提研发投入。我试过几种方案来抑制幻觉方案一让模型只基于给定数据推理不允许引入外部知识。Prompt里明确写“你只能使用以下提供的数据进行分析不要引入任何未在数据中出现的信息”。这个方案能减少一部分幻觉但模型有时候还是会“忍不住”补充。方案二要求模型输出推理链并且每个结论都要标注数据来源。比如“营收增长20%来源extracted_fields.revenue净利润增长5%来源extracted_fields.net_profit两者增速差异显著来源计算”。这个方案效果好很多因为模型知道每个结论都要有出处就不太敢瞎编。方案三用另一个模型做校验。这就是后面要讲的校验Agent。分析Agent输出之后校验Agent检查每个结论是否有数据支撑标记出没有支撑的结论。我现在用的是方案二加方案三的组合。分析Agent的Prompt里强制要求输出推理链和数据来源校验Agent做二次检查。分析Agent的Prompt结构大概是你是一个财务分析助手。基于以下结构化数据分析该公司的财务健康状况。 规则 1. 每个结论必须标注数据来源格式为[来源字段名]。 2. 如果某个判断需要计算请展示计算过程。 3. 不要引入未在数据中出现的信息。 4. 如果数据不足以支持某个结论明确说“数据不足”。 输出格式 { conclusions: [ { statement: 结论内容, evidence: 数据来源和计算过程, confidence: high/medium/low } ], data_gaps: [缺失的数据项] } 数据 {structured_data}这个Prompt跑出来的结果可读性和可验证性都比早期版本好很多。confidence字段也很有用低置信度的结论我会人工复核。3.3 写作Agent怎么让输出像人写的而不是机器写的写作Agent的任务是把分析结果组织成可读的投研笔记。这里的关键是风格控制和信息密度。我早期让模型直接写出来的东西一股AI味“综上所述该公司财务状况整体良好但需关注现金流风险。”这种话放在任何一家公司上都成立等于没说。后来我做了两件事第一给写作Agent提供范例。我把自己以前写的几篇投研笔记整理成模板作为Few-shot示例放进Prompt里。模型会模仿范例的风格、句式、信息密度。第二要求写作Agent输出“有观点”的内容。Prompt里明确写“不要写模棱两可的话每个段落都要有明确判断”。比如不要写“现金流值得关注”要写“经营性现金流连续两个季度低于净利润说明利润质量在下降需要排查应收账款和存货”。写作Agent的Prompt里我还会加一个“禁止词列表”把“综上所述”“整体来看”“值得关注”这类废话词列进去要求模型避免使用。实测下来加了范例和禁止词之后输出质量提升很明显。现在写作Agent产出的初稿我大概改20%就能用早期版本要改80%。3.4 校验Agent怎么给系统加一道保险校验Agent是我觉得最值得投入的一个环节。它的任务是检查前面Agent的输出有没有问题。具体检查什么数据一致性抽取Agent提取的数字和分析Agent引用的数字是否一致。逻辑一致性分析Agent的结论是否和它的推理链一致。来源可追溯每个结论是否都有数据来源标注。格式合规输出是否符合预定义的Schema。校验Agent的Prompt相对简单因为它做的是检查而不是生成你是一个校验助手。请检查以下分析结果是否存在问题。 检查项 1. 每个结论是否有数据来源标注 2. 结论中的数字是否与提供的数据一致 3. 推理链是否存在逻辑跳跃 4. 是否有未标注来源的外部信息 输出格式 { passed: true/false, issues: [ {type: 问题类型, detail: 具体描述, severity: high/medium/low} ] } 分析结果 {analysis_output} 原始数据 {structured_data}校验Agent跑下来大概能抓到10%-15%的问题输出。这些问题如果不抓就会直接呈现给用户影响信任度。实操心得校验Agent的Prompt不要写得太复杂。我试过让校验Agent做很细的检查结果它自己也产生幻觉把没问题的结论标成有问题。后来我把检查项精简到最核心的四项准确率反而上去了。4. Multi-Agents协作与容错机制4.1 Agent之间怎么协作编排模式的选择Multi-Agents系统里Agent之间的协作模式大致有三种第一种是流水线模式。Agent按固定顺序执行A的输出给BB的输出给C。这种模式简单可控但灵活性差。第二种是黑板模式。所有Agent共享一个状态对象每个Agent按需读取和写入。这种模式灵活但需要设计好状态对象的Schema否则容易乱。第三种是协商模式。Agent之间可以互相发消息、讨论、投票。这种模式最灵活但也最难调试。我目前用的是黑板模式为主流水线为辅。主流程是流水线采集→抽取→分析→写作→校验。但在某些环节Agent可以回头调用上游Agent。比如分析Agent发现某个字段缺失可以触发抽取Agent重新提取校验Agent发现问题可以触发分析Agent重新分析。这种混合模式的关键是设置最大回环次数。我设的是每个任务最多回环3次超过3次就标记为“需要人工介入”不再自动重试。这个限制很重要否则系统可能陷入无限循环。4.2 容错设计当模型输出不符合预期时怎么办LLM的输出是不确定的这是做AI系统必须接受的事实。容错设计的核心思路是假设每个环节都会出错然后设计机制来发现和纠正错误。我在系统里加了几层容错第一层是格式校验。每个Agent输出后先检查是否符合预定义的JSON Schema。不符合就重试重试时把错误信息附在Prompt里让模型知道上次哪里错了。第二层是内容校验。格式对了不代表内容对。校验Agent会检查内容的一致性和可追溯性。第三层是降级策略。如果某个Agent连续失败3次系统不会一直卡在那里而是降级处理。比如分析Agent失败就跳过分析直接输出抽取结果并标记“分析环节未完成”。第四层是人工兜底。所有标记为“需要人工介入”的任务会进入一个队列由人工处理。人工处理的结果会作为反馈数据用于后续Prompt迭代。这套容错机制跑下来系统的可用性从早期的60%左右提升到了90%以上。剩下的10%主要是特别复杂的文档或特别罕见的场景这些确实需要人工。4.3 并发处理当同时来了100份公告投研场景里公告往往是批量来的。比如财报季一天可能来几十份甚至上百份公告。如果串行处理根本跑不过来。我的方案是任务队列加Agent池。采集Agent发现新公告后把任务丢进队列。多个抽取Agent实例从队列里取任务并行处理。分析Agent和写作Agent同理。这里有几个参数需要调Agent池大小取决于你的API并发限制和预算。我一般设5-10个并发。任务超时时间单个任务超过一定时间没完成就标记为失败重新入队。我设的是5分钟。重试次数失败任务最多重试3次超过就进人工队列。并发处理带来的一个新问题是状态一致性。如果两个Agent同时读写同一个状态对象可能会冲突。我的做法是每个任务有独立的task_id状态对象按task_id隔离Agent之间不共享状态对象只通过队列传递任务。4.4 成本控制怎么让系统跑得起LLM API是按Token收费的投研场景Token消耗量很大。一份年报可能几万字加上Prompt和输出单次处理可能消耗几万Token。如果每天处理几百份文档成本会很可观。我做了几件事来控制成本第一数据层做预处理。把PDF转文本后先用规则方法去掉页眉页脚、免责声明、目录等无关内容。这一步能减少30%-50%的Token消耗。第二分级使用模型。简单任务用便宜的小模型复杂任务用贵的大模型。比如抽取Agent可以用小模型分析Agent用大模型。我实测下来抽取任务用小模型和大模型的准确率差距不到3%但成本差10倍以上。第三缓存重复内容。很多公告的格式是固定的只有数字不同。我把Prompt模板和文档模板做匹配相同模板的部分复用缓存结果。第四设置Token上限。每个Agent的输入输出都设Token上限超过就截断或分块。这能防止某个异常文档消耗过多Token。这几招下来我的系统单份文档的处理成本从早期的几块钱降到了几毛钱。5. 常见问题与排查技巧实录5.1 模型输出不稳定怎么办这是最常见的问题。同一个Prompt同一个文档跑两次结果不一样。原因通常是温度参数Temperature设置过高。投研场景需要的是稳定和可复现不是创意。我一般把Temperature设成0或0.1。如果模型支持还会设置seed参数进一步保证可复现性。另一个原因是Prompt里有歧义。比如“提取主要财务指标”什么是“主要”模型每次理解可能不一样。解决办法是把要求写死列出具体字段名。还有一个原因是文档本身格式不一致。同一份公告有的用表格有的用文本模型处理方式不同。这需要在前面的数据层做归一化。5.2 抽取字段总是漏怎么办漏字段通常有三个原因第一字段定义不清晰。比如“净利润”可能指归母净利润也可能指净利润总额。Prompt里要写清楚。第二文档里字段位置不固定。有的公司在财报开头就列关键指标有的公司在后面。解决办法是在Prompt里加一句“请通读全文后提取不要只看开头”。第三模型上下文长度不够。长文档被截断后面的内容模型看不到。解决办法是分块处理或者用支持长上下文的模型。我一般会做一个字段覆盖率检查跑完抽取后统计每个字段的填充率。如果某个字段填充率明显偏低就去查是Prompt问题还是文档问题。5.3 分析结论太泛怎么办“财务状况良好”“需关注风险”这种话等于没说。原因是Prompt里没有要求模型给出具体判断。解决办法是在Prompt里加约束“每个结论必须包含具体数字或具体事件禁止使用‘良好’‘关注’‘值得注意’等模糊词汇。”另外可以给模型提供对比基准。比如不要只说“毛利率30%”要说“毛利率30%高于行业平均的25%但低于公司过去三年平均的35%”。有了对比结论就具体了。5.4 系统跑着跑着就卡住了这通常是Agent回环次数过多或者任务队列堵塞导致的。排查步骤看日志确认是哪个Agent卡住了。如果是回环过多检查是不是某个Agent一直失败导致上游反复重试。如果是队列堵塞检查Agent池是不是太小或者某个任务超时时间设得太长。加监控对每个Agent的成功率、平均耗时、回环次数做统计异常时报警。我现在的系统里每个Agent都有独立的日志和监控指标。出问题的时候看一眼Dashboard就知道是哪个环节的事。5.5 常见问题速查表问题现象可能原因排查方法解决方案输出格式不对Prompt约束不够检查输出是否符合Schema加结构化输出约束重试时附错误信息字段漏提取字段定义模糊或文档截断统计字段填充率精确字段定义分块处理长文档结论太空泛Prompt缺少具体性要求人工抽查输出加具体性约束提供对比基准系统卡住回环过多或队列堵塞看Agent日志和队列长度设最大回环次数扩大Agent池成本过高Token消耗大统计单文档Token消耗预处理去噪分级用模型设Token上限结果不可复现Temperature过高对比两次运行结果设Temperature为0加seed参数5.6 几个我踩过的坑坑一过早优化Prompt。我早期花了很多时间调Prompt但后来发现很多问题其实出在数据层。文档没解析干净Prompt再怎么调也没用。建议先把数据层做扎实再调Prompt。坑二忽略日志。早期系统没加详细日志出问题只能靠猜。后来加了结构化日志每个Agent的输入输出都记录排查效率提升很多。坑三一次性上太多Agent。我一开始设计了十几个Agent结果调试起来极其痛苦。后来精简到五个核心Agent系统反而更稳。建议从最少的Agent开始需要时再加。坑四不做回归测试。改了一个Agent的Prompt结果影响了其他Agent的输出。后来我建了一个测试集每次改动都跑一遍回归确认没有引入新问题。坑五忽视人工反馈。早期系统没有反馈机制人工修正的结果没有沉淀下来。后来加了反馈入口人工修正的数据用来迭代Prompt系统越跑越准。6. 系统迭代与持续优化6.1 怎么用人工反馈迭代Prompt人工反馈是系统迭代最重要的数据来源。我的做法是每次人工修正Agent输出后系统自动记录“原始输出”和“修正后输出”。积累到一定量后分析修正的模式。比如发现人工经常把“营收增长”改成“营收同比增长”那就在Prompt里加一句“增长率默认指同比增长率”。如果某个Agent的错误率持续偏高就把这些错误案例整理成Few-shot示例加进Prompt里。实测下来加10-20个典型错误案例错误率能降一半。6.2 怎么评估系统效果评估AI投研系统不能只看“模型回答得像不像人”。我用的指标有几个字段抽取准确率抽取Agent输出的字段和人工标注的字段对比。结论可追溯率分析Agent的结论中有数据来源标注的比例。人工修正率最终输出需要人工修改的比例。端到端耗时从文档输入到报告输出的时间。单文档成本处理一份文档的平均Token成本。这几个指标每周统计一次看趋势。如果某个指标恶化就去查对应的环节。6.3 后续可以扩展的方向系统跑稳之后可以考虑几个扩展方向第一接入更多数据源。现在主要处理公告和财报后续可以接入新闻、研报、行业数据、另类数据。第二做组合层面的分析。现在主要是单公司分析后续可以做行业对比、组合风险监控、催化剂日历。第三做时间序列追踪。把同一家公司历次分析结果存下来看关键指标的变化趋势自动识别拐点。第四做个性化。不同投资风格的人关注的指标不一样可以让用户配置自己的关注列表和阈值。第五做主动推送。现在是人问系统答后续可以做成系统主动发现异常并推送。这些扩展不需要推翻现有架构只需要在Agent层加新的Agent在状态对象里加新的字段。这也是我当初选择Multi-Agents架构的原因之一——扩展性好。6.4 一个实际跑起来的例子最后分享一个实际跑起来的例子让大家有个直观感受。某天早上采集Agent发现某公司发布了一份业绩预告。系统自动触发流程抽取Agent从预告中提取了营收区间、净利润区间、同比增长率。分析Agent对比了公司过去四个季度的数据发现净利润增速在放缓但营收增速在加快判断可能是毛利率承压。校验Agent检查了分析结论的数据来源确认每个结论都有支撑。写作Agent生成了一段简短的投研笔记大意是“营收加速但利润放缓需关注成本端变化建议查阅后续详细财报”。整个流程耗时约3分钟成本约0.5元。这份笔记自动推送到我的工作台。我看了一眼觉得分析逻辑没问题就转发给了团队。如果是早期版本我可能还要花半小时自己翻公告、算数据、写笔记。这就是AI投研系统的价值不是替代人做决策而是把人从信息处理中解放出来让人专注于判断。我个人的体会是做这类系统技术不是最大的瓶颈对投研业务的理解才是。你得知道投研人员真正需要什么信息、在什么场景下需要、以什么形式呈现最有用。这些想清楚了技术方案自然就出来了。反过来如果只是堆技术做出来的东西大概率没人用。另外一个小建议不要追求一步到位。先做一个最小可用的版本跑起来用起来然后根据实际反馈迭代。我现在的系统是第7版前6版都或多或少有问题但每一版都让我更清楚什么该做什么不该做。