當 SkyClaw-v1.0 說「專攻 Agent」，它到底在賣什麼？

雷峰網訊 大多數人對 AI 模型的認知是粗粒度的，視覺模型、生圖模型、大語言模型，分到這一層就停下了。但事實上，更專業的分工早就已經發生。同樣的底座，可以訓練出一個擅長聊天的助手，也可以訓練出一個擅長幹活的執行者。兩者的智力水平或許差不多，但擅長的事完全不同。5 月 26 日，崑崙萬維發佈全新模型 SkyClaw-v1.0，定價低到 0.5 元每百萬 token。值得注意的是，官方將其描述為“一款面向複雜工具使用、多輪工作流和真實世界任務執行的高性能 Agent 模型”，並在用例展示中強烈建議用戶將其嵌入 Agent 工作流中使用，而非作為獨立的聊天模型。幾乎已經把“專攻 Agent”寫在明面上的 SkyClaw-v1.0，究竟是真的工程差異，還是又一個營銷話術？我把它接進 Hermes Agent 跑了幾天，做了一組從淺到深的測試。01Agent 專屬模型，營銷話術還是工程創新？回答這個問題之前，需要先解決一個更基礎的問題：什麼是 Agent 模型？它和我們日常用的 ChatGPT、DeepSeek 有什麼本質區別？簡單來說，對話模型優化的是單次回答的質量，Agent 模型優化的是在環境中持續把事做完的能力。比如我們和 ChatGPT 聊天，這是一個開環系統：你問，它答，結束。它不需要知道"我說的話會改變什麼"。但 Agent 完全不一樣，你讓它幫忙修一個 bug，它需要讀文件、調工具、看反饋、再決定下一步。每一次輸出都會改變環境，每一次環境變化又會變成新的輸入，這就是一個閉環系統。後者的難度相比開環系統指數級地增高。最直接的原因在於，錯誤本身是會積累的。第三步的小誤差，可能讓整個任務在第十步徹底跑偏。而更深刻的難點是，交付完整任務需要 Agent 具有對於何時停止的判斷力。此時不再是生成一句回答就萬事大吉，系統需要判斷“任務做完了嗎"。同時還有不確定性，一旦進入真實的工作場景，工具報錯、文件不存在、測試失敗等種種意外狀況，都可能冒出來。因此訓練一個好的 Agent 模型，遠不是讓聊天模型多讀點編程材料那麼簡單。它需要：▪ 不同的訓練數據：不只是問答對話，而是完整的"目標 → 工具調用 → 觀察 → 修正 → 完成"的執行軌跡▪ 不同的強化學習目標：從“人覺得這個回答好不好”，轉向“這件事到底做沒做成”▪ 不同的可交互環境：搭建一個真正能讓模型“動手幹活”的沙箱，讓它在裡面邊幹邊學在 SkyClaw-v1.0 之前，Agent 模型在行業內也已經很常見了。OpenAI 的 Codex-1 是基於 o3 的 Agent 優化版，明確說“通過在各種環境下對真實編碼任務進行強化學習訓練”，Anthropic 在 Claude Code 背後的模型也做了類似的專項後訓練。頭部玩家都已經在分化“對話模型”和“Agent 模型”，這確實是一種真實的工程趨勢。但這裡有個反直覺的事實，Agent 能力強，不代表對話能力也強。這兩條曲線甚至有所衝突。對話模型被訓練成“詳細解釋、有教育意義、有同理心”，而 Agent 模型卻傾向於“少廢話、快執行、結果導向”。一個在悶頭幹活的執行者，可能不是個有趣的聊天對象。OpenAI 自己就明確建議 Codex-1 不要當聊天模型用。SkyClaw 官網也寫著"強烈建議在 Agent 工作流中使用，而不是作為獨立聊天模型"。這就是「術業有專攻」最精確的註腳，在參數量之外，更大的差異來自優化方向，兩種能力指向不同的訓練目標。理解了這一點，再看 SkyClaw-v1.0 才有意義。按照官方的定位，它是為了 Agent 賽道專門訓練的選手。那麼實際任務中，它跑得到底怎麼樣呢？02實測：番茄鍾與本地記賬本我設計了兩個從零生成的測試，看它能不能交付完整可用的應用。第一個是番茄鍾。功能需要包括 25 分鐘工作 + 5 分鐘休息的循環，同時要有倒計時、進度環、狀態切換音效和完成數統計。第二個是本地記賬板，要能添加記錄、按月彙總、畫分類餅圖、畫 7 天趨勢折線圖。最關鍵的是，不能引用外部圖表庫，所有圖都得自己用 SVG 手寫。這兩個 demo 都是單 HTML 文件交付。我本沒指望它一次跑通，我用 Cursor 寫過幾個小 app，知道這種“一次性吐出生產級前端”的要求，對模型來說也不算簡單。但最終實現結果卻很驚豔，一次生成，速度很快，該有的內容和功能也都有了。其中有幾個工程亮點值得拎出來講講。首先是番茄鍾狀態切換的音效，它沒有用 audio 標籤播一個固定文件，而是用 Web Audio API 現場合成了三音階。工作開始是升調（do-mi-so），休息開始是降調（so-mi-do）。這種細節沒有被我寫在任務要求裡，而是它判斷，好的產品應該這麼做。番茄鍾進度環也一樣。72px 的大數字配 tabular-nums CSS 屬性防止數字跳動，倒計時同步更新到瀏覽器 Tab 標題，讓你切到別的標籤頁也能看到時間，就連“今日完成數”都做了“日期變更自動重置”的邏輯。這同樣不在 prompt 裡，但它知道這是一個真實場景裡必須考慮到的事情。此外還有記賬工具。一個讓我意外之處在於，我特意要求 SkyClaw-v1.0 “不能引圖表庫”，就是想看它能不能自己用 SVG 畫出來。結果它不僅畫了餅圖，用三角函數算座標，正確處理了"扇形角度大於 180°"的邊界 case，還給折線圖加了 linearGradient 漸變面積填充，金額超過 100 的時候自動縮寫成“x 百”避免數字擠在一起。空狀態顯示“? 還沒有記錄，開始記一筆吧”。備註用了 escapeHtml 防 XSS。基本上，這就是一個成熟前端能做到的事情。我的主觀體感上， SkyClaw-v1.0 的交付水平已經和頂尖模型能做到的差不多。如果你的訴求是“用自然語言描述，讓 AI 幫我快速生成一個完整的、能跑的小工具”，SkyClaw 完全可以勝任，而且比我用過的不少更貴的模型還快。不過這也是 SkyClaw-v1.0 訓練的舒適區。在官方 demo 展示中，出現最多的就是這類任務。番茄鍾、記賬板、俄羅斯方塊、Instagram 風格 UI……它的整個訓練流程就是為了這種“從零生成”的而任務設計的。在自己的賽道里，跑得快是必然的，真正的考驗在於離開舒適區之後。03Benchmark 的彩蛋發現在前面的測試完成之後，我有了一個意外的發現，事實上它也是讓我決定做後續硬測試的直接動機。SkyClaw 官方在介紹模型能力時，列出了幾個 benchmark 成績：PinchBench-V2、Claw-Eval、Skywork-Claw-Bench。前面兩個是它自家或合作的評測，最後一個是 OpenClaw 圈內的工作流測評。這些分數都很漂亮，被用來證明“超越 DeepSeek V4 Flash、MiniMax 2.7、Qwen 3.6”，“接近 DeepSeek V4 Pro、Claude Opus 4.6”。但這裡面少了一個東西，SWE-bench。SWE-bench 是什麼？簡單說，它是當前 agent/coding 模型最被認可的真刀真槍評測：從真實的 GitHub 開源項目裡抽取一個用戶報的 bug，把整個代碼倉庫丟給模型，讓它定位問題、提交補丁、跑通原項目的測試套件。這是最貼近真實工程師工作的測試，也是行業裡事實上的硬場景標尺。我去查了一下 SkyClaw 對標的幾款模型的 SWE-bench 成績：它聲稱“超越”或“接近”的每一個模型，全都報告了 SWE-bench 成績。只有 SkyClaw 自己沒報。不報告不等於做不到，但模型公司不主動展示自己的強項數據，是很反常的事。最合理的推測有兩個，要麼是這個分數沒那麼亮眼，要麼這不是它的目標場景。無論是哪種，都意味著同一件事。SkyClaw 公開的 benchmark 體系，可能選擇性地展示了它擅長的賽道。它擅長的是 PinchBench 這類“工具調用 + 信息處理”的任務，而不是 SWE-bench 這類“在大型現有代碼庫裡做精確修改”的任務。這是一個很重要的提醒。當你看到“SkyClaw 超越 X、接近 Y”這種說法時，要問一句“在哪個評測上？”在它選擇的評測上“超越”，不等於在所有維度都“超越”。而 SWE-bench 測的，恰好是真實工程師每天 80% 時間在做的事。大家基本不可能從零寫一個新東西，都是在一個已經存在的項目裡改東西。所以接下來的測試，本質上就是替 SkyClaw-v1.0 做一遍它沒做的考試。04邊界：當任務不再是“從零開始”在一個已經存在的項目裡做精確修改，比如加一個 prop、改一個默認值、修一個 bug、重構一段邏輯，這比從零生成要困難得多。從零開始時，模型是上帝視角，所有代碼都是它自己寫的，它完全理解每一行的意圖。但當它面對一個已有項目時，它面對的是“他人的心智模型”。這個變量為什麼叫這個名字？這個看起來多餘的檢查為什麼要保留？這段邏輯和那段是怎麼互相調用的？這些信息不在代碼註釋裡，模型必須從代碼結構中推斷，然後在不破壞整體的前提下做精確修改。既不能把別人的設計風格改成自己最擅長的寫法，也不能為了“看起來更好”就朝不該改的地方動手。如果說"從零生成"像在空白畫布上畫畫，那在現有代碼庫裡修改，就像做古物修復。前者需要創造力，後者更重要的是剋制。我用一個我自己在維護的開源項目 zelda-hyrule-ui 給 SkyClaw-v1.0 跑了三個遞增難度的任務。Level 1（最簡單）：精確修改 + 文檔同步把一個組件的默認 size 從 90 改成 60，並同步更新兩個文檔。SkyClaw-v1.0 做對了源碼修改，做對了 AI_USAGE.md 的同步，但漏改了 SKILL.md 的一個章節。只是因為我 prompt 裡說“在 §10 中”，它就只搜了 §10，找不到就直接說“沒有”。但其實 SKILL.md 第 689 行有一個完整的 ### StaminaWheel（精力輪） 章節，它只是在別的地方而不是 §10。一個有經驗的工程師，本能動作是“找不到就擴大搜索範圍”，而它沒做這個動作。此外它在執行 npm run build 時，npm 順手重寫了 package-lock.json，它沒意識到要 git checkout 還原，這就是真實工作裡很常見的“Agent 順手汙染了你的 git diff”的場景。Level 2（中等）：跨文件協調修改給一個組件加一個回調 prop，要求改 6 個以上文件，包括源碼、demo 示例、文檔、Props 表格、代碼示例、AI 文檔。SkyClaw-v1.0 首先做了一個非常聰明的判斷：先讀源碼，發現組件裡已經有這個 prop 了。它沒有為了“湊改動”而瞎改正確的代碼，只做了應該做的部分，比如 hover 顏色、demo 交互、文檔同步。有意思的是，SkyClaw-v1.0 在內部識別出“這個 prop 已經存在”，但最終彙報給我的時候只說“沒有遇到困難"。這一點是我後來通過對比 git diff 和源碼才發現的，而更好的選擇應該是，主動告訴我“你以為要新加的功能其實已經做好了，所以我跳過了組件源碼修改"。另外一個比較明顯的短板是時間。Level 1 是幾分鐘搞定的，到了 Level 2 時間膨脹到了 30 分鐘。在多文件協調任務面前，它顯著變慢了。Level 3（最難）：從模糊症狀定位到精確修復我只描述了一個體驗問題，頁面在小屏幕上滑動時會震一下，iPhone 特別明顯，桌面 Chrome 沒事。此外我沒告訴它任何代碼細節，讓它自己定位、自己修，這是最考驗 Agent 真實工程能力的任務。SkyClaw-v1.0 給了我教科書級別的報告。先點出根因（-webkit-overflow-scrolling: touch 配合 iOS Safari 的 scroll gesture chaining），然後解釋三個相關 CSS 概念（每一個都準確），給出修復方案（overscroll-behavior: contain），最後說明為什麼這個修復優雅（不破壞桌面端，不影響橫向滑動，比粗暴禁用滾動更剋制）。回頭去看，SkyClaw-v1.0 的整個修復只加了 1 行 CSS。我去 grep 驗證它說的根因是不是真的，結果是第 553 行確實有它指出的代碼。這份診斷不是瞎猜，確實是基於實際代碼精確定位的。事情有趣的地方就在這裡。如果按“難度遞增、得分遞減”的直覺，三關的成績應該是 5 分 → 4 分 → 3 分。但 SkyClaw 給出了相反的曲線：Level 1（最簡單）表現一般，Level 2（中等）表現良好，Level 3（最難）表現優秀。越難的題，它反而做得越好。一種可能的解釋是，越難的任務越偏“模式識別”。iOS Safari 的滾動 bug 是 Stack Overflow 上被討論過幾千次的經典問題，模型在訓練數據裡見過太多類似案例，所以能直接命中。而 Level 1 和 2 看起來簡單，實際考察的卻是“工程紀律”，比如主動擴大搜索、主動反饋判斷、清理副作用，這些反而是它的弱項。因此 SkyClaw-v1.0 在“現有代碼庫修改”上的真實畫像是：▪ ✅ 單點 bug 修復、模式匹配類問題——接近頂級模型▪ ✅ 寫出來的代碼本身——質量高、註釋規範、邊界考慮全面▪ ⚠️ 跨章節、跨文檔的主動搜索——給它具體範圍它就只搜那個範圍▪ ⚠️ 工程溝通——它會在心裡做關鍵判斷，但不會主動告訴你▪ ⚠️ 多文件協調任務——會顯著變慢，30 分鐘改 6 個文件這正好印證了開篇那句話，Agent 模型今天的能力曲線，不是按“難度”分佈的，是按“訓練數據匹配度”分佈的。在它訓練過的賽道里像專家，在它沒訓練過的賽道里像新手。這是 SkyClaw-v1.0 的邊界，也是今天任何 Agent 模型的邊界。04性價比真相：便宜，但要看用在哪回到最實用的問題，SkyClaw 是不是真的便宜？它的標價是 0.5 元 / 百萬輸入 token，4 元 / 百萬輸出。在 2026 年 5 月這個時間點上，它確實是同梯隊裡最便宜的之一：5 月這一波國內模型集體降價非常密集。DeepSeek V4 Pro 在 5 月 22 日把限時折扣變永久，小米 MiMo 在 5 月 27 日宣佈最高 99% 的降價（cache 命中場景下），整個市場處在快速調整中。SkyClaw 的定價就是在這個時間點拋出來的，它不是突然冒出來的一個便宜模型，而是參與了一場行業級的價格戰。但 Agent 任務的實際成本，從來不是單價決定的，更重要的是完成一個任務消耗多少 token。之前的實測中，SkyClaw 在價格之外，也表現出了一些隱性的成本因素。第一是延遲波動。我做穩定性測試時，連續調用 10 次同一個簡單 prompt，最快 2.1 秒，最慢 37.8 秒。10 倍的波動幅度，對實時交互場景而言，這種不可預測的延遲會很折磨。第二是任務時間膨脹。Level 2 那個 6 文件協調任務跑了 30 分鐘，這本身就是時間成本。第三是工具調用傾向。它在自動化測試裡出現過“問 1+1 也調用計算器工具”的行為。這是 Agent 後訓練的副作用，即訓練時反覆強化“用工具是好的”，導致它在不需要工具的場景也傾向於調用工具解決問題。每一次額外調用都是成本。在這些場景裡，“便宜”就會打折。比如多文件協調、需要反覆試錯的任務、對實時性敏感的工作，這些場景下 SkyClaw 可能用更多 token、更長時間，最後的總賬未必比頂級模型省。但反過來說，在 SkyClaw 的舒適區裡，它的性價比又無可撼動。比如批量化的格式化任務，還有此前實測過的單點 bug 修復和從零生成單文件應用，這些場景下 SkyClaw 的便宜是板上釘釘的。如果你看到這裡，關於 SkyClaw 的判斷應該比較清楚了。它適合的場景包括：▪ 從零生成完整的小工具、UI、報告——它訓練的舒適區▪ 對成本敏感、調用頻次高的批量化 Agent 任務編排▪ 單點的、模式化的代碼問題（CSS bug、配置問題、明確的功能加減）▪ 嚴格 JSON 輸出、格式化數據生成▪ 需要把一個想法快速變成可玩 demo 的場景不太適合的場景：▪ 在大型現有代碼庫裡做精細修改（漏改風險高，需要人工 review）▪ 需要 agent 多次主動澄清需求的對話型任務（它傾向於 silent decision）▪ 實時交互場景（延遲波動太大）▪ 需要嚴格 git 衛生的工作流（它會留下 npm 副作用）▪ 你想要一個"通用全能助手"——它不是05術業有專攻回到開篇那句話，術業有專攻。這是一個被說濫了的詞，但在 AI 模型領域，它正在變得越來越精確。我們正在從“一個大模型解決所有問題”的時代，慢慢走向“不同模型擅長不同任務”的時代。SkyClaw 的發佈，就是這種分化的一個具體切片。但比 SkyClaw 本身更值得思考的，是一個更基本的事實：我們作為人的幻覺，可能才是更應該警惕的東西。我們經常憧憬一個“萬能模型”，給它任何問題，它都能給我答案，給它任何任務，它都能完美交付。在這種憧憬裡，我們容易弱化做成一件事的成本，容易誇大最終成果的想象。但這是不切實際的。SkyClaw 被清晰地定義為一款高性能 Agent 模型，而瞭解一款模型的定義、邊界和侷限性，恰恰是比想象和許願都更重要的事。這也是一個人、一個團隊、一家公司是否真正能駕馭 AI 的基本體現。不是知道這個模型有多強，而是知道它在什麼時候會不行、不行的時候怎麼辦、我們能用它換來什麼、為此又要付出什麼。如果你只是想找一個能跑、便宜、生成質量在線的 Agent 模型，SkyClaw 現在就是一個很合理的選擇。如果你期待它能解決你工作裡所有的代碼問題，它顯然不是那種東西。但話說回來，這件事情今天仍然沒有任何模型能做到。承認這一點，比期待萬能更接近真實的工程。雷峰網文章