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 团队的战略基于三大支柱。

覆盖：实时协调后端系统的智能体。
深度：用于多步骤根因分析的思维链推理。
社区：一个具有基于角色的访问控制与内置护栏的安全多租户框架，面向所有部门开放。

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

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 将故障追溯到一个错误代码：“Subscriber has pending order”。它还发现该客户在三天内通过多个渠道尝试了同一购买 30 多次，每次尝试都被同一个底层待处理订单阻止。AiDaH 在单次响应中呈现了根本原因和修复步骤。此前这需要跨多个系统进行手动调查。

架构：六层，一个界面

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

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

图 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 频道中输入了一个携入状态问题。

接口： Teams 消息到达一个 AWS Lambda 函数，该函数将请求和调用者的联合身份转发给编排器。
预检： 编排器根据 Amazon DynamoDB 中保存的六层基于角色的访问控制模型解析调用者，验证由 AgentCore Identity（Amazon Bedrock AgentCore 的一项能力）签发的令牌，并对传入的提示应用 Amazon Bedrock Guardrails。任何一项检查未通过的请求都会在此停止。
路由： 编排器选择能够处理请求的最便宜层级。像“携入状态”这样的可识别短语会确定性地匹配，并完全跳过模型调用。模糊的措辞会交给轻量级分类器。新颖或多部分问题会交给完整的编排器。
代理实例化： 选定的专家代理作为 AgentCore runtime（Amazon Bedrock AgentCore 的一项能力）中的会话运行。AgentCore memory 会重新水合对话，使代理继承用户号码和之前轮次的任何发现，而不是要求用户重复。
工具发现与调用： 智能体向 AgentCore Gateway 查询其有权使用的工具。每个网关都将其后端发布为具有类型化输入和输出的 MCP 工具，因此智能体按名称和架构选择工具，而不是依赖手工编写的集成逻辑。Amazon Cognito 为该调用代理 OAuth 授权。
后端调用： 网关的 Lambda 函数或 MCP 服务器将工具调用转换为针对目标系统的请求，经由 AWS Transit Gateway 和站点到站点 VPN 隧道到达本地号码可携性平台。敏感字段在返回途中、响应到达模型之前被掩码处理。
推理与协作： 如果答案跨越多个领域，智能体通过 Agent2Agent 协议进行委派。例如，一个携入查询如果最终发现是计费阻塞，就会移交给业务支持系统智能体，结果合并为一段叙述。
响应与审计： 智能体基于 Amazon Bedrock Knowledge Bases 为其解释提供依据，然后将发现和建议的补救措施返回给 Teams 供人工确认。AgentCore Observability 是 Amazon Bedrock AgentCore 的一项能力，它将提示词、工具调用、token 计数和延迟的完整追踪写入 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	将每条提示词、工具调用、token 计数和延迟测量流式传输到 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	脚本化自动化	基于规则的 workflow 触发器和自动路由
3	基础 AI 辅助	简单聊天机器人、FAQ 查询、意图分类
4	上下文智能	上下文感知建议、带记忆的基础自然语言理解
5	主动式 AI	预测性警报、异常检测、推荐引擎
6	自主任务执行	AI 在护栏内端到端完成定义的任务
7	协作式多智能体	专业智能体协作、使用工具、检索受治理的知识
8	自愈与自适应	自主系统持续检测、诊断、修复和学习

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

推动采用：从工具到队友

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

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

团队借助定向提示。ISD 不期望开放式探索，而是为常见场景提供结构化提示模板。这些模板把“随便问 AiDaH 什么”变成了“以下就是如何查询账单或携号转网状态的确切问法”。这减少了犹豫，并产生了即时、可见的成果。当回复被证明快速、准确且可操作时，消息便传开了。一项内部调查给该平台的易用性评分为 4.6 分（满分 5 分），如今日常使用在前线团队中已成常态。

最清晰的信号出现在 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 进行本地开发，配合 agent hooks 和 MCP 集成，并使用 Kiro CLI 实现流水线自动化。源代码管理运行在 GitLab 上，由 AWS CodePipeline 和 AWS CodeBuild 驱动持续集成，容器镜像发布到 Amazon Elastic Container Registry（Amazon ECR），SonarQube 提供持续的代码质量扫描。规范驱动了代码生成。这一纪律让一个小团队从两个用例的概念验证，发展到以 12 周冲刺节奏推进的 150 多个有文档记录的用例。

关键架构决策

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

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

以 MCP 实现通用工具连接 – 统一采用 Model Context Protocol 意味着 AiDaH 无需重建 agent 逻辑即可接入新的后端系统。每个新的运营域只需要一个新的网关，而不是一套新的集成架构。

以 A2A 实现专家协作 – Agent2Agent 协议让各领域专家可以相互委派子任务。一个横跨客户记录、接口日志和计费数据的查询，会自然地路由到相关 agent。

安全基础先行 – 在扩展到生产之前对 Landing Zone 运行 Well-Architected 安全审查，意味着安全控制会被每个新 agent 和网关继承，而不是事后补加。

下一步

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

安全治理同步成熟。团队正在使实践对齐 NIST SP 800-53、OWASP Top 10 for LLM Applications、CSA AI Trust Framework 和 MITRE ATLAS。与此同时，也在持续遵循马来西亚《个人数据保护法》以及马来西亚通信与多媒体委员会的规定。

结论

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

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

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

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

关于作者

Jin Tiong Lim

Jin Tiong 是 U Mobile 的技术服务主管，领导信息系统部门。他专注于通过 AI 和自动化实现电信运营现代化，建设内部能力，使每个部门都能在受治理的护栏内采用 AI。

Kelvin Kok

Kelvin 是 AWS 合作伙伴 Axrail 的首席架构师兼 AI 战略师。他为企业和电信客户在 AWS 上设计代理式 AI 架构，专注于 Amazon Bedrock AgentCore、多代理编排和规范驱动交付。

Colm Mulholland

Colm 是 AWS 马来西亚的高级解决方案架构师。他与电信客户合作，涉及数据、AI/ML 和云原生架构，帮助他们将 AI 工作负载从概念验证推进到生产环境。