摘要：从美团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才从一次漂亮演示变成可以交给团队复用的工程资产。
摘要：从美团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才从一次漂亮演示变成可以交给团队复用的工程资产。