S3数据不搬家，Agent先补语义层
很多企业做数据 Agent 时，第一反应是：
先把数据搬到一个新平台
↓
再做统一建模
↓
再接AI
项目很快变成一个大规模数据迁移工程。
Google Cloud 8 月 24 日公开的 SOAP Architecture 提供了另一条路径：数据可以继续留在 S3 等原位置，先把访问、语义和业务关系层建立起来，再让 Agent 使用。
SOAP 是：
Semantic
Ontology
Agent
Platform
它的核心并不是某一个新产品，而是一张组合架构：
S3 / Iceberg
↓
Borderless Lakehouse
↓
BigQuery
↓
LookML Semantic Layer
+
BigQuery Graph
+
Knowledge Catalog / OKF
↓
Conversational Analytics
↓
Gemini Enterprise / A2A / Coding Agent
真正值得研究的是它把“数据迁移”和“AI可用”拆开了。
第一层：先解决能不能查，不先解决搬不搬
如果 S3 上已经有 Apache Iceberg 表，Google 给出的路径是：
S3 Iceberg
↓
Cross-Cloud Interconnect
↓
BigQuery直接查询
同时通过 Catalog Federation 同步：
AWS Glue Data Catalog
Databricks Unity Catalog
Snowflake Horizon
的元数据。
这意味着：
数据物理位置
和：
查询入口
可以分开。
对 Agent 来说，它真正需要的是：
可查询
可授权
可解释
不一定要求：
全部复制到同一个Bucket
什么时候“先不搬”特别有价值
比如企业有：
120TB S3历史数据
3000张表
多个业务系统
其中很多表已经很少使用。
如果先全量搬：
网络
存储
ETL
校验
停机窗口
权限重建
成本非常高。
更现实的步骤：
1. 只读连接
2. 统计访问频率
3. 建立语义层
4. 让Agent先能解释和查询
5. 再决定哪些真的值得迁
迁移从前置条件变成后续优化。
先做Access Inventory
我会先生成：
Table
Size
Last Query
Query Count 30d
Query Count 365d
Owner
Data Class
例如：
select
table_name,
size_bytes,
last_access_at,
query_count_30d,
query_count_365d
from inventory;
然后分类：
HOT
WARM
COLD
UNKNOWN
如果：
12个月无人访问
它至少应该进入：
Archive / Delete Candidate
而不是默认迁移。
第二层：最重要的不是Schema，而是Metric Definition
一个数据 Agent 最容易犯的错不是 SQL 写错。
而是：
“销售额”
到底指什么？
财务：
已确认收入
销售：
订单金额
运营：
GMV
如果 Agent 只看数据库字段：
amount
revenue
gmv
它很可能自己猜。
SOAP 把 LookML 作为 Semantic Layer，目的就是把：
指标
维度
业务定义
放在模型之外。
一个简单语义对象
metric: active_customer
definition:
customer with at least one
paid order in last 90 days
source:
orders
filter:
status = PAID
owner:
revenue-analytics
version:
v12
Agent 问：
活跃客户有多少？
不需要自己发明定义。
语义层必须版本化
今天：
90天有支付订单
明天业务改成：
60天
如果不保存版本，历史报告无法解释。
所以每次 Agent Answer 都应该记录：
metric_version
例如：
{
"metric": "active_customer",
"version": "v12",
"value": 18291
}
第三层：关系不是JOIN猜出来的
很多 NL2SQL Agent 会做：
Schema
↓
LLM猜JOIN
例如：
customer.id
orders.customer_id
简单场景没问题。
一旦企业有：
Account
Customer
Organization
Contract
Store
Distributor
关系语义非常复杂。
SOAP 用 BigQuery Graph 表达实体和关系，目的是让 Agent 不再自己猜：
Customer → Order
Order → Product
Customer → Organization
Organization → Region
这些关系可以明确建成 Property Graph。
为什么Graph比“把Schema给模型”更稳
Schema 只能说明：
有什么字段
Graph 说明：
哪些实体
通过什么业务关系
连在一起
Agent 问：
哪些华东客户购买了A产品，
但最近90天没有续购？
需要走：
Region
→ Organization
→ Customer
→ Order
→ Product
如果关系来自显式图模型，错误 JOIN 的空间会小很多。
第四层：OKF把业务知识变成可Review资产
SOAP 里还有 Open Knowledge Format（OKF）和 Knowledge Catalog。
Google 的思路是：
表的含义
指标背景
运维知识
Wiki信息
可以生成成 Markdown Bundle，并进入 Git 管理。
这个方向我很认同。
因为数据知识最怕：
只存在某个分析师脑子里
或者：
散落在Wiki
没人知道是否过期
如果 OKF 进入 Git：
变更
→ PR
→ Review
→ Version
Agent 使用的是明确版本。
一个OKF目录可以长这样
knowledge/
├── customer/
│ ├── entity.md
│ ├── metrics.md
│ └── relationships.md
├── order/
│ ├── entity.md
│ └── status.md
└── governance/
└── data-classification.md
metrics.md：
# Active Customer
Definition:
At least one paid order in 90 days.
Owner:
Revenue Analytics.
Source:
orders.status = PAID.
Do not use:
crm.last_contact_at.
最后一句：
Do not use
对 Agent 很重要。
Knowledge也需要Owner
每个定义至少有：
Owner
Source
Updated At
Review Cycle
没有 Owner 的知识条目：
不能作为高置信生产依据
可以标记：
UNVERIFIED
三种入口共享一套Grounding
SOAP 提到三个入口。
第一类：
Looker Dashboard
+
Conversational Analytics
第二类：
BigQuery Conversational Analytics
+
BigQuery Graph
+
Gemini Enterprise
第三类：
VS Code / Claude Code
+
Data Agent Kit
真正重要的是：
入口不同
Grounding相同
不要为：
BI Agent
Coding Agent
Slack Agent
各自维护一套指标定义。
那样很快就会：
三个Agent
三个答案
权限也应该复用数据平台原有控制
SOAP 明确强调：
不需要为Agent重新发明一套数据权限
BigQuery 和 Looker 已有访问控制继续生效。
这是数据 Agent 很重要的边界。
不要因为 Agent 需要方便查询，就创建：
super_reader
给它全库读权限。
更合理：
User Identity
→ Existing Data Policy
→ Agent Delegation
Agent 看到的范围不超过用户和业务目的允许范围。
我会把查询分成三阶段
Stage 1：Metric Resolution
先确定：
用户问的业务概念是什么
例如：
活跃客户
映射到：
active_customer:v12
Stage 2：Relationship Resolution
确定实体路径：
Region
→ Customer
→ Order
Stage 3：Query Generation
最后才生成：
SQL / GQL
很多系统一上来就：
自然语言 → SQL
中间两个步骤都省了。
这就是幻觉入口。
Query Plan最好可见
例如 Agent 输出：
{
"metrics": [
"active_customer:v12"
],
"dimensions": [
"region:v4"
],
"relationship_path": [
"region->organization",
"organization->customer"
],
"filters": [
"region=华东"
]
}
确认后再生成查询。
这让 Review 容易很多。
可以做Semantic Gate
public record SemanticQueryPlan(
Set metrics,
Set dimensions,
List joins,
List filters) {
}
Gate：
所有Metric必须存在
所有Relationship必须在Graph中
所有字段必须有权限
不通过：
禁止SQL执行
语义版本变化需要Regression
比如：
active_customer:v12
→ v13
所有依赖这个 Metric 的：
Dashboard
Agent Eval
Report
Workflow
都应该重新跑。
可以维护：
Metric → Consumer
依赖图。
Agent生成迁移计划也值得借鉴
SOAP 还提出一个很实用的思路：Agent 先只读收集元数据和查询历史，再把表分成：
Migrate
Archive
Keep
Delete Candidate
Need Review
并生成机器可读 Migration Manifest。
例如：
table: legacy_order_2018
decision: ARCHIVE
reasons:
- no_query_18_months
- replaced_by_order_v2
confidence: 0.94
human_review: required
这比：
让AI写一份迁移PPT
实际得多。
Manifest应该能直接驱动下一阶段
例如：
table: customer_profile
decision: MIGRATE
target:
format: ICEBERG
dataset: customer_core
ddl_ref:
ddl/customer_profile.sql
validation:
row_count: true
checksum: true
批准后自动生成 DDL、验证任务。
这才叫：
Executable Migration Plan
“零复制”也不是完全免费
不要误解成：
跨云查询没有任何成本
仍然要考虑：
Interconnect
Query Cost
Cache
Latency
Availability
Network
所以工作负载要分。
高频低延迟：
可能最终值得搬
低频历史：
继续跨云查
不要宗教化“永不迁移”。
一个迁移决策公式
Migration Score
=
Query Frequency
× Latency Sensitivity
× Cost Delta
× Strategic Importance
再减：
Migration Complexity
不是：
只要在S3就全部搬
语义层才是Agent真正需要的“API”
数据库 Schema 是技术接口。
Agent 更需要：
业务语义接口
例如：
metric.active_customer
entity.customer
relation.customer_orders
这样模型在不同底层平台上都可以复用。
未来换：
BigQuery
Snowflake
Databricks
只要语义 Contract 保持，Agent 上层变化会小很多。
我会给语义对象做测试
例如：
metric: revenue
tests:
- fixture: 2026-08-01
expected: 1829102.18
- fixture: canceled_orders
expected_exclusion: true
Semantic Layer 也应该有 CI。
最后一个关键指标：Answer Provenance
Agent 回答：
华东活跃客户 18291
至少携带：
Metric:
active_customer:v12
Data Snapshot:
2026-08-25T08:00
Relationship:
region→organization→customer
Query ID:
BQ-9182
不是只返回一句自然语言。
数据 Agent 真正难的地方，不是“模型会不会写 SQL”。
而是：
指标定义
实体关系
权限
知识版本
有没有统一。
SOAP Architecture 最值得借鉴的地方，是它把“先大迁移、再AI”的顺序反过来了：
先连接
→先补语义
→先建立关系
→先让Agent在原数据上工作
→再决定什么真的值得迁
这会让很多原本几年才能看到 AI 价值的数据现代化项目，先从只读、低风险、可验证的一层开始。
对企业来说，真正要先搬的可能不是数据。
而是把散落在人脑、Wiki 和 SQL 里的业务含义，搬进一套可以版本化和被 Agent 直接读取的语义层。
更多企业级 AI 应用、Agent、RAG 与模型工程化内容，我会继续整理在 智元界：
https://www.zyentor.com/