1. 项目缘起当AI决策需要一双“人眼”时最近在折腾一个基于Spring AI Alibaba的智能客服项目遇到了一个挺典型的问题。我们让AI模型去处理用户的工单分类和初步回复效果在大部分情况下都还不错。但有一次一个用户输入了“我的订单显示已发货但物流三天没更新了而且我地址填错了能改吗”AI的回复是“您好物流停滞问题建议您联系快递公司查询。地址修改请在订单发货前操作。” 这个回复从技术上看它识别出了“物流”和“地址”两个关键词并给出了标准答案。但从业务角度看它完全搞错了重点和优先级——用户的核心诉求是“地址填错”这个紧急且需要人工介入的异常而“物流停滞”可能只是地址错误导致的表象。AI把两个问题割裂处理给出了一个正确但无用的答案。这就是纯粹自动化AI的局限性它缺乏对复杂、模糊或高价值场景的上下文理解和责任判断。如果让这个回复直接发给用户轻则体验糟糕重则可能导致用户流失或产生客诉。于是“Human-in-the-Loop”人机回环简称HITL就成了我们必须引入的架构模式。这不是说AI不行恰恰相反是为了让AI在关键环节变得更可靠、更负责任把机器的效率与人类的判断力结合起来。Spring AI Alibaba作为一套整合了阿里云灵积等大模型能力的框架为我们实现这种模式提供了非常优雅的支撑点。今天我就结合实战聊聊如何在Spring AI Alibaba项目中系统性地设计和落地HITL让AI真正成为业务得力的“副驾驶”而不是一个可能闯祸的“自动驾驶”。2. 理解HITL不止是“审核一下”那么简单很多人一听HITL第一反应就是“加个审核流程”。这没错但太片面了。HITL是一个系统性的设计哲学核心思想是在AI系统的关键决策点上引入人类的监督、纠正或指导并将这些人类反馈重新注入系统用于改进后续的AI表现。在Spring AI Alibaba的上下文中我们可以把它拆解为几个层次。2.1 HITL的三种核心介入模式根据介入的时机和主动性HITL通常有三种模式我们需要根据业务场景灵活选用或组合。2.1.1 被动介入审核与纠正这是最常见的形式即AI先给出输出再由人类进行审核。适用于结果影响重大、容错率低的场景。比如内容安全AI生成的营销文案、客服回复需要确保无违规、无歧义。关键决策AI对贷款申请的初步风险评估、对医疗影像的辅助诊断建议。法律合规AI起草的合同条款、生成的专利摘要。在Spring AI Alibaba中这意味着我们需要在ChatClient或PromptTemplate调用之后不是直接将结果返回给前端或下游系统而是将其送入一个待审核队列可以是数据库表、消息队列等并触发一个审核任务如通知运营人员的企业微信/钉钉机器人。2.1.2 主动介入引导与约束在AI生成过程开始前或进行中人类就提供明确的指令、范例或边界条件。这能极大提升AI输出的相关性和质量。例如复杂任务分解人类先将一个“写一份季度市场分析报告”的复杂任务分解为“分析行业趋势”、“对比竞争对手Q1动-作”、“总结我方销售数据”、“提出下季度建议”四个子任务再让AI分步执行。提供参考信息在让AI总结一份会议纪要前人类先提供关键参会人名单、核心议题列表。设定输出格式明确要求AI以JSON格式输出包含title,summary,action_items等字段。Spring AI Alibaba的PromptTemplate和SystemMessage是实现主动介入的利器。我们可以设计动态的Prompt将人类提供的约束条件来自前端表单或上一次交互的上下文作为变量注入。2.1.3 协同介入混合倡议这是一种更高级的模式AI和人类在同一个界面上协同工作交替贡献。AI可以实时补全代码、建议下一句话人类则可以随时修改、接受或拒绝AI的建议。这更像是“结对编程”或“协同编辑”。虽然Spring AI Alibaba主要关注服务端交互但我们可以通过流式响应Streaming Response配合前端实现类似体验。例如AI流式生成客服回复时客服人员可以在中途输入新的指令进行引导。2.2 为什么Spring AI Alibaba适合做HITLSpring AI Alibaba不是一个孤立的AI模型调用包它是Spring生态的一部分这带来了几个天然优势声明式客户端与AOP支持ChatClient可以被Spring AOP轻松切面环绕。我们可以写一个Around切面在call()方法执行前后无缝插入审核逻辑、日志记录和反馈收集业务代码几乎无侵入。完善的上下文管理通过Conversation、Message等抽象可以轻松维护多轮对话的上下文。这对于HITL至关重要因为人类的纠正反馈需要和原始的AI请求上下文关联起来用于后续的模型微调或Prompt优化。与Spring生态无缝集成审核队列可以用Spring Data JPA管理审核通知可以用Spring Integration或消息模板发送任务调度可以用Spring Scheduler或Quartz。整个HITL工作流可以借助Spring State Machine或Flowable这样的流程引擎来编排实现状态管理如已生成-待审核-审核通过/驳回-已修正。多模型路由与降级Spring AI的ChatClient抽象允许我们配置多个模型连接如通义千问、DeepSeek等。在HITL场景下如果主模型对某个问题置信度低可以通过模型返回的metadata判断部分模型支持可以自动路由到备用模型进行“二次会诊”如果置信度依然不高则直接提升给人工处理。3. 实战架构构建一个可落地的HITL系统光有概念不够我们直接来看一个为智能客服场景设计的、基于Spring AI Alibaba的HITL系统架构。这个架构包含了从AI调用到人工干预再到反馈学习的完整闭环。[用户请求] - [Spring MVC Controller] | v [Service层: HITL Orchestrator] | /----------|----------\ | | v v [AI处理管道] [人工审核后台] (ChatClient Prompt) (Web UI) | | v v [结果置信度] [人工审核/修正] | | \----------|----------/ | v [决策路由器 (Router)] / | \ / | \ v v v [直接回复] [修正后回复] [请求人工客服] (高置信度) (人工修正) (低置信度/复杂) | v [反馈学习循环] (存储交互数据用于优化)3.1 核心领域模型设计首先我们需要设计数据库表来支撑这个流程。这里简化出几个核心实体-- AI交互请求记录表 CREATE TABLE ai_interaction ( id BIGINT PRIMARY KEY AUTO_INCREMENT, session_id VARCHAR(64) NOT NULL, -- 会话ID user_input TEXT NOT NULL, -- 用户原始输入 prompt_used TEXT, -- 实际使用的Prompt模板及变量 model_name VARCHAR(50), -- 使用的模型如 qwen-turbo ai_raw_response TEXT, -- AI原始响应 confidence_score DECIMAL(3,2), -- 置信度分数 (如果模型提供) status VARCHAR(20) DEFAULT PENDING, -- 状态: PENDING, AUTO_APPROVED, NEED_REVIEW, HUMAN_REVISED, REJECTED created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, INDEX idx_status (status), INDEX idx_session (session_id) ); -- 人工审核任务表 CREATE TABLE human_review_task ( id BIGINT PRIMARY KEY AUTO_INCREMENT, interaction_id BIGINT NOT NULL, -- 关联的AI交互记录 reviewer_id VARCHAR(50), -- 审核人ID review_result TEXT, -- 审核意见/修正后的内容 review_action VARCHAR(20), -- 动作: APPROVED, MODIFIED, REJECTED reviewed_at TIMESTAMP, FOREIGN KEY (interaction_id) REFERENCES ai_interaction(id) ); -- 反馈学习数据表 (用于后续的Prompt优化或微调) CREATE TABLE feedback_learning ( id BIGINT PRIMARY KEY AUTO_INCREMENT, interaction_id BIGINT NOT NULL, original_input TEXT, original_ai_output TEXT, final_correct_output TEXT, -- 最终正确的输出可能是AI的也可能是人修的 feedback_type VARCHAR(20), -- 类型: CORRECTION, CONFIRMATION, REJECTION used_for_training BOOLEAN DEFAULT FALSE, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );3.2 实现HITL编排器Orchestrator这是我们系统的“大脑”。它负责协调整个流程。我们将其实现为一个Spring Service。Service Slf4j public class HitlOrchestratorService { Autowired private ChatClient chatClient; // Spring AI Alibaba 的 ChatClient Autowired private AiInteractionRepository interactionRepo; Autowired private HumanReviewTaskRepository reviewTaskRepo; Autowired private NotificationService notificationService; Value(${ai.confidence.threshold:0.8}) private double confidenceThreshold; Transactional public ProcessResult processUserQuery(String sessionId, String userInput) { // 1. 构建Prompt这里可以加入主动介入的要素比如从会话历史中提取约束 Prompt prompt new Prompt(new UserMessage(userInput)); // 可以添加SystemMessage来约束AI行为 // Prompt prompt new Prompt(Arrays.asList(new SystemMessage(你是一个专业的客服助手...), new UserMessage(userInput))); // 2. 调用AI ChatResponse response chatClient.call(prompt); String aiRawResponse response.getResult().getOutput().getContent(); // 3. 解析置信度 (假设模型返回的metadata中包含) // 注意并非所有模型/API都返回置信度这里需要根据实际API响应调整 Double confidence extractConfidence(response); // 4. 保存交互记录 AiInteraction interaction new AiInteraction(); interaction.setSessionId(sessionId); interaction.setUserInput(userInput); interaction.setAiRawResponse(aiRawResponse); interaction.setConfidenceScore(confidence); interaction.setModelName(qwen-plus); // 实际从配置或路由中获取 interaction.setStatus(AiInteractionStatus.PENDING); interaction interactionRepo.save(interaction); // 5. 基于置信度的路由决策 if (confidence ! null confidence confidenceThreshold) { // 高置信度自动通过 interaction.setStatus(AiInteractionStatus.AUTO_APPROVED); interactionRepo.save(interaction); return ProcessResult.autoApproved(aiRawResponse); } else { // 低置信度或无法判断需要人工审核 interaction.setStatus(AiInteractionStatus.NEEDS_REVIEW); interactionRepo.save(interaction); // 创建审核任务 HumanReviewTask task new HumanReviewTask(); task.setInteractionId(interaction.getId()); reviewTaskRepo.save(task); // 发送通知例如到钉钉群 notificationService.sendReviewAlert(interaction.getId(), userInput, aiRawResponse); return ProcessResult.needReview(interaction.getId(), 已提交人工审核请稍候); } } private Double extractConfidence(ChatResponse response) { // 这是一个示例实际需根据阿里云灵积API返回的metadata结构解析 // 例如 response.getMetadata().get(confidence) // 如果API不提供可以尝试其他方法如使用一个轻量级模型对答案进行二次评分 return null; // 暂时返回null表示不启用置信度路由 } }3.3 实现人工审核后台与反馈闭环审核后台可以是一个简单的内部管理系统。当审核员打开任务他看到的是原始的userInput和aiRawResponse他可以选择通过直接采用AI的回答。修改在AI回答的基础上进行编辑。驳回AI回答完全不可用需要转给人工客服或重新生成。审核完成后后端服务需要更新状态并将最终结果返回给用户。同时最关键的一步是将这次纠正记录到feedback_learning表。Service public class ReviewService { Transactional public void completeReview(Long taskId, Long reviewerId, String revisedResponse, ReviewAction action) { HumanReviewTask task reviewTaskRepo.findById(taskId).orElseThrow(); AiInteraction interaction interactionRepo.findById(task.getInteractionId()).orElseThrow(); task.setReviewerId(String.valueOf(reviewerId)); task.setReviewResult(revisedResponse); task.setReviewAction(action); task.setReviewedAt(LocalDateTime.now()); reviewTaskRepo.save(task); // 更新交互记录状态 if (action ReviewAction.APPROVED) { interaction.setStatus(AiInteractionStatus.HUMAN_APPROVED); } else if (action ReviewAction.MODIFIED) { interaction.setStatus(AiInteractionStatus.HUMAN_REVISED); interaction.setFinalResponse(revisedResponse); // 保存最终回复 } else { interaction.setStatus(AiInteractionStatus.REJECTED); } interactionRepo.save(interaction); // 记录反馈学习数据 if (action ReviewAction.MODIFIED || action ReviewAction.REJECTED) { FeedbackLearning feedback new FeedbackLearning(); feedback.setInteractionId(interaction.getId()); feedback.setOriginalInput(interaction.getUserInput()); feedback.setOriginalAiOutput(interaction.getAiRawResponse()); feedback.setFinalCorrectOutput(revisedResponse ! null ? revisedResponse : [REJECTED]); feedback.setFeedbackType(action ReviewAction.MODIFIED ? CORRECTION : REJECTION); feedbackLearningRepo.save(feedback); } // TODO: 通知网关或前端审核已完成可以推送最终结果给用户 } }4. 进阶策略让HITL更智能、更高效基础的审核流程搭建好后我们会发现如果所有低置信度的请求都走人工审核人员的压力会很大。我们需要让HITL本身也“智能”起来减少不必要的介入。4.1 基于规则和分类的预过滤在调用大模型之前先用简单的规则或轻量级文本分类模型过滤掉明显不需要AI处理或必须人工处理的情况。Component public class RequestPreFilter { public FilterResult filter(String userInput) { // 规则1包含敏感词 - 直接转人工 if (containsSensitiveWords(userInput)) { return FilterResult.directToHuman(包含敏感内容); } // 规则2简单问候/感谢 - 固定回复不走AI if (isSimpleGreeting(userInput)) { return FilterResult.cannedResponse(您好很高兴为您服务); } // 规则3意图明确为“转人工” - 直接转 if (userInput.contains(转人工) || userInput.contains(找真人)) { return FilterResult.directToHuman(用户明确要求); } // 可以用一个简单的本地分类模型如FastText判断问题领域 // String domain lightweightClassifier.predict(userInput); // if (complex_refund.equals(domain)) { return FilterResult.directToHuman(复杂售后问题); } return FilterResult.proceedToAI(); // 通过过滤交给AI } }4.2 动态置信度阈值与分级审核不要用一个固定的置信度阈值如0.8。可以根据问题类型、用户价值、时间成本动态调整。高风险领域如金融建议、医疗咨询阈值设为0.95几乎全部审核。常规问答产品信息、操作指南阈值设为0.7。夜间模式凌晨时段审核人员少可以适当提高自动通过阈值或只将极高风险问题转人工其余先由AI回复并标注“答案仅供参考白天将由人工确认”。4.3 利用反馈数据迭代优化feedback_learning表是金矿。定期比如每周分析这些数据Prompt工程优化如果发现AI在某一类问题上如“地址修改”频繁被纠正可以针对性优化Prompt。例如在System Message中强调“当用户同时提到多个问题时优先处理需要人工介入的异常或变更类请求。”构建拒绝分类器用被REJECTED的数据作为负样本被APPROVED的数据作为正样本训练一个二分类模型。这个模型可以在AI调用前运行预测当前请求被人工拒绝的概率如果概率过高直接跳过AI节省成本并提升体验。少样本学习从MODIFIED的数据中提取user_input, corrected_response对作为few-shot examples在下一次类似的Prompt中注入直接提升AI表现。// 示例优化后的Prompt构建注入历史修正案例 public Prompt buildPromptWithFewShot(String currentInput, ListFeedbackLearning similarPastCorrections) { ListMessage messages new ArrayList(); messages.add(new SystemMessage(你是一个客服助手。以下是一些正确回答的示例)); for (FeedbackLearning fb : similarPastCorrections) { messages.add(new UserMessage(fb.getOriginalInput())); messages.add(new AssistantMessage(fb.getFinalCorrectOutput())); } messages.add(new UserMessage(currentInput)); return new Prompt(messages); }5. 踩坑实录HITL实践中必须避开的雷区在实际部署HITL系统的过程中我们遇到了不少坑这里分享几个关键的希望能帮你省点时间。5.1 状态一致性与并发问题审核流程涉及多张表的状态变更ai_interaction,human_review_task并且前端可能轮询状态。必须保证在一个数据库事务内完成状态更新和相关记录的创建避免出现“任务创建了但状态没更新”的中间状态。我们曾因为Transactional注解使用不当导致部分情况下审核任务通知发出了但数据库状态回滚审核员点进链接找不到任务。解决方案确保Orchestrator和ReviewService中的核心方法都有明确的Transactional注解并仔细检查方法内是否有非受检异常RuntimeException被捕获而未抛出这会导致事务无法回滚。5.2 审核时效性与用户体验用户提问后如果进入审核队列不能让他无限期等待。我们最初的设计是“审核完成才回复”导致一些简单但被误判的问题让用户等了十几分钟体验极差。解决方案引入“异步响应”机制。当请求进入审核时立即给用户一个友好提示“您的问题比较复杂正在为您加急处理请稍等片刻通常1-5分钟。” 同时在审核后台高亮显示等待时间。可以为审核任务设置SLA如5分钟超时未处理则自动升级如通知主管或先由一个降级策略如返回一个更保守的AI答案并注明“答案待确认”来响应。5.3 反馈数据的质量与清洗不是所有的人工修改都是“正确”的。审核人员水平参差不齐有时会引入拼写错误或者把原本正确的AI答案改错。如果盲目地将所有MODIFIED数据都用于训练会污染模型。解决方案双人复核对于用于训练数据的关键修正可以要求二级复核。数据评分让审核员在修正时对AI原答案的“错误程度”和自身修正的“把握度”进行简单评分如1-5星。优先采用高把握度的修正数据。定期抽样审计算法或团队负责人定期抽样检查feedback_learning中的数据质量及时剔除错误样本。5.4 Spring AI Alibaba客户端配置与超时当引入HITL后AI调用可能处于一个同步链路上先等AI结果再判断是否审核。如果AI服务响应慢或超时会阻塞整个用户请求。我们在压力测试时就遇到了因模型端延迟导致的线程池耗尽。解决方案合理设置超时在配置ChatClient如AlibabaDashScopeChatClient时务必设置连接超时和读取超时。spring: ai: alibaba: dashscope: chat: options: connect-timeout: 5s read-timeout: 30s # 根据模型复杂度调整异步化AI调用对于非实时性要求极高的场景可以考虑将AI调用也异步化。用户请求进来后立即返回“正在处理中”然后通过消息队列触发后台的AI处理和HITL流程处理完毕后再通过WebSocket或推送通知用户。这大大提升了系统的吞吐量和响应韧性。6. 效果衡量与未来展望引入HITL后不能光凭感觉需要用数据说话。我们建立了几个核心指标AI直接采纳率(AUTO_APPROVED) / TOTAL_REQUESTS。这个比率会随着Prompt优化和模型迭代逐步上升是我们的核心优化目标。人工修正率(HUMAN_REVISED) / NEEDS_REVIEW。反映了AI在“存疑问题”上的可修正性修正率越低说明AI在边界问题上的表现越好。平均审核时间AHT从任务创建到审核完成的时间。关乎运营成本和用户体验。用户满意度CSAT对比引入HITL前后相同渠道的用户满意度调查分数变化。经过两个月的运行我们的AI直接采纳率从初期的65%提升到了82%人工修正率从40%下降到了15%。更重要的是由于拦截了可能出错的回答关于“AI答非所问”的投诉下降了90%。HITL不是终点而是一个让AI系统安全、稳健成长的“训练轮”。随着反馈数据的积累和模型的迭代我们期望需要人工介入的场景会越来越少但介入的机制会永远存在作为系统最后也是最重要的安全阀。Spring AI Alibaba提供的灵活性和Spring生态的完整性让这套机制的实现变得清晰而高效。最终我们构建的不是一个替代人的AI而是一个增强人、与人协同的智能系统。