企业官网建设流程全解析

我大概有半年时间一直在折腾一个偏工程向的落地项目：用 Slickflow.NET 做流程编排，把 AI 大模型接进智能客服系统，实现真正可上生产的 多轮问答系统。先说结论：这套方案跑通之后，稳定性和可控性比“直接怼 Prompt”高出好几个量级，而且每次会话卡在哪、为什么回这句话、业务数据有没有收齐，全部都查得到。这篇就把整个思路、设计、代码和踩坑实录完整写出来，想给有同样需求的 .NET 团队一个可复用的参考。

我为什么会用工作流引擎去管大模型的对话？因为大模型本身是“无状态”的。你给它一段上下文，它给你一段回复，聊完就结束了。可智能客服不一样，用户说“我要退上周买的鞋”，这句话里面有意图（售后）、有实体（商品=鞋，时间=上周），但没有订单号，你得接着问，问了还要能记住；用户说“订单号是 12345”，你再拿着去查单、生成回复。整个链路里，“当前收到什么、还缺什么、下一步该干什么”就是状态。状态不交给可控的中间件去管，而是全塞在模型上下文里，对话一长一定出乱子。

Slickflow.NET 是 .NET 生态里比较成熟的开源工作流引擎，它天然自带流程定义、节点流转、运行实例、驳回跳转这些能力。把会话状态挂到流程实例上，把每一步对话动作定义成节点，大模型只负责两件事：理解用户意图、生成自然语言回复。其余的状态推进、字段收集、业务动作，全由工作流来控制。这套架构适合有 .NET 技术背景、正在做智能客服或类对话系统、并且不想只停留在 demo 层面的团队参考。

1. 为什么智能客服要用“工作流引擎 + 大模型”

1.1 纯 Prompt 方案解决不了的状态问题

哪个做客服系统的开发没试过这种玩法：把所有历史消息一股脑塞进 Prompt，调一次大模型接口，返回一段回答，完事。简单，真的简单，三五天就能出个聊天页面。

可一旦把它当真去跑业务，问题马上就来了。第一个是上下文漂移：跟用户聊了十二轮，模型开始“忘记”用户第一轮就说过自己是会员，又把刚确认过的收货地址推翻重来，或者问了三遍“您要退的是哪件商品”。这不是模型笨，是上下文窗口里塞了太多内容，早期关键信息被淹没了。第二个是流程不可控：用户本来在查订单，突然问一句“你们发什么快递”，模型很可能就顺着聊过去了，查单流程被晾在一边，聊了五六轮才想起来单还没查。第三个是状态不可观测：系统回复错了，你想查一下当时走到哪一步了，翻日志发现只有一堆聊天记录，根本看不到“订单号已收集”“业务数据已入库”这种结构化信息。

核心症结就是那句老话：大模型没有状态，而客服对话本质上是一个状态机。让一个没有状态的东西去管需要状态的事情，短期能靠 Prompt 技巧糊弄，长期一定崩。

1.2 工作流引擎恰好补上“状态”这块短板

工作流引擎最擅长什么？就是管状态。它里面天然就有“流程实例”“当前节点”“流转条件”“历史记录”这套模型。平时我们拿它做审批流、工单流，本质上就是在维护一个状态机，每一步走到哪、满足什么条件能走下一步，被很严格地定义和执行着。

把客服对话套进这个模型，你会发现它意外地契合。用户每一次发言，就是一次“事件”，这个事件触发流程节点判断：当前节点是“收集订单号”，用户发来“订单号是 12345”，满足条件，节点往前推；当前节点是“售后处理”，用户还在问物流，那就先走“物流查询”分支，转完再回到售后主流程。整个过程中，会话停在哪、收集了什么参数、调用过什么业务接口，全部落在工作流的运行实例上，可查询、可回溯、可重跑。

我甚至觉得，客服对话比审批流更适合用工作流。审批流的节点动作是“人去点按钮”，客服对话的节点动作是“大模型生成一句话 + 可能调一个接口”，两者都是同一套状态推进机制。Slickflow.NET 刚好就是 .NET 体系里能现成拿来干这件事的轮子，省掉自己写状态机的大量工作。

我整理过一个对比，能直观看出差别：

1.3 整体架构：一条能落地的对话链路

整个系统我按五层来拆。最外层是 API 网关或一个简单的 WebAPI 入口，负责接收用户消息、返回回复；第二层是会话服务层，核心职责是把每个用户的 SessionId 对应到一个 Slickflow 流程实例；第三层是意图识别层，接收用户文本，输出结构化结果（意图 + 关键信息）；第四层是流程引擎层，也就是 Slickflow.NET，负责节点流转、节点动作执行；第五层是大模型接入层，负责生成自然语言回复和处理语义理解。

一次完整的对话链路是这样的：用户发来“我要查订单” -> 会话服务拿到 SessionId，找到这个会话的流程实例和当前节点 -> 调用大模型做意图识别，得到 intent=query_order -> 流程引擎判断当前节点处于“意图分诊”，满足条件后流转到“收集订单号”节点 -> 该节点判断是否已拿到订单号，没拿到就返回追问 -> 会话服务把“当前节点 + 已收集信息 + 历史消息”组装成 Prompt，让大模型生成一句追问话术返回给用户。用户再说“订单号是 8888”，流程节点收到，订单号字段补齐，流转到“查询订单”节点，调用订单接口，拿到结果后再让大模型组织成自然语言回复。

关键在于：大模型不是流程的总控，而是“意图识别器 + 话术生成器”。它说出来的话决定了对话质量，但对话推进的方向始终由工作流把握。这个架构里的每一层都能单独替换，比如意图识别可以用大模型，也可以先用规则匹配兜底；回复生成可以用云端大模型，也可以用本地 Ollama 部署的模型。灵活，还抗风险。

2. 系统设计：状态、意图与节点怎么编排

2.1 会话 Session 与流程实例的绑定关系

这是整套系统的地基，我得先讲透。每个用户会话进来，必须有且只有一个对应的流程实例。我设计了一个ConversationContext对象，作为会话和流程之间的“翻译官”：

public class ConversationContext { public string SessionId { get; set; } public string ProcessInstanceId { get; set; } public string CurrentActivityId { get; set; } public string CurrentActivityName { get; set; } public Dictionary<string, object> BusinessData { get; set; } = new(); public DateTime StartTime { get; set; } public DateTime LastActiveTime { get; set; } }

SessionId 是用户侧带过来的标识，ProcessInstanceId 是 Slickflow 里的流程运行实例 ID，CurrentActivityId 是当前处于哪个节点，BusinessData 则是这个会话过程中收集到的全部业务字段，比如订单号、商品名、用户手机号等。

第一次对话时，会话服务做两件事：创建一个新的流程实例，并把它启动到开始节点；然后把SessionContext落库，要么放 Redis，要么放数据库表，看团队的基建。之后每一轮对话来的时候，先根据 SessionId 把这个上下文捞出来，拿到 ProcessInstanceId 和 CurrentActivityId，再继续推进流程。

这里有个很重要的取舍：为什么不直接把这些状态都塞在内存里、用静态字典保存？因为客服系统天生要水平扩容，一个请求可能落在 A 节点，下一个请求落在 B 节点，内存态共享不了。而且一旦服务重启，所有在聊的会话全部丢失。老老实实把状态放到 Redis 或数据库里，用 SessionId 做 Key，既保命又方便以后做会话超时清理。

流程实例本身自然是入库的，Slickflow 默认就有流程实例表、节点实例表、运行日志表。会话服务这里的落库主要是把“SessionId 与 ProcessInstanceId 的映射”和“当前节点位置”缓存起来，减少每次走到流程数据库里的查询开销。

2.2 意图识别结果如何映射到流程节点

意图识别是“用户一句话到底想干什么”的判断，它能直接决定流程往哪个节点走。我在系统里维护了一套有限的意图集合，不多，但要覆盖业务场景：

意图识别我用的是两步方案。第一路由一个本地小模型或者一套关键词规则快速判断，命中就返回，不命中再调用大模型做细粒度分类。这样做的好处是常见问题响应快、成本低，也能在大模型服务抖动的时候兜住核心场景。大模型分类的做法也不复杂，把一个意图列表和几条示例放进去做 few-shot：

{ "instruction": "你是客服意图分类器，从以下意图中选择最匹配的一个，只输出 intent 和关键信息字段。", "intents": ["query_order", "after_sale", "logistics_query", "human_service", "small_talk"], "examples": [ {"input": "我想退掉昨天买的裤子", "output": {"intent": "after_sale", "slots": {"product": "裤子", "time": "昨天"}}}, {"input": "订单快递到哪了", "output": {"intent": "logistics_query", "slots": {}}} ], "user_input": "你们那个 8888 订单现在什么状态" }

识别出的结果要保留两个东西：一个是 intent 类型，用于节点分流；一个是 slots 字段，比如订单号、商品名称、期望动作等，这些字段会被塞进 BusinessData 作为流程节点的输入。

有一点必须注意：意图识别结果不可直接信任，尤其是模型给的结果。所以流程设计里，意图只是一个“路由参考”，真正能否跳转还是要看当前节点的流转条件。比如系统正在“售后处理”流程中，用户突然说一句“好的谢谢”，意图识别可能返回 small_talk，但节点条件发现业务数据还没收集完，就不会跳走，而是继续追问缺少的字段。这样即使意图识别偶尔不准，整个对话也不会彻底跑偏。

2.3 多轮问答的节点设计与流转条件

节点设计是整个系统的灵魂。我第一版是按“查订单”这一条链路设计的，节点拆成五类，后来所有业务场景都沿用这个套路：

• 开始节点：生成欢迎语，并把流程推进到“意图分诊”
• 分诊节点：根据意图识别结果分流到不同业务子流程
• 信息收集节点：检查 BusinessData 缺哪些字段，缺哪个就问哪个，直到收齐
• 业务处理节点：调用后端接口，把结果写入 BusinessData
• 回复生成节点：把业务结果 + 会话上下文交给大模型生成最终话术
• 结束 / 转人工节点：明确结束会话或转人工

节点之间的流转条件，我在 Slickflow 的流程定义里用类似这样的 XML 来表达（结构以你使用的版本为准，思路一致）：

<Process Name="CustomerService" Version="1.0"> <StartNode GUID="start"> <Transitions> <Transition To="router" /> </Transitions> </StartNode> <TaskNode GUID="router" Name="意图分诊"> <Transitions> <Transition To="collect_order" Condition="intent == 'query_order'" /> <Transition To="collect_after_sale" Condition="intent == 'after_sale'" /> <Transition To="human_service" Condition="intent == 'human_service'" /> <Transition To="small_talk_reply" Condition="intent == 'small_talk'" /> </Transitions> </TaskNode> <TaskNode GUID="collect_order" Name="收集订单号"> <Transitions> <Transition To="query_order_detail" Condition="businessData.orderNo != null" /> <Transition To="collect_order" Condition="businessData.orderNo == null" /> </Transitions> </TaskNode> <TaskNode GUID="query_order_detail" Name="查询订单详情"> <Transitions> <Transition To="reply_generate" /> </Transitions> </TaskNode> <TaskNode GUID="reply_generate" Name="大模型回复生成" /> <EndNode GUID="end" /> </Process>

流转条件里有个细节值得提醒：收集订单号节点，条件判断是“orderNo 是否存在”，但如果用户一直不给订单号怎么办？不能死循环让用户一直输。我在节点里加了一个字段重试计数，businessData.collectRetryCount，超过两次就跳转到转人工节点，让真人客服接手。这个兜底逻辑一定要有，因为现实中的用户不是测试脚本，真的会答非所问。

节点设计还有一个原则：每个节点尽量只干一件事。信息收集节点只负责收集字段，业务处理节点只负责调接口，回复生成节点只负责组织语言。别把“查订单 + 退款 + 道歉”全塞到一个节点里，否则流程编排的意义就没了一半，反而退回硬编码尴尬局面。

3. 核心代码实现与部署实操

3.1 工程初始化与依赖引入

我用的是 .NET 8，创建一个 ASP.NET Core Web API 项目，这是最常规的智能客服服务端骨架。Slickflow 相关的包直接 NuGet 引入，包名记得以你实际用的版本为准，官方迭代过好几版命名。

<Project Sdk="Microsoft.NET.Sdk.Web"> <PropertyGroup> <TargetFramework>net8.0</TargetFramework> <Nullable>enable</Nullable> </PropertyGroup> <ItemGroup> <PackageReference Include="Slickflow" Version="x.x.x" /> <PackageReference Include="Microsoft.Extensions.Http" Version="8.0.0" /> <PackageReference Include="Newtonsoft.Json" Version="13.0.3" /> </ItemGroup> </Project>

大模型客户端我没用特定的 SDK，直接封装 HttpClient 调 OpenAI 兼容协议。这个决定很实际：不管接的是云端还是本地 Ollama 部署的模型，只要兼容/v1/chat/completions，一套代码全搞定，后面换模型供应商零成本。

在appsettings.json里把模型相关的参数抽出来：

{ "LlmOptions": { "BaseUrl": "http://localhost:11434/v1", "ApiKey": "ollama", "Model": "qwen2.5:7b", "Temperature": 0.2, "MaxTokens": 512 }, "ConnectionStrings": { "SlickflowDb": "Server=.;Database=CustomerServiceWF;User Id=sa;Password=xxx;" } }

Temperature 设成 0.2 是我实测后的选择。客服场景要的是稳定和听话，不是天马行空。Temperature 高了回答变得太“活泼”，同一个问题每次说法都不一样，用户会觉得客服前后不一致。低温度下，话术更可控，业务数字也不会瞎编。

3.2 用 XML 定义一套客服流程

流程定义写好后，通常可以借助 Slickflow 的流程设计器可视化维护，也可以直接在代码里加载 XML 文件。我建议版本化保存，每次改动都留个记录，方便以后回滚。

我项目里的流程定义 XML 大致按第 2 章那个结构来写。定义好之后，代码里加载并启动流程的步骤是这样：

public class WorkflowProcessService { private readonly IWorkflowService _workflowService; public WorkflowProcessService(IWorkflowService workflowService) { _workflowService = workflowService; } public string StartCustomerServiceProcess(string sessionId) { var runner = new WfAppRunner { AppName = "CustomerService", AppInstanceId = sessionId, ProcessGUID = "customer-service-process-guid", Version = "1.0", UserID = sessionId, UserName = "CUSTOMER" }; var result = _workflowService.CreateRunner(runner) .Start(); if (result.Status != WfExecutedStatus.Success) { throw new Exception($"流程启动失败: {result.Message}"); } return result.ProcessInstanceID; } }

AppInstanceId是关键，我直接塞了会话的 SessionId，这样流程实例和会话在业务维度天然绑定。每次用户继续发言，我通过 SessionId 反查ProcessInstanceID，再从流程引擎里拿出当前节点，判断当前该怎么走。

启动成功后，流程会停在“开始节点”之后的下一个节点。此时我拿到当前节点的信息，把欢迎语和第一步引导话术拼进 Prompt，交给大模型生成。

3.3 大模型接入与上下文组装

大模型接入层我写了一个LlmClient，方法不多，核心就一个ChatAsync。历史消息用ChatMessage列表维护，这是对接 OpenAI 兼容协议的标准结构：

public class LlmClient { private readonly HttpClient _httpClient; private readonly IOptions<LlmOptions> _options; public LlmClient(HttpClient httpClient, IOptions<LlmOptions> options) { _httpClient = httpClient; _options = options; } public async Task<string> ChatAsync(IEnumerable<ChatMessage> messages, int maxTokens = 512) { var payload = new { model = _options.Value.Model, messages = messages.Select(m => new { role = m.Role, content = m.Content }), temperature = _options.Value.Temperature, max_tokens = maxTokens }; var response = await _httpClient.PostAsJsonAsync("/v1/chat/completions", payload); response.EnsureSuccessStatusCode(); var json = await response.Content.ReadFromJsonAsync<ChatCompletionResponse>(); return json.choices[0].message.content; } }

上下文的组装是我最有心得的地方。不是把聊天记录全塞进去就完事，而是要把当前工作流状态“翻译”成系统提示词，让模型明确知道自己现在处于哪个环节、已经掌握了哪些信息。我给了一个组装函数，结构大概是：系统指令 + 流程状态摘要 + 最近几轮对话 + 用户当前输入。系统指令里我故意把所有已确认的业务字段写得很死，这样模型不太容易“忘记”用户刚说过的关键信息，因为这不依赖模型的短期记忆，而是来自流程里持久化的事实。

这里特别说明一下：多轮问答最容易翻车的地方就是“历史上下文 + 当前节点事实”打架。比如大模型看到历史里用户说过“我要退鞋”，但当前节点已经流转到“收集订单号”，如果系统提示里不强制说明“当前需要收集订单号，请围绕这个追问”，模型就会顺着历史扯回去。我在系统提示词里直接写明当前节点名称和需要收集的字段，实测能大幅降低跑题率。

3.4 问答主循环：一次完整的多轮对话

下面是整个系统的核心方法，它串起了会话上下文、流程实例、意图识别和 LLM 回复生成。我简化了异常处理和日志，核心链路都在：

public class ConversationService { private readonly WorkflowProcessService _workflowService; private readonly LlmClient _llmClient; private readonly ILogger<ConversationService> _logger; public async Task<string> ProcessMessageAsync(string sessionId, string userMessage) { // 1. 获取或创建会话上下文 var context = await _sessionRepository.GetOrCreateAsync(sessionId); if (string.IsNullOrEmpty(context.ProcessInstanceId)) { context.ProcessInstanceId = _workflowService.StartCustomerServiceProcess(sessionId); context.CurrentActivityId = "router"; } // 2. 意图识别 var intentResult = await _llmClient.ClassifyIntentAsync(userMessage); // 3. 将用户新输入并入业务数据 MergeSlots(context.BusinessData, intentResult.Slots); // 4. 根据当前节点判断是否流转 var transitionDecision = DecideNextNode(context.CurrentActivityId, context.BusinessData, intentResult.Intent); if (transitionDecision.ShouldTransition) { var nextNode = _workflowService.TransitionTo(transitionDecision.NextActivityId, context); context.CurrentActivityId = nextNode.ActivityId; context.CurrentActivityName = nextNode.ActivityName; } // 5. 若当前节点需要执行业务动作，则执行（如查订单） var actionResult = await ExecuteNodeActionAsync(context.CurrentActivityId, context.BusinessData); // 6. 组装 Prompt 生成回复 var messages = BuildChatMessages(context, intentResult, actionResult, userMessage); var reply = await _llmClient.ChatAsync(messages); // 7. 持久化会话上下文，并记录流程日志 await _sessionRepository.SaveAsync(context); _logger.LogInformation("Session {SessionId} at node {Node}", sessionId, context.CurrentActivityName); return reply; } }

DecideNextNode是流程编排的关键，我拿它读取 XML 流程定义里的条件，但代码执行的硬校验仍然保留，避免出现“流程定义说能跳，但缺的业务数据根本没填”这种不一致问题。ExecuteNodeActionAsync是节点动作的模板方法，里面用 switch 匹配不同节点：查订单、查物流、转人工等等。

主循环跑通后，一个用户从“我要查单”到最后看到物流信息，整个状态变迁会稳如老狗。节点错了可以对着运行日志帧级回放，这在纯 Prompt 时代想都不敢想。

4. 上线后排障实录：5 个高频问题

4.1 多轮对话“失忆”：用户说过的信息又被反问

现象就是用户第一轮说“我要退昨天买的鞋”，聊到第五轮，模型突然问“您是想退货还是换货？”。不是模型蠢，是我上下文组装没做好。

排查思路是先看工作流里的 BusinessData，确认“product=鞋、time=昨天”有没有被正确写进去。如果写进去了，那就是 Prompt 里没把这些信息强调出来。我的做法是：组件系统提示词时，把 BusinessData 序列化成一段“已确认信息”，放在所有历史消息之前，并加一句“以下信息是用户已经确认过的，不要重复询问”。类似这样：

你是客服助手。以下是当前会话已经收集到的信息，用户在后续回答中可能不会再重复，请在追问和生成回复时默认这些信息已经成立： { "product": "鞋子", "time": "昨天" } 请开始处理用户问题。

这个改动之后，失忆问题基本消失。根源是我把“记忆”从模型上下文里移到了流程状态里，把流程状态又变成了显式提示，模型想忘都难。

4.2 流程实例卡住不流转

症状是用户回答完问题，系统还是重复上一轮的话术。这类问题大多出在流转条件匹配不上。比如我在 XML 里写了条件是businessData.orderNo != null，但意图识别返回的 slots 字段名写成了order_no，代码里 MergeSlots 只认orderNo，导致字段永远为 null，节点永远进不了下一步。

排查方法我先看两件东西：一是流程实例的运行日志，Slickflow 会记录每个节点的进入和离开；二是把BusinessData在每一轮对话末尾打到日志里，检查字段名、字段值是否符合预期。这两种日志一交叉，问题基本就定位了。之后我统一做了字段名规范，Slots 输出的 key 与 BusinessData 字典的 key 完全一致，再也不折腾别名转换。

4.3 Token 消耗与响应延迟失控

多轮对话最坑的就是历史消息越积越多，每轮请求的 token 量越来越大，延迟和费用双双起飞。我之前上线初期没控制，最多一次一轮请求塞了 8000 多 token，响应时间长到用户直接关页面。

后来我做了三件事。第一，历史消息只保留最近四轮，超出部分做摘要压缩，把关键信息提炼成简洁文本接在上下文后面。第二，意图识别用本地小模型或者关键词规则处理，不占主模型 token。第三，业务节点完成后的结果（比如查询到的物流信息）直接写进 BusinessData，回复生成时优先用结构化数据去组织语言，而不是让模型从零“回忆”查询结果。这样一轮请求从峰值 8000 token 降到 1000 上下，延迟和费用都变得健康。

4.4 并发场景下会话串号

会话串号是客服系统最可怕的故障：用户 A 的问题，用户 B 看到了回复。绝大多数原因不是流程引擎的问题，而是我把会话上下文存在了静态字段里，或者依赖注入生命周期配错了，导致多个请求共享同一个变量。

排查这个问题的关键是先看SessionId在每个环节有没有在最外层传入。我的处理办法是：所有会话状态的读取和写入必须显式带上 SessionId，禁止用类字段保存会话相关数据；依赖注入上，ConversationService和WorkflowService注册为 Scoped 或 Transient，绝不注册为 Singleton；最后写了一个并发压测脚本，模拟 100 个会话同时发消息，跑完检查每个 SessionId 的流程实例和返回话术是否一一对应。验证通过才敢放量上线。

4.5 大模型输出不可控，说话越界

客服场景最怕模型胡说。比如明明订单接口返回“已签收”，模型非要发挥一句“您放心，肯定会退款的”，这就出事了。我的经验是“能不让模型自由发挥的地方就不要让它自由发挥”。

关键业务信息（订单号、物流状态、退款金额）全部在节点动作里用固定模板格式化，不交给模型重新转述。模型只负责把模板内容用自然语言组织起来，并基于上下文补充礼貌用语。同时在系统提示词里写死三个约束：不要承诺任何未经业务接口确认的结果；不要编造工单号、金额、日期；无法确定的信息要引导用户转人工确认。再加上最后一层规则校验，回复里如果出现订单编号格式不对或者金额和接口返回不一致，就用兜底模板返回。这样上线到现在，没见过一次业务口径重大事故。

最后分享一个我从这个项目里带出来的判断：智能客服不是一个“模型问题”，而是一个“工程问题”。模型负责聪明，工作流负责稳定，两者拆开各干各擅长的，系统才扛得住真实流量。如果你正在做类似的东西，我建议先别急着追求流程复杂，第一条链路——查订单、查物流、转人工——跑通再往后退货、退款、更复杂的场景扩展。Slickflow.NET 的学习成本主要在流程定义和节点流转上，但只要你把这个基础模型搭对，后面每加一个新场景，都只是加节点和流转条件的事，迭代效率是真的快。