这个ToB端金融投研Agent系统，服务的是B端业务里的普通散户用户。我们用6个月，从一开始十多个意图边界不清，逐步收敛成「4个核心智能体、2类需求范式、4条执行路径」。最后内部测试里，响应时间从10几秒压到7秒内，关键问答准确率做到约95%。但比数据更值得复盘的，是中间踩过的几个坑：意图互相打架、溯源链路不够硬、个股相关能力差点做成黑盒。
我当时是这个项目的主产品负责人，团队配置不大：2个算法、1个运营、1个开发，加上我这个产品，前后做了6个月。
产品形态是ToB端的Agent系统，最终服务的用户大多数是普通散户。这个定位其实挺拧巴：一边是B端系统，要求稳定、可控、可交付；另一边是真实使用者又是普通散户，他们的问题很发散，表达也不一定专业。
用户不会按产品经理设想的方式提问。
他可能会问：
注意，我这里会尽量用「相关标的」「个股关联呈现」「投研线索辅助」这类表达，而不是直接写“荐股”。金融类AI产品在对外表达上必须保守，这不是文字游戏，而是合规边界。
项目最初的目标，是做一条从「大事分析」到「主线复盘」再到「个股关联呈现」的投研辅助链路。说直白点，不是让AI替用户拍脑袋做决策，而是帮用户把事件、数据、逻辑和风险放到一条可解释的链路里。
听起来很顺。
但真正做起来，第一个坑就来了。
一开始我们很自然地按用户场景拆意图。
行业复盘、事件解读、个股分析、财报对比、政策影响、概念挖掘、相关标的筛选……很快就拆出了十多个意图。每一个单独看都对，但放到真实query里就开始互相抢活。
比如用户问：
“机器人大会催化下，哪些产业链方向值得关注？”
它到底属于什么？
可以是事件分析，因为有“机器人大会”；可以是概念挖掘，因为有“产业链方向”；可以是主线复盘，因为用户想知道方向是否值得关注；也可以是相关标的链路的前置问题。
每个都沾边。
如果系统同时触发多个意图，链路就乱了；如果强行只选一个，用户诉求又可能被截断。更麻烦的是，有些意图设计出来了，但底层工具根本没法稳定承接，最后只能让大模型补一段“看起来合理”的话。
在金融场景里，这就很危险。
我真正意识到不对，是自己推完整流程的时候。我们把大量query一条条摊开看，发现问题不在于“意图拆得还不够细”，恰恰相反，是拆得太细了。
不同问法背后，其实有共性。
最后我把思路反过来：不再从“用户场景”出发无限拆意图，而是先看底层工具和子智能体到底能稳定做什么，再反推能承接哪些需求。
这就是后来沉淀下来的方法：工具能力反推意图适配法。
具体做法是4步：
这一步是整个项目里很关键的转折。
我们最后没有继续新增意图，而是把十多个意图收敛成2类：
后来又补了两个子模式：
但注意，这不是新增第三类、第四类意图。它只是在原有两类范式下扩展处理方式，底层链路不变。
踩坑总结：复杂产品不是靠无限拆分变清楚的，有时候反而要靠强收敛。
如果让我选这个项目里最核心的设计亮点，我会选「大事分析智能体」。
原因很简单：它是整个链路的信息起点。
后面的主线复盘、相关标的呈现、风险提示，很多都依赖它先把事件讲清楚。如果大事分析这一层的信息不准、来源不明、标签不稳，后面做得再花也没用。
一开始我们也踩过一个坑：太相信大模型的总结能力。
你给它一段新闻、一段研报，它确实能总结得很顺。但金融投研不是作文比赛，用户真正关心的是：这句话到底从哪里来？有没有原文依据？是不是模型自己脑补的？
所以后来我们定了两条很硬的规则。
第一，prompt必须要求模型只使用知识库内容，不能脱离知识库自由生成。
第二，最后总结节点使用的原数据，必须是原文数据，而不是被大模型处理过的一手摘要。
这个区别特别关键。
如果最后总结节点拿的是模型加工过的中间结果，风险会被放大。因为你已经很难判断某一句话到底来自原文，还是来自上一轮模型的改写。链路一长，责任就不清楚了。
所以我们的数据流转最后变成这样：
大模型可以做什么？
可以做格式重组、摘要收敛、多源对比、结构化梳理。
大模型不能做什么？
不能编数据，不能生成无来源观点，不能做涨跌预测，不能引导投资建议。
说白了，大模型在这里不是“作者”，更像“编辑”。它负责把原文里的信息整理清楚，但不能自己加戏。
这里还有一个小取舍：并不是所有查询都必须绕完整摘要链路。
如果用户问题同时满足「明确唯一标的 + 精准查询维度 + 固定时间范围」，比如查某家公司某一年报里的某个字段变化，可以走更短的精准检索链路。但即使这样，结果也必须绑定原文ID，保证可追溯。
踩坑总结：金融AI里，答案说得像真的不够，必须能追到原文。
项目里最纠结的模块，是股票相关能力。
早期我们确实想过做得更“决策化”一点：通过开发工具，把事件、行情、主线、标的筛选串起来，给用户更明确的判断结果。
从用户体验看，这当然更爽。
但问题也很明显：普通散户场景下，如果系统给得太像“建议”，合规风险会迅速上升；如果事件刚出来就直接关联到标的，也很容易变成关键词匹配，缺少中间的逻辑校验。
所以后来为了快速上线，也为了守住边界，我们做了一个能力收敛版：不做直接决策建议，只做「事件关联度、主线有效性、相关标的线索」的客观呈现，并且必须附带风险提示。
这个版本听起来没那么性感，但更能上线。
这里最重要的设计，是在事件分析和相关标的呈现之间，加了一层「主线复盘智能体」。
它不负责给用户结论式建议，而是做中观校验：
最后输出一个机器可读的「主线有效性校验结论」。
我们把主线分成4档：
当主线等级是「无效」或「短期脉冲」时，系统终止相关标的输出动作。
但不终止信息服务。
它仍然要告诉用户：
这个设计看起来是“砍功能”，但其实是把产品从Demo拉回到可交付状态。
踩坑总结：金融AI产品里，克制不是保守，克制是上线能力的一部分。
经过这几轮收敛，产品最后沉淀成4个核心智能体：
对应的执行路径也收敛成4条：
这里还有一个容易被忽略的细节：标签不能拆散。
事件分析智能体拿到一个事件后，通常会产出多个标签：事件主体、行业标签、概念标签。如果到了下游被拆开用，就会出现逻辑漂移。
比如上游讲的是“机器人大会”，关联行业是“智能制造”，关联概念是“人形机器人”。如果主线复盘拿一个标签，标的关联又拿另一个标签，最后用户会看到前面讲A事件，后面跳到B概念，逻辑不连贯。
所以我们设计了「事件核心标签包」：
这类设计不一定显眼，但很实用。
说到底，复杂系统不能只靠人记规则，最好让结构本身约束错误。
这类项目如果只讲架构，很容易变成自嗨。所以我们后面也看了几个关键指标。
这里的提升，不只是因为技术侧优化了速度，更重要的是产品侧把问题收窄了。
意图少了，链路清楚了，系统就不用在十几条路里来回犹豫；数据源明确了，生成节点也不用反复补救；股票相关能力收敛后，输出边界反而更稳定。
这也是我做完这个项目后很深的一个感受：AI产品的效率提升，不一定只来自模型能力，也来自产品结构的减法。
1. Agent不是越多越强，边界越清楚越强
用户不关心你有几个Agent，用户只关心结果是不是稳定、可信、能解释。一个边界模糊的Agent，比没有Agent还麻烦。
2. 意图设计不要从场景出发，要从能力边界反推
场景是发散的，能力是有限的。先按场景铺开，最后很容易遇到意图交叉、工具缺位、兜底混乱的问题。先盘点能力，再决定哪些需求能承接，产品反而更稳。
3. 大事分析是投研Agent的地基
它不是一个普通的信息检索模块，而是整个链路的信息源头。大事分析层如果不准、不稳、不可溯源，后面的主线复盘和标的关联都会被带偏。
4. 金融AI的第一原则不是“聪明”，而是“可追溯”
一个听起来很聪明但没有来源的答案，在金融场景里其实没什么产品价值。大模型可以把内容说清楚，但不能替代原文依据。
5. 砍掉“更刺激”的能力，有时候是正确的产品决策
我们原本也想把股票相关能力做得更有决策感，但最后选择先上线收敛版。这个决定看起来不够激进，但它让产品更快可交付，也更符合合规边界。
这次做金融投研多智能体矩阵，我最大的感受是：复杂AI产品真正难的地方，不是让模型“多做一点”，而是让系统“少乱一点”。
能收敛的地方不要发散，能溯源的地方不要自由生成，能用规则兜住的地方不要交给运气。
如果要把这次复盘浓缩成一句话，我会写成：
金融AI Agent的产品价值，不是替用户做决定，而是让每个答案都有路径、有证据、有边界。
欢迎评论区交流，也欢迎同行一起聊聊多智能体产品设计里那些看起来小、实际很要命的坑。
本文由 @Keating 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。