5 月 26 日，昆仑万维发布全新模型 SkyClaw-v1.0，定价低到 0.5 元每百万 token。值得注意的是，官方将其描述为“一款面向复杂工具使用、多轮工作流和真实世界任务执行的高性能 Agent 模型”，并在用例展示中强烈建议用户将其嵌入 Agent 工作流中使用，而非作为独立的聊天模型。
几乎已经把“专攻 Agent”写在明面上的 SkyClaw-v1.0，究竟是真的工程差异，还是又一个营销话术？我把它接进 Hermes Agent 跑了几天，做了一组从浅到深的测试。
01
回答这个问题之前，需要先解决一个更基础的问题：
什么是 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……它的整个训练流程就是为了这种“从零生成”的而任务设计的。
在自己的赛道里，跑得快是必然的，真正的考验在于离开舒适区之后。
03
在前面的测试完成之后，我有了一个意外的发现，事实上它也是让我决定做后续硬测试的直接动机。
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 现在就是一个很合理的选择。
如果你期待它能解决你工作里所有的代码问题，它显然不是那种东西。
但话说回来，这件事情今天仍然没有任何模型能做到。承认这一点，比期待万能更接近真实的工程。
正在生成分享图...
聪聪