先交代一下背景。过去大半年时间我利用业余时间从零手搓了一套投资agent全量知识库大概几百亿token的量级涵盖财报、公告、研报、新闻和宏观数据。很多人听到“百亿token”第一反应是“这是不是把模型上下文干到了百亿”其实不是。这里的百亿token指的是知识库内容的总体量相当于几百万页金融文档转成token之后的总和。这个量级决定了整套系统的架构路线。先算一笔账让大家对百亿token有个体感。一份头部公司的年报PDF正文加附注大概五六万字token化之后在八万到十万之间半年报、季报、临时公告、业绩说明会纪要、评级调整公告、行业新闻这些全算上一家重点跟踪公司一年新增的有效信息大概三四百万token。如果持续跟踪两三百家公司再加上宏观数据库、行业数据库和历史新闻库做到百亿token其实不需要太多年就会碰到。这套agent能干什么你可以直接丢给它一个任务比如“分析某新能源公司最近三个季度的毛利率变化结合同行对比给出你的判断”。它会自己把任务拆成几十个小步骤自己去查财报、找新闻、跑行业对比、调行情数据最后给你一份带数据来源的结论报告。你不用告诉它第一步查什么、第二步算什么只需要在最后检查它给出的证据是否支持结论。这篇文章不是讲某个商业产品的使用心得而是讲我一个人从0到1做这套系统过程中沉淀下来的架构设计、数据管道细节、推理工作流、成本与性能优化、踩坑记录。适合三类人想自己做投资分析工具的个人投资者在做agent或者RAG应用落地的工程师以及好奇AI到底能不能用于严肃决策的产品经理。1. 先想清楚百亿token的投资agent到底解决什么问题1.1 投资分析的瓶颈从来不是模型不够聪明我见过很多人做AI投资工具的第一步都是“接个大模型API”然后就开始问“模型能不能帮我分析股票”。做了大半年之后我的体会很明确模型聪明程度反而最不需要担心真正难的是喂给模型的料够不够靠谱、够不够完整、来源是不是可信。投资分析本质上是一个信息处理问题。一家公司值不值得看需要同时知道它的财务数据、所在行业的景气度、竞争对手的动向、管理层最近的表述、市场情绪的变化。这些信息分散在年报、公告、新闻、研报、行情数据里。一个分析师一天能精读几份报告而市场一天新增的有效信息可能是几百份文档。人读不过来传统的搜索引擎又只能给你一堆链接你要自己一篇一篇打开、筛选、理解。投资agent做的事情是把“读取、筛选、理解、交叉验证”这一步从人身上搬到了机器身上。还有一个容易被忽略的点信息量过大时人脑的判断质量会显著下降。你会被最近看到的新闻带偏会被某个极端案例影响会忘记三个月前已经确认过的事实。机器没有这个毛病只要索引和数据管道扎实它可以一视同仁地去读取全量信息。这是投资agent相对于人类最实在的价值。1.2 百亿token决定了你必须走检索增强而不是硬塞这里要先澄清一个常见误解。经常有人问“既然模型支持很长的上下文把百亿token的知识库直接塞进去不就行了”答案是行不通的原因有三个。第一是成本。token是按用量计费的一次请求塞进几十亿token光输入成本就不是个人能承受的量级。按当前主流商用API的价格粗略算过如果一次分析任务把百亿token全部塞给模型单次成本相当于一辆入门家用车没有人会这么干。第二是时延。模型处理上下文的计算量随长度增长上下文越长首字返回越慢。就算你能付得起钱也没人愿意等几个小时才看到第一句话。第三是注意力稀释。模型在超长上下文里对关键信息的敏感度会下降距离很远的相关证据会被“淹没”在无关内容里。用检索把范围缩小到当前任务真正需要的几段证据效果反而更好。所以这个量级的正确路线就一条用检索增强的办法把“全量百亿token的知识库”变成“当前任务需要的几十段高相关证据”。人是怎么做研究的带着问题去图书馆翻书只读相关的章节然后把相关内容抄到笔记本上最后汇总成结论。agent也是这么干的只不过图书馆是向量库翻书是向量检索抄笔记是上下文管理。1.3 手搓和套壳的差别本质是控制权市面上确实有不少现成的AI投资助手但用一段时间你就会发现几个没法忍的问题。数据滞后。现成产品更新全量数据的速度取决于平台方你看到的信息可能已经过了一周。对投资决策来说晚一天可能就意味着完全不同的结论。回答泛泛而谈。很多产品只会给你“这家公司是行业龙头具备长期竞争力”这种正确但没用的废话。原因很简单它没有你的私有数据也没有针对你关注的标做深度的数据管道。不可审计。你不知道它内部到底查了什么、为什么给出这个结论。投资决策最忌讳的就是黑箱。手搓的核心价值是控制权。数据管道是自己的清洗标准是自己的检索策略是自己的提示词和工具是自己的成本模型也是自己的。出了任何一个问题你知道具体是哪一环可以立刻定位和修。想优化某个环节你知道往哪个方向使劲。这种可控性是任何套壳产品都给不了的。当然手搓不等于拒绝现成组件。LLM调用、向量数据库、开源OCR这些基础能力我没有重复造轮子直接用技术社区验证过的方案。手搓指的是整个系统的架构设计和数据链路是属于自己的而不是在一个别人封装好的“投资助手”外面套一层壳。2. 架构设计五层结构才能扛住百亿token2.1 五层结构全景整套系统的架构我拆成了五层每一层职责单一层与层之间通过明确的数据契约通信。数据采集层负责从各类公开数据源拉取增量内容和全量历史数据。解析与清洗层把PDF、HTML、扫描件、公告原文转成干净、结构化、带来源标记的文本。索引与检索层负责切分、向量化、建索引以及给推理层提供高质量的证据召回。推理与编排层是agent的大脑负责任务拆解、工具调用、记忆管理和结论生成。执行与输出层负责把结论转成报告、图表、摘要和告警。这五层里面我对“数据契约”这件事特别较真。每一层的输出都必须是一个明确、可检验的格式。采集层输出原始文件加元数据解析层输出markdown加表格结构索引层输出chunk加标量字段检索层输出证据块加相似度分数。有了这些契约任何一层的内部实现都可以随时替换而不影响其他层。2.2 为什么数据链和推理链必须分开做agent最容易犯的错误是一上来就写提示词、调模型。我第一版也这么干过结果很惨模型很聪明但喂进去的内容乱七八糟经常出现把两年前旧的公告当最新消息、把未经证实的网上传言当成事实。后来我才想明白投资agent系统里90%的问题出在数据链而不是推理链。数据链不干净推理层再聪明的模型也只能在垃圾上做推理。把数据链和推理链分开之后一个直接的好处是每层都可以独立做质量检查。解析层的输出可以用抽样检查确认表格没有被拆烂索引层的召回可以用评测集打分推理层的输出可以单独审计证据引用。出任何问题通过链路追踪就能定位到具体是哪个环节而不是在提示词里反复试来试去。另一个好处是独立扩展。数据管道可以一夜之间多处理一个数据源而不影响推理逻辑推理层想换一个更强的LLM只需要把数据契约适配好。这套架构让我在后面迭代时省了特别多时间。2.3 一次请求从进入到返回的完整链路我拿一个实际场景走一遍完整链路方便理解五层是怎么协作的。用户给agent下发任务“分析某消费白马公司的投资价值重点关注盈利质量和现金流。”主agent进入规划阶段把任务拆解为五个子任务拉取最近三个年度的财务数据、检索该公司近一年的新闻舆情、找行业对比数据、查询最新公告、拉取当前估值与历史区间。五个子任务并行执行。每个子任务对应一次或多次检索财务数据走结构化查询新闻和公告走向量检索估值数据走行情工具。检索结果回来之后先过一次重排模型把低相关证据过滤掉再按相关性和时效性排序取每个子任务最相关的前几段。然后每个子任务独立做一个小的推理得出结论比如“近三年毛利率从28%下滑到22%主要原因是原材料成本上升”。这些中间结论最后会送到汇总模块做交叉校验财务数字必须和原始报表一致新闻类结论必须标注发布日期不一致时以结构化财务数据为准。最后生成报告。报告里每个关键结论后面都挂着来源引用。整个流程跑下来大概一分多钟看起来像是把一个分析师团队的工作方式压缩到了分钟级。这个链路最重要的设计原则是每一步都可以停、可以查、可以回退。规划阶段拆出什么子任务检索阶段召回了什么证据推理阶段得出了什么中间结论全部有日志。这保证了你永远可以在事后回答“这个结论是怎么来的”。3. 数据管道百亿token是怎么一步步塌实整理出来的3.1 数据源的选择与优先级做投资agent数据源选型基本决定了系统能力的上限。我按“信息价值”和“结构化难度”两个维度整理了优先级。定期报告是核心中的核心。年报、半年报、季报包含最完整的财务数据和经营讨论是基本面分析的底座。临时公告覆盖重大事项比如并购、减持、业绩预告、诉讼进展往往是股价短期波动的主要驱动。新闻资讯覆盖市场情绪和动态时效性要求高但价值密度低、噪音大。宏观数据给整个分析提供背景利率、货币供应、行业景气指数这些指标会直接影响对个股的判断。研报提供机构观点但要注意立场偏差更适合作为参考而非事实。不同类型数据源的特征差异很大我整理成了下面这张表数据源类型典型格式更新频率结构化难度我的优先级定期报告PDF为主季度高最高临时公告网页/PDF实时中最高新闻资讯网页实时低高宏观数据结构化接口月度低中研报观点PDF/网页日高中说直白一点财报数据如果不做扎实后面全是空中楼阁新闻资讯虽然多但大多数对投资判断没有增量信息必须靠过滤而不是一股脑全存。3.2 解析层PDF、表格、扫描件的真实处理现场财报类PDF是整个数据管道里最磨人的部分。年报PDF经常是图片型、双栏混排、表格跨页、数字被拆分到两行有些扫描件甚至方向都是歪的。我的处理流程分四步。第一步是识别文档类型判断是文本型PDF还是扫描件扫描件统一走OCR。第二步是版面恢复用开源的版面分析能力把页面切成标题、正文、表格、页眉页脚几个区域页眉页脚直接丢弃。第三步是结构还原把多级标题的层级关系恢复出来标题和正文的层级关系就是后期文档切分的骨架。第四步是表格抽取把跨页表格合并成完整表结构转成结构化数据单独存放不混进正文。表格处理是最容易翻车的地方。年报里的资产负债表、利润表、现金流量表如果按普通文本切分数字会被拦腰截断检索的时候只能召回半张表。我的做法是所有表格在解析阶段就单独入库保留原始的“行名-列名-数值”结构检索表格时走专门的字段匹配而不是纯语义检索。OCR环节有个经验复杂表格的识别错误率不低所以凡是OCR识别出来的财务表格我都要求后续做一个数值合理性校验比如“净利润绝对值不能超过营业收入绝对值”这种基本约束不满足就打回重处理。宁可漏掉一条不要错存一条。3.3 去重与可信度信息质量的两道筛子金融文本的去重和普通网页去重还不一样。同一条新闻会被几十个媒体互相转载同一份公告会在不同平台重复出现而且转载过程中经常被改写标题可能变正文段落顺序也可能调。这就不能用简单的精确哈希去重。我用的方案是SimHash指纹加相似度阈值每篇文本算一个64位指纹两篇指纹的海明距离小于一定阈值就认为是近似重复只保留发布时间最早的一篇。实测下来新闻库的去重率能达到三成以上也就是说每十条新闻里有三条是重复内容。这个动作直接减少了存储和检索负担也让检索结果不再被同一条新闻刷屏。可信度分级是另一道筛子。我把数据源分了三个信任级别官方公告和定期报告是第一级直接可信主流财经媒体的报道是第二级可信但需要标注来源和发布时间自媒体、社交平台内容是第三级只在做舆情分析时使用并且必须明确标注为市场情绪而非事实。这个分级会在索引阶段写进metadata里推理层可以据此校对证据权重避免模型把论坛上的小道消息当成基本面事实。3.4 切分策略chunk size不是拍脑袋定的RAG系统里文档切分是直接决定检索质量的一个环节。很多人直接用固定长度切比如512个token切一块、再重叠80个token省事但效果一般。金融文档有非常强的结构特征不利用起来很可惜。我的切分策略分三种类型。第一类正文按语义段落切单块控制在600到900个token之间相邻块重叠80个token。第二类表格单独切每张完整表作为独立chunk不做截断。第三类公告类短文档一整个公告通常就是一个语义单位直接整体入库不强行切碎。为什么把正文单块控制在600到900个token这是一组对比实验之后定下来的。块太小比如200个token检索召回的碎片太多模型看不到完整上下文块太大比如1500个token块内信息太杂语义中心被稀释召回精度明显下降。600到900的区间对财报这种信息密度高的文本比较合适既保留了上下文的完整性又控制了无关内容的干扰。长文档还有一个必须处理的细节切分之前先重建“标题树”。一份年报有十几章每章下面还有多级小节如果平铺直叙切块每块就失去了它在全文中的位置信息。我先根据标题层级把文档组织成一棵树切分时把“章节路径”以metadata的方式写进每个chunk比如“2023年报管理层讨论与分析盈利能力”。这样检索时不仅能看到块内容还能看到它在文档里的位置大幅减少“句子单独看没问题、放回上下文被误读”的情况。3.5 索引层向量与标量的双通道索引索引层是数据管道和推理层之间的桥梁。我同时保留了两套索引一套是固定字段的标量索引一套是文本语义的向量索引。标量索引管时间和类型维度比如“发布日期在最近30天内的公告”“来源等级为一级的财务报告”。向量索引管语义相似度比如“找一段描述现金流恶化风险的内容”。检索时先做标量过滤缩小候选集再做向量召回最后用重排模型精排。这个顺序让精确性和语义性都能兼顾。embedding模型的选择标准我认为有三条是底线支持中文语境、对金融术语的语义理解不跑偏、在长文本上不会把关键信息稀释掉。我做过一个简单的小测试把“毛利率”和“净利率”以及“毛利率”和“流动比率”这两组词分别embedding看相似度差别。如果模型连这种基本的财务术语距离都分不清检索质量一定好不了。向量库的筛选标准更多落在工程层面能否支持大规模数据的高并发检索、向量维度适配、标量过滤和向量检索能不能在单次查询里组合、增量更新方不方便。百亿token的文本量级切出来的chunk可能上千万条这个量级对向量库的压力主要在内存和召回延迟上选型时一定要用真实规模压测过再定千万不要用小数据集测出来的结果去推大集群。4. 推理层agent到底是怎么“思考”和干活的4.1 工作流编排为什么Plan-and-Execute比ReAct更适合投资场景agent的核心机制是让模型自主决定下一步做什么。最早做demo时我用了最朴素的ReAct循环模型每一步推理一下、决定调用一个工具、观察结果、再推理。demo能跑通但实际用下来发现两个问题决策链太长导致token消耗大而且中间任一步判断出错后面全跟着偏。后来我换成了Plan-and-Execute的思路主agent先做一轮全局规划把任务拆成一组相对独立的子任务然后再为每个子任务单独执行一个小的ReAct循环。这个改变带来的收益非常明显。第一个收益是可检查性。规划阶段输出的计划人可以提前审一遍发现拆得不对可以直接修正而不是等模型执行完才看到结果。第二个收益是并行性。子任务之间只要没有依赖就可以并行执行整体延迟从串行的累加变成了最慢那条分支的耗时。第三个收益是token成本下降。拆解后的每个子任务只携带和它相关的上下文不用把整盘任务背景重复堆给每一步。投资分析场景天然适合这种方式因为投资任务的价值在于“广覆盖、可复查、有标准流程”而不是在对话里随意发散。一个分析师看一家公司也应该是有步骤的先看财务再看业务再看行业再看风险。把这种步骤变成agent的规划模板输出质量会明显提高。我在实现的时候给主agent内置了几套规划模板比如基本面分析模板、财报解读模板、舆情监测模板。用户的任务先做一次意图分类匹配到最合适的模板再由模型在模板基础上做补充和调整。这样既能保证流程结构不乱又保留了灵活性。4.2 工具调用agent的“手脚”设计工具是agent接触真实世界的方式。没有工具它只能凭记忆回答有了工具它才能拿到实时行情、查原始报表、算财务指标。我把工具分成五类行情类、财务数据类、检索类、计算类、报告类。行情类工具负责实时价格、历史K线、估值分位。财务数据类工具负责从结构化财务库直接查询指标比如“某公司2023年扣非净利润、经营现金流”这类精确数据。检索类工具负责从向量库里召回文本证据比如新闻、公告、研报段落。计算类工具负责指标计算避免模型自己口算财务比率。报告类工具负责把结论组装成结构化报告。function calling的效果很大程度上取决于工具描述写得清不清楚。我吃过很多亏之后总结了一条经验工具描述要用“动词对象边界”的结构来写。比如一个财务查询工具描述应该写清楚“当用户需要某公司某个报告期的具体财务科目数值时使用此工具”而不是笼统写“查询财务数据”。参数说明更要明确数字类型的参数要把单位、时间格式都写清楚枚举类型要把所有可选值列全。还有一个经常被忽略的点工具返回结果要做“裁剪”。模型工具的返回结果如果太长会占用大量上下文、稀释注意力。我的处理办法是行情工具只返回日期、开高低收、成交量这几个核心字段检索工具先返回标题、时间、来源和摘要模型觉得需要全文再单独调用计算工具只返回输入和结果的简洁JSON。上下文这个东西能省一token是一token。4.3 记忆与上下文管理工作记忆和长期知识库分离百亿token的知识库永远不可能塞进上下文所以“记忆”必须分层。我这里把记忆分成两层当前任务的工作记忆和跨任务的长期知识库。工作记忆是任务进行过程中产生的中间状态包括规划出的子任务列表、已经检索到的证据、已经算出来的中间指标。任务结束之后工作记忆并不会被丢弃而是经过一次压缩整理后沉淀成摘要写入长期知识库。长期知识库里存的是“已经确认过的事实”。比如这次分析确认了“某公司2023年扣非净利润为一定金额”这个事实经过原始数据校验后写进事实库下次任何任务引用这个数字时可以直接查事实库不用重新翻原始文档。这个设计在投资场景格外好用因为很多数字会被反复问到事实库相当于给agent准备了一个“小本本”。还有一个上下文管理的技巧喂给模型的证据不是越多越好。我的原则是“先压缩后输入”。每个工具返回的原始内容先经过一层提取把和当前子任务相关的部分提炼成简洁的结构化要点再拼进prompt。实测下来同样一个任务的推理质量在证据经过压缩之后反而更高因为模型注意力没有被冗余信息分散。4.4 防幻觉三道闸门一个都不能少投资场景对幻觉的容忍度是零。模型如果编造一个财务数字轻则误导决策重则直接导致亏损。我花了大量时间在防幻觉上最后沉淀成三道闸门。第一道闸门是证据闸门没有来源引用就不允许输出。在系统的prompt约束里明确要求任何面向用户的断言必须挂一个来源引用引用可以是结构化财务数据的查询记录也可以是某个文档chunk的编号。如果模型想输出一个没有证据支撑的判断它必须先调用检索工具找证据找不到就明说找不到。第二道闸门是校验闸门面向数字类结论必须回查原始数据。模型的中间输出如果出现了财务数字会经过一个独立的校验模块把数字和结构化财务库里的原始值比对不一致就标记为“待确认”并触发重新查询。这个模块不依赖模型自身是一段确定性的代码逻辑所以非常可靠。第三道闸门是置信度闸门证据不足时主动承认不确定。我给模型明确授权当检索到的证据不足、证据互相矛盾、或时效性无法确认时你有权回答“基于现有信息无法确认建议补充以下数据”。在投资场景里一个诚实的“不知道”远远好过一个编造的“知道”。这三道闸门全部是强约束写死在系统层面而不是依赖模型自觉。模型可能今天听话明天跑偏但代码和确定性校验不会。我宁愿这套系统偶尔回答得保守一点也绝不接受它给出一个没有来源的确定结论。5. 成本、性能、评测手搓项目的工程三件套5.1 成本到底怎么算一次深度分析的真实账单手搓系统的成本核心是模型调用费用基础设施相比之下反而不大。我把一次深度投资分析任务的token消耗拆开看大致分布是这样的任务规划阶段消耗几千token五到八个子任务的检索和推理平均每个消耗几千token证据压缩和汇总阶段消耗万级token最后生成报告再消耗万级。一次任务综合下来输入输出加起来大概在十万token左右。按当前主流商用API的典型价位粗略算输入token按百万token几十块钱量级、输出token按百万token上百块钱量级来估算一次深度分析的成本在几块钱到十几块钱之间。如果加上中间各种重试和工具调用保守按三倍算一次完整深度分析控制在几十块钱以内是可以做到的。成本优化的空间比想象中大。我做了三件事一是缓存完全相同的检索请求走缓存热点查询命中率能达到一半以上二是路由简单任务走轻量模型深度分析才走最强的模型日常问答类请求成本直接下降八成三是证据裁剪检索结果的注入量减掉一半输入成本立刻跟着减半。这些优化累计下来整体成本降了一个数量级。5.2 延迟优化从90秒到35秒的实战记录延迟是agent系统最容易翻车的地方。用户问一个问题如果一分钟还没动静耐心基本就耗尽了。我第一版系统经常要一分半钟才返回经过三轮优化才压到半分钟以内。第一轮优化是并行化。把六个串行子任务改成两轮并行第一轮并行执行财务、新闻、公告、行情四个检索第二轮在拿到财务数据之后再并行执行行业对比和估值分析。延迟从九十秒降到六十秒。第二轮优化是缓存和预取。高频请求比如“当前市值”“最新收盘价”直接走本地缓存检索模块的嵌入计算也做了结果缓存。整链路降到四十五秒。第三轮优化是流式输出和工作记忆压缩。报告生成改成流式用户先看到框架再看到细节感知延迟大幅下降。同时每个子任务的中间输入都做了压缩传给模型的token减少模型处理时间也跟着缩短。最终把时间压到半分钟以内对深度分析场景来说已经可以接受了。延迟优化的核心思路就一句话把能并行的并行把能缓存的缓存把不需要的token减掉。凡是能提前算的绝不在请求时算凡是能复用的绝不算两遍。5.3 评测体系不要相信感觉要相信测试集手搓agent最大的风险是“感觉挺好用”。一个人调出来的系统很容易陷入自我感觉良好的陷阱。我建立了一套三层的评测体系来对抗这种主观性。第一层是检索质量评测。我手工标注了一批“问题-预期证据”对比如“某公司最近一次股权激励的考核目标是什么”应该召回对应的公告段落。评测时跑批量查询算召回率、命中率和排序质量。这个测试集我持续扩充每改一次检索策略就全量跑一遍防止优化A指标的同时把B指标搞坏。第二层是推理质量评测。针对常见任务类型准备测试集比如财务趋势分析、新闻舆情汇总、估值区间判断。每次批量跑完后做人工打分分维度记录事实准确性、逻辑完整性、证据支撑度、表述清晰度。人工打分虽然费时但对投资这种高价值场景完全值得。第三层是链路回归。每次修改系统后把用户历史上真实问过的任务重新跑一遍对比新旧版本的输出差异。这个习惯让我避免了很多次“修好一个bug、引入两个新bug”的尴尬。评测这件事听起来不酷但恰恰是它决定了一个手搓系统能不能长期可靠。没有测试集你根本不知道自己改代码是在进步还是在退步。6. 落地过程中踩过的坑6.1 检索到的内容是过时甚至错误的这个坑是我早期踩得最狠的。系统上线初期经常出现“去年三季度的公告被当成最新动态”的情况原因是索引按发布时间排序时一部分公告的发布时间字段解析错了被默认成入库时间。后来我在索引层加了时间校验规则凡是解析出的发布时间早于入库时间的一律视为解析异常走二次处理。这里补一句时间信息在投资场景就是命根子宁可字段为空标成“未知”也不能把错误时间当正确时间存进去。6.2 模型一本正经地编财务数据幻觉问题出现过一轮特别严重的模型直接说出了“某公司毛利率45%”但原始财报里根本没有这个数字是模型从上下文里推断出来的。问题出现在中间推理环节模型把“毛利率较高”这种定性表述直接外推成了具体数字。修复方式就是前面提到的校验闸门所有数字类输出强制过原始数据校验。从那以后这种编造数字的问题基本绝迹。6.3 离线数据与实时数据“打架”知识库是离线建好的行情是实时查询的这两个源经常给出不一致的数字。比如知识库里存的上一季度营收是A模型引用它回答但公司刚发了业绩快报实际营收是B。模型的回答就会自相矛盾。解决方案是所有文本证据在检索时必须标注“信息截止日期”而结构化财务数据和实时工具返回的数据优先级更高一旦发现矛盾统一以时间最新的数据为准并在报告中注明差异。6.4 成本被无效检索白白吃掉有段时间成本曲线涨得吓人排查后发现是agent在事实已经足够清楚的情况下仍然反复调用检索工具去“确认”属于典型的过度执行。修复方式是加了一个“自评停走”机制子任务执行完成后主agent先判断当前证据是否已满足任务需求如果满足就直接进入汇总不再做额外检索。这一步优化把平均每次任务的工具调用次数从十几次降到五六次成本几乎砍半。6.5 一次对话时间太长用户体验崩掉我有一次给朋友演示系统跑了将近两分钟才出结果场面极其尴尬。事后分析发现是报告生成阶段塞了太多格式化要求模型为了满足格式而去生成大量过渡性文字。修复方式是把报告模板拆成“结论先行”和“详细分析”两个阶段用户先看到结论和关键数字再按需加载详细部分。同时给生成阶段减少了不必要的格式化约束输出质量反而更高。下面把这些典型问题和处理方式整理成速查表问题典型现象根因方向有效解法过时内容旧公告被当新消息时间字段解析错误时间校验规则加二次处理编造数字模型输出财报不存在的数值中间推理过度外推数字类输出强制回查原始数据数据打架离线知识与实时数据矛盾多数据源缺乏优先级按时间新鲜度与来源等级排序成本失控工具调用次数激增agent过度执行自评停走机制限制无效检索响应过慢用户等待超过90秒串行任务过多、输出冗余并行化加结论先行模板7. 接下来还能往哪走当前这套系统已经能承担大部分基本面分析工作但我心里很清楚它离“理想中的投资agent”还有距离。下一步我想做的是多智能体分工。现在是一个主agent干所有事下一步可以把数据采集、财务分析、舆情监控、风险检查各拆成一个专职智能体主agent做调度和汇总。这就像从一个人干全活变成一个团队协作每个环节的专注度和可靠性都会有提升。另一个方向是把交易闭环接进来。当前系统停止在“分析和建议”还没有把决策和执行连起来。接闭环之后需要面对的问题是滑点、仓位、风控、对账这个领域的工程复杂度和信息处理完全不是一个量级但也是投资agent价值最大的延伸方向。还有一个想法是让agent学会说“我需要确认”。现在的系统已经能做到证据不足时承认不确定但还不够主动。我理想中的agent应该在证据不足时主动提出“我需要去核实以下三个数据请给我时间”或者“建议你关注这几个尚未披露的事项”。这种主动性和边界意识才是严肃决策工具最需要的品质。最后说点个人体会。做了大半年我最大的感受是投资agent真正值钱的部分不是模型不是框架甚至不是算法而是那一套清洗干净、结构合理、来源可信的数据管道以及围绕它建立起来的工作流纪律。任何一个人只要能忍受信息处理的枯燥能把审计思维刻进系统的每一个环节都能做出一个虽然不完美、但完全属于自己的投资分析工具。模型会迭代产品会过时但你对数据的理解和对流程的敬畏才是这套系统里最不可复制的东西。 
长河君 · 2026/10/13 16:41:20 · 阅读 1.2k 手搓百亿token投资agent：RAG架构、数据管道与推理工作流实战
先交代一下背景。过去大半年时间我利用业余时间从零手搓了一套投资agent全量知识库大概几百亿token的量级涵盖财报、公告、研报、新闻和宏观数据。很多人听到“百亿token”第一反应是“这是不是把模型上下文干到了百亿”其实不是。这里的百亿token指的是知识库内容的总体量相当于几百万页金融文档转成token之后的总和。这个量级决定了整套系统的架构路线。先算一笔账让大家对百亿token有个体感。一份头部公司的年报PDF正文加附注大概五六万字token化之后在八万到十万之间半年报、季报、临时公告、业绩说明会纪要、评级调整公告、行业新闻这些全算上一家重点跟踪公司一年新增的有效信息大概三四百万token。如果持续跟踪两三百家公司再加上宏观数据库、行业数据库和历史新闻库做到百亿token其实不需要太多年就会碰到。这套agent能干什么你可以直接丢给它一个任务比如“分析某新能源公司最近三个季度的毛利率变化结合同行对比给出你的判断”。它会自己把任务拆成几十个小步骤自己去查财报、找新闻、跑行业对比、调行情数据最后给你一份带数据来源的结论报告。你不用告诉它第一步查什么、第二步算什么只需要在最后检查它给出的证据是否支持结论。这篇文章不是讲某个商业产品的使用心得而是讲我一个人从0到1做这套系统过程中沉淀下来的架构设计、数据管道细节、推理工作流、成本与性能优化、踩坑记录。适合三类人想自己做投资分析工具的个人投资者在做agent或者RAG应用落地的工程师以及好奇AI到底能不能用于严肃决策的产品经理。1. 先想清楚百亿token的投资agent到底解决什么问题1.1 投资分析的瓶颈从来不是模型不够聪明我见过很多人做AI投资工具的第一步都是“接个大模型API”然后就开始问“模型能不能帮我分析股票”。做了大半年之后我的体会很明确模型聪明程度反而最不需要担心真正难的是喂给模型的料够不够靠谱、够不够完整、来源是不是可信。投资分析本质上是一个信息处理问题。一家公司值不值得看需要同时知道它的财务数据、所在行业的景气度、竞争对手的动向、管理层最近的表述、市场情绪的变化。这些信息分散在年报、公告、新闻、研报、行情数据里。一个分析师一天能精读几份报告而市场一天新增的有效信息可能是几百份文档。人读不过来传统的搜索引擎又只能给你一堆链接你要自己一篇一篇打开、筛选、理解。投资agent做的事情是把“读取、筛选、理解、交叉验证”这一步从人身上搬到了机器身上。还有一个容易被忽略的点信息量过大时人脑的判断质量会显著下降。你会被最近看到的新闻带偏会被某个极端案例影响会忘记三个月前已经确认过的事实。机器没有这个毛病只要索引和数据管道扎实它可以一视同仁地去读取全量信息。这是投资agent相对于人类最实在的价值。1.2 百亿token决定了你必须走检索增强而不是硬塞这里要先澄清一个常见误解。经常有人问“既然模型支持很长的上下文把百亿token的知识库直接塞进去不就行了”答案是行不通的原因有三个。第一是成本。token是按用量计费的一次请求塞进几十亿token光输入成本就不是个人能承受的量级。按当前主流商用API的价格粗略算过如果一次分析任务把百亿token全部塞给模型单次成本相当于一辆入门家用车没有人会这么干。第二是时延。模型处理上下文的计算量随长度增长上下文越长首字返回越慢。就算你能付得起钱也没人愿意等几个小时才看到第一句话。第三是注意力稀释。模型在超长上下文里对关键信息的敏感度会下降距离很远的相关证据会被“淹没”在无关内容里。用检索把范围缩小到当前任务真正需要的几段证据效果反而更好。所以这个量级的正确路线就一条用检索增强的办法把“全量百亿token的知识库”变成“当前任务需要的几十段高相关证据”。人是怎么做研究的带着问题去图书馆翻书只读相关的章节然后把相关内容抄到笔记本上最后汇总成结论。agent也是这么干的只不过图书馆是向量库翻书是向量检索抄笔记是上下文管理。1.3 手搓和套壳的差别本质是控制权市面上确实有不少现成的AI投资助手但用一段时间你就会发现几个没法忍的问题。数据滞后。现成产品更新全量数据的速度取决于平台方你看到的信息可能已经过了一周。对投资决策来说晚一天可能就意味着完全不同的结论。回答泛泛而谈。很多产品只会给你“这家公司是行业龙头具备长期竞争力”这种正确但没用的废话。原因很简单它没有你的私有数据也没有针对你关注的标做深度的数据管道。不可审计。你不知道它内部到底查了什么、为什么给出这个结论。投资决策最忌讳的就是黑箱。手搓的核心价值是控制权。数据管道是自己的清洗标准是自己的检索策略是自己的提示词和工具是自己的成本模型也是自己的。出了任何一个问题你知道具体是哪一环可以立刻定位和修。想优化某个环节你知道往哪个方向使劲。这种可控性是任何套壳产品都给不了的。当然手搓不等于拒绝现成组件。LLM调用、向量数据库、开源OCR这些基础能力我没有重复造轮子直接用技术社区验证过的方案。手搓指的是整个系统的架构设计和数据链路是属于自己的而不是在一个别人封装好的“投资助手”外面套一层壳。2. 架构设计五层结构才能扛住百亿token2.1 五层结构全景整套系统的架构我拆成了五层每一层职责单一层与层之间通过明确的数据契约通信。数据采集层负责从各类公开数据源拉取增量内容和全量历史数据。解析与清洗层把PDF、HTML、扫描件、公告原文转成干净、结构化、带来源标记的文本。索引与检索层负责切分、向量化、建索引以及给推理层提供高质量的证据召回。推理与编排层是agent的大脑负责任务拆解、工具调用、记忆管理和结论生成。执行与输出层负责把结论转成报告、图表、摘要和告警。这五层里面我对“数据契约”这件事特别较真。每一层的输出都必须是一个明确、可检验的格式。采集层输出原始文件加元数据解析层输出markdown加表格结构索引层输出chunk加标量字段检索层输出证据块加相似度分数。有了这些契约任何一层的内部实现都可以随时替换而不影响其他层。2.2 为什么数据链和推理链必须分开做agent最容易犯的错误是一上来就写提示词、调模型。我第一版也这么干过结果很惨模型很聪明但喂进去的内容乱七八糟经常出现把两年前旧的公告当最新消息、把未经证实的网上传言当成事实。后来我才想明白投资agent系统里90%的问题出在数据链而不是推理链。数据链不干净推理层再聪明的模型也只能在垃圾上做推理。把数据链和推理链分开之后一个直接的好处是每层都可以独立做质量检查。解析层的输出可以用抽样检查确认表格没有被拆烂索引层的召回可以用评测集打分推理层的输出可以单独审计证据引用。出任何问题通过链路追踪就能定位到具体是哪个环节而不是在提示词里反复试来试去。另一个好处是独立扩展。数据管道可以一夜之间多处理一个数据源而不影响推理逻辑推理层想换一个更强的LLM只需要把数据契约适配好。这套架构让我在后面迭代时省了特别多时间。2.3 一次请求从进入到返回的完整链路我拿一个实际场景走一遍完整链路方便理解五层是怎么协作的。用户给agent下发任务“分析某消费白马公司的投资价值重点关注盈利质量和现金流。”主agent进入规划阶段把任务拆解为五个子任务拉取最近三个年度的财务数据、检索该公司近一年的新闻舆情、找行业对比数据、查询最新公告、拉取当前估值与历史区间。五个子任务并行执行。每个子任务对应一次或多次检索财务数据走结构化查询新闻和公告走向量检索估值数据走行情工具。检索结果回来之后先过一次重排模型把低相关证据过滤掉再按相关性和时效性排序取每个子任务最相关的前几段。然后每个子任务独立做一个小的推理得出结论比如“近三年毛利率从28%下滑到22%主要原因是原材料成本上升”。这些中间结论最后会送到汇总模块做交叉校验财务数字必须和原始报表一致新闻类结论必须标注发布日期不一致时以结构化财务数据为准。最后生成报告。报告里每个关键结论后面都挂着来源引用。整个流程跑下来大概一分多钟看起来像是把一个分析师团队的工作方式压缩到了分钟级。这个链路最重要的设计原则是每一步都可以停、可以查、可以回退。规划阶段拆出什么子任务检索阶段召回了什么证据推理阶段得出了什么中间结论全部有日志。这保证了你永远可以在事后回答“这个结论是怎么来的”。3. 数据管道百亿token是怎么一步步塌实整理出来的3.1 数据源的选择与优先级做投资agent数据源选型基本决定了系统能力的上限。我按“信息价值”和“结构化难度”两个维度整理了优先级。定期报告是核心中的核心。年报、半年报、季报包含最完整的财务数据和经营讨论是基本面分析的底座。临时公告覆盖重大事项比如并购、减持、业绩预告、诉讼进展往往是股价短期波动的主要驱动。新闻资讯覆盖市场情绪和动态时效性要求高但价值密度低、噪音大。宏观数据给整个分析提供背景利率、货币供应、行业景气指数这些指标会直接影响对个股的判断。研报提供机构观点但要注意立场偏差更适合作为参考而非事实。不同类型数据源的特征差异很大我整理成了下面这张表数据源类型典型格式更新频率结构化难度我的优先级定期报告PDF为主季度高最高临时公告网页/PDF实时中最高新闻资讯网页实时低高宏观数据结构化接口月度低中研报观点PDF/网页日高中说直白一点财报数据如果不做扎实后面全是空中楼阁新闻资讯虽然多但大多数对投资判断没有增量信息必须靠过滤而不是一股脑全存。3.2 解析层PDF、表格、扫描件的真实处理现场财报类PDF是整个数据管道里最磨人的部分。年报PDF经常是图片型、双栏混排、表格跨页、数字被拆分到两行有些扫描件甚至方向都是歪的。我的处理流程分四步。第一步是识别文档类型判断是文本型PDF还是扫描件扫描件统一走OCR。第二步是版面恢复用开源的版面分析能力把页面切成标题、正文、表格、页眉页脚几个区域页眉页脚直接丢弃。第三步是结构还原把多级标题的层级关系恢复出来标题和正文的层级关系就是后期文档切分的骨架。第四步是表格抽取把跨页表格合并成完整表结构转成结构化数据单独存放不混进正文。表格处理是最容易翻车的地方。年报里的资产负债表、利润表、现金流量表如果按普通文本切分数字会被拦腰截断检索的时候只能召回半张表。我的做法是所有表格在解析阶段就单独入库保留原始的“行名-列名-数值”结构检索表格时走专门的字段匹配而不是纯语义检索。OCR环节有个经验复杂表格的识别错误率不低所以凡是OCR识别出来的财务表格我都要求后续做一个数值合理性校验比如“净利润绝对值不能超过营业收入绝对值”这种基本约束不满足就打回重处理。宁可漏掉一条不要错存一条。3.3 去重与可信度信息质量的两道筛子金融文本的去重和普通网页去重还不一样。同一条新闻会被几十个媒体互相转载同一份公告会在不同平台重复出现而且转载过程中经常被改写标题可能变正文段落顺序也可能调。这就不能用简单的精确哈希去重。我用的方案是SimHash指纹加相似度阈值每篇文本算一个64位指纹两篇指纹的海明距离小于一定阈值就认为是近似重复只保留发布时间最早的一篇。实测下来新闻库的去重率能达到三成以上也就是说每十条新闻里有三条是重复内容。这个动作直接减少了存储和检索负担也让检索结果不再被同一条新闻刷屏。可信度分级是另一道筛子。我把数据源分了三个信任级别官方公告和定期报告是第一级直接可信主流财经媒体的报道是第二级可信但需要标注来源和发布时间自媒体、社交平台内容是第三级只在做舆情分析时使用并且必须明确标注为市场情绪而非事实。这个分级会在索引阶段写进metadata里推理层可以据此校对证据权重避免模型把论坛上的小道消息当成基本面事实。3.4 切分策略chunk size不是拍脑袋定的RAG系统里文档切分是直接决定检索质量的一个环节。很多人直接用固定长度切比如512个token切一块、再重叠80个token省事但效果一般。金融文档有非常强的结构特征不利用起来很可惜。我的切分策略分三种类型。第一类正文按语义段落切单块控制在600到900个token之间相邻块重叠80个token。第二类表格单独切每张完整表作为独立chunk不做截断。第三类公告类短文档一整个公告通常就是一个语义单位直接整体入库不强行切碎。为什么把正文单块控制在600到900个token这是一组对比实验之后定下来的。块太小比如200个token检索召回的碎片太多模型看不到完整上下文块太大比如1500个token块内信息太杂语义中心被稀释召回精度明显下降。600到900的区间对财报这种信息密度高的文本比较合适既保留了上下文的完整性又控制了无关内容的干扰。长文档还有一个必须处理的细节切分之前先重建“标题树”。一份年报有十几章每章下面还有多级小节如果平铺直叙切块每块就失去了它在全文中的位置信息。我先根据标题层级把文档组织成一棵树切分时把“章节路径”以metadata的方式写进每个chunk比如“2023年报管理层讨论与分析盈利能力”。这样检索时不仅能看到块内容还能看到它在文档里的位置大幅减少“句子单独看没问题、放回上下文被误读”的情况。3.5 索引层向量与标量的双通道索引索引层是数据管道和推理层之间的桥梁。我同时保留了两套索引一套是固定字段的标量索引一套是文本语义的向量索引。标量索引管时间和类型维度比如“发布日期在最近30天内的公告”“来源等级为一级的财务报告”。向量索引管语义相似度比如“找一段描述现金流恶化风险的内容”。检索时先做标量过滤缩小候选集再做向量召回最后用重排模型精排。这个顺序让精确性和语义性都能兼顾。embedding模型的选择标准我认为有三条是底线支持中文语境、对金融术语的语义理解不跑偏、在长文本上不会把关键信息稀释掉。我做过一个简单的小测试把“毛利率”和“净利率”以及“毛利率”和“流动比率”这两组词分别embedding看相似度差别。如果模型连这种基本的财务术语距离都分不清检索质量一定好不了。向量库的筛选标准更多落在工程层面能否支持大规模数据的高并发检索、向量维度适配、标量过滤和向量检索能不能在单次查询里组合、增量更新方不方便。百亿token的文本量级切出来的chunk可能上千万条这个量级对向量库的压力主要在内存和召回延迟上选型时一定要用真实规模压测过再定千万不要用小数据集测出来的结果去推大集群。4. 推理层agent到底是怎么“思考”和干活的4.1 工作流编排为什么Plan-and-Execute比ReAct更适合投资场景agent的核心机制是让模型自主决定下一步做什么。最早做demo时我用了最朴素的ReAct循环模型每一步推理一下、决定调用一个工具、观察结果、再推理。demo能跑通但实际用下来发现两个问题决策链太长导致token消耗大而且中间任一步判断出错后面全跟着偏。后来我换成了Plan-and-Execute的思路主agent先做一轮全局规划把任务拆成一组相对独立的子任务然后再为每个子任务单独执行一个小的ReAct循环。这个改变带来的收益非常明显。第一个收益是可检查性。规划阶段输出的计划人可以提前审一遍发现拆得不对可以直接修正而不是等模型执行完才看到结果。第二个收益是并行性。子任务之间只要没有依赖就可以并行执行整体延迟从串行的累加变成了最慢那条分支的耗时。第三个收益是token成本下降。拆解后的每个子任务只携带和它相关的上下文不用把整盘任务背景重复堆给每一步。投资分析场景天然适合这种方式因为投资任务的价值在于“广覆盖、可复查、有标准流程”而不是在对话里随意发散。一个分析师看一家公司也应该是有步骤的先看财务再看业务再看行业再看风险。把这种步骤变成agent的规划模板输出质量会明显提高。我在实现的时候给主agent内置了几套规划模板比如基本面分析模板、财报解读模板、舆情监测模板。用户的任务先做一次意图分类匹配到最合适的模板再由模型在模板基础上做补充和调整。这样既能保证流程结构不乱又保留了灵活性。4.2 工具调用agent的“手脚”设计工具是agent接触真实世界的方式。没有工具它只能凭记忆回答有了工具它才能拿到实时行情、查原始报表、算财务指标。我把工具分成五类行情类、财务数据类、检索类、计算类、报告类。行情类工具负责实时价格、历史K线、估值分位。财务数据类工具负责从结构化财务库直接查询指标比如“某公司2023年扣非净利润、经营现金流”这类精确数据。检索类工具负责从向量库里召回文本证据比如新闻、公告、研报段落。计算类工具负责指标计算避免模型自己口算财务比率。报告类工具负责把结论组装成结构化报告。function calling的效果很大程度上取决于工具描述写得清不清楚。我吃过很多亏之后总结了一条经验工具描述要用“动词对象边界”的结构来写。比如一个财务查询工具描述应该写清楚“当用户需要某公司某个报告期的具体财务科目数值时使用此工具”而不是笼统写“查询财务数据”。参数说明更要明确数字类型的参数要把单位、时间格式都写清楚枚举类型要把所有可选值列全。还有一个经常被忽略的点工具返回结果要做“裁剪”。模型工具的返回结果如果太长会占用大量上下文、稀释注意力。我的处理办法是行情工具只返回日期、开高低收、成交量这几个核心字段检索工具先返回标题、时间、来源和摘要模型觉得需要全文再单独调用计算工具只返回输入和结果的简洁JSON。上下文这个东西能省一token是一token。4.3 记忆与上下文管理工作记忆和长期知识库分离百亿token的知识库永远不可能塞进上下文所以“记忆”必须分层。我这里把记忆分成两层当前任务的工作记忆和跨任务的长期知识库。工作记忆是任务进行过程中产生的中间状态包括规划出的子任务列表、已经检索到的证据、已经算出来的中间指标。任务结束之后工作记忆并不会被丢弃而是经过一次压缩整理后沉淀成摘要写入长期知识库。长期知识库里存的是“已经确认过的事实”。比如这次分析确认了“某公司2023年扣非净利润为一定金额”这个事实经过原始数据校验后写进事实库下次任何任务引用这个数字时可以直接查事实库不用重新翻原始文档。这个设计在投资场景格外好用因为很多数字会被反复问到事实库相当于给agent准备了一个“小本本”。还有一个上下文管理的技巧喂给模型的证据不是越多越好。我的原则是“先压缩后输入”。每个工具返回的原始内容先经过一层提取把和当前子任务相关的部分提炼成简洁的结构化要点再拼进prompt。实测下来同样一个任务的推理质量在证据经过压缩之后反而更高因为模型注意力没有被冗余信息分散。4.4 防幻觉三道闸门一个都不能少投资场景对幻觉的容忍度是零。模型如果编造一个财务数字轻则误导决策重则直接导致亏损。我花了大量时间在防幻觉上最后沉淀成三道闸门。第一道闸门是证据闸门没有来源引用就不允许输出。在系统的prompt约束里明确要求任何面向用户的断言必须挂一个来源引用引用可以是结构化财务数据的查询记录也可以是某个文档chunk的编号。如果模型想输出一个没有证据支撑的判断它必须先调用检索工具找证据找不到就明说找不到。第二道闸门是校验闸门面向数字类结论必须回查原始数据。模型的中间输出如果出现了财务数字会经过一个独立的校验模块把数字和结构化财务库里的原始值比对不一致就标记为“待确认”并触发重新查询。这个模块不依赖模型自身是一段确定性的代码逻辑所以非常可靠。第三道闸门是置信度闸门证据不足时主动承认不确定。我给模型明确授权当检索到的证据不足、证据互相矛盾、或时效性无法确认时你有权回答“基于现有信息无法确认建议补充以下数据”。在投资场景里一个诚实的“不知道”远远好过一个编造的“知道”。这三道闸门全部是强约束写死在系统层面而不是依赖模型自觉。模型可能今天听话明天跑偏但代码和确定性校验不会。我宁愿这套系统偶尔回答得保守一点也绝不接受它给出一个没有来源的确定结论。5. 成本、性能、评测手搓项目的工程三件套5.1 成本到底怎么算一次深度分析的真实账单手搓系统的成本核心是模型调用费用基础设施相比之下反而不大。我把一次深度投资分析任务的token消耗拆开看大致分布是这样的任务规划阶段消耗几千token五到八个子任务的检索和推理平均每个消耗几千token证据压缩和汇总阶段消耗万级token最后生成报告再消耗万级。一次任务综合下来输入输出加起来大概在十万token左右。按当前主流商用API的典型价位粗略算输入token按百万token几十块钱量级、输出token按百万token上百块钱量级来估算一次深度分析的成本在几块钱到十几块钱之间。如果加上中间各种重试和工具调用保守按三倍算一次完整深度分析控制在几十块钱以内是可以做到的。成本优化的空间比想象中大。我做了三件事一是缓存完全相同的检索请求走缓存热点查询命中率能达到一半以上二是路由简单任务走轻量模型深度分析才走最强的模型日常问答类请求成本直接下降八成三是证据裁剪检索结果的注入量减掉一半输入成本立刻跟着减半。这些优化累计下来整体成本降了一个数量级。5.2 延迟优化从90秒到35秒的实战记录延迟是agent系统最容易翻车的地方。用户问一个问题如果一分钟还没动静耐心基本就耗尽了。我第一版系统经常要一分半钟才返回经过三轮优化才压到半分钟以内。第一轮优化是并行化。把六个串行子任务改成两轮并行第一轮并行执行财务、新闻、公告、行情四个检索第二轮在拿到财务数据之后再并行执行行业对比和估值分析。延迟从九十秒降到六十秒。第二轮优化是缓存和预取。高频请求比如“当前市值”“最新收盘价”直接走本地缓存检索模块的嵌入计算也做了结果缓存。整链路降到四十五秒。第三轮优化是流式输出和工作记忆压缩。报告生成改成流式用户先看到框架再看到细节感知延迟大幅下降。同时每个子任务的中间输入都做了压缩传给模型的token减少模型处理时间也跟着缩短。最终把时间压到半分钟以内对深度分析场景来说已经可以接受了。延迟优化的核心思路就一句话把能并行的并行把能缓存的缓存把不需要的token减掉。凡是能提前算的绝不在请求时算凡是能复用的绝不算两遍。5.3 评测体系不要相信感觉要相信测试集手搓agent最大的风险是“感觉挺好用”。一个人调出来的系统很容易陷入自我感觉良好的陷阱。我建立了一套三层的评测体系来对抗这种主观性。第一层是检索质量评测。我手工标注了一批“问题-预期证据”对比如“某公司最近一次股权激励的考核目标是什么”应该召回对应的公告段落。评测时跑批量查询算召回率、命中率和排序质量。这个测试集我持续扩充每改一次检索策略就全量跑一遍防止优化A指标的同时把B指标搞坏。第二层是推理质量评测。针对常见任务类型准备测试集比如财务趋势分析、新闻舆情汇总、估值区间判断。每次批量跑完后做人工打分分维度记录事实准确性、逻辑完整性、证据支撑度、表述清晰度。人工打分虽然费时但对投资这种高价值场景完全值得。第三层是链路回归。每次修改系统后把用户历史上真实问过的任务重新跑一遍对比新旧版本的输出差异。这个习惯让我避免了很多次“修好一个bug、引入两个新bug”的尴尬。评测这件事听起来不酷但恰恰是它决定了一个手搓系统能不能长期可靠。没有测试集你根本不知道自己改代码是在进步还是在退步。6. 落地过程中踩过的坑6.1 检索到的内容是过时甚至错误的这个坑是我早期踩得最狠的。系统上线初期经常出现“去年三季度的公告被当成最新动态”的情况原因是索引按发布时间排序时一部分公告的发布时间字段解析错了被默认成入库时间。后来我在索引层加了时间校验规则凡是解析出的发布时间早于入库时间的一律视为解析异常走二次处理。这里补一句时间信息在投资场景就是命根子宁可字段为空标成“未知”也不能把错误时间当正确时间存进去。6.2 模型一本正经地编财务数据幻觉问题出现过一轮特别严重的模型直接说出了“某公司毛利率45%”但原始财报里根本没有这个数字是模型从上下文里推断出来的。问题出现在中间推理环节模型把“毛利率较高”这种定性表述直接外推成了具体数字。修复方式就是前面提到的校验闸门所有数字类输出强制过原始数据校验。从那以后这种编造数字的问题基本绝迹。6.3 离线数据与实时数据“打架”知识库是离线建好的行情是实时查询的这两个源经常给出不一致的数字。比如知识库里存的上一季度营收是A模型引用它回答但公司刚发了业绩快报实际营收是B。模型的回答就会自相矛盾。解决方案是所有文本证据在检索时必须标注“信息截止日期”而结构化财务数据和实时工具返回的数据优先级更高一旦发现矛盾统一以时间最新的数据为准并在报告中注明差异。6.4 成本被无效检索白白吃掉有段时间成本曲线涨得吓人排查后发现是agent在事实已经足够清楚的情况下仍然反复调用检索工具去“确认”属于典型的过度执行。修复方式是加了一个“自评停走”机制子任务执行完成后主agent先判断当前证据是否已满足任务需求如果满足就直接进入汇总不再做额外检索。这一步优化把平均每次任务的工具调用次数从十几次降到五六次成本几乎砍半。6.5 一次对话时间太长用户体验崩掉我有一次给朋友演示系统跑了将近两分钟才出结果场面极其尴尬。事后分析发现是报告生成阶段塞了太多格式化要求模型为了满足格式而去生成大量过渡性文字。修复方式是把报告模板拆成“结论先行”和“详细分析”两个阶段用户先看到结论和关键数字再按需加载详细部分。同时给生成阶段减少了不必要的格式化约束输出质量反而更高。下面把这些典型问题和处理方式整理成速查表问题典型现象根因方向有效解法过时内容旧公告被当新消息时间字段解析错误时间校验规则加二次处理编造数字模型输出财报不存在的数值中间推理过度外推数字类输出强制回查原始数据数据打架离线知识与实时数据矛盾多数据源缺乏优先级按时间新鲜度与来源等级排序成本失控工具调用次数激增agent过度执行自评停走机制限制无效检索响应过慢用户等待超过90秒串行任务过多、输出冗余并行化加结论先行模板7. 接下来还能往哪走当前这套系统已经能承担大部分基本面分析工作但我心里很清楚它离“理想中的投资agent”还有距离。下一步我想做的是多智能体分工。现在是一个主agent干所有事下一步可以把数据采集、财务分析、舆情监控、风险检查各拆成一个专职智能体主agent做调度和汇总。这就像从一个人干全活变成一个团队协作每个环节的专注度和可靠性都会有提升。另一个方向是把交易闭环接进来。当前系统停止在“分析和建议”还没有把决策和执行连起来。接闭环之后需要面对的问题是滑点、仓位、风控、对账这个领域的工程复杂度和信息处理完全不是一个量级但也是投资agent价值最大的延伸方向。还有一个想法是让agent学会说“我需要确认”。现在的系统已经能做到证据不足时承认不确定但还不够主动。我理想中的agent应该在证据不足时主动提出“我需要去核实以下三个数据请给我时间”或者“建议你关注这几个尚未披露的事项”。这种主动性和边界意识才是严肃决策工具最需要的品质。最后说点个人体会。做了大半年我最大的感受是投资agent真正值钱的部分不是模型不是框架甚至不是算法而是那一套清洗干净、结构合理、来源可信的数据管道以及围绕它建立起来的工作流纪律。任何一个人只要能忍受信息处理的枯燥能把审计思维刻进系统的每一个环节都能做出一个虽然不完美、但完全属于自己的投资分析工具。模型会迭代产品会过时但你对数据的理解和对流程的敬畏才是这套系统里最不可复制的东西。