SEO / GEO 工作自动化部署与实践规范（十六）：SEO Agent Economics / Cost & Capacity Engineering——怎样管理模型Token、Search API、Crawler、GSC/GA4、GitHub Actions和人工审核成本，让自治SEO系统不会“越自动化越贵”

创见日期：2026年9月8日

前十五篇已经让SEO/GEO自动化系统逐步拥有SEO Intelligence、Research、Fact Check、Technical SEO、Indexing、Measurement、Content Operations、GEO Research、Release Engineering、Monitoring、Incident Response、Knowledge、Orchestrator、Evaluation、Experimentation与Causal Measurement。

但一个系统只要开始真正运行，就会遇到一个非常现实的问题：它要花多少钱？

Automation Scale
≠
Economic Efficiency

系统可能自动化率越来越高，但Token越来越多、Search调用越来越多、Crawler越来越重、GitHub Actions越来越长、GSC/GA4 API越来越频繁、Human Review Queue越来越大，最终变成：以前是人工很贵，现在是机器又贵、人还没减少。

所以第十六篇建立的是 SEO Agent Economics / Cost & Capacity Engineering。核心问题从“Agent能不能做”升级成“这个任务值不值得做、应该由哪个模型做、做到什么程度、什么时候停止”。

一、最大的误区：只计算Token成本

TOTAL COST
=
Model Cost
+
Tool Cost
+
Search Cost
+
Crawler Cost
+
Data API Cost
+
Compute Cost
+
CI/CD Cost
+
Storage Cost
+
Observability Cost
+
Human Review Cost
+
Failure Cost
+
Opportunity Cost

Token Cost并不等于Agent Cost。

二、真正应该优化的是Cost per Validated Outcome

便宜模型单次调用成本低，但如果需要更多Retry、Fact Check和Human Review，最终每个正确结果的成本可能反而更高。

Cost per Validated Outcome
=
Total Cost
/
Validated Outcomes

三、建议把核心成本指标从“每次调用”改成“每个有效结果”

cost_per_validated_research
cost_per_verified_diagnosis
cost_per_published_article
cost_per_resolved_incident
cost_per_experiment
cost_per_incremental_lead

四、项目原创原则：最便宜的模型，不一定产生最低系统成本

Cheap Model
+
More Rework
+
More Review
+
More Failures
=
More Expensive System

五、当前模型价格差异足以支撑分层路由

截至2026年9月8日，OpenAI官方GPT‑5.6模型页面显示Sol、Terra、Luna存在显著价格梯度，同时支持更低的Cached Input价格。具体价格和促销状态会变化，因此生产系统不能把当天价格永久写死进业务逻辑。

六、第一个成本原则：不要所有任务都使用最强模型

URL分类、简单标签、低风险提取可由更低成本模型处理；复杂Google Update研究、Technical Root Cause、复杂实验设计才升级更强模型。

七、模型选择由Evaluation决定，而不是感觉决定

应比较不同模型在具体Task上的质量阈值。例如URL分类如果低成本模型已达到所需准确率，就没有必要默认使用更昂贵模型。

八、目标是最低成本满足质量阈值的模型

Choose Model
=
Lowest Cost Model
such that
Quality >= Required Threshold

九、不同Risk Level使用不同默认模型策略

LOW、MEDIUM、HIGH、CRITICAL可使用不同默认路由，但最终仍由Eval结果决定。

十、成本还有Reasoning Depth

复杂推理任务会产生更多计算、Output、Tool Call和Runtime，因此还要管理Reasoning Budget。

十一、每个Task拥有Compute Budget

task_id
max_input_tokens
max_output_tokens
max_model_calls
max_tool_calls
max_search_calls
max_runtime
max_cost_usd

十二、Orchestrator在任务开始前判断Budget

普通Daily Monitoring、Deep Research、P0 Incident应该有完全不同的预算上限，具体数字按业务价值校准。

十三、Budget应和Business Value关联

影响高额Organic Revenue的Incident值得投入更多分析成本；极低价值URL不应触发昂贵Deep Research。

十四、建立Economic Priority

Economic Priority
=
Expected Business Value
× Confidence
× Urgency
÷ Expected Cost

十五、Agent任务必须允许“经济上不值得执行”

Estimated Value < Estimated Task Cost
→ NO_ACTION / BATCH_LATER

十六、Cost Gate进入Orchestrator

Task
↓
Value Estimate
↓
Cost Estimate
↓
Budget Available?
↓
Expected ROI?
↓
Execute / COST_BLOCKED

十七、第二个巨大成本来源：重复上下文

每次请求都重新输入完整SOP、Knowledge、历史对话，会造成Context Inflation。

十八、More Context并不等于Better Agent

上下文越长，还会增加Latency、噪声和维护成本。

十九、Prompt Caching非常重要

稳定Policy、SOP、Tool Guidance应放在稳定前缀，动态Task与数据放后面，以提高缓存复用。

二十、不要让动态信息破坏缓存前缀

Static Instructions
↓
Stable Policies
↓
Dynamic Task Data

二十一、Cache Hit Rate成为成本指标

cache_hit_rate
cached_input_tokens
uncached_input_tokens

二十二、超长Context可能触发成本跃迁

模型文档会对超长输入定义不同计费档位，因此Context并不是简单线性成本。

二十三、建立Context Budget

context_budget
↓
summarize
retrieve selectively
drop irrelevant history

二十四、Knowledge Base不应每次全文注入

Query
↓
Retrieve Relevant Objects
↓
Validate
↓
Inject Minimum Necessary Context

二十五、Context Engineering同时提高Accuracy和Economics

好的Retrieval不仅减少Token，也减少无关信息。

二十六、Output Tokens通常更昂贵

因此机器之间的内部工作流不应默认生成长篇自然语言解释。

二十七、Machine-to-Machine任务优先Structured Output

{
  "severity": "P2",
  "confidence": 0.84,
  "action": "WATCH"
}

二十八、Narrative只在需要人阅读时生成

MACHINE → minimal structured output
OPERATOR → concise decision summary
EDITORIAL → long-form content

二十九、Output Budget按Consumer分类

同一分析结果给机器、运营人员、公众号读者需要不同输出长度。

三十、Batch Processing适合非实时任务

OpenAI当前Batch API面向可延迟的批处理任务，适合Query分类、历史内容标签、批量Claim抽取、知识处理和夜间Evaluation。

三十一、不是所有任务都需要Realtime

Queue
↓
Batch
↓
Next Morning Result

三十二、Task需要Latency Class

REALTIME
NEAR_REALTIME
DAILY
BATCH
BACKGROUND

三十三、Incident不能为了便宜进入长时间Batch

成本优化必须服从业务时效。

三十四、真正优化的是Cost × Latency × Quality

不能单独优化任何一个维度。

三十五、第三大成本来源：Search和Browser Tool Call

多个Agent反复搜索同一Google官方文档会产生重复工作。

三十六、Research结果必须缓存

Fetch Once
↓
Evidence Store
↓
Reuse

三十七、建立Source Cache

source_url
content_hash
fetched_at
expires_at
source_class

三十八、不同Source设置不同TTL

Search Status可按分钟，核心文档按天，稳定标准按周。

三十九、Search Budget按Task设置

简单Fact Check和Deep Research不应拥有同样的Search上限。

四十、Research Agent必须具备Stopping Rule

2 Official Sources
+
Claim Fully Supported
→ STOP RESEARCH

四十一、第四大资源约束：Crawler

每天全站Crawl、全站Render通常没有必要。

四十二、Crawler成本包括Bandwidth、CPU、Memory、Storage、Rendering、Proxy与Log Processing

JavaScript Rendering往往远比普通HTML Fetch昂贵。

四十三、Crawler分层

Tier 1: lightweight HTTP fetch
Tier 2: HTML crawl
Tier 3: rendered browser

四十四、不要每天Render整个网站

Sample
↓
Detect Risk
↓
Escalate Render

四十五、Change-Driven Crawl比Full Crawl更经济

代码或模板变更后优先抓受影响范围，而不是整个站点。

四十六、Crawler拥有Crawl Budget

max_urls
max_rendered_urls
max_bytes
max_runtime
max_concurrency

四十七、Priority Crawl Queue

P0 changed production URLs
P1 revenue pages
P2 indexing anomalies
P3 routine long tail

四十八、第五大资源约束：Search Console API

Search Console API存在Search Analytics、URL Inspection等QPM/QPD与内部Load限制，因此不能把它当成无限数据库。

四十九、Search Analytics还有数据提取边界

更多API调用并不必然获得完整数据，因此需要理解接口本身的数据行限制和聚合边界。

五十、GSC Extractor应该Daily Incremental

每天只拉新增日期
↓
Store
↓
Historical Warehouse

五十一、历史查询优先自己的Warehouse

除非需要Fresh Data，否则不要每次重新请求GSC历史数据。

五十二、URL Inspection尤其要Risk-Based Sampling

新发布、掉流量、Canonical异常、核心Landing Page优先。

五十三、第六大资源约束：GA4 Data API

GA4 Data API拥有按Property、Project、小时、并发等维度的Quota Token限制，请求复杂度也会影响消耗。

五十四、GA4 Query有Complexity Cost

1 API Call不等于1 Cost Unit。

五十五、GA4官方也建议Caching、合并请求与降低Query复杂度

因此Shared Data Layer与Backpressure应成为默认架构。

五十六、GA4 Agent不应让每个子Agent独立查询

Measurement Agent
↓
Shared Data Layer
↓
Other Agents

五十七、建立Analytics Cache

property
date_range
dimensions
metrics
filters
response_hash
fetched_at

五十八、第七大资源：GitHub Actions

Hosted Runner有按分钟计费和Plan配额，因此冗余Workflow也会产生直接或间接成本。

五十九、项目中的真实案例：WordPress Publisher存在Work Amplification

单篇新文章发布时，当前系统会顺序检查大量历史due articles。

六十、Work Amplification应该成为成本指标

Work Amplification Factor
=
Actual Work Units
/
Required Work Units

六十一、Targeted Release既是可靠性优化，也是成本优化

单篇发布应优先定向Slug，而不是全量历史due。

六十二、Free ≠ Costless

即使Runner包含免费分钟，低效Workflow仍会增加Latency、Failure Surface和人工诊断成本。

六十三、Workflow Efficiency应该监控

workflow_runtime
workflow_success_rate
work_amplification
retries
cancelled_runs

六十四、Concurrency Cancellation也是经济问题

重复取消和Retry会消耗Runner、人工诊断时间并延迟发布。

六十五、Failure Cost通常比Compute Cost大

几美分Runner费用与工程师几十分钟调查相比往往微不足道。

六十六、第八大成本：Human Review

AI自动生成大量任务，但如果每项都需要人工审批，机器吞吐可能直接制造新的人工瓶颈。

六十七、自动化可能制造人工审核债务

Machine Throughput
>
Human Review Capacity

六十八、建立Human Review Capacity

Orchestrator必须知道团队每天能够处理多少Review Units。

六十九、Review Queue需要Backpressure

Review Queue > threshold
↓
Reduce Low-priority Generation
↓
Batch
↓
Defer

七十、不同Task的Review Cost不同

Meta检查、Research审阅、Canonical Change和Migration应使用不同Review Unit。

七十一、建立Human Cost Model

human_cost
=
review_minutes
×
cost_per_minute

七十二、提高Autonomy实际上是在购买Human Capacity

Eval证明某LOW RISK Action足够可靠后，从L2升级L3能够直接减少人工审批时间。

七十三、Autonomy Upgrade应该有ROI

节约的Review Hours就是可以量化的Autonomy Value。

七十四、第九大成本：Evaluation

Golden Dataset、Trace Eval、Model Grader和Human Review自身都需要成本。

七十五、不能每次小改动都跑最昂贵的Full Eval

Commit → deterministic/unit
PR → focused regression
Major Agent Change → full golden dataset
Production Candidate → shadow/canary/human

七十六、Risk-Based Eval降低成本

Publisher和Canonical Agent需要比低风险分类器更严格的Eval。

七十七、第十大成本：Observability

Trace、Logs、Metrics、Snapshots、Answer Capture都会增加存储与处理成本。

七十八、不是所有Trace都需要永久保留

可按Risk和Incident状态设置Retention Policy。

七十九、Trace Sampling降低成本

100% Critical
100% Errors
sample Medium
sample Healthy Low Risk

八十、第十一大成本：Knowledge Base

文件、Embedding、Vector、Graph、Versions、Snapshots会随着时间增长。

八十一、Knowledge也需要Lifecycle

ACTIVE
↓
STALE
↓
SUPERSEDED
↓
ARCHIVED

八十二、Hot / Warm / Cold Knowledge

当前政策和近期Incident放Hot，历史实验和长期规则放Warm，过期Snapshot和旧Research放Cold。

八十三、第十二大成本：Failure和Retry

失败后机械重试十次不是可靠性，而可能只是十倍成本。

八十四、Retry必须指数退避并有上限

1s → 5s → 30s → STOP

八十五、Failure Classification决定是否值得Retry

TRANSIENT → retry
RATE_LIMIT → backoff
AUTH → stop
POLICY → stop
INVALID_DATA → review

八十六、WordPress 522案例再次适用

GitHub ConnectTimeout与Cloudflare 522形成跨路径证据后，继续重试就是Waste，正确动作是STOP → Incident → Wait for Recovery。

八十七、Cost Engineering本质也是Stopping Engineering

Research、Crawler、Experiment、Retry都必须知道什么时候已经Enough。

八十八、每个Workflow拥有Economic Stop Condition

cost_spent >= budget
or
marginal_information_gain < threshold
→ STOP

八十九、边际信息价值

第1次Search可能拿到80%答案，第15次只增加0.1%；More Research不一定等于More Value。

九十、建立Marginal Value

Marginal Value
=
Additional Expected Decision Quality
/
Additional Cost

九十一、Capacity和Cost是两个不同问题

即使预算充足，系统仍可能受到RPM、TPM、API Quota、Concurrency、Runner、Crawler CPU、Human Review限制。

九十二、每一种资源都需要Capacity Model

MODEL → TPM / RPM
GSC → QPM / QPD
GA4 → quota tokens / concurrency
GITHUB → runner concurrency
CRAWLER → URLs / second
HUMAN → reviews / day

九十三、系统容量由最窄瓶颈决定

模型可跑10,000 tasks/day，但Human Review只能处理100，真实Capacity仍接近100。

九十四、Orchestrator必须知道Resource Capacity

capacity_registry
resource
limit
current_usage
reserved
available

九十五、需要Admission Control

接近容量上限时，新任务应进入QUEUE而不是直接执行。

九十六、Backpressure不可缺少

GSC/GA4接近Quota时自动降低低优先级查询，而不是继续打到Rate Limit。

九十七、Capacity需要Reservation

平时不要把所有资源全部耗尽，应为Incident保留Capacity。

九十八、Incident Capacity Reserve

正常任务和P0/P1需要独立资源预留。

九十九、P0 Incident应该抢占普通任务

停止Historical Content Analysis、低优先级Batch、Experiment Reporting，释放模型、API与人审Capacity。

一百、Priority Preemption

Incident
>
Production
>
Monitoring
>
Research
>
Backfill

一百零一、不同Agent拥有Service Class

P0 Incident、Production Release、Historical Reanalysis可拥有不同Budget、Latency和Priority。

一百零二、系统需要Degraded Mode

API Budget不足、Rate Limit下降、GA4 Quota接近上限时，只保留关键任务。

一百零三、Degraded Mode不是Failure

暂停低优先级任务是成熟系统行为。

一百零四、Cost Anomaly Detection进入Monitoring

日常成本突然远超Baseline，应触发COST_ANOMALY。

一百零五、常见Cost Anomaly原因

Infinite Loop
Retry Storm
Prompt Explosion
Tool Loop
Duplicate Scheduler
Cache Miss
Crawler Explosion
Historical Reprocessing

一百零六、Cost Spike可能就是Incident

Runaway Agent可能同时产生费用与Quota事故。

一百零七、建立Cost Circuit Breaker

小时或日预算异常时自动暂停低优先级任务，必要时进入READ_ONLY。

一百零八、每个Agent应该拥有Cost Attribution

agent_id
task_id
site
workflow
model
tokens
tools
runtime
human_minutes

一百零九、Cost Tagging贯穿Trace

trace_id、agent_id、task_type、site、business_unit都应成为FinOps维度。

一百一十、SEO Agent Cost Ledger

cost_event_id
timestamp
task_id
agent_id
site
resource_type
model
input_tokens
cached_tokens
output_tokens
tool_calls
api_calls
runner_minutes
crawler_urls
rendered_urls
human_minutes
estimated_cost

一百一十一、Daily Cost Dashboard不只显示Dollar

Spend
Tasks
Validated Outcomes
Cost / Outcome
Cache Hit Rate
Model Mix
Search Calls
Crawler URLs
GSC Usage
GA4 Quota
Runner Minutes
Human Review Minutes

一百一十二、Model Mix是重要指标

如果主要做分类的系统却80%任务使用最高成本模型，通常值得审查。

一百一十三、理想Model Mix由Task Distribution决定

Task Need
→ Model

一百一十四、Cost per Validated Outcome应按Agent比较

总成本更高的Agent也可能因为成功率更高而拥有更低的单位有效结果成本。

一百一十五、总账单下降不是唯一目标

如果成本+30%但有效Lead+200%，经济效率可能显著提升。

一百一十六、最终要计算Unit Economics

Cost per Lead
Cost per Qualified Lead
Cost per Incremental Organic Lead

一百一十七、Content Automation要算完整内容单位成本

Research + Draft + Fact Check + Editorial + Publish + Monitoring，最终形成Cost per Published Article，而不是只看Draft Token Cost。

一百一十八、真正昂贵的经常不是Draft

Research、Human Review、Fact Check、Rework和发布故障可能比正文生成贵得多。

一百一十九、Technical SEO也有Unit Economics

Cost per Diagnosed Issue
Cost per Valid Root Cause

一百二十、Monitoring也要避免“监控一切”

监控越多，API、Storage、Alert和Human Attention成本越高。

一百二十一、Alert成本主要是Attention

一个False Alert可能只消耗极少模型费用，却打断员工20分钟。

一百二十二、Alert Precision本身是成本指标

False Alert Cost
=
Human Interruption
+
Investigation Time

一百二十三、Evaluation可以降低False Alert Cost

更贵但更精确的Monitoring Agent可能降低总成本。

一百二十四、Experiment也必须计算经济价值

Design、Deployment、Monitoring、Analysis、Opportunity Cost都属于实验成本。

一百二十五、低流量实验可能经济上没有意义

如果要运行半年才能检测很小Effect且业务价值低，正确动作可能是DO NOT EXPERIMENT。

一百二十六、Knowledge Base价值可以量化

知识复用减少的Research时间就是Knowledge Reuse Savings。

一百二十七、Knowledge Reuse Rate也是经济指标

Higher Reuse
→ Less Research
→ Lower Cost

一百二十八、不要为了节省成本使用过期知识

Cost Gate不能覆盖Evidence Gate。

一百二十九、可靠性永远是成本优化的Hard Boundary

不能为了便宜取消Fact Check、Frontend Verification、Rollback、Monitoring。

一百三十、最低成本不是目标，风险调整后的成本才是

Risk-Adjusted Cost
=
Direct Cost
+
Expected Failure Cost

一百三十一、Expected Failure Cost

Probability of Failure
×
Impact of Failure

一百三十二、生产发布尤其适合这种思维

省掉Frontend Verification可能只节约几秒，但一次错误发布可能造成数小时事故。

一百三十三、“越自动化越贵”通常来自四类根因

1. Over-computation
2. Duplicate Work
3. Over-observation
4. Human Review Explosion

一百三十四、Over-computation

所有任务都使用最强模型、Deep Reasoning、Full Context。

一百三十五、Duplicate Work

多个Agent重复Search、重复GSC、重复历史文章、重复Crawler。

一百三十六、Over-observation

每天全站Render、全量URL Inspection、所有Trace永久保留。

一百三十七、Human Review Explosion

AI产生任务速度远大于人处理速度。

一百三十八、解决方案是系统工程

Routing
Caching
Batching
Sampling
Prioritization
Backpressure
Budget
Capacity
Stopping Rules

一百三十九、Cost Optimization Ladder

Measure
↓
Remove Duplicate Work
↓
Cache
↓
Batch
↓
Route Models
↓
Reduce Human Review
↓
Redesign Workflow

一百四十、不要一上来就换最便宜模型

架构层面的Work Amplification往往比单次模型价格更值得优先优化。

一百四十一、项目当前最明显的机会：Targeted Release

Single Article却检查大量Due Articles，应优先转向Targeted Slug Release。

一百四十二、第二个机会：Published Fast Skip

Find Post
↓
Already Published?
YES → Verify / Skip
NO → Resolve Tags / Publish

一百四十三、第三个机会：Shared Data Layer

GSC、GA4、Google Updates由中央Collector一次拉取，多Agent共享。

一百四十四、第四个机会：Incremental Processing

Changed
New
Anomalous
Due for Review

只处理需要处理的对象。

一百四十五、核心原则

Do not recompute what has not changed.

一百四十六、Change Detection成为默认前置Gate

Input Changed?
NO
↓
SKIP

一百四十七、Content也一样

没有流量、政策、知识或新鲜度变化时，不要每天Refresh。

一百四十八、Knowledge也不要每天重新Embedding全部文件

只处理新增、变化和失效对象。

一百四十九、SEO Agent Economics形成四层预算

Task Budget
Agent Budget
Site Budget
Portfolio Budget

一百五十、Budget需要多个时间窗口

hourly
daily
weekly
monthly

一百五十一、Budget State

HEALTHY
WATCH
CONSTRAINED
EXHAUSTED

一百五十二、HEALTHY / WATCH / CONSTRAINED / EXHAUSTED

随着预算状态恶化，逐步减少低价值任务，最终除P0 Incident外进入READ_ONLY。

一百五十三、Budget状态进入Global System State

第十三篇的NORMAL、DEGRADED、INCIDENT、READ_ONLY现在可以叠加Economic State。

一百五十四、完整调度不再只是Priority Queue

Task Value
Risk
Urgency
Cost
Capacity
Budget

一百五十五、最终Orchestrator调度逻辑

Task Arrives
↓
Business Value
↓
Risk
↓
Required Quality
↓
Available Knowledge
↓
Expected Cost
↓
Capacity Available
↓
Choose Model
↓
Choose Tool
↓
Realtime or Batch
↓
Execute
↓
Measure Cost
↓
Validate Outcome

一百五十六、执行以后做Cost Attribution

比较Actual Cost与Estimated Cost，持续修正Cost Model。

一百五十七、Cost Prediction也需要Learning Loop

Estimate Cost
↓
Execute
↓
Observe Cost
↓
Update Estimate

一百五十八、形成Cost Prediction Model

未来Agent可以在执行前给出Estimated Cost、Expected Value、Expected Duration与Confidence。

一百五十九、从“Can AI do this?”升级成“Should AI do this?”

这是自治系统真正进入经营层的标志。

一百六十、SEO Agent Economics Flywheel

MEASURE
↓
ATTRIBUTE
↓
NORMALIZE
↓
BENCHMARK
↓
OPTIMIZE
↓
ROUTE
↓
BUDGET
↓
EXECUTE
↓
VALIDATE
↓
MEASURE AGAIN

一百六十一、第十六篇让系统第一次拥有资源约束

Value?
Cost?
Capacity?
Enough Evidence?
↓
Execute / Stop

一百六十二、最终完整系统

SEO Intelligence
↓
Research
↓
Fact Check
↓
Technical SEO
↓
Indexing
↓
Measurement
↓
Content
↓
GEO
↓
Release
↓
Monitoring
↓
Incident
↓
Knowledge
↓
Orchestrator
↓
Evaluation
↓
Experimentation
↓
Causal Measurement
↓
Cost & Capacity Engineering

结语：真正成熟的SEO自治系统，知道每一单位资源应该花在哪里

如果一个Agent每天分析100万个URL，并不意味着它先进；如果其中99%根本不需要分析，那只是更昂贵的自动化。

AI Automation的经济效率，不取决于“调用成本有多低”，而取决于“每一单位资源最终产生了多少经过验证的有效结果”。

Validated Tasks: 1,240
Total Cost: $38.20
Cost per Validated Outcome: $0.031
Human Review Saved: 18.4 hours
Incremental Leads: 23
Cost per Incremental Lead: $1.66

只有当Automation同时满足Quality、Reliability、Capacity、Economics，它才真正具备Scale；否则只是Automated Cost Growth。

来源与延伸阅读

• OpenAI — GPT‑5.6 Model Pricing
• OpenAI — Responses API / Prompt Caching
• OpenAI — Batch API
• Google Search Console API — Usage Limits
• Google Search Console — Search Analytics Query
• Google Analytics Data API — Limits and Quotas
• Google Analytics — Managing Data API Quotas
• GitHub Docs — Actions Runner Pricing