4个人的小团队，30天推翻重来3次。从一开始建了十几个意图互相打架的Workflow，到最后响应时间从28秒干到12秒、准确率从60%拉到85%的ReAct——中间每一步都是被真实问题逼着往前走的。这篇文章没有理论框架的大而全梳理，只有一个AI PM在金融场景里实打实踩过的坑。如果你也在做Agent产品，希望能帮你少走点弯路。

一、先交代背景：我们在做什么

简单说，我在某头部券商的APP里做一个AI功能模块——帮C端散户看懂热点事件、找到相关个股。

你想想散户平时怎么获取投研信息？要么自己硬啃研报（大部分人看不懂），要么用第三方AI炒股软件（质量参差不齐）。我们的优势是券商自己有事件库、研报库、行情数据这些”弹药”，但一直没有好的方式递到散户手里。所以这个项目的目标就是：用多智能体架构，把专业数据翻译成散户看得懂的人话。

团队很小：1个PM（我）、2个开发、1个运营。总共给了30天，中间架构推翻重来了3次。

30天3个版本，不是我们想卷，是每一版上线都被现实打脸，不得不改。

二、V1.0 Workflow：我是怎么把意图做崩的

2.1 一开始的想法：有什么场景就建什么意图

V1.0用的是Workflow（工作流）架构，说白了就是提前画好流程图，用户进来后按流程一步步走。可控性很强，但也很死板。

设计意图分类的时候，我直接套用了以前做对话机器人的老思路：

有什么场景 → 建什么意图 → 每个意图配一套规则和回复模板

于是一口气建了十几个意图：“个股分析”、“行业分析”、“事件解读”、“国内大事”……看上去分工明确、挺有条理的对吧？

2.2 翻车现场：意图互相打架

结果很快就翻车了

用户问了一句：”降息对券商有什么影响？”

系统直接懵了：

– “券商”命中了行业分析

– “降息”命中了事件解读

两个意图同时激活，系统不知道该走哪条路

这还不是偶发。金融领域的问题天生就是跨维度的——一句话同时涉及行业、事件、个股、政策，你用离散的意图根本穷举不完。

意图建得越多，打架的case就越多。整个系统越做越乱。

2.3 转折点：别管用户想干什么，先看系统需要什么

这个问题困了我整整一周。

转折发生在某天晚上，我把收集到的几十个真实用户问句全部摊在桌上：

• “消费板块最近走势怎么样”
• “茅台最新财报解读”
• “今年光伏行业政策汇总”
• “算力板块后市逻辑”
• “降息对券商有什么影响”
• “近期市场整体复盘”

然后我逼自己换了一个视角：不看用户在问什么内容，只看系统需要调什么数据来回答这个问题。

一瞬间规律就出来了——不管问句怎么变，系统的处理方式其实就两种：

说白了，意图分类的本质不是“用户想干嘛”，而是“系统要用哪套数据管线”。

想明白这一点之后，十几个意图直接收敛成了2个，整个路由逻辑瞬间清晰：先拆分复合问句，再判断每个子问句走哪条管线，最后合并输出。

踩坑总结：做Agent的意图设计，别从用户场景出发去穷举。先问自己”我有几套不同的数据管线”——每条管线就是一个意图，够了。这个思路能帮你少走至少一周弯路。

三、V1→V2：回复没有”人味”，架构必须换

3.1 上线就发现的问题：像机器人在念稿

V1跑起来之后，我在内测阶段就感觉不对劲——回复结构太死板了。

Workflow架构下，每个意图都绑了一套固定的生成模板。结果就是不管用户问”光伏政策”还是”券商业绩”，回复的段落标题、小节结构都长一个样，连标题都不会根据内容变化。

说直白点，看起来就像一个模板在批量填空。

对散户来说，这种回答完全没有”人味”——不像一个分析师在跟你聊市场，更像一个系统在吐报表。而我希望产品的感觉是”你身边懂股票的朋友在给你讲”，而不是”机器在给你读研报”。

3.2 加入选股：让用户从”看新闻”走到”找股票”

同一时期，业务方提了新需求：用户看完事件解读后，想直接看到相关个股。

业务方一开始给的需求清单特别长——基本面数据、技术指标、资金流向、机构持仓、分析师评级、风险提示……恨不得把整个终端搬进来。

但我们就4个人、30天，不可能做全量。所以我做了一个关键决策：先用最简的筛选逻辑跑通“从事件到个股”这条链路，验证这个方向用户到底买不买账。具体怎么筛的就不展开了，大致是多维度初筛加风险过滤，取关联度最高的几只输出。

跑通了再加数据维度，远比一上来堆功能高效得多。

一句话经验：POC阶段，PM最重要的判断不是”做什么”，而是”先不做什么”。

3.3 架构升级：从Workflow到Plan

为了解决回复死板的问题，同时把新的选股能力加进来，我们把架构换成了Plan（规划式）。

简单说就是：系统先想好”这个问题我需要分几步解决、调哪几个子智能体”，然后按计划一步步执行。

好处很明显：回复结构不再是固定模板，而是根据实际调了哪些数据动态生成

• 新增选股智能体只要注册成一个新工具就行，不用改整体流程
• 用户体验变成了“看新闻 → 查影响 → 找标的”的一条龙服务

四、V2→V3：Plan不够用了，但ReAct也不是银弹

4.1 Plan的硬伤：计划定了就不会变

Plan解决了结构死板的问题，但新的坑马上来了：它的计划是一开始就定死的，中间某一步拿不到数据，系统不会自动调整。

举个例子，用户问了一个比较冷门的事件，事件库里数据不全。系统按计划走到选股环节，发现没数据——但它不会回头重新想，只能硬着头皮输出一个残缺的结果。

这对用户来说就是”系统答了，但答了个寂寞”。

4.2 换ReAct：让系统学会”走不通就换条路”

V3我们升级到了ReAct架构，它的核心机制是”思考→行动→看结果→再思考”的循环：

3个子智能体被封装成工具集

规划智能体根据用户问题思考要调哪个工具

关键来了：如果某个工具没返回有效数据，系统会自动回到规划环节重新想办法

最后由生成智能体把所有数据汇总输出

说白了，系统终于有了”此路不通换条路”的能力。

4.3 代价来了：生成时间彻底失控

但ReAct的灵活性是有代价的。

每多”思考”一轮就多一次大模型调用，响应时间完全不可控。极端情况下系统在那转圈思考，用户等半天也看不到东西。

散户的耐心大家都懂——超过十几秒基本就关页面了。

解决方案说出来不优雅但很有效：直接跟算法协商，强行限制最大循环轮次。 不让它无限”思考”下去，到了上限就必须给出结果。

本质上就是牺牲一部分理论最优，换一个用户能接受的等待时间。做C端产品，很多时候就是这种不优雅但必要的妥协。

五、灰度2周，数据说话

改完之后不是拍脑袋觉得”应该好了”，我们老老实实跑了2周灰度测试，盯了三个核心指标：

28秒→12秒，这个差距对C端来说是质变。28秒，用户已经关页面了；12秒，还愿意等一下。

60%→85%，从”五个回答错两个”变成”绝大部分时候靠谱”。金融产品的用户信任就是这么一点点攒出来的。

六、踩完坑之后沉淀下来的5条经验

6.1 意图别穷举，看你有几条数据管线就分几个意图

传统做法是”有什么场景建什么意图”，在Agent时代这条路走不通。

正确思路：先看你系统底层有几套不同的检索和生成管线，每条管线对应一个意图就够了。

我的血泪教训：建了十几个意图花了一周才收敛到2个。这个弯路你完全可以避免。

6.2 架构选型：别追”最先进”，让问题推着你走

三种架构各有各的适用场景：

我们每次换架构都是被具体问题逼的，不是为了”技术升级”而升级。先用最简单的方案跑起来，真出问题了再换，比一上来就追求ReAct靠谱得多。

6.3 跟业务方博弈：POC阶段先验证链路，别堆功能

业务方永远会给你一个”全都要”的清单，这很正常。PM的价值就在于判断“现在最重要的是什么”。

选股功能可以列出几十个数据维度，但POC阶段就一个目标：验证”从事件到个股”这条链路用户到底买不买账。链路跑通了再加维度，远比一上来面面俱到高效。

6.4 C端产品，给”智能”设个上限

ReAct理论上思考越多效果越好，但你的用户不会等你。

金融C端的潜规则：超过12秒，散户就关页面了。 强行限制循环轮次，不优雅但必要。

6.5 金融AI产品，溯源是生命线

用户不只想看结论，还想知道结论从哪来的。我们系统里所有给到生成环节的数据都是数据库的原始内容，每一条输出都能追溯到原文出处。

这不是技术洁癖，是合规硬要求，也是让用户敢用你产品的基础。

写在最后

30天，3次推翻重来，从10个意图互相打架到响应12秒、准确率85%。

回头看，最大的收获不是某个具体方案，而是一个做Agent产品的心态：别想着一步到位搞个完美架构，先用最土的方案跑起来，等真实问题打脸了再改。每次迭代只解决一个核心问题，不贪多。

如果这30天的经验只能浓缩成一句话，我会说：

架构是被问题逼出来的，不是在白板上画出来的。

希望对正在做或准备做Agent产品的朋友有点帮助。有问题欢迎评论区交流。