U Mobile以Bedrock AgentCore构建电信运维智能体
摘要：马来西亚运营商 U Mobile 推出智能运维平台 AiDaH，以 Amazon Bedrock AgentCore 承载八类专业智能体，通过 MCP 连接本地与云端系统，并借助 A2A 完成跨域协作。平台已覆盖六个业务部门、150 多个运维场景；内部统计显示，2026 年 1 至 9 月部分工单量最多下降 84.5%。其关键实践是以确定性路由优先降低成本，在身份、权限、数据脱敏和人工确认层建立治理闭环，而非让模型直接执行高影响操作。
从辅助坐席到可执行智能体
U Mobile 已将基于 Amazon Bedrock AgentCore 的 AiDaH（AI-Driven Agentic Helpdesk）投入生产环境。平台不再只生成客服回复，而是主动查询日志、验证订户状态、检索业务政策、定位故障点，并生成修复方案；对会改变实时订户账户的动作，仍由支持人员确认后执行。
上线九个月后，AiDaH 已覆盖六个业务部门、150 多个有文档记录的运维场景。U Mobile 的内部统计称，2026 年 1 月至 9 月，网络与开通工单下降 84.5%，一般咨询下降 81.6%，计费工单下降 48.7%。这些数据来自单一企业内测，能够说明该工作流可能带来的运营收益，但并非独立、对照式基准，ticket 分类口径、季节性和同期流程变化仍需进一步披露。
六层架构如何拆解复杂运维
AiDaH 部署在 AWS 亚太地区（新加坡），但其工具边界深入 U Mobile 的本地化 IT 环境。整体分为六层：
- 交互层：员工通过 Microsoft Teams 和 Web Portal 使用平台；Teams 前端由 AWS Lambda 承接，并通过 REST API 支持程序化触发。
- 编排层：Amazon Bedrock AgentCore 负责路由。每个请求先经过身份校验、六级 RBAC 与 Bedrock Guardrails 检查。
- 专业智能体层：八个智能体覆盖 CRM、客户问题管理、号码携转、订单与 SIM、基础设施监控、大数据分析、云成本和财务运营。
- 网关与后端 API 层：AgentCore Gateway 把业务系统封装成 MCP 工具，由 Lambda 或 MCP Server 将工具调用转换为具体系统请求。
- 数据与知识层：Bedrock Knowledge Bases 配合 OpenSearch Serverless 提供企业级 RAG；AgentCore Memory 保存跨轮次上下文，DynamoDB 保存 RBAC 和会话元数据。
- 运营系统层：本地与云端系统通过 Transit Gateway 和 IPsec Site-to-Site VPN 接入，不暴露于公网。
典型请求从 Teams 发起后，AgentCore Identity 签发短期令牌，Cognito 代理下游 OAuth 授权。专业智能体从 Gateway 发现自己有权调用的工具，查询本地系统，再通过 A2A 将跨域子任务交给其他智能体。最终答案由知识库提供事实依据，修复建议返回 Teams 等待人工确认。
分级路由：用确定性路径换取成本与延迟
AiDaH 的编排层没有让每个请求都进入大模型。其路由策略分为三层：约 70% 的请求通过确定性关键词匹配直接解决，20% 由轻量模型分类，剩余 10% 才进入完整编排器。
这种设计的工程价值在于把“能否处理”和“是否值得调用模型”分离。对于“携转状态”这类高频、结构化问题，关键词路由可以避免一次模型推理带来的延迟、Token 成本和非确定性输出；只有表达模糊或涉及多系统关联的问题才升级到完整编排路径。
不过，路由比例本身不能替代质量评测。关键词覆盖不足会造成错误降级，把复杂问题送入确定性分支；轻量分类器的误判则可能造成额外推理开销或错误升级。生产环境还应持续测量路由准确率、升级率、端到端延迟、每次成功解决成本以及错误动作拦截率，而不是只统计模型调用比例。
MCP、A2A 与“稳定内核”
AiDaH 的关键设计是把智能体逻辑与后端集成标准化。MCP 为工具提供统一的名称、Schema 和类型化输入输出，新增业务域主要增加 Gateway 与工具定义；A2A 则允许号码携转、CRM、计费等专业智能体相互委派任务。相比为每个系统硬编码函数，这种模式降低了接入新域时的边际工程成本。
不过，MCP 标准化的是发现和调用接口，不自动保证业务语义正确。工具描述模糊、Schema 不完整或后端错误码不稳定，都会让模型产生“调用成功、诊断错误”的结果。工程上仍需要为每个工具定义可测试的契约、幂等语义、超时策略、补偿动作和错误分类，并针对提示注入、工具描述投毒与跨工具数据外泄进行专门测试。
安全治理建立在执行链路上
AiDaH 在接入订户数据、计费系统和网络基础设施前，先对 AWS Landing Zone 开展 Well-Architected Security Review。基础设施侧采用 Control Tower 防护栏、Organizations SCP、Security Hub、集中身份和网络边界；应用侧则把 Microsoft Entra ID 联合身份、AgentCore Identity 短期令牌、Cognito OAuth、六级 RBAC、网关字段脱敏和 Bedrock Guardrails 串联起来。
所有 Prompt、工具调用、响应、Token 消耗和延迟通过 AgentCore Observability 写入 CloudWatch，底层 API 活动由 CloudTrail 记录。计算位于私有 VPC 子网，静态数据由 KMS 管理密钥。
这套设计的关键不是“让模型自由探索”，而是限制模型能够看到和执行什么。尤其在处理实时订户账户时，平台保留人工确认点：高影响动作必须由员工审核后再执行。未来若向 Level 8 的自愈网络演进，还应补充幂等执行、动作白名单、变更窗口、回滚机制和独立策略引擎。
Spec-Driven Development 如何支撑规模化交付
U Mobile 使用 Kiro 以规格驱动方式开发 AiDaH：先编写并评审需求、设计和任务拆分，再让代码生成围绕已确认规格展开。对于“智能体—工具—权限”这一边界，规格化尤其重要，因为每个新业务域都需要同步定义 Gateway、MCP 工具及对应 RBAC 权限。
配套工具链包括 GitLab、CodePipeline、CodeBuild、ECR 和 SonarQube。团队称其通过 12 周迭代周期，从两个用例的概念验证扩展到 150 多个用例。规格驱动并不自动保证实现正确，但它能把原本隐含在代码中的接口契约和权限要求显式化，从而更适合审计与多人协作。
实测结果应如何解读
84.5% 的最高工单降幅是案例中最醒目的数字，但不能直接解释为模型准确率或完全自动化率。AiDaH 仍采用人在回路，且工单下降也可能来自流程标准化、知识库完善和前端入口统一。平台被写入 L2 支持标准操作规程，说明它已经成为受治理的业务工具，而不是一次性演示。
更可靠的验证方式应包括：按场景类别统计诊断准确率与根因召回率；比较人工、规则引擎和智能体三种路径；对路由升级与错误动作做消融；追踪 P50/P95 延迟和单工单推理成本；测量工单重复率及客户等待时间；并对财务和网络变更场景做独立安全审计。
开发者与企业部署建议
对于准备复制这一架构的团队，可按以下顺序落地：
- 先挑选高频、只读、可回滚的运维场景，不要从自动修复生产网络开始。
- 为工具建立严格 Schema、权限边界、幂等语义和错误码规范。
- 将确定性规则放在模型之前，并对路由升级率建立持续监控。
- 把身份传播和审计设计成平台能力，而非事后补丁。
- 在模型看到敏感字段之前完成网关脱敏。
- 对写操作设置人工审批、动作预算与回滚路径。
- 用业务 KPI 与安全指标共同验收，而不是只统计对话量或模型调用量。
AiDaH 的生产价值来自一套完整的工程约束：标准协议降低接入成本，分级路由控制推理开销，AgentCore 托管运行时与记忆减少平台负担，RBAC、脱敏和审计限制风险。模型负责提出判断，平台负责决定它能看到什么、可以做什么，以及何时必须交还给人类。
—— 完 ——消息来源：AWS Machine Learning Blog (2026-11-04)
主题标签： #Amazon Bedrock AgentCore #多智能体 #MCP #电信运维 #企业AI
编辑部与事实核查说明：本篇专刊由智客前沿资讯管线根据官方技术公告、学术论文及开源工程文档整理编译，经算法实体核验与人工编辑审校后发布。若发现技术事实纰漏，欢迎依据勘误方针或一键向编辑部发送勘误反馈。
社区整体评论区