金融AI产品的架构选择直接决定生死。从Workflow到Plan的彻底重构，不仅让复盘智能体的准确率从65%飙升至90%，更揭示了金融领域AI产品的核心法则：意图必须跟着工具走，而非用户需求。本文将深度拆解架构迭代中的关键转折与血泪教训，为同赛道产品人提供实战避坑指南。
我花了 2 个月，把一个金融复盘智能体从 workflow 推翻重做成 Plan 架构。V1 的流程硬编码，用户复合型提问直接接不住；V2 把子节点封装成工具，规划大模型根据意图动态编排，灵活性提升明显。过程中最深的体会是 —— 意图得跟着你手上有什么工具走，而不是跟着用户嘴走。最终跑出了 90% 准确率、8 秒响应。如果你也在做金融 AI 产品，希望能帮你少走点弯路。
今年 2 月，我接了一个金融复盘智能体的项目，落地为 APP 内的核心功能模块。
这个智能体的定位非常明确：给用户提供以行业概念为主体的复盘报告总结。
我们的核心用户，是看盘之余还想了解行业趋势、事件影响的投资者。他们此前的路径只有两个：要么自己翻研报、找数据做复盘，费时费力；要么跳转去别的 AI 金融软件，体验极度割裂。
而我们要做的，就是让用户在 APP 内，一键拿到结构化、可溯源的行业复盘。
团队配置：1 个产品、1 个运营、2 个开发。
项目工期：1 个月。
人少、时间紧，第一版必须快速落地。但恰恰是这份 “求稳求快” 的心态，让我踩了第一个，也是最致命的一个坑 —— 选了一个看似稳妥、但完全适配不了场景的架构。
最开始，我为项目选了Workflow 架构—— 也就是按顺序自动执行的流程化架构，人为预设固定流程和节点跳转规则。
它的特点是逻辑死板、可控性强，非常适合标准化的重复任务。但我忽略了一个核心问题：金融复盘，偏偏就不是标准化任务。
当时设计的完整执行链路是这样的：
顶层意图判断 → 实体拆分和映射 → 泛指大类图谱映射为子行业并拆分问句 → 子问句意图判断 → 槽位提取 → 不同意图对应固定工具流程 → LLM 生成最终结果。
流程图画出来逻辑闭环、节点完整，看起来万无一失。但真正上线跑起来，才发现全是问题，直接翻车。
1. 流程硬编码，复合型提问完全接不住
用户的一句话里，往往会塞进多个实体、多个问题。
而 Workflow 的固定流程，根本没法灵活响应这种复合型、多轮次的提问。每个节点的跳转路径都是提前预设好的，只要遇到意料之外的问法，系统直接卡住，完全无法处理。
2. 溯源链太长，中间环节一步错、步步错
金融领域的内容，最核心的要求就是可溯源 —— 给用户的结论，必须能对应到数据库的原始数据，不能是大模型凭空生成的。
但 V1.0 的链路里，要通过槽位词条找到摘要，再把摘要转成向量，最后才能检索原文库和研报库。三步才触达数据源，中间任何一步出错，最终结果就会完全跑偏。用户拿到一份看似完整的复盘报告，却找不到结论的来源，这在金融领域是致命的。
3. 生成结果死板，像个模板填充器
Workflow 的天生短板，就是输出结果的灵活性极差。
整条执行路径都是预设好的，LLM 能拿到什么数据、输出什么格式，全被固定流程框死了。最终出来的报告，看着结构完整，实则全是模板填充，完全没有真正的复盘分析感，用户体验极差。
翻车之后，我停下来重新思考了一个最核心的问题：智能体的意图，到底该怎么定？
之前我的设计思路，是典型的用户导向：先穷尽用户会问的所有问题，再给每一种问法设计一条对应的流程，匹配对应的意图。
但金融领域的用户提问，维度太广、问法太多，你根本不可能预判完所有情况。预设的流程再多，也永远跟不上用户的嘴。
直到某天我突然想通了：先判断我们手上有哪些可用的工具，意图是根据工具（节点 / 封装智能体）的功能，决定这个意图做还是不做；如果要做，需要调用哪些工具检索数据，来生成最终答案。
说直白点：
不是用户要什么，你就建什么意图；而是你手上有什么工具、能拿到什么数据，决定了你能做什么意图。
意图跟着工具走，不是跟着用户嘴走。
这个认知上的转变，直接推动了整个项目的架构推翻重写，也就是 V2.0 的诞生。
想通了 “意图跟着工具走” 的核心逻辑后，V1.0 的 Workflow 架构就彻底不够用了 —— 流程是硬编码的，不管工具怎么变，路径永远是那条固定路径。
所以 V2.0，我做了两个核心的、颠覆性的改动。
Plan 架构的核心逻辑，是智能体先针对用户的 query，提前想清楚完整的行动步骤、制定全局执行计划，再一步步落地执行。
它和 Workflow 最核心的区别是：
Workflow 是 “走预设的固定路”，而 Plan 是 “根据目的地，动态规划一条专属的路”。
规划大模型可以根据用户的提问，动态生成工具的使用流程，而不是死守一条提前写死的路径，灵活性直接拉满。
我把之前散落在流程里的各种检索节点，全部封装成了 3 个独立的工具：多波段内行情数据工具、指定时间内事件与研报工具、行业龙头个股数据工具。
整个执行逻辑彻底重构：
意图判断的规则不变，但推理节点会通过工具的说明书，理解每个工具能做什么；Plan 模块会根据用户的 query，生成工具的调用流程；每个工具节点根据流程，输出对应的数据；最后由生成大模型，结合所有召回的数据做收敛总结，输出最终的复盘报告。
整个流程，只需要一个 Plan 的工具说明书提示词，就能适配绝大多数用户的提问，灵活性大幅提升。尤其适配金融领域提问场景广、问法多变的特点 —— 你不需要再预设成千上万条流程，让规划大模型根据意图，自己编排执行路径就好。
Plan 架构解决了 Workflow 灵活性不足的问题，但它也有自己的天生短板：
执行流程是一开始就制定好的，没有动态纠错机制。必须保证每个节点的输出都是正确的，只要一个节点出错，整个结果的准确率都会受影响。
说白了就是 “计划定了就定了，走错了也得走完”，不会根据中间节点的结果，回头调整计划。这也是后续架构迭代，需要重点解决的问题。
整个架构重构的过程中，我砍掉了不少一开始规划的功能。
原因非常现实：当前数据不支持、开发人力跟不上、项目需要先快速落地。
比如一些需要细粒度数据的深度分析功能，数据库里没有对应的数据源，就算做出来也是空壳，给不了用户真正的价值；还有一些需要多轮交互的复杂场景，2 个开发在 1 个月的工期里，根本赶不出来。
砍功能不是妥协，是取舍。
先保证核心路径跑通、核心体验拉满，再慢慢迭代补全功能，远比一口气做个半吊子的半成品，要强得多。
架构重构完成后，我们做了 5 天的灰度测试，核心监测召回准确率和平均响应时间两大指标，结果远超预期。
V1.0 准确率低，核心原因就是流程硬编码导致的检索路径僵化，大量用户提问匹配不到正确的执行路径；V2.0 能把准确率拉到 90%，核心得益于 Plan 架构的动态编排能力，以及工具封装后大幅缩短的溯源链路。
而响应时间从 15 秒以上降到 8 秒，是因为架构精简了大量冗余流程，工具封装后减少了中间环节，一步直达数据源，速度自然大幅提升。
从 Workflow 到 Plan，从硬编码流程到动态工具编排，从 65% 准确率到 90%，这 2 个月的推翻重写，我总结了 5 个核心避坑指南，做金融 AI 产品的同行可以直接参考。
1. 金融复盘场景，Workflow 根本跑不动，灵活性是命脉标准化的重复任务，用 Workflow 完全没问题，但金融复盘天然就不是标准化场景。硬套流程化架构，复合型提问直接接不住，生成结果只会是模板填充。灵活性从来都不是锦上添花，是金融 AI 产品的命脉。
2. 意图跟着工具走，不是跟着用户嘴走先判断你手上有哪些工具、哪些数据源，再决定你能做哪些意图、承接哪些用户需求。不是用户要什么你就建什么，而是你有什么，再决定你能做什么。
3. 溯源链别太长，中间环节越少越好金融领域的数据溯源，从来都不是可选项，是必选项。V1.0 三步才触达数据源，中间一步错步步错；V2.0 把节点封装成工具，一步直达数据源，准确率和响应时间都有质的提升。链路越短，越稳。
4. Plan 架构灵活性更好，但天生没有纠错机制Plan 比 Workflow 灵活得多，但它的核心短板，是计划一旦定好，就不会动态调整。一个节点输出错误，整个链路的结果都会跑偏。后续如果要进一步升级，ReAct 架构会是更好的选择 —— 思考→行动→观察→再思考的循环闭环，能实时根据结果调整下一步动作。
5. 先砍后补，比一口气做半个成品强人少时间紧的项目里，砍功能从来都不是妥协，是最正确的决策。数据不支持的功能，做了也是空壳；开发跟不上的功能，做了也是半成品。先保证核心路径跑通，再迭代补全，才是最高效的落地方式。
从 Workflow 到 Plan，从上线翻车到数据达标，这 2 个月最深的感受就是：推翻重来不可耻，停在错误里不肯动，才可耻。
做金融 AI 产品，归根结底就三句话：
意图跟着工具走，架构跟着场景选，推翻重来不可耻。
欢迎评论区交流，有坑我们一起踩，有路我们一起探。
本文由 @Keating 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。