新增一个数据源，真正耗时的往往不是把文件放进对象存储，而是完成格式识别、质量检查、敏感字段处理、业务建模、血缘登记和上线验证。Agentic Data Operations Platform（ADOP）提供了一种参考架构：让多个职责明确的 AI Agent 协同完成 Bronze、Silver、Gold 数据流水线，同时把治理和合规控制放在流程内部。
它的价值不在于“让一个大模型写完整条 ETL”，而在于把数据工程拆成可编排、可审计、可回退的操作单元。这样，新数据源的接入可以从依赖大量人工沟通的周级项目，转变为小时级的受控流程。
ADOP 解决的不是单个 ETL 问题
传统数据接入通常包含一串相互依赖的步骤：
- 发现并读取新数据源。
- 推断字段类型、主键和数据分布。
- 将原始数据写入 Bronze 层。
- 执行去重、标准化、类型转换和异常处理，生成 Silver 层。
- 根据业务语义生成 Gold 层数据集。
- 运行质量规则并验证结果。
- 注册元数据、数据血缘和访问策略。
- 通过审批后发布到生产环境。
其中有些步骤适合由 Agent 负责，例如分析数据样本、生成转换建议、解释质量异常和补充元数据；另一些步骤必须由确定性系统执行，例如权限校验、策略评估、数据写入和生产发布。
因此，一个可用的 ADOP 应该把 Agent 放在“理解、规划和建议”的位置，把实际执行交给经过授权的工具和服务。Agent 不应直接获得整个数据平台的无限权限。
Bronze、Silver、Gold 的 Agent 分工
可以把平台拆成几个专用 Agent。每个 Agent 都有明确输入、输出和工具边界。
- Source Profiling Agent：读取受控样本，识别格式、字段类型、空值比例、候选主键和潜在敏感字段。
- Ingestion Agent：根据批准的配置启动数据摄取任务，并将不可变原始数据写入 Bronze 层。
- Transformation Agent：生成或解释 Silver 层转换计划，例如日期标准化、重复记录处理和字段重命名。
- Data Quality Agent：设计并执行质量规则，报告失败原因和影响范围。
- Modeling Agent：根据业务语义提出 Gold 层事实表、维度表或服务数据集的结构。
- Governance Agent：补充分类、血缘、保留期限和访问建议，但不能绕过组织策略。
- Orchestrator Agent：跟踪任务状态，决定下一步调用哪个 Agent，并在风险较高时转人工审批。
这些 Agent 可以通过 Amazon Bedrock 调用基础模型，再通过受控工具访问对象存储、数据目录、编排服务、质量检查服务和审批系统。关键设计是：模型输出应该是结构化计划，而不是可以直接执行的任意文本。
例如，Transformation Agent 可以输出这样的计划：
{
"source": "s3://incoming/orders/2025-01-01.csv",
"target": "silver.orders",
"steps": [
{"operation": "trim", "column": "customer_id"},
{"operation": "cast", "column": "order_total", "type": "decimal(18,2)"},
{"operation": "parse_date", "column": "created_at", "format": "ISO-8601"},
{"operation": "deduplicate", "keys": ["order_id"], "keep": "latest"}
],
"requires_approval": false
}
执行器只接受预先定义的 operation，并对字段、目标表和权限进行额外校验。这样可以避免模型生成一段未经审查的 SQL 或脚本后直接接触生产数据。
把治理控制放进执行路径
数据治理不能只依赖 Agent 的提示词。提示词可以帮助模型理解规则，但不能替代强制执行的策略系统。
一个较稳妥的控制链路如下：
数据源
-> 样本分析
-> 敏感字段识别
-> 策略检查
-> Bronze 写入
-> Silver 转换
-> 质量门禁
-> Gold 建模
-> 人工审批或自动发布
在每个阶段，平台都应记录以下信息：
- 使用了哪个 Agent、模型和提示词版本。
- Agent 请求了哪些工具，以及工具返回了什么结果。
- 哪些字段被标记为敏感数据。
- 哪些规则通过、失败或被豁免。
- 哪个用户或服务账号批准了发布。
- 最终数据集由哪些源数据和转换步骤产生。
对于个人信息、支付信息或受监管数据，建议默认采用“发现即阻断”的策略：一旦检测到高风险字段，流程可以继续完成分析，但在脱敏策略和审批完成前，不允许进入下游共享层。
一个可改造的流水线配置
下面的 YAML 是一个最小化的 ADOP 流程配置示例。它不是某个 AWS 服务的固定格式，而是可以映射到自有编排器、Step Functions 或其他工作流系统的配置模型。运行前需要将存储位置、目录名称和策略标识替换为实际环境中的值。
pipeline:
name: orders-onboarding
source:
uri: s3://example-incoming/orders/
format: csv
sample_rows: 1000
agents:
profiler:
model: amazon.nova-lite
tools:
- read_sample
- infer_schema
- detect_sensitive_fields
transformer:
model: amazon.nova-lite
tools:
- propose_transform_plan
quality:
model: amazon.nova-lite
tools:
- run_quality_rules
- explain_failures
layers:
bronze:
uri: s3://example-lake/bronze/orders/
immutable: true
silver:
table: silver.orders
rules:
- order_id_not_null
- order_total_is_decimal
- created_at_is_valid
- order_id_is_unique
gold:
table: gold.daily_order_summary
governance:
catalog: example-data-catalog
classification_policy: pii-block-until-approved
retention_days: 365
require_human_approval_if:
- sensitive_fields_detected
- quality_score_below: 0.98
- schema_breaking_change: true
一个简单的启动命令可以把这份配置交给平台的编排入口：
aws bedrock-agentcore-runtime invoke \
--runtime-identifier adop-orchestrator \
--payload fileb://orders-onboarding.yaml \
--region us-east-1
具体命令取决于实际采用的 Agent 运行时和部署方式。这个示例的重点是接口边界：编排器接收声明式流程，Agent 生成结构化计划，执行器负责校验和调用数据服务，审批系统负责高风险分支。
如何判断 Agent 是否真的节省了时间
“从数周到数小时”不应只用模型响应速度来衡量。更有意义的指标包括：
- 从提交数据源到生成首个可查询 Bronze 表的时间。
- 从源字段变更到检测并通知的时间。
- 自动生成的转换计划一次通过率。
- 数据质量规则的覆盖率和误报率。
- 需要人工介入的流程比例。
- 高风险数据被阻断或正确升级审批的比例。
- 每个新数据源的运行成本和失败重试次数。
还需要保留人工抽样验证。Agent 可能会正确识别字段类型，却错误理解业务含义；也可能为同一个指标提出多个看似合理但不兼容的定义。Gold 层尤其需要业务负责人确认，因为它承载的是面向分析和决策的语义，而不只是清洗后的数据。
落地时的边界与建议
ADOP 更适合作为受控的自动化层，而不是取代数据平台基础设施。对象存储、目录、权限、质量引擎、审计系统和编排服务仍然需要稳定运行，Agent 负责连接这些能力并减少人工设计工作。
建议采用以下落地顺序：
- 先选择格式稳定、风险较低的批量数据源，验证 Bronze 和 Silver 流程。
- 为 Agent 工具建立严格的输入 schema、权限范围和超时策略。
- 让模型输出计划和解释，执行器只运行白名单操作。
- 为敏感字段、质量失败和结构破坏定义强制审批门禁。
- 对每次运行保存模型版本、提示词版本、工具调用和最终数据版本。
- 在接入更多数据源前，用真实历史任务评估节省的时间、成本和错误率。
ADOP 的核心不是把所有数据工程决策交给 AI，而是把重复的分析、计划和文档工作自动化，同时保留确定性校验、权限控制和人工责任边界。对于需要持续接入多种数据源的团队，这种架构能够让数据工程师把时间从手工编写和维护接入流程，转移到规则设计、数据产品建模和异常处理上。