WebDev-Skills-Bench 这类评测套件最核心的目的不是给 Agent 打个分而是回答一个很实际的问题给 Agent 加的网页开发技能到底有没有真的提升结果。我连续跑了几组对照之后感觉这个判断比很多人想的更依赖任务类型、评测基线和观察指标。如果你准备给 Agent 配技能或者正在做网页生成、前端辅助、小游戏开发这一类自动化流程这篇能帮你少走弯路。先说明一点早期我用 Agent 做网页开发经常是“看起来很强一换任务就翻车”。后来把技能加进去效果有变化但很难说清楚到底是模型变强了还是技能真的起作用了。WebDev-Skills-Bench 这类方式就是把“技能有没有用”从感觉变成可比较的评测结果。下面按我自己的实测顺序拆开讲。1. 先搞清楚 WebDev-Skills-Bench 到底在测什么1.1 它不是普通跑分工具而是一个“技能筛选器”很多人一看 Bench 就以为是在测模型智商实际不是。WebDev-Skills-Bench 更关心的是 Agent 在做具体网页开发任务时额外注入的技能包是否带来了可量化的提升。我理解它的评测逻辑是同一组网页开发任务分别让“无技能基线 Agent”和“带技能 Agent”去完成然后对比结果。任务通常是一段需求描述加一个目标 HTML/CSS/JS 文件Agent 需要在浏览器环境里操作、修改、运行最后输出一个可访问的页面。关键不是“跑通一个 Demo”而是“在相同条件下对比两次结果”。所以它给出的结论应该是“技能 A 在任务类型 B 上提升了首轮通过率但在任务类型 C 上没有明显变化。”有了这种信息你才能决定哪些技能值得保留、哪些只是浪费 token。1.2 评测时最该盯住三个点完成度、稳定性和复用性常见评测指标很多但我实际使用中只盯三个完成度任务要求的功能是否全部出现是否有缺失的按钮、事件、样式或交互。稳定性同一任务跑多遍成功路径是不是一致是否会出现“上次能跑这次报错”的随机失败。复用性新任务和评测任务越接近迁移越顺畅如果只是针对一个任务过拟合替换成本会很高。如果你只比对一次的成功率很多问题会被掩盖。比如技能本身没问题但 Agent 有时候会漏掉某个关键步骤这时单次运行结果波动会很大。所以评测时至少同一个任务跑三到五遍再下结论。1.3 评测结果比“功能列表”更值得看我见过不少团队把 Agent 包装成“拥有十个技能”但一到真实项目就卡在路径、权限、依赖版本和输入格式上。WebDev-Skills-Bench 的价值就是把这些干扰因素压缩到可控范围里尽可能只暴露“技能带来的差异”。所以拿到评测结果时不要只看某张表上高分而是看任务失败点集中在哪里。如果失败集中在环境相关环节比如页面资源加载不出来、脚本执行超时那多半不是技能问题而是评测环境没配好。2. 评测前必须准备好的环境与基线2.1 浏览器环境和执行环境先固定住网页开发类评测离不开真实浏览器行为。一般会用 headless 浏览器或浏览器自动化框架让 Agent 能打开页面、执行 JS、检查 DOM再截图或读取控制台日志。这一步很关键因为很多网页任务不是“生成代码”就结束还要确认代码真的能在浏览器里运行。我建议在跑评测前把以下内容写清楚浏览器版本和自动化驱动版本。页面运行的基础模板比如空 HTML、单页应用还是带固定样式的骨架。超时时间设置尤其是页面加载和脚本执行超时。输出目录和日志目录避免多任务互相覆盖。这些看起来是基础工作但直接影响评测结果是否可复现。比如同一个任务在 Chrome 126 和 Chrome 120 上的表现可能不同尤其涉及 Canvas、WebGL、CSS 新特性的时候。2.2 基线必须和被测 Agent 使用同一个模型评测技能有没有用最容易犯的错是基线用一个模型带技能用另一个更强的模型。这样比较出来的提升根本不是技能带来的。正确方式是只改变一个变量基线 Agent - 模型Model-XX - Prompt单条任务指令 - 技能库空 - 参数temperature0.2 带技能 Agent - 模型Model-XX同一个 - Prompt单条任务指令 对应技能描述 - 技能库待测技能 - 参数temperature0.2温度、最大 token 数、重试次数也要保持一致。很多 Agent 在低温下表现稳定但如果你把温差跳过可能把稳定性差异误判为技能效果。2.3 先跑通一个最小样例再上全量任务我不建议一上来就跑完整评测集。第一步先选一个最简单的页面任务比如“生成一个包含标题和按钮的静态页面”让无技能基线和带技能 Agent 各跑一次。这样做的原因很简单小任务能快速暴露链路问题比如技能没有真正加载、Agent 调不到文件、浏览器环境启动失败、输出路径写错。等这些前置问题都解决后再逐步切换到复杂任务比如表单交互、多页面跳转、Canvas 绘图和小游戏开发。注意评测过程中尽量保留每轮运行的完整日志、截图和最终输出文件。这些材料比分数更有说服力尤其是排查“为什么技能没触发”的时候。3. 开发游戏给 Agent 时到底要加哪些技能最近常有人问开发游戏给 Agent 需要添加哪些技能。这类问题放到 WebDev-Skills-Bench 里其实可以拆成可验证的评测任务。游戏和普通网页开发最大的区别在于普通页面偏静态展示游戏偏交互循环、状态更新和实时绘制。3.1 游戏任务和普通网页任务的差异普通网页任务比如“做一个产品介绍页”Agent 只要把内容、布局、图片放好基本就有很高完成度。游戏任务不同它有明显的运行时特征需要一个主循环持续更新画面。玩家输入会改变对象状态比如移动、跳跃、发射子弹。不同对象需要碰撞检测。分数、生命值、关卡等状态需要持久化。Canvas 或 DOM 动画需要的性能开销不同。这些差异意味着一个给普通网页任务设计的技能包用在游戏任务上可能作用不大。评测时需要单独设计游戏类任务组比如“实现一个接苹果小游戏”“实现角色移动和障碍物检测”“实现点击方块计分游戏”。3.2 游戏场景下通常值得验证的技能清单下面这份清单不是标准答案而是我评测时会优先考虑加入的技能类型技能名称解决的问题验证方式HTML 页面骨架生成快速搭建入口和容器任务开始后是否自动生成页面结构Canvas 绘制基础画布、坐标系、绘制圆形/矩形/图片游戏界面是否能正确渲染游戏主循环requestAnimationFrame 或 setInterval 封装帧率是否稳定循环是否能正常启停输入事件处理键盘、鼠标、触摸事件绑定按键后对象是否移动误触是否影响状态碰撞检测判断两个对象是否重叠碰到障碍物后生命值或分数是否正确变化状态管理分数、生命、关卡、重置逻辑重新开局后状态是否清零资源加载图片、音频、JSON 配置的异步加载是否出现资源未加载就使用的情况性能与日志输出调试信息、定位死循环或卡顿长时间运行后浏览器是否无响应技能不是越多越好。一个技能如果描述太长反而会占用上下文让 Agent 更晚进入实际操作。评测结果里如果发现带技能后首轮 token 消耗明显增加但成功率没有提升那这个技能就要考虑精简。3.3 用 Bench 验证“游戏技能”是否真的有用我自己的做法是给每一个候选技能建一个独立任务组比如taskgame-basic: 需求实现一个 400x400 的画布点击后出现一个红色方块。 校验画布存在、颜色正确、点击后方块数量发生变化。 taskgame-collision: 需求实现一个方块从上方落下接住则得分落到底部则生命值减一。 校验分数更新、生命值更新、重新开始后状态复位。跑完无技能基线和带技能 Agent 后重点看首轮成功率、平均尝试次数和最终输出代码是否简洁。如果带技能后任务从 5 轮尝试降到 1 轮那这个技能就有明确价值如果只是输出变长成功率没变化那就该删。4. 单条任务跑通最少要盯住哪几个环节进入正式评测后不建议急着调大并发。先把单条任务从输入到输出完整跑通确认每个环节都符合预期再批量执行。4.1 任务输入格式和技能触发条件很多任务失败不是因为 Agent 能力不够而是输入格式没有对齐。比如任务要求给出“具体游戏类型”Agent 默认理解成“一个简单页面模板”任务要求“包含音频按钮”但技能描述里只写了“Canvas 绘制”Agent 就不会去加载音频。所以我会在任务描述里写清三个要素用户最终想看到什么。技术边界比如是否允许新建文件、是否只能用纯前端。验收方式比如能否通过点击按钮触发某个动作。技能触发条件也要明确。比如“当任务中包含 Canvas、游戏、动画关键词时加载 Canvas 绘制技能”而不是让 Agent 自己猜测。4.2 执行日志和错误堆栈单条任务跑的时候日志是判断问题的最直接依据。重点看Agent 是否按预期调用技能。浏览器控制台是否有 JS 报错。页面最终是否停留在可交互状态。是否有超时导致的半成品输出。如果日志显示 Agent 生成了完整代码但浏览器无反应通常不是技能问题而是脚本没有注入或者 DOM 更新没有触发。这时不要急着改技能先看执行环境。4.3 输出校验标准要提前写死评测输出不能只看“页面能打开”要有明确的校验规则。比如页面存在一个 id 为 game-canvas 的 canvas 元素。 点击按钮后画布中出现一个 40x40 的绿色方块。 方块移动后分数区域数值从 0 变为 1。校验分为三个层级DOM 结构校验、交互行为校验、视觉截图校验。DOM 和交互最好用脚本自动完成视觉截图可以人工或模型二次判断。自动校验能减少主观误差。4.4 失败重试有几个原则即使评测集比较小也要在单条任务跑通后规划失败重试策略。我的建议是第一次失败保留原始输出。第二次重试可以换一次模型采样但不能无限重试。重试超过 3 次仍未成功标记为失败记录失败原因。不要在同一任务里反复改参数否则结果不可比。重试的意义不是提高成绩而是确认任务是否存在随机性。如果同一技能同一任务第一次 30 秒跑完第二次卡住那说明技能本身或运行环境不稳定需要先排查。4.5 结果归因分数提升不等于技能有效就算带技能 Agent 的通过率提升了也不一定说明技能有效。常见干扰因素包括这次随机运气好、基线 Prompt 写得太简陋、技能里把任务步骤写得太具体。判断方法把同一个技能用在另一个相近但不完全相同的任务上看是否还有提升。比如“接苹果游戏”技能用在“射击气球游戏”上如果仍然有效说明技能具备通用能力如果完全失效那可能它只是针对评测任务的模板。5. 批量评测时怎么判断“技能有用”单条任务跑通后再上批量评测。批量评测的意义不是把任务数堆起来而是让结论更可信。5.1 看成功率更要看失败模式批量后你会得到一张结果表我最常用这样的对比指标无技能基线带技能 Agent是否可判定为技能带来首轮完成率45%70%是但要看稳定性平均尝试次数3.21.8是能缩短决策链最终通过率80%85%不明显可能只是随机波动平均 token 消耗1200018000否成本变高任务间失败类型布局缺失、交互失效逻辑报错、状态未复位需进一步分析光看通过率显然不够。如果带技能后通过率提升了但失败集中在“状态管理缺失”这类任务上说明技能覆盖范围不全。如果失败模式从“完全跑不动”变成“跑起来了但逻辑有误”这反而是技能有效的信号。5.2 看技能路径调用次数和 token 消耗批量评测时日志里通常能查到每个技能被调用的次数。如果一个技能被加入后Agent 在绝大多数任务里都用到了它说明技能描述和任务关联度高。如果 Agent 经常忽略技能或者只在极少任务里触发那可能是任务描述和技能描述之间存在语义鸿沟。token 消耗也要看。技能本质上是把额外指令塞进上下文每跑一次任务都会多占 token。如果一个技能让任务成功率从 40% 提升到 90%但 token 消耗涨了一倍那在真实生产环境里你要权衡的是“多花一倍成本换稳定性值不值”。5.3 看输出差异性和可维护性另一个容易被忽略的指标是输出差异性。同一任务不带技能跑三次输出三份风格完全不同的代码带技能后代码结构趋于一致说明技能确实起到了约束作用。但要注意一致性不等于正确性。如果 Agent 只是老老实实照技能模板写但没理解游戏需求里的特殊逻辑那输出虽然统一却仍然不对。我还会人工抽查几份代码看注释、命名、函数拆分是否清晰。技能效果好的时候代码通常更接近工程习惯而不是一坨临时拼凑的脚本。5.4 榜单数据要结合自己的任务重新验证网上可能会有别人跑好的 WebDev-Skills-Bench 结果但最好不要直接照搬结论。因为不同项目对“技能”的定义、任务难度和校验逻辑可能不同。我的建议是把别人的评测结果当作线索然后用自己最关心的任务类型去复测。比如别人说“Canvas 技能对游戏开发无效”但你的任务集中在粒子效果和动画那可能要单独验证。评测的价值在比较逻辑不在最终分数。6. 实际踩坑与排查顺序最后这部分是我在评测 Agent 技能时经常遇到的问题和排查顺序。6.1 先看是环境问题还是技能问题遇到任务失败第一反应不要是“技能没用”。先按这个顺序查页面有没有被浏览器成功打开。资源文件、脚本文件路径是否正确。浏览器控制台有没有报错。Agent 是否真的加载了目标技能。技能描述和任务输入是否对齐。环境问题如果不排除技能评测的噪声会非常大。比如浏览器下载失败、静态资源被拦截、脚本执行权限不足都会让 Agent 输出看起来像“能力不足”。6.2 技能加载了但没触发常见原因如果日志显示 Agent 拥有技能但实际没调用常见原因有三个任务描述太笼统Agent 没有意识到该用技能。技能列表太长Agent 在上下文里漏掉了关键技能。技能描述和任务语言不一致比如技能里全是英文术语任务描述是中文口语。解决办法把技能命名改得更贴近任务关键词或者在任务描述里显式提示“如果任务涉及 Canvas 动画参考 Canvas 绘制技能”。但要小心提示语本身也可能变成一种“隐式技能”让评测不公平。所以基线和带技能 Agent 的任务描述最好保持一致只在技能库上做区别。6.3 输出不稳定的排查链路同一任务多次运行结果时好时坏我一般按这么查先看模型参数是否一致尤其温度和随机种子。再看浏览器是否每次都干净启动缓存和 Cookie 是否残留。再看任务输入是否可变比如随机生成的初始状态。最后看技能内部是否有随机逻辑或外部请求。如果多跑几轮后失败任务集中在某一个特定关卡或交互点那很可能不是技能问题而是任务本身存在歧义。需要在任务描述里补清规则。6.4 低配环境也能跑评测但要降规模如果你的机器显存或内存不大跑完整评测集会很吃力。我建议把评测集拆小先选 5 到 10 个代表性任务跑完一轮拿到稳定结论再决定是否扩大规模。低配环境下还要注意关闭浏览器多余动画效果降低截图分辨率。减少并发任务数避免内存不足导致浏览器崩溃。增加单任务超时时间但不要无限等待。优先用任务描述简单、输出校验明确的任务减少模型不确定性。评测本身是一个资源消耗型工作但它的收益在于让你下一次给 Agent 加技能时不用靠猜。最后我个人最大的感受是Agent 技能有没有用不能听功能列表也不能看单个成功案例。真正该做的是把它放进类似于 WebDev-Skills-Bench 这样的可控评测里用无技能基线去对照用不同任务去验证泛化能力。如果你的目标只是做一两个游戏 Demo不装技能可能也能跑如果要反复做不同的小游戏技能库带来的稳定性收益就是可以被量化出来的。先跑单条再跑批量再把失败模式拆开看结论自然会清晰。
