AWS 发布 ADOP 代理化数据运营参考架构

AWS 在其机器学习博客中正式介绍了 Agentic Data Operations Platform（ADOP），这是一套构建在 Amazon Bedrock 之上的参考架构，目标是把企业数据工程团队从数周的新数据源接入工作中解放出来。ADOP 通过专门的 AI 代理自动完成从 Bronze（原始层）到 Silver（清洗层）再到 Gold（聚合层）的全链路数据加工，并内置可配置的治理与合规控制。

面向数据工程负责人的三个转变

ADOP 的设计意图体现在三处关键变化：其一，工程师不再把大部分时间耗费在管道搭建上，而是真正交付数据产品；其二，合规检查从上线后的下游卡口前移至接入环节的实时控制；其三，统一架构而非模型本身，决定了 Claude Code、Kiro、Cursor、Codex 等不同 AI 编程工具如何与数据系统交互。

开发环节用代理，生产环节用产物

ADOP 与一般「代理化平台」的最大区别在于：它是构建期加速器，而非运行时依赖。AI 代理运行在开发环境中，负责推理、提议并生成 ETL 代码、质量校验、语义层定义和合规控制；工程师对产出进行评审后，CI/CD 流水线将确定性产物（PySpark、SQL、Airflow DAG、IAM 与 Cedar 策略等）部署到预发与生产环境。在默认模式下，生产环境不再调用模型；若业务确实需要运行时模型推理，可通过 Amazon Bedrock 端点扩展，但生成的管道代码本身保持静态、可审计。

相比通用编程助手，ADOP 的定位更「固执」：

• 限定在数据工程技能与提示词范围内，不做开放式生成。
• 将企业架构标准固化在设计中，而非依赖个人记忆。
• 模型只负责填充蓝图，不负责绘制蓝图。
• 在构建期就嵌入策略与合规护栏，而非仅在评审阶段兜底。
• 全企业共享同一接入流程，新数据源的处理方式始终一致。

典型适用场景

ADOP 适用于被人工接入与合规流程拖慢的数据工程场景，常见模式包括：

• 大规模数据源接入：用自然语言描述新源，代理自动完成 schema 推断、ETL、质量校验与语义层更新。
• 医疗、金融等受监管行业的管道：针对每个数据集配置专用治理提示词，内置合规控制（最终合规判定由客户负责）。
• 为 BI 与机器学习特征自动构建并维护的 AI-ready Gold 层。
• 多工具 AI 开发治理：Claude Code、Kiro、Cursor、Codex 共享同一架构契约。

架构组成

ADOP 是一个基于 AI 的编程框架，可在 AWS 及多云环境下构建端到端数据管道。它通过 Amazon Bedrock 启动基于 Claude Code 的 Data Onboarding Agent，并借助 Claude Code 的 Dynamic Workflow 能力为管道构建的每个阶段派生出专门子代理。

架构主要包含以下模块：

• 子代理：负责元数据生成、数据本体推断、质量校验、ETL 转换与编排（Airflow 或 AWS Step Functions）。需求通过与用户角色的对话式交互迭代丰富，每个产物在部署到 AWS 前都经过本地验证与人机协同审批。
• 决策引擎（AI 克隆）：作为企业架构师的 AI 编码版本，将组织的技术标准与设计哲学直接嵌入构建过程，抑制因各团队使用通用工具带来的架构碎片化。
• 护栏：子代理受架构契约约束，包括工具路由规则、Cedar 授权策略、不变量以及合规提示词。参考实现面向 AWS，但也通过 CLI 或 Model Context Protocol（MCP）接口扩展到其他服务，支持混合云与多云。
• 数据合规：架构内置三类合规相关能力，可在数据接入全过程中应用相应控制。

与 Bedrock AgentCore 的关系

Amazon Bedrock AgentCore 提供了跨任意框架或模型大规模构建、连接并优化代理的平台能力。ADOP 与之并行：ADOP 在开发期运行代理、将确定性产物交付到生产；而 AgentCore 更偏向大规模代理运行时的构建与连接。两者均为 AWS 对齐的合法架构模式，ADOP 在受监管数据负载上更关注成本可预测性与审计友好性。