前段时间在一个内部模拟项目里我决定不走现成的SaaS也不套开箱即用的Agent框架从底层开始手搓一个投资agent。系统前后积累的语料、训练和运行轨迹加起来到了百亿token级别模型调度、数据清洗、工具调用、仓位计算、风控回测全部在一套自建链路里跑。趁着这些坑还热乎我把这个agent到底怎么工作的一次性拆完尤其是一些被文档和Demo掩盖掉的反直觉细节。这个投资agent做的事情很简单把“投资研究员交易员”的部分日常工作自动化。它接收新闻、财报、行情等数据调用各种分析工具最后输出带有置信度的结论和建议。它不只是一个会聊天的机器人而是一个能自主规划任务、操作函数、读取结构化数据的完整系统。如果你正在琢磨大模型怎么落地到投研、量化或其他决策类场景这篇文章应该能帮你少走很多弯路。1. 为什么是“百亿token”为什么是“手搓”1.1 投资agent到底是个什么东西很多人一听到“投资agent”第一反应是让大模型看看行情图然后告诉我买什么。实际上这个定位太模糊也太危险。一个真正能用的agent至少要完成四件连续的事情感知信息、拆解目标、调用工具、输出带约束的决策。这里面每一步背后都有对应的工程模块任何一个环节掉链子结果都是不可用的。我做的这个agent核心是把大模型当作“调度中枢”而不是“答案生成器”。大模型负责理解任务、判断需要什么数据、决定调用哪个工具、组织最终结论。而具体的数字、事实、行情快照全部从外部工具拿不让模型自己凭记忆编。这套思路上手之后你会发现投资agent其实就是一个“长着大模型大脑的自动化投研流水线”。投研场景比其他Agent场景更难的地方在于信息时效性极强。昨天的数据可能今天就失效财报数字差一个零结论就完全反过来。所以agent必须对时间戳极度敏感对数据来源极度较真。这意味着很多通用Agent框架里好用的东西到了投研场景反而要重新设计。1.2 “百亿token”到底意味着什么先解释一下token的概念。token是模型处理文本的基本单位一个token可以是一个词的一部分、一个完整单词也可以是一个汉字片段。中文百亿token换算过来大概是几十亿到上百亿个汉字相当于把几万份财报、几十万篇新闻、上百万条公告和研报里的文字全部喂给模型。这些数据不是一次性填进提示词里的。模型有上下文窗口限制不可能把百亿token都塞进一次推理里。真正的用法分两条线一条线是离线训练把海量语料做继续预训练和指令微调让模型“懂行话、懂格式、懂工具调用”的底层能力变强另一条线是在线运行每次决策只抽取出最相关的几十万token进上下文用检索和工具调用把信息密度提高。所以“百亿token”不是指一个模型吃了百亿长度的一次性输入而是指整个系统在训练和运行层面累计消耗的语料总量。这个量级的好处是覆盖的公告、研报、新闻类别足够多模型对各种边缘表达都有了基本认知。缺点是数据清洗工作量非常大占到整个项目一半以上的工时这点后面详细说。1.3 为什么必须手搓而不是买现成的市面上的金融大模型和Agent平台越来越多但在我这个场景里直接用现成品有几个绕不过去的问题。第一是可控性投资agent的错误代价极高我需要能审计每一次调用、每一个参数、每一行逻辑现成黑盒产品很难做到。第二是数据隔离内部整理的语料和策略特征不想经过外部不可控的服务自建链路才可以把隐私边界牢牢攥在自己手里。第三是可变现投资场景的字段、术语、风控规则高度定制通用产品调整起来的成本往往比从头做还高。手搓最大的好处是透明。模型为什么调这个工具、为什么拒绝回答、为什么给出这个置信度每一个环节都有日志可查。模型出问题的时候你能直接定位到是prompt写得不清楚、微调数据不够、还是工具返回格式有歧义。这种可观测性在投研场景不是加分项而是刚需。当然代价也很明显。数据管道要自己搭模型微调要自己跑工具和风控要自己写排错周期长对人的综合能力要求很高。如果你只是想快速验证思路那完全可以先用现成框架但如果目标是长期可靠地跑手搓这条路带来的积累是不可替代的。2. 地基语料清洗与训练配方2.1 数据源选择与接入投资agent的上限不是模型决定的而是语料决定的。我最初收集的数据覆盖了公告、定期报告、券商研报、新闻流、行业数据和行情快照累计处理了大概几TB的原始文本。数据源的选择逻辑很简单凡是会影响投资决策的信息都应该有对应语料凡是噪音太大或者无法溯源的数据宁可不要。接入方式多种多样有API接口有离线文件包也有需要自己解析的网页结构。所有源都会统一转成JSONL格式字段固定为id、timestamp、source、title、content、meta。这里的timestamp是重中之重投资信息有强时效性没有时间的文本会污染整个训练集和决策链路。meta字段里会记录原始来源、抓取时间、解析版本用于后续溯源和审计。每天的增量更新机制也必不可少。初版我试过全量重跑既慢又浪费。后来改成每日增量拉取新数据进入待清洗队列清洗完再合并进总库。这样从源头保证信息新鲜度也让百亿token级别的大库可以持续滚动增长而不是越跑越脏。2.2 清洗和质量筛选原始文本的噪音比例远超想象。公告里的表格模板、研报页眉页脚、网页里夹带的广告和推荐位、新闻评论区这些内容直接进模型完全是灾难。清洗的第一步就是去掉这些模板和乱码再剔除纯图片、纯表格的无效文本最后把长文本按段落切块并补齐缺失字段。重复数据是另一个大坑。同一个公司公告会被多个源转载同一篇新闻会有几十个版本。如果不去重微调模型会被重复样本带偏在线检索也会召回一堆几乎一样的内容白白浪费宝贵的上下文空间。我用的是MinHash近似去重先把文本分块做指纹再通过局部敏感哈希找出重复项。这套方案对百亿级语料来说足够快准确率也在可接受范围内。清洗完之后还需要做质量打分。打分维度包括文本可读性、信息密度、行业相关性、时效性、是否包含具体数字和日期。低于阈值的片段直接丢弃。整个处理下来原始数据大概会淘汰掉一半以上。很多人觉得数据越多越好我的经验是投资场景里十份高质量公告胜过一千份没营养的口水文章。2.3 训练样本组织从“问答”到“决策过程”清洗后的文本不能直接用来训练agent。Agent需要的不只是“看懂文本”还需要学会“用工具完成任务”。所以需要把语料重组成三种类型的样本。第一类是领域继续预训练样本直接喂清洗后的原始文本让模型熟悉财务术语、公告格式和行业黑话。第二类是指令微调样本格式是“用户问题-工具调用序列-最终回答”模型要照着完整的决策链路去生成。第三类是工具调用样本专门训练模型在特定条件下选择正确工具并生成合法参数。第三类是最费功夫的。一条典型样本长这样用户问“某公司最近一个季度营收增速怎么样”模型应该先判断需要财务数据于是调用财报查询工具传入标的代码和报告期拿到返回结果后再做计算最后用自然语言总结。这个过程里工具调用的JSON格式必须完全正确参数不能多不能少日期和单位必须精确。为什么要费劲做这种微调而不是靠prompt让模型现学现用因为测试下来没有经过微调的模型在function calling上的表现非常不稳定。它经常把不存在的字段填进参数或者漏掉必填项甚至自己编一个工具出来。用高质量微调样本约束之后输出格式的合规率有质的提升这也为后面减少幻觉打下了基础。3. 投资agent的四层骨架感知、规划、工具、记忆3.1 一次完整决策的运行链路整个agent的架构拆开看是四层感知层、规划层、工具层、记忆层。感知层负责接收外部信号比如新闻推送、行情快照、定时任务触发规划层由大模型驱动负责把目标拆解成子任务工具层提供所有实际能力比如查询、计算、执行代码记忆层负责在长期跨度上保留状态和经验。一次完整的运行链路大概是这样的感知层检测到某只标的发布了财报于是生成一个“财报解读”任务。规划层拆解出三个子任务读取财务数据、对比历史数据、计算关键指标。接下来工具层依次执行财务数据查询和历史数据查询返回结构化结果。最后模型把结果组织成结论附上置信度和风险提示写入运行日志。这个链路最关键的地方在于模型不是一次性输出所有内容而是每走一步都看一眼工具返回的结果再决定下一步。这是一个自反馈循环而不是简单的“输入问题输出答案”。自反馈的好处是如果某个工具调用失败模型可以重新规划策略而不是将错就错继续编。这在投资场景里极其重要。为了让大家直观感受我贴一段高度简化的调度伪代码真实系统远比这个复杂但核心骨架就是这样。def run_agent(task): plan llm_plan(task, memory.retrieve(task)) for step in plan: if step.type tool: result call_tool(step.tool_name, step.params) if not result.success: step llm_replan(step, result.error) elif step.type reason: context summarize(plan, result, memory) answer llm_reason(context) memory.save(step, result, answer) return final_answer(answer)3.2 function calling工具层的接口设计工具层是agent的手和脚。在大模型场景里工具调用通常通过function calling实现模型根据工具描述生成一个结构化的调用请求系统执行后再把结果返回给模型。这里有一个核心设计原则工具数量要少而精接口要统一。我最初接了二十多个工具后来砍到十二个。工具太多模型的选择准确率会下降描述文档也会占用上下文。每个工具的描述要写得非常具体包括用途、入参、出参、示例甚至包括常见坑点。比如行情查询工具描述里要说明“输入统一使用某标准代码日期使用YYYY-MM-DD格式若停牌则返回状态字段”。工具返回格式也必须标准化我统一用JSON结构status表示成功或失败data存放结果error存放错误信息。这样模型无论拿到什么工具的结果都能用同一套逻辑处理。失败的返回里会带上错误原因和可能的修复建议比如“日期格式不正确请检查”这能显著降低模型重试时反复犯同样错误的概率。还有一个容易忽略的点工具权限边界。某个内部工具可以执行一段简单的Python脚本但运行环境和依赖库都是受控的脚本禁止访问网络、禁止写任意文件、禁止超过单次5秒执行时间。这种硬限制能防止模型在调试过程中产生无法预料的副作用。投资agent的工具调用发生在真实系统里防呆设计必不可少。3.3 记忆系统短期上下文与长期经验档案大模型本身没有记忆它只能看到当前上下文里的内容。要让agent看起来有连续性必须自己建记忆系统。我把它拆成两层短期上下文和长期经验档案。短期上下文解决的是“当前这个任务里前面做了什么”。比如分析一只股票前半段已经查了财务数据后半段就不需要重新查一遍。做法是维护一个任务级的状态记录把已调用的工具、已拿到的重要数据、已得出的中间结论都写进去。上下文快满的时候会对早期内容做摘要压缩只保留关键数字和结论丢掉原始文本。长期经验档案解决的是“类似的历史场景下我们吃过什么亏”。做法是把每次决策的关键要素存进向量数据库要素包括事件类型、市场环境、当时的核心数据、最终结果、复盘反思。当下一次任务到来时先用向量检索把最相似的历史经验捞出来拼进提示词让模型参考。这个设计对投资场景特别有用。比如模型之前处理过一次“高营收增长但毛利率下滑”的案例最后市场反应偏负面下次再遇到类似公司财报长期记忆就能提醒模型不要单纯因营收增速高就给乐观结论。这种能力不是预训练能带来的而是必须靠运行中积累出来的。4. 决策质量怎么控幻觉约束与仓位计算4.1 事实性约束与拒绝机制大模型在没有外部约束时会自信地编造数字。投资场景绝对不能让模型自由发挥这是整个系统里最重要的一条经验。我的做法是给模型立下三条硬规矩。第一所有具体数字必须来自工具返回结果不允许使用模型自身记忆里的数值。在系统提示词里明确写着“当你需要引用营收、利润、增长率、价格等数据时必须先通过工具获取如果工具没有返回对应数据请明确标注缺失而不是猜测。”这条规矩不完美但能挡住绝大多数幻觉。第二关键结论需要交叉验证。比如判断一个公司是否符合高增长特征财务表里查到营收增速是40%那么计算增速用的同比基数和本期数必须来自同一次工具返回不能从不同来源拼凑。系统会单独跑一个校验器检查结论中的关键数字与工具返回的原始数字是否一致不一致则打回重算。第三拒绝机制。当关键数据缺失、工具调用连续失败、或者模型置信度低于阈值时模型必须输出“需要更多信息”或“建议人工复核”而不是硬给一个结论。刚开始我觉得这样会让agent显得很笨后来发现这是它最聪明的设计。投资里没有把握时说“不知道”价值远大于瞎猜一个看似精确的方向。4.2 仓位计算与硬编码风控投资agent不能只给方向它最终要给出操作建议。如果建议涉及仓位就必须有可计算、可验证的规则。我的做法是把模型输出和实际仓位建议彻底解耦模型只负责生成方向判断和风险描述真正的仓位比例由独立的规则模块计算不让模型直接给出数字。仓位计算逻辑大致是这样先为每个标的风险设定一个可容忍的亏损预算然后用标的的历史波动率除以这个预算得到基础仓位上限如果多个标的高度相关会做相关性惩罚进一步降低各标的的仓位权重最后再把结果限制在硬性最大仓位之下比如单一标的不超过组合的一成单一行业不超过三成。这套逻辑不是让模型去理解而是把模型输出作为输入由规则模块机械计算。与模型输出解耦之外还需要硬编码风控层。这个风控层独立于大模型存在是最后一道闸门。无论模型怎么输出只要风控层判断超出预设条件比如标的价格波动触发异常阈值、组合回撤超过某一比例就会强制降仓或拒绝执行。模型可以犯错但硬风控不能让模型把整个组合拖下水。这里想强调一个底层观念模型的本性是生成文本不是计算最优组合。在任何涉及资金的场景里都不应该让模型直接输出可直接执行的交易指令至少要做一层独立的规则校验和强制执行。这不是对模型能力的不信任而是对复杂系统失控概率的必要敬畏。4.3 回测环境防止未来函数是底线一套agent策略上线前一定要在历史数据上回测。但回测里有一个特别阴险的坑叫作未来函数。未来函数指的是你在回测的某一天用了那一天之后才产生的数据。看起来像是指标更准了实际上是在作弊实盘时不可能复现。举个例子一篇财报解读新闻本来可能是在当日收盘后发出如果回测系统把它当作当日盘中可获取信息来决策就会过分乐观地假设能提前得到信息。为了杜绝这个问题系统里给每条数据都打上了严格的可获得时间戳回测引擎只允许读取“决策时点之前”的数据任何未来信息在那一刻都不存在。撮合环节也要做细。不能简单假设“想买就能按收盘价成交”。真实市场里有涨跌停、停牌、成交量限制和冲击成本。我的回测引擎把这些因素都建模进去成交量不超过当日平均成交量的某一比例涨停时买入单会被拒绝数据不足的标的不参与回测。这些约束会让结果看起来没那么漂亮但真实感强得多。对回测结果的态度我的经验是如果回测里的年化收益高到离谱比如比同期的市场基准高出几倍那么大概率不是策略牛而是回测某个环节出了bug比如未来函数、幸存者偏差或者过拟合。先检查数据时间戳再检查撮合逻辑最后再怀疑策略本身这个排查顺序能省很多时间。5. 真正跑起来之后踩过的坑5.1 工具调用幻觉比想象中严重即便是微调过的模型在真实运行中还是会出现工具调用幻觉。最典型的场景是模型生成了一个看似合理的工具调用但里面参数是编的。明明标的不存在某个财务字段模型还是传了一个自创的字段名进去明明某天没有交易数据模型却自动生成一条“停牌”描述来解释空缺。排查这类问题一定要把每次工具调用的日志完整记录下来。我会记录调用的工具名、全部参数、返回结果、耗时、错误信息。一旦发现异常参数就把当时的上下文截取下来放回模型里做采样测试看是不是稳定复现。如果稳定复现说明训练样本里缺少这类边界情况的负样本需要在微调数据里补充“工具不可用时的正确拒绝方式”。另一个有效手段是加一层执行前校验器。所有的工具调用参数都要先过校验器校验器里写清楚每个参数的类型、枚举范围、必填条件。参数不合法直接拦截返回错误信息给模型而不是带着错误参数执行真正的工具。这个拦截层成本很低但能把工具调用幻觉造成的破坏限制在系统边界之内。5.2 上下文爆炸与token成本失控投资agent跑起来之后我发现最大的性能瓶颈不是模型算得慢而是上下文太长。每次决策都要查新闻、调财报、算指标如果把这些过程全量塞进模型上下文一轮任务下来很容易冲到几十万token。推理时间变长费用变高模型对早期内容的注意力也下降。解决办法是把“检索”和“理解”分开。第一步先从新闻库和财报库里做召回拿回大量候选结果第二步用一个轻量级的rerank模型对候选结果排序只保留最有价值的8到15条进入最终上下文第三步把工具返回的长表格先压缩成摘要摘要只保留关键数字、日期和结论。经过这三步同样一个任务上下文能从几十万token压到几万token速度和成本都明显改善。压缩的时候有一个禁忌摘要不能丢数字。做摘要的模型我要它强制保留所有具体数值和日期只删掉修饰性语言。因为投资决策对数字极其敏感营收从10亿变成10.1亿可能改变结论压缩模块如果自作聪明地四舍五入会把整个分析带偏。这个细节如果没人提醒很容易被忽略。5.3 回答不稳定低温、多数投票与校准同样的输入模型跑两次可能给出完全不同的结论这在投资场景里是致命的。投资分析要可重复、可复核不能像一个情绪化的人一样今天看多明天看空。刚开始时我把温度调到0.1发现还是不够稳定因为采样过程本身还有随机性而且模型的内部状态在不同请求下依然存在微小差异。后来我引入了一套“决策投票”机制每次任务让模型独立跑5次每次用不同的采样顺序和随机种子然后对结论进行分层投票。第一层是方向投票大家是看多、看空还是中性第二层是幅度投票如果方向一致再看置信度高低第三层是冲突检测如果5次结果分歧太大系统判定为低置信度情况自动转人工复核或标记为不确定。这套机制的效果是单次模型的随机波动被平均掉了最终输出的稳定性大幅提高。代价是推理成本变成原来的5倍。但投资场景下稳定性比成本重要得多。我还把每次投票的原始结果都保存在日志里随时可以复盘某次结论为什么是多数派、少数派当时的观点是什么这对后续调优非常有价值。6. 百亿token之后还能往哪走这个agent做到现在最大的收获反而不是模型多聪明而是整个系统的“克制”。它知道什么时候该查数据什么时候该拒绝回答什么时候该让人来拍板。单纯让模型变得更强的边际收益已经远不如给系统增加正确的约束来得大。接下来我计划做三件事。第一给每个决策结论加归因分析到底是哪个数据、哪个历史经验导致了最后的判断让决策链路更加透明可解释。第二在多个独立agent之间引入对抗辩论一个负责看多一个负责看空最后由仲裁模块给出综合结论这比单个agent的自言自语更稳。第三继续扩充另类数据比如供应链、舆情情绪、地区事件等结构化弱相关的信息源让agent的感知范围更宽。最后分享一个调试小技巧非常管用。排查问题的时候先把所有工具调用都关掉让模型只基于纯文本做分析观察它的输出风格和错误模式然后逐个打开工具每打开一个就记录它对最终结果的边际贡献。哪一层引入之后出现了明显的问题问题往往就在那一层的工具描述、返回格式或校验逻辑上。这个方法能快速定位到浪费token和引入幻觉的环节比盲目调prompt高效得多。如果你正准备在类似方向上做一些尝试我的建议是不要急着追求大模型先想清楚你的agent每一步能调用什么、不能调用什么、拿到结果之后怎么验证。把边界划清楚剩下的工作都是在边界之内不断打磨。百亿token只是一个数字真正值钱的是这些token背后你如何看待“AI能做什么”和“AI不该做什么”之间的那条线。