智能体已经就位,但企业数据还没有:从记录系统走向行动系统

2026-07-24 21 预计阅读时间: 1 分钟
来源: cloud.google.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间:12 分钟

企业把 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 描绘的是一种从“保存事实”转向“带着可信语境执行动作”的架构。模型决定智能体能思考到哪里,数据和基础设施则决定它能否稳定、安全、经济地完成工作。真正需要准备的,不只是更多算力,而是一套可检索、可解释、可授权并可执行的数据系统。


相关推荐