企业官网建设流程全解析

先说清楚一件事：这不是标题党，也不是把公开代码拼起来讲PPT。我花了四个多月时间，从数据采集到决策模块，把一个能每天自动处理海量文本、最终输出具体投资动作的agent系统完整地“手搓”了出来。这里说的“百亿token”，不是训练大模型的规模，而是这个agent在真实运行中要消化的语料总量——新闻、公告、研报、财报电话会记录、宏观数据、产业链动态，全部算进去，一天要过的token数级在十亿上下，一个月累计过百亿很正常。你听到这个数字先别觉得夸张，真正跑起来之后你会发现，百亿token其实是很容易达到的量级，难点从来不是“量”，而是“怎么让系统在这么大的输入里保持稳定、可解释、还能赚钱”。

我写这篇文章的目的，是把这套系统从0到1的完整构建过程拆开讲。包括为什么非要自建而不是买现成的，数据层怎么设计才能扛住百亿级token，agent的“大脑”到底怎么组织记忆和推理，以及我在实盘与回测中踩过的那些最痛、最不容易想到的坑。适合正在做或打算做投资类AI应用的人读，也适合对“大模型agent如何落地在实际业务里”感兴趣的工程师参考。

1. 先聊清楚：手搓投资Agent到底在解决什么问题

1.1 现成方案为什么不够用

市面上已经有不少投资分析类的AI产品。有接入大模型API做智能问答的，有做新闻舆情监控的，也有做量化因子挖掘的。但如果你真的把它们拿去跑一段时间的实际投资流程，会发现一个共同的问题：它们解决的是“单点问题”，不是“完整闭环”。

什么叫单点？比如你问它“某公司最近的毛利率趋势怎么样”，它能给你一段看起来很像样的回答，但你需要自己去验证数据对不对、口径是否统一、有没有隐含的关联信息没提到。再比如舆情监控，它能告诉你“今天这家公司负面新闻多了”，但它不会告诉你这个负面到底对哪条产品线有冲击，不会去翻这家公司的历史财报验证影响幅度，更不会把这个信号跟它当前的估值水平做交叉验证。

我需要的不是“会说话的数据库”，而是一个能自己完成“收集信息→建立背景知识→发现异常→形成观点→落成交易动作→事后复盘”全流程的agent。这种完整闭环，现成产品基本给不了。

1.2 “百亿token”这个量级是怎么算出来的

很多人听到百亿token，第一反应是“这得多少钱”。我先算一笔账，你就知道这个数字其实非常真实。

假设系统每天覆盖：

• 全市场数千只股票的公告和新闻，平均每只5-10条，每条折算500-1000 token
• 头部公司的深度研报，一天几十到上百份，每份1-3万token
• 美股、港股、A股的重要财报电话会记录，财报季一个月可能几百份，每份1.5万到4万token不等
• 宏观数据与政策新闻，几十到上百条，每条500-2000 token
• 行业深度报告与产业链调研纪要，一天几十份，每份1-5万token
• 历史新闻与公告的每日新增知识库索引、向量化存储增量

粗略估算，一天新增原始语料就在8-12亿token。如果算上每隔几小时就增量补充的历史信息再处理，一个月的处理量跨越百亿token没有任何难度。

所以“百亿token”不需要是噱头。它真正带来的技术问题是：你的系统能不能在保持单次推理质量的前提下，把这么大的信息量合理压缩、关联、丢弃和调用。

1.3 我给自己定的设计目标

在建第一个原型之前，我先明确了几条硬约束：

1. 全流程自动化：从抓取数据到输出交易信号，中间不需要人工干预。
2. 可解释性优先：每一个交易决策都能追溯到具体的信息依据，而不是一个说不清理由的“模型黑盒”输出。
3. 成本可控：百亿token如果全部走最贵的商业大模型推理，一个月成本会高到离谱。必须在架构上做大量“便宜模型做粗活、贵模型做细活”的调度。
4. 延迟容忍但不无限延迟：不是高频交易系统，单轮决策延迟可以接受分钟级，但不能超过半小时。

这四条约束，最终决定了后面几乎所有架构上的关键设计。

2. 数据层的“冷热分离”：百亿Token的摄取与压缩

2.1 采集端架构：不是爬虫，是“订阅式数据管道”

很多人一上来就想到用爬虫爬新闻。但爬虫抓取有两个致命问题：一是规模上去之后封IP和反爬会让你痛不欲生；二是爬到的数据质量和时效性完全没有保证，公告、财报这种关键信息你根本不敢用爬的，出错一次就是致命的。

所以我的采集端设计原则是：能用正规数据源订阅解决的，绝不用爬虫。公告和行情数据走交易所和第三方数据服务商的API推送，新闻和研报通过聚合型数据接口获取全文内容，只有那些特别小众的行业网站、自媒体内容才用爬虫兜底。

整体架构分为三层：

• 接入层：统一封装各种数据源的API，输出标准化的数据模型，比如新闻包含标题、正文、发布时间、来源、相关标的等。
• 队列层：全部进入消息队列做削峰填谷，避免数据源突发推送导致下游被压垮。
• 存储层：按数据类型分流，文件型内容进对象存储，结构化元数据进数据库，需要全文检索的进搜索引擎，需要向量检索的进向量数据库。

2.2 Token量级下的存储选型

在百亿token的持久化场景下，“全都存全字段全文”是不现实的。我做了一个关键的取舍：把语料分成“热数据”和“冷数据”两套体系。

• 热数据指最近30天内需要反复被agent读取、关联、推理的内容。这部分用成本较高的高速存储，数据进来之后先做清洗，再去重，然后打上时间戳、实体标签、情感倾向、行业分类等元数据，最后进入向量库和搜索引擎。
• 冷数据指超过30天的历史资料。这部分压缩之后存到低成本的对象存储，只保留高频特征和摘要，以及全文的压缩文件。只有在做深度回测或长周期研究时，agent才会去冷数据里捞取原始原文。

下表是我在实际设计中各存储组件承担的职责：

2.3 数据清洗里那些容易“暴雷”的细节

数据清洗看着不起眼，其实是最容易让整个系统失效的地方。

第一个暴雷点是重复内容。同一篇新闻可能被几十个网站转载，同一份公告上交所发一遍、公司官网发一遍、数据商又推一遍。我统计过，原始数据源的重复率能达到35%-50%。如果不做去重，agent的上下文窗口里会反复出现同样的信息，导致它对某些事件的重要度评估严重失真。

第二个暴雷点是公告和新闻报道的时间差。公告原文发出的时间永远准确，但新闻往往是滞后几个小时甚至一天的转载。如果按agent自己“看到”的时间来标记数据，会导致时序错乱，而时序在投资决策中是极其敏感的信息。

第三个暴雷点是同名实体的歧义。比如“XX科技”可能同时存在于A股、港股，甚至在不同行业有不同业务主体。不做实体消歧，agent检索的时候会把无关的信息全混在一起。

这三个坑，每一个都花了我大量时间去修。现在回想起来，如果要给做同类系统的人一个首要建议，我会说：花50%的时间在数据层都是值得的，因为这里的一个小错误，会在后面被放大器一样放大到决策结果里。

2.4 Token压缩策略：不是所有内容都值得进大模型

在百亿token的规模下，如果每个原始文本都要完整送进大模型分析，成本和时间都不可接受。我采用了一套“分级压缩”策略：

• 第一级：规则过滤。先按明确的规则把明显无关的内容丢弃。比如金融标的明显不涉及的行业新闻、重复率高到可疑的转载、无实质性内容的口水文。这一级能削减40%-50%的原始流量。
• 第二级：小模型预筛。用速度很快、成本很低的轻量模型给每条内容做粗分类和摘要，提取出“事件-标的-影响方向”的三元组。比如“某公司发布2024年财报，净利润同比下滑30%”，这一步会抽取成“公司X；财报事件；负面；下滑30%”。这一步能再压缩掉大量冗余。
• 第三级：结构化存档。只有真正命中关注列表、且信息增量判断为“高”的内容，才进入最终的推理管道，由主力大模型做深度分析。

这套分级压缩做完之后，进入主推理模型的实际token量大概只有原始流的10%-15%。既保住了信息覆盖度，又把昂贵的推理成本压到了可接受范围。

3. 记忆与知识组织：Agent怎么在百亿Token里“记住”事情

3.1 为什么单一向量库扛不住投资场景

一开始我用了一个很朴素的思路：把所有文档切片、向量化，存进向量数据库，需要的时候做相似度检索，拿到上下文喂给大模型。这个方案跑了一个月，效果非常差。

问题出在投资场景的信息结构跟普通问答完全不同。比如你问agent“某公司这轮下跌的主要原因是什么”，正确答案往往不是“找一段跟这次下跌最相似的文本”，而是要穿越多个信息源去拼凑因果链：三个月前的一份行业政策文件→中间两个月里产业链上下游的利润挤压→一周前公司发布的一份低于预期的财报→财报之后分析师的一致下调。这条因果链跨越了时间、跨越了信息类型、跨越了不同主体。向量相似度检索只能找回“看起来相似”的碎片，根本无法还原这种跨文档的推理关系。

3.2 图结构知识库：把信息变成“关系”

所以我引入了图数据库来构建实体关系网络。在这个图里：

• 节点是实体，包括公司、行业、产品、宏观指标、人物、事件。
• 边是关系，包括“属于行业”“是供应商”“发布公告”“发生事件”“影响”等。

每条新闻进来之后，不光是向量化存起来，更重要的是抽取其中的实体和关系，把新的信息挂到已有的知识图谱上。这样当agent分析某家公司时，它可以通过图结构直接查到比如“这家公司有哪些上游供应商，这些供应商最近有哪些负面新闻，是否会影响原材料供应”。

图结构还天然支持多跳推理。agent可以沿着关系边逐步展开：公司→所属行业→行业政策→政策影响的其他公司→这些公司的市场表现。这是纯粹向量检索完全做不到的。

3.3 混合记忆机制：短期事件记忆与长期基本面记忆

为了让agent既能看到短期的事件驱动，又能保持长期的基本面视角，我设计了双层记忆机制：

• 短期事件记忆：保留最近14-30天的新闻、公告、市场异动数据，这部分记忆“声音很大”，会持续影响agent对当前局面的判断。一旦超过窗口期，如果事件后续没有持续发酵，这部分记忆会被静默降权。
• 长期基本面记忆：包括公司核心财务指标、主营业务结构、行业竞争格局、历史估值区间等信息。这部分记忆更新频率低，但每次更新权重很高，比如财报季看到新的年报数据，就会更新一次基本面快照。

agent在一次决策中，会分别从短期记忆和长期记忆里检索信息，再放入推理模块做综合判断。这个分离设计的价值在于，它避免了“今天一条中性新闻把agent对整个公司的长期判断都带偏了”这种问题。

3.4 长期会话的上下文膨胀问题

agent在跑一段时间之后，它的“记忆”会越来越多。如果不做管理，会出现两个问题：

一是上下文膨胀。把所有历史记录都塞进提示词，首轮推理的token消耗就会滚雪球，到后面根本无法承受。

二是重要信息被噪声淹没。投资决策中真正关键的往往就是几个核心事件节点，如果历史记忆里充满了大量冗余事件，模型很难自发抓出最重要的那几个。

我的解决方案是做“记忆压缩与重要性重排”。每隔固定周期，agent会对自己积累的记忆做一个“复盘”：把已经发生的决策、当时的信息依据、后续的实际结果进行回溯。基于结果，它会给每条记忆做一个“有效性打分”。高分的记忆会被保留完整细节，低分的会被压缩成一行摘要，甚至直接丢弃。这套机制有点像是给人脑做“睡眠巩固”——不是把所有经历都记住，而是把重要的强化，不重要的忘掉。

4. 决策引擎：从“读得懂信息”到“敢给出投资动作”

4.1 ReAct模式还不够，我用的是“三层推理”

很多人做agent都会用ReAct模式（推理-行动循环）。但我很快发现，纯ReAct在投资场景有两个问题：一是它缺乏对“长期观点”的稳定表达，每一步推理都是片段式的；二是它对工具的使用缺少优先级，容易在细枝末节的信息上浪费大量的调用次数。

我最后落地的是“三层推理”结构：

第一层：全局扫描。agent先基于当前市场全景、仓位情况、关注列表，产出一个大方向的判断。比如“当前宏观流动性偏紧，成长板块整体承压，重点关注防御类资产”。

第二层：标的研究。在全局扫描通过初筛之后的候选标的上，agent做深度研究。它会主动调用数据层去检索这个标的的短期事件记忆和长期基本面记忆，然后形成一份结构化的“标的研究卡”，内容包括：核心业务、最近关键变化、主要风险、估值区间判断。

第三层：决策落定。结合前两层的输出，agent对每一个候选标的给出具体的操作建议：买入、卖出、持有、加仓、减仓，同时给出建议仓位比例、止损条件和复盘时间点。

每一层推理的结果都会保存下来，作为可解释性的核心依据。这样无论是事后复盘还是人工审查，都能直接看到“为什么在那一刻得出那个判断”。

4.2 工具调用的“预算机制”

Agent在推理过程中需要调用很多外部工具：查行情、查新闻、查财务数据、查研报、计算估值指标等。如果不对工具调用做约束，一次完整决策可能会触发几十次甚至上百次API调用，延迟和成本都会失控。

我设计了一套“工具调用预算”机制，核心思路是：

• 每次决策先设定最大工具调用次数上限，比如30次。
• 工具按照“信息价值密度”排序：比如“查询最新财报核心指标”的优先级远高于“搜索一篇可能相关的长研报”。
• 每完成一次工具调用，agent会评估这次调用对当前决策的信息增益。如果连续几次调用增益都很低，agent会被强制收敛到现有信息上做决策，而不是无限深挖。

这套机制的效果非常明显。平均单次决策的工具调用数从最初的50+次降到了20次以内，决策时间从半小时级别降到几分钟级别，同时决策质量没有明显下降。本质上是把“信息过载”的代价转变成了一种可管理的资源约束。

4.3 风险控制：Agent的“刹车系统”

纯粹追求收益率的agent是做不长久的。我在决策引擎上接了一层独立的风控模块，不参与观点生成，只负责“踩刹车”。

风控模块监控几个维度的硬约束：

• 单标的仓位上限：任何单一标的的仓位不能超过总资金的一定比例，防止集中度风险。
• 波动率异常预警：当标的的短期波动率超过历史均值的数倍时，风控模块会强制要求降低该标的的仓位。
• 流动性约束：对日均成交额偏小的标的，自动降低可交易规模上限，防止“想卖卖不掉”。
• 回撤控制：当组合回撤超过阈值，风控模块会触发全局减仓逻辑，无论agent当前有多看好的观点。

这套风控层和agent的主推理是隔离的。即使agent在推理中因为某个突发信息变得异常兴奋，风控层也能在动作执行前拦住它。实际跑下来，这套隔离设计避免了至少三笔可能带来大幅回撤的错误交易。

5. 成本优化：百亿Token处理背后的真金白银

5.1 “贵模型写结论，便宜模型做粗活”的分层调度

在百亿token的量级下，如果在所有环节都用最贵的那档商业大模型，成本会立刻变成天文数字。我举一个具体数字对比：轻量模型处理同样长度文本的成本可能只是主力模型的几十分之一，而投资场景里真正需要复杂推理的环节，可能只占整个数据流的百分之十出头。

所以我把模型调用分成了三条路径：

• 路径一：轻量模型。负责绝大部分预处理，包括分拣、粗分类、实体抽取、初步摘要。这类任务对单次输出质量要求不高，量大，用轻量模型最合适。
• 路径二：中等模型。负责标的研究卡生成、事件因果链分析等需要一定推理深度、但不需要特别强创造力的任务。
• 路径三：旗舰模型。只留给最高价值的推理环节，包括最终的决策落定、复杂多标的比较、异常市场情况判断。这类调用次数最少，但单次质量最重要。

成本上我统计过，三条路径的综合花费大概是“所有环节都用旗舰模型”方案的8%-12%。换句话说，如果全用贵方案一个月要花十万元，分层调度之后一万元不到就能覆盖。

5.2 缓存与批处理的降本空间

除了模型分层，还有两个容易被忽略的降本手段：缓存和批处理。

缓存：同一家公司在两小时内可能连续被多个信息源推送相似内容，如果不加缓存，同一份事实会被重复向量化、重复送进模型。我在数据层做了一层“语义指纹缓存”：任何文本进入管道前先计算指纹，如果指纹已在缓存中且未过期，直接复用之前的结果。这一步把重复处理的文本量又削减了10%左右。

批处理：很多任务其实不需要实时处理。比如历史新闻的增量向量化、冷数据的后台摘要生成，这些完全可以在夜间批量跑。批处理的好处不只是省钱，还能避开白天的API高峰时段，延迟更稳定，出错的概率也更低。

5.3 一个反向思考：省钱不一定是好事

说到这里我得泼一盆冷水：成本优化不能无限度。我试过把更多环节压到轻量模型上，结果很快发现，某些需要细腻推理的任务在轻量模型上做出来的质量下降是肉眼可见的——比如损失了关键的因果归纳能力，或者丢失数字之间的逻辑关系，而这些对投资判断非常致命。

后来我总结出一个原则：成本优化的边界，是决策质量不下降。如果省下来的钱导致错误的概率增加，哪怕只增加一个百分点，在投资里所带来的潜在损失都远超省下的成本。实时性、成本、质量这三者一定要找到一个平衡点，而不是单维度追求最便宜。

6. Agent的“性格”：构建投资价值观与行为准则

6.1 没有价值观的agent会变成“信息变色龙”

在开放域大模型上直接做投资推理，会出现一个很有意思的现象：模型会被输入的最新信息“牵着鼻子走”。今天新闻全是利好，它就乐观；明天市场一片悲观，它马上也变得悲观。本质上，这是因为通用模型没有内化的投资框架，它们只是在做“接下来最像应该接的话”。

投资市场恰恰最忌讳这种“没有主心骨”的判断方式。所以我花了很多精力做一件事：给agent构建一套稳定的“投资价值观”。

具体来说，我在它的系统提示词里写入了明确的投资风格和偏好约束，包括但不限于：

• 偏向价值与成长并重，不追逐纯市场情绪驱动。
• 对任何信息都先做“信息来源可信度”评估，小道消息权重极低。
• 更重视基本面变化，而非单纯价格波动。
• 拒绝高杠杆和任何可能带来极端尾部风险的策略。

这些约束不是一句空话，它们会直接影响agent在决策时的信息权重分配。比如当一条未经证实的利空消息出现时，agent会先给这条消息标一个很低的置信度，再决定要不要基于它做动作，而不是因为“情绪上觉得要出事”就立刻止损。

6.2 极端行情下的行为压力测试

光有纸面的价值观还不够，你得验证agent在极端行情下能不能管住自己。

我做了一个离线压力测试：把历史上几次极端行情的新闻流按原时序重新输入给agent，观察它在没有“后见之明”的前提下会做出什么反应。比如某次行业突发利空、相关标的一夜之间大幅下跌的场景，agent是否能够在恐慌信息洪流中保持冷静，不出现一次性清仓、追涨杀跌这类非理性行为。

测试结果还是发现了一些问题。最典型的是：在持续负面信息轰炸下，agent会反复触发“减仓”动作，即使当时估值已经进入长期低位区间。这说明它的“长期价值观”在实际推理中会被短期的情绪流覆盖。为此，我增加了一道“冷却机制”：如果agent在短时间内连续多次对同一标的下达减仓指令，系统会强制暂停新指令，并强制从长期基本面记忆里重新拉取该标的的核心数据做二次确认。这个机制上线后，极端行情下误操作的频率大幅下降。

6.3 让Agent学会“空仓等待”

散户最常犯的错误之一，是总觉得必须时刻持有仓位才算在“做投资”。我发现让模型学会“空仓等待”比让它学会“找标的”更难。

刚开始agent总是倾向于给出“买入”建议，因为“买入”看起来像是在做事情。但投资里最稀缺的能力之一是判断什么时候不动。现在我在决策引擎里加了一个“机会成本评估”：当agent打算买入一个标的时，它必须说明，这个配置机会相对于持有现金或持有其他候选标的的优势在哪里。如果它说不出来，默认输出“持有现金”或“维持现状”。

这个改动很反直觉，但效果很好。组合的表现波动反而变小了，因为系统性避免了在不该出手的时候频繁折腾。

7. 实盘与回测：数据不说谎，但也别全信

7.1 我在回测里发现“自欺欺人”的三种方式

做投资agent，回测是避不开的环节。但我必须提醒你：回测的自我欺骗能力，比你想的要大得多。

我踩过最典型的三个坑：

第一种是前视偏差。回测时用了未来才知道的信息。比如你拿财报数据做信号，但财报公布日和数据生效日之间存在时滞，如果直接拿最终财报数据填进去，回测结果会显著虚高。我的解决方案是：所有回测数据必须严格按照“当时实际可获得信息”的时间戳标记，宁可信息少一点，不能引入未来信息。

第二种是幸存者偏差。回测股票池只用了现在还在上市的标的，退市的、暴跌的公司在历史区间被排除了，结果回测中的“平均收益”被大幅高估。这个问题的解决方式非常繁琐：要把历史股票池完整还原，包括已经退市的标的。

第三种是过度优化。为了让回测曲线好看，不断调参数。最后你会得到一个在历史数据上几乎完美、但一上实盘就崩掉的策略。我对自己的约束是：参数只允许调两轮，两轮之后无论曲线多难看都接受，直接进模拟盘验证。

7.2 模拟盘到小资金实盘的“梯度跨越”

回测通过之后，我没有直接上大资金。我走了一个三阶段：

• 第一阶段：纯模拟盘，跑了两周，主要验证系统的稳定性、决策延迟是否符合预期。
• 第二阶段：极小资金实盘，金额小到亏损也不会心疼。这个阶段检验的是“真实市场环境中执行层面会不会出问题”，结果还真发现了一些回测永远不可能发现的坑，比如数据源在盘中偶尔延迟几分钟，导致信号触发时间点比预期晚。
• 第三阶段：逐步加仓。每增加一定比例的资金，都要重新观察系统在一段时间内的行为是否依然稳定。

这套梯度走下来，最大的好处是：你不会在第一天就用真金白银为一个架构缺陷买单。投资agent的架构缺陷往往是系统性的，一旦触发，亏损不是一笔两笔，而是后续所有决策都被污染。

7.3 一个让我印象深刻的“意外胜利”

整个项目过程中有一个案例让我印象特别深刻。

有一次，agent在某个标的的基本面没有重大变化的情况下，突然给出了“小幅减仓”的建议。我看了它的推理记录，发现依据是一条不起眼的供应链新闻——说该公司的主要客户正在寻求替代供应商。这条新闻在当时的新闻流里热度很低，连很多专业财经媒体都没有重点报道。

我当时并没有特别在意，但一周之后，该公司发布了一份低于预期的订单指引，股价大跌。agent在小幅减仓之后没有完全改变对这家公司的长期看法，只是降低了敞口，因此在大跌中的损失非常有限。

这个案例让我意识到：百亿token数据的真正价值，恰恰藏在那些“看起来不那么重要”的角落里。人做不到每天阅读几千条信息并保持同样的注意力水平，但一个设计良好的agent可以。它不是比你聪明，它是比你在“无聊信息”上更勤快。

8. 踩坑实录：这些弯路你可能也会走

8.1 “模型幻觉”在数据密集场景下会加倍显现

大模型幻觉问题，在投资场景带来的后果比其他场景严重的多。如果你的客服机器人偶尔答错一个问题，用户投诉一下也就过去了。如果投资agent在提取财报数字时幻觉了一个关键财务指标，那基于这个数据做出来的所有后续推理都是错的。

我遇到过一次印象最深的问题：agent在总结一份财报公告时，把“净利润同比下滑20%”错误地转述成了“净利润同比增长20%”。方向完全相反，但如果只靠人工去查这条摘要，很难一眼发现。好在我多数关键结论都会在“决策链”里附带引用原始文本的ID，出问题后可以快速定位到是哪一步抽取错了。

这个事件的教训促使我在系统里加了一道“关键数字校验层”：凡是涉及财务数据的提取结果，必须回到原文中做二次确认，任何一个数字如果没有找到原文出处，就会被标红并要求重新提取。

8.2 向量检索的“相似性陷阱”

向量检索在投资场景还有一个隐蔽的问题：相似的内容不一定相关，相关的内容不一定相似。

比如“某公司发布回购计划”和“另一家公司发布回购计划”，这两段文本在语义上高度相似，但在投资决策中涉及的两家公司完全不同，如果按相似度召回，很容易把它们混为一谈。反过来，真正影响某公司股价的因果关系，往往在文本上一点都不相似。

我花了很长时间才意识到，向量检索只能作为信息召回的起点，不能作为终点。真正可靠的做法是：向量召回一批候选，然后用实体关系图谱做过滤和排序，最终才把最相关的信息放上推理台面。

8.3 长期运行的“概念漂移”

市场环境不是静止的。比如“新能源”这个词在几年前的含义、市场热度、估值体系，和现在完全不同。agent如果长期用同一套语义理解机制去处理信息，会慢慢跟不上市场语言的变化。

这个问题没有一次性解决方案。我的做法是定期对agent的“行业语义映射表”做一次人工审查和更新。每个季度更新一次行业分类、更新一次新兴概念的词典、校正一次实体关系。这个过程很像是给agent做一次“知识体检”。

如果你打算长时间运行一个投资agent，一定要在系统设计之初就把这种“定期校准机制”规划进去，否则跑几个月后你会发现，agent对市场新词、新概念的反应明显变慢了。

9. 复盘机制：让Agent从自己的错误里学习

9.1 决策复盘的三层结构

投资agent如果没有复盘机制，它只会永远重复同样的错误。我的复盘机制分为三层：

• 单笔交易复盘：每一笔已平仓的交易，都会把agent当时的推理链、当时的市场背景、后续的真实走势放在一起做对比。是看对了做对了，还是看对了做错了，还是看错了但运气好。
• 配置组合复盘：每个固定周期看整个组合的收益来源，拆解为选股贡献、择时贡献、风控贡献等不同部分，搞清楚哪些收益是能力，哪些只是运气。
• 系统参数复盘：对运行过程中修改过的参数做历史回测验证，确认每次参数调整到底是变好了还是变差了。

9.2 挫折信息如何反馈进推理

复盘的挑战不是“记录”，而是“把经验反馈进未来的推理”。

我的解决方案是给agent增加一个“经验记忆库”。这不是普通的记忆库，而是专门存储“带标签的错误案例”。比如“在某类流动性环境里追高半导体板块，事后证明大概率会承受大幅回撤”——这种经验会作为一条带有明确触发条件的规则，在agent未来遇到类似场景时被强制调取出来。

这个经验库不是静态的。agent每个周期都会根据最新的实际结果对经验库中的规则做“置信度更新”。连续有效的经验会保留，连续失效的经验会被降权甚至删除，这样保证经验库不会积累一批已经过时的错误认知。

9.3 承认“模型也有状态不好的时候”

复盘中我慢慢意识到，大模型作为决策核心有一个非常独特的挑战：它和人类一样，会有“状态波动”。同样是类似的市场环境和信息输入，今天的推理质量和昨天的推理质量可能不完全一样。

我现在的做法是：给每次决策加一个“质量自评分数”。在推理输出时，agent会同时评估自己对当前决策的确定性。如果连续几次决策的自评分数都偏低，系统会触发一个“降级模式”，自动缩小单笔仓位上限，直到agent的推理质量恢复。

这套做法的核心思想就是：在你不确定的时候，降低风险敞口，是最好的选择。它不追求每次都赚最多，但保证了在大模型偶发的“状态不佳”时，系统不至于犯下致命的错误。

10. 对于想做同类项目的人，我的几点实在建议

整个项目走下来，如果有人问我“我要不要也做一个投资agent”，我会先反问他三个问题：

第一个问题：你能不能接受长时间看不到效果？这类系统不像做一个工具类应用，上线一周就能看到明确反馈。投资agent需要在各种市场环境下持续跑几轮才能验证策略的有效性。短期内它的表现甚至可能不如随机选股，这需要非常强的心理承受力。

第二个问题：你有没有稳定的高质量数据源？数据源决定了一个投资agent的天花板。模型能力只是用来“理解”的工具，而理解的对象是数据。如果数据质量不行，再强的模型也白搭。我的建议是：在动手写第一行代码之前，先确认你的数据供应链是可靠的。

第三个问题：你愿不愿意做那些“看起来不酷”的工作？数据清洗、实体消歧、回测防作弊、日志审计——这些工作做了没人夸你，不做一定会出事。投资agent跟普通AI应用最大的区别是：它犯错是要花钱的。所以那些让你觉得“枯燥”的工程保障，恰恰是它最重要的生命力。

我还会特别想说的一点是，技术从来不是这类项目最难的环节。更难的，是你对投资本身的理解深度。一个对投资没有思考的人，就算把百亿token的数据管道做得再好，也只会得到一个更快产生错误决策的机器。先把投资逻辑想清楚，再谈技术实现。

如果你也在这条路上探索，希望这篇长文能让你少踩几个我已经踩过的坑。说到底，投资agent是一场无限游戏，它比拼的不是某个单次的惊艳表现，而是长期、稳定、可持续地在复杂信息环境里做出相对不坏的决定。与所有正在“手搓”自己系统的朋友们共勉。