在金融数据服务公司做投研系统的第七年我最深的感受不是“数据不够多”而是“信息过载已经开始影响判断”。当我同时盯着一家公司的财报、三份卖方研报、十几条行业新闻和一堆会议纪要时真正有生产力的不是记忆力而是能不能从一个模糊需求出发稳定地把这些材料变成结论。去年我给自己立了一个项目做一个以AI大模型为底座、由AI Agent自主驱动的投研工作流让系统自己巡数据、自己查证、自己写结构化纪要而我把时间留给更重要的假设与决策。这篇文章就是我在这件事上的完整复盘。如果你也正在做AI应用开发、AI编程相关的事尤其想用Agent处理某个垂直领域的高密度文本这篇文章里的思路和坑应该对你有用。我会按真实搭建顺序来讲先说架构选择再讲哪些环节真正实现了自主最后讲工程落地和风险兜底。1. 为什么我把投研流程拆成“数据管线 决策智能体”两层1.1 传统投研工作流里的三个隐性成本先说传统工作流。一个典型的研究任务大概是这样确定研究对象去几个信息平台收集公告和研报阅读后建立事实时间线提取关键指标最后形成一段有逻辑的观点。听起来不复杂但实际做下来有三个非常隐蔽的成本注意力切换、疲劳漏读、观点锚定。这三个成本几乎每个人都会踩中只是不会立刻让结果出错而是会在长期研究里慢慢侵蚀判断质量。第一个成本是注意力切换。研究一只股票或一个行业时往往要同时看财务数据、产能数据、管理层发言和下游舆情这些信息分散在不同系统里每切换一个来源大脑就要重新建立上下文一天下来真正用于思考的时间少得可怜。第二个成本是疲劳漏读。我自己有个明显体会连续读三份同类研报之后对第四份的敏感度会下降很多容易漏掉转折句和风险提示。第三个成本是观点偏差人很容易被最近读到的材料锚定尤其当多份材料说法不一致时最后写出来的结论往往取决于阅读顺序而不是证据强度。我尝试过用普通AI聊天窗口来缓解这些问题效果很有限。聊天式AI适合回答单点问题但它没有持久记忆也不理解“连续监控一家公司两个月”意味着什么更不会主动发现问题。所以我从一开始就决定不做聊天助手而是做一个能自主推进任务的Agent系统也就是把投研流程拆成两层底层是干净、持续更新的数据管线上层是负责规划、调用工具、判断和执行的研究智能体。1.2 分层设计的核心逻辑为什么一定要拆成“数据管线 决策智能体”两层因为模型不应该直接面对原始数据。原始数据里有大量噪声PDF表格转文本后列会错位、公告里同一个公司可能用不同简称、网页上的日期格式千奇百怪。让大模型在原始文本上做推理它会把不少算力浪费在纠错上而且纠错失败的后果会一路传递到结论层。所以我的数据管线负责把所有非结构化材料处理成结构化事实。具体来说它做五件事解析、抽取、规范化、去重、向量化。解析是把PDF、HTML、音频转写文字变成纯文本抽取是识别公司名、时间、金额、业务主体等关键实体规范化是把“1.2亿”和“120,000,000”统一成标准数值去重是把同一事件在不同来源里的重复信息合并向量化则是为了后续做语义检索。智能体这层只管做决策不关心材料本身在哪个网站。它拿到手的是数据管线提交的干净事实和检索入口所以上下文更短、更聚焦幻觉率也明显下降。这层再往上才是面向人的交互层。也就是说用户看到的是最终研究结果模型从来不需要自己去和乱糟糟的原始网页搏斗。1.3 这套架构最终解决了什么这套架构跑起来之后解决的核心问题可以归纳成三句话第一信息巡护不再依赖人的精力系统会按固定频率检查标的池里的公司有没有新公告、新研报、新舆情并自动判断哪些变化值得发起一次研究任务。第二研究过程不再是人肉翻阅Agent会把一篇研报拆成“结论-论据-数据-风险”四个要素并逐条验证这些结论是否和原始数据一致。第三观点生成不再是一锤子买卖系统会保存每次分析的状态下次继续跟踪时直接基于之前的结论做增量更新而不是从零开始。坦白说这三句话听起来很像是产品宣传词但真正把它落地中间每一步都有不少坑。后面的章节我会一个个展开。2. 自主驱动不等于全自动我先让AI接管了这三个环节2.1 环节一信息收集与实时监控做AI Agent最容易犯的错误是一上来就想要一个全自动闭环输入公司代码直接输出买卖建议。这种想法既危险也不现实。我的做法是从环节级自主开始先选评价标准清晰、出错后果可控的流程给AI接管跑顺一个再扩大边界。我第一个接管的环节是信息收集与监控。每天早上八点半系统会启动一个研究助理Agent遍历我的关注列表去公告源、研报源和舆情源做增量检查。一旦发现新内容它先做基础解析再结合历史观点判断这件事有没有增量信息。比如某家电公司发布了月度销售数据Agent会自动和上月对比提取异常项生成一条“数据变化摘要”推送到我的工作台。这个环节最适合先自动化因为它没有复杂的价值判断信息是否新增、对比后数值是否异常这些都是可校验的。而且一旦跑通它能解放掉我每天至少一小时的无脑刷新时间。更关键的是监控任务里出现错误时影响范围非常有限最多是一条推送判断不准确人工一眼就能纠正不会造成严重后果。2.2 环节二结构化观点核验第二个环节是观点核验。过去我读完一份卖方研报要手动把它提出的逻辑链条和数据源对照一遍这个过程又慢又枯燥。现在Agent会先把研报里的观点拆成断言比如“公司A在细分赛道的市占率持续提升”然后基于数据管线里的财务数据和产业数据做一致性检查。如果研报给出的支持证据与数据库中的数值冲突Agent会明确标出“矛盾”而不是假装没看到。这里有一个从实操中总结出来的关键细节给Agent设计核验任务时必须要求它把每个判断行号和证据行号同时输出。也就是说AI不能只说“市占率提升”还要指出这个结论对应原始文本的哪个章节、支撑数据来自哪一行。一旦这样要求模型的胡诌空间就会被压缩到很小因为行号对不上时人工审核一眼就能发现问题。2.3 环节三会议纪要与调研纪要的结构化第三个环节是会议纪要与调研纪要的结构化处理。这个场景比公告更复杂因为口语内容里大量省略主语像“我们明年会继续加大这块投入”没有上下文时根本不知道“这块”指什么。Agent在处理时需要先结合这家公司最近的产品和财报口径把指代消解成具体的业务线再提取口径变化、资本开支计划和绩效目标。最开始我让Agent只做关键词抽取效果很差因为它分不清哪一个数字是新增信息、哪一个只是复述历史内容。后来我改成两步走第一步让Agent总结原文里所有“变化点”第二步再让Agent基于历史版本找“新增变化”把两步结果做差集才真正把会议纪要的价值释放出来。这一步跑通之后我的深度研究效率提升非常明显但我仍然要说它只是辅助不是决策替代。这三个环节之所以先做是因为它们都满足同一标准输入输出边界清楚错误能被看见结果可以验证。凡是满足这个标准的任务才值得谈自主。那些判断链条长、主观因素多的环节我到现在仍然保持更高程度的人工参与。3. 核心引擎的搭建任务规划、工具调用与记忆管理3.1 为什么选择Agent而不是一条Prompt链把Agent接到投研场景之后我最常被问的问题就是为什么不写一个超长的Prompt链按步骤调用模型非要用Agent架构答案很简单真实投研任务的路径不是固定的。同样是“分析一家公司”有的任务需要先查财务数据有的需要先读产业数据有的还需要横向对比几家同行。如果用固定Prompt链每加一种新任务类型就要重写一套流程维护成本高得吓人。Agent的核心优势是能在运行中动态规划。系统给Agent一个目标它自己决定先调用哪个工具、再推理哪个结论遇到证据不足时还会主动扩大搜索范围。我在这套系统里实际上采用的是ReAct风格的循环模型先思考当前任务需要什么信息再调用对应工具观察结果后决定下一步直到任务完成。这样既保留了步骤的可追溯性又避免了为每种任务单独写流程。为了便于理解我把这套循环简化成下面的伪代码class ResearchAgent: def __init__(self, llm, tools, memory): self.llm llm self.tools {tool.name: tool for tool in tools} self.memory memory def run(self, task): plan self.llm.split_task(task) for step in plan: result self.execute_step(step) self.memory.save(result) return self.memory.collect()实际工程里当然比这复杂但核心思想是一样的Agent不是一次性生成答案而是把一个大任务切成多步每步都带着前面步骤的结论往下走。3.2 工具集的设计与选择工具集是整个Agent能力的边界。我的工具集最初有十几个接口后来砍到了六个公告检索、财务数据查询、网页搜索、文档解析、数值计算、向量记忆检索。因为实践下来发现模型做工具选择的准确性会随着工具数量增加而下降。给模型太多选择它反而容易在无关工具上犯错尤其在复杂研究场景里一个选择错误就可能带偏整个推理方向。每个工具的定义必须足够清晰。我给工具写了两部分内容第一部分是功能描述用来让模型判断“什么情况下该用它”第二部分是JSON Schema把参数限制得尽可能严。比如财务数据查询工具的输入参数必须包含公司ID和指标名不允许模型自由发挥传一个模糊的“最近数据”。这样做的代价是灵活性降低但换来的是调用成功率大幅提升整体收益非常高。3.3 记忆与上下文管理投研系统对记忆的需求非常特殊。研究一家公司往往要持续几周甚至几个月Agent如果每次分析都只看当前材料就会丢失历史判断。我在系统里做了三层记忆短期记忆是当前分析任务的中间结果存内存里长期记忆是历史研究报告和关键结论放进向量数据库按公司和主题建索引结构化记忆是公司的基础数据、财务指标时间序列、以及已经核验过的事实放在结构化数据库里。这样的分层带来的直接好处是上下文窗口不再被历史材料占满。刚开始做的时候我图省事把所有相关材料都塞进上下文结果token消耗巨大而且长文本把模型注意力稀释了输出质量反而变差。后来改成“先检索后生成”的RAG模式每次只把最相关的一段材料放进上下文模型输出明显更稳定。这个现象其实不难理解让模型在五千个非关键事实里找一个关键事实和在五十个高相关事实里做判断难度完全不在一个量级。3.4 多Agent协作还是单Agent关于架构我还犹豫过要不要上多Agent。市面上很多宣传把多Agent说得无所不能但实际落地时多个Agent之间的通信协议和状态同步会带来巨大复杂度。我的最终方案是折中主体是一个研究Agent负责规划、检索和推理另外挂了两个只做专门任务的轻量Agent一个是事实验证Agent专门对研究Agent的结论做反向证伪一个是语言改写Agent负责把零散的推理结果整理成结构化报告。这种组合既避免了多Agent网状协作的麻烦又保留了“生成和验证分离”的好处。核心原因在于让同一个模型既负责推导结论又负责检查自己容易陷入自我确认偏差单独抽一个验证Agent出来做“找茬”效果会好很多。如果你也想做垂直领域的Agent我建议不要一上来就铺很多角色先把“一个主Agent加一个验证Agent”这个最小组合跑稳再考虑扩展。4. 数据质量与幻觉问题我在评测和测试中踩过的坑4.1 AI测试不是问它好不好而是给用例集打分很多刚开始做AI应用开发的人测试方式是把几个问题扔给模型肉眼看一下回答得怎么样。这种测试在投研场景远远不够因为投研输出不仅要求“看起来流畅”还要求每一个数字、每一个结论都有据可查。我专门做了一套评测集规模不大五十条左右但每一条都包含四部分任务类型、输入材料、期望输出结构、关键事实标签。跑一次大概半小时但对模型选型和版本升级非常关键。评测指标我用了五个事实准确率、引用完整率、格式合规率、单任务延迟和单任务成本。重点说前两个。事实准确率是指Agent输出里和原始材料一致的内容占比引用完整率是指有具体出处来源的断言占所有断言的比例。这两个指标加起来基本能反映一个Agent在投研场景里有没有乱说。指标含义我的可接受阈值事实准确率输出与原始材料一致的比例不低于95%引用完整率有明确出处的断言占比不低于90%格式合规率输出结构符合预定模板的比例不低于98%单任务延迟从收到任务到产出结论的耗时5分钟以内单任务成本一次完整任务的模型调用费用视任务复杂度而定这里想强调一句评测集最怕一次性建完就不管。模型在升级工具在变数据源也在变评测集必须跟着迭代。我每个月会往里面加几条最近半年真实踩过坑的case让测试集始终贴近实际使用场景。4.2 Agent自己要会交叉验证评测集只是最后一道防线真正降低幻觉的是系统内部的交叉验证机制。做法是每次Agent生成一个重要结论都必须附带证据链证据链要么来自结构化数据库要么来自某篇源文档的某个段落。如果某个结论找不到证据链接它在最终报告里的展示权重会被系统自动降低。更激进一点我还会让验证Agent主动反向提问。比如研究Agent说“该公司的产能利用率明显提升”验证Agent会立刻去数据表里查产能数据和产量数据如果增幅不匹配就会给这个结论打上“存疑”标签。这一步让系统不只是在总结材料而是在做一定程度的事实审核对投研场景来说很有价值。4.3 幻觉的源头往往不在模型而在数据管线这是我最想提醒后来人的一点。很多团队把幻觉问题全归咎于大模型拼命调Prompt和温度参数却忽略了数据管线里的低级错误。有一次系统把一份财报PDF里错位的表格数据当成真实业绩生成的分析结论完全反了方向。排查之后发现问题是PDF转文本时两列数字被交换了位置。这样的错误再强的模型也救不回来。所以我在数据管线的每一层都加了质量检查解析之后做schema校验抽取之后做实体对齐入库之前做数值格式校验。一旦发现异常宁可跳过这一份材料也不能把脏数据喂给Agent。这条原则非常朴素但无数次救我于水火。如果你正在做其他垂直领域比如医疗、法律或工业文档这条原则同样适用。4.4 置信度和来源追溯是底线最后是置信度机制。AI生成的研究输出不能是“全对”或者“全错”的二值状态我要求每个核心断言都带一个置信度范围是0到1并且模型必须给出给低分的原因。比如“供应链数据显示原材料价格回落因此该公司下季度毛利有望改善”置信度如果只有0.6那Agent必须说明低分是因为原材料价格回落尚未反映在历史财务数据里属于外推判断。来源追溯则是让用户能顺着证据链回看。我在系统里给每份源文档算了一个内容指纹Agent引用的每一个事实都记录来源ID和段落位置。这样做除了提升透明度还有一个实际好处当新的数据发布后系统能快速识别哪些历史结论已经过时主动推送给用户而不是装作无事发生。这个机制对长期跟踪同一批标的特别重要。5. 从日级任务到分钟级响应部署层与模型路由的工程实践5.1 任务调度不是所有任务都需要实时系统上线之后我第一版设计把所有Agent任务都做成实时触发结果资源消耗很快就失控了。后来我按业务价值重新设计了调度策略。每天开盘前的晨报、每周的行业复盘、以及季度财报季的集中事件提示它们的时效性要求完全不同不应该共用一套调度逻辑。我用一个简单的任务优先级表来管理任务类型触发方式预期延迟标的事件提示事件触发1分钟以内公告增量监控每5分钟轮询5分钟以内舆情情绪指标每小时更新1小时以内晨报生成每日定时08:30前完成深度研究专题手动触发10分钟内完成优先级越高的任务用越轻量的模型和越短的上下文优先级低的任务才允许调用复杂模型做深度分析。调度层重新设计之后整体成本能省一半以上。这其实是我对AI基础设施最朴素的理解不是堆GPU而是先把资源按真实需求分配好。5.2 模型路由与成本控制投研任务里其实大量步骤并不需要最强的大模型。比如抽取公告里的发布日期、解析财务表格、做文本分类这些任务用轻量级模型就够了。我按任务难度把模型分成了三档第一档用于实体抽取和格式转换响应要快、成本要低第二档用于信息摘要和逻辑推理需要中等水平第三档才用于观点生成和复杂推理使用最强模型。这个路由策略帮我控制住了成本。同一个研究流程如果全程使用最强模型成本是路由后的差不多四倍而综合质量并没有显著提升。我的经验是不要因为大模型调用方便就不假思索地滥用越是大规模任务流越要在模型选择上花时间。顺便说一句模型路由不只是省钱它还能降低延迟让轻量任务做到秒级响应。5.3 部署后的可观测性Agent系统的最大工程风险是不可观测。普通Web接口调用一次返回一次出了问题看日志就好但Agent会在一次任务里做多次推理、多次工具调用链路长且状态复杂一旦出问题很难定位。所以我在部署阶段坚持给每一轮推理和工具调用都打日志模型输入的摘要、工具名称、返回值长度、耗时、token数、是否触发重试。这部分的投入在初期显得很繁琐但后来几次线上问题都是靠这些日志才快速定位。比如有一次系统持续生成同一公司的大量重复纪要日志显示是向量检索的结果排序没加时间衰减导致旧材料一直排在前面。没有可观测性这种问题几乎不可能被发现。如果你在做Agent类的应用请务必从第一天起就把链路日志当成核心功能来做而不是事后补救。5.4 模型部署迭代的策略在模型部署和迭代方面我不追求每出一款新模型就立刻切换。更稳妥的策略是并行运行把要评测的模型和当前线上模型接到同一套评测集上跑一周对比看的不是某个单点案例而是整体指标分布。这听起来很笨但能避免不少被单一样例误导的冲动。此外所有上游模型接口都要做一层适配层。这样换模型时下游数据结构和业务代码不需要大改。经历过一次模型供应商接口变化导致全线报错之后我极度推荐把模型调用封装成统一接口这属于AI工程实践里最容易被忽略却最重要的一点。系统稳定运行的时间越长你越会发现这种基础设施层面的约束比某个独门Prompt值钱得多。6. 自主投研的安全带评审、留痕与人为最终决策6.1 自主程度分级我最终停在L2聊完工程必须聊边界。很多朋友听完我的分享第一反应是问那它能不能完全替代研究员我的回答是我把它分成了四级L0是完全人工L1是AI辅助检索和摘要L2是AI生成完整初稿加人工审核L3是完全无人参与的自动决策。我自己目前部署在L2L3只用在信息预警和环境变化的初筛上。之所以不轻易上L3是因为投研场景里最终结论的容错空间太窄。AI擅长从大量材料里提取和追踪信息但判断还需要考虑市场情绪、资金面、事件冲击等很难结构化的因素这些东西现阶段让模型负全责我不放心。与其追求完全自动化不如承认人的判断仍然是闭环里不可省的一环。6.2 评审流程与留痕机制在L2模式下系统输出的任何一份研究初稿都带两个附加属性模型版本号和材料快照。模型版本号保证如果结论质量波动可以回溯到具体是哪一版模型造成的材料快照则保证即使源网站后续修改或删除内容审核者看到的始终是Agent当时读到的原始版本。我还在工作流里加了一个“建议动作”字段Agent可以对每条风险事件给出“继续观察、需要复核、建议关注”之类的标签但不会输出“买入或卖出”这样的交易指令。真正的决策必须由人在充分知情的情况下做出。这套机制不是为了限制AI而是为了让它能在一个更安全的环境里被长期使用。6.3 人的工作不是重复AI而是发现AI发现不了的问题当AI把信息收集和结构化工作做得越来越好后人的角色会自然发生变化。以前我大部分时间花在找材料和核对数字上现在这些工作Agent十分钟就能完成我把重心转向了提出更关键的假设、评估被忽视的风险、以及处理AI还没法理解的模糊信息。举个例子Agent能从公告里准确提取“公司计划三年内实现产能翻倍”但它很难判断管理层这句话背后是基于真实订单需求还是行业惯性扩张。这类问题的答案藏在产业关系和经营细节里需要的是行业经验不是信息处理能力。所以在我看来AI自主驱动的投研最终形态不是替代研究员而是把研究员从信息苦力中解放出来去做真正需要人的判断力的工作。每次有人问我这个系统做到什么程度我通常会说它还不能替我承担决策责任但它已经帮我找回了大量被信息淹没的时间。后续我打算继续做两件事一是把跟踪频率从日级提升到更细粒度二是让Agent在跨公司横向对比上更聪明。这些都是工程和算法问题可以做得很稳。如果有人正在做类似的垂直领域Agent希望这篇复盘能让你少走几段弯路。