我已經在生產環境中並行運行 Kimi K2.6 的 Agent Swarm 和 Claude Opus 4.8 的 Dynamic Workflows 兩個星期了。有趣的部分不是「哪個比較好」。它們在 SWE-Bench 上的成績不相上下（80.2 vs 80.8）。有趣的是，它們的弱點完全相反，而這使得它們能疊加出任何單一模型都無法達到的效果。
這篇文章涵蓋了完整的流程、提示詞，以及 5 個你今天就能上手的應用案例。全部拿去用吧。
核心概念一句話總結
Kimi 的 swarm 廣闊且便宜。Opus 4.8 深入且昂貴。所以，讓 swarm 產生所有候選方案，然後只花費 Opus 的資源來對抗性地剔除錯誤的。
這個組合之所以有效的原因：
Kimi 的 swarm 可以產生多達 300 個子 Agent，它們會自動分解任務：不需要 LangGraph、CrewAI 或手動編寫的工作流程。這是模型內建的功能。它在廣泛任務上速度快約 4.5 倍，成本約為輸入 $0.60/M、輸出 $2.50/M，加上快取可以節省 75-83%。你可以負擔得起讓它浪費。
它已知的缺點：如果你沒有明確要求驗證，它會產出引用不足、過於自信的主張，而且子 Agent 之間會互相矛盾。
Opus 4.8 則完全相反。它的 Dynamic Workflows 會編寫一個編排腳本，執行從獨立角度攻擊問題的子 Agent，然後部署對抗性 Agent，其唯一任務就是反駁發現，並迭代直到答案收斂。這是第一個在未經批判地報告有缺陷結果方面得分為 0% 的 Claude。它的過度自信程度比 4.7 低了約 10 倍。
它的成本：一次執行可能產生多達 1,000 個 Agent，所以你絕對不希望它來做廣泛的搜尋。你要用它來做「剔除」的工作。
大家都在問的問題，其實是錯的
「我該用哪個模型？」聽起來像是個聰明的問題。但其實不是。
它默默地假設你必須跟一個模型結婚，然後跟另一個離婚。你不需要。
在 2026 年出貨最多的開發者們，已經不再思考模型，而是開始思考角色。一個作家不會在打字機和編輯之間做選擇。他們在不同時刻、為了不同工作，兩者都會使用。
這就是全部的祕密。所以，讓我來介紹這兩個角色。
認識引擎：為什麼 Kimi K2.6 悄悄地改變了遊戲規則
如果這個工作流程有一個明星，那就是 Kimi。而且你越看這些數字，就越覺得它不像升級，更像是個作弊碼。
價格幾乎可以忽略不計。 官方價格是每百萬輸入 Token 0.95 美元，每百萬輸出 Token 4.00 美元。這大約是 premium 等級在輸入端便宜 5 倍、輸出端便宜 6 倍。甚至還有一個免費的入門方式：你現在就可以在 kimi.com 上使用它，並透過 Cloudflare Workers AI 使用每日免費額度來運行。當嘗試的成本降到這麼低時，你就不再會吝嗇你的想法。你只管去執行它們。
它不會累，而且它不會單獨工作。 這是大多數人忽略的部分。Kimi 的 Agent Swarm 可以在一次自主運行中，產生多達 300 個專業化的子 Agent，並協調它們執行約 4,000 個步驟，是前一個版本的三倍。其他每個助手都是一個工人一次做一件事。Kimi 是一個協調者，同時將任務分配給數十或數百個工人，然後合併結果。
以下是當你放開它時會發生的情況：
- 人們在一小時內就能產出相當於一個小型代理機構的成果：找出網站薄弱的本地商家、為每個商家建立登陸頁面草稿、撰寫外聯郵件，並產出一份市場報告，全部來自一份簡報。
- 開發者在一個下午就能將數千行經過驗證的資料拉入一個乾淨的試算表，每一行都經過真實來源的檢查，這項工作需要單一 Agent 花費大半天的時間。
- 在一個廣為流傳的案例中，Kimi 被指向一台筆電上的小型模型，並被要求讓它變得更快。它在無人看管的情況下運行了 12 個小時，進行了超過一千次工具呼叫，重寫了數千行程式碼，並將吞吐量從大約每秒 15 個 Token 推高到將近 200 個。沒有人類介入。只有一個目標。
它也是開源的， 採用修改過的 MIT 授權，並附帶一個開發者們在 GitHub 上按星數以千計的 CLI。你不是在租用一個黑箱的存取權。你是站在一個你可以檢查、託管和建構的基礎之上。
Kimi 是引擎室。它負責跑里程。它運行 swarm。它把「我希望我能試十個版本」變成「我在午餐前就試了十個版本」。
但是，一個沒有駕駛的引擎只會朝著錯誤的方向快速前進。這正是第二個角色登場的地方。
認識終結者：Opus 4.8 的價值所在
如果 Kimi 負責跑里程，那麼 Opus 4.8 負責抓錯誤。
Anthropic 這次發布的頭條不是一個基準測試。而是誠實。據報導，Opus 4.8 讓自己程式碼中的缺陷未被標記而溜過去的可能性，比其前身低了約四倍。它較少虛張聲勢，而且更願意說「這部分不太可靠」。
在高產量的工作流程中，這一個特質就價值連城。當一個 swarm 產出了一大堆成果時，你不需要另一個不知疲倦的建造者。你需要一雙銳利、懷疑的眼睛來告訴你真相。Opus 也在你最想確保的事情上表現出色：生產級的精確度，以及對文件和視覺內容的高保真閱讀。
它在流程的前端也帶來了判斷力，這部分一個好的架構決策就能節省十個小時在錯誤方向上的工作。一個非常大的上下文視窗意味著它可以在寫下任何一行程式碼之前，就將整個問題掌握在腦中。
它是資深審查者。是架構師。是你信任的那個人，他會看著引擎產出的一切，然後冷靜地說：「這個出貨，但那個先修好。」
正面對決：Opus 4.8 vs Kimi K2.6
這是每個人都想看，但幾乎沒有人會誠實寫出來的部分。
Anthropic 讓 Opus 4.8 有了真正的進步：更敏銳的判斷力、他們做過最誠實的模型，以及在最困難的編碼和推理測試中獲得最高分。確實是出色的工作。
與此同時，Kimi K2.6 悄悄地做了一些難以反駁的事情。它的 Agent 承擔相同的實際工作，在大部分任務上產出的結果並沒有明顯較差，而且成本便宜好幾倍。在大多數人日常出貨的事情上，輸出的差距很小，而價格的差距很大。
以下是兩者逐點比較：
- 每個 Token 的價格。 Opus 4.8 是每百萬輸入 Token 5 美元，每百萬輸出 Token 25 美元。Kimi K2.6 是每百萬輸入 Token 0.95 美元，每百萬輸出 Token 4.00 美元，整體大約便宜 5 到 6 倍。
- 模型權重。 Kimi 是開源的，採用修改過的 MIT 授權，所以你可以自行託管。Opus 是專有的。
- 規模和上下文。 Kimi 是一個 1 兆參數的模型，擁有 256K 的上下文視窗。Opus 擁有 1M 的上下文視窗。
- Agent。 Kimi 的亮點是 swarm：在一次自主運行中，多達 300 個子 Agent 協調執行約 4,000 個步驟。Opus 透過 Dynamic Workflows 運行並行子 Agent。
- 接受的輸入。 Kimi 接受文字、圖片和影片。Opus 接受文字和圖片。
- 最難的編碼測試（SWE-bench Verified）。 兩者都獲得高分。Kimi 大約在 80 出頭，Opus 則略高一些，在 80 後段。
- 各自最擅長的事。 Kimi：成本、並行量和開放性。Opus：誠實、判斷力和精確度。
誠實地看待這些比較，得到的教訓不是「Kimi 贏了」或「Opus 贏了」。而是它們在不同的方面贏了。一個是你追求絕對正確時會使用的精密儀器。另一個是負責跑里程、運行 swarm，而且幾乎不碰你預算的引擎。這正是為什麼聰明的做法不是選邊站。而是把每個模型放在它最強的位置。
工作流程：規劃、群集、判斷、出貨
這是值得保存的部分。四個步驟，兩個模型，乾淨的交接。
1. 用 Opus 4.8 規劃（思考）。
向 Opus 描述整個問題，並要求它進行架構設計，而不是執行。結構是什麼？風險是什麼？最乾淨的路徑是什麼？然後要求它做一件特定的事：一份書面規格（稍後會說明為什麼這很重要）。你這裡是刻意花費 premium Token。這將是你買過最便宜的一小時，因為它能防止昂貴的錯誤。
2. 用 Kimi K2.6 群集（執行）。
將規格交給 Kimi，然後讓引擎運轉。這就是產量的所在：產生程式碼、編寫測試、起草變體、跨檔案進行重複性的建構。讓 swarm 將繁重的工作並行化。因為它非常便宜，你不會害怕丟掉第一次的嘗試然後重新運行。這個階段以極小的成本完成了 80% 的工作。
3. 用 Opus 4.8 判斷（說實話者）。
將 swarm 產出的一切餵回給 Opus，並問那個關鍵問題：這有什麼問題？這就是它的誠實值回票價的地方。它會抓住那些沉默的缺陷、未經支持的假設、那些看起來正確但其實不然的東西。你不是在支付 premium 價格來產生內容。你是在支付它們來驗證，這是花費昂貴 Token 最具槓桿效應的方式。
4. 送回 Kimi K2.6 出貨（循環）。
拿 Opus 的筆記，交給 Kimi，讓引擎以接近零的成本進行修復和打磨。然後出貨。而且因為在 Kimi 端的循環成本非常低，你可以明天再跑一次，後天也是，不用一直盯著費用表。
用架構師來規劃。用引擎來建構。用說實話者來判斷。用引擎來出貨。重複。
真正的關鍵：寫一份規格，而不是一個提示詞
這是區分那些能從 swarm 中得到魔法的人，和那些只得到昂貴垃圾的人之間的訣竅。
當大多數人聽到「300 個 Agent」時，他們會發射一個一行文的提示詞，像是「爬取美國所有的資料中心」，然後期待奇蹟。這是燒掉額度並得到垃圾的最快方法。
真正的關鍵是把 swarm 當作承包商，而不是精靈。與其給它一行文，不如給它一份兩到三頁的文件，明確定義要收集什麼、什麼才算有效、哪些來源是可接受的、輸出格式應該是什麼，以及當它發現衝突資訊時該怎麼做。你不是在寫一個提示詞。你是在寫一份規格，而 swarm 會根據這份規格執行，同時你可以去做別的事。
現在這兩個角色完美地結合在一起：世界上寫這份規格最好的工具，就是你那個謹慎、有判斷力的模型。Opus 4.8 在 PLAN 步驟中將模糊的目標轉化為精確的規格。Kimi 的 swarm 在 SWARM 步驟中大規模執行那份規格。思考者下達命令。軍隊執行命令。
那些說 Agent swarm 「脆弱」的人，幾乎總是指他們的提示詞很脆弱。以規格驅動的工作完全改變了結果。
直接複製這個由你的架構師撰寫的規格骨架：
把它交給引擎，然後就可以離開了。
今天就運行這個循環：3 個可以直接用的提示詞
你不需要一個大專案來嘗試這個。拿起任何你通常會丟給單一模型的任務，然後透過以下三個提示詞來運行。填寫括號內的內容，然後開始。
提示詞 A. 規劃（貼到 Opus 4.8）
1我想要 [用白話描述你的目標]。2先不要建構任何東西。扮演架構師的角色。3使用以下標題將此轉化為一份精確的規格：4目標、範圍、規則、來源、輸出、停止條件。5在完成之前，標記出計畫中兩個風險最高的假設。
提示詞 B. 群集（貼到 Kimi K2.6）
1這是一份規格。從頭到尾執行它。2盡可能地並行化，然後將所有內容合併到下方定義的最終 OUTPUT 中。3除非規格確實自相矛盾，否則不要問我問題。4[貼上來自提示詞 A 的規格]
提示詞 C. 判斷（貼到 Opus 4.8）
1這是規格，以及一個 swarm 根據它產出的輸出。2保持懷疑。你的工作是找出問題，而不是讚美它。3列出每一個缺陷、未經支持的主張和沉默的漏洞，按嚴重性排序，4然後給我一個簡短的修復清單，我可以直接交回給建造者。5[貼上規格和輸出]
然後將提示詞 C 的修復清單拿回給 Kimi，讓它修補所有東西，然後出貨。這就是循環的一個完整回合，而且再次運行的成本幾乎為零。
讓你的財務長微笑的數字
這就是為什麼這不僅優雅，而且在經濟上也是顯而易見的。
在一個天真的工作流程中，你在所有事情上都使用 premium Token。每一個拋棄式的草稿、每一個測試、每一個愚蠢的實驗，都是全價。
在這個工作流程中，昂貴的模型只觸及兩個判斷力真正重要的時刻：規劃和裁決。中間的一切，佔 Token 用量 80% 的純粹執行工作，則由成本便宜好幾倍的模型來運行。
你不是在削減品質。你是在削減那些從來不需要昂貴的部分的價格。
這就是團隊如何悄悄地大幅削減他們的 AI 帳單，同時增加出貨量的方法。不是透過買得更少。而是透過買得更聰明。
為什麼這個組合勝過任何單一模型
更深層的原則比 AI 還要古老：比較優勢。
使用不知疲倦、便宜的引擎來處理產量。使用謹慎、高品質的頭腦來進行判斷。不要讓你最昂貴的思想家去做粗活，也不要信任你最快的建造者來做最終決定。
單一模型會迫使你妥協。全 premium 會在不需要的任務上燒錢。全便宜則有風險出貨沒人抓到的缺陷。雙模型循環完全拒絕了妥協。它同時得到了便宜模型的經濟性和謹慎模型的良知。
這不是一個 hack。這只是一個良好的分工，終於在軟體中實現了。
一個會悄悄毀掉這個工作流程的錯誤
跳過 JUDGE 步驟。
這是最誘人偷工減料的地方，因為 swarm 的輸出通常看起來已經完成了。它可以編譯。它可以運行。感覺像是完成了。
「看起來完成了」和「是正確的」是兩個不同的星球，而這個工作流程之所以安全，完全是因為你指派了一個謹慎、誠實的模型來告訴你兩者之間的差異。為了節省幾分鐘而砍掉這個步驟，你就把一個出色的系統變回了快速出貨 bug 的方法。
只有當有值得信賴的東西在檢查工作時，便宜的產量才是超能力。保留判斷者。
結論
在一個關於哪個模型「最好」的爭論越來越激烈的時代，安靜的真相幾乎有點好笑。最好的模型原來是兩個，各自指向它們天生適合的工作。
Kimi 負責跑里程。Opus 負責抓錯誤。一份好的規格是它們之間的橋樑。
還在爭論的人會繼續爭論。你現在有一個工作流程了。
去建構那個他們下個月會寫文章討論的東西吧。
把這篇存起來 🔖。
