038. 聊天 Provider 与多模态视觉理解

学习目标

这一节让 AI 简历里的聊天助手真正接入模型，并支持图片输入。

学完后，你应该能理解：

• 为什么要自定义聊天 provider；
• 前端如何调用 OpenAI 兼容代理；
• 模型参数为什么要按平台区分；
• 多模态模型和视觉理解模型有什么区别；
• 图片消息可以用 base64 或网络地址；
• 保存聊天历史时为什么更适合保存图片 URL；
• 不保存历史时为什么可以直接用 base64；
• 聊天输入框如何支持选择和粘贴图片。

自定义聊天 provider

聊天组件本身需要一个 provider 来负责请求模型。

可以理解成：组件负责界面，provider 负责怎么发请求。

项目后端已经做了 OpenAI 兼容格式代理，所以前端 provider 只要把消息按 OpenAI 格式发到后端接口即可。

这样前端不用直接适配每个模型平台。

后端负责：

• 转发到百炼或其他平台；
• 处理平台差异；
• 返回组件能识别的格式。

固定模型和请求地址

早期可以先把模型和请求地址写死，保证流程跑通。

例如：

• 请求后端的 OpenAI 兼容代理；
• 固定某个模型；
• 开启流式输出；
• 关闭不需要的深度思考。

等聊天流程稳定后，再做模型下拉选择。

工程上经常先固定一条可运行链路，再逐步开放配置。

关闭深度思考

有些模型支持 enable_thinking 之类的参数。

如果当前任务只是普通编辑、提取或生成，深度思考可能没有必要。

关闭它可以：

• 减少 token 消耗；
• 提升返回速度；
• 避免输出额外思考过程；
• 让交互更像普通聊天。

但这个参数不是所有模型都支持。

不同平台、不同模型，参数名和支持范围都可能不一样。

兼容不同响应格式

后端接口不一定总是完全符合前端组件期待的格式。

有些后端开发者可能不知道 OpenAI 的响应规范，也可能漏掉某些字段。

前端 provider 需要做一定兼容。

例如某些字段不存在时，给一个默认值或做格式转换。

这样可以减少因为接口字段细节导致的聊天组件崩溃。

什么是多模态模型

多模态模型指的是能理解多种输入的模型。

输入可以包括：

• 文本；
• 图片；
• 音频；
• 视频。

这里说的是输入能力，不是输出能力。

能生成图片或视频的模型是另一类生成模型；多模态理解强调的是“能看、能听、能读”。

视觉理解模型

视觉理解模型可以看作多模态模型里的专科模型。

通用多模态模型像全科医生，能理解多种输入。

视觉理解模型更像眼科专家，专门处理图片和视频理解。

如果任务是识别图片内容、比较图片差异、提取截图文字，视觉理解模型通常更合适。

消息格式

发给模型的消息通常有不同角色。

常见角色包括：

• system；
• user；
• assistant；
• tool。

普通文本消息很简单。

多模态消息则需要在 user 消息里放入文本和图片内容。

图片内容可以是 base64，也可以是图片 URL。

base64 和图片 URL

图片输入有两种常见方式。

方式	特点
base64	不需要额外上传，适合临时对话
图片 URL	消息更轻，适合保存聊天历史

如果聊天历史不保存，直接用 base64 很方便。

用户刷新页面后消息就没了，也不需要维护图片文件。

如果聊天历史要保存，更推荐上传图片，保存图片 URL。

为什么保存历史时用 URL

如果把 base64 直接存进聊天历史，消息会非常大。

这会影响：

• 数据库存储；
• 历史加载速度；
• 前端渲染性能；
• 缓存效果。

如果保存图片 URL，历史消息里只需要存一个地址。

加载历史时，浏览器再按地址加载图片。

但这样也要管理图片生命周期。用户删除会话时，相关图片也可能需要清理。

base64 和 URL 都会消耗 token

无论用 base64 还是图片 URL，模型理解图片时都会产生消耗。

图片 URL 不是免费。

模型平台拿到 URL 后，也需要下载和处理图片内容。

所以选择 base64 还是 URL，主要看工程管理和历史保存需求，不是简单看 token 是否消耗。

改造聊天输入框

默认聊天输入框不一定支持图片。

需要改造它，让用户可以：

• 点击选择图片；
• 粘贴图片；
• 把图片加入待发送列表；
• 和文字一起发送；
• 发送后清空文件状态。

这一步本质上是把前面封装的文件选择、图片判断、base64 转换接进聊天组件。

视觉理解验证

接好图片后，可以用简单任务验证。

例如：

• 提取图片里的文字；
• 识别图片标题；
• 找出两张图的不同之处；
• 描述截图内容。

如果模型能根据图片回答，说明多模态消息格式已经跑通。

组件库还处在早期

AI 前端组件库虽然越来越流行，但很多封装还比较原始。

例如：

• 多模态支持不完善；
• 工具调用展示不完整；
• 和 LangGraph 的状态不兼容；
• 上下文和文件处理要自己补。

所以真实项目里，经常需要在组件库基础上继续封装。

AI 修改简历为什么费 token

让 AI 修改简历时，通常要把模板源码或相关上下文发给模型。

源码很长，所以 token 消耗会比较高。

这和普通表单审核、字段提取、排序配置不一样。

代码修改任务本身就更重，要预期它会消耗更多 token。

这一节的重点

这一节让聊天助手具备实际 AI 能力。

你需要理解：

• provider 负责模型请求；
• 后端代理要兼容 OpenAI 格式；
• 多模态是输入能力；
• 图片可以用 base64 或 URL；
• 是否保存历史决定图片管理方式；
• 聊天输入框要主动支持文件和图片。

接下来就可以围绕 AI 简历做更具体的对话编辑能力。