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助力您的未來發展。