1. 从零拆解一个投资Agent的骨架设计1.1 为什么是“手搓”而不是“调包”看到“百亿token手搓”这个说法很多人的第一反应是都烧了这么多token了为什么不直接上现成的框架我一开始也这么想但真正动手做过一轮之后才明白投资类Agent和普通的问答机器人完全是两码事。普通对话Agent可以容忍模糊、可以闲聊、可以答非所问但投资Agent不行——它输出的每一个数字、每一条逻辑链都要经得起推敲因为用户可能真的拿它辅助决策。“手搓”的核心原因在于可控性。市面上通用的Agent框架底层大多是“规划-执行-反思”的循环这套东西做任务型助手够用但放到投资场景里就会暴露三个致命问题第一工具调用的顺序不可控模型可能先查行情再查财报也可能反过来导致上下文里信息错位第二中间推理过程被框架封装出了问题根本不知道是哪一步歪的第三也是最要命的通用框架对“数据时效性”没有强约束模型可能拿着三天前的价格当成实时价来算。所以手搓的本质是把整个推理链路拆成显式的、可观测的、可干预的步骤。我把它归纳成一句话投资Agent不是让模型自由发挥而是给模型搭一个带护栏的流水线。这个流水线里模型负责它最擅长的语义理解和逻辑串联而数据的获取、校验、计算、风控全部由确定性代码来兜底。1.2 整体架构四层分离我最终落地的架构分成四层从下往上依次是数据层、工具层、推理层、编排层。这个分层不是拍脑袋定的而是踩过坑之后收敛出来的。数据层负责所有原始信息的接入和清洗。行情、财报、公告、宏观指标、新闻舆情来源五花八门格式千奇百怪。这一层的核心任务是把非结构化数据转成结构化并且打上时间戳和可信度标签。我试过让模型直接读原始新闻结果它把一条三年前的旧闻当成了最新消息因为新闻正文里没写日期模型自己“脑补”了一个。从那以后所有进入推理层的数据必须带明确的timestamp和source_credibility字段。工具层是模型能调用的所有函数的集合。这里有个关键设计原则工具粒度要细但数量要克制。我一开始设计了三十多个工具结果模型在规划时经常选错因为它面对的选择太多了。后来砍到十二个核心工具每个工具只做一件事比如get_price_history只负责拉历史价格get_financial_ratio只负责算财务比率模型的选择准确率立刻上来了。推理层是模型真正干活的地方。但这里不是简单地把问题丢给模型而是把任务拆成多个子步骤每个子步骤有明确的输入输出格式。比如分析一家公司推理层会依次执行识别用户意图→提取关键实体→规划数据需求→调用工具→整合分析→生成结论。每一步的输出都是下一步的输入形成一条链。编排层是总控负责调度、重试、降级和日志。这一层不涉及任何模型调用纯粹是工程逻辑。它的存在让整个系统在某个工具超时或返回异常时能够优雅地降级而不是直接崩溃。1.3 为什么不用多Agent协作很多人一提到复杂任务就想到多Agent一个负责查数据一个负责分析一个负责写报告。我早期也试过这个路子结论是在投资场景下多Agent的通信成本远大于收益。原因很简单投资分析需要的是信息的高度一致性。如果查数据的Agent和分析的Agent是两个独立的上下文那么分析Agent拿到的数据摘要很可能丢失了原始数据里的关键细节。比如查数据Agent返回“市盈率处于历史低位”但分析Agent需要知道具体分位数是多少、对比的是哪个时间段。这种信息在Agent间传递时会被压缩压缩就会失真。单Agent多步骤的方案所有中间结果都在同一个上下文里模型能看到完整的原始数据推理的连贯性更好。代价是上下文会很长token消耗大但这恰恰是“百亿token”的由来——用token换准确性在投资场景里是划算的。2. 核心模块的细节实现与踩坑记录2.1 意图识别别让模型猜用户想要什么用户输入“帮我看看某公司”这句话的信息量几乎为零。是看股价看财报看估值还是看新闻如果直接把这个丢给模型它会随机选一个方向或者更糟把所有方向都浅尝辄止地覆盖一遍输出一堆废话。我的做法是在推理层的最前面加一个意图分类器。这个分类器不是简单的关键词匹配而是一个小型的、经过微调的模型把用户输入映射到预定义的意图类别上。类别包括行情查询、财务分析、估值判断、舆情监控、组合诊断、策略回测等。这里有个细节意图分类器要输出置信度并且设置阈值。如果最高置信度低于0.7系统不会强行分类而是反问用户“您是想了解股价走势还是想分析财务健康度”这个反问机制上线后用户满意度明显提升因为模型不再自作聪明了。踩过的坑早期我用纯Prompt让大模型做意图分类准确率只有七成左右而且不稳定同样的输入两次结果可能不同。换成小模型微调后准确率稳定在九成以上而且推理速度快了一个数量级。在分类这种确定性任务上小模型永远优于大模型。2.2 数据获取时效性是生命线投资Agent最怕的就是数据过期。我设计了一套三级时效校验机制。第一级是数据源自带的时间戳。所有API返回的数据必须包含时间字段没有时间字段的数据一律丢弃。第二级是系统级的时间窗口检查。每个工具函数在返回数据前会检查数据时间与当前时间的差值如果超过预设阈值行情数据5分钟财报数据24小时宏观数据7天就打上stale标记。第三级是推理层的时效感知。模型在生成结论时如果引用了带stale标记的数据必须在输出中明确说明“该数据截至X时间可能存在滞后”。这套机制听起来简单但实现起来有个难点不同数据源的时钟不同步。我遇到过行情API返回的时间比系统时间慢了三分钟的情况导致所有数据都被误判为过期。解决办法是引入一个时钟偏移校准模块定期用权威时间源校准各数据源的时钟偏差把偏差值记录下来在时效检查时做补偿。另一个坑是数据源的静默失败。有些API在异常时不会报错而是返回一个空数组或者默认值。如果代码不检查返回内容的合理性就会把空数据当成真实数据传给模型。我的做法是给每个工具函数加返回值断言比如行情数据必须包含open/high/low/close/volume五个字段缺一个就抛异常触发重试或降级。2.3 工具调用的参数构造模型最容易翻车的地方让模型调用工具最难的不是选哪个工具而是构造正确的参数。比如查历史价格需要股票代码、开始日期、结束日期、复权方式四个参数。模型经常犯的错误包括日期格式不对写成“2024年1月”而不是“2024-01-01”、复权方式漏填、股票代码带了多余的前后缀。我的解决方案是参数模板模型填充代码校验三段式。每个工具函数都有一个对应的参数模板明确每个参数的类型、格式、取值范围。模型只负责从用户输入和上下文中提取值来填充模板填充完成后代码层会做严格的格式校验不合格的参数会被拦截并返回错误信息给模型让它重新填充。这里有个经验给模型的错误信息要具体。不要说“参数错误”而要说“日期格式应为YYYY-MM-DD您提供的是YYYY年MM月请重新提取”。模型看到具体的错误描述后修正的成功率大幅提升。还有一个进阶技巧参数默认值要合理。比如复权方式默认用前复权因为大多数分析场景下前复权更符合直觉。默认值的存在减少了模型需要填充的参数数量也就减少了出错概率。2.4 推理链的显式化让每一步都可追溯投资Agent的推理过程必须可追溯否则用户问“你为什么得出这个结论”系统答不上来信任就崩了。我的做法是把推理链拆成显式的步骤对象每一步都有step_id、step_type、input、output、timestamp、model_version等字段。这些步骤对象在数据库里持久化用户可以在界面上展开查看完整的推理路径。比如一个估值分析请求推理链可能是识别意图估值判断→提取实体某公司→获取财务数据近三年→计算估值指标PE/PB/PS→获取行业对比数据→生成估值结论。每一步的输入输出都记录在案。这个设计带来的额外好处是调试极其方便。当输出结果不对劲时我可以直接定位到是哪一步出了问题而不是面对一个黑盒抓瞎。我统计过有了推理链记录后问题定位时间从平均半小时缩短到五分钟以内。踩过的坑推理链的存储成本。百亿token的调用量如果每一步的完整输入输出都存数据库会爆炸。我的优化策略是分级存储关键步骤如最终结论、工具调用参数全量存储中间步骤只存摘要和哈希值需要时再根据哈希值从日志系统里捞完整内容。3. 完整实操流程从用户输入到最终输出3.1 第一步输入预处理与安全过滤用户输入进来后第一站是预处理模块。这个模块做三件事清洗、脱敏、合规检查。清洗包括去除多余空格、统一标点、纠正明显的错别字。脱敏是把用户可能输入的个人信息如手机号、身份证号替换成占位符。合规检查是确保输入不包含违规内容这一步用的是规则引擎加小模型的双重校验。这里有个细节预处理不能改变用户输入的语义。我见过一些系统在预处理阶段做了过度归一化把“这家公司咋样”改成了“这家公司怎么样”虽然意思没变但丢失了用户的口语化特征后续的意图分类反而可能受影响。我的原则是最小干预只做必要的清洗保留原始表达。3.2 第二步意图识别与任务规划预处理后的输入进入意图识别模块。前面说过这里用的是微调过的小模型输出意图类别和置信度。如果置信度达标系统进入任务规划阶段如果不达标触发反问机制。任务规划的核心是生成一个执行计划。这个计划不是让模型自由发挥而是从预定义的计划模板库里匹配。比如“估值判断”意图对应一个固定的计划模板获取财务数据→计算估值指标→获取行业数据→对比分析→生成结论。模型的任务是根据具体输入填充计划中的参数而不是重新设计计划。为什么用模板而不是让模型自由规划因为投资分析的流程是相对固定的自由规划带来的灵活性收益很小但不确定性风险很大。模板化保证了每次分析的流程一致结果可比。3.3 第三步工具调用与数据整合计划确定后进入工具调用阶段。这里的关键是并行与串行的合理编排。有些工具调用之间没有依赖关系可以并行执行比如获取行情数据和获取新闻舆情。有些则有严格的先后顺序比如必须先获取财务数据才能计算估值指标。我的编排策略是依赖图并行调度。系统根据计划生成一个依赖图没有前置依赖的节点并行执行有依赖的节点等前置完成后执行。并行度控制在合理范围内避免触发数据源的限流。数据整合阶段有个容易被忽视的问题不同数据源的单位和口径不一致。比如有的数据源用“万元”为单位有的用“元”有的用“百分数”有的用“小数”。如果不做统一模型算出来的结果会差几个数量级。我的做法是在数据层就做单位归一化所有进入推理层的数据单位必须是标准化的并且在元数据里记录原始单位和转换系数。3.4 第四步分析推理与结论生成数据齐备后进入分析推理阶段。这一步是模型真正发挥语义理解能力的地方但也不是完全自由。我给模型设定了结构化的输出格式要求它按照“数据摘要→分析逻辑→结论→风险提示”的四段式来组织输出。数据摘要部分模型需要引用具体的数据点和时间戳。分析逻辑部分模型需要说明推理的依据比如“基于近三年营收复合增长率15%高于行业平均的8%判断公司处于扩张期”。结论部分要明确、可证伪避免“可能”“或许”这类模糊表述。风险提示部分要列出分析中使用的假设和可能失效的条件。这里有个重要的经验给模型提供分析框架而不是让它自己发明框架。我试过让模型自由分析结果它有时候用DCF有时候用相对估值有时候混着用导致不同请求的结果不可比。后来我固定了几套分析框架根据意图选择对应的框架模型在框架内填充内容结果的一致性和专业性都大幅提升。3.5 第五步输出后处理与质量校验模型生成的结论不能直接返回给用户必须经过后处理。后处理包括数值合理性检查、逻辑一致性检查、合规复查。数值合理性检查是看模型输出的数字是否在合理范围内。比如市盈率不可能是负数除非亏损市净率不可能低于0.1。如果发现异常值系统会标记并触发人工复核或重新分析。逻辑一致性检查是看结论和论据是否匹配。比如论据说“营收下滑”结论却说“公司处于高速增长期”这就是逻辑矛盾。我用一个轻量的NLI模型来做这个检查发现矛盾就回退到推理阶段重新生成。合规复查是最后一道关确保输出内容不包含任何违规表述。这一步用的是规则引擎覆盖常见的风险词和敏感表述。4. 常见问题与排查技巧实录4.1 模型“幻觉”数据的识别与拦截投资Agent最危险的问题就是模型编造数据。我遇到过模型在分析中引用了一个根本不存在的财务指标还给它编了一个看起来很像真的数值。这种幻觉如果没被发现后果很严重。我的拦截策略是数据溯源校验。模型输出的每一个数值都必须能在推理链的某个步骤中找到对应的原始数据。如果找不到系统就标记为“疑似幻觉”拒绝输出。实现上我在推理链的每一步都记录了数据的哈希值模型输出时要求它附带数据来源的步骤ID后处理阶段做哈希比对。这个机制上线后幻觉数据的漏网率从最初的百分之几降到了万分之一以下。代价是模型的输出格式约束更严了但为了准确性这个代价值得。4.2 工具调用超时与降级策略数据源不稳定是常态。行情API可能因为网络问题超时财报数据可能因为源站维护而不可用。如果每次超时都让整个请求失败用户体验会很差。我的降级策略分三级重试、缓存、替代源。第一级是自动重试同一个工具调用失败后等待一秒重试最多重试三次。第二级是缓存降级如果重试都失败检查本地缓存是否有近期数据如果有就使用缓存数据并标记“数据可能滞后”。第三级是替代源如果缓存也没有切换到备用数据源。这里有个坑降级不能静默进行。用户必须知道当前使用的是降级数据否则可能基于过期信息做决策。我的做法是在输出中明确标注数据状态比如“当前行情数据来自缓存截至X时间实时数据暂时不可用”。4.3 上下文过长导致的推理质量下降百亿token的消耗意味着单次请求的上下文可能非常长。我实测发现当上下文超过一定长度后模型的推理质量会明显下降表现为忽略中间部分的信息、重复之前已经说过的内容、结论变得模糊。应对策略有三个。第一是上下文压缩把历史步骤的详细输出压缩成摘要只保留关键数据点和结论。第二是关键信息前置把最重要的数据和分析框架放在上下文的最前面利用模型对开头内容的注意力优势。第三是分段推理把长推理链拆成多个短推理链每个链的输出作为下一个链的输入而不是把所有内容堆在一个上下文里。实测下来分段推理的效果最好但实现复杂度也最高。我的折中方案是对于简单查询用单段推理对于复杂分析用分段推理段与段之间通过结构化的中间结果传递信息。4.4 常见问题速查表问题现象可能原因排查步骤解决方案输出数据与输入不符模型幻觉或数据源错误检查推理链中数据来源步骤启用数据溯源校验拦截无来源数据工具调用频繁失败数据源限流或网络问题查看工具调用日志的错误码增加重试机制配置备用数据源推理结论前后矛盾上下文过长导致信息丢失检查上下文长度和关键信息位置压缩上下文关键信息前置意图识别错误用户表达模糊或分类器偏差查看分类置信度和混淆矩阵设置置信度阈值低置信度触发反问输出格式不符合预期模型未遵循格式约束检查Prompt中的格式说明强化格式约束增加后处理校验响应时间过长串行调用过多或上下文过大分析各步骤耗时占比并行化无依赖调用压缩上下文4.5 几个反直觉的实操心得第一个心得模型不是越大越好。我试过用最大的模型做意图分类效果反而不如微调过的小模型。大模型在确定性任务上容易“想太多”输出不稳定。任务越确定模型应该越小。第二个心得Prompt的长度有最优区间。太短了模型信息不足太长了模型注意力分散。我实测下来对于投资分析类任务系统Prompt控制在800到1200字之间效果最好。超过1500字后模型开始忽略部分指令。第三个心得错误处理比正常流程更重要。我花在错误处理上的时间大概是正常流程开发时间的三倍。但正是这些错误处理逻辑让系统在真实环境中的可用性从“勉强能用”提升到了“稳定可靠”。投资Agent的竞争力不在于它多聪明而在于它多可靠。第四个心得日志要记全但查询要方便。百亿token的调用量会产生海量日志如果日志系统设计不好出了问题根本查不到。我的做法是给每个请求分配一个trace_id所有相关日志都带上这个ID查询时按ID过滤能快速还原完整链路。5. 性能优化与成本控制5.1 Token消耗的构成分析百亿token听起来吓人但拆开看消耗大头在三个地方系统Prompt的重复传输、工具返回数据的注入、推理链的累积。系统Prompt每次请求都要传一遍如果Prompt有1000字一天一万次请求就是千万token。优化方法是Prompt缓存把不变的部分缓存起来只传变化的部分。工具返回数据往往是最大的消耗源因为原始数据可能很长但模型真正需要的只是其中几个字段。优化方法是数据裁剪在工具层就把不需要的字段过滤掉只返回模型需要的最小数据集。推理链的累积消耗通过前面说的上下文压缩来控制。5.2 缓存策略的设计缓存分三层数据缓存、结果缓存、Prompt缓存。数据缓存是缓存工具返回的原始数据设置合理的TTL。行情数据TTL短财报数据TTL长。结果缓存是缓存完整的分析结论如果用户问了相同或相似的问题直接返回缓存结果。Prompt缓存是缓存系统Prompt的编码结果避免重复编码。缓存的难点在于失效策略。数据更新了缓存必须失效。我的做法是给每个缓存条目打上依赖数据的版本号数据更新时版本号递增查询时比对版本号不一致就重新计算。5.3 并发与限流数据源通常有QPS限制如果不做限流很容易被封。我的做法是令牌桶限流优先级队列。每个数据源配置一个令牌桶请求先拿令牌再执行。优先级队列保证重要请求优先获得令牌比如用户实时查询的优先级高于后台批量分析。并发度也不是越高越好。我实测发现并发度超过数据源QPS限制的80%后失败率会显著上升。所以限流阈值设置在QPS的70%左右留出余量应对突发流量。6. 后续扩展方向这套架构目前跑得比较稳但还有几个方向可以继续打磨。多模态输入是一个现在只支持文本输入未来可以支持用户上传财报PDF或图表系统自动解析。实时性提升是另一个现在的行情数据有分钟级延迟对于日内交易场景还不够快需要接入更低延迟的数据源。个性化适配也值得做不同用户的投资风格和风险偏好不同系统可以根据用户历史行为调整分析框架和输出详略程度。我个人在实际操作中的体会是投资Agent的难点从来不在模型本身而在工程细节的打磨。数据怎么清洗、工具怎么设计、错误怎么处理、成本怎么控制这些看起来不性感的工作才是决定系统能不能真正用起来的关键。模型能力是天花板工程能力是地板地板不牢天花板再高也没用。