Amazon Quick 新增了预览版 Agentic Catalog Experience，面向负责整理和发布数据资产的数据管理员。它把目录检索、上游资产识别以及 Dataset 和 Topic 创建串成一个 AI 驱动的工作流，让用户可以用自然语言寻找数据，并把已有目录中的业务语义带入新资产。目前，该体验支持 AWS Glue Data Catalog 和 Databricks Unity Catalog。
从“找表”变成“理解可用数据”
传统数据目录通常要求使用者知道数据库名、表名或字段名。面对数百个数据源时，数据管理员可能需要先搜索关键词，再逐张检查字段、描述和血缘关系，最后才能判断哪张表适合构建分析数据集。
Agentic Catalog Experience 改变的是交互入口。数据管理员可以用接近业务问题的语言描述需求，例如：
查找包含客户、订单日期、地区和净销售额的上游资产，
优先选择已有字段说明且适合按月汇总的数据。
系统的目标不只是返回名称匹配的表，而是帮助发现相关的上游目录资产。确认资产后，工作流还能自动创建 Dataset 和 Topic，并继承目录里已经维护的语义信息。
这里的价值在于减少重复建模。字段说明、业务含义等语义如果已经存在于上游目录，就不必在每个分析入口中重新录入。不过，来源摘要没有说明具体会继承哪些属性，也没有承诺所有元数据都能无损映射。因此在预览阶段，团队仍应逐项检查名称、字段类型、描述和业务口径。
Dataset 与 Topic 自动创建意味着什么
自动创建并不等于自动治理。它更适合承担机械工作：定位候选资产、生成初始对象，并把已有语义带到新的分析层。数据管理员仍要负责确认几个关键问题：
- 候选表是否来自正确的数据域和环境。
- 金额、客户数等指标是否采用一致口径。
- 字段描述是否仍然有效，而不是过期注释。
- 新 Dataset 是否暴露了敏感字段。
- Topic 中的业务术语是否会产生歧义。
如果上游目录维护得很差，智能工作流只会继承质量有限的语义。反过来，拥有清晰字段注释、稳定命名和明确所有者的目录，更容易从自动创建流程中获益。
可以这样实践：先检查 Glue 目录的语义质量
Agentic Catalog Experience 的具体编程接口没有在摘要中给出。下面不是该预览功能的 API，而是一个可直接运行的目录检查脚本，用来模拟上线前的准备工作：根据自然语言关键词搜索 AWS Glue 表，并显示表描述、字段类型和字段注释。
运行前需要安装 boto3，配置可读取 Glue Data Catalog 的 AWS 凭证，并把区域和关键词改成自己的环境：
python -m pip install boto3
export AWS_REGION=us-east-1
export CATALOG_QUERY="customer order revenue region"
python inspect_glue_catalog.py
创建 inspect_glue_catalog.py：
import os
import re
import boto3
region = os.getenv("AWS_REGION", "us-east-1")
query = os.getenv("CATALOG_QUERY", "customer order revenue")
terms = {term.lower() for term in re.findall(r"[A-Za-z0-9_]+", query)}
glue = boto3.client("glue", region_name=region)
for database_page in glue.get_paginator("get_databases").paginate():
for database in database_page.get("DatabaseList", []):
database_name = database["Name"]
for table_page in glue.get_paginator("get_tables").paginate(
DatabaseName=database_name
):
for table in table_page.get("TableList", []):
columns = table.get("StorageDescriptor", {}).get("Columns", [])
searchable = " ".join(
[
database_name,
table.get("Name", ""),
table.get("Description", ""),
*[
f"{column.get('Name', '')} {column.get('Comment', '')}"
for column in columns
],
]
).lower()
score = sum(term in searchable for term in terms)
if score == 0:
continue
documented = sum(bool(column.get("Comment")) for column in columns)
print(
f"\n[{score}/{len(terms)} terms] "
f"{database_name}.{table['Name']} "
f"documented_columns={documented}/{len(columns)}"
)
print(f"Description: {table.get('Description', '(none)')}")
for column in columns[:20]:
comment = column.get("Comment") or "(no comment)"
print(f" - {column['Name']}: {column['Type']} | {comment}")
这个脚本不会理解复杂业务语义，也不会创建 Amazon Quick 对象，但它能暴露两个直接影响智能目录体验的问题：目录是否能检索到候选资产，以及字段是否拥有可继承的说明。对于 Databricks Unity Catalog，也可以采用相同思路，先盘点表注释、列注释、标签和所有权信息，再邀请数据管理员试用自然语言发现流程。
预览阶段的采用方式
适合的起点不是一次性接入全部数据域，而是挑选一个语义相对成熟、风险可控的主题，例如销售分析或供应链报表。准备一组真实问题，让数据管理员分别使用现有流程和智能目录流程完成资产发现与对象创建，然后比较候选资产准确率、人工修订量和完成时间。
上线前可以使用这份检查清单：
- Glue Data Catalog 或 Unity Catalog 中的核心表拥有明确描述。
- 关键字段包含业务定义、单位和时间口径。
- 已定义敏感数据的访问边界。
- 自动创建的 Dataset 和 Topic 必须经过人工审核。
- 记录错误继承、候选遗漏和术语歧义，作为目录治理的修复输入。
这项预览功能的核心意义不是让 AI 代替数据管理员，而是缩短从“我需要什么数据”到“我有一个可继续审核的分析对象”之间的距离。最终效果仍取决于目录元数据质量、权限设计，以及团队是否保留清晰的人工验收环节。