Kimi K2.5 把視覺、程式碼和 Agent 放一起

Kimi K2.5 在 2026 年 1 月 27 日上線。數字很兇：256K context、1T total parameters、32B active parameters。講白了，Moonshot AI 想把它做成一個能看圖、能寫 code、也能跑 agent 的模型。

這種定位很實際。很多模型會聊天，少數能寫程式。能看截圖、讀長文件、再把工具串起來的，還真沒那麼多。K2.5 的重點，就是把這些能力塞進同一個系統。

對台灣開發者來說，這代表一件事。你不一定要把視覺、文件、程式碼拆成三套工具。K2.5 想讓你用一個模型處理更多流程。

先看 Kimi K2.5 是什麼

Kimi K2 是前一代。K2.5 是往前推一步。核心還是 sparse MoE 架構，但這次加上原生多模態、比較長的 context、還有更完整的 agent 行為。

Moonshot 的產品切法也很直接。網頁、App、API、coding 工具都能碰到它。使用模式則分成 Instant、Thinking、Agent、Agent Swarm。這不是單純聊天介面，而是把模型放進工作流。

更有意思的是視覺能力不是外掛。它不是先 OCR，再丟文字給 LLM。它把影像理解放進底層設計。這對 UI 還原、圖表分析、文件處理都很有差。

• 發布時間：2026 年 1 月 27 日
• 架構：Mixture-of-Experts
• 總參數：1T
• 啟用參數：32B
• Context：256K tokens
• 視覺編碼器：MoonViT 400M
• Agent Swarm：最多 100 個 sub-agents
• 並行 tool calls：最多 1,500 次

架構數字為什麼重要

1T total parameters 聽起來很大，但 MoE 的重點不是每次都全開。它是讓模型有很大的容量，推理時只啟用一部分 expert。這種設計比較像大倉庫，不是每次都把整間倉庫搬出來。

真正有感的是 256K context。這個長度對 codebase、合約、研究筆記、跨檔案任務都很有用。你可以把更多背景一次丟進去，不用一直切段。對 agent 來說，這也代表它比較不容易忘記前面做過什麼。

再來是視覺編碼器。Moonshot 文件提到 MoonViT 400M encoder。這表示它不是只會看圖說故事，而是要能處理 UI mockup、圖表、截圖、混合文件這些真實場景。

• MoE 適合大容量和較省推理成本
• 256K context 對長文件和多步驟工具流程很實用
• MoonViT 400M 代表原生視覺理解
• 61 layers、384 experts、每個 token 選 8 個 experts

Benchmark 看的是實戰感

K2.5 的 benchmark 不是那種「全部碾壓」的故事。比較像是：只要任務混合了 reasoning、tools、code、vision，它就很能打。這種模型比較像工作夥伴，不是考試機器。

Moonshot 公開的數字裡，K2.5 在一些 agent 與多模態項目表現不錯。像 HLE with tools 是 50.2，AIME 2025 是 96.1，HMMT 2025 是 95.4，GPQA-Diamond 是 87.6，MMMU-Pro 是 78.5，MathVision 是 84.2，MathVista 是 90.1，SWE-Bench Verified 是 76.8，SWE-Bench Multilingual 是 73.0。

這些數字的意思很簡單。它不是只會答題。它也能碰實際軟體任務。尤其 SWE-Bench 這種測試，對開發者來說比較接近真實工作。

“We believe that AI should be open, accessible, and beneficial to everyone.” — Yao Shunyu, Moonshot AI co-founder and CEO

這句話很直白。Moonshot 想做的不是單一 demo。它要的是能真的進工作流的模型。開放模型、託管服務、API、工具鏈，全部一起上。

如果拿它跟其他開放模型比，差異最明顯的地方是多模態 agent。純文字模型可以解題。K2.5 可以直接看截圖、讀圖表、再產出可執行的結果。這對前端、產品、研究都很有用。

• HLE with tools：50.2
• AIME 2025：96.1
• MMMU-Pro：78.5
• SWE-Bench Verified：76.8
• 對比一些閉源模型，K2.5 在部分純推理項目仍有差距

開發者會怎麼用它

最適合的場景，是一個模型要連做好幾件事。像是讀 UI 截圖、產出前端 code、再用自然語言解釋修改內容。這種流程以前常要拆成三段，現在可以試著壓在一個 agent 裡。

對工程團隊來說，API 細節很重要。Moonshot 文件提到 visual input、text input、JSON mode、partial mode、tool calling、thinking 與 non-thinking modes，還有官方 web search。這些東西湊在一起，才像真的能上線。

不過也有一個小坑。Moonshot 說 $web_search 跟 K2.5 的 thinking mode 目前不相容。這種事情很煩，但很真實。你如果做搜尋型流程，可能得改用 non-thinking mode，不然會卡住。

• Visual coding：截圖轉前端 code
• Research workflow：拆成多個 sub-agents
• Office 任務：文件、簡報、表格、網站
• API 控制：JSON mode、tool use、長 context prompt

它跟別的模型差在哪

如果只看聊天體驗，很多模型差不多。但一進到工作流程，差距就很明顯。K2.5 的強項是把 vision、code、agent 串在一起，而不是只在單一任務上刷分。

跟 OpenAI 的 GPT 系列比，K2.5 的優勢是 open model 與可部署性。跟 Anthropic 的 Claude 比，它更強調多模態與開放權重。跟 Gemini 比，K2.5 的賣點則是長 context 加上 agent swarm 的工作型設計。

當然，它不是每項都贏。公開比較裡，K2.5 在某些純推理與純 coding 測試，還是會落後 GPT-5.2 或 Gemini 3 Pro 這類閉源旗艦。可是如果你的任務是混合型，這個差距就沒那麼單純。

• 開放權重：方便自架和客製化
• 256K context：比很多模型更適合長工作流
• 原生視覺：對 UI、圖表、文件很有用
• Agent Swarm：最多 100 個 sub-agents
• 1,500 並行 tool calls：適合大規模自動化

這波對產業代表什麼

我覺得 K2.5 最值得看的地方，不是單點能力，而是工作方式。以前大家想的是「一個模型回答一個問題」。現在比較像「一個模型帶一群子任務」。這會影響產品設計，也會影響團隊分工。

對新創來說，這種模型能縮短原型期。對企業來說，它可能變成內部知識搜尋、文件整理、客服輔助、報表分析的核心。當模型能直接吃圖、吃長文、吃工具，很多流程就不必再手工轉檔。

台灣團隊如果想導入，建議先從低風險場景試。像是截圖轉規格、簡報摘要、程式碼審查、研究整理。這些任務有明確輸入輸出，容易驗證，也比較好抓錯誤率。

接下來要觀察的是產品穩定度。模型強不代表流程穩。Agent Swarm 很猛，但一旦 tool chain 出錯，整條流程就會亂掉。這才是上線時最常見的痛點。

我會怎麼看 Kimi K2.5

如果你只想要短答案，K2.5 可能太重。可是一旦你要處理截圖、長文件、code、工具呼叫，它就很值得試。它不是聊天玩具，比較像一個可編排的工作引擎。

我自己的判斷很直接。K2.5 會先在開發者圈子打開。因為開發者最知道長 context、tool use、vision workflow 有多麻煩。只要 API 和穩定性夠好，它就有機會進到更多產品裡。

如果你現在要選一個測試清單，我會建議先做三件事：看它能不能讀你的 UI 截圖、能不能穩定處理長 prompt、能不能在 tool calling 裡少出包。這三項過了，才談得上真的能上線。

說白了，Kimi K2.5 值不值得追，不看宣傳詞。看它能不能把 vision、code 和 agent 真正接起來。這才是重點。