Claude 程式碼子代理：我們的生產工作流程，實現安全部署
我們為測量一切的客戶部署無頭網站 -- Core Web Vitals、結構化標記、無障礙評分、自然搜尋流量變化。一次不良部署可能會摧毀花費數月建立的排名。所以當 Anthropic 推出 Claude Code 中的子代理、掛鉤和技能時，我們圍繞它們重建了整個部署前管道。
這篇文章介紹了我們的確切設置：.claude/ 目錄結構、每個子代理定義、掛鉤配置，以及將它們全部整合在一起的技能文件。我們將分享系統捕獲的四個真實事件、我們規模的投資回報率數學，以及這種方法仍存在的空白。
我們遇到 40% 的 CLS 激增，但它仍然上線了
三週前。客戶的部落格重新設計。在開發環境中一切看起來都很好。我們合併了。
兩天後他們的 CTO 寄來了一張來自 Search Console 的截圖。CLS 在行動設備上從 0.08 飆升至 0.14。在「企業帳單軟體」中排名第 3 的頁面跌落到第 8。收入影響？他們估計為 $40k/月。
問題是什麼？一張非同步載入但沒有大小屬性的英雄圖像。典型的問題。我們的 CI 沒有捕獲任何東西，因為我們沒有在實際預覽版本上檢查佈局移位。
那時我們開始查看子代理。
子代理是在父階段內運行的作用域化 Claude Code 實例，具有自己的系統提示、工具存取和任務邊界。掛鉤在特定點觸發子代理 -- 在命令執行前、檔案變更後或提交時。技能是可重複使用的指令文件（markdown），教導 Claude 如何執行特定任務。
Anthropic 在 2025 年 4 月 14 日推出了該重新設計，在這些基元旁邊推出了例程。對於我們的用例，原始子代理加上掛鉤讓我們對每個檢查何時觸發及它接收什麼上下文擁有更精細的控制。
與傳統 CI 檢查的主要區別：子代理可以推理結果、將故障關聯到多個檢查中，並撰寫人類可讀的摘要。CI 工作返回退出代碼 0 或 1。子代理返回「/blog/[slug] 上的結構化數據缺少 dateModified 欄位，該欄位在前一次構建中存在。這可能會在 3-5 天內導致 Google Search Console 中的豐富摘要回歸。」
這就是整個重點。
三個月後，我們的 GitHub Actions 設置最終讓我們崩潰了
我們先前的管道是一系列 GitHub Actions 呼叫 Lighthouse CI、pa11y、linkinator 和自訂 Node 指令碼。它可以運作。
有點。
但它有三個問題。
檢查之間沒有推理。 如果 Lighthouse 標記了 CLS 問題，無障礙掃描在同一影像上標記了缺少的 alt 標記，我們會收到兩個單獨的警報，彼此沒有關連。工程師必須手動在 CI 日誌中進行 grep、關聯時間戳記、弄清楚這是同一個元件。
浪費時間。
脆弱的配置。 每個工具都有自己的配置檔案、閾值格式和輸出結構。更新閾值意味著觸及 4-6 個檔案。這裡是 YAML。那裡是 JSON。第三個地方是環境變數。一個錯字，整個管道就會在應該失敗時以退出代碼 0 退出。
沒有上下文說明。 工程師得到通過/失敗。初級開發人員花費 20-40 分鐘來理解為什麼某事失敗以及如何處理。「無障礙評分：87」並不能告訴你缺少哪個 ARIA 屬性或為什麼它對螢幕閱讀器很重要。
我們每週花費 3 小時來調試誤報或在 Slack 中解釋失敗。
最後一根稻草？2025 年 8 月。我們在週五下午 4 點推出了 Northwind Traders 重新設計（我知道）。Lighthouse 通過。無障礙通過。連結通過。我們上線了。
週一上午他們的行銷副總裁寫信給我們。「為什麼我們的產品頁面從 Google 消失了？」原來我們不小心在 /products/ 下的每個頁面上將 robots meta 設定為 noindex。我們的 CI 沒有檢查 robots 標記。花了六天才能重新編列索引。他們損失了估計的 $12k 收入。
我們不需要另一個 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 重新爬取所有內容，每週大約損失 $8k 的流量。
結構化資料就在那裡。我們只是將屬性名稱從 priceCurrency 改為 currency，因為 Shopify API 使用該金鑰。沒有想到。沒有驗證捕獲它。
那時我們建立了 schema-validation 子代理。
您在 .claude/agents/ 中建立一個 markdown 檔案，其中包含系統提示、允許的工具清單和任務說明。父階段（或掛鉤）使用 dispatch_agent() 或通過 settings.json 中的掛鉤配置來生成它。
最小結構：
# Agent: [Name]
## Role
[單行描述]
## Allowed Tools
- Bash (restricted to specific commands)
- Read file
- Write file
## Instructions
[逐步任務說明，參考技能檔案]
## Output Format
[父代理預期的確切格式]
對輸出格式要非常具體。如果部署閘門協調器預期 JSON 帶有 passed 布林值和 summary 字串，請明確指出。傳回自由形式文本的子代理會中斷協調。我們在一個子代理傳回 markdown 表格而部署閘門無法解析它們時學到了這一點。花了我凌晨 2 點時兩個小時來調試，因為父代理只是靜靜地失敗了。沒有錯誤。只是沒有觸發部署塊。
不要犯我的錯誤。鎖定格式。
子代理 1：SEO 回歸檢查
這將當前構建的 SEO 關鍵元素與基準快照進行比較。
# Agent: SEO Regression Check
## Role
偵測當前構建和儲存的基準之間的 SEO 回歸。
## Allowed Tools
- Bash (node scripts only)
- 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. 將 meta 描述變更 > 15% 不同的標記為 MEDIUM。
## Output Format
{"passed": boolean, "critical": [], "high": [], "medium": [], "summary": string}
extract-seo-meta.js 指令碼是 120 行 Puppeteer，會點擊網站地圖中的每一頁，並將 title、meta、canonicals、h1 和 OG 標籤轉儲到 JSON。沒有什麼聰明的。只是提取。
子代理的價值在於比較和推理，而不是提取。它知道哪些變更很重要。哪些是表面的。哪些會在未來一個季度內花費客戶 $15k 的自然流量。
範例：如果您將 meta 描述從「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 並將其作為部署成功掛鉤的一部分進行更新。
子代理 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
- 效能評分: 85
- 無障礙評分: 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：結構化資料驗證
# Agent: Schema Validation
## Role
驗證所有頁面上的 JSON-LD 結構化資料。
## Allowed Tools
- Bash
- Read file
## Instructions
1. 讀取 .claude/skills/parse-schema-org.md
2. 對於網站地圖中的每一頁：
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，帶有 position、name、item
d. 檢查所有 @id 參考是否在頁面圖形中解決
e. 驗證結構化資料中的 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意味著結構化資料驗證只在您觸及與結構化資料相關的檔案時執行。在 CSS 變更中運行它沒有意義。 post-deploy-success更新基準。沒有這個，您的 SEO 回歸檢查會與陳舊資料比較。
將所有內容整合在一起的技能定義
做最多工作的技能檔案是 compare-seo-snapshot.md：
# Skill: Compare SEO Snapshots
## Purpose
比較兩個 SEO 中繼資料快照並識別回歸。
## Input
- 目前快照：/tmp/seo-current.json
- 基準快照：.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 描述、canonical、至少一個 h1。
### Removed Pages
- 基準中但不在目前中的頁面是 HIGH。
- 這些可能表示意外的路由移除。
此技能檔案將數月的 SEO 事件回應編碼為 Claude 可以可靠地遵循的格式。沒有它，子代理會做出合理但不一致的判斷，關於什麼構成回歸。
系統捕獲的四個事件
事件 1：47 個部落格文章上的意外 noindex
客戶： B2B SaaS 公司，200 個頁面，60k 自然搜尋工作階段/月。
開發人員更新了部落格範本中的 <Head> 元件以新增新的中繼標籤。他們從包含 <meta name="robots" content="noindex, nofollow"> 硬編碼的預演配置複製貼上。變更通過了代碼審查，因為審查者專注於新標籤，而不是現有的標籤。
SEO 回歸子代理將 47 個頁面標記為 CRITICAL -- robots meta 變更為 noindex。部署被阻止。
偵測時間： 推出後 2 分 14 秒。沒有系統，當 Search Console 顯示覆蓋範圍下降 3-7 天後，它會被捕獲。
迴避的估計影響： 這 47 篇文章每月產生大約 $14,000 的管道。即使是一週的去索引事件也可能花費 $3,500+。
事件 2：新英雄圖像的 CLS 回歸
客戶： 電子商務品牌，Next.js 14 店面在 Shopify Hydrogen 上。
設計團隊將首頁英雄交換為具有不同寬高比的新圖像，但沒有更新 <Image> 元件上的寬度/高度屬性。圖像加載得很好，但導致 CLS 為 0.34 -- 遠高於 0.1 閾值。
CWV 煙霧測試子代理報告首頁上的 CLS 回歸。摘要特別指出：「由元素 img.hero-banner 引起的 CLS 移位 0.34 累積。影像尺寸 (1920x800) 與容器寬高比 (16:9 = 1920x1080) 不符。新增明確的 width={1920} height={800} 或更新容器。」
偵測時間： 1 分 47 秒。
事件 3：URL 重新結構後損壞的內部連結
客戶： 專業服務公司，80 個頁面。
我們將他們的服務頁面從 /services/[name] 重新結構為 /[category]/[name]。重新導向已就位，但三篇部落格文章有到舊 URL 的硬編碼連結，且 CMS 驅動的導覽有指向已刪除頁面的快取項目。
損壞的連結掃描發現 4 個內部 404。子代理的摘要指出，4 個中的 3 個位於部落格文章正文內容中（不是導覽），這意味著它們被重新導向審核所遺漏。
偵測時間： 3 分 8 秒。linkinator 爬取是最慢的部分。
事件 4：Article 結構化資料中缺少 dateModified
客戶： 媒體公司，2,000 篇文章。
CMS 從 WordPress 遷移到 Sanity，遺失了 dateModified 欄位對應。結構化資料產生代碼回到 dateModified 的 null，導致無效的 JSON-LD。
結構化資料驗證子代理將每個文章頁面標記為 HIGH -- 缺少必填的 dateModified 欄位。摘要說明：「Google 需要 Article 結構化資料的 dateModified 才能符合 Top Stories 和豐富結果的資格。所有 2,147 篇文章頁面都受到影響。」
偵測時間： 4 分 22 秒（大型網站地圖）。
投資回報率：每次運輸節省的分鐘和每月節省的美元
以下是我們的數學：
| 指標 | 前（CI + 手動） | 後（子代理） | 差異 |
|---|---|---|---|
| 每次部署檢查 | 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 個標記）
- 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 和一些政府網站阻止爬蟲或積極速率限制。我們維護排除清單，但需要手動更新。
冷啟動時間。 克隆倉庫後的第一次執行花費更長時間，因為 npx 需要擷取套件。我們正在考慮在 Docker 層中預先安裝 CLI 工具。
Anthropic 速率限制。 同時生成 5 個子代理偶爾會在尖峰時段期間觸發 Claude API 上的速率限制。我們在子代理之間添加了 2 秒的交錯，這有效但不優雅。
我們較長的代理定義（結構化資料驗證有 400 個單詞）有時比較短的定義產生結構化較少的輸出。我們正在考慮將結構化資料驗證代理分割成每種類型的子子代理。
常見問題
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 倍，但我們發現對於這些任務不必要。
子代理是否可以在 CI/CD 管道（如 GitHub Actions）中執行？
是的。您可以在 CI 環境中以無頭方式呼叫 Claude Code。我們通過在預覽部署完成時呼叫 Vercel Webhook 的 Webhook 觸發我們的，該 Webhook 使用預覽 URL 作為環境變數呼叫 claude-code run .claude/agents/deploy-gate.md。
Claude Code 技能和子代理之間的區別是什麼？
技能是教導 Claude 如何做某事的 markdown 指令檔案 -- 像一個食譜。子代理是一個隔離的 Claude 實例，可以用自己的上下文和工具生成。子代理使用技能。將技能視為文件，將代理視為工人。
您是否需要 Anthropic 的例程功能，或原始子代理就足夠了？
對於我們的部署閘門工作流程，原始子代理加上 settings.json 中的掛鉤是充分的。例程添加了對更複雜的多步驟工作流程有用的更高級協調層。如果我們的部署檢查超過六個代理，我們可能採用例程。
如何處理子代理故障或逾時？
每個子代理有 120 秒的逾時。如果子代理失敗或逾時，部署閘門協調器將其視為 WARN，而不是 BLOCK。我們寧願因為 Lighthouse 掛起而通過不完整檢查的運輸，也不願進行塊部署。摘要說明哪些檢查未完成。
此方法是否可以取代 Lighthouse CI 或 pa11y 等專用工具？
不 -- 它包裝它們。子代理通過 bash 呼叫這些工具，然後推理輸出。您仍需要安裝底層工具。價值在於協調、關聯和自然語言報告層，而不是取代掃描儀。