AWS ADOP平台：数据管道从数周压缩至小时级

数据工程团队通常需要花费数周时间才能完成一个新数据源的接入工作：编写 ETL、手写质量检查、更新语义模型、验证合规性。AWS 上的 Agentic Data Operations Platform (ADOP) 旨在大幅缩短这一时间周期。它是一个基于 Amazon Bedrock 和你选择的 AI 编码工具构建的参考架构。专业的 AI 智能体将整个 Bronze→Silver→Gold 生命周期自动化，并配有可配置的管控措施，以支持你的数据治理和监管合规工作。

对于数据工程负责人而言，三件事发生了变化。工程师不再将大部分时间花在数据管道的基础搭建上，而是开始交付数据产品。合规从下游关卡转变为接入时应用的内联控制。你的架构——而非模型——决定了每个 AI 编码工具（Claude Code、Kiro、Cursor、Codex）如何与你的数据系统交互。

本文面向工程副总裁、首席数据官和数据平台总监，文中后半部分为平台工程师提供实现细节。

图 1：ADOP 解决的六个数据工程挑战

开发环境中的智能体，生产环境中的制品

这是将 ADOP 与典型智能体平台方案区分开来的设计选择。

ADOP 是一个构建时加速器，而非运行时依赖。智能体运行在开发环境中，在那里进行推理、提案和生成：ETL 代码、质量检查、语义层定义、合规管控。工程师审查输出。持续集成和持续交付（CI/CD）将生成的制品（确定性 PySpark、SQL、Airflow DAG、IAM 和 Cedar 策略）晋升到预发和生产环境。在 ADOP 的默认模式中，生产环境运行确定性制品，不调用模型。需要模型推理的生产机构可以扩展此架构，使用 Amazon Bedrock 端点，但生成的管道代码本身保持静态且可审计。

图 2：ADOP 代币经济学和投资回报

ADOP 与通用编码助手有何不同：通用编码助手功能强大，但范围开放。将它们指向数据平台，每个工程师在不同日期会得到不同的架构。ADOP 是有意为之的固执己见。它用以下方式封装了同样的模型：

收窄的车道——数据工程技能和提示词，而非"你能输入的任何内容"。

内置公司哲学——你的标准存在于设计中，而非某人的记忆里。

没有大语言模型（LLM）在架构上自由发挥——模型填充蓝图，而非绘制蓝图。

策略和法规护栏——应用管控措施，在构建时而非仅在审查时支持你的合规工作。

整个企业共用一套接入流程——每个数据源都以相同方式落地，每次如此。

通用工具让开发者更快。ADOP 让每个开发者保持一致。

ADOP 与 Amazon Bedrock AgentCore 的关系：Amazon Bedrock AgentCore 是一个平台，用于以任何框架或模型大规模构建、连接和优化智能体。ADOP 在开发环境中运行智能体，并向生产环境交付确定性制品。两种都是有效的 AWS 对齐模式。ADOP 针对受监管数据工作负载的成本可预测性和审计姿态进行优化。

ADOP 适用于数据工程速度因手动接入和合规开销而受到限制的任何场景。常见模式包括：

规模化企业数据接入——用自然语言描述一个新数据源。智能体处理模式推断、ETL、质量检查和语义层更新。

医疗和金融服务中的受监管管道——可配置的管控措施，旨在帮助你应对所在行业的监管要求，通过专用治理提示词应用于每个数据集。客户负责确定自身的合规性。

为商业智能和机器学习（ML）特征自动填充和维护 AI 就绪的 Gold 层。

多工具 AI 开发治理——Claude Code、Kiro、Cursor 和 Codex 都基于相同的架构契约运作。

ADOP 是一个 AI 驱动的编码框架，在 AWS 和多云环境上构建端到端数据管道。它通过 Amazon Bedrock 在 Claude Code 上启动数据接入智能体，使用 Claude Code 的动态工作流功能为管道构建的每个阶段生成专用子智能体。

图 3：ADOP 架构概览，数据接入智能体通过 Amazon Bedrock 生成专用子智能体

图 4：从 Bronze 到 Silver 到 Gold 的 ADOP 数据湖层次，内置合规管控

子智能体——子智能体处理元数据生成、数据本体推断、数据质量检查、ETL 转换和编排（Airflow 或 AWS Step Functions）。需求通过与用户角色的对话交互迭代丰富，每个制品在部署到 AWS 之前在本地验证，并经过人工批准。

决策引擎（AI 克隆）——决策引擎作为你企业架构师的 AI 编码版本，将组织的指南、技术标准和设计理念直接嵌入构建过程。这有助于促进构建者之间的一致性，减轻团队在缺乏共享护栏的情况下使用通用编码工具时出现的碎片化问题。

护栏——子智能体受架构契约约束：工具路由规则、Cedar 授权策略、不变式和内联合规提示词。虽然参考实现面向 AWS，但该框架可通过 CLI 或模型上下文协议（MCP）接口扩展到其他服务，支持混合和多云环境。

数据合规——三种能力完善了架构。ADOP 帮助你应用合规相关管控：每个治理框架一个合规提示词可在接入时应用，因此法律审查的是提示词文件，而非应用程序代码。你仍负责验证管控措施是否满足你的监管义务。

智能体可观测性——每个智能体决策都通过 AgentTrace（意图、选择的工具、结果、成本）进行追踪，可发布到 Amazon CloudWatch 或 OpenTelemetry 接收器进行审计。整个堆栈默认在本地开发环境中运行。当规模需要时，可晋升到 AgentCore 运行时（Amazon Bedrock AgentCore 的一项功能），架构契约无需更改。

负责任 AI 和数据处理——智能体在开发过程中可能处理受监管或可识别个人身份的数据。客户应审查其数据处理实践，应用适当的访问控制，并在将制品晋升到生产环境之前验证智能体行为是否符合其组织的负责任 AI 策略。

两步快速上手

首先克隆代码库。

git clone https://github.com/aws-samples/sample-Agentic-Ai-Data-Operations.git

将数据集上传到 Amazon Simple Storage Service（Amazon S3）或本地存储，然后运行修改后的提示词。

注意：以下示例仅用于说明目的，使用了虚构数据、存储桶名称和字段引用。不代表任何真实的个人身份信息（PII）。本示例不构成监管合规指导或法律建议。

/onboard-workflow

Onboard attendance data from s3://amzn-s3-demo-source-bucket/demo_landing/attendance.csv into Silver with dedup on (employee_id, check_in) 
and not-null policy on employee_id and check_in,and into a flat denormalized Gold Iceberg table aggregated daily-per-employee with derived 
measures(hours_worked_clean, attendance_rate, late_arrival_flag, overtime_hours, absence_category).

Run daily at 03:00 UTC.

Apply data governance controls: hash/pseudonymize PII fields in Silver, suppress or mask sensitive fields in Gold, enforce retention policies, 
and log processing metadata. Apply guidelines (This example is illustrative only and does not constitute compliance guidance.)

Please profile the data first, then propose your recommended quality thresholds and transforms before generating any code.

图 5：在 Amazon Bedrock 上的 Claude Code 中运行 ADOP 接入工作流

ADOP：从概念验证到生产

最初的几周是架构密集期，因为编码你的标准（而非构建管道）是是一次性投入。契约存在后，每个新数据源只是一个提示词，而非一个项目。从方向上看，运行此模式的团队已经看到后续数据源的接入时间大幅压缩，随着技能追踪内存的积累，曲线进一步趋平。

图 6：从基础到生产的分阶段 ADOP 采用时间线

面向智能体驱动的数据工程转型

向智能体驱动的数据工程转型需要深思熟虑的组织变革。以下计划有助于工程团队平滑采用 ADOP，同时保持问责制和质量标准。

干系人沟通 — 识别三个沟通层级：执行发起人（CDO、工程VP）每月接收进度仪表板；平台和数据工程负责人获取每周冲刺总结；个人贡献者通过团队频道接收实时更新。传递信息的框架应围绕 ADOP 保留了什么（工程判断力、架构标准），而非它实现了什么自动化。在首次赋能培训前，发布一页 FAQ，回答关于智能体生成代码质量和岗位影响等常见问题。

培训计划 — 第1周：AWS 主导的 ADOP 研讨会，涵盖架构契约配置、决策引擎配置和平台最佳实践。第2周：实操提示词编写实验。每个团队在 AWS 指导下从头到尾接入一个低风险数据源。第3周：制品审查和护栏配置会议。工程师对照自己的代码验证智能体输出。第4-6周：每周两次办公时间用于故障排除。从第7周起改为每周一次。为所有会议录制录像，用于未来团队成员的异步入职培训。

分阶段推广策略 — 阶段1（第1-3周）：与两到三名工程 champion 试点，接入一个非关键数据源。Champion 验证输出质量，并提供反馈以优化架构契约。阶段2（第4-6周）：扩展到整个平台团队。接入3-5个复杂度递增的额外数据源。阶段3（第7-12周）：全组织推广。新数据源通过 ADOP 完成接入。现有管道在计划的维护窗口期间进行机会性迁移。

成功指标 — 追踪四个关键指标：(1) 数据源接入周期时间，目标是到阶段3实现显著缩减。(2) 首次制品接受率，根据组织质量标准设定目标。(3) 工程满意度评分，通过第3、6、12周的匿名脉冲调查。(4) 护栏合规率，衡量生成的管道在无需人工干预的情况下通过自动化策略检查的一致性。

升级路径 — 第1级：工程 champion 在其 squad 内部解决提示词编写问题和小型制品调整。第2级：平台团队在一个冲刺周期内解决架构契约缺口、护栏配置错误或反复出现的制品拒绝。第3级：工程VP或CDO介入处理跨团队推广障碍、资源冲突或无法在平台层面解决的策略争议。在共享日志中记录所有升级事件，以识别系统性问题，并将改进反馈到架构契约中。

安全与数据隐私

智能体驱动开发的一个常见问题是构建过程如何处理密钥、凭证和敏感数据。ADOP 通过以下设计选择来解决这一问题。

密钥管理 — 密钥不进入智能体上下文。数据库凭证、API 密钥和服务令牌在部署时通过 AWS Secrets Manager 或你现有的 vault 解决方案解析。智能体引用密钥 ARN 或占位变量。在管道生成过程中，智能体不会看到或处理实际的凭证值。

数据隔离 — 敏感数据留在原地。智能体使用 schema 元数据、行数示例和列统计信息，而非原始生产数据。当数据质量规则生成需要数据剖析时，它在隔离的沙箱中对有限子集运行，并将结果汇总后再返回智能体上下文。

数据隐私 — 模型交互是临时的。通过 Amazon Bedrock 与 Claude 的对话不会保留用于模型训练（参见 Amazon Bedrock Data Privacy and Security FAQ）。提示词和响应仅在会话期间存在，推理保持在你的 AWS 账户边界内。

网络隔离 — 网络边界得到尊重。本地优先的开发模式意味着智能体在开发者机器上或在你的虚拟私有云（VPC）内运行。除非你明确配置外部集成，否则不会有数据离开你的网络。当升级到 AgentCore 运行时时，相同的网络隔离策略在服务级别适用。

负责任的 AI 注意事项

ADOP 智能体基于 schema 元数据和自然语言提示生成管道代码、数据质量规则和合规控制。由于这些输出是 AI 生成的，因此适用以下实践：

强制人工审查 — 生成的制品，特别是合规和监管控制，必须由合格的工程师在推广到生产环境前进行审查。智能体输出是草稿，不是经过认证的实现。

幻觉风险 — LLM 可能产生看似合理但错误的逻辑。生成的掩码规则、保留策略或访问控制可能不完整或存在细微错误。在法律或合规团队验证之前，将每个生成的控件视为未验证状态。

法律与合规验证 — AI 生成的监管控件不构成法律建议或经认证的合规实现。你的法律、隐私和合规团队必须在部署前验证生成的制品满足你特定的监管义务。

信任范围 — 智能体基于 schema 元数据和配置提示工作，而非法律解释。它们无法评估监管适用性、司法管辖区细微差别或组织风险承受能力。

使用 Amazon Bedrock Guardrails 实现生产级 AI 控制

ADOP 将 Amazon Bedrock Guardrails 视为架构中强制性的生产控制，而非可选附加组件。三种能力适用于 API 层的 ADOP 智能体：

内容过滤 — Amazon Bedrock Guardrails 在每次智能体交互中强制执行主题和内容边界，阻止数据工程范围之外的输出。按智能体角色配置过滤器，并在响应到达制品生成阶段之前执行。

接地验证 — 上下文接地检查验证智能体输出是否锚定于 schema 元数据和架构契约。未通过接地阈值的响应将被拒绝，有助于防止幻觉逻辑进入生成的管道。

敏感信息过滤器 — PII 检测和基于正则表达式的过滤器有助于防止凭证或受监管数据出现在智能体响应或生成代码中，与安全部分的密钥管理控制形成互补。

这些控制与每次智能体调用内联运行，在 LLM 和制品输出之间形成验证层。它们在架构契约中配置一次，然后在所有子智能体间统一执行。

---

ADOP 将你的企业架构标准编码一次，然后让智能体在每个新数据源上始终如一地应用它们。结果：更快的接入、统一标准的管道，以及从一开始就被应用的合规控制。无论你是在本地 IDE 中运行智能体，还是扩展到 Amazon Bedrock AgentCore，架构契约都保持一致。

在 GitHub 上开始使用 ADOP

了解更多关于 Amazon Bedrock 的信息

阅读 Amazon Bedrock 文档

AWS Show and tell 视频播客

It's Safe to Close Your Laptop Now – Hosting Coding Agents on Amazon Bedrock AgentCore。当你的 ADOP 智能体超出本地开发时，本指南涵盖了将它们提升到 AgentCore 上的托管托管，实现持久化和可扩展执行。

Spark on AWS Lambda – An Apache Spark Runtime for AWS Lambda。如果你的 ADOP 生成的管道需要编译 PySpark 代码，SoAL（Spark on AWS Lambda）架构可以通过无服务器方式执行 Spark 作业而无需完整集群开销，显著减少 token 数量。