pstack 新增创建与维护验证技能这一动作值得聊的其实不是“技能”本身而是背后一个长期被忽略的问题Agent 跑完任务之后怎么证明它真的跑对了我们见过太多这样的场景让 Agent 完成一个订单流程模型输出了“已完成”可你打开页面一看库存没扣、邮件没发、状态没变。问题往往不在 Agent 会不会调用工具而在于它缺少一套像真实用户一样检查结果的验证能力。pstack 这次把“创建验证技能”和“维护验证技能”放在一起给了一个很清晰的信号验证不是写完用例就结束的一次性动作而是要跟着应用一起活着的能力。这篇文章我会拆开讲为什么 Agent 的验证能力值得被单独做成技能创建和维护分别要做什么以及落地时最容易踩哪些坑。1. Agent 真正缺的不是执行能力而是验证能力1.1 “执行完成”和“任务完成”之间隔着一条验证链路很多人刚接触 Agent 时会有一个误解只要模型会调用工具任务就能完成。但“工具被调用”和“业务目标达成”完全是两回事。举个例子。Agent 调用下单接口拿到了 HTTP 200它可能认为订单创建成功。但真实场景里200 可能只是网关接受了请求订单服务内部可能因为库存不足、风控拦截或价格校验失败在更下层返回了一个业务错误。如果 Agent 只看接口状态码就会把一次失败包装成成功输出给用户。真实用户不会这么干。用户会打开订单列表刷新页面确认订单状态变为“已支付”甚至再查看一下发票和物流信息。真实用户的验证动作是一连串对最终状态的确认而不是对中间步骤的单一回应。Agent 想要“像真实用户一样验证应用”就不能只依赖模型自己判断“我好像成功了”。它需要一条可执行的验证链路去什么页面、等什么条件、读什么字段、和什么预期值做比对、最后给出结论。这正是验证技能要解决的事情。1.2 为什么验证能力总是被放在最后才想起来我见过不少 Agent 项目第一个版本都能“跑通”但进入测试或压测阶段就原形毕露。原因不难理解项目前期大家最关心的是 Agent 能不能理解指令、能不能把流程走完。验证被默认成“人工看一眼就行”甚至被当成“等上线后再补”。等到真的需要稳定重复执行任务时才发现 Agent 输出的结果无法被自动确认。这里有一个更深层的问题大语言模型在执行任务和判断结果时用的是同一套内部推理。它既是运动员又是裁判。在长流程任务里模型很容易只拿到中间状态用“我觉得没问题”来填补信息空白。要打破这种自证循环就必须引入外部检查用真实的应用状态作为判定依据。所以当 pstack 提出新增创建与维护验证技能时我看重的不是又多了一个 agent 工具而是它把“验证”从人工兜底变成了 Agent 能力体系里的正式成员。1.3 从“输出结果”到“结果可验证”的转变给 Agent 增加验证技能本质上是在工作流里插入一个独立的检查节点。任务执行完之后Agent 不直接报告“成功”而是先调用验证技能去确认目标状态。这个转变会带来三个直接变化可观测验证技能的输入、操作和判定结果都可以记录不再是模型“信心满满”的一句话。可回归每次应用改动后可以重新跑一遍验证技能快速发现这次改动是否影响已有功能。可交接验证技能可以沉淀成团队共享资产后来接手的人不需要凭经验人工检查直接调用技能就能得到结论。说到底Agent 最大的风险不是不能干活而是干了活之后没人知道活干得对不对。验证技能补上的正是这一块。2. 验证技能是什么先厘清 Skill、Tool 与 MCP2.1 技能是一组方法的封装不只是工具最近 Agent 技能这个概念被频繁提起尤其是“skill”和“MCP”经常被拿来比较。很多人问agent skill 和 MCP 有什么区别我通常这样理解工具Tool是一个可被模型调用的函数它有输入、有输出执行某个具体动作比如“查天气”“发邮件”。MCP 是一种协议解决的是模型如何发现、连接和调用这些工具的标准化问题。技能Skill是更高一层的封装。它不只是单个工具还可以包含触发条件、执行步骤、校验规则、提示词模板、输出格式甚至多个工具的组合调用。换句话说工具给 Agent 提供了“动手”的能力技能则给 Agent 提供了“在什么场景下按什么顺序动手怎么判断结果对不对”的方法。验证技能就是专门用于“判断结果是否符合预期”的技能。它不是一段简单的 if 断言而是一整套可被调用的检查路径。pstack 新增的创建与维护验证技能做的正是这件事让验证从分散代码变成 Agent 可以直接理解和执行的技能对象。2.2 验证技能的四要素一个合格的验证技能至少要包含四部分验证目标明确要验证什么比如“订单支付成功”“登录后进入首页”“文件上传完成”。检查动作为了确认目标状态需要执行哪些操作比如访问 URL、等待元素出现、调用查询接口、查数据库。判定标准什么样的结果可以判定为通过比如状态码等于具体值、页面出现指定文案、数据库记录被创建。结果反馈把验证结果以结构化格式返回给 Agent通常包括状态、耗时、失败原因、截图或原始响应。缺少任何一环技能都很难被可靠维护。举个例子。验证“登录成功”如果只检查“URL 里出现了 dashboard”可能会在页面还没渲染完时误判成功。更真实的验证是URL 变化 页面出现用户头像 接口返回了 token 数据库会话记录已创建四个信号里至少两个独立信号同时满足才判定通过。2.3 为什么“创建”和“维护”必须拆开看pstack 的标题里把“创建”和“维护”并列这一点很关键。创建验证技能很爽因为它是在解决一个明确的当下问题我要验证这个页面、这个接口、这个流程。但应用是活的前端文案会改、接口字段会调整、页面 DOM 结构会变、权限模型会升级。任何一个变化都可能让验证技能失效。维护验证技能才是真正决定这个能力能不能长期用下去的环节。维护不是改一行选择器那么简单它要处理页面结构变化后的选择器更新业务规则变化后的预期值调整误报率升高时的判断逻辑优化多环境配置差异的同步技能版本变更的回归记录如果只创建不维护验证技能很快就会变成一堆过时的断言甚至会误导 Agent:明明功能正常验证技能报错或者功能已经坏了验证技能还在“盲目通过”。所以我更愿意把验证技能看作一个小型业务系统创建是上线维护是长期运营。两者需要同等级别的重视。3. 从创建到维护让 Agent 像真实用户一样验证应用3.1 最小可用验证技能怎么搭我们不需要一开始就设计很复杂的技能。从最小可用版本开始先跑通再逐步完善。我建议按下面这个顺序创建第一个验证技能选定一个高频且容易出错的业务场景比如“创建订单成功”。确定验证层面优先选择最接近用户真实感知的一层。能看 UI就看 UIUI 不稳定就配合 API 或数据库一起看。写出验证路径模拟真实用户的操作打开页面、等待关键元素、读取状态字段、对比预期值。设定判定标准至少包含“通过”“失败”“不确定”三个状态。不确定很重要因为有时页面加载延迟会导致误判。返回结构化结果把失败原因和关键截图或响应原文带上方便 Agent 和开发人员定位。一个常见的验证技能定义结构大概长这样{ skill: verify_order_created, description: 验证订单创建后是否进入成功状态, check_layer: ui_and_api, steps: [ { action: open_page, target: /orders }, { action: wait_for, target: .order-status, timeout_ms: 10000 }, { action: assert_text, target: .order-status, expected: 已创建 }, { action: call_api, target: /api/orders/latest, assert_field: status, expected: created } ], pass_condition: ui_assert_and_api_assert_both_pass }注意这不是某个项目的官方配置只是一个通用示例结构。不同工具配置方式会不同。关键是验证技能要把“检查动作”和“判定标准”显式写出来而不是在代码里散落一堆断言。3.2 从单任务验证到批量任务验证第一个验证技能跑通后接下来就会遇到批量使用的问题。单任务验证的典型流程是Agent 执行主任务 - 调用验证技能 - 得到结论。这里只有一个上下文验证技能的失败影响范围可控。批量验证就复杂多了。比如你要让 Agent 连续处理几十个订单或者同时在不同环境里跑回归。这时会遇到几个新问题并发控制多个验证任务同时跑会不会互相干扰超时管理单个验证技能卡住会不会拖垮整个任务队列重试策略失败后直接重试还是先记录现场再决定结果汇总几十个验证结果如何统一报告而不是堆成几十条日志我建议不要一上来就设计完整的批量框架。先拿一个任务重复跑三次确认结果稳定再扩展到五个任务最后再考虑并发和环境矩阵。提前优化往往是浪费时间。3.3 维护验证技能的正确姿势维护验证技能核心不是“每次改动后修一下”而是建立一套可持续的维护机制。我自己的经验是三个动作第一建立基线。每次技能改动后至少要在主环境跑一遍回归记录通过率。没有基线后续改动很难判断是变好还是变坏。第二监控误报。当验证技能开始频繁报错时不要急着改断言先看失败日志。是应用真坏了还是验证技能过时了这两个原因的处理方式完全不同。如果是选择器过期就更新选择器如果是业务规则变了就改预期值如果只是网络抖动就要增加等待和重试。第三给技能做版本记录。至少记录三个信息改动时间、改动原因、改动前后结果对比。没有版本记录三个月后没人敢动这些技能。验证技能对时效性非常敏感。有时候一个 CSS class 名变化就能让整个技能失效。如果置之不理这个技能就会慢慢变成负资产。4. 落地验证技能时最容易踩的 6 个坑4.1 把验证技能写成“大而全测试套件”有些人会把验证技能设计成“所有用例都覆盖”“一个技能验证整个业务线”。结果就是技能很重。问题很明显Agent 每次调用都要加载很长的步骤执行时间变长上下文被大量中间结果占用失败时难以定位到底哪个步骤出了问题。更合理的做法是一个验证技能只专注一个验证目标。目标粒度可以拆细一点比如“验证订单创建成功”“验证订单金额正确”“验证订单状态流转”而不是“验证整个订单流程”。4.2 只验证主流程成功路径真实用户不只看到成功页面他们也会遇到错误提示、空状态、权限拒绝、服务不可用。Agent 验证应用时不能只检查“正常情况”。一个合格的验证技能至少要考虑一个失败路径。比如验证登录时不仅要确认“密码正确能登录”还要确认“密码错误时出现错误提示”。这种负向验证能帮 Agent 判断是否真的走到了预期分支而不是所有情况都糊弄成一个成功结果。4.3 选择器和断言设计得过脆硬编码文案和 CSS 类名是最容易失效的验证方式。页面文案稍微改个词验证就挂前端重构一下类名整个技能都不能用。更稳妥的做法是优先使用稳定的语义化属性比如> Agent验证技能：从创建到维护，让AI像真实用户一样确认结果
pstack 新增创建与维护验证技能这一动作值得聊的其实不是“技能”本身而是背后一个长期被忽略的问题Agent 跑完任务之后怎么证明它真的跑对了我们见过太多这样的场景让 Agent 完成一个订单流程模型输出了“已完成”可你打开页面一看库存没扣、邮件没发、状态没变。问题往往不在 Agent 会不会调用工具而在于它缺少一套像真实用户一样检查结果的验证能力。pstack 这次把“创建验证技能”和“维护验证技能”放在一起给了一个很清晰的信号验证不是写完用例就结束的一次性动作而是要跟着应用一起活着的能力。这篇文章我会拆开讲为什么 Agent 的验证能力值得被单独做成技能创建和维护分别要做什么以及落地时最容易踩哪些坑。1. Agent 真正缺的不是执行能力而是验证能力1.1 “执行完成”和“任务完成”之间隔着一条验证链路很多人刚接触 Agent 时会有一个误解只要模型会调用工具任务就能完成。但“工具被调用”和“业务目标达成”完全是两回事。举个例子。Agent 调用下单接口拿到了 HTTP 200它可能认为订单创建成功。但真实场景里200 可能只是网关接受了请求订单服务内部可能因为库存不足、风控拦截或价格校验失败在更下层返回了一个业务错误。如果 Agent 只看接口状态码就会把一次失败包装成成功输出给用户。真实用户不会这么干。用户会打开订单列表刷新页面确认订单状态变为“已支付”甚至再查看一下发票和物流信息。真实用户的验证动作是一连串对最终状态的确认而不是对中间步骤的单一回应。Agent 想要“像真实用户一样验证应用”就不能只依赖模型自己判断“我好像成功了”。它需要一条可执行的验证链路去什么页面、等什么条件、读什么字段、和什么预期值做比对、最后给出结论。这正是验证技能要解决的事情。1.2 为什么验证能力总是被放在最后才想起来我见过不少 Agent 项目第一个版本都能“跑通”但进入测试或压测阶段就原形毕露。原因不难理解项目前期大家最关心的是 Agent 能不能理解指令、能不能把流程走完。验证被默认成“人工看一眼就行”甚至被当成“等上线后再补”。等到真的需要稳定重复执行任务时才发现 Agent 输出的结果无法被自动确认。这里有一个更深层的问题大语言模型在执行任务和判断结果时用的是同一套内部推理。它既是运动员又是裁判。在长流程任务里模型很容易只拿到中间状态用“我觉得没问题”来填补信息空白。要打破这种自证循环就必须引入外部检查用真实的应用状态作为判定依据。所以当 pstack 提出新增创建与维护验证技能时我看重的不是又多了一个 agent 工具而是它把“验证”从人工兜底变成了 Agent 能力体系里的正式成员。1.3 从“输出结果”到“结果可验证”的转变给 Agent 增加验证技能本质上是在工作流里插入一个独立的检查节点。任务执行完之后Agent 不直接报告“成功”而是先调用验证技能去确认目标状态。这个转变会带来三个直接变化可观测验证技能的输入、操作和判定结果都可以记录不再是模型“信心满满”的一句话。可回归每次应用改动后可以重新跑一遍验证技能快速发现这次改动是否影响已有功能。可交接验证技能可以沉淀成团队共享资产后来接手的人不需要凭经验人工检查直接调用技能就能得到结论。说到底Agent 最大的风险不是不能干活而是干了活之后没人知道活干得对不对。验证技能补上的正是这一块。2. 验证技能是什么先厘清 Skill、Tool 与 MCP2.1 技能是一组方法的封装不只是工具最近 Agent 技能这个概念被频繁提起尤其是“skill”和“MCP”经常被拿来比较。很多人问agent skill 和 MCP 有什么区别我通常这样理解工具Tool是一个可被模型调用的函数它有输入、有输出执行某个具体动作比如“查天气”“发邮件”。MCP 是一种协议解决的是模型如何发现、连接和调用这些工具的标准化问题。技能Skill是更高一层的封装。它不只是单个工具还可以包含触发条件、执行步骤、校验规则、提示词模板、输出格式甚至多个工具的组合调用。换句话说工具给 Agent 提供了“动手”的能力技能则给 Agent 提供了“在什么场景下按什么顺序动手怎么判断结果对不对”的方法。验证技能就是专门用于“判断结果是否符合预期”的技能。它不是一段简单的 if 断言而是一整套可被调用的检查路径。pstack 新增的创建与维护验证技能做的正是这件事让验证从分散代码变成 Agent 可以直接理解和执行的技能对象。2.2 验证技能的四要素一个合格的验证技能至少要包含四部分验证目标明确要验证什么比如“订单支付成功”“登录后进入首页”“文件上传完成”。检查动作为了确认目标状态需要执行哪些操作比如访问 URL、等待元素出现、调用查询接口、查数据库。判定标准什么样的结果可以判定为通过比如状态码等于具体值、页面出现指定文案、数据库记录被创建。结果反馈把验证结果以结构化格式返回给 Agent通常包括状态、耗时、失败原因、截图或原始响应。缺少任何一环技能都很难被可靠维护。举个例子。验证“登录成功”如果只检查“URL 里出现了 dashboard”可能会在页面还没渲染完时误判成功。更真实的验证是URL 变化 页面出现用户头像 接口返回了 token 数据库会话记录已创建四个信号里至少两个独立信号同时满足才判定通过。2.3 为什么“创建”和“维护”必须拆开看pstack 的标题里把“创建”和“维护”并列这一点很关键。创建验证技能很爽因为它是在解决一个明确的当下问题我要验证这个页面、这个接口、这个流程。但应用是活的前端文案会改、接口字段会调整、页面 DOM 结构会变、权限模型会升级。任何一个变化都可能让验证技能失效。维护验证技能才是真正决定这个能力能不能长期用下去的环节。维护不是改一行选择器那么简单它要处理页面结构变化后的选择器更新业务规则变化后的预期值调整误报率升高时的判断逻辑优化多环境配置差异的同步技能版本变更的回归记录如果只创建不维护验证技能很快就会变成一堆过时的断言甚至会误导 Agent:明明功能正常验证技能报错或者功能已经坏了验证技能还在“盲目通过”。所以我更愿意把验证技能看作一个小型业务系统创建是上线维护是长期运营。两者需要同等级别的重视。3. 从创建到维护让 Agent 像真实用户一样验证应用3.1 最小可用验证技能怎么搭我们不需要一开始就设计很复杂的技能。从最小可用版本开始先跑通再逐步完善。我建议按下面这个顺序创建第一个验证技能选定一个高频且容易出错的业务场景比如“创建订单成功”。确定验证层面优先选择最接近用户真实感知的一层。能看 UI就看 UIUI 不稳定就配合 API 或数据库一起看。写出验证路径模拟真实用户的操作打开页面、等待关键元素、读取状态字段、对比预期值。设定判定标准至少包含“通过”“失败”“不确定”三个状态。不确定很重要因为有时页面加载延迟会导致误判。返回结构化结果把失败原因和关键截图或响应原文带上方便 Agent 和开发人员定位。一个常见的验证技能定义结构大概长这样{ skill: verify_order_created, description: 验证订单创建后是否进入成功状态, check_layer: ui_and_api, steps: [ { action: open_page, target: /orders }, { action: wait_for, target: .order-status, timeout_ms: 10000 }, { action: assert_text, target: .order-status, expected: 已创建 }, { action: call_api, target: /api/orders/latest, assert_field: status, expected: created } ], pass_condition: ui_assert_and_api_assert_both_pass }注意这不是某个项目的官方配置只是一个通用示例结构。不同工具配置方式会不同。关键是验证技能要把“检查动作”和“判定标准”显式写出来而不是在代码里散落一堆断言。3.2 从单任务验证到批量任务验证第一个验证技能跑通后接下来就会遇到批量使用的问题。单任务验证的典型流程是Agent 执行主任务 - 调用验证技能 - 得到结论。这里只有一个上下文验证技能的失败影响范围可控。批量验证就复杂多了。比如你要让 Agent 连续处理几十个订单或者同时在不同环境里跑回归。这时会遇到几个新问题并发控制多个验证任务同时跑会不会互相干扰超时管理单个验证技能卡住会不会拖垮整个任务队列重试策略失败后直接重试还是先记录现场再决定结果汇总几十个验证结果如何统一报告而不是堆成几十条日志我建议不要一上来就设计完整的批量框架。先拿一个任务重复跑三次确认结果稳定再扩展到五个任务最后再考虑并发和环境矩阵。提前优化往往是浪费时间。3.3 维护验证技能的正确姿势维护验证技能核心不是“每次改动后修一下”而是建立一套可持续的维护机制。我自己的经验是三个动作第一建立基线。每次技能改动后至少要在主环境跑一遍回归记录通过率。没有基线后续改动很难判断是变好还是变坏。第二监控误报。当验证技能开始频繁报错时不要急着改断言先看失败日志。是应用真坏了还是验证技能过时了这两个原因的处理方式完全不同。如果是选择器过期就更新选择器如果是业务规则变了就改预期值如果只是网络抖动就要增加等待和重试。第三给技能做版本记录。至少记录三个信息改动时间、改动原因、改动前后结果对比。没有版本记录三个月后没人敢动这些技能。验证技能对时效性非常敏感。有时候一个 CSS class 名变化就能让整个技能失效。如果置之不理这个技能就会慢慢变成负资产。4. 落地验证技能时最容易踩的 6 个坑4.1 把验证技能写成“大而全测试套件”有些人会把验证技能设计成“所有用例都覆盖”“一个技能验证整个业务线”。结果就是技能很重。问题很明显Agent 每次调用都要加载很长的步骤执行时间变长上下文被大量中间结果占用失败时难以定位到底哪个步骤出了问题。更合理的做法是一个验证技能只专注一个验证目标。目标粒度可以拆细一点比如“验证订单创建成功”“验证订单金额正确”“验证订单状态流转”而不是“验证整个订单流程”。4.2 只验证主流程成功路径真实用户不只看到成功页面他们也会遇到错误提示、空状态、权限拒绝、服务不可用。Agent 验证应用时不能只检查“正常情况”。一个合格的验证技能至少要考虑一个失败路径。比如验证登录时不仅要确认“密码正确能登录”还要确认“密码错误时出现错误提示”。这种负向验证能帮 Agent 判断是否真的走到了预期分支而不是所有情况都糊弄成一个成功结果。4.3 选择器和断言设计得过脆硬编码文案和 CSS 类名是最容易失效的验证方式。页面文案稍微改个词验证就挂前端重构一下类名整个技能都不能用。更稳妥的做法是优先使用稳定的语义化属性比如>