Shiplight 全栈拆解：Agent 原生测试平台如何把意图变成可持续回归

我一开始以为 Shiplight 只是“让 AI 帮你写 Playwright”。把官网、定价、登录入口、公开 Skill、npm 元数据和 67 个文档入口走完之后，我改了判断：它真正的产品不是测试生成器，而是一条把 Coding Agent 的临时浏览器验证，逐步变成可维护回归资产的流水线。

这篇不再重复我在验证瓶颈与“定位器是缓存”里讲过的品类叙事。问题换成更实际的三个：

1. Shiplight 的完整工作流到底怎样运转？
2. “自然语言、确定性执行、自愈”为什么能同时成立？
3. 如果公司要做一个对等产品，哪些是 P0，哪些只是看起来很完整？

先给结论：最值得学的不是 YAML 语法，也不是某个模型 Prompt，而是“语义真相与执行缓存分离”之后形成的整条闭环。

名词速查

术语	一句话解释
Coding Agent	Claude Code、Codex、Cursor 这类能读代码、改文件、调用工具的开发代理
MCP	让 Agent 发现并调用外部工具的一套协议；这里用来控制真实浏览器
YAML IR	测试的中间表示：比自然语言更结构化，又比 Playwright 代码更容易读
Action Cache	把已经解析好的 Playwright 动作和定位器缓存下来，正常运行时不再问模型
Self-healing	缓存定位器失效后，依据原始意图重新找到元素并继续执行
BYOK	Bring Your Own Key，用户直接提供自己的模型 API Key
Agent Verification	不只看 UI，还继续检查 API、数据库、日志和队列状态的跨层验证
Control Plane	管组织、Token、运行历史、分析和计费的云端控制面

一句话心智模型：它是一台“测试编译器”，不是一个聊天机器人

Shiplight 之所以长成今天这样，是因为有一个可反驳的根本约束：

Coding Agent 生成代码的速度，已经高于人类持续编写和维护 UI 测试的速度；但回归测试又必须高频、低成本、可重复。

如果这个约束不存在，做一个录制器、一个低代码编辑器，再配云端执行就够了。问题恰恰是：测试的第一作者正在从人变成 Agent，而测试执行频率在上升。若每一步都让模型重新看页面，成本、延迟和随机性先崩；若继续把 CSS selector 当真相，UI 一改，维护量先崩。

Shiplight 的解法像编译器：

• 自然语言 intent 是相对稳定的源语言；
• YAML 是可审查的中间表示；
• Playwright action 与 locator 是面向当前页面版本的机器码缓存；
• AI 只在“机器码失效”时重新编译那一步。

这个比喻比“AI 测试工具”更有解释力。它能同时解释可读、自愈、快速执行和低模型成本，而不是把四个卖点各讲一遍。

三个平面，十个部件

我把产品拆成 Agent、执行、云端三个平面。表里最后一列很重要：一个部件缺失时，产品会先坏在哪里。

平面	部件	负责什么	缺了会怎样
Agent	/shiplight Skill	把验证、建测、修复、覆盖和 CI 编成代理工作流	只剩浏览器原语，Agent 会点但不知道怎样做 QA
Agent	项目规格与 knowledge/	保存环境、角色、数据和已知约束	每个会话重新解释项目，错误假设反复出现
执行	Browser MCP	打开、检查、操作浏览器，采集 Console 与 Network	Agent 看不到应用真实运行状态
执行	YAML DSL	保存目标、步骤、断言、条件、循环和清理逻辑	测试退回难审查的生成代码
执行	Transpiler / CLI	把 YAML 转为 Playwright，负责运行、调试和报告	本地与 CI 不能共享同一资产
执行	Action Cache	确定性重放已经解析过的动作	每一步都调用模型，速度和成本失控
执行	AI Runtime	处理新意图、语义断言、提取和恢复	缓存失效后只能人工修 locator
云端	Runs / Artifacts	保存步骤、截图、视频、Trace 与历史	红灯仍然只是一个红灯，无法快速定位
云端	Analytics / Attribution	统计 flake、耗时、成本与失败原因	团队无法区分产品回归、测试漂移和基础设施噪声
云端	Runner / LLM Proxy	提供托管计算和统一模型入口	用户仍可自建，但商业化和零配置体验变弱

公开文档把这条主链写成 start → inspect → act → verify → close → report。产品层再往外包一圈，就得到完整生命周期：Author → Run → Heal → Fix → Learn。

flowchart LR
  subgraph Author[作者期]
    direction TB
    A[需求、Diff、Ticket 或录屏] --> B[Coding Agent 规划验证]
    B --> C[Browser MCP 走真实流程]
    C --> D[生成可读 YAML]
  end

  subgraph Runtime[运行期]
    direction TB
    E[Playwright 确定性执行] --> F{缓存动作成功?}
    F -->|是| G[继续并产出证据]
    F -->|否| H[AI 根据 intent 重解析]
    H --> I[候选 locator 与 Heal Event]
    I --> G
  end

  subgraph Close[闭环期]
    direction TB
    J{整条测试通过?} -->|是| K[提交缓存与运行历史]
    J -->|否| L[归因: 产品 / 测试 / 数据 / 基础设施]
    L --> M[修测试开 PR 或报告产品 Bug]
  end

  D --> E
  G --> J

从一句需求到一个可持续测试

1. 开发期验证：先看世界，再谈代码对不对

/shiplight verify 不是先生成测试文件。它先读代码变更和验收标准，启动本地服务，打开真实浏览器，走受影响的页面，再检查 Console、Network 和可见结果。

这一步的价值是把“代码看起来对”升级为“运行后的世界状态对”。我在Agent 怎样知道自己真的做完了里写过：工具成功不等于任务成功，完成权必须交给环境证据。

但 verify 仍是一次性的。它像开发者手动点了一遍，只是点的人换成了 Agent。真正形成复利，要进入下一步。

2. 固化：真实走查之后才写 YAML

公开的 agent-skills-v2 把建测流程写得很具体：先确定目标 URL 和认证方式，读取规格与项目知识；浏览器走通真实流程，捕获 locator；然后写 YAML；最后用严格模式转译并运行最小相关测试。

这条约束值得抄：禁止从需求文字直接幻想页面结构。否则 Agent 很容易写出语法完美、元素根本不存在的测试。

一个典型步骤有两层：

- intent: 点击创建项目
  action: click
  locator: "getByRole('button', { name: 'New Project' })"

intent 说“为什么做”，action + locator 说“这版页面上怎样做”。人评审前者，机器优先执行后者。

3. 运行：四种步骤对应四种成本

步骤	正常路径	模型调用	自愈边界
ACTION	执行缓存的 locator/action	缓存失败才调用	能重新解析交互元素
VERIFY	先跑可选的 JS 断言	无 JS 或 JS 失败时调用	退回语义断言
DRAFT	模型看页面后决定动作	通常每步调用	本身就是慢路径
Code Step	直接执行任意 JS	不一定调用	原始 JS 出错不会自愈

这里容易被营销文案藏掉的一件事是：自愈不是免费午餐。成熟 ACTION 可以不调用模型，但自然语言 VERIFY、DRAFT 和第一次 Heal 仍会产生 Token、延迟和非确定性。高频套件要尽快把常用 DRAFT 富化成 ACTION，把精确的金额、权限和计数断言写成确定性检查。

自愈为什么不会立刻变成“自动掩盖 Bug”

根据公开文档，运行时自愈的骨架可以压缩成下面这段伪代码。它是对公开行为的机制化表达，不是 Shiplight 私有源码：

def execute_step(step, page):
    try:
        run_cached_action(step.cache, page)
        return PASSED
    except LocatorFailure as failure:
        page_state = inspect(page)
        candidate = model.resolve(step.intent, page_state, failure)
        execute(candidate, page)
        record_heal_event(step.cache, candidate)

        if downstream_outcome_is_verified():
            stage_cache_update(candidate)
        else:
            fail_without_rewriting_intent()

四道护栏决定它是在“恢复缓存”还是“修改事实”：

1. 意图不随运行自动改。运行时不会改仓库里的 YAML。
2. 只恢复实现细节。按钮重命名可以 Heal，产品行为改变应该进入 /shiplight fix。
3. 后续结果仍须成立。点到一个“差不多的按钮”不够，业务断言要继续通过。
4. 测试通过后才持久化缓存。失败路径上的候选动作不能污染后续运行。

不过，这四道护栏仍不能证明错误自愈率足够低。Shiplight 没有公开一个可独立复核的 Heal Precision 基准。对采购方和自研团队，这都是最该压测的指标，而不是“自愈次数”。

失败之后，它卖的是归因，不只是重试

Shiplight 把失败分成四个主要桶：产品回归、规格/测试问题、测试数据、基础设施/Flake。/shiplight fix 读取失败报告、YAML、规格、相关测试和真实页面，然后做最小修复。

规则里最关键的一句是：如果应用坏了，保留失败并报告 Bug，不允许删断言或跳步骤来变绿。如果预期产品行为真的变了，要先更新规格，再更新 YAML。

GitHub 的 Auto-triage 进一步把这条流程自动化：失败后读日志、截图和 Trace；向 Slack 发诊断；可修复的测试问题会重跑并开 PR，但不自动合并，而且可限制 Agent 只改测试目录。

这也暴露了最危险的结构问题：同一个 Agent 可能写业务代码、写测试、再修测试。若目标只是“让 CI 绿”，它有充分动力改弱断言。我在Agent 写码、Agent 测码时的验证真空和面向 Agent 的交付门禁设计里都讨论过这件事。公司版产品应当进一步分离：

• 代码变更集与判决集；
• 测试修复建议与测试修复批准；
• 可见用例与 held-out 验收；
• “执行成功”与“业务终态正确”。

它怎样“越跑越聪明”

官方使用了“每次运行都更聪明”的表达。但从公开机制看，我认为更准确的名字是结构化记忆与缓存复用，而不是默认理解成客户数据微调。

它能沉淀的内容包括：

• 本地与云端 Action Cache；
• specs/context.md 中的项目级背景；
• knowledge/*.md 中的环境、角色、数据和失败经验；
• 测试规格、运行历史与失败归因；
• 录屏、Console、Network、截图和 Trace；
• 已经确认过的流程与 locator。

其中 knowledge/ 的设计很像“给后续 Agent 留值班手册”：只保存耐久事实，不保存完整对话，更不能保存密码和 Token。知识冲突时，公开 Skill 规定的优先级是当前用户指令、规格、现有测试意图、当前应用行为，最后才是上下文与知识笔记。

我亲手核过的技术足迹

这部分不是官网产品文案。我在 2026-09-18 直接读取 npm registry 元数据，并抓取文档 sitemap 计数。

npm view shiplightai version dist.unpackedSize dist.fileCount dependencies --json
npm view @shiplightai/mcp version dist.unpackedSize dist.fileCount dependencies --json
npm view @shiplightai/sdk version dist.unpackedSize dist.fileCount dependencies --json

当时得到：

包	版本	解包大小	文件数	直接依赖数
shiplightai	0.1.104	12,283,766 B	31	23
@shiplightai/mcp	0.2.2	658,925 B	15	32
@shiplightai/sdk	0.1.11	628,593 B	18	17

依赖组合能确认的技术边界包括 Node.js 22+、Playwright 1.60、MCP SDK、Vercel AI SDK，以及 OpenAI、Anthropic、Google 模型 SDK。还有 Zod、YAML、Express、Sharp 等常见运行时组件。

文档 sitemap 当时有 67 个公开入口。我没有逐行审计 npm 包实现，也没有把依赖名反推成数据库或内部服务。营销站响应可确认是 Next.js/Vercel，文档是 VitePress；Cloud App 的响应来自 Google Frontend，CSP 里允许 Stripe、PostHog、Google reCAPTCHA 以及 AWS/Google Storage 资源。再往下猜数据库、队列或 Runner 编排，证据就不够了。

商业飞轮：免费的是本地闭环，收费的是团队历史与托管资源

Shiplight 的免费入口设计得很锋利：Browser MCP、本地验证和测试创作不需要账号；BYOK 与自有 CI 也在免费计划中。Agent 在本地先得到价值，只有当测试进入团队协作后，Cloud 才自然变得有用。

收费需求依次出现：

1. 保存运行历史、视频和 Trace；
2. 跨 CI 共享自愈缓存；
3. 分析 Flake、耗时、失败归因和单测成本；
4. 使用托管 GitHub Runner；
5. 使用 LLM Proxy 而不是自行管理模型 Key；
6. 增加保留期、成员、SSO、审计和私有部署。

走查时的公开价格是 Free $0、Pro $60/月、Enterprise 合同价；LLM 按 Lite、Standard、Pro 三档计费，托管 Runner 从 $0.008/分钟 到 $0.054/分钟。这里的关键不是具体价格，而是计费单位：模型 Token + Runner 分钟 + Artifact 存储。Action Cache 命中率越高，模型成本越低；这让技术优化和毛利方向一致。

它和相邻产品真正差在哪里

产品	更像什么	相比 Shiplight 的强项	Shiplight 的差异
Playwright	确定性浏览器测试底座	免费、成熟、完全可控	多了 Agent 工作流、语义层和云端闭环
Stagehand	Browser Agent SDK	浏览器 Agent 原语、开源生态	不是完整测试生命周期平台
Momentic	最直接的 AI 测试平台	Web + iOS + Android、规模数据更成熟	Shiplight 更强调 Coding Agent、Git 所有权与可退出
mabl	企业全栈测试平台	Web、Mobile、API、性能、可访问性更广	Shiplight 更轻、更靠近开发代理工作流
QA Wolf	平台加托管 QA 服务	直接替客户承担覆盖建设	Shiplight 是客户自己掌控的工具链

我认为 Shiplight 最有辨识度的不是“AI 测试”，而是四件事一起出现：同一个 Coding Agent 能调用；测试留在 Git；正常路径确定性执行；失败之后能回到 Agent 修复循环。

公开边界与采购风险

1. Web-first，不等于全平台测试

它可以用 Playwright 跑 Chromium、Firefox、WebKit，也支持移动 viewport 和 Chrome Extension，但这不等于原生 iOS/Android 自动化。移动优先团队需要单独评估。

2. AI 断言仍然是概率系统

自然语言 VERIFY 可能受模型版本、页面噪声和上下文裁剪影响。金额、权限、唯一性、数量、审计记录等高风险断言，应该优先落到代码、API 或数据库检查。

3. 独立客户证据仍少

官网展示的 HeyGen 等案例有参考价值，但成效数字来自卖方公开材料，不能直接外推到别的团队。真正的 POC 应测错误自愈率、归因准确率、人工维护小时和每个测试的模型成本。

4. SOC 2 表述要看正式状态

官网多处写 “SOC 2 compliant”，但我走查时 Trust Center 显示 SOC 2 Type I Compliant、Type II In Progress。企业采购应以 Trust Center 和可申请的正式报告为准，而不是营销页的一句话。

5. 产品仍在快速换代

Cloud v1、Cloud v2、旧 Webhook/Test Plan 与新 Runner 文档同时存在；CLI 从 2026 年 2 月到 9 月发布了大量 0.1.x 版本。这说明团队迭代很快，也意味着接入方要做好版本固定和回归验证。

如果公司要做对等产品，先做哪一半

我的建议不是一上来复制整个功能表，而是把产品定位收窄为：

公司内部的 Coding Agent 验证与可持续回归平台：Agent 改完代码后，能在真实浏览器里证明它工作，并把这次证明保存成以后可重复运行的测试。

P0：8–12 周的内部 MVP

假设团队 6–8 人，第一阶段只做六件事：

1. Browser MCP：Session、Snapshot、Screenshot、Click、Fill、Navigate、Upload、Console、Network、Trace。
2. 三个 Skill：verify、create-test、fix。
3. 自有测试 IR：稳定意图、缓存动作、确定性断言、变量、认证和清理。
4. Hybrid Runtime：缓存优先，失效时模型返回结构化 action，测试通过后才提交缓存。
5. CLI：test、transpile、debug、report。
6. GitHub Actions 模板与本地 HTML 报告。

第一阶段不要做托管 Runner、录屏市场、复杂 Dashboard、计费系统或自建模型。它们会让产品看起来完整，却不能证明核心闭环可靠。

P1：团队协作与失败闭环

核心运行时稳定后，再补：

• Run、Attempt、StepResult、Artifact 数据模型；
• 共享 Action Cache 与 Heal Event 审计；
• GitHub App、PR Check 与结果回链；
• 失败归因和自动修复 PR；
• Slack 或飞书通知；
• RBAC、Token Scope、审计日志和保留策略。

P2：商业化与差异化

最后才轮到：

• 产品录屏转测试；
• 托管 Runner；
• 邮件与短信测试；
• UI + API + DB + 日志的 Agent Verification；
• VPC、私有化和数据驻留；
• 原生移动测试；
• 覆盖知识图谱与跨项目分析。

自研时最不能照抄的五个地方

1. 不要复制 YAML 表面语法。先定义自己的语义模型和版本化策略；行为可以对等，表达不必一样。
2. 不要让 Heal 静默发生。每次保存原 locator、新 locator、页面指纹、模型、后续断言和批准状态。
3. 不要让写代码的 Agent 独占 Oracle。高风险测试必须有独立上下文、CODEOWNERS 或 held-out 验收。
4. 不要把秘密放进模型上下文。变量值要可屏蔽，页面、日志、录屏和 Trace 要有脱敏与生命周期策略。
5. 不要先造浏览器和模型。Playwright 与现有模型足够；真正该自研的是 IR、Cache、安全护栏、证据链和失败归因。

长期护城河也不在 MCP 工具数量。公开 Skill 和基础浏览器动作很容易追平。真正难复制的是：每次测试执行产生的 Heal 数据、失败归因数据、跨环境缓存命中、测试资产与业务规格的关系，以及团队对这些证据的信任。

小结

Shiplight 的根本设计不是“让 AI 写测试”，而是把稳定意图与易变页面实现分离：意图留在 Git，locator 退化成可失效、可重建的缓存。

最朴素的两条替代路线会在不同地方先崩：纯 Playwright 崩在维护量，纯 Agent 执行崩在成本、延迟和随机性。Shiplight 用确定性快路径与 AI 慢路径把两者接起来，再用证据、归因和修复 PR 把失败送回开发循环。

如果只借一个设计，就借这条；如果准备做产品，第一版只证明三件事：Agent 能走通真实流程、测试第二次能确定性重放、UI 改动后不会错误自愈。其余能力都可以后加。

一个半天能启动的 POC

挑公司里一条 8–15 步、需要登录、过去半年改过两次 UI 的核心流程。用现有 Coding Agent 加 Playwright 做三个版本：纯生成脚本、每步自然语言执行、意图加 locator 缓存。然后记录五个数：首次作者时间、第二次运行耗时、模型调用数、改按钮名称后的恢复结果、是否点错元素仍然通过。

这半天不需要 Cloud、不需要 Dashboard，也不需要先决定买还是造。它会直接告诉你：你们的真实瓶颈在测试生成、执行成本、维护，还是 Oracle 本身。

参考来源

Shiplight 一手产品与工程资料

• Shiplight 官网
• Quick Start
• Agent-Driven Testing
• MCP Tool Reference
• YAML E2E Tests
• Statement Types
• How self-healing works
• Where tests run
• CI/CD 与 Auto-triage
• Shiplight Cloud
• API Tokens 与 LLM Proxy
• 官方定价
• Trust Center
• 公开 Agent Skills
• YAML 示例与语言规范

相邻产品

• Playwright
• Stagehand
• Momentic
• mabl
• QA Wolf