Formula 1用Agent AI将数据管道接入从8周缩至40分钟

公式 1®（F1）通过数字平台、F1 电视、社交媒体、票务和周边商品等渠道与全球 8 亿多粉丝互动，全年无间。比赛每两周举行一次。粉丝参与的窗口以分钟计，商业决策需要以"赛场速度"做出反应。在幕后，F1 的市场营销技术（MarTech）平台 Customer 360 捕捉所有这些接触点的互动，以驱动个性化、分段和商业战略。

然而，该平台面临重大的运营挑战。F1 IT 总监 Chris Roberts 表示："我们的 MarTech 平台是 F1 粉丝参与的神经系统。但每个新数据源都需要 6 到 8 周的手工工程。我们仅仅为集成 12 个新数据源就积压了 18 个月的工作。" 企业生成数据的速度超过了工程团队能够集成的速度。因此，F1 数据运营主管 Matt Kemp 着手改进效率和数据质量。"手动导入数据源既耗时，又造成解决方案的差异，最终导致数据完整性问题。我想要一个可重复、稳健和可靠的解决方案。AWS 从我们的需求出发，实现了一个端到端的 AI 智能体解决方案，在每个步骤都应用业务逻辑。"

2026 年初，F1 和 AWS 合作构建了 Data Accelerator，这是一个在 Amazon Bedrock AgentCore 上使用 AI 智能体的解决方案，将 F1 的 MarTech 数据平台从手动维护系统转变为自管理、可观测和统一的数据资产。在这篇文章中，我们展示了 Data Accelerator 如何将数据源上线从长达 8 周缩短到大约 40 分钟的代码生成加几小时的部署。它还识别并修复了生产中的数据源异常，在单个窗口中跟踪数据平台操作和智能体血缘，为分析师、工程师和科学家打开了协作的大门。Roberts 说："这是第一次，我们拥有了跨整个 MarTech 平台的端到端可见性，具有数据血缘和根本原因分析，而不仅仅是充满告警的仪表板。"

F1 的 Customer 360 平台从票务合作伙伴、流媒体集成、赞助商激活信息流、社交媒体和周边商品系统中摄取数据。运营这么广泛和高速的数据资产暴露了团队想要解决的三个摩擦点。首先，上线每个新数据源是一项繁重的手动工作：工程师编写模式映射、构建摄取管道、配置数据质量检查、定义通用数据保护条例（GDPR）分类，并手动设置治理策略。这个过程每个数据源需要 6 到 8 周。其次，平台必须跟上不断变化的上游信息流。供应商经常改变列名、添加字段或在没有通知的情况下重构和重新安排载荷。这些变化经常在最糟糕的时刻浮现，比如在比赛周末中途或在关键任务活动启动期间。第三，可见性是分散的。日志分散在各个服务中，没有统一的数据血缘。当利益相关者质疑一个指标时，工程师需要花费数小时手动追踪 Amazon Simple Storage Service（Amazon S3）路径、Amazon Redshift 控制表、Airflow 日志和 DBT 输出中的问题。

Data Accelerator 通过五个同时交付的工作流来解决这些挑战：

使用 Amazon Bedrock AgentCore 进行 AI 智能体数据源上线，在其运行时容器中托管智能体。

自动模式演变检测和修复。

通过 Amazon SageMaker Unified Studio 实现统一数据访问。

具有根本原因分析工具（RCA）和上下文图的端到端可观测性。

自动识别可观测仪表板中的故障，以及可以通过代码变更修复的 AI 智能体操作。

第六个工作流优化了客户身份解析算法，以在各个渠道统一粉丝接触点。以下部分详细描述每个工作流。

AI 智能体数据源上线

Data Accelerator 的核心是一组平台智能体，它们接收一个关于数据源信息有限的业务需求文档（BRD），并生成一个完全生产就绪的上线管道。这包括基础设施代码、数据转换、治理策略和 GDPR 分类，而不需要人类编写任何样板代码。智能体在两个阶段工作：

阶段 1：配置生成

当需要上线新数据源时，团队成员将 BRD 上传到 Amazon S3 存储桶。上传触发一个 AWS Lambda 函数，该函数调用 Amazon Bedrock AgentCore Runtime（Amazon Bedrock AgentCore 的一个功能）。智能体读取 BRD 并生成一组配置文件。然后它通过 GitHub App 访问 GitHub，将这些文件作为拉取请求推送到标准化的 Git 存储库，并通过其 REST API 访问 Jira 以创建引用该 PR 的工单。所有智能体对话和操作都通过内置的 AgentCore 可观测性在 Amazon CloudWatch 中追踪。分配的工程师审查、必要时调整并批准。

阶段 2：完整管道生成

一旦配置文件被批准，人工触发下一个阶段。智能体获取批准的配置并生成三个单独的拉取请求：

AWS Glue 应用程序和基础设施代码。

DBT 转换框架。

包括 GDPR 标记的治理策略。

所有三个 PR 都链接到单个 Jira 工单以用于追踪。工程师在基础设施、DBT 和治理存储库中逐个审查每个 PR 并批准。

自动 GDPR 分类

这与基本代码生成器的区别在于集成的 GDPR 分类。智能体主动分析每个数据列，确定它是否包含个人数据、敏感个人数据或伪匿名数据，并用适当的 GDPR 分类对其进行标记。这些标记直接发布到 SageMaker Unified Studio 中的治理注册表，使合规团队能够立即看到，而无需手动审查周期。

模块化技能架构

该系统不是紧密耦合的智能体图。单个智能体使用模块化技能定义进行操作，每个定义都封装了一项不同的功能：模式映射和数据类型推断、数据质量验证、治理执行和敏感数据分类。在运行时，智能体评估传入的需求并激活相关技能，通过多遍推理过程组合它们。Pass-0 负责通过清洗来管理令牌，Pass-1 汇总工具输出，Pass-2 汇总整体评估，逐步提高准确性和完整性，而不是依赖一次性响应。新功能作为新技能模块发布，无需更改核心智能体循环，保持架构的可维护性和可组合性，随着平台的增长。

结果是上线时间从 6 到 8 周下降到大约 40 分钟的代码生成加几小时的部署和审查。AI 智能体现在自主处理 95% 的工作。

自动模式演变

上线新数据源是一个挑战，但保持现有集成健康是另一个挑战。上游供应商经常修改他们的数据结构，从重命名列到创建新字段。以前，F1 团队在管道失败时发现这些变化，通常是在现场比赛周末。处理上线的同一智能体架构现在持续监视上游模式变化。当供应商修改其数据结构时，智能体通过使用 AWS Lambda 和 Amazon EventBridge 的事件驱动触发器检测它。它评估下游影响，识别哪些管道受到影响，以及哪些消费者依赖于更改的字段。然后它跨所有受影响的存储库生成必要的代码更新，并使用完整上下文和链接的 PR 创建 Jira 工单。工程师收到一条通知，解释什么改变了，描述影响，并提供建议的修复供审查。端到端解决现在需要几小时而不是几天。

通过 Amazon SageMaker Unified Studio 实现统一数据访问

在 Data Accelerator 之前，使用 Customer 360 数据需要在多个隔离的环境中切换。数据工程师在一个账户中维护管道。想要对粉丝行为进行建模的数据科学家需要访问一个单独的账户，分析师则在完全不同的环境中运作。团队之间没有共享工具或上下文，从提出问题到得到答案需要花费数天的协调，然后才能开始进行任何分析。

该解决方案以 Amazon SageMaker Unified Studio 为基础，构建了一个数据网格框架，由中央治理账户协调多个数据生产团队之间的数据发现与访问。其关键推动因素在于：治理被编码为声明式配置，而不是依赖手动控制台操作。单个数据源定义可以同时将数据发布到目录，并配置消费者订阅所需的访问控制。这意味着 AI 智能体能够以端到端方式安全地接入新的数据产品，覆盖从存储、目录到受治理访问的完整流程，因为该框架从设计上强制实施安全约束。无需人工审核 IAM 策略或 AWS Lake Formation 授权。该平台通过结构化设计保证正确性。正因如此，“统一入口”才成为可能。

数据工程师可以在一个地方整理和治理数据集，数据科学家也能在同一环境中找到这些数据集：它们已经过治理、拥有完善文档，并可直接用于建模。无论是构建粉丝细分模型，还是优化客户身份算法，数据科学家都不需要知道数据存储在哪里、由谁负责相关管道，或者应该使用哪个 S3 前缀。他们只需打开 Unified Studio，找到经过整理的 Customer 360 数据集，然后开始建模。他们可以使用共享笔记本、一致的工具以及受治理的数据访问能力，因为声明式治理在不牺牲控制力的前提下实现了安全的自助服务。数据整理与数据使用终于可以并存于同一环境之中。

通过 RCA 和上下文图实现端到端可观测性

数据平台是否值得信赖，取决于团队能否回答一个问题：此时此刻，数据是否正确？在 Data Accelerator 出现之前，要回答这个问题，就需要登录 Apache Airflow、检查 Amazon S3 路径、查询 Amazon Redshift 控制表并阅读 DBT 日志。Roberts 补充道：“没有人能够看到全貌。当利益相关者问‘为什么这个数字看起来不对？’时，我们的回答总是‘给我们几个小时’。可观测性仪表板彻底改变了这种情况。”

可观测性层将从 S3 Raw 摄取开始，经过 Processed 层，最终进入 Amazon Redshift DBT 阶段的完整数据血缘，以一张根据健康状态进行颜色编码的交互式图表呈现。用户可以单击任意节点，深入查看各个数据源和数据表；每个对象都会显示通过/失败状态、最近一次运行时间和持续时长。如果管道发生故障，血缘可视化会准确显示故障发生的位置，以及哪些下游数据受到影响。

根因分析（RCA）是 F1 平台中的一项 AI 智能体工具，它会读取系统日志，并识别整个数据资产中的故障点。单独使用时，RCA 可以告诉你什么发生了故障。我们通过传入以 JSON 编码的业务上下文和系统拓扑来增强 RCA 工具。S3 中缺少文件可能是表面错误，但借助上下文图，RCA 会告诉你，上游提供商调整了交付时间窗口，因此管道运行时该文件尚未到位。这就是知道什么发生了故障与理解为什么发生故障之间的区别。

F1 首次将完整的数据血缘、因果根因分析和业务上下文定义集中在一处，并且仪表板每 15 分钟自动刷新一次。

展示跨数据源和处理阶段管道健康状况的数据血缘可视化

包含故障详细信息的可观测性仪表板

客户身份解析

最后一个工作流对用于解析 F1 各个粉丝触点中客户身份的算法进行了优化。同一位粉丝可能会使用应用、在网站上购买门票、观看 F1 TV，并在社交媒体上互动。要在不发生错误合并或漏配的情况下，将这些互动统一到同一个身份之下，是 Fan Personalization Platform（FPP）实现有效个性化的基础。

F1 已经拥有一套可用的身份解析流程，但该流程速度较慢，并且难以随着各渠道粉丝互动量的增长而扩展。团队没有重新设计管道或替换组件，而是专注于优化现有解析算法的计算性能。通过分析执行瓶颈并调整匹配逻辑，本次合作将处理时间缩短了 50%，同时完整保留了整个解析管道及其下游集成。没有更改任何流程，也没有以准确性为代价：同一套算法如今在 F1 的生产规模下只需原来一半的时间即可运行完毕。

借助速度更快的身份解析，F1 能够接入任何新的数据源，并以原来一半的时间收集新的客户数据。更快的解析意味着更新鲜的统一用户画像，进而意味着可以在每个营销渠道中提供更及时、更相关的个性化体验。

Kemp 表示：“这一切的核心，就是在正确的时间向正确的粉丝传递正确的信息，无论是通过电子邮件、F1 应用、票务系统还是社交媒体。现在，我们能够在几小时内接入数据源，并更快地解析身份，因此我们终于可以在每个营销渠道中，真正提供粉丝所期待的个性化体验。”

设计内生的安全与治理

Data Accelerator 遵循“AI 提议、人工审核”的原则。AI 智能体运行在 Amazon Bedrock AgentCore 上，并具备长期记忆能力，能够在多次调用之间保留上下文。开发过程中使用 Kiro 进行结构化的规范驱动开发，并采用 Amazon Bedrock（Claude Sonnet 4.6）作为基础模型。事件驱动的基础架构使用 AWS Lambda 提供计算能力、Amazon EventBridge 进行路由、Amazon Managed Workflows for Apache Airflow（MWAA）编排工作流，并将 Amazon S3 用作原始数据层。所有 AI 模型访问均通过 F1 的 AI Gateway 进行治理，以实现统一的访问控制、成本管理和审计日志记录。但架构只是其中一半。真正让这套系统达到生产就绪水平的，是其安全体系。

该安全体系包括：

最小权限：采用细粒度权限；使用一小时后过期的短期令牌；仅允许访问特定代码仓库和资源。

完整审计跟踪：记录每项操作并标明归属，以满足合规要求。

人工审核：每个生成的 Pull Request 都必须经过工程师批准。

自动化测试：AI 智能体会为自己所做的更改生成全面的测试。

回滚能力：合并后发现的问题可以立即还原。

网络隔离：整个系统均运行在 Amazon Virtual Private Cloud（Amazon VPC）的私有子网内，无法直接访问互联网。

凭证加密：所有密钥均以静态加密形式存储在 AWS Systems Manager Parameter Store 中。

Roberts 表示：“让我们有信心把 AI 智能体引入生产数据管道的，是我们所谓的‘Human at the helm’。AI 智能体承担繁重工作，但决策由人来做。每项变更都要经过工程师已经在使用的同一套审核流程，因此团队很快就接受了它。”

Data Accelerator 为 F1 的 MarTech 运营带来了可衡量的成效：

数据源接入：从 6～8 周缩短至约 40 分钟的代码生成时间，外加数小时的部署和审核时间。

自主工作：AI 智能体无需人工干预即可处理 95% 的接入任务。

价值实现时间：缩短约 99%。

模式演进：端到端解决时间从数天缩短至数小时。

集成积压：持续 18 个月的积压任务在数周内得到清理。

过去将时间用于编写样板代码摄取代码和追踪模式中断问题的数据工程师，现在可以专注于推动业务发展的战略计划。

实施速度：一名开发人员在 4 个月内将 AI 智能体解决方案从概念验证推进到生产发布。

MarTech 平台的可靠性、一致性和数据完整性均得到提升，同时减少了运营开销。Kemp 表示：“Data Accelerator 不只是提升了速度，它还改变了我们的运营方式。数据工程师从编写样板代码摄取代码，转向专注于战略计划。我们甚至可以在最终用户察觉之前发现并修复问题。”

Data Accelerator 的成功归结为三项原则：在开发人员已经使用的工作环境中为他们提供支持、始终让他们掌握决策权，以及从第一天起便将 GDPR 分类等治理能力嵌入系统，而不是事后追加。这些原则塑造出了一套解决方案：F1 与 AWS 合作，利用 Amazon Bedrock AgentCore 上的 AI 智能体改造 MarTech 数据运营。通过结合数据源自动接入、模式演进检测，以及由 Amazon SageMaker Unified Studio 提供的统一数据访问能力，F1 将接入时间缩短了约 99%，并在数周内清除了持续 18 个月的集成积压任务。

这种方法在设计上具有可复制性。任何需要处理多源数据接入、模式频繁变化和治理要求的组织，都可以将同样的架构应用到自己的环境中。AI 智能体与具体领域无关，它们知道如何接入、分类和监控数据。业务领域本身可以替换。

要进一步了解本解决方案使用的 AWS 服务，请参阅：

Amazon Bedrock AgentCore。

Amazon SageMaker Unified Studio。

AWS Professional Services。

这个成果是多年来对 MarTech 平台增量改进的结晶，通过 F1 与 AWS 之间的紧密合作得以实现。来自两个组织的许多贡献者塑造了架构，加强了使数据加速器成为可能的基础。我们感谢以下思想领袖和开发人员的奉献和专业知识：Paula Marenco Aguilar、Nadeen Nilanka、Taye Aduewa、Marton Juhasz、Deepak Gulia、Alex Goff、Nick Morgan 和 Seshadri Senthamaraikannan。