人工智能

U Mobile 如何借助 Amazon Bedrock AgentCore 构建智能体电信运营

U Mobile 是马来西亚最新的 5G 网络提供商，一直以精简的方式运营电信业务，通过持续自动化以更少资源做更多事情。当新的 AI 能力出现时，U Mobile 探索了如何在基本生产力提升之外进一步增强运营效率。真正的机会在更上游，即运营团队最初如何诊断和解决问题。同样的精简运营原则塑造了 AiDaH 的基础：它不是一次性的技术举措，而是长期简化运营、在不增加复杂性的前提下扩展能力之旅的下一步。

当用户无法购买数据附加包时，解决这个问题并不是单一问题，而是一个协调问题。客服人员需要提取接口日志以获取错误代码。同一客服人员随后必须查询业务支撑系统 API 以确认用户资格，并交叉参考内部知识库以了解适用的业务政策。所有这些都发生在多个系统之间，之后才能起草回复的第一个字。而当这一过程失败时，工单会升级到后端 IT 团队，用户等待的时间就更长。

传统自动化工具可以帮助客服人员写出更好的回复。它们做不到的是在多个系统之间导航、分析结果并提出纠正措施。弥合这一差距需要基于 Amazon Bedrock AgentCore 构建的智能体架构。

U Mobile 的信息系统部（ISD）正是这样做的。他们与 AWS 及 AWS 合作伙伴 Axrail 合作，在 Amazon Bedrock AgentCore 上创建了 AiDaH，即 AI 驱动的智能体服务台。Amazon Bedrock AgentCore 是一个可在任意框架或模型下大规模构建、连接和优化智能体的平台。两项能力决定了这一选择。托管智能体运行时意味着无需运维智能体基础设施。内置记忆可在多轮对话中携带对话上下文，而无需搭建单独的状态存储。在启动这一旅程的一年内，AiDaH 已处理六大业务部门中 150 多个有记录的运营场景。U Mobile 的内部测量显示，关键类别的故障工单量最多下降了 84.5%。

在本文中，我们将介绍 AiDaH 背后的六层架构。然后描述平台之下的安全基础，最后简要说明团队构建该平台所采用的规范驱动方法。

问题：系统太多，摩擦太大

U Mobile 的 IT 环境体现了现代电信典型的复杂性：业务支撑与客户关系管理系统、移动号码可携平台、大数据分析以及基础设施监控工具，以混合方式运行在本地和云上。

在 AiDaH 之前，这种碎片化意味着即使是常规诊断也需要跨不同系统和门户手动检查日志、查询用户资格并查阅知识库以了解业务政策。每次查询都是一次上下文切换，每次上下文切换都是时间损失，而每个未解决的查询都会升级到后端 IT 团队。将覆盖范围扩展到更多运营领域会加剧问题，因为每个新系统通常都需要定制集成。

ISD 团队的战略建立在三大支柱之上。

  1. 覆盖：智能体实时协调后端系统。
  2. 深度：用于多步根因分析的思维链推理。
  3. 社区：一个具有基于角色的访问控制和内置护栏的安全多租户框架，可供每个部门使用。

历程：从知识库到智能体平台

AiDaH 始于一个原则：大处着眼，小处着手。U Mobile 于 2025 年底开始概念验证，使用两个试点智能体和 Amazon Bedrock Knowledge Bases（一项完全托管的检索增强生成（RAG）能力）。2026 年第一季度的试点让内部 IT 服务台上线，包含 4 个智能体和 20 个运营场景。整个 2026 年，平台不断加固和扩展，增加了三层路由，到年中达到 6 个智能体。AiDaH 于 2026 年第三季度面向 50 名 L2 呼叫中心和门店用户上线，包含 8 个智能体，目前覆盖 150 多个有记录的运营场景。

智能体在实践中意味着什么

传统 AI 辅助与智能体 AI 之间的区别最好通过一个真实例子来说明。

使用传统 AI 助手时，处理“海外移动数据无法使用”的客服人员可以获得起草回复的帮助和一些建议的故障排除步骤，但仍需手动检查漫游状态、验证资格、创建工单并发送最终回复。

使用 AiDaH 时，系统会独立检查用户的漫游配置、验证国际数据资格并确定具体故障点。然后它会制定修复计划：重置哪些服务、推送什么配置以及是否需要网络工单。客服人员审核并确认，随后执行操作。过去消耗客服人员时间的调查现在在他们读到第一行之前就已完成。人类决策点保留在关键之处：在实时用户账户上发生变更的那一刻。

在一个生产案例中，一名用户报告无法购买附加包。AiDaH 将故障追溯到一个错误代码：“用户有待处理订单”。它还发现该客户在三天内通过多个渠道尝试了同一购买 30 多次，每次尝试都被同一个底层待处理订单阻止。AiDaH 在单次响应中呈现了根因和修复步骤。此前这需要跨多个系统手动调查。

架构：六层，一个界面

AiDaH 运行在基于 Amazon Bedrock AgentCore 构建的分层架构上，部署于亚太地区（新加坡）区域。员工通过 Microsoft Teams 进行交互，这是有意为之的选择，以便在大多数用户已经工作的地方触达他们，无需学习新应用，也无需切换门户。

下图展示了各层如何组合在一起。

AiDaH’s six-layer architecture, from the Microsoft Teams interface down to on-premises operational systems

图 1：AiDaH 的分层架构

如图 1 所示，该平台分为六层。

第 1 层：员工界面

员工通过 Microsoft Teams 以及由 Amazon CloudFront 提供、受 AWS WAF 保护的 Web 门户访问 AiDaH，后端为 AWS Lambda，并提供 REST API 用于程序化触发。

第 2 层：编排

路由大脑位于 Amazon Bedrock AgentCore 上。每个请求都要经过预检安全检查，涵盖基于角色的访问控制、身份验证和护栏，然后进入成本优化的路由层。大约 70% 的请求通过确定性关键词匹配解决，无需调用模型；20% 由轻量级模型分类；只有 10% 需要完整的编排器。能够有把握处理请求的最便宜路径就是实际执行的路径。

第 3 层：专业智能体

八位专家分别覆盖客户关系管理、客户问题管理、号码可携、订单与 SIM 卡运营、基础设施监控、大数据分析、云成本管理和财务运营。它们通过 Agent2Agent（A2A）协议通信，从而可以委派子任务并完成任何单个智能体都无法独立处理的跨系统工作流。

第 4 层：网关和后端 API

AgentCore Gateway 是 Amazon Bedrock AgentCore 的一项能力，它通过统一的模型上下文协议（MCP）接口将 U Mobile 的后端暴露给智能体。每个网关背后是 AWS Lambda 函数和 MCP 服务器，它们将智能体意图转换为针对特定系统的调用。

第 5 层：数据和知识

Amazon Bedrock Knowledge Bases 是一项完全托管的 RAG 能力，它使用 Amazon OpenSearch Serverless 向量存储，将智能体响应建立在受治理的内容之上。内容涵盖共享的企业知识库和独立的财务语料库。AgentCore memory 是 Amazon Bedrock AgentCore 的一项能力，用于在多轮对话中保持对话上下文；Amazon DynamoDB 则保存六层基于角色的访问控制模型和会话元数据。

第 6 层：运营系统

U Mobile 的本地和云运营系统通过 AWS Transit Gateway 和 AWS Site-to-Site VPN 访问，后者是一条 IPsec 加密隧道，不暴露于公共互联网。

请求如何流经各层

追踪单个请求可以让各层之间的交互变得具体。设想一位支持人员正在 Microsoft Teams 的 AiDaH 频道中输入一个关于携入状态的问题。

  1. 界面： Teams 消息到达一个 AWS Lambda 函数，该函数将请求和调用者的联合身份转发给编排器。
  2. 预检： 编排器根据保存在 Amazon DynamoDB 中的六层基于角色的访问控制模型解析调用者，验证由 AgentCore Identity（Amazon Bedrock AgentCore 的一项能力）签发的令牌，并对传入提示应用 Amazon Bedrock Guardrails。任何一项检查未通过的请求都会在此停止。
  3. 路由： 编排器选择能够处理请求的最便宜层级。像“携入状态”这样的可识别短语会确定性匹配，并完全跳过模型调用。含糊的表述会交给轻量级分类器。新颖或多部分的问题则交给完整编排器。
  4. 智能体实例化： 选定的专业智能体作为会话在 AgentCore runtime（Amazon Bedrock AgentCore 的一项能力）中运行。AgentCore memory 会重新水合对话，使智能体继承用户号码以及此前轮次中的任何发现，而不是要求用户重复提供。
  5. 工具发现和调用： 智能体向 AgentCore Gateway 查询其有权使用的工具。每个网关将其后端发布为具有类型化输入和输出的 MCP 工具，因此智能体按名称和模式选择工具，而不是依赖手工编码的集成逻辑。Amazon Cognito 为该调用代理 OAuth 授权。
  6. 后端调用： 网关的 Lambda 函数或 MCP 服务器将工具调用转换为针对目标系统的请求，经由 AWS Transit Gateway 和 Site-to-Site VPN 隧道到达本地号码可携平台。敏感字段在返回途中、响应到达模型之前会被掩码处理。
  7. 推理与协作： 如果答案跨越多个领域，智能体会通过 Agent2Agent 协议进行委派。例如，一个携入查询如果最终发现是计费阻塞，就会移交给业务支持系统智能体，结果会合并为一段叙述。
  8. 响应与审计： 智能体基于 Amazon Bedrock Knowledge Bases 为其解释提供依据，然后将发现和建议的补救措施返回给 Teams 供人工确认。AgentCore Observability 是 Amazon Bedrock AgentCore 的一项能力，它将提示、工具调用、令牌计数和延迟的完整追踪写入 Amazon CloudWatch，AWS CloudTrail 则记录相应的 API 活动。

接入新的运营领域只需在第 5 步添加一个网关及其 MCP 工具定义。第 1–4 步以及第 7 步和第 8 步保持不变。稳定的核心正是让每个新领域的边际成本保持低廉的原因。

生产环境中的 Amazon Bedrock AgentCore 能力

下表将每项 AgentCore 能力映射到它在 AiDaH 中承担的职责。

能力 在 AiDaH 中的角色
Runtime 将 AiDaH 及其子智能体作为自动扩缩的托管容器进行托管，无需预置服务器
Memory 跨轮次维护对话上下文，例如用户号码、订单 ID 和先前的发现
Identity 签发短期访问令牌，使只有授权用户才能调用智能体
Gateway 通过统一、安全的 MCP 接口将智能体连接到 U Mobile 后端
Observability 将每个提示、工具调用、令牌计数和延迟测量数据流式传输到 Amazon CloudWatch

夯实安全基础

部署一个能够访问用户数据、计费系统和网络基础设施的智能体 AI 平台，需要的不仅仅是应用层安全。它需要一个安全的云基础。U Mobile 采取了双管齐下的方法：验证并增强底层 AWS Landing Zone，并基于 Amazon Bedrock AgentCore 中的安全能力进行构建。

Landing Zone 安全 – 在将 AiDaH 扩展到生产环境之前，U Mobile 邀请 AWS 对承载该平台的 Landing Zone 进行 Well-Architected 安全审查。该审查依据 AWS 安全最佳实践对环境进行了验证。基础设施保护首先通过 AWS Control Tower 护栏和 AWS Organizations 服务控制策略实现。随后，审查检查了集中式身份联合以及入站和出站网络安全控制。AWS Security Hub 中汇总的安全发现以及每个架构层级的加密标准完成了评估。结果有两方面：一是确信每个 AiDaH 组件都运行在经独立验证的基础上，二是获得了一份持续改进的优先路线图。

应用层安全 – 每个智能体操作都可追溯到特定的已认证用户。员工通过 Microsoft Entra ID 进行联合身份认证，AgentCore Identity 签发用于授权智能体调用的短期令牌。Amazon Cognito 在网关处代理 OAuth 授权。因此，智能体只能访问其调用用户有权查看的系统。六层基于角色的访问控制模型按智能体、按工具和按数据源强制执行权限。敏感用户数据在到达模型之前会在网关处被掩码处理，Amazon Bedrock Guardrails 则强制执行内容策略。

每个提示、工具调用和响应都通过 AgentCore Observability 流式传输到 Amazon CloudWatch Logs，AWS CloudTrail 则记录底层 API 活动。该审计追踪至关重要：AiDaH 现已被写入 U Mobile 的 L2 支持标准操作程序，并接受运营审计。所有计算都在私有 VPC 子网中运行，本地连接仅通过加密 VPN 进行，AWS Key Management Service（AWS KMS）管理静态和传输中数据的加密密钥。

超过 150 个已记录的运营场景

AiDaH 目前覆盖的场景横跨六个领域。下表总结了各领域的覆盖情况。

领域 覆盖范围
客户管理 账户详情、账单历史、付款状态、有效套餐和合同、SIM 信息、服务状态
订单运营与物流 订单和配送状态、待处理订单、资源分配、追踪工作流、配送跟踪、发货历史
客户问题管理 附加购买失败、套餐变更和充值失败的根因诊断。号码可携携入和携出检查。跨短信、通话和数据的服务中断诊断
IT 基础设施运营 服务器和设备状态监控、IP 和主机名查询、网络设备清单
商业智能与分析 用户趋势分析、设备采用趋势、收入趋势、异常检测、单个用户分析。分析智能体将自然语言问题转换为 SQL 查询，因此无需技术技能
知识检索 企业级检索，提供上下文感知、有依据的响应，并附带回溯至源证据的引用

衡量进展：AI 能力模型

为了跟踪进展并在整个组织内建立共同词汇，团队采用了八级 AI 能力模型，从基本数字访问到自主自愈运营。它借鉴了行业思想，包括 TM Forum 自治网络成熟度等级，并针对 U Mobile 的运营环境进行了调整。下表列出了这八个等级。

等级 名称 描述
1 数字访问 自助服务门户、在线工具和仪表板
2 脚本化自动化 基于规则的工作流触发和自动路由
3 基础 AI 辅助 简单聊天机器人、FAQ 查询、意图分类
4 上下文智能 上下文感知建议、具备记忆的基础自然语言理解
5 主动式 AI 预测性警报、异常检测、推荐引擎
6 自主任务执行 AI 在护栏约束下端到端完成既定任务
7 协作式多智能体 专业智能体协作、使用工具、检索受治理的知识
8 自愈与自适应 自主系统能够检测、诊断、修复并持续学习

AiDaH 在首次试点后的九个月内达到了第 7 级：专业智能体协作、使用工具、检索受治理的知识，并支持跨领域的运营决策。第 8 级——问题在无需人工介入的情况下被检测、诊断和解决——是当前的目标。

推动采用：从工具到队友

部署 AiDaH 是一回事。让人们信任并使用它则是另一回事。

ISD 很早就认识到，采用不是技术问题，而是行为改变挑战。员工习惯于既定工作流、可信工具和熟悉的升级路径。引入 AiDaH 意味着要求他们改变根深蒂固的习惯。这也意味着要信任 AI 代表他们检索信息、诊断问题并提出下一步建议。

团队依靠定向提示。ISD 没有期望开放式探索，而是为常见场景提供了结构化提示模板。这些模板将“随便问 AiDaH 什么”变成了“以下正是如何请求账单检查或携入状态”。这减少了犹豫，并产生了即时、切实的成果。当响应被证明快速、准确且可操作时，消息便传开了。一项内部调查将该平台的易用性评为 5 分中的 4.6 分，如今日常使用在前线团队中已成为常态。

最清晰的信号出现在 AiDaH 被正式纳入 U Mobile 的 L2 支持标准操作流程之时。从可选工具转变为可审计的 SOP，正是从试验阶段迈向运营阶段的标志。

ISD 的做法从来不是购买一套现成的解决方案，而是掌控整个旅程：构建内部 AI 能力，鼓励负责任的试验，并将实用的 AI 素养融入日常运营节奏。除 AiDaH 本身之外，ISD 还维护着一个专门的内部 AI 频道，供各团队分享用例、技术和早期实验。目标不是将 AI 专业知识集中在一个团队，而是将其分散，让每个部门都能在受治理的护栏内自信地使用 AI。进展并非线性。这一过程伴随着挫折和重新校准，而每一次都让平台和团队变得更强大。

成果

根据 U Mobile 的内部测量数据，2026 年 1 月至 9 月期间，三大类别的月度故障工单量均有所下降：

  • 开通与网络工单下降了 84.5%。
  • 一般咨询下降了 81.6%。
  • 计费与收费相关工单减少了 48.7%。

团队如何构建它：使用 Kiro 进行规范驱动开发

U Mobile 使用 Kiro 加速了 AiDaH 的开发，Kiro 是围绕规范驱动开发构建的 AWS 智能体 IDE。在 Kiro 中，一项新能力始于规范而非提示词：需求、设计和任务分解会先被写下来并经过评审，代码生成则针对这一达成一致的产物进行。对于 AiDaH 而言，这一点在智能体与工具的边界上最为重要。每个新的运营领域都意味着一个新的网关、一组 MCP 工具定义，以及决定谁可以调用它们的基于角色的访问控制条目。先将这些写下来，使每个新领域成为可重复的工作单元，而不是一次全新的设计练习。

配套工具链是常规的。团队使用 Kiro IDE 进行本地开发，配合智能体钩子和 MCP 集成，并使用 Kiro CLI 进行流水线自动化。源代码控制运行在 GitLab 上，由 AWS CodePipeline 和 AWS CodeBuild 驱动持续集成，容器镜像发布到 Amazon Elastic Container Registry（Amazon ECR），SonarQube 提供持续的代码质量扫描。规范驱动了代码生成。这一纪律让一个小团队从两个用例的概念验证，发展到以 12 周冲刺节奏推进的 150 多个有文档记录的用例。

关键架构决策

若干选择塑造了 AiDaH 从概念验证扩展到生产平台的方式。其中四项尤为突出，每一项都降低了添加下一个运营领域的成本，或在平台增长过程中保持其可治理性。

以 AgentCore 作为托管基础设施—— 团队没有构建自定义的智能体框架，而是使用了 Amazon Bedrock AgentCore 内置的扩展、身份、记忆和可观测性能力。AWS 负责底层的预置、扩展和补丁管理，从而消除了整个基础设施工程层。

以 MCP 实现通用工具连接—— 标准化采用模型上下文协议意味着 AiDaH 可以在不重建智能体逻辑的情况下接入新的后端系统。每个新的运营领域需要一个新的网关，而不是一套新的集成架构。

以 A2A 实现专家协作—— Agent2Agent 协议让领域专家智能体可以将子任务相互委派。一个跨越客户记录、接口日志和计费数据的查询，会自然地在相关智能体之间路由。

安全基础先行—— 在扩展到生产环境之前，对登陆区运行 Well-Architected 安全审查，意味着安全控制由每个新智能体和网关继承，而不是事后附加。

下一步

U Mobile 的路线图侧重于扩展广度和深度：接入更多运营领域和后端集成，同时将平台能力从单系统查询演进为多系统关联诊断。更长远的目标——能力模型中的第 8 级——是从为支持人员提供信息，转向自主解决问题。

安全治理同步成熟。团队正在使实践与 NIST SP 800-53、OWASP LLM 应用十大风险、CSA AI 信任框架和 MITRE ATLAS 保持一致。与此同时，对马来西亚《个人数据保护法》和马来西亚通信与多媒体委员会法规的合规工作也在持续推进。

结论

AiDaH 展示了当 AI 停止辅助、开始行动时会发生什么。在不到一年的时间里，U Mobile 从两个智能体的概念验证，发展到八个专业智能体服务 150 多个有文档记录的运营场景。根据 U Mobile 的内部测量数据，关键类别的故障工单量最多下降了 84.5%，而 U Mobile 现已将该平台写入其正式的 L2 支持流程。

我们逐一介绍了六个层次，跟踪了一个请求从 Teams 到本地系统再返回的流程，并描述了在生产规模扩展之前进行的 Well-Architected 安全审查。技术基础很重要，但那些不那么光鲜的工作同样重要。这意味着在扩展之前验证登陆区，编写结构化提示词以便员工知道如何开始，并将采用视为行为改变问题而非部署里程碑。面临类似系统碎片化问题的团队可能会发现同样的模式有用。从托管智能体运行时开始，在集成边界添加标准工具协议，并在规模扩展之前而非之后运行安全审查。

方向依然明确：安全地扩展，负责任地自动化，稳步迈向自主、自愈的运营，一次一个审慎且受治理的步伐。

如需了解更多，请访问 Amazon Bedrock AgentCore 和 Amazon Bedrock AgentCore 开发者指南。如需探索规范驱动开发，请参阅 Kiro.

关于作者