## 01、痛点

“故障截图已经发你了，怎么还没处理？”老李在客服群里经常看到这句话。图片很清楚，错误码、时间、机器序列号都在，但工单系统里依然只有用户手打的一行“系统登不上”。截图只是附件，系统没有把图片里的信息变成可检索、可分类、可路由的内容。另一边，语音报障、拍照上传、巡检照片越来越多，研发团队却还在把多模态当玩具：演示里让模型认一张猫，现场却不敢让真实接口接收图片。

问题不在模型能力，而在接口设计。过去我们习惯的输入是纯文本，处理链路按文字走；现在手机、摄像头、录音笔带来的原始数据是图片和音频，如果不把它们纳入业务接口，模型再强也只是离线的娱乐工具。所以今天要讲的是，怎么用 Spring AI 的模型抽象，把图文、语音变成客服接口的一部分，而不是再做一个孤立的多模态演示。

## 02、是什么

Spring AI 官方的模型抽象覆盖六类能力：Chat、Embedding、Image Generation、Audio Transcription、Text-to-Speech、Moderation。注意，这里没有把“多模态”单独列成一个新的模型类型，而是把它融入到这些抽象里。也就是说，多模态不是一个开关，而是 Chat、Transcription 等能力对媒体输入的扩展。

以 Chat 为例，一条消息可以同时包含文本和多个媒体对象。媒体对象在 Spring AI 里通常叫 Media，它由二进制数据和 MIME 类型组成。调用方不需要关心图片到底如何编码，只需要把 Media 放进消息列表，适配器会根据供应商能力把它转成模型可接受的请求。音频转文字则走 Audio Transcription 抽象，文字转语音走 Text-to-Speech，内容审核走 Moderation。Embedding 也能处理文本或图像，取决于供应商。

关键点是：媒体不是被提前转成一段人工描述，而是作为原始上下文进入模型。这样图片里的错误码、颜色、位置、截图中的堆栈信息，都保留在输入中，而不是经过 OCR 或人工转写后被削弱。

## 03、为什么

为什么现在要把它接进业务流？因为过去很多业务在人工转换媒体数据，成本高、误差大、速度慢。客服接到报障，用户发一张截图，客服需要自己看、自己概括，再复制错误码进工单；设备巡检拍了照片，巡检员回办公室后再填表；保险理赔上传发票，审核员眼睛看、手录入。这些环节的共同点是：媒体是证据，但系统只把它当附件，信息进入业务系统之前必须经过人。

多模态模型让机器可以直接消费这些原始证据。输入即业务数据，不需要中间转录。这样不仅快，还减少了转述中的误差。工程上，Spring AI 把不同供应商的模型抽象成统一接口，避免每接一家厂商就重写一遍代码。业务方可以把精力放在接口设计和输出结构上，而不是供应商差异。

还有一点是合规与可追溯。媒体留在链路里，随时可以复核；模型给出的摘要、分类、标签，可以关联到原始截图或录音。审计时不是只看一段模型输出，而是能回到原始文件。

## 04、架构

整体架构可以分四层：业务接口层、Spring AI 抽象层、供应商适配层、模型能力层。业务接口接收文本、图片、音频，构造 UserMessage 和 Media；Spring AI 抽象层定义 ChatClient、TranscriptionClient、EmbeddingClient 等统一接口；适配层把统一对象翻译成各供应商的请求；能力层执行真实模型推理。

这里必须区分两个概念：Portable API 与 Provider Capability。Portable API 是你可以写的代码，它稳定、可移植，例如都通过 ChatClient 发起对话、都使用 Media 表示图片。但 Provider Capability 是某个供应商模型实际支持哪些输入。并不是所有 ChatModel 都支持同样的媒体和能力：有的模型接收图片和文本，但不接收音频；有的模型能转录音频，却不能在聊天上下文中直接理解声音；有的审核能力只能识别文本。这决定了你不能看到一个接口存在，就默认所有供应商都能处理所有媒体。

所以在架构上，需要为媒体类型做路由或降级。比如图片优先走支持视觉的 Chat 模型；音频先走 Transcription；如果某个供应商不支持图片，可以降级为文本加 OCR 摘要，或者在前置层拦截。不要把供应商能力当成全局能力，这是多模态落地最容易踩的坑。

## 05、实战

老李拿客服工单接口开刀。需求很直接：用户提交文字描述和故障截图，系统生成一段标准化问题描述，并提取问题类型、紧急度和关键字。后端用 Java 和 Spring AI，接口大致如下：

```java
@PostMapping("/ticket")
public TicketSummary createTicket(@RequestPart("description") String description,
                                  @RequestPart(value = "screenshot", required = false) MultipartFile screenshot) {
    Media media = new Media(MimeTypeUtils.IMAGE_PNG, screenshot.getBytes());
    UserMessage message = new UserMessage(description, List.of(media));
    String summary = chatClient.prompt(new Prompt(List.of(message))).call().content();
    return ticketService.create(description, summary, screenshot);
}
```

这里的重点是：截图不再只是存个附件路径，而是作为 Media 放进了消息列表，直接进入模型上下文。模型可以读到截图里的错误码，结合用户描述生成更准确的问题摘要。生成结果再写回工单系统，成为可检索字段。

接着再扩展一个语音转文字实验。客服场景里用户经常发语音报障，可以让接口接收一段音频，先转录成文字：

```java
TranscriptionResponse response = transcriptionModel.call(
        new TranscriptionRequest(Resource.from(audioBytes), "whisper-1"));
String voiceText = response.getResult().getOutput();
```

然后把 voiceText 当作文字描述，传入前面的 Chat 接口，配合截图一起生成问题描述。这样语音、文字、图片三种输入在同一套抽象里流转，不需要为每种媒体写单独的供应商接入。

实际落地时，输出最好不要自由文本，而是约定 JSON 字段，例如 problemType、priority、keywords。可以在输入里要求模型按字段输出，并在代码里解析成结构化对象。不同供应商对媒体输入的支持不同，开发前要先确认模型是否支持对应媒体，必要时在代码分支里做降级。

## 06、洞见

多模态真正的价值不是“模型能看图”，而是把过去必须人工转换的数据直接带入业务工作流。过去图片是附件，客服看、人工转录、错误码手敲进系统；现在图片进入消息上下文，成为分类、摘要、路由的原料。以前语音要听一遍再填表，现在直接进入转录和后续处理。业务链路中少了“人看、人听、人转写”的中间步骤，不是模型会看图，是图片终于被系统当作一等数据。

如果只做一个识别猫的演示，业务不会买单。真正有意义的是：哪些原本由人来看的媒体，能进入自动化工单、巡检、理赔、质检流程；模型的输出能不能写回业务库，变成字段、标签、工单备注；媒体本身能不能留档，形成可审计的证据链。技术上的多模态支持只是起点，流程重构才是杠杆。

另一个洞察是：多模态落地后，数据入口会变宽。用户不再被迫用文字描述问题，可以直接发图、发语音。这反过来要求接口设计更宽容，也要求后端对媒体类型、大小、格式、安全审核有统一约束。不要一放开媒体输入，就把安全审核和权限控制丢掉。

## 07、行动

第一步，选一个真实业务场景，加入图片输入。不要为了炫技单做演示。可以从客服工单、设备巡检、保险理赔、门店陈列检查里挑一个。选定后，找一个已经有文字输入的接口，增加一个可选图片字段。先让图片和文字一起进入模型，生成更完整的问题描述或分类。

第二步，定义模型输出结构，把结果写回业务系统。输出不要停留在聊天窗口里，要落到工单、巡检单、理赔单的字段中，这样才进入闭环。第三步，做供应商能力核对。记录哪些模型支持图片，哪些支持音频，哪些审核只能处理文本。第四步，小流量对比人工处理与模型处理，重点看漏识别、错分类、响应时间和成本。第五步，根据反馈调入口策略，例如什么情况下要求用户补图，什么情况下允许纯语音。

安全上，用户上传的图片和音频可能包含敏感信息，要做脱敏和内容审核，不能让媒体数据绕过原有合规流程。多模态上线不是替代客服或人工审核，而是把重复的转录和概括工作交给模型，让人处理异常和决策。

## 08、小结

Spring AI 把多模态能力放在统一模型抽象里，而不是独立演示项目。图片、音频作为 Media 进入消息上下文，Chat、Transcription、TTS、Moderation 各司其职。可移植 API 让代码稳定，但供应商能力各异，必须区分并做好降级。实战中客服接口同时接收文字和故障截图，生成结构化描述，语音还能先转文字再入 Chat。多模态的价值在于减少人工转换，让原始媒体直接进入业务工作流。下一步，选一个真实场景，加上图片输入，定义输出并小流量验证。

## 09、链接与概念说明

概念说明：

- Portable API：指应用通过统一接口编程，不绑定特定供应商。例如 ChatClient 的调用方式不变，但底层模型可以替换。
- Provider Capability：指具体供应商模型支持哪些输入和任务。例如是否支持图片进入 Chat、是否支持音频转录、审核是否覆盖图片。
- Media：Spring AI 中表示非文本数据的载体，通常包含二进制数据和 MIME 类型，可放入消息列表。
- Audio Transcription：语音转文字能力，把音频内容转换为文本。
- Text-to-Speech：文字转语音能力，把文本内容合成为音频。
- Moderation：内容审核能力，用于识别不安全或违规内容。

链接：Spring AI 官方项目地址为 spring.io/projects/spring-ai，具体 API 和版本差异以官方文档为准。

“故障截图已经发你了，怎么还没处理？”老李在客服群里经常看到这句话。图片很清楚，错误码、时间、机器序列号都在，但工单系统里依然只有用户手打的一行“系统登不上”。截图只是附件，系统没有把图片里的信息变成可检索、可分类、可路由的内容。另一边，语音报障、拍照上传、巡检照片越来越多，研发团队却还在把多模态当玩具：演示里让模型认一张猫，现场却不敢让真实接口接收图片。

《Spring AI 2.0实战》第5招 模型也能看图听声音

多模态的价值不在模型能看图，而在把图片、语音等原生数据直接接进业务工作流。本文用 Spring AI 做客服接口实战，并讲清可移植 API 与供应商能力差异。

架构师

编程语言

本文深入解析SpringAI如何将图片、音频等媒体数据整合进统一模型抽象，并作为核心业务接口。通过客服工单实战案例，展示多模态数据如何从孤立附件转变为可分类、可检索、可路由的一等数据，显著减少人工转录成本。同时强调供应商能力差异与降级策略，避免技术落地陷阱，为构建自动化处理工作流提供参考。

语音产品特惠新用户14.9元起


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Spring AI 2.0实战》第5招 模型也能看图听声音-腾讯云开发者社区-腾讯云

《Spring AI 2.0实战》第5招模型也能看图听声音

《Spring AI 2.0实战》第5招模型也能看图听声音

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring AI 2.0实战》第5招 模型也能看图听声音

《Spring AI 2.0实战》第5招 模型也能看图听声音

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring AI 2.0实战》第5招模型也能看图听声音

《Spring AI 2.0实战》第5招模型也能看图听声音