三週前，我寫了一篇關於 Kimi K2.6 的介紹，並稱它為大多數人還在忽視的模型。
那篇文章上線後，很多人嘗試了它，其中一半回來問了同一個問題。
「好，但我到底要怎麼用這個東西來做真正的工作？」
這篇文章就是答案，比介紹更深入、更少表面、更多戰術。
那些新功能、大多數使用者還不知道的四種模式、今天就能複製測試的提示詞，以及還沒有人寫過的使用場景。
如果你讀過第一篇文章，這就是你想要的後續。如果你沒讀過，你也會很快跟上進度。
快速回顧...
Kimi K2.6 是 Moonshot AI 的開源模型，於 2026 年 4 月 20 日發布。它完全免費，透過 API 使用時每百萬輸入 token 約 $0.55-0.80 美元，同樣的工作量大約是 Claude 的 7-10 倍便宜，具體取決於輸出量。
技術上的亮點是：300 個子 Agent 平行執行 4,000 個協調步驟。
這就是 Agent 群集——一個提示詞 -> 數百個 Agent 同時工作，一個協調器合併結果。
這個亮點數字是大多數文章停下來的地方，但真正的故事是：這個架構為什麼存在。
為什麼單 Agent AI 已經觸及結構性天花板
這是 Moonshot 的觀點，不是我的，而且它比任何教學都更具衝擊力。
三年來，AI 產業一直在改良那把錘子。更快的推理、更長的上下文、更便宜的 token。每次發布都是讓工具變得更好一點點。
問題在於，木匠仍然只有兩隻手和一天二十四小時。如果瓶頸從來都不在錘子上，更好的錘子也無濟於事。
這部分大多數人會跳過：讓一個單 Agent 深度研究工具去調查一百家公司或綜合幾十篇論文。
隨著任務持續進行，上下文窗口被填滿，系統會退回使用歷史折疊或摘要來騰出空間給新的 token。
這種壓縮是有損的，而後續的每個推理步驟都會變得更糟。
這不是一個 bug 或暫時的限制。這是單 Agent 順序執行模型本身所造成的結構性天花板。你無法用更聰明的模型來修復它。你只能透過放棄這個架構來解決。
這就是 Agent 群集的意義——不是一個更好的單 Agent，而是整個工作坊的重建。
K2.5 有 100 個子 Agent 和 1,500 個協調步驟。K2.6 有 300 個子 Agent 和 4,000 個步驟。
在長期任務的實際應用中，執行速度比順序 Agent 快上 4.5 倍，而且最終品質更高，因為群集在結構上避免了導致單 Agent 失敗的上下文崩潰。
這些亮點數字是真實的，它們之所以重要，是因為瓶頸已經轉移了。
Agent 群集是一個自我設計的組織
Moonshot 研究文章中幾乎沒有人引用的一句話：
「這不是許多 AI Agent 合作的故事。我們正在建立的是一個擁有老闆、員工和分工的組織結構，差別在於這個組織不是由人類設計的。它自己設計自己。」
當你給 Agent 群集一個目標時，你不是在指揮一個助手。你是在聘請一位 CEO。然後這位 CEO 會自己找到研究員、分析師、事實核查員——全部自行完成。
你不需要微觀管理。你不需要挑選團隊。你只需要定義最終交付物，群集就會建立必要的組織來完成它。
🚨 好，這就是 Agent 群集對一個簡單問題「展示你能做什麼」給出的答案
那種自我組織才是真正的關鍵。市場上每一個其他的「多 Agent」系統，都是 LLM A 呼叫 LLM B 在你設計好的固定循環中運行。
Kimi 的群集每次都從零開始建立組織圖，規模根據當前的工作量調整。
群集實際上是如何運作的
當你提交一個群集任務時，後台會發生五件事。
分解。協調器將你的目標拆分成領域專屬的子任務。研究交給研究 Agent，綜合交給綜合 Agent，寫作交給寫作 Agent。
Agent 匹配。每個子任務根據技能和工具路由到最適合的子 Agent。這個路由是為什麼 K2.6 在群集模式下 BrowseComp 達到 86.3%（K2.5 為 78.4%）的原因——同樣的工人，更聰明的調度。
平行執行。所有子 Agent 同時工作，各自擁有獨立的上下文窗口，這解決了單 Agent 運行中導致上下文崩潰的問題。
失敗恢復。當一個子 Agent 停滯時，協調器會重新導向並重新分配。群集在運行過程中自我修復。
綜合。輸出合併成一個連貫的最終交付物，並解決矛盾。
還有第六件事沒有人談論：結構性分歧。獨立的 Agent 自然會對重疊的問題得出不同的結論，協調器強制進行調和，這在結構上避免了群體思維。這就是為什麼群集輸出通常比單一模型產生的結果更銳利。
Moonshot 自己證明這一點的例子：群集將散落在個人網站和檔案庫中的 200 多篇 Paul Graham 文章，用一個提示詞就提取出來並歸類到 6 個主題資料夾中，附帶完整的摘要報告。
另一個運行任務在 100 個利基 YouTube 領域中找到了前 3 名創作者，它先自己定義每個領域，然後派遣 100 個平行子 Agent。
兩種情況的模式相同：大量需要尋找或處理的項目，且每個項目彼此獨立。這就是最佳應用場景。對於步驟 N 依賴步驟 N-1 的順序任務，請繼續使用單 Agent 模式。
群集實際上是如何運作的：四種模式。Instant 用於快速查詢，Thinking 用於分析和複雜程式碼，Agent 用於中等自主任務（如 10 頁報告），Agent Swarm 僅用於真正可以平行化的工作。大多數使用者會預設使用群集模式，為他們從未使用的平行化支付費用。請根據任務規模匹配模式。
三個被低估的功能以及可以用它們來做什麼
在 /swarm 之前先執行 /plan，幾乎沒有人教這個。
/plan 會讓你在任何工作開始之前，清楚看到 Kimi 將如何把你的任務分解成子 Agent 和步驟。
你看到計劃，如果 Agent 錯了就調整，然後再執行。
零成本，而一個 200 個 Agent 的群集如果分解錯誤，會花掉真正的錢。
文件轉技能：上傳你最好的作品——一份精緻的報告、一個登陸頁面、一份成交的簡報。Kimi 會捕捉結構和風格特徵，形成一個可重複使用的技能，未來每個群集都會自動應用。這個功能就在選單中，但幾乎沒有人使用。
程式碼驅動設計：同樣的提示詞，兩種不同的結果。Claude 預設使用乾淨的模板佈局。Kimi 則先把 UI 當作程式碼問題來處理，搭配 MoonVIT 編碼器，產生出感覺精雕細琢的編輯式佈局。
用「設計一個 The J Hotel 的登陸頁面」來提示兩者：Claude 回傳一個置中的預訂表單，海軍藍底色搭配金色裝飾，看起來像所有 AI 產生的飯店頁面。
Kimi 回傳一個靠左對齊的編輯式佈局，帶有溫暖的首圖，預訂按鈕浮在圖片上，字體排版感覺經過設計。
如果你大規模產出前端，請在這部分工作切換到 Kimi。
今天就可以建立的六個專案：
多階段市場進入策略，一次產出 PDF、Excel 和 PowerPoint。
比較性學術深度研究，將 24 個月的相關論文整合成 40 頁的分析報告。
從原始 CSV 建立財務儀表板，整合巨觀數據。
內容庫審計，以一致的風格重寫 50 篇舊文章。
將 outreach 規模從 30 個潛在客戶擴大到 300 個。
長期程式碼重構，將 50,000 行的舊程式碼庫按模組拆分，在 24-36 小時內自動運行。
三個今天就可以測試的真實提示詞：
這些是操作者等級的——包含範圍鎖定、來源規則、錯誤處理和閾值條件，不是那些充斥在時間軸上的通用提示詞。
測試 1：Agent Swarm 平行研究
將 Kimi 切換到 Agent Swarm 模式，然後貼上這個。
你會看到的：群集將研究分散到多個 Agent，每個 Agent 從不同來源平行提取資料，然後合併成一個乾淨的最終交付物。計時比較一下手動執行需要多久。
測試 2：文件轉技能
找出你最好的專業作品。一份報告、提案、簡報——任何你引以為傲的東西。上傳它並貼上這個。
你會看到的：一份關於完全不同主題的新文件，但感覺像是同一個作者寫的。這就是大規模產出高品質內容的關鍵。
測試 3：計劃模式驗證群集
在進行任何昂貴的群集運行之前，先測試分解。
你會看到的：Kimi 在執行之前清楚展示它會如何處理任務。這是你在啟動 200 個 Agent 的群集之前能買到的最便宜的保險。
以及最重要的部分之一 | 成本概況，誠實地。
一些粗略數字供你參考：
kimi 的免費方案立即提供 Instant 和 Thinking 模式，Agent 和 Agent Swarm 需要 Allegretto 方案——但我直接說，我覺得它值得。
API 定價約為每百萬輸入 token $0.55-0.80 美元，每百萬輸出 token $2.65-3.60 美元，具體取決於端點和路由。
同樣的工作量，大約是 Claude Opus 的 7-10 倍便宜。
一個 100 個 Agent 的研究運行，產出 40 頁的報告（附引用和結構化資料集），通常 token 成本為 $2-6 美元。
同樣的工作若透過 Claude Code 手動編排，成本為 $30-80 美元，且耗時三倍。
如果你有硬體，自行託管是免費的——權重在 Hugging Face 上以 Modified MIT License 發布。
- Leo
