ollama v0.23.4更新：Vision图像输入全面支持，Claude本地图片路径工具结果修复，OpenCode集成大升级

ollama v0.23.4 于 2026年5月14日发布，这次版本更新虽然只有 2 个 commit，但实际涉及 18 个文件、815 行新增、109 行删除，改动集中在两个核心方向：一是 launch/opencode 终于支持 vision models 的 image inputs；二是修复了 Claude 在使用本地图片路径时 tool results 的格式问题。对于经常使用 Ollama 做多模态推理、以及通过 OpenCode 进行模型接入和编辑的用户来说，这次更新非常关键，属于“看起来是小版本，实际上体验变化很大”的一次升级。

一、v0.23.4 发布概览

本次更新信息如下：

• • 版本：v0.23.4

• • 发布日期：2026年5月14日

• • 变更说明：

• • • ollama launch opencode now supports vision models with image inputs

  • • Fixed formatting of Claude tool results when using local image paths

从提交记录看，主要是两项变化：

1. 1. anthropic：保留 Claude 本地图片路径的 tool results 在 renderer 中的格式

2. 2. launch/opencode：为 vision models 增加 image modalities 支持

也就是说，这次更新不是单纯补丁，而是同时覆盖了 Anthropic 适配、OpenCode 启动器、多个模型 renderer、server prompt 处理逻辑，以及大量单元测试。

二、核心更新一：OpenCode 现在支持 vision models 的 image inputs

这是这次更新里最受关注的部分。

1. OpenCode 配置构建逻辑升级

在cmd/launch/opencode.go中，buildInlineConfig和buildModelEntries都发生了变化。过去构建 OpenCode 的 inline config 时，只是简单把模型列表写进去，而这次新增了通过api.ClientFromEnvironment()获取客户端，并尝试调用client.Show()去探测模型能力。

如果客户端可用，就会在构建模型条目时判断该模型是否具备vision能力；如果具备，就给模型补上：

• •modalities.input = ["text", "image"]

• •modalities.output = ["text"]

这意味着 OpenCode 在对接 Ollama 模型时，不再只是把它当成纯文本模型，而是可以把视觉输入能力显式告诉上层配置。

2. 视觉能力探测采用 Show API

新增逻辑中，构建模型条目时会对每个模型执行一次Show请求，读取返回的Capabilities。当能力列表中包含vision时，就自动写入图像输入模态。

这部分实现还有一个重要细节：引入了openCodeModelShowTimeout = 2 * time.Second，并且在buildModelEntries中为所有模型探测共享一个超时预算。

换句话说，多个模型一起探测时，不会每个都无限等待，而是共享同一个上下文时间窗口，避免 OpenCode 配置构建被拖慢。

3. 模型限额逻辑保持兼容

本次修改还保留了云模型限额逻辑：

• • 如果是云模型名称

• • 就继续通过lookupCloudModelLimit补充limit.context

• •limit.output

也就是说，新加的 vision modalities 不会破坏原有的 cloud model 配置能力。

三、OpenCode 相关测试大幅增强

这次更新在cmd/launch/opencode_test.go中增加了大量测试，说明这项改动不是简单接入，而是经过了完整验证。

1. 视觉模型获得 image input modalities

新增测试验证：当client.Show()返回capabilities=["vision"]时，buildModelEntries会为模型写入：

• •modalities.input = ["text", "image"]

• •modalities.output = ["text"]

测试中对gemma4:26b做了模拟返回，确认配置完全符合预期。

2. 当无法探测能力时保持默认行为

新增测试还验证了：

• • 如果没有 API client

• • 就不设置modalities

• • 只保留默认name

这说明新逻辑是渐进增强，不会影响非 vision 场景。

3. 多模型共享超时预算

还有一个很重要的测试：

• • 构造两个慢请求模型

• • 使用context.WithTimeout

• • 验证共享超时只会阻塞一个探测流程

这说明新增的 capability probe 逻辑在性能和资源控制上考虑得很细。

四、核心更新二：Claude 本地图片路径的 tool results 格式修复

第二个 changelog 点是：

• • Fixed formatting of Claude tool results when using local image paths

这部分对应anthropic/anthropic.go的修改。

1. 新增 OutputConfig

在MessagesRequest中新增了：

• •OutputConfig *OutputConfig

其中OutputConfig定义了：

• •Effort string

这说明 Anthropic 请求结构里现在可以携带输出努力等级，并且会参与 think 值的转换。

2. Think 逻辑调整

FromMessagesRequest中新增了对OutputConfig.Effort的归一化处理：

• • 去空格

• • 转小写

• • 把xhigh映射到high

然后根据逻辑决定ThinkValue：

• •Thinking.Type == "enabled"时，think = true

• •Thinking.Type == "disabled"时，think = false

• • 如果没显式设置 Thinking，就从OutputConfig.Effort映射为：

• • •high

  • •medium

  • •low

  • •max

这说明本次更新不仅修了 tool result，也顺带把 thinking/output_config 的兼容性做完整了。

3. 图片源结构调整

ImageSource结构也发生了变化：

• • 去掉了原先对"url"的支持提示

• • 当前仅保留"base64"

并且新增resolveImageSource：

• • 只允许base64

• • 解码失败就报错

• • 统一从 base64 解析 image data

这与本次“本地图片路径 tool results”修复相关，因为工具结果里如果带图片内容，需要能正确转换成内部图像数据。

4. 新增 convertToolResultContent

这是本次修复最关键的函数之一。

convertToolResultContent(content any)支持三类内容：

• •nil

• •string

• •[]any

当 content 是数组时，会逐项解析：

• •type = "text"：拼接文本

• •type = "image"：读取source，解析 base64 图片，加入 images

最终返回：

• • 文本内容

• • 图片列表

• • 错误

这就让 tool_result 不再只能是纯文本，而是可以保留图片结果。

5. tool_result 处理方式更合理

在convertMessage中，tool_result的处理逻辑也升级了：

• • 先统计 tool result block 数量

• • 调用convertToolResultContent

• • 将结果转成api.Message{Role: "tool"}

• • 填充Content

• • 填充Images

• • 填充ToolCallID

同时还修复了 user message 和 tool results 的拼接顺序，避免在用户消息中包含工具结果时丢失内容或重复内容。

五、Anthropic 相关测试新增，确保 tool_result 图片可用

anthropic/anthropic_test.go新增的测试很多，说明这个修复是有明确回归保护的。

1. tool_result 携带图片

新增测试TestFromMessagesRequest_WithToolResultImage验证：

• • tool_result 内容可以是数组

• • 数组中同时包含：

• • • text

  • • image

• • image 源使用base64

• • 解析后：

• • •Role是tool

  • •ToolCallID保留

  • •Content是文本部分

  • •Images数量正确

  • • 图像字节与原始 base64 解码结果一致

另一个测试验证：

• • assistant 先发 tool_use

• • user 再发 tool_result

• • 同时还有普通文本

最终转换后：

• • tool message 保留

• • user message 也保留

• • 顺序正确

这类测试很重要，因为它直接对应了“本地图片路径工具结果格式”这类复杂场景，避免数据在中间层丢失。

3. output_config 和 thinking 的交互

新增的几组测试分别验证：

• •OutputConfig.Effort = high时，think 设为 high

• •OutputConfig.Effort = xhigh也会映射成 high

• •Thinking.disabled会覆盖 output_config

• •Thinking.adaptive会继续使用 output_config 努力等级

也就是说，这次更新不只是修图像，连输出控制逻辑也一并校准了。

六、renderer 层统一支持 image tags 与 tool response 图像渲染

这次更新不仅改了 Anthropic 和 OpenCode，还大范围触及了多个 renderer。

整体方向非常明确：让各种模型 renderer 在处理图像时，既能支持原始视觉格式，也能支持[img-x]这种统一占位符风格，并且保证 tool response 中的图像不会被漏掉。

1. 新增 image_tags 统一辅助函数

新增文件model/renderers/image_tags.go，提供：

• •renderContentWithImageTags(content, imageCount, imageOffset)

它的逻辑可以概括为：

• • 如果没有图片，直接返回原内容

• • 如果内容里已经包含[img-，则视为已编号占位符，直接保持

• • 如果内容中有[img]，就按顺序替换成[img-0]、[img-1]...

• • 如果没有占位符，就把图片标签前置

• • 若前置标签后面紧跟非空白文本，则自动补一个空格

• • 返回新内容和新的 imageOffset

这个工具函数的意义很大，因为它统一了多个 renderer 的图像占位符行为。

2. 新增 image_tags 单元测试

model/renderers/image_tags_test.go覆盖了多个典型场景：

• • 没有占位符时前置图片标签

• •[img]依次替换成[img-3]、[img-4]

• • 图片多于占位符时，剩余图片继续前置

• • 占位符多于图片时，剩余占位符保持原样

• • 已经编号的占位符不重复改写

这组测试说明统一图像标签逻辑已经进入稳定阶段。

七、Gemma4、GLM-OCR、LFM2、Nemotron3Nano、Qwen35、Qwen3VL 渲染逻辑同步调整

本次更新中，多个 renderer 都做了相同方向的优化：统一调用renderContentWithImageTags，并修正 tool response 和图片内容渲染。

1. Gemma4 Renderer

model/renderers/gemma4.go中，tool response 的渲染不再直接写loopMessages[k].Content，而是调用renderToolResponseContent。

同时renderContent在图片存在且使用 img tags 时，会先输出[img-x]，再拼接内容，并在必要时补空格。

这解决了图像和文本拼接时的格式问题。

2. GLM-OCR Renderer

model/renderers/glmocr.go调整后：

• •renderContent直接依赖renderContentWithImageTags

• •Render中 tool response 部分使用渲染后的 content，而不是原始 message.Content

测试也同步调整为：

• •[img-0] Describe this image.

• •[img-0][img-1] Describe these images.

注意空格变化，这正是这次格式修正的一部分。

3. LFM2 Renderer

model/renderers/lfm2.go中，图片内容处理逻辑简化，借助统一 helper 做 image tag 处理，并修正了原先文本和图片拼接时的样式。

测试中同样从：

• •[img-0]Describe this image.

修正为：

• •[img-0] Describe this image.

model/renderers/nemotron3nano.go做了两类调整：

• • tool response 渲染改为使用renderMessageContent

• •renderMessageContent内部改用统一的 image tag 处理函数

测试里也体现了空格格式调整，以及多图场景下[img-1][img-2] Compare these.的正确输出。

5. Qwen35 Renderer

model/renderers/qwen35.go中：

• •useImgTags模式下直接调用统一 helper

• • 非 img tags 模式仍输出<|vision_start|><|image_pad|><|vision_end|>

这说明 Qwen35 仍兼容原始视觉 token，同时支持统一图片标签方案。

6. Qwen3VL Renderer

model/renderers/qwen3vl.go同样完成统一图像内容处理，并修正 tool_response 输出：

• • 不再直接输出 message.Content

• • 改为输出渲染后的 content

• • 保证 tool response 中的图片标签也能正确落地

对应测试也将预期文本中的图片标签和空格样式更新为正确版本。

八、server/prompt.go 的关键改动：渲染与消息内容分离

这次更新对server/prompt.go的改动也很关键。

过去在 prompt 构建过程中，消息内容会直接被修改；而现在做了更稳妥的处理：

• • 先复制一份msgs到renderMsgs

• • 在渲染流程中，如果是 renderer 模式，就修改renderMsgs

• • 原始msgs尽量保持不变

这样做的好处是：

1. 1. 避免原始消息被渲染逻辑污染

2. 2. 更适合在不同 renderer 间复用消息

3. 3. 在处理图像标签时，图像和文本的结构更可控

同时，prompt.go还新增了对[img]占位符的前置替换逻辑，让所有 renderer 在 prompt 生成阶段更一致。

九、server/prompt_test.go 大量新增测试，覆盖图像标签与工具图像

这次最“爆炸”的测试更新就在server/prompt_test.go。

1. GLM-OCR 添加 image tags

新增测试验证：

• • prompt 中会出现[img-0][img-1] extract text

• • tool response 也会正确携带图片标签

新增测试覆盖以下 renderer：

• • gemma4

• • qwen3-vl

• • qwen3.5

• • glm-ocr

• • nemotron-3-nano

测试内容包括：

• • user 消息中的图片标签位置

• • tool response 中的图片标签位置

• • 多个 renderer 的输出一致性

新增测试验证：

• • 如果用户内容中已经有[img]

• • 那就按顺序替换成[img-0]、[img-1]

• • 不会重复插入，不会丢失

这说明占位符规则已经稳定地统一到了各个 renderer。

十、这次 v0.23.4 的实际价值

从开发者视角看，这次更新的价值主要体现在三点：

1. OpenCode 能更好地接入视觉模型

这会让 Ollama + OpenCode 的多模态使用场景更完整，vision models 不再只是“能跑”，而是能被上层工具正确识别为图像输入模型。

2. Claude 本地图片路径结果不再容易格式异常

这对工具调用、文件读取、图片输出类场景非常重要，尤其是在工具结果里混合文本和图片时，格式修复能减少很多前端展示或中间层解析问题。

3. 多个 renderer 的图像标签行为统一了

这使得：

• • 图像占位符更一致

• • tool response 更稳定

• • 多图场景更清晰

• • prompt 渲染更可预测

尤其对于需要精确控制图像插入位置的任务来说，这次更新很实用。

十一、总结

代码地址：github.com/ollama/ollama

ollama v0.23.4 不是一个简单的小修小补版本，而是围绕“多模态输入”和“工具结果图像处理”做了一次系统性增强。

本次更新的重点可以概括为：

• • OpenCode 支持 vision models 的 image inputs

• • Claude 本地图片路径 tool results 格式修复

• • Anthropic 增强 tool_result 图片解析能力

• • OutputConfig 与 Thinking 逻辑进一步统一

• • 新增统一的 image tags 处理函数

• • Gemma4、GLM-OCR、LFM2、Nemotron3Nano、Qwen35、Qwen3VL 等 renderer 同步优化

• • server prompt 构建逻辑更稳健

• • 大量测试覆盖确保行为一致

我们相信人工智能为普通人提供了一种“增强工具”，并致力于分享全方位的AI知识。在这里，您可以找到最新的AI科普文章、工具评测、提升效率的秘籍以及行业洞察。 欢迎关注“福大大架构师每日一题”，发消息可获得面试资料，让AI助力您的未来发展。