企业把 AI 智能体推向生产时,真正卡住规模化的往往不是模型能力,而是数据能否提供可信的业务语境。智能体需要理解客户、订单、权限和业务规则,还要跨系统查询并执行操作。一次提示词就可能触发多轮检索、数据库查询和 API 调用,原本面向人工访问设计的数据平台,很容易在这种非线性负载下暴露延迟、成本和治理问题。
Google Cloud 在 Next 2026 提出的 Agentic Data Cloud,核心目标是把数据、模型与运营数据库组织成统一的“行动系统”。这不只是增加一个向量数据库或接入一个大模型,而是要求计算、网络、存储、语义目录和事务系统共同适配智能体负载。
智能体缺的不是更多数据,而是可用语境
传统数据平台更像被动的记录系统:数据进入仓库,分析人员编写 SQL,报表再交给业务人员决策。智能体则需要在一次任务中完成“理解、查证、推理、执行”闭环。
这里的上下文至少包含四层:
- 事实数据:客户、库存、订单和设备状态等实时记录。
- 语义定义:什么是活跃客户,收入采用哪个口径,退款状态如何解释。
- 关系与历史:实体之间的关联、用户偏好以及之前执行过的操作。
- 策略边界:谁可以读取什么数据,哪些动作必须审批,哪些字段不得进入模型上下文。
如果这些信息散落在数据湖、ERP、CRM、文档和遗留 API 中,智能体即使能够调用工具,也可能拿到不完整或相互矛盾的答案。来源摘要中的调查数据显示,43% 的 IT 负责人把遗留 API 和数据源的集成困难视为主要基础设施缺口。
Agentic Data Cloud 给出的方向是“无边界 Lakehouse”:通过 Apache Spark、Apache Iceberg 等开放标准,让 BigQuery、Spanner 等原生引擎访问跨环境数据。重点不是把所有数据复制到一个位置,而是降低跨系统读取、推理和激活数据时的迁移成本与延迟。
非线性调用会把基础设施问题放大
用户发送一条“检查高价值客户的延迟订单并安排补偿”指令,智能体可能执行十几步操作:识别客户、读取订单、查询物流、检查补偿规则、计算额度、写入 CRM,再调用通知服务。多个智能体并发运行后,负载不再等同于传统应用的一次请求对应一次查询。
这会产生几个直接后果:
- 查询扇出增加,连接池、API 配额和数据库并发率先成为瓶颈。
- 重复检索相同上下文,提高向量查询、模型调用和网络传输成本。
- 分析系统与事务系统之间存在多个网络跳点,端到端延迟难以预测。
- 智能体重试可能重复执行写操作,造成重复退款、重复建单等业务事故。
这也是为什么摘要中有 83% 的组织认为,生产级智能体 AI 需要基础设施升级;81% 的负责人则把运营复杂度和工程开销列为扩展 AI 时的主要意外成本。芯片到模型的纵向协同可以减少网络跳转并提升吞吐,但应用层仍需明确设置并发、超时、缓存、幂等和审计策略。
可以这样实践:给智能体建立受控的数据工具层
下面是一个可运行的最小 Python 示例。它不依赖特定云 API,假设企业通过受控工具层向智能体提供数据,而不是允许模型直接连接生产数据库。示例演示了三个关键机制:语义说明、参数化查询和幂等写入。
运行前准备 Python 3.10 或更高版本,然后将以下内容保存为 agent_data_layer.py 并执行 python agent_data_layer.py:
import json
import sqlite3
from datetime import datetime, timezone
DB_PATH = "agent_demo.db"
SEMANTIC_CONTEXT = {
"delayed_order": "status='delayed' and promised_at is earlier than now",
"high_value_customer": "customer_tier='gold'",
"compensation_policy": "Gold customers with delayed orders receive 20 credits",
}
def connect():
db = sqlite3.connect(DB_PATH)
db.row_factory = sqlite3.Row
return db
def initialize():
with connect() as db:
db.executescript(
"""
CREATE TABLE IF NOT EXISTS orders (
order_id TEXT PRIMARY KEY,
customer_id TEXT NOT NULL,
customer_tier TEXT NOT NULL,
status TEXT NOT NULL,
promised_at TEXT NOT NULL
);
CREATE TABLE IF NOT EXISTS actions (
idempotency_key TEXT PRIMARY KEY,
action_type TEXT NOT NULL,
payload TEXT NOT NULL,
created_at TEXT NOT NULL
);
"""
)
db.execute(
"""
INSERT OR REPLACE INTO orders
(order_id, customer_id, customer_tier, status, promised_at)
VALUES (?, ?, ?, ?, ?)
""",
("ORD-1001", "CUS-42", "gold", "delayed", "2026-03-01T10:00:00Z"),
)
def find_compensation_candidates():
with connect() as db:
rows = db.execute(
"""
SELECT order_id, customer_id
FROM orders
WHERE customer_tier = ?
AND status = ?
AND promised_at < ?
""",
("gold", "delayed", datetime.now(timezone.utc).isoformat()),
).fetchall()
return [dict(row) for row in rows]
def create_compensation(order_id, customer_id, credits=20):
key = f"delay-credit:{order_id}"
payload = json.dumps(
{"order_id": order_id, "customer_id": customer_id, "credits": credits},
ensure_ascii=False,
)
with connect() as db:
cursor = db.execute(
"""
INSERT OR IGNORE INTO actions
(idempotency_key, action_type, payload, created_at)
VALUES (?, ?, ?, ?)
""",
(key, "grant_credit", payload, datetime.now(timezone.utc).isoformat()),
)
return {"created": cursor.rowcount == 1, "idempotency_key": key}
if __name__ == "__main__":
initialize()
print("Semantic context:", json.dumps(SEMANTIC_CONTEXT, indent=2))
for order in find_compensation_candidates():
result = create_compensation(**order)
print(order, result)
连续运行两次后,第二次不会创建重复补偿记录。迁移到真实平台时,可以把 SQLite 查询替换为 BigQuery、Spanner 或内部 API,但应保留以下边界:
- 模型只能调用经过授权和参数校验的工具。
- 写操作必须带幂等键,并记录调用者、依据和结果。
- 高风险事务先生成执行计划,再交由策略引擎或人工审批。
- 语义定义由数据治理团队维护,不应只写在提示词里。
还可以给每个工具声明结构化契约,使模型清楚工具用途和限制。例如,下面的工具描述可以交给支持函数调用的模型;具体请求格式需要按所选模型 SDK 调整:
{
"name": "create_compensation",
"description": "为符合已批准政策的延迟订单创建补偿。调用前必须查询订单状态。",
"input_schema": {
"type": "object",
"properties": {
"order_id": {"type": "string"},
"customer_id": {"type": "string"},
"credits": {"type": "integer", "minimum": 1, "maximum": 20},
"idempotency_key": {"type": "string"}
},
"required": ["order_id", "customer_id", "credits", "idempotency_key"],
"additionalProperties": false
}
}
语义目录要成为运行时组件
传统数据目录通常服务于人工搜索和治理检查。面向智能体时,目录需要成为主动推理层:从非结构化资料中提取含义,将业务术语关联到表、字段、文档和策略,并在每次任务中返回经过权限过滤的上下文。
摘要提到 Knowledge Catalog 可用于聚合、丰富数据湖中的数据并支持智能体搜索。目录背后仍需要高吞吐检索基础设施,否则每个任务都重新解析文档、生成向量并搜索全部语料,延迟和成本会快速上升。调查中有 36% 的负责人把缺少专用高吞吐向量数据库列为关键缺口,也反映了这一问题。
不过,向量检索并不等同于可信知识。生产系统还要处理文档版本、数据血缘、租户隔离、访问权限和失效时间。检索结果最好附带来源标识、更新时间和置信信息,使智能体能够拒绝过期或冲突的上下文。
从试点走向生产的检查清单
企业不必一次性重建所有数据平台。更稳妥的顺序是选取一个有明确价值、风险可控的工作流,然后沿着真实调用链补齐能力:
- 盘点任务需要访问的分析数据、运营数据、文档和遗留 API。
- 为关键指标和业务动作建立统一语义定义与责任人。
- 测量单个任务的查询扇出、网络跳数、令牌消耗和端到端延迟。
- 对读取实施最小权限,对写入增加幂等、审批、审计和回滚机制。
- 缓存稳定上下文,但为库存、余额和权限等实时数据设置严格失效策略。
- 用并发智能体压测基础设施,而不是只测试单轮聊天响应时间。
- 评估开放格式和标准接口,避免语义层与数据层被单一模型绑定。
Agentic Data Cloud 描绘的是一种从“保存事实”转向“带着可信语境执行动作”的架构。模型决定智能体能思考到哪里,数据和基础设施则决定它能否稳定、安全、经济地完成工作。真正需要准备的,不只是更多算力,而是一套可检索、可解释、可授权并可执行的数据系统。