从数据过载到可执行洞察：Verizon Connect 的智能体 AI 扩展

从数据过载到可执行洞察：Verizon Connect 如何将代理式 AI 扩展至 100,000 名用户

_特别感谢为该项目付出辛勤努力的 Verizon Connect 团队成员：Matteo Simoncini, Luca Bravi, Alberto Rossettini, Martin Villarruel, Ceyhun Unlu, Adriel Zuquini, Andrea Benericetti。_

如今，车队管理者面临着一项艰巨挑战：将数据过载转化为可执行的洞察。当你管理着数千辆车，每辆车每天产生数百个数据点时，仅靠人工分析几乎不可能识别出关键模式。Verizon Connect 是一家全球车队管理解决方案提供商，通过其 Reveal 平台为世界各地的企业提供服务，该公司在大规模业务中恰好遇到了这一挑战。

凭借超过 120 万个活跃车辆订阅，每天产生超过 5 亿个数据点，涵盖 80,000 种独立数据指标，车队管理者被淹没在这片数据之中，只能在零散的纸质日志和被动的电子表格中搜寻异常。如此庞大的数据量使得他们无法在新兴的安全问题、维护需求或运营低效演变成代价高昂的问题之前就将其识别出来。Verizon Connect 没有选择再构建一个静态仪表盘或基于规则的自动化系统（这类系统只能捕捉预定义的模式），而是选择代理式 AI（agentic AI），用一个集中化的智能解决方案取代人工的猜测式判断。代理式 AI 能够动态调查新模式、提出后续问题，并根据其发现调整分析方式，非常适合应对车队运营中不可预测的特性。

在本文中，我们将展示 Verizon Connect 如何构建并扩展一套代理式 AI 解决方案，将庞杂的车队数据转化为清晰、可执行的洞察，每天服务 100,000 名用户。我们将带你了解其中的架构决策、实施挑战以及可衡量的成果，为你的数据到洞察转型提供参考。

构建可扩展的架构

该解决方案在大规模处理数据的同时保持成本效率。下图描述了核心组件。在本节稍后部分，我们将逐一讲解并讨论解决方案的各个组件，并在「总体架构」一节中将它们串联起来。

__

图 1 – 高层级解决方案架构

各组件的高层级描述与逻辑流程如下。

1. 编排启动——每日触发器通过激活分析层中的异常检测模块来启动工作流。
2. 数据摄取——该模块从原始数据存储中拉取结构化信息。计算量最大的工作在这里完成。
3. 定向输出——该模块不是让大语言模型（LLM）去「大海捞针」，而是识别出特定异常，并将其写入专用的异常表。通过将数值分析卸载给专门的代码，我们避免了 LLM 处理原始表格数据时面临的规模与准确性问题。
4. AI 代理激活——在异常数据准备就绪后，管理器会触发 AI 代理。为提升性能，多个代理可以并行运行，每个代理专注于不同的客户或数据分段。
5. 推理与上下文——AI 代理编排最终分析。它从异常数据中查询「是什么」，并回溯原始数据了解「为什么」，利用 LLM 将这些输入综合成连贯的叙述。
6. 洞察交付——最终推理结果以生成洞察的形式存储，然后通过 Reveal 应用交付给终端用户。

解决方案的组件

异常检测

AI 工程中的一个常见陷阱是让 LLM 对大规模原始表格数据执行数值分析。正如 AWS Prescriptive Guidance 所指出的，LLM 在大规模处理复杂表格结构和数值提取时可能会力不从心。为解决这一问题，我们使用 AWS Step Functions 和 AWS Lambda 构建了一个无服务器统计模型（见图 4）。该模型负责对结构化数据执行计算密集型的异常检测工作。它识别出异常「是什么」，从而让 AI 代理专注于「为什么」发生以及「如何解决」。

AI 代理

我们选择了 Strands Agents——一个用于构建和执行 AI 代理的开源 SDK，并将其运行在无服务器的 AWS Lambda 环境中。这种部署模式可以根据需求横向扩展。AI 代理通过动态推理循环运作，自主决定必要的调查路径，而非遵循固定的步骤。从下面的描述你可以注意到，AI 代理是无状态的，生成洞察所需的上下文在分析时全新获取。

AI 代理使用特定工具来：

• 从 Amazon Simple Storage Service（Amazon S3） 检索预先计算的异常。
• 从 Amazon Aurora 查询原始数据的附加上下文，从 Amazon DynamoDB 查询历史洞察。
• 将最终洞察写回 Amazon S3。
• 在 Amazon DynamoDB 中跟踪任务请求状态。

两阶段代理式架构

洞察生成采用两阶段方法，每个阶段以不同方式利用 LLM 的推理能力：

阶段 1：摘要生成（异常聚合与优先级排序）。在第一阶段，代理接收一组在整个车队中检测到的原始异常。LLM 并非逐条处理每个异常，而是自主决定如何将它们聚合成连贯的洞察候选。它可以按以下维度对异常分组：

• 共同根因（例如多辆车表现出相同的行为模式）
• 时间相关性（事件集中在特定日期）
• 类别相似性（相关的安全或效率指标）

分组逻辑和筛选标准完全由 LLM 自行判断。系统不会对异常应如何组合施加固定规则。聚合之后，代理会基于严重程度、复现频率、车队整体影响和可执行性等因素，为每个候选洞察分配相关性评分。在这些已评分的候选中，代理选出相关性最高的前四条洞察进入详细生成阶段。通过这种方法，优先级排序能够适配每个用户车队的具体情境，而不是依赖可能遗漏新兴模式的静态业务规则。

阶段 2：详细生成（基于代理式工具的调查）。第二阶段是系统的代理式特性变得至关重要的环节。对于每条摘要洞察，系统会派生一个独立的代理实例，并为其提供数据检索工具。代理自主决定调用哪些工具、以什么顺序调用、调用多少次——不断迭代，直到收集到足够的证据来产出一条有数据支撑的洞察。既然已经解释了代理的执行方式，接下来让我们看看为什么代理式方法对这一用例至关重要。车队管理涉及无数变量和不可预测的场景，需要动态调查而非预定逻辑，这带来了两个根本性局限：

• 有限的模式覆盖：代码只能检测被显式编程的模式。边缘案例、新型关联或意外的数据分布会被忽略。
• 僵化的调查流程：脚本无论分析中途数据揭示出什么，都只遵循预定步骤。

相比之下，AI 代理可以发现任何性质的模式，包括开发过程中未曾预料的边缘案例。如果数据暗示出某种意外关联（例如急刹车事件与特定时段模式的关联，或某辆车在特定日期之后行为发生变化），代理可以实时调整其调查策略，发起额外的工具调用来探索这些新出现的假设。这种灵活性在车队管理中尤为宝贵，因为：

• 驾驶员行为的变化难以预测
• 外部因素（天气、交通、路况）会产生不明显的关联
• 车队构成和使用模式会随时间演变
• 可能出现历史数据中不存在的新异常类型

流程编排示例

• 初步发现：代理识别出一条摘要洞察，报告整个车队的急刹车事件增加了 30%。
• 建立基线：它自主决定拉取过去 30 天的车队历史平均值，以确认这一激增是真正的异常还是典型的季节性趋势。
• 模式识别：在发现激增集中在特定日期后，代理将关注点转向按日拆分。它发现大多数安全事件发生在同样的两天内。
• 定向下钻：基于这些日期，代理识别出编号 1015、1142 和 1032 的车辆占这些事件的近 70%。
• 对比分析：随后它发起最后一次定向请求，将 1015 号车辆的历史表现与其当前行为进行对比，以判断该驾驶员的画像是否发生了根本性变化。
• 综合：只有在「将这些点串联起来」之后，代理才终止循环，生成一条最终的、有数据支撑的洞察，突出所涉及的具体驾驶员和日期。

大语言模型

为优化性价比，我们首先使用高端的 Claude 4.5 Sonnet 来验证逻辑和洞察质量。验证完成后，我们在生产用例中转向了更具成本效益的 Claude 4.5 Haiku。进一步的性价比优化促使我们采用 Amazon Nova 2 Lite——一款极速多模态模型，它在提供可比洞察质量的同时，将输入 token 成本比 Claude 4.5 Haiku 降低了 70%。这一可观的节省至关重要，因为该工作负载以输入 token（远程信息处理数据、异常、上下文）为主。Nova 2 Lite 的高效率使 Verizon Connect 能够以更经济的方式向其全部用户群交付 AI 洞察。质量通过自动化测试套件和黄金标准数据集得到保障，确保完整发布时方案已经过实战检验。LLM 大规模托管在 Amazon Bedrock 上——这是一项完全托管的服务，具备全面的生成式 AI 能力，以及安全性、隐私性和负责任的 AI 特性。

每日触发管理与并发控制

为了在 100,000 名用户工作日开始时为他们准备好洞察，我们使用 Amazon Simple Queue Service（Amazon SQS） 来管理执行。通过控制 SQS 到 Lambda 触发器的最大并发数，我们可以：

• 平滑 API 需求峰值
• 保持在 Amazon Bedrock 配额之内：每分钟 token 数（TPM）和每分钟请求数（RPM）
• 在不过度配置资源的情况下提供可靠的交付

举例说明，考虑一个为全美客户交付洞察的场景。洞察的目标交付时间为美东时间早上 8:00，基于前一天太平洋时间午夜之前生成的数据。鉴于三小时的时区差，端到端流程必须在五小时窗口内完成。为异常检测预留一小时后，AI 代理和 LLM 生成洞察还有四小时窗口。以每分钟 1,500 次请求（可调整）的速率计算，洞察生成阶段大约需要 1.25 小时，完全满足我们的运营要求。

__

图 2 – SQS 到 Lambda 最大并发数详情

生成的洞察

代理生成的洞察可供 Reveal 应用直接消费。用户登录后，新洞察会出现在实时地图——Reveal 访问量最高的页面——上的专用面板中，让每位用户都能立即看到相关洞察。每条洞察都可点击，进入包含完整分析的详情页面。

图 3 – Reveal 访问量最高的页面包含指向运营洞察（Operational Insights）结果的链接。

总体架构

总体架构将以下四个组件整合在一起：异常检测、请求并行化、洞察生成引擎，以及供 Reveal 应用消费的生成洞察存储。

图 4 – 总体架构

要理解这些组件如何协同工作，请参考以下工作流：一次洞察请求被触发，其中包含需要计算洞察的客户 ID 列表。统计模型执行异常检测，并将结果存储在 Amazon S3 中。

1. 按前文所述触发 N 个并行请求。
2. N 个代理分析数据、创建洞察，并将其保存到 Amazon S3。在此阶段，代理调用 Amazon Bedrock API 以访问所选模型。
3. Reveal 应用可以访问存储在 Amazon S3 中的洞察。

成果：可执行的智能

运营洞察（Operational Insights）功能已于 2025 年 11 月向 Verizon Connect 用户推出，并以清晰、自然的语言叙述为车队管理者提供服务，示例如下：

• 安全模式检测：「您的车队本周急刹车增加了 100%。有趣的是，这与急加速的减少同时出现，可能表明驾驶员疲劳或交通拥堵加剧。」
• 运营效率：「#90000 号车辆在发动机运转时间中有 50% 处于怠速状态，显著高于您的车队平均水平。这意味着不必要的燃油成本。」
• 车队表现：「每日行驶里程下降了 59%，但超速事件增加了 54%。这表明车辆正在以更短的距离、更高的速度行驶——建议考虑路线优化。」

结论与展望

在本文中，我们展示了 Verizon Connect 如何在 AWS 上构建可扩展的代理式 AI 解决方案，将原始物联网（IoT）远程信息处理数据转化为可执行的车队洞察，服务超过 100,000 名用户。该架构结合了 Amazon Bedrock、Strands Agents、AWS Step Functions、Amazon SQS 和多层数据层，以大规模交付可靠、经济高效的洞察。

随着 AI 领域的演进，我们计划将基于 AWS Lambda 的代理部署迁移到 Amazon Bedrock AgentCore Runtime，以进一步精简 AWS Lambda 执行，并采用模型上下文协议（Model Context Protocol，MCP）实现更快的工具集成。

要有效实施代理式 AI 解决方案，应从小规模试点开始，验证基本用例并确立成本效率。在初步价值得到证明之后，通过集成自动化工作流和数据驱动的个性化来扩展系统。最后阶段是过渡到全面的企业级部署，支持整个组织范围内的高级编排和实时处理。现在就开始构建：

• 从基础入手：使用 Amazon Bedrock 获取托管 AI 服务，使用 AWS Lambda 进行无服务器代理托管
• 加入编排：使用 AWS Step Functions 进行工作流管理，使用 Amazon SQS 实现可扩展队列
• 存储与检索数据：使用 Amazon S3 进行对象存储，使用 Amazon Aurora 处理结构化数据，使用 Amazon DynamoDB 实现快速查询
• 探索代理框架：参阅 Strands Agents 文档了解开源代理开发

关于作者

（原文此处未提供作者姓名，署名信息以原文页面为准。） PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/from-data-overload-to-actionable-insights-how-verizon-connect-scaled-agentic-ai-to-100000-users