先交代一个反直觉的结论我们最终跑通的 AI 办事系统用的不是几十B 的“大家伙”而是一个开源 9B 量级的实时对话模型真正让它从“聊天窗口”变成“办事入口”的不是参数规模而是旁边那一套把前后台串起来的管道内部代号 Harness。这个系统要解决的是很多团队都会撞上的天花板对话模型聊得头头是道一旦让它调用后台系统办事比如查工单、改状态、生成报表、发送通知不是参数乱填就是让用户盯着转圈等结果。我们的目标很明确——让“对话”和“办事”异步并行。用户说第一句话任务在后台跑用户继续说第二句话系统照样接得住任务跑完事件再推回会话窗口。接下来我按选型、链路、管道设计、异步并行的落地细节外加踩坑复盘来展开适合正在做 AI 助理、智能客服、LLM工具调用这类项目的同学参考。我不太喜欢讲抽象架构所以尽量说具体决策和背后原因。1. 为什么AI助手总在“聊天”和“办事”之间翻车1.1 “聊得好”和“办得成”是两套评价体系很多业务系统现在都配了“智能助手”入口但用起来普遍不及预期。我们这边有几套内部系统工单、审批流、客户反馈、周报生成。用户操作路径很长登录、进菜单、筛选、打开详情、再点反馈每一步都在消磨耐心。最开始我们想做的是“对话直接办事”先试了直接接通用大模型 APIdemo 演示时经常翻车。翻车点不在模型不会说话而在“说”和“做”的节奏错位。聊得好指的是语义回复自然、情绪判断准确办得成指的是调用正确的工具、传了正确的参数、还能幂等地执行。前者是生成问题后者是工程问题。我们最初把两件事揉在一个同步请求里走用户一句话 → 模型返回一段 JSON → 立即执行 → 结果塞回上下文 → 再让模型总结。短任务比如查单个工单状态还能忍受但“查一批数据 生成周报 发送给负责人”这种流程要跑几十秒同步交互直接让用户进入“转圈焦虑”。1.2 拆解需求把对话层和任务层分成两个平面想明白之后我们把系统拆成两个清晰平面。对话层负责维持会话、理解意图、澄清参数、汇报结果任务层负责执行动作、编排依赖、重试、幂等控制。两层之间不直接互相调用而是通过任务 ID 和消息事件汇聚。这个设计直接决定了后面 Harness 管道的样子。对话层是高频低延迟的用户一句话接一句话模型必须快速响应任务层是低频长耗时的查询数据库、生成文档、发送消息都可能要几秒甚至几十秒。如果把两边压在同一个请求链路里互相拖累是必然的。拆开之后会话网关可以按对话压力扩缩容任务 Worker 可以按任务积压量扩缩容两者互不知晓只通过消息队列交换事件。这个思路不复杂但很多项目一开始都没想到直到卡在体验上才回头补课。1.3 模型选型为什么9B开源实时对话模型是“刚刚好”的起点模型选型上我们一开始也讨论过要不要直接用更大的闭源模型。最终否掉的原因很简单业务数据要出内网这是硬红线还有版本可控、调用成本、时延预算都不允许我们依赖外部 API。于是目光落到开源模型上选型坐标有三个私有化部署、时延够低、支持工具调用。某高校开源团队放出的那个 9B 实时对话模型正好踩在点上。它支持流式输入流式输出能处理多轮对话原生支持 function calling官方模型卡上写的授权也允许内部商用。9B 这个规模有个好处单卡能跑量化之后显存压力很小部署成本低推理首 token 延迟能压到几百毫秒级别足够支撑高并发实时会话。对比百 B 级模型虽然通用知识量和复杂推理能力更强但时延、显存、单卡吞吐都撑不住我们这种“每个用户都开一条实时会话”的场景。我们和高校那边做的联合适配也不是什么玄学就三件事把业务 API schema 对齐到模型的工具调用格式用内部脱敏对话样本做了一轮轻量 LoRA让模型更习惯“先澄清参数再动手”然后 INT8 量化部署双卡 40G 专业 GPU线上实测单卡稳定扛住 25 路左右并发对话。2. 实时会话链路让模型“听得懂人话说得出结构”2.1 链路组成与连接方式整个实时会话链路从前到后是前端(文本或语音) → 长连接网关 → 会话状态节点 → 实时推理服务 → 工具参数规整层 → Harness 管道。语音这块我们初期做成可插拔的优先用 ASR 转文本再进模型不追求端到端语音模型先把文本链路跑稳。传输层选型上我们最终用了全双工长连接而不是 HTTP SSE。原因很实际实时对话需要双向消息。用户端要随时把语音片段、文本消息、打断事件发给服务端服务端要主动推送模型流式输出、任务状态、任务结果。SSE 只能做单向推送打断和上行控制还得另起连接调试和维护成本高。长连接配心跳15 分钟空闲自动关闭断线重连后靠 session_id 恢复上下文这一套在现网跑下来很稳。2.2 模型部署与并发基线实测模型部署上我们没有追求最大化吞吐而是先保住时延体验。INT8 量化之后9B 模型在双卡 40G 专业 GPU 上能轻量部署我们给线上配了单卡承载会话另一卡做备用和滚动更新。上下文策略是重点只保留最近 3 轮完整对话 当前活动任务快照 最后一次操作结果。一开始我们贪心把所有历史都塞进上下文结果模型越聊越“糊涂”经常把旧任务细节复读出来。后来发现模型不需要记住全部历史只需要知道最近在聊什么、当前有没有没做完的任务、上一个动作结果是什么。这三样信息组成了会话的“工作记忆”足够了。实测下来40 路并发对话时首 token 平均延迟约 0.7 秒完整回复的 token 生成速度稳定体感上基本没有“卡住”的感觉。2.3 工具调用不能靠模型“自由发挥”让 9B 模型稳定输出工具调用参数是这个项目里最花功夫的部分。我们给每个业务工具定义了 JSON Schema推理服务开启结构化输出约束让模型只能产出符合 schema 的 JSON。一个典型工具定义长这样{ type: function, function: { name: task_query_feedback, description: 查询客户反馈数据, parameters: { type: object, properties: { keyword: { type: string, description: 查询关键词 }, time_range: { type: string, enum: [today, week, month, custom], description: 时间范围 } }, required: [keyword, time_range] } } }但 schema 只是限制了格式没有限制语义。9B 模型在处理中文枚举和时间表达时偶尔会“自由发挥”比如用户说“上周”模型可能输出 time_rangelast week”而不是我们枚举里的 “week” 或 “custom”。所以我们在模型后面加了一层工具参数规整层把自然语言时间表达归一化成具体日期区间枚举值做映射兜底参数缺失或非法时不盲目执行而是让 Harness 生成一句澄清问句回给用户。宁可多问一句也不要执行错动作这个原则我们一直保留到生产环境。3. Harness管道的核心设计一套消息契约打通前后台3.1 先解释一下Harness这个叫法“Harness”不是某家云厂商那款同名产品我们只是取“给马套上缰绳”的意思作为自研管道的代号。它做的事情概括成一句话把前端会话、模型推理、后台任务、业务工具这四个原本各管一段的模块用一套统一的消息契约串起来。有了这层管道前后台不用互相知道对方存在只需要遵守同一种消息格式。这层设计带来的直接好处是业务工具可以完全复用现有系统的 API不需要为了 AI 对话单独改接口反过来任何一个工具只要接上 Harness就能立刻被对话层调用。前端页面通过按钮调用工具和对话模型通过自然语言调用工具走的是同一条路由只是入口不同。3.2 消息信封所有事件都长一个样Harness 内部传递的消息统一封装成“信封”结构所有模块只要收发这种信封即可。我最看重的字段是 session_id因为异步并行之后任务结果返回的顺序和用户对话顺序完全无关没有 session_id 根本没法把结果还给正确的会话。{ id: evt_f8a21c, session_id: sess_88234, type: task.progress, payload: { task_id: t_1190, status: RUNNING, stage: query_feedback, ts: 1729675100 } }消息类型在整个系统中只有五种session.message 承载模型输出task.created 表示任务已入队task.progress 表示执行进度task.result 表示任务完成并携带结果数据session.close 表示会话结束。类型少各模块的处理逻辑就简单不容易出现“消息发出去没人接”的情况。3.3 一个典型请求的完整流转拿一个真实场景走一遍用户说“查一下上周客户反馈里提到发货慢的有多少条然后同步给客服组长”。第一步用户消息进入会话网关带上 session_id网关把消息转给模型推理服务。第二步模型结合工作记忆输出工具调用意图任务一查询反馈数据任务二等结果出来后发送给指定联系人。第三步Harness 解析结构化物件生成两个有依赖关系的子任务task_1 先入队task_2 标记为等待依赖。第四步task_1 的 Worker 查到数据把结果写入会话工作记忆并把 task_1 标记完成触发 task_2 入队。第五步task_2 执行发送动作。第六步task_2 完成后Harness 生成一条汇总消息由会话网关推送到前端“上周提及发货慢的反馈共 87 条已同步给客服组长。”整个过程里用户在前台不用干等。他可以在 task_1 还在跑的时候继续问“那售后响应慢的有多少”这第二个问题会开启另一组任务。等第一组任务跑完推回结果用户看到的是一段自然的汇报而不是一堆技术状态码。这就是“异步并行”在用户侧的体感对话不断任务不乱结果都能回来。4. 异步并行的落地细节状态机、依赖编排和限流4.1 什么样能并行什么样必须等异步并行不是“把所有任务都并行跑”这么简单而是要先判断依赖关系。我们内部用任务图来编排每个子任务是图里的节点节点之间只有两种关系并行和依赖。并行指的是两个任务互不依赖可以同时跑依赖指的是 B 任务必须等 A 任务的结果才能开始。举个例子用户说“汇总上周各区域销售数据算增长排名把前三名写进周报”。这个请求会被拆成读取销售数据的子任务按区域拆分华东、华北、华南、西南四个查询互不依赖可以并行等四个结果都回来后才能做汇总排名汇总完成之后生成周报的子任务才能开始。这里面并行的是第一层四个查询第二层第三层都是严格串行依赖。如果任务图设计错了要么任务空等要么数据还没齐就开始汇总结果必错。4.2 任务状态机与失败处理每个任务在 Harness 里都维护一个状态机状态只有六种PENDING、RUNNING、WAITING_DEPS、SUCCEEDED、FAILED_RETRY、CANCELLED。状态含义触发动作PENDING已入队等待调度调度器按优先级分配 WorkerRUNNINGWorker 正在执行可发送 task.progress 回传进度WAITING_DEPS等待依赖任务完成依赖任务完成后自动唤醒SUCCEEDED执行成功结果写入上下文生成汇报消息FAILED_RETRY执行失败等待重试指数退避最多重试 3 次CANCELLED被用户或策略取消释放占用的资源槽位除了状态机幂等是我们特别强调的一环。后台任务并行多了之后一个任务可能因为超时被重复投递如果这个任务是“发送邮件”或者“创建订单”重复执行就是事故。所以每个任务在创建时都带一个幂等键由 session_id、任务类型、业务参数联合算出。Worker 执行前先去查幂等记录存在就直接返回上次结果不再重复执行。4.3 资源限制与压测数据并行带来的最大风险不是模型扛不住而是下游业务系统扛不住。我们把任务队列和每个工具的并发上限绑在一起每个业务工具单独维护并发信号量比如查询类工具最大并发 30发送类工具最大并发 10。全局还有一个总并发因子防止某个用户的任务图把整个 Worker 池占满。压测环境里我们模拟 40 路实时会话同时在线用户持续发消息后台同时有 120 个左右子任务在飞最终测出来的数据是首 token 平均延迟约 0.7 秒任务成功率 99.2%任务平均完成时长约 12.8 秒数据库连接池始终没有被打满。这个数据不算极限性能但足够说明一件事小模型加异步管线的组合完全可以在真实业务场景里稳定跑起来。5. 踩坑记录与复盘后的一点个人判断5.1 四个真实影响体验的坑第一个坑是会话上下文无限膨胀。最开始我们希望模型记得越全越好把所有历史都堆进上下文结果聊到第十轮左右模型开始“复读”前面的任务描述甚至把已经完成的任务再执行一遍。后来改成“最近 3 轮完整对话 活动任务快照 最后操作结果”这个问题基本消失。第二个坑是模型工具参数的“幻觉”。9B 模型有时会编造不存在的参数值尤其是时间范围。我们一开始直接把参数透传给业务系统结果出现过查询“2024年2月30日”这种非法日期的闹剧。后来加上参数规整层非法值一律反查澄清宁可多问一句也不往后传。第三个坑是任务完成时用户已经下线。有一次用户问完就关了页面后台任务照常跑了 20 秒结果准备推送时发现会话已经关闭消息丢得无声无息。后来所有任务结果都持久化用户重新上线时主动拉取未读任务结果才算把这个洞堵上。第四个坑是并行任务把数据库连接池打满。早期压测一上量查询类任务几十个并发同时打向数据库连接池直接耗尽影响到正常使用系统的同事。后来给每个工具加并发信号量全局再加总限额才把数据库保下来。这个坑说明异步并行不是只管队列就够了下游的资源水位同样要盯。5.2 这套模式适合什么场景不适合什么场景跑完这个项目我对“小模型 异步管线”的适用边界有了更清楚的判断。适合的场景有企业内部工具比如查工单、改状态、发起审批客服助手比如查订单、改地址、同步客服组长行政 OA 类重复性动作多、流程大部分可结构化。这些场景的共同点是动作边界清晰、参数可枚举、错误影响可控。不适合的场景也很明确需要大量创造力的开放式任务或者是单次执行要跑几十分钟、强行拆分很难的复杂流程。这种场景硬上异步任务编排只会把任务图画得比业务本身还复杂最后收益抵不上运维成本。异步并行是为了让前台体验不被后台执行拖住不是为了把单个慢任务伪装成快。5.3 给想复制这套路线的团队的三句实话第一句别一上来就上 DAG 编排先做“单动作 状态回显”。让用户问一句系统执行一个动作把结果正常推回来这条链路跑稳了再谈依赖和并行。第二句工具调用协议要按照 API 网关的规范设计。每个工具的入参、出参、错误码、幂等键都定义清楚这样对话模型调用和前端页面调用共用同一套后端能力维护成本会低很多。第三句进度汇报不一定要靠 LLM 生成。任务进行中的进度卡用模板就能扛住 90% 的场景只有最终结果需要模型润色成自然语言。这样既能保证反馈速度又能省下大量模型调用成本。这个项目做下来我最深的体会是实时对话模型的“实时”不只是推理延迟低更在于整条链路能不能让用户感觉到“我说的话立刻有反应我交代的事正在办”。真正决定体验上限的是管道设计而不是模型大小。9B 模型给了我们一个低门槛的起点Harness 管道才是让 AI 真正“办成事”的缰绳。
