凌晨 2 点，小王急需一笔周转资金。 他打开 App，却要在实名认证、人脸识别、银行卡绑定、额度评估等多个页面之间来回跳转。每跳一次页面，焦虑就更深一分。这个看似普通的借款流程，正是我们要解决的核心问题。 > 用户想要的很简单：说清楚需求，事情就办完。 现在，AI 已经让这种体验开始变成现实：少跳转，系统理解意图，自动推进流程。 本文分享一套落地实践：如何把原本依赖页面推进的借款流程，重构成一段连续对话。
为什么传统页面流程不适合会话式业务处理
大多数业务系统仍然依赖页面驱动：流程靠跳转推进，状态判断分散在各个页面，业务能力也绑在页面上。 在这种模式下，连续对话很难顺利进行：用户意图是跳跃的，系统流程却还是线性的，体验天然容易被割裂。 新增业务节点时，还要修改页面和跳转逻辑，扩展成本也很高。
核心矛盾主要有三点：
- 体验割裂：用户办理过程中不断跳页，链路很长，移动端中断感明显
- 逻辑分散：每个页面都藏着一部分流程判断，节点一多，维护和排查成本一起上升
- 扩展困难：新增一个节点，往往意味着新建页面、改跳转逻辑、补多个入口，多业务接入后更容易耦合
如果继续沿用页面驱动，对话就只能停留在表面。 系统可以回答问题，却无法真正推动业务办理。
我们的解法：把对话入口做成业务执行系统
为此，我们构建了一套「对话驱动的业务执行架构」。页面和路由仍然存在，但业务推进不再依赖页面跳转，而是交给系统控制层统一承接。 页面继续负责交互，系统开始真正负责推进业务。 对用户来说，他看到的是连续的对话界面。对系统来说，背后是一条由输入、状态、决策、节点执行和服务调用组成的执行链路。 我们不是把原来的页面搬进聊天窗口，而是把散落在页面里的流程能力重新组织了一遍。
如果对“业务执行系统”还没有直觉，可以先看下面这张简化图：
这张图里最重要的变化只有一句话：页面负责承接交互，系统负责推进流程。
整体架构，拆成了哪几层
围绕“页面承接交互、系统推进流程”这一目标，我们把系统拆成四层：
| 层级 | 主要职责 |
|---|---|
| 表示层 | 负责承接用户交互与消息展示，如 AiDialogPage、ChatContainer、MessageItem 等，只关心“这一轮对话怎么呈现” |
| 业务控制层 | 负责领域管理、对话控制、流程编排与节点调度，如领域管理器、领域路由器、对话控制器、流程编排器等，决定“当前应该进入哪个领域、下一步该做什么” |
| 节点层 | 负责把实名、人脸、绑卡、额度评估等能力做成可复用节点，统一节点状态与生命周期 |
| 服务层 | 负责接口调用、请求上下文与状态管理，如 FlowService、BaseNetworkService、aiDialogApiClient，最终通过网关访问后端 |
这套分层最直接的价值，是把页面从业务复杂度里拿出来。页面层只负责展示和交互，流程复杂度集中沉淀在系统控制层。 无论新增节点、扩展领域，还是调整模型能力和后端服务，都不必反复改页面结构。
再往上抽象一点，这套业务执行系统长期围绕四件事展开：
- 接住输入：识别当前输入到底该交给节点、本地规则还是模型处理
- 保存状态：在对话过程中持续维护节点状态、领域状态和用户上下文
- 推进流程：在当前条件下决定下一步该执行哪个节点、是否切换领域
- 执行动作：把实名、绑卡、补资料、额度评估等能力，以统一节点协议接进系统
图：对话流业务执行系统分层架构图 图注：这张图重点表达四层分工和核心模块关系。表示层负责承接对话交互，业务控制层负责领域管理、流程推进与节点调度，节点层承载具体业务能力，服务层统一对接后端。
关键设计一：把“下一步去哪”留在前端
首先要明确的，不是节点怎么拆，也不是领域怎么分，而是：流程控制到底放在前端，还是放在后端。 可选路径主要有两条：
- 方案一：服务端流程编排服务端决定下一节点，前端收到结果后再渲染。优点是逻辑集中；缺点是每走一步都要等接口返回，交互节奏很难做好。
- 方案二：前端流程编排服务端只提供节点状态。前端先拿一次状态信息，之后根据配置和状态自己决定“下一步是什么”，直接渲染，不再每一步都向服务端追问。
最后我们选了第二种：服务端提供状态，前端负责流程决策与节点切换。
这个选择背后，是一组明确的边界判断：
- 服务端更适合输出稳定状态和结果
- 前端更适合处理强交互、强节奏、需要即时反馈的执行过程
两者职责一旦划清，系统就会更稳定。服务端负责给出“事实”，前端负责决定“下一步怎么走、怎么展示、何时推进”。一句话概括：服务端给状态，前端管流程。
这个选择基本决定了整套系统的骨架。流程控制留在前端后，对话、消息流、节点切换和界面节奏才能落进同一条控制链路。对应到实现上，核心职责是：
- 对话控制器负责把用户输入、消息流转和流程推进接在一起
- 流程编排器负责读取节点配置、判断节点状态，并驱动下一步
- 领域管理与路由模块负责领域注册、领域切换和共享会话上下文
这条主链路在运行时大概长这样：
这套设计的本质，不是“把页面改成了聊天”，而是把流程控制从页面里抽离出来，收进系统控制层。
一旦这件事成立，对话、消息流、节点切换和界面节奏，才有可能真正被放进同一条控制链路里。
关键设计二：不是所有输入，都该先交给模型
如果“前端编排流程”解决的是主链路控制，那么“本地决策优先，模型兜底”解决的，就是输入处理边界。
以实名节点为例。用户输入一串身份证号时，如果系统先把内容发给模型，再结合“当前节点”“当前领域”判断意图，链路会变长，准确率也会受影响，更不用说安全与合规问题。 但当前节点知道自己在处理什么，也知道这类输入长什么样，所以可以直接判断：这是一段实名认证输入，而不是一条开放式咨询。这类输入没必要先经过模型。
因此在这套架构里，用户输入会先交给当前节点做本地判断。节点能处理，就直接执行；处理不了，再走模型意图识别。
模型是兜底能力，不是默认入口。
这不是一个“优化技巧”，而是执行系统里的职责切分：
- 节点负责处理自己最了解的那一类输入
- 系统负责决定输入该落到哪一层
- 模型只处理真正需要开放理解能力的部分
这背后对应着一条清晰的架构边界：
- 节点上下文明确、规则确定的输入，优先本地处理
- 需要开放理解能力、跨节点判断的输入，再交给模型
- 模型是兜底能力，不是默认入口
进一步看，这里已经形成了一条分层执行链：节点先处理自己最熟悉的输入，系统负责决定是否升级处理，模型只处理节点无法直接消化的开放问题。
它的价值，不只是少走一次调用，更是让输入处理的责任落在最合适的那一层。
关键设计三：领域可以切，会话不能断
真实业务里，用户很少严格按单一剧本走到底。 进入页面时，系统可能先判断用户更适合授信还是发标；授信完成后，用户可能直接进入发标；发标过程中，又可能突然说“额度太低，想提额”。
这就带来一个核心问题：多领域能力既要隔离，又不能把会话切断。
如果把所有领域的节点一次性全加载进来，系统会变得混乱；但如果每个领域都完全独立，用户上下文又会被打断。
为了解决这个矛盾，系统采用了“多领域隔离 + 共享会话”的设计：
- 在逻辑层，不同业务域用独立的领域配置和节点体系做隔离
- 在交互层，统一共享同一套消息上下文，领域切换后历史消息不丢
- 在路由层，根据用户当前状态和输入意图，动态决定当前该落到哪个业务域、哪个节点
这也是领域管理和领域路由的价值所在。它们解决的不是“能不能切领域”，而是切过去之后，用户会不会觉得自己仍在同一段会话里。
从架构角度看，这一层本质上承担的是执行上下文路由：它决定的不是页面该跳去哪，而是当前这段会话该由哪个业务域继续接管。
更重要的是，这套设计共享的只是会话表面，真正按领域保存的还有各自的运行状态。 消息历史可以共用，但用户数据、节点结果和流程状态会按业务域分别保留。这样用户切回某个领域时，接上的不是一段“新对话”，而是上一次办理到一半的现场。
关键设计四：下一步节点，尽量提前准备
对话式办理里，最影响体验的往往不是首屏，而是刚完成上一步、准备进入下一步的时候。
用户刚提交完实名、绑卡或选项，如果下一节点这时才开始创建实例、拉数据、做初始化，等待感就会非常明显。 因此，系统采用了一种更前置的处理方式：当前节点一渲染完成，就提前准备下一个尚未完成的节点。
这一步不是直接把下一个节点展示出来，而是在后台先创建它的管理器，并触发初始化和可预取的数据请求。
这套机制有几个关键约束：
- 不是所有节点都强制预拉取，节点自己可以声明是否支持
- 节点可以声明哪些数据是“渲染前必须准备好”的
- 已经预拉取过的节点不会重复触发，避免无效请求
- 预拉取只负责把准备动作前置，不改变正常的流程推进顺序
表面上看，这是一次性能优化；但本质上，它是在重新分配等待发生的时机。
系统并没有减少总耗时，而是将等待从“点击之后”，前移到“用户仍在当前节点操作”的阶段完成——用户无感，系统消化。 换句话说，这里做的不是消灭等待，而是隐藏等待。 最终呈现给用户的，是一个几乎没有停顿的流畅过程。
从架构角度看，这也意味着节点的形态发生了变化： 它不再是“点到哪里再临时创建”的页面碎片，而是可以被系统提前准备、按需复用的运行时单元。
实践结果也验证了这一点：
- 节点切换时的等待明显下降
- 节点渲染时间平均降低约 500ms
- 多数场景下基本实现用户无明显感知
本质上，这不是一次简单的性能优化，而是一次对“用户感知时序”的系统性重构。
最后真正沉淀下来的，不是一套流程
如果只讲前面的运行机制，这篇文章还不够完整。更值得讲的，是这套系统最后沉淀下来了什么。
它没有停留在一次项目实现上，而是逐步长出了一组能落到代码、也能持续复用的底层能力。
真正沉淀下来的，不是几个零散功能点，而是三层彼此衔接的能力：统一接入方式、可执行节点单元、可扩展领域决策层。
图：系统能力沉淀关系图 图注：这张图重点表达系统最终留下来的三层能力关系。统一节点协议解决“怎么接入”，可执行业务单元解决“谁来执行”，可扩展的领域决策层解决“不同业务怎么定义自己的推进方式”。三者叠在一起，系统才真正具备了承接新业务形态的能力。
1. 先把节点接入做成统一协议
系统没有把节点当成“某个页面片段”，而是当成一类可插拔单元来设计。系统为节点定义了一套完整运行协议，包括初始化、渲染、过渡处理、本地决策、空闲处理、回答处理和完成回调。 它的价值在于，业务节点虽然差异很大，但系统仍然可以要求它们按同一套协议接入。 这样一来，节点就不只是一个 UI 组件，而是一个带状态、带行为、能被编排器调度的业务单元。
2. 再把节点能力沉淀为执行单元
如果节点生命周期协议解决的是“怎么统一接入”，那么更进一步的问题就是：节点接进来之后，到底承担什么。
在这套系统里，节点并不只是一个负责展示的 UI 片段。很多节点已经同时承担了输入处理、状态维护、服务调用和完成判定等职责。 它们既接受编排器调度，也能在自己的边界内完成相对完整的业务动作。 它意味着，系统沉淀下来的不只是“流程骨架”，还包括一批可以被复用、被编排、被组合的业务执行单元。
入口分流、进度推进、信息补全这类高复杂度能力，不再只能散落在页面逻辑里，而是开始以标准节点的形式被系统承接。 为了让同一类节点既能复用，又不把不同轮次的展示语义混在一起，系统还把节点内部数据拆成了不同层次：长期状态保留在节点内部，本次渲染需要的题目快照、决策结果和元信息，则通过独立通道下发。
这样一来，即使同一类节点反复出现，也能在“复用能力”和“刷新语义”之间找到平衡。
节点之所以重要，不只是因为它能被渲染出来，更因为它已经成为系统执行业务动作的基本单位。不过，这里解决的仍然是“单个节点如何完成动作”，还不是“整条流程下一步怎么走”。
3. 最后，把不同业务的推进逻辑开放出来
当节点已经被沉淀为执行单元后，系统还要继续回答另一个更高一层的问题：不同业务的流程到底该怎么推进。
有的流程适合按固定节点顺序推进，有的要结合服务端状态动态跳转，还有的更像一套基于规则的实时求值过程：题目是否展示、历史答案是否失效、当前轮是否完成、下一步进入哪个节点，都要在运行中决定。
系统如果只支持一种默认推进逻辑，很快就会退化成“公共壳子 + 业务特判”，最终把复杂度重新打回页面层。
因此，系统需要的不是让每个业务都重写一套编排器，而是在统一运行时之上抽出一层可插拔的领域决策层。
运行时继续负责节点渲染、消息流转和状态保存。 领域决策层则负责基于当前上下文产出编排结果，把变化频繁的业务规则从主干中隔离出来。 以财务信息收集场景中的小龙虾为例，它并不是固定题目串行，而是依据服务端下发的页面契约和用户当前答案动态生成题目流。
每完成一道题，系统都要重新计算依赖显隐、失效答案清理、题目集完成态，以及下一步进入引导节点、题目节点还是结果节点。
为了稳定承接这类流程，系统补齐了四项能力：
- 领域启动准备机制：允许每个领域先准备自己的页面配置和初始数据，而不是套用统一初始化方式
- 领域级决策机制：允许每个领域定义自己的下一步判断逻辑，而不是都走固定顺序
- 页面规则引擎：把“依赖显隐、单题推进、答案清理、完成态判断”抽成可复用能力，供需要的领域按需使用
- 按渲染语义重建实例：当同一类节点承担的题目语义发生变化时，允许按领域规则重建实例，避免状态串扰
这组能力真正沉淀下来的，不是某一条题目流，而是一种更稳定的架构分层：系统控制层负责统一运行时，领域决策层负责解释业务规则，页面规则引擎负责执行局部约束。
这样一来，复杂业务不必再侵入编排主干。 当规则变化时，系统也不需要重写运行时，只要调整对应领域的决策实现，就能继续承接新题型、新依赖关系和新的流程变体。
系统真正被沉淀下来的，不是某条借款题目流，而是一种可以持续承接新业务的能力边界。
落地之后，效果怎么样
从当前落地情况看，这套架构已经在实际业务中上线，并接入了授信、用户挽留，以及数据收集动态决策类流程场景做验证。
从工程侧看，它已经证明了几件事：
- 对话驱动流程在真实借款场景里是能跑通的
- 节点化、系统化的抽象可以支撑多领域接入
- 前端编排、多领域路由、本地决策和预拉取这些设计，不是停留在方案里，而是进入了真实链路
从业务效果看，这套交互形态和系统能力仍在持续灰度验证中，但当前数据已经给出了一些正向信号：
- 注册成交率相对提升约 0.6%
- 授信后发标率相对提升约 1.1%
未来还能往哪里走
虽然当前系统已经进入真实链路，但仍有持续演进空间。 后续可以重点关注几个方向：
- 从“组件承载采集”继续走向“完整对话式采集” 当前系统已经能把组件、节点和流程接进对话链路。后续可以再往前走一步，让更多用户信息采集直接在聊天过程中完成，而不再强依赖组件形态承载。系统未来不仅要支持“在对话里展示组件”，还要支持“在对话里直接完成信息收集和状态更新”。
- 让模型能力从文本理解继续扩展到多模态交互 未来系统承接的输入不应只限于文本。图片上传、图片识别、证件理解、材料校验这类能力一旦进入主链路，系统就需要同时承接文本、图片以及更多模态的输入。关键不是增加一种输入类型，而是把多模态输入统一纳入节点执行和流程推进。
- 把对话驱动能力继续扩展到更完整的业务流程 当前能力已经在授信、发标以及数据收集动态决策驱动场景里完成了验证。后续更值得做的，是继续往还款、提额等环节延伸。真正的目标，是把授信、发标、还款、提额这些关键链路，逐步收进同一套对话驱动体系。
写在最后
现阶段 AI 还不足以独立执行所有业务逻辑。 流程推进、状态管理、节点切换、领域路由等核心能力，必须由系统掌控，否则不确定性、成本和可控性都会成为问题。
这次改造的重点，是先搭建稳定的业务承载能力，让系统主导流程节奏 在此基础上，AI 才能作为辅助能力融入，真正服务于主流程，而不是独立存在。 先把系统骨架搭稳，用户感知的流畅体验才有可能实现。
