1. 这个问题要先拆成两层来看我最近被好几个团队问过同一个问题已有的业务系统比如内部管理系统、工单平台、客服后台想加一个 AI 助手入口是不是得专门搭一套会话服务先说结论不一定。多数情况下你不需要为了“加一个 AI 对话框”去单独部署一套重型会话平台但如果你把“会话服务”理解成“谁拥有会话状态”这个问题那答案就清晰多了。“会话”拆开看就两件事一是消息的收发管道二是历史上下文的存储。前者解决的是“用户的话怎么送到模型那里、模型的话怎么流回页面”后者解决的是“AI 记不记得你们刚才聊到哪了、能不能结合业务数据回答问题”。很多团队纠结要不要单独搭服务其实真正要拆的是第二件事——你愿不愿意让业务系统自己持有和管理这些状态。适合读这篇内容的读者我默认你已经有一个跑得挺稳定的业务系统团队里有人会写后端前端也有一两个能改页面的同学但还没有专职的 AI 工程师或算法团队。你要的不是从零训练模型而是把一个现成的大模型能力自然接进现有业务里。下面我说的所有方案都是基于“接现成模型”这个前提不涉及微调、不涉及私有化部署 GPU 集群这种重投入。2. 三种主流做法对应三种完全不同的处境2.1 方案 A直接在业务后端加一个对话路由最轻的做法就是不改架构在现有业务系统的后端服务里加一个/api/ai/chat接口。前端页面加个聊天框用户发消息走这个接口后端负责拼 prompt、调模型 API、拿结果返回给前端。会话历史可以存进现有业务库的某张表里结构简单到五六个字段就能搞定。这个方案最直接的优势就是快。一个后端同学花两天时间就能把整个链路跑通。我建议任何团队在评估“要不要单独搭服务”之前都先用这种最笨的方式把流程走一遍因为你只有亲手跑通了才知道哪些环节是瓶颈哪些环节根本用不着过度设计。但它的短板也非常明显模型调用是同步的、耗时的、不稳定的。一个耗时长则十几秒的请求直接挂在业务请求线程上会挤压正常业务接口的线程池。人多了一打先遭殃的不是 AI 接口而是你原本稳定的订单接口、查询接口。所以我给这种方式的定位是验证期专用人少、并发低、能接受偶尔超时才适合这么干。2.2 方案 B独立部署一个会话服务当你有多个业务系统都要接入 AI或者单系统并发量上来之后再考虑单独抽一个会话服务出来。这个服务不承担任何具体业务逻辑只做几件事接收来自各业务系统的对话请求组装上下文调用模型把结果流式推回调用方顺便管会话状态和审计日志。为什么这个阶段要拆核心原因是“故障隔离”和“扩缩容独立”。模型调用是个不可控的第三方依赖你不想让这种不可控性传染给核心业务服务。独立的会话服务可以单独扩副本、单独配置超时、单独做限流模型供应商那边出问题了至少不会把整个业务系统拖垮。判断要不要拆的最实际标准就是看会话状态的归属。如果是单个业务系统内部用会话状态放在业务库里完全没问题。但如果你发现这些会话数据要被多个系统共享比如 A 系统产生的会话摘要B 系统也要读或者你打算积累用户长期的偏好、画像这些数据未来要跨业务线复用——那就必须拆出来让会话服务成为会话数据的唯一持有者。2.3 方案 C直接接入现成的 AI 助手产品或平台还有一种情况你根本不需要在业务系统里自己做对话界面直接把企业微信、飞书、钉钉里的机器人助手接进来或者采购一个知识库问答平台甚至用近期很流行的“AI Agent 搭建工具”快速配置一个。这种适合什么场景呢适合你的需求就是通用问答——员工问“报销流程是什么”“怎么申请服务器资源”回复内容基于制度文档、知识库不需要跟你系统里的业务数据做深度联动。这类方案的好处是上线最快通常一个下午就能配好而且自带管理后台、权限控制、统计报表。代价是你失去了自由度数据要放到对方平台上会话里能拿到多少业务上下文完全取决于平台给你开放了多少接口。我见过不少团队先用这种方案验证需求跑了一两个月发现问答命中率上不去原因就是“AI 没有看到用户在当前系统里的具体数据”最后还是得回到自研路上来。2.4 怎么选一张表说清楚维度方案 A内嵌直连方案 B独立会话服务方案 C现成产品接入成本2~3 天1~2 周几小时并发承载低高可独立扩容取决于平台会话状态归属业务库会话服务独有平台方业务数据联动完全可控直接 SQL完全可控按需组装受限故障影响范围可能拖垮业务服务隔离在会话服务内部平台故障不可控适合阶段POC 验证 / 内部小规模多系统接入 / 线上稳定运行通用问答 / 制度检索判断口诀就一句话会话若只是功能嵌进去会话若是资产拆出来。3. 渐进式方案先内嵌验真再独立服务规模化3.1 第一阶段用“最小可用链路”回答四个问题不管最终要不要拆服务我建议都从内嵌直连开始。这个阶段不追求完美只求回答四个问题第一用户在这个系统里实际会问什么类型的问题收集 100 条真实提问比在会议室里拍脑袋想 100 个场景有效得多。第二模型返回的内容业务方能不能接受这里包括回答准确率、格式、语气。第三你的业务数据里哪些字段能安全地提供给模型哪些字段涉及敏感信息必须屏蔽第四高峰期大概会有多少人同时使用有团队一上来就规划了 Kafka、Redis 会话缓存、向量数据库结果跑了一个月日活用户就十几个人。这就是典型的过度设计。反过来也有团队用方案 A 跑了半年用户还真用起来了每天几百个请求这时候再拆服务就有非常充分的理由和依据——你手里的真实数据会告诉你瓶颈在哪里。3.2 第二阶段从内嵌到独立服务的抽取边界当你决定拆独立会话服务后要做的第一件事不是写代码而是画清楚边界。建议按下面这个思路来业务系统负责用户身份认证、业务数据查询、权限控制、前端界面会话服务负责会话生命周期管理、上下文组装、模型调用、流式推送、限流、审计核心接口可以这样设计POST /ai/session 创建会话 POST /ai/session/{sid}/chat/stream 发送消息SSE 流式返回 POST /ai/session/{sid}/history 获取历史消息 POST /ai/session/{sid}/archive 归档会话会话服务对外不关心业务系统内部的数据结构它只认一个统一的消息协议{ session_id: s_10001, biz_type: work_order, user_id: u_888, content: 帮我看看单号 T-20240510 的处理进度, extra: { callback_url: https://biz.example.com/hooks/ai-result } }这里的biz_type很关键后面讲上下文组装的时候还要用到。3.3 上下文组装让 AI 说“人话”、办“实事”独立会话服务的核心价值不在于“能聊天”而在于每一次请求都能拿到跟当前用户、当前业务场景相关的数据然后组装成模型能理解的上下文。这也是区分“玩具”和“工具”的分水岭。我以前做过一个工单系统的 AI 助手一开始直接把用户原话发给模型模型答得乱七八糟因为它根本不知道用户是谁、他有没有权限、他说的单号在系统里是什么状态。后来改成服务端拦截请求先在业务库里查出必要的数据再把这些数据拼进 system prompt效果立刻就变了。具体做法是在会话服务里维护一个“上下文增强器”的概念不同biz_type对应不同的数据拉取逻辑。以工单查询为例在调用模型之前先用工具从业务系统拉取工单状态和当前操作人的角色然后组装成如下 prompt你是企业内部的工单客服助手。用户工号 {user_id}角色一线客服。 用户咨询工单 #{ticket_no}当前状态处理中当前负责人张三最近更新2小时前。 请基于以上信息回答用户问题。只回答与工单相关的内容不确定的信息不要编造。效果差异是肉眼可见的。没有上下文增强时模型只会说“您可以通过工单系统查询进度”有上下文增强时模型直接答“您的工单 T-20240510 当前在处理中负责人张三预计今天下午完成”。后者才算真正有用的助手。3.4 多轮记忆与 Token 窗口控制有状态就必然面临上下文膨胀的问题。你不可能把用户过去所有对话全塞给模型token 量会随着对话轮数线性增长费用和响应时间都扛不住。这里我的经验是做一个“三级记忆”策略第一级短期上下文保留最近 5~10 轮对话原文直接放给模型。这是模型回答准确的根基。第二级中期摘要每 20 轮左右让模型把前面的对话总结成一段摘要存进会话字段里之后每次请求带着摘要最近对话走。第三级长期画像会话结束后把用户关注过的问题类型、常用操作沉淀成标签下次新会话启动时再注入。对话轮次不必死板按 token 估算更科学。中文场景下大致可按“1 个汉字约 1.5~2 token”估算4k 上下文窗口留给历史消息的区域建议控制在 1500~2000 token剩下的预留给 system prompt、业务数据和模型输出。超出这个量就触发摘要压缩。# 伪代码消息列表的 token 估算与截断 def trim_messages(messages, max_tokens1800): trimmed [] total 0 # 摘要作为首条消息保留 summary messages[0] # 已摘要化 total count_tokens(summary) for msg in reversed(messages[1:]): cost count_tokens(msg) if total cost max_tokens: break trimmed.insert(0, msg) total cost return [summary] trimmed3.5 流式响应前端体验的分水岭很多第一次接 AI 的团队会忽略流式输出这一步让用户傻等七八秒页面上一个字都不出用户直接就关掉了。等模型完整返回再一次性推给前端这种体验放在即时对话场景里是致命的。正确做法是用 SSEServer-Sent Events做流式返回。前端用fetch或EventSource接收逐步推送的 token就像打字机一样逐字显示。后端实现绕不开三个要点正确设置Content-Type: text/event-stream消息格式按data: {json}\n\n分隔连接断开或超时要有兜底策略# FastAPI 示例SSE 流式返回 from fastapi.responses import StreamingResponse app.post(/ai/session/{sid}/chat/stream) async def chat_stream(sid: str, req: ChatRequest): async def event_generator(): async for chunk in model_call(req.content): yield fdata: {json.dumps({delta: chunk}, ensure_asciiFalse)}\n\n return StreamingResponse(event_generator(), media_typetext/event-stream)这里有个容易被忽略的点SSE 只适合服务端单向推送给客户端。如果对话过程中要传输的不只文本还有工具调用的状态、引用的文档列表、结束原因都可以在data字段里用不同的事件名区分。前端通过addEventListener监听不同事件体验会更细腻。3.6 前端接入别重复造轮子也别强行统一前端要做的事情其实很简单一个聊天框一个消息列表一个流式读取逻辑。没必要为此引入一套重型的聊天框架一个自定义组件完全够用。接会话服务时建议把 SDK 封装成这样几个函数// ai-sdk.js const AIClient { createSession(bizType) { return fetch(/ai/session, { method: POST, body: JSON.stringify({ biz_type: bizType }) }) }, async sendMessage(sessionId, content, onDelta) { const resp await fetch(/ai/session/${sessionId}/chat/stream, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ content }) }); const reader resp.body.getReader(); const decoder new TextDecoder(); while (true) { const { done, value } await reader.read(); if (done) break; const chunk decoder.decode(value); // 按SSE格式解析 data 字段 onDelta(parseDelta(chunk)); } } };前端不要自己偷偷保存会话历史所有的会话记录都以服务端为准。刷新页面后通过getHistory加载历史消息这样用户换设备、清缓存对话记录都不会丢。3.7 安全与审计上线前就必须想清楚加 AI 助手的最大隐患不在模型而在数据边界。你的业务系统里大概率有用户手机号、身份证、订单金额、内部审批意见等敏感数据。这些数据一旦进了 prompt、发给了外部模型 API你基本就失去了对它的控制。所以务必要在会话服务里做三层过滤。第一层数据脱敏敏感字段在拼进 prompt 前打码或替换比如手机号只保留后四位。第二层输出过滤模型的返回内容过一道敏感词和规则匹配防止内部数据被诱导出来。第三层全量审计所有输入输出落日志记录用户身份、时间、调用模型版本、token 消耗存档备查。别嫌麻烦出了事没日志你连事故原因都定位不了。4. 我踩过的坑和一张排查速查表4.1 会话状态放在前端结果一切换设备就“失忆”我最早做一个内部工具时图省事把对话历史存在浏览器 localStorage 里。单机自测没问题但用户一换电脑历史全没了用户如果在两个设备间来回用上下文还会互相覆盖AI 完全不记得自己说过什么。这事折腾了两周才彻底修掉。教训就是会话状态的唯一持有者必须是服务端。前端只做展示永远不要做存储。即使内嵌阶段会话表放业务库里也比放浏览器靠谱得多。4.2 用普通 POST 接口做对话前端迟迟收不到半个字第一次做 AI 对话接入时我用普通 POST 接口等模型完整生成后一次性返回。单轮对话还好多轮对话一旦模型思考超过 5 秒前端就超时了。用户点完发送页面一直转圈体验极差。改成 SSE 流式之后第一帧内容在 500 毫秒内就能出现在屏幕上用户感知完全变了。流式不是可选项是默认项。哪怕你的模型响应够快流式也给你留了提前渲染、提前交互的空间。4.3 把“知道”当“做到”知识库不是塞给模型的资料包团队另一个容易踩的坑是买了个向量数据库把公司文档全灌进去然后希望 AI 什么都能答。但模型能不能答好取决于两件事检索质量与上下文配合。向量检索召回一堆文档片段如果片段路线不对模型就会一本正经地胡说。我当时查“报销流程”时召回回来的文档片段是《财务审批权限表》模型煞有介事地告诉用户“您需要副总裁审批”实际上那个场景只需要部门经理签字。原因就是检索到的片段虽然关键词相关但上下文语境不对。解决方式是在检索之外增加一层业务规则过滤比如根据用户角色、单据金额先限定文档范围再走向量检索。知识库是辅助业务规则才是边界。4.4 多轮对话跑着跑着就“晕头”越聊越跑偏对话超过十几轮后模型会开始“遗忘”早期关键信息甚至把用户上一轮的内容错当成自己说的。本质原因是上下文窗口容不下全部历史而你只做了“截断”没有做“摘要”。你丢掉的不是废话而是关键约束模型自然就飘了。我的做法是不等超限再处理而是每 N 轮主动做一次摘要并固化。比如每 10 轮调用一次模型把前面的核心信息浓缩成 3~5 条要点存成摘要消息。后续每一轮请求都用“摘要最近对话”的组合保证模型始终带着全貌回答。4.5 并发一上来先挂的不是 AI 服务而是业务系统本身前面说过方案 A 的风险线程池被 AI 调用挤爆。这问题我在线上真实见过用户量一多AI 聊天请求把业务服务线程池耗尽整个系统所有接口都开始超时。这是拆独立会话服务最强的信号。拆出来之后的隔离策略是会话服务单独部署配置独立的超时和重试策略模型 API 单次调用最长等待 30 秒超过就断开并提示“服务繁忙”业务系统调用会话服务时再设置 3 秒的向下游超时不因为 AI 服务变慢而拖垮主链路。两边超时分开设置整个系统会稳很多。4.6 常见问题速查表症状可能原因排查思路与解决方向回答与事实不符上下文没接入业务数据检查是否做了服务端上下文增强业务字段是否有拼进 prompt响应慢、前端空白未做流式输出改 SSE 推送查看模型 API 首字延迟换设备后历史丢失会话状态存了前端迁到服务端存储前端改为读接口多轮后回答跑偏历史消息截断但不做摘要加中期摘要策略保留最近 5~10 轮摘要高并发下业务接口超时AI 调用挤占业务线程池会话服务拆出独立部署超时设置分级用户被诱导出敏感信息输入输出缺过滤输入脱敏、输出过滤、全量审计模型总是答“请联系人工”上下文里缺少可用数据把相关业务字段通过工具调用或数据库查询注入调用费用暴涨每次都带全量历史做 token 估算与裁剪加摘要压缩5. 最后分享一点我的实际感受做这类 AI 接入最大的成本其实不在代码而在“治理”。模型调用本身很便宜、很快难的是你决定让模型接触到哪些业务数据、哪些数据能出域、会话怎么管理、出了问题怎么追溯。这些决定越早做越省钱。我的习惯是先用内嵌直连的方式跑最少两周让真实用户把问题暴露出来再决定要不要拆独立服务。大多数团队在这个阶段会发现优先级根本不在架构上而在“AI 能不能回答准”上。把这个阶段打磨透了再谈拆服务、再谈规模化每一步都踩在真实需求上。如果你也正好在评估这个事不妨先按这个节奏走一遍试试。