这个ToB端金融投研Agent系统，服务的是B端业务里的普通散户用户。我们用6个月，从一开始十多个意图边界不清，逐步收敛成「4个核心智能体、2类需求范式、4条执行路径」。最后内部测试里，响应时间从10几秒压到7秒内，关键问答准确率做到约95%。但比数据更值得复盘的，是中间踩过的几个坑：意图互相打架、溯源链路不够硬、个股相关能力差点做成黑盒。

我当时是这个项目的主产品负责人，团队配置不大：2个算法、1个运营、1个开发，加上我这个产品，前后做了6个月。

产品形态是ToB端的Agent系统，最终服务的用户大多数是普通散户。这个定位其实挺拧巴：一边是B端系统，要求稳定、可控、可交付；另一边是真实使用者又是普通散户，他们的问题很发散，表达也不一定专业。

用户不会按产品经理设想的方式提问。

他可能会问：

• “某个政策出来了，哪些板块可能有关？”
• “这个概念最近是不是一条主线？”
• “某个公司财报怎么看？”
• “A和B两家公司谁更受这个事件影响？”
• “这个方向下有哪些相关标的可以看看？”

注意，我这里会尽量用「相关标的」「个股关联呈现」「投研线索辅助」这类表达，而不是直接写“荐股”。金融类AI产品在对外表达上必须保守，这不是文字游戏，而是合规边界。

项目最初的目标，是做一条从「大事分析」到「主线复盘」再到「个股关联呈现」的投研辅助链路。说直白点，不是让AI替用户拍脑袋做决策，而是帮用户把事件、数据、逻辑和风险放到一条可解释的链路里。

听起来很顺。

但真正做起来，第一个坑就来了。

第一个坑：十多个意图看起来都合理，放在一起全打架

一开始我们很自然地按用户场景拆意图。

行业复盘、事件解读、个股分析、财报对比、政策影响、概念挖掘、相关标的筛选……很快就拆出了十多个意图。每一个单独看都对，但放到真实query里就开始互相抢活。

比如用户问：

“机器人大会催化下，哪些产业链方向值得关注？”

它到底属于什么？

可以是事件分析，因为有“机器人大会”；可以是概念挖掘，因为有“产业链方向”；可以是主线复盘，因为用户想知道方向是否值得关注；也可以是相关标的链路的前置问题。

每个都沾边。

如果系统同时触发多个意图，链路就乱了；如果强行只选一个，用户诉求又可能被截断。更麻烦的是，有些意图设计出来了，但底层工具根本没法稳定承接，最后只能让大模型补一段“看起来合理”的话。

在金融场景里，这就很危险。

我真正意识到不对，是自己推完整流程的时候。我们把大量query一条条摊开看，发现问题不在于“意图拆得还不够细”，恰恰相反，是拆得太细了。

不同问法背后，其实有共性。

最后我把思路反过来：不再从“用户场景”出发无限拆意图，而是先看底层工具和子智能体到底能稳定做什么，再反推能承接哪些需求。

这就是后来沉淀下来的方法：工具能力反推意图适配法。

具体做法是4步：

1. 先盘点底层能力边界：现有工具、子智能体分别能做什么，输入输出是什么，稳定性到哪一步。
2. 再判断需求能不能承接：没有工具支撑的需求，不上线正式意图，只做友好兜底，并沉淀到迭代池。
3. 把可承接需求收敛成2类系统范式：泛化范围类、精准标的/事件类。
4. 基于范式规划调用链路，而不是按表面场景乱跳。

这一步是整个项目里很关键的转折。

我们最后没有继续新增意图，而是把十多个意图收敛成2类：

后来又补了两个子模式：

1. 多标的并行处理：比如A和B公司财报对比。
2. 多范围聚合处理：比如消费和新能源板块走势对比。

但注意，这不是新增第三类、第四类意图。它只是在原有两类范式下扩展处理方式，底层链路不变。

踩坑总结：复杂产品不是靠无限拆分变清楚的，有时候反而要靠强收敛。

第二个坑：大事分析是核心，但不能让大模型“自由发挥”

如果让我选这个项目里最核心的设计亮点，我会选「大事分析智能体」。

原因很简单：它是整个链路的信息起点。

后面的主线复盘、相关标的呈现、风险提示，很多都依赖它先把事件讲清楚。如果大事分析这一层的信息不准、来源不明、标签不稳，后面做得再花也没用。

一开始我们也踩过一个坑：太相信大模型的总结能力。

你给它一段新闻、一段研报，它确实能总结得很顺。但金融投研不是作文比赛，用户真正关心的是：这句话到底从哪里来？有没有原文依据？是不是模型自己脑补的？

所以后来我们定了两条很硬的规则。

第一，prompt必须要求模型只使用知识库内容，不能脱离知识库自由生成。

第二，最后总结节点使用的原数据，必须是原文数据，而不是被大模型处理过的一手摘要。

这个区别特别关键。

如果最后总结节点拿的是模型加工过的中间结果，风险会被放大。因为你已经很难判断某一句话到底来自原文，还是来自上一轮模型的改写。链路一长，责任就不清楚了。

所以我们的数据流转最后变成这样：

1. 从用户query里提取槽位关键词。
2. 先在摘要库里做关键词检索和精排，拿到候选摘要。
3. 通过摘要ID和词条相似度，锁定对应原文块。
4. 再用向量检索去原文库、研报库里拿更完整的原生内容。
5. 最后总结节点只能基于原文级数据做结构化表达。

大模型可以做什么？

可以做格式重组、摘要收敛、多源对比、结构化梳理。

大模型不能做什么？

不能编数据，不能生成无来源观点，不能做涨跌预测，不能引导投资建议。

说白了，大模型在这里不是“作者”，更像“编辑”。它负责把原文里的信息整理清楚，但不能自己加戏。

这里还有一个小取舍：并不是所有查询都必须绕完整摘要链路。

如果用户问题同时满足「明确唯一标的 + 精准查询维度 + 固定时间范围」，比如查某家公司某一年报里的某个字段变化，可以走更短的精准检索链路。但即使这样，结果也必须绑定原文ID，保证可追溯。

踩坑总结：金融AI里，答案说得像真的不够，必须能追到原文。

第三个坑：原本想做“更有决策感”，后来主动收敛了

项目里最纠结的模块，是股票相关能力。

早期我们确实想过做得更“决策化”一点：通过开发工具，把事件、行情、主线、标的筛选串起来，给用户更明确的判断结果。

从用户体验看，这当然更爽。

但问题也很明显：普通散户场景下，如果系统给得太像“建议”，合规风险会迅速上升；如果事件刚出来就直接关联到标的，也很容易变成关键词匹配，缺少中间的逻辑校验。

所以后来为了快速上线，也为了守住边界，我们做了一个能力收敛版：不做直接决策建议，只做「事件关联度、主线有效性、相关标的线索」的客观呈现，并且必须附带风险提示。

这个版本听起来没那么性感，但更能上线。

这里最重要的设计，是在事件分析和相关标的呈现之间，加了一层「主线复盘智能体」。

它不负责给用户结论式建议，而是做中观校验：

• 这个事件对应的行业/概念有没有成交额放量？
• 主力资金是否连续流入？
• 有没有明确领涨标的？
• 上涨标的占比是否足够？
• 梯队是否完整？

最后输出一个机器可读的「主线有效性校验结论」。

我们把主线分成4档：

当主线等级是「无效」或「短期脉冲」时，系统终止相关标的输出动作。

但不终止信息服务。

它仍然要告诉用户：

• 为什么这条主线无效；
• 对应量化数据是什么；
• 当前行情怎么理解；
• 风险点在哪里。

这个设计看起来是“砍功能”，但其实是把产品从Demo拉回到可交付状态。

踩坑总结：金融AI产品里，克制不是保守，克制是上线能力的一部分。

最后沉淀出的架构：4个Agent，4条路径

经过这几轮收敛，产品最后沉淀成4个核心智能体：

对应的执行路径也收敛成4条：

1. 单事件分析路径：只调用大事分析智能体。
2. 单主线复盘路径：只调用主线复盘智能体。
3. 事件+复盘组合路径：大事分析 → 主线复盘。
4. 全链路投研线索路径：大事分析 → 主线复盘 → 标的关联智能体。

这里还有一个容易被忽略的细节：标签不能拆散。

事件分析智能体拿到一个事件后，通常会产出多个标签：事件主体、行业标签、概念标签。如果到了下游被拆开用，就会出现逻辑漂移。

比如上游讲的是“机器人大会”，关联行业是“智能制造”，关联概念是“人形机器人”。如果主线复盘拿一个标签，标的关联又拿另一个标签，最后用户会看到前面讲A事件，后面跳到B概念，逻辑不连贯。

所以我们设计了「事件核心标签包」：

• 固定结构：1个主标签 + 最多3个副标签。
• 主标签按事件核心关联度、用户Query提及顺序、市场热度排序确定。
• 主标签和副标签全程强绑定流转，不拆分。
• 下游智能体必须以主标签为核心执行主体，副标签只能做补充。
• 如果出现多个平级主标签，规划智能体先向用户确认，不直接并行执行。

这类设计不一定显眼，但很实用。

说到底，复杂系统不能只靠人记规则，最好让结构本身约束错误。

数据验证

这类项目如果只讲架构，很容易变成自嗨。所以我们后面也看了几个关键指标。

这里的提升，不只是因为技术侧优化了速度，更重要的是产品侧把问题收窄了。

意图少了，链路清楚了，系统就不用在十几条路里来回犹豫；数据源明确了，生成节点也不用反复补救；股票相关能力收敛后，输出边界反而更稳定。

这也是我做完这个项目后很深的一个感受：AI产品的效率提升，不一定只来自模型能力，也来自产品结构的减法。

经验沉淀

1. Agent不是越多越强，边界越清楚越强

用户不关心你有几个Agent，用户只关心结果是不是稳定、可信、能解释。一个边界模糊的Agent，比没有Agent还麻烦。

2. 意图设计不要从场景出发，要从能力边界反推

场景是发散的，能力是有限的。先按场景铺开，最后很容易遇到意图交叉、工具缺位、兜底混乱的问题。先盘点能力，再决定哪些需求能承接，产品反而更稳。

3. 大事分析是投研Agent的地基

它不是一个普通的信息检索模块，而是整个链路的信息源头。大事分析层如果不准、不稳、不可溯源，后面的主线复盘和标的关联都会被带偏。

4. 金融AI的第一原则不是“聪明”，而是“可追溯”

一个听起来很聪明但没有来源的答案，在金融场景里其实没什么产品价值。大模型可以把内容说清楚，但不能替代原文依据。

5. 砍掉“更刺激”的能力，有时候是正确的产品决策

我们原本也想把股票相关能力做得更有决策感，但最后选择先上线收敛版。这个决定看起来不够激进，但它让产品更快可交付，也更符合合规边界。

结尾

这次做金融投研多智能体矩阵，我最大的感受是：复杂AI产品真正难的地方，不是让模型“多做一点”，而是让系统“少乱一点”。

能收敛的地方不要发散，能溯源的地方不要自由生成，能用规则兜住的地方不要交给运气。

如果要把这次复盘浓缩成一句话，我会写成：

金融AI Agent的产品价值，不是替用户做决定，而是让每个答案都有路径、有证据、有边界。

欢迎评论区交流，也欢迎同行一起聊聊多智能体产品设计里那些看起来小、实际很要命的坑。