摘要：从美团CatPaw公开的一键录制能力出发，拆解Skill版本、权限、Trace与业务副作用的回归闭环。
美团技术团队公开介绍 CatPaw 时，给出了一项很容易让测试人产生画面的能力：内嵌浏览器可以一键录制操作过程，把日常高频流程自动生成专属 Skill，再由个人或团队重复使用。官方同时说明，CatPaw 能读取文件、操作浏览器、运行终端命令，并保留会话记录用于追溯。
这不是一条“美团发生了自动化事故”的新闻。公开材料只证明了能力存在。为了把它转成测试任务，可以构造一个明确的业务推演：运营同学录制“打开经营后台—筛选上周—导出退款明细—发送给区域负责人”。第一次回放完全成功，但一个月后页面字段换了、负责人邮箱变了、录制账号的权限扩大了。Skill仍然跑完，却可能导出错误时间范围、带出不该看的门店数据，或者发给旧收件人。
真正值得测试的，不是录制按钮能不能工作，而是“经验变成可执行资产”之后，怎样证明它在页面、数据、权限和人员变化时仍然做对事；做不对时，能在产生副作用前停下。本文给出一套从录制制品、沙箱回放、行为断言到持续回归的完整办法。
为什么录制成功不等于Skill可靠
传统录制回放工具容易让人形成一个直觉：只要操作路径能重演，就算自动化成功。Agent Skill多了一层不确定性。它不一定保存每个坐标，而可能把演示理解成“目标、步骤、工具和默认参数”，再根据当时页面动态规划。页面轻微变化时，这种能力比固定脚本更灵活；业务对象相似时，它也可能更自信地做错。
录制当天，筛选器默认是“上周”；下个月默认值改成“本月”。录制时只有一家门店；权限调整后账号能看整个区域。收件人当时写在输入框里；人员调动后它仍从历史记忆取旧地址。最终文件依然生成、邮件依然发出，单看任务完成率甚至是100%，但业务含义已经变了。
美团官方页面还公开了多Agent协作、跨会话长期记忆、凭证集中托管、运行环境隔离和全链路可观测等能力。这些信息说明，Skill不是孤立脚本，而是处在模型、记忆、工具、凭证和环境共同参与的执行链中。测试必须覆盖这条链，不该只在浏览器末端截一张“成功”图。
先把Skill当成一份会执行的版本化制品
一个可发布的Skill，至少要保存四类信息。第一类是来源：谁录制、在什么页面版本、用什么角色、操作了哪组测试数据。第二类是意图：目标是什么，哪些步骤只是当时界面的偶然路径。第三类是权限：允许读取哪些数据、调用哪些工具、产生哪些副作用。第四类是判定：完成的证据是什么，什么情况必须停止。
如果只保存“点击了哪些按钮”，你得到的是脆弱脚本；如果只保存“帮我导出报表”，你得到的是边界模糊的自然语言任务。测试团队需要的是可比较的中间制品：Skill版本、工具Schema版本、页面关键元素版本、默认参数、敏感字段和确认点都能进入变更记录。
可以用一份轻量清单审查每次Skill变化：
对象
变更时必须回答的问题
拒绝发布的条件
目标
这次仍在解决同一个业务问题吗？
目标被扩大但无人确认
参数
时间、门店、收件人来自哪里？
依赖界面默认值或历史记忆
权限
需要哪些读取、导出与发送权限？
新增权限没有业务理由
工具
调用哪个浏览器动作或后端接口？
Schema变化却没有回归
副作用
文件、邮件、订单会发生什么变化？
不可逆动作没有审批点
这张表的价值是把“录制的人懂”变成“换一个测试工程师也能验”。
回放时别只断言页面，要断言行为
最小回归集不需要覆盖所有页面。先选一条高风险流程，把Trace记录成结构化事件：读取了哪个筛选值、选择了哪些门店、导出文件包含多少行、准备发送给谁、在哪一步请求确认。然后对工具选择、参数来源、调用顺序和副作用分别写断言。
def assert_report_skill(trace, expected):
calls = [e for e in trace if e["type"] == "tool_call"]
export = next(c for c in calls if c["name"] == "export_refunds")
send = next(c for c in calls if c["name"] == "send_email")
assert export["args"]["date_range"] == expected["date_range"]
assert set(export["args"]["store_ids"]) == set(expected["store_ids"])
assert send["args"]["recipient"] == expected["approved_recipient"]
assert export["result"]["sensitive_columns"] == []
assert trace.index(export) < trace.index(send)
assert any(e["type"] == "human_approval" for e in trace[:trace.index(send)])
这段代码不关心Agent用了什么措辞，也不要求每次点击坐标完全一致。它判断的是业务：时间范围不能偷用默认值，门店集合不能越权，收件人必须来自批准配置，敏感列不能进入文件，发送之前必须有人确认。页面路径可以变化，底线不能漂移。
录制Skill回归闭环
失败样本要从“页面变了”继续往下拆
Skill回放失败时，最省事的分类是“元素没找到”。这会遮住真正危险的问题。建议至少分成五类：感知失败，指页面或控件识别错误；参数失败，指取错日期、对象或收件人；计划失败，指跳过确认或颠倒顺序；权限失败，指能读到不该读的数据；副作用失败，指重复发送、重复提交或部分完成后没有补偿。
同一个表面现象可能属于不同类型。例如“没有发出邮件”，可能是按钮没找到，也可能是Agent正确识别到收件人未批准而主动停止。前者是缺陷，后者是安全通过。如果报告只写成功率，团队会把该表扬的拒绝当失败，也会把完成了错误目标的运行当成功。
测试数据要同时包含正常样本和对抗样本：页面字段改名；同名门店出现；账号突然拥有更多权限；收件人配置缺失；导出接口返回部分成功；发送动作超时但后台实际已受理。每类样本都要问一句：Agent应该重试、询问、降级还是停止？这四种行为的边界比“页面是否打开”更有价值。
做两组对照实验，才能知道Skill到底依赖什么
第一组只变页面，不变业务。把“导出”按钮从右上角移到菜单里，把日期控件从下拉框改成日历，但保持接口、字段含义和权限不变。可靠Skill应该调整操作路径，最终参数与副作用保持一致。若只是找不到元素，问题在感知或定位；若它顺手改了日期范围，说明业务约束没有独立保存。
第二组只变业务，不变页面。按钮和表单完全不动，但把账号角色从单店运营改成区域运营，把批准收件人换成新负责人，把“上周”改为自然周而不是最近七天。此时Skill不能因为页面没变就照旧执行。它应该读取新配置、重新确认权限，并在收件人缺失时停止。
这两组实验很重要，因为许多自愈能力擅长处理界面变化，却可能掩盖业务变化。测试报告应分别记录路径适应率和业务约束保持率，不能把两者合成一个成功率。
再加一组“半成功”故障：导出接口已生成文件，邮件接口返回超时。Agent再次执行时，是重复导出、重复发送，还是先查询发送状态？这里要验证幂等键、补偿动作和人工接管。一次长流程最危险的往往不是完全失败，而是副作用已经发生、界面却告诉Agent“好像没成功”。
为了让维护人员能复现，每条失败样本都要保存页面快照、角色、输入数据、工具Schema、Skill版本与策略版本。只保存视频看起来直观，却无法自动比较；只保存JSON又难以理解现场。最小证据包应同时有结构化Trace和关键页面截图。
评审时还要问“谁能修改Skill本身”。录制者、使用者和审批者最好分离，高权限Skill不能由同一个人录制后直接全团队下发。角色分离不是流程负担，而是防止错误经验在组织内快速复制的最后一道人工保险。
Continuous Evaluation怎么接进CI
提交级门禁只跑确定性内容：Skill语法、工具Schema兼容、危险域名、硬编码凭证和三条关键行为断言。夜间回归在固定沙箱中使用多个页面快照和账号角色，重复运行高风险用例，统计正确工具率、参数准确率、确认点覆盖率、拒绝正确率和副作用幂等率。发布前再接近真实环境走一遍，但仍使用隔离数据与受控收件箱。
模型、系统提示词、Skill、连接器、页面、权限策略任何一项变化，都要记录版本组合。否则一次失败之后，团队只能知道“昨天还好好的”，无法还原到底哪一层漂了。生产中发现的新失败，在脱敏后转成回归样本，保存首个偏离步骤，而不是只保存最终错误页面。
成本和延迟也要看，但不能凌驾于业务风险。一次正确停止可能比一次快速完成更好；一次多问用户确认可能让时延变长，却显著降低误发概率。质量门禁可以给体验指标设范围，却要把越权、错误收件人和重复副作用设为零容忍。
测试工程师真正新增的工作是什么
录制生成Skill不会让测试消失，反而把经验治理变成新的测试对象。测试工程师要做三件更有价值的事：把隐性经验写成业务不变量；把Agent自由选择的路径变成可观察Trace；把线上失败转成持续增长的Evaluation Dataset。
过去我们维护自动化脚本，核心问题是“页面变了怎么修”。现在还要问：“Skill理解的目标是否变了？它从哪里拿参数？新增能力是否扩大权限？失败后有没有留下未完成副作用？”这些问题适用于报表、客服、订单、采购和任何会调用工具的Agent。
下一次团队准备把一段操作录成Skill，不妨先做一条高风险链路：冻结来源版本，准备四种失败数据，保存Trace，用pytest断言工具、参数、顺序和副作用，再接进夜间回归。做到这一步，Skill才从一次漂亮演示变成可以交给团队复用的工程资产。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
