为什么要写这个系列做Java后端十年我接触过不少企业的核心系统。金融、电商、政务——行业不同但底层的现状惊人地相似生产系统还在Java 8框架停在Spring Boot 2.x甚至更早代码跑了很多年没人敢轻易动。去年开始几乎每个项目都在谈接AI。但真正动手的时候团队就卡住了。不是因为不懂大模型而是老系统本身接不住。JDK版本不够Spring AI引不进来依赖树牵一发动全身升级一个包怕带崩一片生产流量压着不敢拿主流程赌一个AI试点。更危险的是硬塞。我见过团队在老系统的Service层直接new一个HttpClient调模型APIPrompt拼在业务代码里超时没配、降级没有。模型响应慢的时候老系统的订单查询线程池被占满主流程跟着卡住。还有团队把用户手机号、身份证原样送进Prompt过了两个月才被安全审计发现。这种事见多了我就开始想一个问题老系统不具备直接接入AI的条件这是不是大多数企业的常态答案是肯定的。而且这不应该成为接不了AI的理由。核心思路其实就三条老系统少改 —— 不升级 JDK不引入 Spring AI 依赖 AI 能力旁路 —— 独立部署老系统通过 HTTP 或 MQ 调用 企业边界先行 —— 脱敏、审计、降级、幂等比模型调用更重要这个系列就是把这三条线展开成10讲。从AI Gateway到MCP工具中心从SQL Agent到RAG知识库从工单Agent到多Agent研发团队——每一讲都围绕同一个前提你的老系统还在跑Java 8你不能为了AI去赌它的稳定性。每讲配套一个可运行的Maven Lab不讲空架构不写Hello World。你跑得通Demo看得到边界拿得到代码。这就是我做这个系列的原因。Java 8老系统AI工单助手实战先做推荐不要一上来自动派单企业上AI工单第一反应往往是能不能让AI自动处理 能不能让AI自动派单 能不能让AI直接闭环听起来很爽做起来很惨。自动闭环意味着AI对结果负责。在客服场景里这意味着AI直接决定派谁、修不修、退不退钱——每一步都是客户体验的雷区。一旦出错客户投诉升级企业没有回退路径。更稳的第一步是让AI做工单助手不是工单执行者。具体来说AI 摘要问题 → 判断分类 → 识别优先级 → 发现 SLA 风险 → 推荐处理人 → 等待人工确认 → 派单执行AI在这个链路里是提效工具不是决策主体。这是企业AI落地的第一道安全门。工单助手在架构里的位置MCP Tool Center的第一个真实出口第2讲搭了MCP Tool Center——把老系统的能力标准化成MCP工具让AI Agent调用。工单助手就是这个架构的第一个真实出口不是Demo是生产级旁路。老系统工单事件CRM / 呼叫中心 / 售后系统 ↓ MCP Tool Center 推送 TicketEvent ↓ TicketAgentService 分析 ↓ 分类 / 优先级 / SLA风险 / 推荐处理人 ↓ AssignmentConfirmationService 等待人工确认 ↓ 派单执行回写到工单系统注意这里没有直接连老系统的数据库所有交互通过MCP Tool Center的标准事件通道走。这是第2讲就定好的旁路原则老系统不动AI能力嫁接进来。代码结构src/main/java/com/ynzz/lab/chapter07/agent/ ├── TicketAgentService ← 主流程事件 → 分析 → 推荐 ├── TicketClassifier ← 分类PAYMENT / ORDER_DELIVERY / GENERAL ├── TicketPriorityPolicy ← 优先级HIGH / MEDIUM / LOW SLA风险判断 ├── TicketMaskingService ← 脱敏手机号、地址等敏感字段 ├── AssignmentPolicy ← 处理人推荐 推荐理由 ├── AssignmentConfirmationService ← 人工确认后才实际派单 └── TicketAuditService ← 审计日志 src/main/java/com/ynzz/lab/chapter07/common/ ├── TicketEvent ← 输入事件 └── TicketAnalysisResult ← 输出结果含状态枚举 src/main/java/com/ynzz/lab/chapter07/policy/ └── AssigneeRecommendation ← 推荐结构体assignee reason主入口是TicketAgentService.analyze(event)它编排全流程但不执行派单——派单是AssignmentConfirmationService.confirm()的职责必须带confirmedBy参数。核心逻辑一TicketClassifier关键词规则分类classify(title: String, content: String): TicketCategory完整规则表关键词title或content命中条件分类结果Demo命中情况“支付”或”未支付”包含任一关键词PAYMENT工单1标题含”支付”和”未支付” ✅“发货”或”物流”或”延迟”包含任一关键词ORDER_DELIVERY工单2标题含”延迟”内容含”发货” ✅其他无上述关键词GENERAL咨询类、投诉类、降级工单等为什么要用关键词而不是模型企业内部工单场景关键词规则有三个不可替代的优势可审计分拣逻辑写在代码里业务负责人能review。模型分类你没法解释”为什么这个工单进了支付类”。可配置运营人员看懂”包含支付进支付组”比看懂prompt engineering容易一百倍。稳定不受模型版本漂移影响同一个工单三个月前后分类结果一致。关键词规则做底座模型做增强——这是企业落地的标准路径。核心逻辑二TicketPriorityPolicy优先级与SLA风险priorityOf(category: TicketCategory, content: String): TicketPriority hasSlaRisk(priority: TicketPriority, content: String): Boolean优先级规则表条件优先级说明category PAYMENTHIGH资金状态风险涉及订单状态机客诉升级概率高content 包含”三天”或”延迟”MEDIUM可能触发履约SLA不处理会升级其他LOW普通咨询先进通用服务台消化SLA风险判断表条件slaRisk说明priority HIGHtrue高优先级工单本身SLA时限紧张content 包含”三天”true“三天”是SLA触发阈值——用户明确感知了履约超时设计细节”三天”是硬编码在规则里的数字阈值。不是说AI自己理解”三天很紧急”而是把业务规则翻译成了一条if条件。这比让模型自由发挥稳定一百倍。优先级不是情绪化等级是业务触发条件。核心逻辑三AssignmentPolicy处理人推荐与理由recommend(category: TicketCategory, priority: TicketPriority): AssigneeRecommendation推荐规则表分类推荐处理人推荐理由PAYMENTpay-team-lisi支付团队值班人员具备支付回调和订单状态对账经验ORDER_DELIVERYorder-team-zhangsan订单履约团队值班人员熟悉仓库出库和物流状态排查GENERALservice-desk通用服务台先接收判断是否升类真实项目的演进路径硬编码 → 值班表配置值班人轮流换 → 技能标签匹配谁处理过同类工单谁优先 → 历史数据加权谁处理得快、评价高谁冒出来每一步都可以独立演进不是一上来就做大模型匹配。核心逻辑四TicketAgentService主流程顺序analyze(event: TicketEvent)的调用链TicketEvent ↓ ① TicketMaskingService.mask() ← 脱敏原文 ↓ ② TicketClassifier.classify() ← 分类 ↓ ③ TicketPriorityPolicy.priorityOf() ← 优先级 ↓ ④ TicketPriorityPolicy.hasSlaRisk() ← SLA风险 ↓ ⑤ AssignmentPolicy.recommend() ← 推荐处理人 ↓ ⑥ TicketAuditService.record() ← 审计记录 ↓ TicketAnalysisResult status WAITING_FOR_HUMAN_CONFIRMATION为什么是这个顺序① 脱敏必须排第一。工单内容里有手机号、地址、订单号。这些字段进模型之前要先脱敏否则就是合规风险。脱敏后生成maskedFields列表告诉后续环节”哪些字段被动过”。② 分类在优先级之前。优先级规则依赖分类结果——PAYMENT类直接HIGH不依赖内容。分类错了优先级必然错整个链路都歪。③ 优先级在SLA之前。SLA风险判断依赖优先级字段HIGH优先级天然带SLA风险。如果把这两步反过来就没法利用优先级这个中间结果。④ 推荐在最后。推荐处理人需要同时看分类和优先级——同是HIGH优先级支付类进支付组履约类进履约组不能只看优先级。⑤ 审计在最后。审计记录要一次性写入包含分类结果、优先级、SLA风险、推荐处理人全量信息。不是每步单独写那样审计记录是碎片化的。这个顺序是因果依赖倒推出来的。把顺序写清楚规则链就是可解释、可调试、可让业务负责人review的。两个Demo工单完整推导工单一用户支付成功但订单仍显示未支付输入ticketId T202606050001 title 用户支付成功但订单仍显示未支付 content 用户反馈 10:32 已支付订单号 O202606050001后台仍显示 CREATED手机号 13800000000。 source customer-service逐步命中规则步骤执行逻辑命中的规则输出① 脱敏检测手机号正则 1[3-9][0-9]{9}TicketMaskingServicemaskedFields[mobile]13800000000 → 1**********② 分类title content 扫描关键词命中”支付”“未支付”categoryPAYMENT③ 优先级priorityOf(PAYMENT, content)categoryPAYMENT → HIGHpriorityHIGH④ SLA风险hasSlaRisk(HIGH, content)priorityHIGH → slaRisktrueslaRisktrue⑤ 推荐recommend(PAYMENT, HIGH)PAYMENT → pay-team-lisirecommendedAssigneepay-team-lisi⑥ 审计记录全量字段TicketAuditService.record()auditIdxxx结果不派单规则statusWAITING_FOR_HUMAN_CONFIRMATION最终输出{ ticketId: T202606050001, category: PAYMENT, priority: HIGH, slaRisk: true, recommendedAssignee: pay-team-lisi, recommendationReason: 支付团队值班人员具备支付回调和订单状态对账经验, assignmentStatus: WAITING_FOR_HUMAN_CONFIRMATION, maskedFields: [mobile] }工单二用户咨询订单延迟发货输入ticketId T202606050002 title 用户咨询订单延迟发货 content 用户说订单已经三天没有发货希望确认仓库进度。 source customer-service逐步命中规则步骤执行逻辑命中的规则输出① 脱敏content扫描敏感字段无手机号/地址maskedFields[]② 分类title content扫描关键词命中”延迟”“发货”categoryORDER_DELIVERY③ 优先级priorityOf(ORDER_DELIVERY, content)命中”三天”“延迟”priorityMEDIUM④ SLA风险hasSlaRisk(MEDIUM, content)命中”三天”slaRisktrue⑤ 推荐recommend(ORDER_DELIVERY, MEDIUM)ORDER_DELIVERY → order-team-zhangsanrecommendedAssigneeorder-team-zhangsan⑥ 审计记录全量字段TicketAuditService.record()auditIdxxx结果不派单规则statusWAITING_FOR_HUMAN_CONFIRMATION两个工单对比字段工单1支付异常工单2履约延迟categoryPAYMENTORDER_DELIVERYpriorityHIGHMEDIUMslaRisktruetruerecommendedAssigneepay-team-lisiorder-team-zhangsanmaskedFields[mobile][]assignmentStatusWAITING_FOR_HUMAN_CONFIRMATIONWAITING_FOR_HUMAN_CONFIRMATION两个工单都是WAITING_FOR_HUMAN_CONFIRMATION——这才是Demo的核心信息。AI算完了但不自己动手。为什么人工确认后才能派单这是架构里最容易被挑战的地方AI分析了半天为什么不能直接派单① 责任边界必须清晰。AI推荐处理人人工确认处理人最后派单的是系统。出问题回溯链路清楚AI给了推荐人工做了决策系统执行了指令。如果AI直接派单”是AI派的”——这个责任模型在企业里没有买单方。② 推荐准确率有上限场景有边界。Demo规则引擎覆盖了三个分类。但真实工单里有大量模糊场景用户描述混乱、同时涉及多个问题、用户情绪化表达等。AI分类准确率80%已经很高但那20%落在高优先级工单上就是投诉和资损。③ 人工确认是信任建立机制不是效率瓶颈。客服主管看了一眼分类和推荐点一下确认3秒钟。但这个动作让他知道系统干了什么建立了信任。第一阶段人工确认第二阶段低风险自动派单试点第三阶段扩大范围——这是企业接受AI的标准路径。AssignmentConfirmationService.confirm()的签名设计public TicketAnalysisResult confirm(String ticketId, String confirmedBy)必须传confirmedBy——谁确认的什么时候确认的。这条记录进了审计日志是合规追溯的依据。企业避坑坑一让AI自动关闭工单。关闭工单意味着客户问题被宣告”已解决”但如果客户还在投诉自动关闭会直接触发客诉升级。关闭动作必须保留人工审核节点或者接入知识库标准答案 客户确认短信双验证。坑二高优先级工单不经人工确认直接派单。HIGH优先级工单往往是SLA违约窗口期最短的那类。派错人比派慢了的损失更大。高优先级必须走人工确认这是铁律。坑三工单原文裸给模型。手机号、地址、订单号、身份证号在工单里是高频出现字段。这些字段进模型之前必须脱敏否则有数据合规风险。脱敏要覆盖工单的title和content两个字段不能只处理content。坑四推荐不输出理由。recommend()方法必须返回AssigneeRecommendation含assignee reason不能只返回一个处理人ID。没有理由工单分发记录就是黑盒团队无法review和优化。坑五跳过审计日志。每个工单的分析结果、分类决策、人工确认记录必须完整落库。这不只是合规要求也是后续迭代规则引擎的数据基础——你得知道AI分类错了多少次、哪个分类规则命中率最低。从Demo到落地四条工程路径① SLA规则引擎当前Demo的SLA风险判断是硬编码Stub真实项目需要接入SLA配置表SLA配置表优先级 × 客户等级 × 工单类型 → 不同组合对应不同的响应时限和升级规则 → 超时自动触发升级通知 提升优先级 → 业务人员可维护的配置不是代码里的 if-else② 历史相似工单RAG第6讲知识库延伸新工单进来时基于embedding检索相似历史工单的处理方案新工单 → embedding → 向量检索 ↓ Top-3 相似历史工单 ↓ 处理方案摘要 历史处理人 客户评价 ↓ 一并推给当前处理人这条链路的ROI很高处理同类问题的重复时间大幅减少新人上手速度提升历史高评价方案被复用而不是每次重新探索。③ 自动派单门槛设计不是所有工单都要人工确认要设计一个门槛规则自动派单试点的准入条件 ✓ 分类 GENERAL ✓ 优先级 LOW ✓ 知识库命中标准答案置信度 0.9 ✓ 非首次咨询避免用户换人引发不满 ✓ 推荐处理人的历史确认率 95%团队信任度门槛这五条都命中才开启自动派单试点。开了试点也要有监控仪表盘自动派单准确率、人工干预率、客户满意度三个数字每周review。④ 工单系统集成支持的主流工单系统 飞书工单Feishu / Lark 钉钉工单 企业微信工单 JIRA Service Management 自研工单系统通过 Webhook / API集成的核心是MCP Tool Center的双向通道接收工单事件、分析、回写处理结果到工单系统。飞书/钉钉场景下回写结果可以直接推送消息给处理人体验闭环。小结工单AI落地不是一上来就”全自动处理”而是工单事件MCP 推送 ↓ 脱敏手机号 / 地址 / 身份证 ↓ 摘要 分类 优先级 SLA 风险 ↓ 推荐处理人 推荐理由 ↓ 审计记录 ↓ 人工确认或低风险自动派单 ↓ 派单执行这个链路里AI是提效工具不是决策主体。分类靠规则优先级靠业务定义推荐靠值班表——每一步都是显式的、可审计的、可让业务负责人负责的。真正的工程难度不在于让AI跑起来而在于把业务规则翻译成稳定可维护的代码并设计好人工确认的边界。这是企业AI落地和Demo的分水岭。AI 工单助手的目标不是替代客服主管而是让他从读原始文字、猜分类、查值班表里解放出来把精力放在真正需要判断的工单上。