術業有專攻。

作者丨星 龍

編輯丨馬曉寧 梁丙鑒

大多數人對 AI 模型的認知是粗粒度的，視覺模型、生圖模型、大語言模型，分到這一層就停下了。但事實上，更專業的分工早就已經發生。同樣的底座，可以訓練出一個擅長聊天的助手，也可以訓練出一個擅長干活的執行者。兩者的智力水平或許差不多，但擅長的事完全不同。

5 月 26 日，昆侖萬維發布全新模型 SkyClaw-v1.0，定價低到 0.5 元每百萬 token。值得注意的是，官方將其描述為“一款面向復雜工具使用、多輪工作流和真實世界任務執行的高性能 Agent 模型”，并在用例展示中強烈建議用戶將其嵌入 Agent 工作流中使用，而非作為獨立的聊天模型。

幾乎已經把“專攻 Agent”寫在明面上的 SkyClaw-v1.0，究竟是真的工程差異，還是又一個營銷話術？我把它接進 Hermes Agent 跑了幾天，做了一組從淺到深的測試。

01

Agent 專屬模型，營銷話術還是工程創新？

回答這個問題之前，需要先解決一個更基礎的問題：

什么是 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-numsCSS 屬性防止數字跳動，倒計時同步更新到瀏覽器 Tab 標題，讓你切到別的標簽頁也能看到時間，就連“今日完成數”都做了“日期變更自動重置”的邏輯。這同樣不在 prompt 里，但它知道這是一個真實場景里必須考慮到的事情。

此外還有記賬工具。一個讓我意外之處在于，我特意要求 SkyClaw-v1.0 “不能引圖表庫”，就是想看它能不能自己用 SVG 畫出來。結果它不僅畫了餅圖，用三角函數算坐標，正確處理了"扇形角度大于 180°"的邊界 case，還給折線圖加了linearGradient漸變面積填充，金額超過 100 的時候自動縮寫成“x 百”避免數字擠在一起。空狀態顯示“ 還沒有記錄，開始記一筆吧”。備注用了escapeHtml防 XSS。

基本上，這就是一個成熟前端能做到的事情。我的主觀體感上， SkyClaw-v1.0 的交付水平已經和頂尖模型能做到的差不多。如果你的訴求是“用自然語言描述，讓 AI 幫我快速生成一個完整的、能跑的小工具”，SkyClaw 完全可以勝任，而且比我用過的不少更貴的模型還快。

不過這也是 SkyClaw-v1.0 訓練的舒適區。

在官方 demo 展示中，出現最多的就是這類任務。番茄鐘、記賬板、俄羅斯方塊、Instagram 風格 UI……它的整個訓練流程就是為了這種“從零生成”的而任務設計的。

在自己的賽道里，跑得快是必然的，真正的考驗在于離開舒適區之后。

03

Benchmark 的彩蛋發現

在前面的測試完成之后，我有了一個意外的發現，事實上它也是讓我決定做后續硬測試的直接動機。

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 現在就是一個很合理的選擇。

如果你期待它能解決你工作里所有的代碼問題，它顯然不是那種東西。

但話說回來，這件事情今天仍然沒有任何模型能做到。承認這一點，比期待萬能更接近真實的工程。

未經「AI科技評論」授權，嚴禁以任何方式在網頁、論壇、社區進行轉載！

公眾號轉載請先在「AI科技評論」后臺留言取得授權，轉載時需標注來源并插入本公眾號名片。