U Mobile 如何基于 Amazon Bedrock AgentCore 构建智能体电信运维系统 AiDaH

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

当订阅用户无法购买流量加油包时，解决这个问题并不是单一问题，而是一个协调问题。客服智能体需要调取接口日志以查找错误码。随后，同一智能体必须查询业务支撑系统 API 以确认订阅用户资格，并交叉查阅内部知识库以获取适用的业务政策。所有这些都要跨多个系统进行，然后才能开始撰写一个字的回复。而一旦失败，工单就会升级到后端 IT 团队，订阅用户则要等待更长时间。

传统的自动化工具可以帮助智能体写出更好的回复，但它们无法跨多个系统进行导航、分析结果并提出纠正措施。要弥补这一差距，需要一种构建在 Amazon Bedrock AgentCore 之上的智能体架构。

U Mobile 的信息系统部（ISD）正是构建了这样的架构。他们与 AWS 和 AWS 合作伙伴 Axrail 合作，在 Amazon Bedrock AgentCore 上创建了 AiDaH——AI 驱动的智能体帮助台（AI-Driven Agentic Helpdesk）。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 个智能体。2026 年第三季度，AiDaH 面向 50 名 L2 呼叫中心和分支机构用户正式上线，拥有 8 个智能体，目前覆盖超过 150 个已文档化的运营场景。

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

传统 AI 辅助与智能体 AI 之间的差异，用一个真实案例最能说明。

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

而在 AiDaH 中，系统会自主检查用户的漫游配置、核实国际数据业务资格，并定位具体的故障点。随后它会制定一份修复方案：需要重置哪些服务、需要推送什么配置、是否需要提交网络工单。客服人员审核并确认后，各项操作随即执行。过去耗费客服人员时间的排查工作，如今在他们读到第一行内容之前就已经完成。人工决策环节被保留在最关键之处：即在活跃用户账户发生变更的时刻。

在一个生产环境案例中，一名用户报告无法购买附加包。AiDaH 将故障追溯到一个错误代码：“用户存在未完成订单”。它还发现该客户在三天内通过多个渠道尝试了同一笔购买超过 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 的一项功能，通过统一的 Model Context Protocol（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。任何一项检查未通过的请求都会在此终止。
路由： 编排器选择能够处理该请求的最廉价层级。诸如“port-in status”这样的可识别短语会确定性匹配，完全跳过模型调用。表述含糊的问题会交给轻量级分类器。新颖或多部分的问题则交给完整编排器。
智能体实例化： 被选中的专家智能体作为会话在 AgentCore runtime（Amazon Bedrock AgentCore 的一项功能）中运行。AgentCore memory 重新载入对话上下文，使智能体继承用户号码以及此前轮次的发现，而无需让用户重复提供。
工具发现与调用： 智能体向 AgentCore Gateway 查询其有权使用的工具。每个网关将其后端发布为具有类型化输入和输出的 MCP 工具，因此智能体按名称和架构选择工具，而无需手工编写的集成逻辑。Amazon Cognito 为调用代理 OAuth 授权。
后端调用： 网关的 Lambda 函数或 MCP 服务器将工具调用转换为针对目标系统的请求，经由 AWS Transit Gateway 和 Site-to-Site 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	脚本化自动化	基于规则的工作流触发与自动路由
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（AWS 围绕规格驱动开发构建的智能体 IDE）加速了 AiDaH 的开发。在 Kiro 中，新能力以规格（spec）而非提示（prompt）开始：需求、设计和任务分解首先被写下来并经过评审，然后代码生成基于这份达成一致的文档进行。对 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 协议让领域专家智能体可以相互委派子任务。一个跨越客户记录、接口日志和账单数据的查询可以自然地在相关智能体之间路由。

安全基础先行 – 在扩展到生产环境之前先在 Landing Zone 上运行 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 安全审查。技术基础固然重要，但那些不那么光鲜的工作同样关键。这意味着在扩展之前先验证 Landing Zone、编写结构化的提示词让员工知道如何上手，以及把采用视为一个行为改变问题，而非部署里程碑。面临类似系统碎片化问题的团队或许会发现同样的模式很有用：从托管智能体运行时起步，在集成边界添加标准工具协议，并在规模扩展之前（而非之后）进行安全审查。

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

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