今天想和大家聊聊智能客服机器人工作流的设计与实战。我们团队最近在重构一个老旧的客服系统目标是打造一个高并发、低延迟、高可用的智能对话平台内部代号就叫“coze”。在这个过程中我们踩了不少坑也总结了一些经验希望能给有类似需求的同学一些参考。1. 从业务痛点说起为什么需要“coze”我们之前的客服系统简单来说就是个“if-else”集合体。用户问“我的订单到哪了”系统就去查数据库用户问“怎么退货”系统就回复一段预设文案。这种模式在初期用户量不大时还能应付但随着业务增长问题接踵而至响应延迟高高峰期用户排队简单的查询也要等上好几秒体验极差。对话状态混乱用户多轮对话时比如先问订单再问物流最后问优惠券系统经常“失忆”上下文衔接不上。扩展性差每增加一个新业务比如会员积分查询就要在庞大的规则代码库里“打补丁”牵一发而动全身。智能化不足只能处理明确的关键词对于“我买的东西还没送到怎么回事”这类口语化、多意图的语句完全无能为力。传统的RPA机器人流程自动化擅长处理固定、重复的桌面操作流但对需要理解和生成自然语言的对话场景力不从心。纯规则引擎虽然决策速度快但维护成本随着规则数量指数级增长且无法处理语义模糊性。而单一的AI大模型虽然理解能力强但在处理严谨的业务流程、保证响应速度和稳定性方面直接接入生产环境风险很高。因此我们的“coze”工作流核心思路是融合用规则引擎保障核心流程的确定性与效率用AI模型处理语义理解与泛化用精心设计的状态机和事件驱动架构来串联整个流程应对高并发。2. 核心架构设计事件驱动与微服务化“coze”的架构可以概括为“一心两翼”。一心一个轻量级的对话状态机Dialogue State Machine作为核心调度中心。它不处理具体业务只负责管理会话生命周期、维护上下文、并根据当前状态和接收到的事件决定下一个要执行的动作Action。两翼左侧输入翼一系列意图识别微服务。我们将意图识别拆解成多个层次先由快速的关键词/规则匹配服务过滤掉明确指令如“转人工”剩余的复杂语句交给AI语义理解服务我们用的是微调后的开源模型进行意图分类和槽位填充。这两个服务可以并行或串行调用兼顾速度与精度。右侧输出翼一系列动作执行微服务。每个动作对应一个独立的服务如“查询订单状态”、“生成退货指引”、“调用知识库问答API”、“转接人工坐席”等。这些服务专注于自己的领域可以独立开发、部署和扩缩容。整个系统的运转基于异步事件。用户消息到达后被包装成一个UserUtteranceEvent发布到内部消息队列如Kafka。状态机作为消费者接收到事件后驱动流程执行调用意图识别服务 - 根据识别结果和当前状态决定下一个动作 - 调用对应的动作执行服务 - 将执行结果包装成BotResponseEvent发送回响应队列最终返回给用户。这种解耦使得每个环节都可以独立优化和容错。3. 关键实现细节与代码示例对话状态机设计 我们参考了FSM有限状态机的思想但更灵活。每个会话Session维护一个状态对象包含session_id、current_state如GREETING,HANDLING_QUERY,WAITING_FOR_CONFIRMATION、context一个字典保存用户ID、订单号、已识别的槽位等信息和history。状态转移由预定义的规则表驱动规则表定义了从[当前状态 识别到的意图]到[下一个状态 要执行的动作]的映射。意图识别微服务集成 我们使用gRPC进行微服务间通信保证高性能。下面是一个简化的Go语言SDK调用示例包含了错误处理和链路追踪使用OpenTelemetry。package main import ( context fmt log time go.opentelemetry.io/otel go.opentelemetry.io/otel/trace pb your_project/intent_recognition/proto // 假设的protobuf生成代码 google.golang.org/grpc google.golang.org/grpc/credentials/insecure ) type IntentRecognitionClient struct { conn *grpc.ClientConn client pb.IntentRecognitionServiceClient tracer trace.Tracer } func NewIntentRecognitionClient(addr string) (*IntentRecognitionClient, error) { ctx, cancel : context.WithTimeout(context.Background(), 5*time.Second) defer cancel() conn, err : grpc.DialContext(ctx, addr, grpc.WithTransportCredentials(insecure.NewCredentials()), grpc.WithBlock(), ) if err ! nil { return nil, fmt.Errorf(failed to connect to intent service: %w, err) } tracer : otel.Tracer(coze-dialogue-engine) return IntentRecognitionClient{ conn: conn, client: pb.NewIntentRecognitionServiceClient(conn), tracer: tracer, }, nil } func (c *IntentRecognitionClient) Recognize(ctx context.Context, query string) (*pb.RecognitionResult, error) { // 创建子Span用于追踪本次识别调用 ctx, span : c.tracer.Start(ctx, IntentRecognition.Recognize) defer span.End() req : pb.RecognitionRequest{ Query: query, SessionId: ctx.Value(session_id).(string), // 从上下文获取 Timestamp: time.Now().Unix(), } // 设置调用超时 callCtx, cancel : context.WithTimeout(ctx, 2*time.Second) // 严格限制识别时间 defer cancel() resp, err : c.client.Recognize(callCtx, req) if err ! nil { // 记录错误日志和追踪信息 log.Printf(ERROR calling IntentRecognition for session %s: %v, req.SessionId, err) span.RecordError(err) // 返回一个默认的“未知意图”结果保证流程不中断 return pb.RecognitionResult{ Intent: UNKNOWN, Confidence: 0.0, Slots: map[string]string{}, }, nil // 注意这里错误被消化返回了降级结果 } log.Printf(INFO Intent recognized for session %s: %s (confidence: %.2f), req.SessionId, resp.Intent, resp.Confidence) return resp, nil } func (c *IntentRecognitionClient) Close() error { return c.conn.Close() }异步事件处理机制 我们使用了一个事件分发器Event Dispatcher。状态机在完成动作决策后并不直接调用动作服务而是生成一个ActionExecutionEvent事件。事件分发器负责将其投递到对应的动作服务专属队列。动作服务处理完成后再生成ActionCompletedEvent或ActionFailedEvent回馈给状态机。这样状态机本身是无阻塞的可以快速处理下一个用户事件系统的吞吐量得到极大提升。4. 性能测试我们达到了什么水平在4核8G的标准云服务器上我们对核心链路进行了压测使用Locust模拟用户请求。QPS (Queries Per Second)在意图识别服务规则AI和订单查询动作服务均无瓶颈的情况下对话状态机核心调度链路可稳定支撑1200 QPS。瓶颈主要出现在AI模型推理耗时上通过模型量化、服务端批处理Batching和GPU加速我们将AI服务的平均响应时间控制在150ms以内。响应延迟 (P95/P99)从用户消息发出到收到机器人回复P95延迟稳定在200ms以下P99延迟在350ms以下。这得益于异步化设计和各环节的超时控制。容错率我们模拟了动作服务宕机、网络波动、AI服务响应超时等场景。在降级策略如AI服务超时后 fallback 到规则匹配动作服务失败返回友好提示保障下系统整体可用性达到99.95%未出现因单个组件故障导致的雪崩。5. 生产环境避坑指南这是血泪换来的经验希望大家能避开冷启动优化AI模型服务启动后第一次推理特别慢冷启动。我们的解决方案是预热Warm-up。在服务启动后、接入真实流量前先构造一批典型的查询语句进行预测让模型和计算图“热”起来。同时在K8s中配置就绪探针Readiness Probe确保预热完成后再接收流量。会话粘性Session Affinity处理为了保证用户对话上下文的一致性同一会话的多个请求必须路由到同一个状态机实例。我们没有采用传统的负载均衡器会话保持而是在网关层根据session_id进行一致性哈希如使用Redis存储会话与实例的映射将请求定向到特定实例。这样更灵活也便于状态机实例的水平扩容和故障转移。上下文存储与清理用户对话上下文不能一直放在内存里。我们使用Redis作为外部存储并设置合理的TTL如30分钟。状态机每次处理事件时先从Redis加载上下文处理完再写回。同时要设计一个后台任务定期清理过期的会话数据避免内存泄漏。监控与告警除了常规的CPU、内存、QPS监控必须关注业务指标如“未知意图UNKNOWN比例”、“各动作服务失败率”、“用户主动转人工率”。这些指标的异常波动往往比系统指标更能提前暴露问题。我们为这些关键业务指标设置了告警。灰度发布与回滚任何对状态机规则、意图识别模型或动作服务的更新都必须走严格的灰度流程。我们通过网关将少量流量如5%导入新版本对比新老版本的响应内容、错误率和用户满意度确认无误后再全量。回滚方案必须预先准备好并且一键触发。6. 结尾的思考多轮对话的上下文边界在哪“coze”工作流让我们能稳定高效地处理大部分客服场景。但有一个问题我们仍在探索多轮对话的上下文应该记住多少记住多久比如用户一小时前咨询了订单A现在又来问订单B系统是否应该主动关联用户的历史信息如果用户连续问了10个不同的问题上下文窗口会不会太大导致AI模型性能下降或出现“注意力分散”更进一步当对话轮数非常多时是应该用更复杂的记忆网络Memory Network来提炼关键信息还是简单地只保留最近N轮对话这不仅仅是技术问题更关乎用户体验和产品设计。我们目前采取的是分层上下文策略短期上下文最近5轮对话完整保存长期关键信息如用户ID、最近的主要订单号作为“用户档案”单独存储和索引在需要时主动注入。但这个边界如何划分得更智能或许将是下一代对话系统需要解决的核心问题之一。以上就是我们在构建“coze”智能客服机器人工作流中的一些实践和思考。架构没有银弹最适合自己业务场景的才是最好的。希望这篇笔记能对你有所帮助也欢迎一起交流探讨。