SEO / GEO 工作自动化部署与实践规范（十八）：Data Architecture / Event Bus / Warehouse / Feature Store——怎样把 GSC、GA4、Crawler、WordPress、GitHub、GEO Prompt、Incident、Experiment 和 Agent Trace 从“各自查询”升级成统一 Search Data Platform

创见日期：2026年9月9日

前十七篇，我们已经逐渐建设出SEO Intelligence、Research、Fact Check、Technical SEO、Indexing Diagnosis、GSC/GA4 Measurement、Content Operations、GEO Research、Release Engineering、Monitoring、Incident Response、Knowledge Base、Orchestrator、Evaluation、Experimentation、Cost & Capacity Engineering与Security Control Plane。

但系统规模越大，一个新的问题越明显：Research Agent自己查数据，Measurement Agent再查一次，Monitoring Agent重新拉GSC，Experiment Agent重新拉GA4，Publisher自己记录WordPress结果，GitHub拥有另一套Commit和Workflow ID，Crawler保存另一套URL，GEO Prompt Monitoring再维护另一套Prompt与Citation。

Data Exists Everywhere
≠
Shared Search Intelligence

所以第十八篇真正要建设的是 Search Data Platform：把GSC、GA4、Crawler、WordPress、GitHub、GEO、Release、Incident、Experiment、Agent Trace接入统一的Event、Entity、Time、Version、Lineage、Warehouse、Feature与Serving体系。

一、最大的架构错误：每个Agent都直接查询Source System

Agent A → GSC
Agent B → GSC
Agent C → GSC
Agent D → GSC

这会产生重复API、不同查询口径、不同日期范围、不同聚合方式、不同缓存，甚至不同答案。

二、统一Data Layer不是为了集中存储，而是为了统一事实

ONE DATA CONTRACT

让不同Agent看到同一件事情时使用相同Definition、Entity、Timestamp、Version与Metric Logic。

三、项目原创原则：Agent不应该拥有自己的“私有事实世界”

Shared Data Platform
↓
Research
Measurement
Monitoring
Content
GEO
Experiment
Orchestrator

四、Search Data Platform拆成六层

SOURCE LAYER
↓
INGESTION / EVENT BUS
↓
RAW DATA LAYER
↓
CANONICAL / WAREHOUSE
↓
FEATURE / SEMANTIC LAYER
↓
SERVING LAYER

五、第一层：Source Layer

Google Search Console
Google Analytics 4
Crawler
Server / CDN Logs
WordPress
GitHub
Google Search Status
Google Documentation
GEO Prompt Monitoring
AI Referral
Release Manifest
Incident
Experiment
Agent Trace
Knowledge Base

六、Source System不应该同时承担长期分析职责

Source
↓
Ingest
↓
Warehouse
↓
Analyze

七、GSC天然支持Warehouse模式

Search Console支持把Search Performance数据持续导出到BigQuery，适合长期分析和跨数据源Join。大型SEO系统不应继续把Search Analytics API作为所有历史分析的唯一数据来源。

八、GSC形成双通道

Fresh Operational Channel
Search Console API

Analytical Channel
GSC
↓
BigQuery Bulk Export
↓
Warehouse

九、不要让Dashboard直接无限扫描Raw GSC Export

RAW GSC
↓
DAILY AGGREGATE
↓
SERVING TABLE
↓
Dashboard

预聚合、分区和Summary Table能显著降低重复扫描成本。

十、GA4同样应该成为Warehouse Source

GA4
↓
BigQuery

Raw Event Data进入Warehouse后可以与GSC、Crawler、Release和Experiment真正Join。

十一、GA4 Export和GA4 UI不是同一种数据产品

GA4 BigQuery Export保存Raw Event Data，而GA4 Reporting UI还有自己的报告语义和处理逻辑，因此Metric Definition必须明确。

十二、第二层：Event Bus

PR merged、Article published、HTTP 5xx detected、robots.txt changed、Google Update announced、Experiment deployed、Incident opened、Agent policy blocked action等都应该形成Event。

十三、Event的意义是“发生了什么”

{
  "event_type": "content.published",
  "entity_id": "content_0017",
  "occurred_at": "...",
  "source": "wordpress"
}

十四、Event和Command必须区分

Event:
ARTICLE_PUBLISHED

Command:
CHECK_INDEX_STATUS

十五、Event让系统真正解耦

ARTICLE_PUBLISHED可以同时被Index Monitoring、Internal Link Update、GSC Annotation、GEO Monitoring和Knowledge Writer订阅，Publisher无需知道具体消费者。

十六、Pub/Sub模式适合这种架构

One SEO Event
↓
Many Autonomous Workflows

十七、Event Bus不一定一开始就需要Kafka

早期可以用Database Event Table + Worker Queue，中型可用Cloud Pub/Sub，关键是Event Contract。

十八、Event Bus必须处理重复消息

很多消息系统使用at-least-once delivery，因此Subscriber必须假设Same Event May Arrive Again。

十九、Event必须拥有event_id

event_id:
evt_20260909_wp_1000029_publish

Already Processed?
YES → SKIP

二十、Event Schema建议

event_id
event_type
event_version
source
entity_type
entity_id
occurred_at
ingested_at
site_id
payload
trace_id
release_id
experiment_id
incident_id
schema_version

二十一、occurred_at和ingested_at必须分开

事件发生时间与系统接收时间不是一回事，Late-arriving Data必须保留两种时间语义。

二十二、还需要effective_at

Title在9月1日部署，但Google在9月5日重新抓取，deployed_at与search_effective_at不是同一时间。

二十三、搜索系统至少存在三种时间

Event Time
Ingestion Time
Effective Time

二十四、GitHub特别适合Event-Driven

PR merge、push、workflow_run.completed、release.created都可以通过Webhook转换为内部Search Events。

二十五、Webhook必须验证来源

Webhook
↓
Signature Verify
↓
Event Normalize
↓
Event Bus

二十六、Webhook不能假设一定送达成功

Retry
Dead Letter
Replay

二十七、第三层：Raw Data Layer

所有外部来源进入平台后，先保存Immutable Raw Data，再进行Transform。

二十八、Raw Layer的价值是可重算

RAW
↓
TRANSFORM
↓
CANONICAL

二十九、Raw Layer尽量Append-only

raw_gsc
raw_ga4
raw_crawler
raw_github_events
raw_wordpress
raw_geo_observations
raw_agent_traces

三十、Raw不等于“所有敏感内容永久保存”

INGEST
↓
SECURITY FILTER
↓
RAW SAFE STORAGE

Secret、Access Token和不必要PII仍必须过滤。

三十一、第四层：Canonical Data Layer

同一个页面在不同系统中可能表现为完整URL、相对路径、post_id、slug或canonical URL。如果不统一，Warehouse会把它们当成不同对象。

三十二、建立Canonical Entity Model

SITE
URL
PAGE
QUERY
QUERY_CLUSTER
CONTENT
RELEASE
EXPERIMENT
INCIDENT
PROMPT
ANSWER
CITATION
AGENT_RUN

三十三、URL和Page不是同一个实体

Page可以从/old-url/迁移到/new-url/，Business Entity仍可能相同，因此PAGE_ID应该稳定，URL_ID可以变化。

三十四、Content和URL也不是同一个实体

同一篇内容可能经历Draft、Published、Revision、Merged、Moved，因此content_id与url_id必须分离。

三十五、WordPress提供重要版本证据

Post Revisions可以把CMS内容版本映射到发布和实验记录，因此可以建立CONTENT → CONTENT_VERSION → WORDPRESS_REVISION。

三十六、Release是独立实体

同一Article可以发布多次，因此content_id对应多个release_id。

三十七、Release Entity连接

content_id
git_commit
pull_request
wordpress_post_id
wordpress_revision_id
frontend_url
published_at
content_hash

三十八、Query需要稳定Entity

Query原文对应query_id，同时还可以属于query_cluster，让Research、Content、GSC与Experiment围绕同一需求实体协作。

三十九、Prompt不是Query

GEO中的Prompt与Search Query必须分开建模，但可以通过Intent/Cluster建立关联。

四十、建立Entity Relationship

SITE
├─ PAGE
│  ├─ URL
│  ├─ CONTENT
│  └─ RELEASE
├─ QUERY_CLUSTER
│  └─ QUERY
├─ PROMPT_SET
│  └─ PROMPT
├─ EXPERIMENT
├─ INCIDENT
└─ AGENT_RUN

四十一、ID不能依赖Display Name

Slug变化不应导致Entity ID变化。应使用Stable Identity，再把URL/Slug作为Attribute。

四十二、建议使用Global Entity ID

site_001
page_000128
url_003911
content_000091
release_20260909_001
incident_20260909_003

四十三、Data Join围绕Entity ID

GSC URL
↓
URL Resolver
↓
url_id
↓
page_id

四十四、URL Resolver是Search Data Platform核心服务

HTTP/HTTPS
www/non-www
trailing slash
redirect
canonical
parameters
case
international variants

四十五、Canonical Mapping必须可追溯

Mapping需要valid_from / valid_to，支持历史分析。

四十六、Temporal Entity Model

不能只保存current_state，还要保存state_history，否则Experiment、Incident和Causal Analysis都无法回溯。

四十七、第五层：Warehouse

Canonical Layer完成以后，长期、可Join、可查询的数据才真正进入Analytical Warehouse。

四十八、建议采用事实表 + 维度表

Facts:
fact_search_performance
fact_ga4_events
fact_crawl
fact_geo_observation
fact_release
fact_incident
fact_experiment_result
fact_agent_run

Dimensions:
dim_site
dim_page
dim_url
dim_query
dim_query_cluster
dim_country
dim_device
dim_content
dim_prompt
dim_agent

四十九、不要把所有数据塞进一张超级宽表

短期方便，长期会产生定义冲突、大量NULL和不可维护的更新逻辑。

五十、Raw、Canonical、Serving三层职责分离

RAW
↓
CANONICAL
↓
SERVING

五十一、BigQuery Partition按访问模式设计

例如fact_search_performance按data_date分区，可以通过Partition Pruning减少扫描。

五十二、Cluster进一步优化常用实体查询

PARTITION:
date

CLUSTER:
site_id
page_id
query_cluster_id

五十三、Data Warehouse也是Cost Architecture

Partition和Clustering不仅影响性能，也直接影响查询成本。

五十四、不要让Agent执行无界SQL

Agent SQL Tool应强制date range、site_id、max bytes、row limit。

五十五、Warehouse Query也需要Budget Gate

estimated_bytes
query_cost
timeout
row_limit
→ QUERY_BLOCKED / USE_PREAGGREGATED_TABLE

五十六、第六层：Semantic Layer

Warehouse有数据不代表大家对Organic Sessions、Leads、Search Visibility的定义一致，因此必须建立Metric Registry。

五十七、Metric Registry示例

metric_id:
organic_clicks

source:
gsc

definition:
SUM(clicks)

grain:
site + date

filters:
search_type = WEB

owner:
measurement

version:
v2

五十八、核心KPI都应该版本化

Lead定义变化时，历史报表不能悄悄改变。

五十九、Metric Definition和Data Lineage一起保存

Metric
↓
Serving Table
↓
Canonical Transform
↓
Raw Source

六十、建立Data Lineage

Organic Leads
↓
fact_conversion_daily
↓
GA4 event normalization
↓
GA4 BigQuery Export

六十一、Data Quality成为独立系统

Freshness
Completeness
Uniqueness
Validity
Consistency
Volume

六十二、建议Data Quality Event

{
  "event_type": "data.quality.failed",
  "dataset": "gsc_daily",
  "check": "freshness",
  "severity": "P1"
}

六十三、直接连接Data Quality Gate

GSC DATA STALE
↓
DATA_QUALITY = FAILED
↓
ANALYSIS_BLOCKED

六十四、第七层：Feature Store

Feature Store解决Agent和模型反复需要的Decision Features，而不是再复制一份Warehouse。

六十五、什么叫Feature

clicks_7d
clicks_28d
impressions_28d
ctr_delta_28d
position_delta_28d
organic_sessions_28d
lead_rate_28d
days_since_publish
days_since_google_crawl
content_age_days
canonical_changed_30d
indexing_issue_count
internal_links_in
geo_citation_frequency

六十六、Feature Store让Agent从“重新分析历史”变成“读取当前状态”

page_id
↓
Feature View
↓
Decision Agent

六十七、Feature Store首先是工程概念

早期可直接使用BigQuery Feature Tables，例如feature_page_daily、feature_query_cluster_daily、feature_site_daily、feature_prompt_daily。

六十八、BigQuery可以作为Feature数据基础

Time-sensitive Feature需要时间戳，从而支持Point-in-time Correctness；在需要低延迟Serving时再接专业Feature Store。

六十九、Point-in-time Correctness非常关键

评估9月1日Agent Decision时不能读取9月20日才生成的Feature，否则产生Data Leakage。

七十、Experiment必须防止未来数据泄漏

Decision Date:
Sep 1

Feature:
AS OF Sep 1

七十一、Feature必须拥有feature_timestamp

page_id
feature_name:
ctr_28d
feature_value:
0.043
feature_timestamp:
2026-09-01T00:00:00Z

七十二、Feature Registry必须存在

feature_id
name
entity
definition
source
refresh_frequency
freshness_sla
owner
version

七十三、Feature不是永久真理

Definition变化必须版本化，不能覆盖历史。

七十四、适合SEO Orchestrator的Features

business_value_score
traffic_risk_score
indexing_risk_score
content_staleness_score
release_risk_score
geo_opportunity_score
experiment_eligibility_score
incident_probability_score

七十五、Score必须可解释

需要保留score_version、inputs、calculated_at，而不是只有magic_score。

七十六、第八层：Serving Layer

Warehouse适合复杂分析，但Agent日常决策需要Serving Tables、Views、APIs和Feature Views。

七十七、不同Consumer需要不同Serving Surface

Dashboard → daily_site_summary
Monitoring Agent → current_alert_features
Content Agent → page_content_context
Experiment Agent → experiment_measurement_view

七十八、Agent不应默认直接访问Raw Table

Agent
↓
Semantic / Serving API

Deep Diagnostic
↓
Raw Drilldown

七十九、这也是Security Boundary

Research Agent通常不需要访问所有GA4 User-level Raw Event，聚合结果已足够。Least Data Privilege和Least Tool Privilege同样重要。

八十、Data Security继承第十七篇

Raw GA4 → restricted
Aggregated SEO Feature → broader agent access

八十一、Trace数据接入Data Platform

Agent Tracing中的模型调用、Tool Calls、Handoffs、Guardrails和Custom Events可以形成统一trace_id。

八十二、Trace不能无脑全文入Warehouse

TRACE
↓
REDACT
↓
STRUCTURED METADATA
↓
WAREHOUSE

八十三、Agent Trace最有价值的是结构化元数据

agent_id
task_id
model
tool_calls
duration
tokens
outcome
policy_blocks
human_override
cost
trace_id

八十四、Agent Run成为Warehouse Fact

fact_agent_run:
task_type
agent_version
model
started_at
ended_at
status
cost
tool_count
human_review
validated_outcome

八十五、Experiment成为一等数据实体

dim_experiment
fact_experiment_measurement
fact_experiment_result

八十六、Experiment关联

experiment_id
↓
treatment_pages
control_pages
↓
releases
↓
measurement
↓
result

八十七、Incident必须进入Warehouse

incident_id
started_at
detected_at
mitigated_at
resolved_at
affected_pages
severity
root_cause
related_release

八十八、系统因此能回答“流量下降之前发生了什么”

Page Performance
+
Release Events
+
Crawler Events
+
Incident
+
Google Update

八十九、Event Correlation

10:00 Release
10:05 Canonical changed
10:12 Crawler detects noindex
10:20 Incident opened
Next days GSC impressions fall

九十、统一Timeline是Root Cause Analysis核心资产

Incident Timeline可以由Event Store自动生成，而不再依赖人工拼日志。

九十一、GEO数据进入统一Entity体系

prompt_id
answer_id
platform
brand_mentioned
citation_id
citation_url_id
competitor_entity
observed_at

九十二、Citation URL解析成统一url_id

Citation URL
↓
URL Resolver
↓
url_id
↓
page_id

九十三、这是真正的SEO + GEO统一Measurement

PAGE成为共同实体，一张Page可以同时拥有GSC Performance、GA4 Outcome、Crawler State、GEO Citation、Content Version与Release History。

九十四、最终Agent查询“Page 360”

GET /page/page_00128/context

current_url
search_features
analytics_features
technical_state
content_version
geo_state
recent_releases
open_incidents
active_experiments

九十五、Page 360不是把全部Raw Data丢给Agent

它提供Minimum Sufficient Context。

九十六、Data Platform和Agent Economics连接

Shared Data
→ Less API
→ Less Compute
→ Less Context
→ Lower Cost

九十七、Change Detection由Data Platform提供

page.changed
content.changed
canonical.changed
traffic.anomaly
citation.changed

九十八、解决“每天全部重跑”

Source Change
↓
Event
↓
Affected Entity
↓
Incremental Recompute

九十九、Feature也Incremental Update

只重算Affected Pages、Changed Windows、Updated Metrics。

一百、Data Platform需要Schema Registry

Event Payload变化要通过event_version/schema_version管理。

一百零一、Data Contract明确Backward Compatibility

Required、Optional、Deprecated字段都要有清晰语义。

一百零二、Schema Change也产生Event

data.schema.changed
↓
Feature Pipeline
Dashboard
Agent Tool

一百零三、Data Quality应该有SLA

GSC、Release Event、Crawler等数据源拥有不同Freshness Expectation。

一百零四、Agent必须知道数据新鲜度

gsc_data_age=36h时，Agent应降低Confidence，而不是假装实时。

一百零五、建立Freshness Metadata

generated_at
source_max_event_time
freshness_status

一百零六、Agent Decision记录Data Snapshot

decision_id
data_snapshot_id

一百零七、Decision Reproducibility

一个月后重新运行Query时数据已经变化，因此必须能还原当时Agent看到什么。

一百零八、Data Snapshot和Agent Trace连接

trace_id
↓
decision_id
↓
data_snapshot_id

一百零九、Data Lineage连接Knowledge

Knowledge Object应关联experiment_id、metric_version、data_snapshot_id和source_tables，而不是只保存一句结论。

一百一十、Knowledge因此真正Evidence-backed

第十二篇的Knowledge Base获得底层数据证据。

一百一十一、Search Data Platform还需要Data Catalog

dataset
table
field
owner
description
sensitivity
freshness
lineage

一百一十二、Agent不应该自己猜字段含义

position必须明确是GSC Average Position还是Rank Tracker Position，Semantic Layer负责定义。

一百一十三、Feature Store不是Warehouse替代品

Warehouse:
What happened?

Feature Store:
What is the current decision-ready state?

一百一十四、Event Bus也不是Warehouse替代品

Event Bus:
Something happened.

Warehouse:
What happened over time?

一百一十五、Knowledge Base也不是Warehouse

Knowledge:
What have we learned?

Warehouse:
What was observed?

一百一十六、四者必须分清

EVENT BUS
What happened now?

WAREHOUSE
What happened historically?

FEATURE STORE
What features are ready for decisions?

KNOWLEDGE BASE
What did we learn?

一百一十七、Search Data Platform最终服务Orchestrator

Event
↓
Data Platform
↓
Features
↓
Orchestrator
↓
Agent

一百一十八、降低Agent自由查询范围

从“Go investigate everything”升级为“Here is the relevant Entity Context. Investigate this anomaly.”

一百一十九、Agent按需Drill Down

Feature / Aggregate
↓
Need More?
↓
Canonical Data
↓
Need More?
↓
Raw Evidence

一百二十、这也是Cost-aware Query Strategy

先Cheap Summary，需要时再逐层深入，而不是每次Deep Scan。

一百二十一、项目当前最值得优先实施的P0 Data Architecture

1. 统一 site_id / page_id / url_id
2. 建立 Release Manifest Table
3. GSC历史数据进入Warehouse
4. GA4关键数据进入统一Warehouse
5. Crawler输出使用统一url_id
6. 建立Event Schema
7. GitHub / WordPress发布产生Release Events
8. Incident / Experiment使用稳定ID
9. 建立page_daily_feature
10. 统一Data Freshness与Quality状态

一百二十二、P1：Event-Driven Search Operations

GitHub Webhooks
WordPress Publish Event
Crawler Change Event
Traffic Anomaly Event
Data Quality Event
Incident Event
Experiment Event
Feature Recompute Queue

一百二十三、P2：Unified Search Intelligence Warehouse

GSC
+
GA4
+
Crawler
+
Content
+
Release
+
GEO
+
Incident
+
Experiment
+
Agent Trace

一百二十四、P3：Feature & Serving Layer

page_feature_view
query_cluster_feature_view
site_health_feature_view
prompt_feature_view
agent_feature_view

一百二十五、第一个Page Feature Schema

page_id
as_of
url_id
page_type
business_value
clicks_7d
clicks_28d
impressions_28d
ctr_28d
ctr_delta_28d
position_28d
position_delta_28d
sessions_28d
leads_28d
lead_rate_28d
index_status
http_status
canonical_state
days_since_publish
days_since_content_update
days_since_crawl
internal_link_count
geo_mentions_28d
geo_citations_28d
open_incident
active_experiment
recent_release
feature_version

一百二十六、Feature View会改变Agent架构

page_id
↓
page_feature_view
↓
CREATE / UPDATE / MERGE / NO_ACTION

一百二十七、Monitoring Agent也一样

site_health_feature_view:
5xx_rate
indexing_anomaly
traffic_loss
conversion_loss
recent_release
platform_incident
data_quality

一百二十八、Experiment Agent使用Point-in-time Features

Treatment Page Features必须AS OF Experiment Start，防止未来信息泄漏。

一百二十九、GEO Agent使用Prompt Feature View

prompt_id
mention_frequency
citation_frequency
brand_presence
competitor_presence
citation_url_distribution
ai_referral_sessions
last_observed_at

一百三十、Evaluation Agent也可以拥有Feature

agent_id
task_type
eval_pass_rate
tool_accuracy
policy_violation_rate
cost_per_validated_outcome
human_override_rate

一百三十一、支持Capability-based Routing

第十四篇提出“Which agent is validated for this task?”，现在终于有统一数据底座支撑。

一百三十二、Data Platform本身也必须Monitoring

event_lag
pipeline_failure
warehouse_freshness
feature_staleness
schema_failure
duplicate_event_rate
dead_letter_queue

一百三十三、数据基础设施故障也是Incident

GSC Export停止数天可能导致Monitoring、Experiment、Content和Agent Decision全部失真，因此应正式定义DATA INCIDENT。

一百三十四、Data Incident自动传播Confidence

GSC_DATA = STALE
↓
features / decisions / reports
↓
confidence ↓

一百三十五、需要Dependency Graph

GSC
↓
search_daily
↓
traffic_risk_feature
↓
Monitoring Agent

一百三十六、Data Dependency Graph与Security Graph相互补充

Security Graph:
Who can access what?

Data Graph:
What depends on what?

一百三十七、最终架构

SOURCES
GSC / GA4 / Crawler / WordPress / GitHub
GEO / Incident / Experiment / Trace
        ↓
INGESTION
Batch / API / Webhook / Stream
        ↓
EVENT BUS
        ↓
RAW LAYER
        ↓
NORMALIZATION
        ↓
ENTITY RESOLUTION
        ↓
CANONICAL WAREHOUSE
        ↓
SEMANTIC / METRIC LAYER
        ↓
FEATURE STORE
        ↓
SERVING LAYER
        ↓
Agents / Dashboards / Alerts / Experiments / Reports / Orchestrator

一百三十八、完整闭环变成Data-driven Control Loop

EVENT
↓
INGEST
↓
NORMALIZE
↓
FEATURE
↓
DECIDE
↓
ACT
↓
OBSERVE
↓
WAREHOUSE
↓
LEARN
↓
NEW FEATURE
↓
NEXT DECISION

一百三十九、第十八篇解决的是Data-level Organizational Memory

第十二篇解决“What have we learned?”，第十八篇解决“What actually happened?”。两者结合，Agent才能拥有可靠长期记忆。

一百四十、没有统一Data Platform，自治Agent最终会发生事实漂移

每个Agent自己查询、计算、缓存和定义，时间越长，定义差异越大。

一百四十一、Agent之前必须先统一Data

More Agents
≠
Better System

Better Shared State
→
Better Agents

一百四十二、第十八篇核心原则

不要让每个Agent重新发现事实；让数据平台负责维护事实，让Agent负责解释、决策和行动。

结语：真正的Search Operating System必须拥有共享的数据现实

当GSC说页面获得点击、GA4说用户进入网站、WordPress说内容在哪天修改、GitHub说哪个Commit产生Release、Crawler说Canonical何时变化、GEO系统说Prompt何时开始引用URL、Incident系统说何时发生故障、Experiment系统说哪个页面属于Treatment、Agent Trace记录哪个Agent据此做了什么判断——这些数据必须能够在同一Entity、Time、Version与Lineage体系中关联。

WHO
did
WHAT
to WHICH ENTITY
WHEN
based on WHICH DATA
using WHICH VERSION
producing WHICH OUTCOME

Agent不应该成为数据整合层；Agent应该消费已经被统一、版本化、可追溯的数据。

Event Bus
+
Warehouse
+
Semantic Layer
+
Feature Store
+
Knowledge Base
=
Search Data Plane

Orchestrator
+
Policy
+
Agents
+
Release
+
Monitoring
=
Search Control Plane

当Data Plane与Control Plane真正接起来，前十八篇才开始从一组Automation Workflow升级成一个真正可以长期运行、学习和扩展的Search Operations Platform。

来源与延伸阅读

• Google Search Central — Search Console Bulk Data Export
• Google Search Central — BigQuery Efficiency Tips
• Google Analytics — BigQuery Export
• Google Cloud — Pub/Sub Overview
• Google Cloud — BigQuery Partitioned Tables
• Google Cloud — BigQuery Clustered Tables
• Google Cloud — Feature Store / Feature Serving
• GitHub — Webhooks
• GitHub — Validating Webhook Deliveries
• WordPress REST API — Posts
• WordPress REST API — Post Revisions
• OpenAI Agents SDK — Tracing