索未 · SEO ｜ 规范与标准流程

创见日期：2026 年 9 月 9 日

前十五篇，我们已经让 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

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

最初每天只有：

10 次模型调用；

20 次 API 请求；

1 篇内容；

几个 URL 检查。

成本几乎感觉不到。

但当系统发展到：

每天监测几十个站点；

几万个 URL；

上千 Query；

多个 AI Search 平台；

几十个 Agent；

持续 Evaluation；

实时 Monitoring；

自动 Crawler；

自动发布；

Incident Detection；

Experimentation；

Knowledge Retrieval，

一个非常危险的现象会出现：

系统可能：

自动化率越来越高，

但：

Token 越来越多；

Search 调用越来越多；

Crawler 越来越重；

GitHub Actions 越来越长；

GSC/GA4 API 越来越频繁；

Human Review Queue 越来越大；

最终变成：

所以第十六篇要建立的是：

以及：

核心问题不再是：

而是：

· · ·

很多 AI 项目谈成本时，第一反应是：

Input Tokens + Output Tokens

但真正 SEO Agent 系统的成本远不止这些。

完整成本更接近：

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

所以：

· · ·

假设：

Agent A：

$0.03 / task

但只有：

60%

任务真正完成。

Agent B：

$0.08 / task

但：

96%

能够输出经过验证的正确结果。

只看单次调用：

Agent A 便宜。

但真正的：

Cost per Validated Outcome

可能 Agent B 更低。

· · ·

例如：

cost_per_validated_research cost_per_verified_diagnosis cost_per_published_article cost_per_resolved_incident cost_per_experiment cost_per_incremental_lead

这比：

cost_per_token

更接近业务。

· · ·

例如低价模型：

错误率更高；

需要更多 Retry；

产生更多 Fact Check；

产生更多 Human Review。

于是：

Cheap Model + More Rework + More Review + More Failures

最终反而：

More Expensive System

· · ·

截至 2026 年 9 月 8 日，OpenAI 当前官方模型页面显示：

GPT-5.6 Sol：

Input:        $4 / 1M tokens Cached Input:$0.40 / 1M Output:       $20 / 1M

GPT-5.6 Terra：

Input:        $2 / 1M Cached Input:$0.20 / 1M Output:       $12 / 1M

GPT-5.6 Luna：

Input:        $0.20 / 1M Cached Input:$0.02 / 1M Output:       $1.20 / 1M

其中 Sol 当前官方页面还注明为促销价格，至少持续到 2026 年 11 月 21 日，因此生产系统不能把今天的具体价格永久写死进业务逻辑。

这说明：

同一个任务如果不做 Model Routing，

成本差异可能非常大。

· · ·

例如：

URL 分类：

Luna

可能已经足够。

复杂的：

Google Update 深度研究；

Technical Root Cause；

复杂实验设计，

才升级：

Sol

这就是：

· · ·

第十四篇已经建立：

Agent Evaluation

现在可以真正用在：

成本路由。

例如：

| Task | Luna | Terra | Sol | | ----------- | ---: | ----: | --: | | URL 分类 | 97% | 98% | 98% | | Claim Check | 83% | 94% | 97% | | Root Cause | 61% | 82% | 95% |

那么：

URL 分类没有必要默认 Sol。

· · ·

可以写成：

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

例如：

classification_accuracy >= 95%

满足以后，

就不继续买更贵的能力。

· · ·

例如：

Luna

Terra

Sol

Sol + Human Review

但这只是：

默认策略。

最终还是应该由：

Eval 结果决定。

· · ·

即使模型价格相同，

复杂推理任务往往产生：

更多计算；

更长 Output；

更多 Tool Call；

更长 Runtime。

所以系统还要控制：

Reasoning Budget

而不是简单：

“使用 Sol"。

· · ·

例如：

task_id  max_input_tokens max_output_tokens  max_model_calls max_tool_calls  max_search_calls max_runtime  max_cost_usd

这样 Agent 不是拥有：

无限资源。

· · ·

例如：

普通：

Daily SEO Monitoring

预算：

$0.20

Deep Research：

$5

P0 Incident：

$20

这是示例性的项目内部预算，

真正数字应根据业务价值和历史成本校准。

· · ·

一个影响：

$200,000/月

Organic Revenue 的 Incident，

花：

$10

模型成本调查，

几乎无关紧要。

但：

一个每月只有：

10 次 Impressions

的低价值 URL，

花：

$5

做 Deep Research，

明显不合理。

· · ·

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

这是项目内部排序指标。

· · ·

例如：

Estimated Value: $0.50  Estimated Task Cost: $3.00

那么正确 Action 可能是：

NO_ACTION

或者：

BATCH_LATER

这和第十三篇的：

NO_ACTION

完全一致。

· · ·

Task ↓ Value Estimate ↓ Cost Estimate ↓ Budget Available? ↓ Expected ROI?

如果不满足：

COST_BLOCKED

· · ·

Agent 系统最容易发生：

每次请求都把：

10 页 System Prompt；

几十页 SOP；

完整 Knowledge；

完整历史 Conversation

全部重新输入。

这会造成：

· · ·

还可能带来：

更高 Latency；

更差 Retrieval Signal；

更多无关信息；

更难维护。

所以：

More Context ≠ Better Agent

· · ·

OpenAI 当前 GPT-5.6 模型页面显示，Sol 未缓存 Input 为$4/1M，而 Cached Input 为$0.40/1M；Terra 为$2 与$0.20；Luna 为$0.20 与$0.02，即当前 Cached Input 价格为相应普通 Input 的十分之一。

当前 Responses API 也支持 GPT-5.6 及以后模型的 Prompt Cache 配置。

因此稳定 Prompt 结构应该设计成：

STATIC POLICY STATIC SOP STATIC TOOL GUIDANCE ↓ DYNAMIC TASK DYNAMIC DATA

尽量保持：

稳定前缀。

· · ·

错误：

Current Time User ID Random Run ID ↓ Huge Static Instructions

每次开头不同，

可能降低 Cache Reuse。

更加合理：

Static Instructions ↓ Stable Policies ↓ Dynamic Task Data

· · ·

建议：

cache_hit_rate cached_input_tokens uncached_input_tokens

进入：

Agent Cost Dashboard。

· · ·

OpenAI 当前 GPT-5.6 模型文档说明，当输入超过 272K tokens 时，Sol、Terra 和 Luna 的整个请求会采用更高费率：输入价格翻倍，输出价格为标准费率的 1.5 倍。

这意味着：

Context 不是线性成本。

可能存在：

· · ·

例如：

context_budget = 50K

超出以后：

summarize retrieve selectively drop irrelevant history

而不是：

无限追加 Context。

· · ·

第十二篇已经建立：

SEO Intelligence Memory。

正确方式：

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

而不是：

Load Entire Knowledge Base

· · ·

好的 Retrieval：

不仅提高 Accuracy，

也降低：

Token；

Latency；

Noise。

· · ·

以当前 GPT-5.6 Sol 为例：

Input：

$4 / 1M

Output：

$20 / 1M

输出价格是输入的 5 倍。

所以 Agent 不应默认输出：

长篇解释。

· · ·

例如：

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

而不是生成：

2000 字自然语言报告。

· · ·

系统内部：

JSON

人需要决策：

Summary

公众号或网站：

Long-form Content

这三种 Output Budget 不同。

· · ·

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

· · ·

OpenAI 当前 Batch API 官方说明：

批处理在 24 小时窗口内完成，

模型费用相对于同步 API 可以获得 50% 折扣。

这非常适合：

每日 Query 分类；

历史内容标签；

批量 Claim 抽取；

知识重新 Embedding；

低优先级页面分析；

夜间 Evaluation。

· · ·

例如：

每天凌晨分析：

50,000 Queries

没有必要：

每一条同步调用。

可以：

Queue ↓ Batch ↓ Next Morning Result

· · ·

例如：

REALTIME NEAR_REALTIME DAILY BATCH BACKGROUND

不同类型：

使用不同成本策略。

· · ·

P0 Incident 需要：

立即响应。

所以：

成本优化必须服从：

业务时效。

· · ·

不是：

单独 Cost。

可以定义：

Utility = Quality × Business Value  ÷  Cost × Latency Penalty

· · ·

SEO Agent 很容易：

每一个问题都重新搜索网络。

例如：

100 个 URL；

每个 URL：

5 次 Search。

就是：

500 Search Calls

而很多结果其实可以共享。

· · ·

例如：

Google Search Central：

最新 Canonical 文档。

10 个 Agent 都需要。

正确：

Fetch Once ↓ Evidence Store ↓ Reuse

而不是：

10 个 Agent 分别重新搜索。

· · ·

source_url content_hash fetched_at expires_at source_class

如果内容未变化：

直接复用。

· · ·

例如：

Google Search Status：

TTL = minutes

Google 核心文档：

TTL = days

稳定标准：

TTL = weeks

· · ·

例如：

简单事实核验：

max_search_calls = 3

Deep Research：

max_search_calls = 20

不能无限搜索：

“也许下一条结果更好”。

· · ·

例如：

2 Official Sources + Claim Fully Supported ↓ STOP RESEARCH

而不是：

继续浏览 20 篇行业文章。

· · ·

Technical SEO 自动化非常容易产生：

Crawl Everything Every Day

这通常没有必要。

· · ·

Bandwidth CPU Memory Storage Rendering Proxy Browser Log Processing

尤其：

JavaScript Rendering

远比普通 HTML Fetch 昂贵。

· · ·

HTTP HEAD / lightweight fetch

HTML crawl

Rendered Browser

只有必要 URL 升级。

· · ·

更加合理：

Sample ↓ Detect Risk ↓ Escalate Render

例如：

HTML 与 Rendered 内容可能不一致的页面，

才进入 Tier 3。

· · ·

例如 Git Merge 显示：

template/product.php

发生修改。

优先抓取：

受影响模板页面。

而不是：

整个 100,000 URL 站点。

· · ·

max_urls max_rendered_urls max_bytes max_runtime max_concurrency

· · ·

例如：

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

而不是：

URL 平等处理。

· · ·

Google 当前 Search Console API 对 Search Analytics 设置 QPM 及内部 Load 限制；官方明确指出，更长日期范围的查询消耗更高的内部资源，也建议避免重复查询相同历史数据。当前每站点 Search Analytics 上限为 1,200 QPM；

URL Inspection 每站点为 2,000 QPD、600 QPM。

所以：

API 不是：

无限免费数据库。

· · ·

当前 Search Analytics Query 每次最多可请求 25,000 行；Google 的"All your data"指南说明，Search Analytics 对每个日期、每种 Search Type 最多暴露 50,000 行，并按 Clicks 排序。

这意味着：

“多调用 API"

也不一定：

“得到全部数据”。

· · ·

错误：

每天重新拉过去 16 个月

正确：

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

· · ·

例如：

过去 90 天。

不要：

每次重新请求 GSC。

应该：

Local Store

除非需要：

Fresh Data。

· · ·

每站点当前：

2,000 requests/day

不是无限。

所以：

不要每天检查所有 URL。

· · ·

例如：

新发布；

突然掉流量；

Canonical 异常；

重要 Landing Page

优先。

而不是：

随机浪费 Quota。

· · ·

截至 2026 年 8 月 26 日更新的 Google 官方文档显示，GA4 Data API Standard Property 的 Core quota 包括：

200,000 tokens / property / day 40,000 / property / hour 14,000 / project / property / hour 10 concurrent requests / property

Realtime 和 Funnel 也拥有各自对应的 Quota 类别。请求 Token 消耗会随着行数、维度/指标数量、过滤复杂度、日期范围、高基数维度及 Property 事件量增加。

· · ·

不是：

1 API Call = 1 Cost Unit

一个复杂请求，

可能远重于：

简单请求。

· · ·

Google 关于 Data API Quota Management 的官方建议包括：

缓存响应；

合并请求；

减少不必要维度；

简化 Query；

控制并发。

这和我们的 Agent 经济策略完全一致。

· · ·

更加合理：

Measurement Agent ↓ Shared Data Layer ↓ Other Agents

而不是：

Content Agent 查 GA4；

GEO Agent 查 GA4；

Experiment Agent 再查 GA4。

· · ·

例如：

property date_range dimensions metrics filters response_hash fetched_at

相同 Query：

复用。

· · ·

当前 GitHub 官方 Actions 计费参考显示，标准 GitHub-hosted Linux 2-core runner 基准价格为：

$0.006 / minute

Windows 2-core：

$0.010 / minute

macOS 约：

$0.062 / minute

不同 Plan 同时拥有不同 Included Minutes，因此实际账单仍取决于账户计划和使用方式。

· · ·

当前 WordPress Publisher：

每发布一篇新文章，

会运行：

Processing 35 due articles

也就是说：

新文章只有：

1

但历史回读：

34

这就是典型：

· · ·

定义：

Work Amplification Factor = Actual Work Units / Required Work Units

例如：

35 / 1 = 35x

· · ·

当前系统已有：

slug mode

未来单篇发布应：

publish one slug

而不是：

due all history

· · ·

即使当前 Included Minutes 足够，

低效 Workflow 仍然有成本：

更慢反馈；

更高失败概率；

更高 Concurrency；

更多日志；

更大的 Incident Surface。

所以：

· · ·

workflow_runtime workflow_success_rate work_amplification retries cancelled_runs

· · ·

PR Merge 以后：

多个 Workflow 抢同一个：

wordpress-publisher

产生取消和 Retry。

这不仅是可靠性问题，

还制造：

额外 Runner；

人工诊断；

发布时间延迟。

· · ·

例如：

GitHub Action 多跑 10 分钟：

成本可能只有几美分。

但：

工程师调查 30 分钟，

成本远高于 Runner。

所以：

Failure Cost

不能只看：

Infrastructure Bill。

· · ·

这是最容易被 AI 项目忽略的成本。

如果：

Agent 自动生成 100 个 Task，

每一个都需要：

人工审批 5 分钟。

那么：

500 minutes

Human Review。

· · ·

Agent 越高产，

Review Queue 越长。

最终：

Machine Throughput > Human Review Capacity

系统开始堵塞。

· · ·

例如：

团队每天最多：

60 review units

Orchestrator 不能生成：

300

然后假装系统正常。

· · ·

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

而不是继续产生任务。

· · ·

例如：

文章 Meta：

1 minute

Research：

5 minutes

Canonical Change：

15 minutes

Migration：

可能：

hours

所以 Human Review 也应量化。

· · ·

human_cost = review_minutes × cost_per_minute

这样：

Agent 经济分析

终于包含人。

· · ·

如果第十四篇 Evaluation 证明：

某 LOW RISK Action：

99.9% Reliable

可以：

从 L2 升级 L3。

那么：

减少的人工审批，

就是：

可量化经济收益。

· · ·

例如：

每月：

1,000 LOW-RISK Tasks。

每次 Review：

2 分钟。

自动化以后：

节约：

2,000 minutes ≈ 33 hours

这就是：

Autonomy Value。

· · ·

第十四篇建立：

Golden Dataset；

Trace Eval；

Model Grader；

Human Review。

这些本身也要花钱。

· · ·

应该建立：

Unit / deterministic

Focused Regression

Full Golden Dataset

Shadow / Canary / Human

· · ·

LOW-RISK Agent：

少量 Eval。

Publisher：

严格 Eval。

Canonical Agent：

更严格。

这和：

Risk Level

统一起来。

· · ·

Trace；

Logs；

Metrics；

Snapshots；

Answer Capture

都会产生存储成本。

· · ·

例如：

正常 LOW-RISK 任务：

30 days

Incident：

1 year+

Critical Release：

长期保留。

这就是：

· · ·

例如：

100% Critical 100% Errors 20% Medium 2% Healthy Low Risk

具体比例根据业务调整。

· · ·

知识库随着时间增长：

文件；

Embedding；

Vector；

Graph；

Versions；

Snapshots

都会增加。

· · ·

ACTIVE ↓ STALE ↓ SUPERSEDED ↓ ARCHIVED

旧知识可以：

移出 Hot Retrieval，

降低：

检索噪声和成本。

· · ·

当前政策；

当前项目；

近期 Incident。

历史实验；

长期规则。

过期 Snapshot；

历史 Research。

不同存储与 Retrieval 策略不同。

· · ·

如果一个 API 失败，

Agent 自动 Retry：

10 次。

这不是：

可靠性。

可能只是：

10 倍成本。

· · ·

1s ↓ 5s ↓ 30s ↓ STOP

而不是：

无限循环。

· · ·

retry

backoff

stop

stop

review

· · ·

当：

GitHub Runner：

ConnectTimeout

Cloudflare：

522

已经形成跨路径证据，

继续重试：

不是可靠性。

而是：

正确：

STOP ↓ Incident ↓ Wait for Recovery

· · ·

Agent 必须知道：

什么时候：

Enough。

Research：

证据足够。

Crawler：

样本足够。

Experiment：

达到结论。

Retry：

达到上限。

· · ·

例如：

cost_spent >= budget

或者：

marginal_information_gain < threshold

则：

STOP

· · ·

第一次 Search：

可能获得：

80% 答案。

第二次：

+15%。

第十五次：

可能：

+0.1%。

但每次仍然收费。

所以：

· · ·

Marginal Value = Additional Expected Decision Quality / Additional Cost

低于阈值：

停止。

· · ·

即使钱足够，

系统还可能受：

RPM；

TPM；

API Quota；

Concurrency；

Runner；

Human Review；

Crawler CPU

限制。

所以第十六篇不仅是：

Cost Engineering。

也是：

· · ·

例如：

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。

这就是：

· · ·

capacity_registry  resource limit current_usage reserved available

任务调度时：

先检查。

· · ·

如果系统已接近容量上限：

New Task ↓ QUEUE

而不是：

直接执行。

· · ·

例如：

GSC API：

快到 Quota。

系统自动：

降低低优先级查询。

不是：

继续打到 429。

· · ·

官方当前 Standard Property 每 Property 并发 Core 请求为 10。

所以：

不要让 20 个 Agent：

同时 Query 同一个 Property。

· · ·

例如：

平时只使用：

70%

保留：

30%

给 Incident。

否则：

网站出事故时，

所有 API Budget 已经被日报耗尽。

· · ·

Normal Capacity 70%  Reserved Incident Capacity 30%

具体比例是项目内部策略。

· · ·

例如：

P0

出现以后：

停止：

Historical Content Analysis；

低优先级 Batch；

Experiment Reporting。

释放：

模型；

API；

人审

Capacity。

· · ·

Incident > Production > Monitoring > Research > Backfill

· · ·

例如：

P0 Incident。

Production Release。

Historical Reanalysis。

对应不同：

Budget；

Latency；

Priority。

· · ·

如果：

API Budget 剩余不足；

OpenAI Rate Limit 下降；

GA4 Quota 接近上限，

系统可以：

DEGRADED

· · ·

例如：

只保留：

P0/P1；

关键 Landing Page；

核心 Monitoring。

暂停：

低优先级任务。

这是：

成熟系统行为。

· · ·

例如：

正常：

$8/day

突然：

$84/day

应该触发：

COST_ANOMALY

· · ·

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

· · ·

例如：

Agent Bug 导致：

每分钟：

100 次 API。

不仅成本问题，

还可能：

打满 Quota。

所以：

Cost Incident

进入：

Incident Response。

· · ·

例如：

hourly_cost > 3 × baseline ↓ PAUSE LOW PRIORITY

进一步：

daily_budget > 100% ↓ READ_ONLY

具体阈值按项目设置。

· · ·

agent_id task_id site workflow model tokens tools runtime human_minutes

否则月底看到：

$1,000

不知道：

钱花在哪。

· · ·

例如：

trace_id ↓ agent_id ↓ task_type ↓ site ↓ business_unit

才能真正做：

FinOps。

· · ·

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

· · ·

至少显示：

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

· · ·

例如：

Sol 80% Terra 15% Luna 5%

对一个主要做分类的系统，

可能明显不合理。

· · ·

不是固定：

"70% 便宜模型”。

而是：

Task Need → Model

· · ·

例如：

B 总花费更高，

但效率更好。

· · ·

如果成本：

+30%

但：

有效 Lead：

+200%

经济效率可能显著提高。

· · ·

例如：

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

甚至：

SEO Agent Contribution Margin

· · ·

例如：

Research + Draft + Fact Check + Editorial + Publish + Monitoring

最终：

Cost per Published Article

而不是：

"AI 生成正文只花$0.08"。

· · ·

可能是：

Research；

Human Review；

Fact Check；

重新修改；

发布故障。

所以：

Draft Token Cost

只是很小一部分。

· · ·

例如：

Cost per Diagnosed Issue

以及：

Cost per Valid Root Cause

后者更加重要。

· · ·

监控指标越多：

存储；

API；

Alert；

Human Attention

越贵。

所以：

Signal Value 必须考虑。

· · ·

一个错误 Alert：

可能只花：

$0.001 模型费用。

但：

打断员工 20 分钟。

真正成本巨大。

· · ·

第十一篇的：

Alert Fatigue

现在可以经济化。

False Alert Cost = Human Interruption + Investigation Time

· · ·

如果 Monitoring Agent：

Precision 提高，

即使模型更贵，

总成本仍可能下降。

· · ·

第十五篇中：

一个实验的成本包括：

Design Deployment Monitoring Analysis Opportunity Cost

所以：

Expected Incremental Value

必须大于：

Experiment Cost。

· · ·

如果：

需要运行 6 个月

才能检测小效果，

而业务价值很低，

正确 Action：

DO NOT EXPERIMENT

· · ·

例如过去：

每次 Research：

20 分钟。

知识复用以后：

3 分钟。

那么：

Knowledge Reuse Savings

就是：

17 分钟。

· · ·

Higher Reuse → Less Research → Lower Cost

前提是：

知识仍然有效。

· · ·

这会出现：

Lower Compute Cost ↓ Higher Decision Error

所以：

Cost Gate

不能覆盖：

Evidence Gate。

· · ·

不能因为：

便宜

而取消：

Fact Check；

Frontend Verification；

Rollback；

Monitoring。

这属于：

· · ·

可以内部定义：

Risk-Adjusted Cost = Direct Cost + Expected Failure Cost

· · ·

例如：

Probability of Failure × Impact of Failure

一个便宜但风险高的 Agent，

Expected Cost 可能很高。

· · ·

省掉：

Frontend Verification，

可能每篇节约几秒。

但一次错误发布：

可能造成：

数小时事故。

完全不值得。

· · ·

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

· · ·

所有任务：

Sol；

Deep Reasoning；

Full Context。

· · ·

多个 Agent：

重复搜索；

重复拉 GSC；

重复跑历史文章；

重复 Crawler。

· · ·

每天：

全站 Render；

全量 URL Inspection；

所有 Trace 永久保存。

· · ·

AI 产生任务速度：

远大于：

人处理速度。

· · ·

Routing Caching Batching Sampling Prioritization Backpressure Budget Capacity Stopping Rules

· · ·

第一层：

Measure

第二层：

Remove Duplicate Work

第三层：

Cache

第四层：

Batch

第五层：

Route Models

第六层：

Reduce Human Review

第七层：

Redesign Workflow

· · ·

很多团队成本优化第一步：

换 Nano 模型。

但真正浪费可能来自：

35 倍历史 Work Amplification。

先解决架构浪费，

往往价值更高。

· · ·

就是：

WordPress Publisher：

Single Article ↓ 35 Due Articles Checked

优先优化：

Targeted Release

可能比：

降低模型成本

更加直接。

· · ·

当前 Publisher 如果：

先查询 Tags，

再判断文章是否已经发布，

历史文章仍然产生无意义 API 调用。

更加合理：

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

这同时降低：

API 调用；

延迟；

超时风险。

· · ·

GSC、GA4、Google Updates：

由中央 Collector 一次拉取。

多个 Agent：

共享。

避免：

N × API calls。

· · ·

只处理：

Changed New Anomalous Due for Review

而不是：

重新处理全部历史。

· · ·

· · ·

Input Changed? NO ↓ SKIP

· · ·

文章没有：

流量变化；

政策变化；

知识变化；

内容过期，

就不要：

每天 Refresh。

· · ·

只处理：

新增；

变化；

失效。

· · ·

单任务。

单 Agent。

单网站。

全部项目。

· · ·

需要：

hourly daily weekly monthly

不同窗口。

这样才能及时检测：

Runaway Agent。

· · ·

HEALTHY WATCH CONSTRAINED EXHAUSTED

· · ·

正常运行。

· · ·

降低低价值任务。

· · ·

只允许：

高优先级。

· · ·

READ_ONLY

除 P0 Incident 外。

· · ·

第十三篇：

NORMAL DEGRADED INCIDENT READ_ONLY

现在可以叠加：

Economic State

· · ·

而是：

Task Value Risk Urgency Cost Capacity Budget

共同决定。

· · ·

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

· · ·

Actual Cost vs Estimated Cost

如果偏差：

过大，

说明 Cost Model 需要更新。

· · ·

Estimate Cost ↓ Execute ↓ Observe Cost ↓ Update Estimate

系统会越来越准确知道：

某类任务真正需要多少钱。

· · ·

未来 Agent 可以在执行前告诉 Orchestrator：

Estimated Cost: $0.18  Expected Value: $4.20  Expected Duration: 42 sec  Confidence: High

然后：

决定是否执行。

· · ·

过去：

Can AI do this?

未来：

Should AI do this?

这是完全不同的问题。

· · ·

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

· · ·

过去：

Research → Keep researching  Crawler → Keep crawling  Agent → Keep reasoning

现在：

Value? Cost? Capacity? Enough Evidence?

然后才执行。

· · ·

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

· · ·

如果一个 Agent：

每天分析 100 万个 URL，

并不意味着它先进。

如果其中：

99% 根本不需要分析，

那只是：

更昂贵的自动化。

同样：

使用最强模型；

最长 Prompt；

最多 Search；

最多 Crawler；

最多 Report，

也不会自动产生：

最高价值。

所以第十六篇最核心的一句话是：

未来 SEO Agent 不应该只记录：

Tokens Used: 2.1M

而应该回答：

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 Sol / Terra / Luna Model Pricing 截至 2026 年 9 月 8 日，OpenAI 官方模型文档显示 GPT-5.6 Sol、Terra 和 Luna 之间存在显著价格梯度，并分别提供 Cached Input 价格。

模型文档也注明超长输入可能触发不同费率，因此模型选择和 Context Budget 都应进入 Agent 经济模型。

OpenAI — Responses API Prompt Caching 当前 Responses API 对 GPT-5.6 及以后模型提供 Prompt Cache 配置，可通过稳定 Prompt 结构和缓存诊断提高 Cache Reuse，是降低长 Agent Workflow 重复输入成本的重要机制。

OpenAI — Batch API OpenAI 当前 Batch API 面向非实时批处理任务，在 24 小时处理窗口下相对于同步 API 提供 50% 模型费用折扣，适合历史分析、批量分类、低优先级 Evaluation 和知识处理。

Google Search Console API — Usage Limits Search Console API 对 Search Analytics、URL Inspection 等接口提供独立的 QPM/QPD 和 Load 限制；

Google 明确建议避免反复查询相同历史数据，较长日期范围也会增加 Search Analytics 内部资源负载。

Google Search Console — Getting All Performance Data Search Analytics 单次 Query 最大 rowLimit 为 25,000；

Google 的当前数据提取指南说明其每日期、每 Search Type 暴露的数据存在 50,000 行上限，因此本地增量数据仓库比不断重复请求历史数据更加适合长期自动化。

Google Analytics Data API — Limits and Quotas GA4 Data API 当前使用 Core、Realtime 和 Funnel 等独立 Quota 类别；

Standard Property 在 Core 类别具有每日、每小时、每 Project/Property 及 Concurrent Request 限制，复杂 Query 会消耗更多 Quota Tokens。

Google Analytics — Managing Data API Quotas Google 官方建议通过 Caching、合并请求、降低 Query 复杂度、控制并发等方式减少 Data API Quota 使用，这与 SEO Agent Shared Data Layer 和 Backpressure 设计高度一致。

GitHub Docs — Actions Runner Pricing / Billing GitHub 当前对不同 Hosted Runner 提供不同分钟费率，同时不同 Plan 包含不同免费分钟和存储额度。

即使未产生直接账单，冗余 Workflow 仍然会增加 Latency、Failure Surface 和人工诊断成本。