[Amazon Bedrock] U Mobile 如何用 Amazon Bedrock AgentCore 构建 agentic 电信运营

U Mobile 如何用 Amazon Bedrock AgentCore 构建 agentic 电信运营

U Mobile 是马来西亚最新的 5G 网络提供商，其电信运营一直走精益路线：通过持续的自动化，用更少的投入做更多的事。当新的 AI 能力出现时，U Mobile 开始探索如何超越基础的生产力提升、进一步改进运营效率。真正的机会在更上游——在于运营团队最初是如何诊断并解决问题的。同样是这套精益运营的纪律，奠定了 AiDaH 的基础：它不是一次性的技术项目，而是一段长期旅程的下一步——在不增加复杂性的前提下简化运营、扩展能力。

当一位用户无法购买流量叠加包时，解决它并不是一个单一问题，而是一个协同问题。客服人员需要拉取接口日志找错误码，同一个人还得查询业务支撑系统的 API 来确认用户资格，并交叉比对企业内部知识库中适用的业务政策。这一切都发生在多个系统之间，而且是在写下回复的第一个字之前。如果还是没解决，工单就会升级到后台 IT 团队，用户要等得更久。

传统的自动化工具可以帮助客服人员写出更好的回复。它们做不到的是穿行于多个系统、分析结果并提出纠正措施。要补上这段差距，需要一套构建在 Amazon Bedrock AgentCore 之上的 agentic 架构。

U Mobile 的信息系统部门（ISD）构建的正是这样一套东西。他们与 AWS 以及 AWS 合作伙伴 Axrail 一起，在 Amazon Bedrock AgentCore 上创造了 AiDaH——即 AI-Driven Agentic Helpdesk。Amazon Bedrock AgentCore 是一个可用任意框架或模型、以规模化方式构建、连接和优化 agent 的平台。有两个能力决定了这一选择。托管的 agent runtime 意味着没有 agent 基础设施需要运维；内建的 memory 能跨轮次承载会话上下文，而不必再搭建一套独立的状态存储。开启这段旅程不到一年，AiDaH 就已处理六个业务部门的 150 多个已记录在案的运营场景。U Mobile 的内部度量显示，在关键类别中故障工单量最多下降了 84.5%。

在本文中，我们会梳理 AiDaH 背后的六层架构，接着介绍平台之下的安全底座，最后简要说明团队用来构建它的 spec-driven 方法。

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

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

在 AiDaH 之前，这种碎片化意味着即使是一次例行诊断，也要在不同的系统和门户之间手工查日志、查询用户资格、到知识库里翻业务政策。每一次查询都是一次上下文切换，每一次上下文切换都是被浪费的时间，而每一个没能解决的问题都会升级成给后台 IT 团队的工单。把覆盖范围扩展到更多运营领域还会让问题加剧，因为每接入一个新系统通常都需要一次定制化的集成。

ISD 团队的策略建立在三个支柱之上。

Reach：agent 在后端系统之间实时协同。 Depth：用思维链推理做多步根因分析。 Community：一套带有基于角色的访问控制和内建护栏的安全多租户框架，向所有部门开放。

历程：从知识库到 agentic 平台

AiDaH 始于一条原则：想大问题，从小处着手。U Mobile 在 2025 年底开始概念设计，起点是两个试点 agent 和 Amazon Bedrock Knowledge Bases——一项完全托管的检索增强生成（RAG）能力。2026 年一季度的试点让内部 IT 服务台上线，包含 4 个 agent 和 20 个运营场景。整个 2026 年，平台不断加固并扩展，增加了三层路由，到年中达到 6 个 agent。2026 年三季度，AiDaH 带着 8 个 agent 面向 50 位 L2 客服中心和分支机构用户正式启用，如今已覆盖 150 多个已记录在案的运营场景。

agentic 在实践中意味着什么

传统 AI 辅助与 agentic AI 之间的差别，用一个真实例子最容易说明。

用传统的 AI 助手时，处理“境外流量用不了”这类问题的客服人员，能得到起草回复和一些排障建议的帮助，但依然要自己手工查漫游状态、核实资格、提工单，并发送最终回复。

有了 AiDaH，系统会自主检查该用户的漫游配置、核实国际流量资格，并定位具体的故障点。随后它组装出一份修复方案：要重置哪些服务、要下发什么配置，以及是否有必要提一张网络工单。客服人员评审并确认，操作随即执行。过去消耗客服人员时间的调查工作，如今在他们读到第一行之前就已经完成了。真正要紧的地方保留了人的决策点：在某个在网用户账户即将发生变更的那一刻。

在一个生产案例中，一位用户反馈无法购买叠加包。AiDaH 把故障追溯到一个错误码——“Subscriber has pending order”。它还显示，这位客户在三天里跨多个渠道尝试了同一笔购买 30 多次，每一次都被同一个底层的待处理订单拦住。AiDaH 在一次回复中就呈现了根因和修复步骤。换作以往，这需要在多个系统之间做人工调查。

架构：六层，一个界面

AiDaH 运行在一套构建于 Amazon Bedrock AgentCore 的分层架构上，部署在 Asia Pacific (Singapore) 区域。员工通过 Microsoft Teams 与之交互，这是刻意的选择——在大多数用户已经在工作的地方与他们相遇，既不用学习新应用，也不用在不同门户之间切换。

下图展示了这些层是如何衔接在一起的。

图 1：AiDaH 的分层架构

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

第 1 层：员工界面

员工通过 Microsoft Teams 和一个 Web 门户访问 AiDaH，该门户由 Amazon CloudFront 承载、由 AWS WAF 防护，后端是 AWS Lambda，并提供一个用于程序化触发的 REST API。

第 2 层：编排

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

第 3 层：专家 agent

八个专家 agent，分别覆盖客户关系管理、客户问题管理、携号转网、订单与 SIM 运营、基础设施监控、大数据分析、云成本管理和财务运营。它们通过 Agent2Agent（A2A）协议通信，因此可以相互委派子任务，完成单个 agent 无法独自处理的跨系统工作流。

第 4 层：网关与后端 API

AgentCore Gateway 是 Amazon Bedrock AgentCore 的一项能力，它通过统一的 Model Context Protocol（MCP）接口把 U Mobile 的后端暴露给 agent。每个网关后面是 AWS Lambda 函数和 MCP 服务器，它们把 agent 的意图转换成针对某个具体系统的调用。

第 5 层：数据与知识

完全托管的 RAG 能力 Amazon Bedrock Knowledge Bases，借助 Amazon OpenSearch Serverless 向量存储，把 agent 的回答落在受治理的内容之上。内容涵盖共享的企业知识库和一个独立的财务语料库。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”这样的已识别短语会被确定性匹配，完全跳过模型调用。含糊的表述交给轻量分类器。新颖的或由多个部分组成的问题交给完整的编排器。 agent 实例化： 选中的专家 agent 作为一个会话运行在 AgentCore runtime（Amazon Bedrock AgentCore 的一项能力）上。AgentCore memory 会重新载入对话，使该 agent 继承用户号码和前面轮次中的既有发现，而不是要用户再说一遍。 工具发现与调用： agent 向 AgentCore Gateway 查询自己有权使用的工具。每个网关把自己的后端发布为带类型化输入与输出的 MCP 工具，因此 agent 是按名称和 schema 选择工具，而不是靠手工编写的集成逻辑。Amazon Cognito 为这次调用协商 OAuth 授权。 后端调用： 网关的 Lambda 函数或 MCP 服务器把工具调用转换成针对目标系统的请求，途中经过 AWS Transit Gateway 和 Site-to-Site VPN 隧道，抵达本地部署的携号转网平台。敏感字段在返回途中就被遮蔽，之后响应才会到达模型。 推理与协作： 如果答案横跨多个领域，agent 会通过 Agent2Agent 协议委派。举例来说，一次携入查询最终发现是缴费被冻结，就会移交给业务支撑系统 agent，再把结果合并成一段连贯的说明。 响应与审计： agent 依据 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 及其子 agent，无需预配任何服务器 Memory跨轮次维护会话上下文，例如用户号码、订单 ID 和既往发现 Identity签发短期访问令牌，确保只有获授权的用户才能调用 agent Gateway通过统一、安全的 MCP 接口把 agent 连接到 U Mobile 的后端 Observability把每一条提示词、工具调用、token 计数和延迟度量流式传输到 Amazon CloudWatch

加固安全底座

部署一个能够触达用户数据、计费系统和网络基础设施的 agentic AI 平台，仅有应用层的安全是不够的，它需要一个安全的云底座。U Mobile 采取了双管齐下的做法：验证并加固底层的 AWS Landing Zone，并依托 Amazon Bedrock AgentCore 的安全能力来构建。

Landing Zone 安全 – 在把 AiDaH 扩展到生产规模之前，U Mobile 请 AWS 对承载该平台的 Landing Zone 做了一次 Well-Architected Security Review。这次评审依据 AWS 的安全最佳实践验证了该环境。基础设施防护排在首位，通过 AWS Control Tower guardrails 和 AWS Organizations 的服务控制策略实现。评审接着检查了集中式的身份联邦，以及入口与出口的网络安全控制。汇总到 AWS Security Hub 的安全发现，以及贯穿每一个架构层级的加密标准，完成了这次评估。结果是两方面的：确认每个 AiDaH 组件都运行在一个经过独立验证的基础之上，同时得到一份按优先级排列的持续改进路线图。

应用层安全 – 每一个 agent 动作都能追溯到某个具体的、已通过认证的用户。员工通过 Microsoft Entra ID 实现联邦登录，AgentCore Identity 签发授权 agent 调用的短期令牌。Amazon Cognito 在网关处协商 OAuth 授权。因此一个 agent 只能触达其调用者有权查看的系统。六级的基于角色的访问控制模型按 agent、按工具、按数据源来强制权限。敏感的用户数据在到达模型之前会在网关处被遮蔽，内容由 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 与主机名查询、网络设备清单 商业智能与分析用户趋势分析、终端渗透趋势、收入走势、异常检测、单个用户的分析。分析 agent 把自然语言问题转换成 SQL 查询，因此不需要技术技能 知识检索面向全企业的检索，给出感知上下文、有依据的回答，并附带指回原始证据的引用

衡量进展：一个 AI 能力模型

为了跟踪进展、在整个组织内建立共同的词汇，团队采用了一个八级的 AI 能力模型，从基础的数字接入一直到自主的自愈式运营。它借鉴了行业上的思考，包括 TM Forum Autonomous Networks 的成熟度等级，并结合 U Mobile 的运营实际做了调整。下表列出了这八个等级。

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

从第一次试点算起，AiDaH 在九个月内就达到了第 7 级：专家 agent 彼此协作、使用工具、检索受治理的知识，并跨领域支持运营决策。第 8 级——问题在没有人工介入的情况下被检测、诊断和解决——是当前的目标。

推动采用：从工具到队友

部署 AiDaH 是一个挑战。让人们信任并使用它是另一个挑战。

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

团队依靠的是定向提示。ISD 并不指望大家漫无边际地去探索，而是为常见场景提供了结构化的提示词模板。这些模板把“想问 AiDaH 什么都行”变成“要查账单或查携入状态，就该这样问”。这减少了犹豫，并立刻带来看得见的成绩。当回答被证明是快速、准确、可执行的时候，口碑就传开了。一项内部调查显示，平台在易用性上得到 4.6 / 5 的评分，如今一线团队每天都离不开它。

最清晰的信号出现在 AiDaH 被正式纳入 U Mobile 的 L2 支持标准作业程序之时。从一件可选的工具变成一份可审计的标准作业程序，标志着从试验转向运营。

ISD 的做法从来不是去买一个现成的解决方案，而是把这段旅程掌握在自己手里：建设内部 AI 能力、鼓励负责任的试验，并把实用层面的 AI 熟练度融入日常运营节奏。除了 AiDaH 本身，ISD 还维护着一个专门的内部 AI 频道，团队在那里分享用例、技巧和早期实验。目标不是把 AI 专长集中在一个团队，而是把它分散开来，让每个部门都能在受治理的护栏之内自信地使用 AI。进展并非线性。这条路上有挫折也有重新校准，而每一次都让平台和团队更强大。

成效

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

开通与网络类工单下降 84.5%。 一般咨询类下降 81.6%。 计费与扣费类减少 48.7%。

团队是怎么构建的：用 Kiro 做 spec-driven 开发

U Mobile 用 Kiro 加快了 AiDaH 的开发，这是 AWS 围绕 spec-driven 开发构建的 agentic IDE。在 Kiro 里，一个新能力始于一份规格而不是一个提示词：需求、设计和任务拆解先写下来并经过评审，代码生成则针对这份已经达成一致的产出物进行。对 AiDaH 而言，这一点在 agent 与工具的边界上最为关键。每一个新的运营领域都意味着一个新的网关、一组 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 相互委派子任务。一个同时涉及客户记录、接口日志和账单数据的查询，会自然地路由到相关的几个 agent 上。

先夯实安全底座 – 在扩展到生产规模之前先对 Landing Zone 做一次 Well-Architected Security Review，意味着安全控制会被每一个新的 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 Security Review。技术底座很重要，那些不那么光鲜的工作同样重要：扩容前先验证 Landing Zone，写好结构化的提示词让员工知道如何开始，把采用当作一个行为改变的问题而不是一个部署里程碑。面对类似系统碎片化的团队，也许会发觉同一套路子有用：从托管的 agent runtime 起步，在集成边界上采用标准的工具协议，并在扩容之前而不是之后做一次安全评审。

方向依然清晰：安全地扩张、负责任地自动化，稳步迈向自主、自愈的运营，一步一步，既审慎又在治理之中。

要了解更多信息，请访问 Amazon Bedrock AgentCore 和 Amazon Bedrock AgentCore Developer Guide。想进一步了解 spec-driven 开发，可以看看 Kiro。

关于作者