我们为关心每个指标的客户交付无头网站——Core Web Vitals、结构化标记、无障碍访问评分、有机流量差值。一次糟糕的部署可能会摧毁耗时数月建立的排名。所以当 Anthropic 在 Claude Code 中推出子代理、钩子和技能时，我们围绕这些功能重建了整个前置部署流程。

本文介绍了我们的确切设置：.claude/ 目录结构、每个子代理定义、钩子配置以及将所有内容联系在一起的技能文件。我们将分享该系统捕获的四个真实事件、我们规模下的投资回报率计算，以及这种方法仍然存在的差距。

我们遭遇了 40% 的 CLS 激增，但它仍然进入了生产环境

三周前。客户的博客重设计。在开发中一切看起来都很好。我们合并了。

两天后，他们的 CTO 发送了一张来自 Search Console 的截图。CLS 在移动设备上从 0.08 跃升至 0.14。排名第 3 的"企业计费软件"页面下降到第 8。收入影响？他们估计每月 40,000 美元。

问题是什么？一张异步加载但没有大小属性的英雄图像。经典问题。我们的 CI 没有捕获任何内容，因为我们没有在实际的预览版本上检查布局偏移。

那时我们开始研究子代理。

子代理是作用域受限的 Claude Code 实例，在父会话内运行，具有自己的系统提示、工具访问和任务边界。钩子在特定点触发子代理——在命令运行之前、文件更改后或提交时。技能是可重用的说明文件（markdown），它们教 Claude 如何执行特定任务。

Anthropic 在 2025 年 4 月 14 日推出了重设计，同时推出了与这些基元配对的 Routines。对于我们的用例，原始子代理加钩子为我们提供了更精细的控制，精确控制每个检查何时触发以及它接收什么上下文。

与传统 CI 检查的关键区别：子代理可以推理结果、关联跨检查失败，并编写人类可读的摘要。CI 作业返回退出代码 0 或 1。子代理返回"结构化数据在 /blog/[slug] 上缺少 dateModified 字段，该字段在之前的版本中存在。这可能会在 3-5 天内导致 Google Search Console 中的丰富摘要回归。"

这就是全部意义所在。

三个月后，我们的 GitHub Actions 设置最终破裂了

我们之前的流程是 GitHub Actions 调用 Lighthouse CI、pa11y、linkinator 和自定义 Node 脚本的一团混乱。它能工作。

勉强。

但它有三个问题。

检查之间没有推理。 如果 Lighthouse 标记了 CLS 问题，而无障碍扫描在同一图像上标记了缺失的 alt 标签，我们会收到两个单独的警报且没有任何连接。工程师必须手动 grep 通过 CI 日志、关联时间戳、找出这是同一个组件。

浪费时间。

脆弱的配置。 每个工具都有自己的配置文件、阈值格式和输出架构。更新阈值意味着要接触 4-6 个文件。这里是 YAML。那里是 JSON。第三个地方是环境变量。一个打字错误，整个流程在应该失败时退出 0。

没有上下文解释。 工程师得到通过/失败。初级开发人员花费 20-40 分钟来理解为什么某些东西失败以及该怎么办。"无障碍得分：87"不会告诉你哪个 ARIA 属性丢失或为什么它对屏幕阅读器很重要。

我们每周花费 3 小时调试误报或在 Slack 中解释失败。

最后的压力？2025 年 8 月。我们在周五下午 4 点推送了一个 Northwind Traders 重设计（我知道）。Lighthouse 通过了。无障碍通过了。链接通过了。我们发布了。

周一早上，他们的市场营销副总裁给我们发来电子邮件。"为什么我们的产品页面从 Google 消失了？"事实证明我们意外地在 /products/ 下的每个页面上将 robots meta 设置为 noindex。我们的 CI 没有检查 robots 标签。花了六天才能重新索引。他们损失了大约 12,000 美元的收入。

我们不需要另一个 CI 工具——我们需要一个可以推理我们已经信任的工具输出的编排层。编写良好的技能文件是子代理能够进行无障碍规则幻觉和能够使用正确标志运行 pa11y 并正确解释 JSON 输出之间的区别。

我们的 .claude/ 目录结构

这是实际的树：

.claude/
├── settings.json
├── agents/
│   ├── seo-regression.md
│   ├── cwv-smoke.md
│   ├── accessibility.md
│   ├── broken-links.md
│   ├── schema-validation.md
│   └── deploy-gate.md
├── skills/
│   ├── run-lighthouse.md
│   ├── run-pa11y.md
│   ├── run-linkinator.md
│   ├── parse-schema-org.md
│   ├── compare-seo-snapshot.md
│   └── format-deploy-report.md
└── snapshots/
    └── seo-baseline.json

snapshots/ 目录包含用于比较检查的基线数据。很简单。我们在 Git 中对其进行版本控制，以便我们可以看到当客户询问"为什么排名在上周二下降"时发生了什么变化。

没什么花哨的。只是 markdown 文件和 JSON。

一个客户在晚上 11 点打来电话，因为 Google 删除了他们所有的丰富摘要

2025 年 9 月。我们正在为一家中等规模的零售商建立一个电子商务网站（我们称之为 Acme Home Goods）。他们花了六个月的时间让丰富摘要——产品星级、定价、可用性——出现在搜索结果中。

我们推送了一个 Shopify 主题更新。看起来很好。周五晚上发布。

周六晚上 11:14，我收到一条短信。"我们的产品页面在 Google 中看起来被破坏了。星号消失了。价格消失了。发生了什么？"

我打开 Search Console。每个产品页面都抛出结构化数据错误。offers 字段缺少 priceCurrency。没有它，Google 不会显示丰富摘要。排名没有下降，但点击率从 4.2% 下降到 1.8%，一夜之间。

成本？在我们修复它并且 Google 重新爬取所有内容之前，每周大约 8,000 美元的流量损失。

schema 在那里。我们只是将属性名称从 priceCurrency 更改为 currency，因为 Shopify API 使用该键。没想到。没有验证捕获它。

那时我们构建了 schema-validation 子代理。

您在 .claude/agents/ 中创建一个 markdown 文件，其中包含系统提示、允许的工具列表和任务说明。父会话（或钩子）使用 dispatch_agent() 或通过 settings.json 中的钩子配置生成它。

最小结构：

# Agent: [Name]

## Role
[单行描述]

## Allowed Tools
- Bash（限制为特定命令）
- Read file
- Write file

## Instructions
[分步任务描述，引用技能文件]

## Output Format
[父级期望的确切格式]

对输出格式要非常具体。如果 deploy-gate 编排器期望 JSON 具有 passed 布尔值和 summary 字符串，请明确说明。返回自由文本的子代理会破坏编排。我们在子代理返回 markdown 表格而 deploy gate 无法解析它们时学到了这一点。花了我两小时在凌晨 2 点进行调试，因为父级只是以静默方式失败。没有错误。只是没有触发部署块。

别犯我的错误。锁定格式。

子代理 1：SEO 回归检查

这会将当前版本的 SEO 关键元素与存储的基线快照进行比较。

# Agent: SEO Regression Check

## Role
检测当前版本和存储的基线之间的 SEO 回归。

## Allowed Tools
- Bash（仅限 node 脚本）
- Read file

## Instructions
1. 阅读位于 .claude/skills/compare-seo-snapshot.md 的技能文件
2. 运行：node scripts/extract-seo-meta.js --url=$PREVIEW_URL --output=/tmp/seo-current.json
3. 阅读 .claude/snapshots/seo-baseline.json
4. 逐个字段比较两个快照：
   - title 标签（完全匹配）
   - meta 描述（相似度 > 0.85）
   - canonical URL（完全匹配）
   - h1 计数（每个页面必须等于 1）
   - robots meta（不能更改为 noindex）
   - Open Graph 标签（og:title、og:description、og:image 存在）
5. 将 robots 更改为 noindex 的任何页面标记为 CRITICAL。
6. 将缺失或重复的 title 标签标记为 HIGH。
7. 将元描述更改 > 15% 不同的标记为 MEDIUM。

## Output Format
{"passed": boolean, "critical": [], "high": [], "medium": [], "summary": string}

extract-seo-meta.js 脚本是 120 行 Puppeteer，它点击 sitemap 中的每个页面并将 title、meta、canonicals、h1 和 OG 标签转储到 JSON。没什么聪明的。只是提取。

子代理的价值在于比较和推理，而不是提取。它知道哪些变化很重要。哪些变化是表面的。哪些变化将在下个季度花费客户 15,000 美元的有机流量。

示例：如果你将元描述从"2025 年面向小企业的最佳 CRM 软件"更改为"面向小企业的最佳 CRM 软件"，相似度得分为 0.91。那没问题。但如果它更改为"CRM 软件"，相似度会下降到 0.65。子代理将其标记为 MEDIUM，因为这是关键字密度减少了 40%，可能会伤害点击率。

这不仅仅是 diff。这是关于 diff 意味着什么的推理。

到目前为止，我们用这个捕获了四个问题。robots noindex 的事情。有人删除了所有 OG 图像的情况（会破坏社交分享）。title 标签被截断为 40 个字符而不是 60 个的情况（看起来不太好，对 SEO 没有影响，但客户会注意到）。还有一个 canonical URL 从 https:// 更改为 http:// 的情况（会导致重复内容处罚）。

每一个都会花费我们至少几个小时的清理和客户信任。可能更多。

我们将 seo-baseline.json 存储在 repo 中，并在部署成功钩子中进行更新。

子代理 2：Core Web Vitals 烟雾测试

# Agent: CWV Smoke Test

## Role
在关键页面上运行 Lighthouse 并标记 CWV 回归。

## Allowed Tools
- Bash

## Instructions
1. 阅读 .claude/skills/run-lighthouse.md
2. 针对以下页面的 $PREVIEW_URL 运行 Lighthouse CI：
   - / (首页)
   - /blog/ (列表)
   - /blog/[most-recent-post] (详情)
   - /services/ (如果存在)
3. 阈值（如果任何低于则失败）：
   - LCP: 2500ms
   - FID/INP: 200ms
   - CLS: 0.1
   - Performance score: 85
   - Accessibility score: 90
4. 如果一个指标相比之前的运行回归超过 10%，
   即使仍在阈值之上，也将其标记为 WARNING。
5. 包括导致 Lighthouse 报告的 LCP 或 CLS 的特定元素。

## Output Format
{"passed": boolean, "pages": [{"url": string, "scores": {}, "flags": []}], "summary": string}

相关的技能文件（run-lighthouse.md）包含确切的 lhci CLI 调用：

# Skill: Run Lighthouse

## Command
```bash
npx @lhci/cli@0.14.0 collect \
  --url="$1" \
  --numberOfRuns=3 \
  --settings.preset=desktop \
  --settings.output=json \
  --settings.outputPath=/tmp/lhci-results/

Parsing

从 /tmp/lhci-results/ 中读取中位数运行。提取：

• categories.performance.score * 100
• audits['largest-contentful-paint'].numericValue
• audits['cumulative-layout-shift'].numericValue
• audits['interaction-to-next-paint'].numericValue (如果存在)

## 子代理 3：无障碍扫描

```markdown
# Agent: Accessibility Scan

## Role
针对预览 URL 运行 pa11y 并报告 WCAG 2.1 AA 违规。

## Allowed Tools
- Bash

## Instructions
1. 阅读 .claude/skills/run-pa11y.md
2. 针对与 CWV 代理相同的页面集运行 pa11y。
3. 按严重程度对结果进行分组：error、warning、notice。
4. 对于每个错误，包括：
   - 违反的 WCAG 准则（例如 1.1.1 Non-text Content）
   - HTML 元素（选择器）
   - 单句修复建议
5. 如果存在任何错误，则失败。如果警告 > 10，则警告。

## Output Format
{"passed": boolean, "error_count": number, "warning_count": number, "errors": [{"criterion": string, "selector": string, "fix": string}], "summary": string}

我们使用 pa11y@8.0.0 与 --runner=axe 标志。默认 htmlcs 运行器错过了一些 axe 捕获的颜色对比问题。

子代理 4：破坏链接扫描

# Agent: Broken Link Scan

## Role
爬取预览网站并报告破坏的内部和外部链接。

## Allowed Tools
- Bash

## Instructions
1. 阅读 .claude/skills/run-linkinator.md
2. 运行：npx linkinator@6.1.2 $PREVIEW_URL --recurse --timeout 15000 --format json > /tmp/link-results.json
3. 过滤状态 >= 400 或状态 === 0（超时）的结果。
4. 将内部（同一域）与外部破坏的链接分开。
5. 内部破坏的链接是 CRITICAL。外部破坏的链接是 WARNING。
6. 排除已知不稳定的外部域：twitter.com、linkedin.com（它们阻止爬虫）。

## Output Format
{"passed": boolean, "internal_broken": [{"source": string, "target": string, "status": number}], "external_broken": [...], "summary": string}

子代理 5：Schema 验证

# Agent: Schema Validation

## Role
验证所有页面上的 JSON-LD 结构化数据。

## Allowed Tools
- Bash
- Read file

## Instructions
1. 阅读 .claude/skills/parse-schema-org.md
2. 对于 sitemap 中的每个页面：
   a. 提取所有 <script type="application/ld+json"> 块
   b. 解析为 JSON（如果格式错误则失败）
   c. 根据 @type 验证必需字段：
      - Article: headline、datePublished、dateModified、author、image
      - LocalBusiness: name、address、telephone
      - WebPage: name、description
      - BreadcrumbList: itemListElement with position、name、item
   d. 检查所有 @id 引用是否在页面的图表中解析
   e. 验证 schema 中的 URL 是绝对的，不是相对的
3. 将缺失的必需字段标记为 HIGH。
4. 将格式错误的 JSON 标记为 CRITICAL。

## Output Format
{"passed": boolean, "pages": [{"url": string, "schemas": [{"type": string, "valid": boolean, "issues": []}]}], "summary": string}

子代理 6：部署门卫编排器

这个父代理生成其他五个代理并做出执行/否执行决定。

# Agent: Deploy Gate

## Role
编排所有前置部署检查并做出最终部署决定。

## Allowed Tools
- Bash
- Read file
- Write file
- dispatch_agent

## Instructions
1. 并行生成这些代理：
   - .claude/agents/seo-regression.md
   - .claude/agents/cwv-smoke.md
   - .claude/agents/accessibility.md
   - .claude/agents/broken-links.md
   - .claude/agents/schema-validation.md
2. 收集所有输出。
3. 阅读 .claude/skills/format-deploy-report.md
4. 决定逻辑：
   - 如果任何代理有 CRITICAL 标志：BLOCK 部署。
   - 如果 2 个或更多代理有 HIGH 标志：BLOCK 部署。
   - 如果 1 个代理有 HIGH 标志：WARN，需要手动覆盖。
   - 否则：APPROVE。
5. 将完整报告写入 /tmp/deploy-report.md
6. 输出决定。

## Output Format
{"decision": "APPROVE" | "WARN" | "BLOCK", "reports": {agent_name: agent_output}, "summary": string}

钩子配置：settings.json

这是我们的实际 settings.json（客户特定的 URL 已编辑）：

{
  "hooks": {
    "pre-commit": [
      {
        "agent": ".claude/agents/schema-validation.md",
        "condition": "files_changed_match('**/*.json', '**/structured-data/**')",
        "env": {
          "PREVIEW_URL": "http://localhost:3000"
        }
      }
    ],
    "pre-push": [
      {
        "agent": ".claude/agents/deploy-gate.md",
        "env": {
          "PREVIEW_URL": "$VERCEL_PREVIEW_URL"
        },
        "timeout": 300,
        "on_failure": "block"
      }
    ],
    "post-deploy-success": [
      {
        "command": "node scripts/extract-seo-meta.js --url=$PRODUCTION_URL --output=.claude/snapshots/seo-baseline.json",
        "description": "Update SEO baseline after successful deploy"
      }
    ]
  },
  "agent_defaults": {
    "model": "claude-sonnet-4-20250514",
    "max_tokens": 8192,
    "timeout": 120
  },
  "skills_directory": ".claude/skills/"
}

关于此配置的说明：

• 我们为子代理使用 claude-sonnet-4-20250514，而不是 Opus。这里的推理任务不能证明成本差异是合理的。Sonnet 可以很好地处理"比较两个 JSON 对象并标记差异"。
• 部署门卫上的 timeout: 300 给所有五个子代理时间来运行。单个代理有 120 秒的默认值。编排器获得 5 分钟，因为它等待所有内容。
• 前置提交钩子上的 condition 意味着 schema 验证仅在您接触 schema 相关文件时运行。在 CSS 更改时运行没有意义。
• post-deploy-success 更新基线。没有这个，你的 SEO 回归检查会与陈旧的数据进行比较。

粘合在一起的技能定义

工作最多的技能文件是 compare-seo-snapshot.md：

# Skill: Compare SEO Snapshots

## Purpose
比较两个 SEO 元数据快照并识别回归。

## Input
- Current snapshot: /tmp/seo-current.json
- Baseline snapshot: .claude/snapshots/seo-baseline.json

## Comparison Rules

### Title Tags
- 如果标题更改并且该页面的有机流量（来自基线元数据）> 1000 个会话/月，标记为 HIGH。
- 如果标题现在为空或与另一页面的标题匹配，标记为 CRITICAL。
- 如果低流量页面上的标题更改，标记为 MEDIUM。

### Canonical URLs
- canonical URL 的任何更改都是 HIGH。
- 指向不同域的 canonical 是 CRITICAL。
- 缺失 canonical（存在，现在消失）是 HIGH。

### Robots Meta
- 任何获得"noindex"的页面都是 CRITICAL。
- 任何在内部链接上获得"nofollow"的页面都是 HIGH。

### New Pages
- 当前中的页面但不在基线中的是 INFO（新内容的预期）。
- 但验证它们有：title、meta description、canonical、至少一个 h1。

### Removed Pages
- 基线中但不在当前中的页面是 HIGH。
- 这些可能表示意外的路由删除。

这个技能文件将数月的 SEO 事件响应编码成 Claude 可以可靠遵循的格式。没有它，子代理会对构成回归的内容做出合理但不一致的判断。

系统捕获的四个事件

事件 1：意外的 47 个博客文章上的 noindex

客户： B2B SaaS 公司，200 个页面，60k 有机会话/月。

一位开发者更新了博客模板中的 <Head> 组件以添加新的 meta 标签。他们从具有 <meta name="robots" content="noindex, nofollow"> 硬编码的暂存配置中复制粘贴。更改通过了代码审查，因为审查者专注于新标签，而不是现有标签。

SEO 回归子代理将 47 个页面标记为 CRITICAL——robots meta 更改为 noindex。部署被阻止。

检测时间： 推送后 2 分 14 秒。没有该系统，当 Search Console 在 3-7 天后显示覆盖率下降时，它会被捕获。

避免的预计影响： 这 47 篇文章推动了大约 14,000 美元/月的管道。即使是一周的 deindex 事件也可能花费 3,500 美元以上。

事件 2：来自新英雄图像的 CLS 回归

客户： 电子商务品牌，Next.js 14 商城在 Shopify Hydrogen 上。

设计团队将首页英雄交换为具有不同纵横比的新图像，但没有更新 <Image> 组件上的宽度/高度属性。图像加载良好，但导致 CLS 为 0.34——远高于 0.1 阈值。

CWV 烟雾测试子代理报告了首页上的 CLS 回归。总结特别指出："CLS 由元素 img.hero-banner 引起，移动 0.34 累积。图像尺寸 (1920x800) 与容器纵横比 (16:9 = 1920x1080) 不匹配。添加显式 width={1920} height={800} 或更新容器。"

检测时间： 1 分 47 秒。

事件 3：URL 重组后的破坏内部链接

客户： 专业服务公司，80 个页面。

我们将他们的服务页面从 /services/[name] 重组为 /[category]/[name]。重定向已就位，但三篇博客文章有指向旧 URL 的硬编码链接，CMS 驱动的导航有一个缓存条目指向已删除的页面。

破坏链接扫描发现了 4 个内部 404s。子代理的摘要指出，4 个中的 3 个在博客文章正文内容中（不在导航中），这意味着它们被重定向审计错过了。

检测时间： 3 分 8 秒。linkinator 爬取是最慢的部分。

事件 4：Article schema 中缺失 dateModified

客户： 媒体公司，2,000 篇文章。

从 WordPress 到 Sanity 的 CMS 迁移丢失了 dateModified 字段映射。schema 生成代码回退为 dateModified 的 null，这产生了无效的 JSON-LD。

schema 验证子代理将每个文章页面标记为 HIGH——缺少必需的 dateModified 字段。摘要说明："Google 需要 Article 结构化数据的 dateModified 才能够进入顶部故事和丰富结果。所有 2,147 个文章页面都受到影响。"

检测时间： 4 分 22 秒（大型 sitemap）。

投资回报率：每次发布节省的分钟数和每月节省的美元

这是我们的计算：

指标	之前（CI + 手动）	之后（子代理）	Delta
每次部署的检查	4 个工具，手动审查	5 个代理，自动化	+1 检查，-100% 手动审查
运行所有检查的时间	8-12 分钟（顺序 CI）	3-5 分钟（并行子代理）	-60%
理解失败的时间	每次失败 20-40 分钟	1-2 分钟（上下文摘要）	-90%
每周部署（所有客户）	18	18	相同
误报率	~15%（嘈杂的 Lighthouse）	~4%（推理过滤噪声）	-73%

每次发布节省的分钟数： 当检查失败时平均 25 分钟（30% 的部署）。那是 25 × 5.4 失败部署/周 = 135 分钟/周 = 9 小时/月。

系统成本：

• 子代理的 Claude API 成本：~$0.12 每个完整部署门卫运行（5 个代理，Sonnet，每个代理平均 6,000 个 token）
• 每周 18 个部署 × 4.3 周 × $0.12 = $9.29/月 API 成本
• Puppeteer/Lighthouse 基础设施：在现有 Vercel 构建实例上运行，无添加成本
• 维护时间：每月约 2 小时更新技能文件和阈值

工程师时间节省的美元价值： 9 小时/月 × $85/小时（我们团队的混合费率）= $765/月节省。

防止的事件的美元价值： 根据上述四起事件，noindex 事件本身可能花费 3,500 美元。如果我们每季度防止一个这样的事件，那是 $1,166/月 避免的客户影响。

净投资回报率：$1,920/月的价值对 $9.29/月的 API 成本。 这是 206 倍的回报。即使您将 API 成本增加 10 倍以扩大团队规模，它仍然是有利的。

差距以及我们会改变什么

这个系统并不完美。以下是仍然粗糙的内容：

没有视觉回归测试。 子代理可以运行 Lighthouse 和 pa11y，但不能查看截图并说"英雄部分被破坏了。" 我们在关注 Claude 的视觉功能。

基线漂移。 SEO 基线在成功部署时更新，但如果您发布了系统没有捕获的回归，它将成为新的基线。我们每月手动审查基线。

外部链接不稳定性。 Twitter/X、LinkedIn 和一些政府网站阻止爬虫或进行激进的速率限制。我们维护一个排除列表，但需要手动更新。

冷启动时间。 克隆 repo 后的首次运行耗时较长，因为 npx 需要获取包。我们考虑在 Docker 层中预安装 CLI 工具。

Anthropic 速率限制。 同时生成 5 个子代理可能会在 Claude API 的高峰时间偶尔触发速率限制。我们在生成之间添加了 2 秒的错开，这有效但不优雅。

我们更长的代理定义（schema 验证是 400 字）有时会比更短的定义产生更少的结构化输出。我们考虑将 schema 验证代理拆分为每类型的子子代理。

常见问题

Claude Code 子代理是否适用于任何 LLM，还是仅限于 Claude？

子代理是与 Anthropic API 绑定的 Claude Code 功能。您需要有权访问 Claude Code 的 Claude API 密钥。代理定义格式特定于 Claude Code 的 .claude/ 目录约定，不是一般标准。

运行五个子代理每次部署的 API 费用成本是多少？

在我们的规模上，使用 Claude Sonnet 每个完整部署门卫运行大约 $0.12。这大约是每周 18 次部署的 $9-10/月。Opus 的成本大约高 5 倍，但我们还没有发现这些任务需要这么做。

子代理能否在 GitHub Actions 等 CI/CD 流程中运行？

是的。您可以在 CI 环境中无头调用 Claude Code。我们通过 webhook 在 Vercel 预览部署完成时触发我们的，该 webhook 调用 claude-code run .claude/agents/deploy-gate.md，预览 URL 作为环境变量。

Claude Code 技能和子代理有什么区别？

技能是 markdown 说明文件，教 Claude 如何做某事——像一个食谱。子代理是一个隔离的 Claude 实例，可以生成自己的上下文和工具。子代理使用技能。将技能视为文档，将代理视为工人。

您是否需要 Anthropic 的 Routines 功能，或原始子代理是否足够？

对于我们的部署门卫工作流程，原始子代理加上 settings.json 中的钩子就足够了。如果我们的部署检查超出六个代理，Routines 会添加一个更高级别的编排层。我们可能会采用 Routines。

您如何处理子代理故障或超时？

每个子代理都有 120 秒的超时。如果子代理失败或超时，部署门卫编排器将其视为 WARN，而不是 BLOCK。我们宁愿在检查不完整的情况下发布，也不愿因为 Lighthouse 挂起而阻止部署。摘要说明了哪些检查未完成。

这种方法能否替代 Lighthouse CI 或 pa11y 等专用工具？

不——它包装了它们。子代理通过 bash 调用这些工具，然后推理输出。您仍然需要安装底层工具。价值在于编排、关联和自然语言报告层，而不是替代扫描仪。