企业官网建设流程全解析

先说结论：这次 pstack 带来的更新，不是单纯加一个测试工具，而是把“应用验证”这项能力做成了 Agent 可以直接创建、维护和执行的技能。过去我们让 Agent 写文案、写代码、查资料，但很难让它像真实用户一样在应用里走一遍完整流程；现在验证技能的思路，就是要补上这块短板。本文会围绕技能设计、环境准备、部署启动、功能测试、API 调用、批量任务和排查方法展开，帮你快速判断这套玩法怎么落地。

1. pstack 验证技能核心能力速览

先看一张规格表，快速了解这个方向能做什么、适合谁。

从公开信息来看，pstack 这次的重点是把“验证”从脚本层抽象成技能层。传统自动化测试脚本是写死步骤，一个脚本对应一个场景；验证技能则把步骤、断言、执行条件和环境差异拆开，Agent 拿到技能定义后，可以结合当前页面状态动态调整执行细节。这样维护成本明显降低，新场景也能通过复制和修改已有技能快速生成。

2. 适用场景与使用边界

在动手部署之前，先明确验证技能适合解决什么问题，不能神化它的能力边界。

2.1 适合谁

首先是 Agent 平台开发者。你在做一个 Agent 应用，给用户提供了自然语言入口，但你很难确定每一步工具调用是否真的完成了业务目标。用验证技能，Agent 可以在执行完操作后主动回到应用界面，用真实用户的视角检查页面状态。

其次是测试工程师。接口自动化容易写，端到端 UI 验证才是最容易碎的部分。验证技能让测试用例逻辑变成可读、可维护的 YAML 或 JSON 步骤，不再是一堆散落的 Selenium 代码。

最后是平台运维和 SRE。上线前要做巡检，但巡检不能只检查进程是否存活。验证技能可以模拟一个用户登录后执行核心操作，再断言页面关键元素出现，比单纯探活更接近真实体验。

2.2 能解决什么问题

验证技能最直接的价值，是把 Agent 的验证动作标准化。Agent 不再只是“说它完成了”，而是可以“证明自己完成了”。比如 Agent 需要完成一笔订单创建，它可以通过技能去执行登录、选择商品、提交订单、确认订单号出现，整个链路走完才算验证通过。

同时，技能的可维护性解决了一个长期痛点：UI 一变，脚本就废。验证技能会把选择器、超时时间、环境地址和动作步骤分开管理，页面结构变了只需更新对应技能文件，不需要改动整段逻辑。

2.3 不适合什么场景

验证技能不适合做主观判断。页面的视觉设计是否美观、文案语气是否恰当、品牌调性是否统一，这些不能靠点击和断言完成。它也不适合替代人工的复杂业务审核，比如涉及资金变更、敏感权限、法律合规的流程，最终的确认必须由人完成。

另外，如果被验证的应用本身完全无法被浏览器或 HTTP 协议访问，比如只存在于内网且没有开放任何隧道，那验证技能也帮不上忙。先解决访问问题，再谈验证技能。

2.4 安全与合规边界

这是重点。验证技能会模拟真实用户操作，一旦使用不当，就可能变成不受控的自动访问工具。所以必须明确三个原则：第一，只能验证你有权访问、有权测试的应用；第二，不通过验证技能收集或保存未授权的用户数据；第三，涉及真实用户信息、人脸、声音、资金账号等敏感内容时，必须先脱敏并获得明确授权。

如果应用部署在公网环境，建议给验证技能加访问限制，比如只允许指定 IP 调用验证接口。批量验证时更要注意执行频率，避免对目标应用造成不必要的负载。

3. 环境准备与前置条件

因为不同项目实现细节会有差异，这里给一套通用前置检查清单，把基础条件打牢。

3.1 操作系统与运行环境

服务端建议使用 Linux 系统，比如 Ubuntu 20.04 或更新版本。如果你做本地开发，macOS 和 Windows 也可用，但最终投入生产环境时优先 Linux。需要提前确认的组件包括：

• Python 3.10 及以上版本
• Node.js 18 及以上版本（如果技能运行端涉及前端自动化或浏览器插件）
• Git
• 支持运行 Agent 执行器的环境变量
• 持久化存储，用于保存验证结果、截图和日志

3.2 浏览器自动化组件

验证技能要“像真实用户一样操作”，浏览器驱动是关键。常见的方案是 Playwright 或 Selenium，二选一即可。建议优先 Playwright，它的选择器更稳定，等待机制更完善，也更容易在容器里安装。

安装示例：

pip install playwright playwright install chromium

注意浏览器内核版本要和驱动匹配。升级浏览器后驱动没更新，验证任务会大面积失败，这是最常见的坑之一。

3.3 大模型与 Agent 执行器

验证技能本身不强制要求本地大模型，但 Agent 要理解技能定义并动态调整执行步骤时，会依赖大模型的推理能力。你可以选择调用云端 API，也可以本地部署模型。这里不展开具体选型，但有一个原则：验证任务对稳定性要求高，尽量给大模型调用设置超时和重试，避免单次响应卡住导致整个验证任务挂在半路。

3.4 网络与端口

预留一个管理端口和服务端口。比如管理台默认监听 127.0.0.1 的 8000 端口，浏览器调试端口单独分配。端口选择上避开常见的 8080、9090，避免和现有服务冲突。

4. 部署启动与服务访问

部署方式取决于 pstack 项目自身提供的形式。如果项目提供了一键脚本或 Docker Compose，优先用现成方式；如果是源码部署，下面这套流程可以作为参考。

4.1 源码部署通用流程

git clone <pstack 项目地址> cd pstack python -m venv .venv source .venv/bin/activate pip install -r requirements.txt cp config.example.yaml config.yaml python main.py --config config.yaml

这是通用模板，实际路径和命令需要按项目 README 替换。启动后观察控制台日志是否出现监听地址，确认服务正常启动。

4.2 服务访问确认

服务启动后，管理台一般会提供一个地址。本地测试时可使用：

curl http://127.0.0.1:8000/health

如果返回正常，继续检查管理台能否访问。浏览器打开对应地址，正常应看到技能管理界面或任务管理界面。

4.3 注册自定义技能

在管理界面中可以新建技能，也可以直接写技能文件。实际项目中，我更推荐把技能文件放在一个独立的目录下，统一管理版本。比如：

skills/ login_verify.yaml order_create_verify.yaml search_result_verify.yaml

这样一个目录就是一个技能库，配合 Git 就可以做版本回溯和分支管理。

5. 核心功能：创建与维护验证技能

这一节是关键。你理解了验证技能的创建和维护逻辑，就知道怎么做端到端验证了。

5.1 验证技能的定义结构

一个验证技能通常包含：名称、版本、描述、触发条件、步骤、断言、超时和环境变量引用。步骤的执行顺序就是验证动作的顺序，Agent 会按顺序执行并收集结果。

下面是一个简化但完整的技能示例：

skill: name: app_login_verify version: "1.0.0" description: 验证用户从登录页进入主控台的完整流程 tags: [login, regression] env: BASE_URL: "http://localhost:3000" TEST_USER: "tester" TEST_PASSWORD: "test-pass-123" steps: - action: open target: "${BASE_URL}/login" - action: input selector: "#username" value: "${TEST_USER}" - action: input selector: "#password" value: "${TEST_PASSWORD}" - action: click selector: "#login-btn" - action: wait timeout: 5000 - action: expect selector: ".dashboard" state: visible timeout: 10000 on_fail: screenshot: true output_log: true

这个例子体现了几个重要设计：

• 环境变量独立，技能本身不写死地址和账号
• 每个步骤都明确动作、目标和参数
• 最后一步是 expect 断言，验证页面是否出现目标元素
• 失败时保存截图和日志，方便排查

5.2 创建技能的落地步骤

第一步，在技能目录中新建 YAML 文件，命名尽量使用“场景名_预期结果”，例如login_verify.yaml。

第二步，写基础信息。名称和描述要清晰，足够让 Agent 判断什么场景该选用这个技能。

第三步，把动作步骤拆细。宁可多写两步，也不要一步写多个动作。比如“输入完成并点击按钮”就应当拆成 input 和 click。

第四步，加断言。断言是整个技能的核心，没有断言的验证只能算“操作回放”。

第五步，执行一次，观察结果，再根据失败信息调整选择器或超时。

5.3 维护验证技能的常见操作

维护技能不只是改一个文件，它需要考虑版本、兼容和归档。常见操作如下：

• 新增场景：复制已有技能，修改描述和步骤
• 修改选择器：当页面结构变化时，只更新对应步骤的 selector
• 调整超时：遇到网络慢导致偶发失败，可以增大 wait 或 expect 的 timeout
• 停用过期技能：旧系统下线后，将对应技能标记为停用，避免批量任务误执行
• 记录变更原因：每次更新技能都写清楚原因，方便回溯

维护的核心原则是保持技能文件可读、可 diff。不要在一行里写超长步骤，不要硬编码敏感信息，不要把环境地址写死在技能文件里。

5.4 Agent 执行验证的简化流程

Agent 执行一个验证技能时，内部大概可以这样理解：

def run_skill(skill_definition, env): browser = start_browser() result = {"step": [], "status": "unknown"} try: for step in skill_definition["steps"]: step_result = execute_step(browser, step, env) result["step"].append(step_result) if step_result["status"] != "success": result["status"] = "failed" break else: result["status"] = "passed" finally: browser.close() return result

实际实现会比这个复杂，会包含截图、日志、重试、并发控制等，但这个流程能帮你理解技能的执行机制：顺序执行步骤，失败即终止，最后汇总状态。

5.5 判断验证成功的标准

验证成功与否应同时满足三个条件：

• 所有步骤未报错
• expect 断言全部通过
• 没有触发额外异常条件，比如页面无响应、脚本超时、浏览器崩溃

只要有一条不满足，整体状态就是失败。不要只看最后一步，步骤中途的失败同样需要暴露。建议在结果里输出失败步骤索引和对应日志片段，比只给一个“failed”状态有用得多。

6. 接口 API 调用与批量任务

验证技能不是只能在管理台手动点击执行。要真正落地，必须有 API 触发和批量任务能力。

6.1 API 触发验证任务

通用接口设计大概长这样，具体按项目文档调整：

curl -X POST http://127.0.0.1:8000/api/v1/verify \ -H "Content-Type: application/json" \ -d '{ "skill": "app_login_verify", "env": { "BASE_URL": "http://localhost:3000", "TEST_USER": "tester", "TEST_PASSWORD": "test-pass-123" } }'

请求成功后会返回一个任务 ID，通过任务 ID 查询最终结果：

curl -X GET http://127.0.0.1:8000/api/v1/tasks/{task_id}

这种异步设计很重要。一个验证任务可能执行 30 秒甚至几分钟，如果接口同步等待，很容易触发超时。先用 POST 创建任务，再轮询获取结果，稳定性更好。

6.2 用 Python 批量执行验证技能

批量任务要解决的问题是：多个技能逐个执行、结果汇总、失败任务处理。这里给一个通用的批量调度示例：

import os import time import requests api_base = "http://127.0.0.1:8000" def create_task(skill_name, env): url = f"{api_base}/api/v1/verify" payload = {"skill": skill_name, "env": env} response = requests.post(url, json=payload, timeout=30) response.raise_for_status() return response.json()["task_id"] def wait_task(task_id, timeout=300, interval=5): url = f"{api_base}/api/v1/tasks/{task_id}" start = time.time() while time.time() - start < timeout: resp = requests.get(url, timeout=15).json() if resp.get("status") in ("passed", "failed", "timeout"): return resp time.sleep(interval) return {"status": "timeout", "task_id": task_id} skill_dir = "./skills" env = {"BASE_URL": "http://localhost:3000"} results = [] for skill_file in sorted(os.listdir(skill_dir)): if not skill_file.endswith(".yaml"): continue skill_name = skill_file.replace(".yaml", "") task_id = create_task(skill_name, env) result = wait_task(task_id) results.append({"skill": skill_name, "result": result}) print(skill_name, result["status"])

批量任务有几个细节要注意：

• 同一时间只跑少量并发任务，避免打爆被测应用
• 每个任务之间留间隔
• 失败任务要记录失败原因，而不是简单重试
• 任务结果落盘，后续可以做趋势分析

6.3 批量任务的失败重试策略

失败重试不是无限重试。推荐策略是：第一次失败后等待 10 秒重试一次，再失败就标记为 failed 并通知人工。连续失败三次以上，大概率不是偶发问题，而是技能定义、被测应用或环境出了状况，继续重试没有意义。

如果被测应用是慢接口导致超时，优先调大任务的 timeout，而不是增加重试次数。如果失败信息里有明确的选择器找不到元素，应先去更新技能文件，而不是直接重跑。

7. 资源占用与性能观察

Agent 执行验证技能，本质上是在起浏览器、跑任务、调用大模型，因此资源占用需要提前心里有数。

7.1 浏览器进程的资源消耗

一个浏览器实例通常会占用几百 MB 到 1GB 以上的内存，具体取决于页面复杂度和数量。批量验证时，如果同时开多个浏览器实例，内存消耗会线性增长。建议先单任务跑通，再逐步加大并发，观察内存曲线。

查看系统资源的命令：

free -h top -b -n 1 | head -20 ps aux | grep -E "chrome|chromium" | wc -l

如果内存消耗过高，优先限制并发数量，或者让每个任务结束后强制关闭浏览器进程。实际项目里，浏览器进程没被回收是最常见的资源泄漏原因。

7.2 CPU 和 GPU 观察

页面渲染和交互主要消耗 CPU；如果技能中调用了本地大模型做步骤判断，才会明显消耗 GPU。本地大模型场景下，用nvidia-smi可以观察显存占用：

nvidia-smi

从通用经验来看，验证任务对 GPU 的依赖远低于图像生成、视频生成类任务。大量验证任务跑到超时或卡住，问题通常出在网络、选择器和等待策略上，而不是算力不足。

7.3 降低资源占用的方法

如果批量验证时内存压力大，可以从以下方向调整：

• 减少并发浏览器实例
• 使用无头模式运行，减少渲染资源消耗
• 调整超时，避免任务无休止等待
• 及时清理临时文件和浏览器缓存
• 将耗时长的验证任务拆分成多个子任务

7.4 日志量与磁盘空间

验证任务会产生截图、日志和结果记录，长时间运行后磁盘占用很可观。建议按天或按周归档日志，并定期清理不再需要的临时截图。任务结果数据库也要做保留策略，比如只保留最近 30 天的详细记录。

8. 常见问题与排查方法

验证技能这类系统，问题大都集中在浏览器环境、技能定义、网络和 API 调用上。整理了一张排查表，可以直接对照处理。

排查思路是优先看日志，再看进程，最后看技能内容。大部分问题都不用改代码，先确认环境和技能定义是否一致。

9. 最佳实践与使用建议

9.1 先小后大，从稳定场景开始

第一次接入验证技能，不要一上来就跑全量链路。选择登录、搜索、列表加载这类相对稳定的场景先试跑，确认技能定义、浏览器环境、API 调用都可以正常工作，再逐步增加下单、支付、配置修改这类复杂流程。

9.2 技能与 MCP 分工要清楚

从这波 Agent 开发趋势来看，skill 和 MCP 的区别一直是讨论热点。简单理解：MCP 是给 Agent 提供“手”，让它能操作外部系统；Skill 是给 Agent 提供“流程”，告诉它怎么编排达到目标。验证技能本质上是流程封装，所以不要把它写成一堆 MCP 工具调用，而应该以场景为中心组织步骤。

9.3 敏感信息使用变量与环境隔离

测试账号、密码、地址、密钥等敏感信息，不应硬编码在技能文件里。用环境变量或密钥管理系统传递，避免技能文件泄露。批量验证不同环境时，统一通过 env 参数传入，而不是复制多个技能文件。

9.4 验证任务应具备幂等性

同一个验证技能在相同环境下重复执行，结果应当稳定一致。如果出现“第一次失败、第二次通过”的情况，多半是等待策略不够或前置数据没准备好。这类问题要优先解决，否则后续自动化和回归会很不稳定。

9.5 权限与合规提醒

验证技能会模拟真实用户操作，这决定了它必须在授权范围内使用。不要使用验证技能去访问第三方平台、采集未授权数据、绕过登录验证或执行任何非授权的自动化操作。涉及人脸、声音、个人隐私和资金信息时，更要严格遵守合规要求。

9.6 做好结果留痕与告警

每次验证任务的输出都应包含时间、环境、技能版本、结果状态、失败信息和截图。这样不管是通过还是失败，都能追溯。批量任务里如果连续失败，应当第一时间告警，而不是让任务继续空跑。

10. 总结与下一步

pstack 这次新增的创建与维护验证技能，给 Agent 应用验证提供了一条值得尝试的路线。它的价值不在于把 UI 自动化测试简单包装成“技能”，而是让 Agent 拥有了按真实用户行为去完成验证、并根据结果反馈修正的闭环能力。

如果你想快速尝试，我建议按这个顺序来：先搭好环境，再创建一个登录验证技能，然后通过接口触发一次验证，最后把返回结果和环境变量、截图逻辑接好。跑通这一步以后，再慢慢扩展其他核心链路。

最容易踩的坑有三个：一是浏览器驱动版本不匹配，导致 Agent 起不来页面；二是技能文件里硬编码环境地址和账号，换环境就乱；三是断言超时设置太短，把偶发慢网络误判成功能失败。这三个问题在第一次使用时几乎都会遇到，优先提前准备。

后续可以考虑的方向是：把验证技能接入 CI 流程，每次代码提交后自动执行核心验证；也可以把验证结果整理成报告，反馈给 Agent 自动修复流程；还能结合 MCP 工具，让 Agent 在验证失败时主动调接口查日志、改配置、再验证，形成一个更完整的自动闭环。

这次更新最值得关注的一点是，Agent 从“能完成任务”走向了“能验证任务是否完成”。对做 Agent 应用的团队来说，这个能力越早接入，质量兜底就越早建立。建议收藏备用，后面真正搭建 Agent 验证体系时可以直接按这套思路来。