电信运维 Agent 上线九个月的落地成效

U Mobile 做的 AiDaH，是把客服排查问题时反复切换系统的工作，交给一组能查询后台、核对规则、协作诊断的 AI Agent。涉及真实用户账户的修改，仍由工作人员确认。按其内部统计，部分工单类别的月工单量最高下降了 84.5%。

这份案例值得程序员读的地方，是它把 Agent 接进业务系统的具体方法：请求先分流，工具统一接入，权限跟随用户，最后再把新流程写进操作规范。但这些成果也有统计口径和适用前提，不能直接当成换个平台就能复制的收益。

工单难处理，往往是因为答案散在多个系统里

用户买不了流量包，客服可能要先查接口错误日志，再查询业务支撑系统里的购买资格，最后翻知识库确认业务政策。任何一步查不清，就转交后台 IT。

这类工作的难点不只是组织答案，而是把证据找齐。只负责生成回复的助手，可以给排查建议，却仍然把系统查询和结果核对留给人。

原文给了一个生产案例：某用户连续三天、通过多个渠道尝试购买附加套餐，累计超过 30 次，每次都被同一个未完成订单拦住。AiDaH 查到错误码「Subscriber has pending order」，把根因和修复步骤放进同一次回复。

这说明它至少能完成跨系统调查，但原文没有提供这次调查耗时、人工基线或独立验证结果。

另一个漫游故障示例，则展示了预期工作流程：系统检查漫游配置和国际流量资格，找出故障点，提出需要重置的服务、推送的配置，以及是否创建网络工单。工作人员审核后，才执行操作。

它把调查过程交给 Agent，把账户变更的决定留给人。

这也是理解该案例的边界：AiDaH 已经进入生产运维，但还没有达到全文所说的无人参与、自主修复。

为什么约七成请求根本不需要调用模型

AiDaH 的入口主要是 Microsoft Teams，也提供 Web 门户和 REST API。部署区域是 Asia Pacific（Singapore）。选择 Teams 的用意很实际：员工沿用已有工作入口，减少学习新系统的负担。

入口后面并不是直接调用大模型，而是先验证身份、检查权限并应用护栏，再进入三层路由：

• 约 70% 的请求通过确定性关键词匹配处理，无须调用模型。
• 约 20% 的请求交给轻量模型分类。
• 只有约 10% 的请求进入完整编排器。

例如，「port-in status」可以直接匹配携号转入状态查询；表达含糊时才需要分类器；新问题或多部分问题再交给完整编排器。

这里的「不调用模型」主要描述路由阶段，不能据此认定整条业务链路都不用模型。后续仍可能需要专门的 Agent 查询、分析和组织回复。

这套设计的价值，是把高频、稳定、容易识别的路径固定下来，让模型处理剩余的不确定性。原文没有给出模型名称、分类准确率、各层延迟或实际费用，因此它证明了成本控制的设计思路，没有证明具体节省金额。

背后的六层架构可以顺着一次请求理解：Teams 接收问题，编排层检查和分流，专业 Agent 执行任务，网关连接后台，知识与记忆层提供上下文，最终访问云上或本地业务系统。

专业 Agent 共 8 个，覆盖客户关系、客户问题、号码携转、订单与 SIM、基础设施监控、大数据分析、云成本和财务。跨领域任务通过 Agent2Agent（A2A）协议委派子任务。例如，携号转入失败若与账单阻塞有关，就需要相关领域协作。

工具标准化之后，权限和业务适配仍然要做

AgentCore Gateway 把后台能力暴露为 Model Context Protocol（MCP）工具，每个工具提供有类型的输入和输出。Agent 根据工具名称与结构选择调用，后面的 AWS Lambda 或 MCP server 再转换成具体业务系统请求。

这个边界很关键：Agent 不必为每个系统重新学习一套集成架构，但连接旧系统的适配工作仍然存在。

新增领域时，团队主要增加网关、MCP 工具定义和权限条目；身份检查、路由、会话恢复和审计等公共流程可以复用。原文将这种稳定的公共部分，视为控制新增领域成本的关键。

知识与状态也各有职责。Amazon Bedrock Knowledge Bases 使用 Amazon OpenSearch Serverless 向量存储，为回答提供受治理的资料；企业知识库和财务资料分开。AgentCore memory 保存跨轮对话上下文，Amazon DynamoDB 则保存六级角色权限模型和会话元数据。因此，「内置记忆」并不等于整个平台不需要其他状态存储。

权限沿着调用链传递：员工通过 Microsoft Entra ID 联合登录，AgentCore Identity 签发短期令牌，Amazon Cognito 在网关处理 OAuth 授权。访问范围按 Agent、工具和数据源分别控制，敏感用户字段在返回模型前脱敏。

本地系统通过 AWS Transit Gateway 和 AWS Site-to-Site VPN 的 IPsec 加密隧道访问。AgentCore Observability 将提示词、工具调用、Token 数量和延迟写入 Amazon CloudWatch，AWS CloudTrail 记录底层 API 活动。

开发流程同样围绕边界展开。他们使用 Kiro，先评审需求、设计和任务拆分，再生成代码。新增领域需要哪些工具、谁能调用，先形成规格。原文提到 12 周冲刺节奏，但没有提供与其他开发方式的效率对照。

我的判断

我更认可它对系统边界的处理：确定性路由承接明确请求，MCP 统一工具描述，用户身份约束调用范围，关键写操作保留人工确认。这些选择都直接对应运维里的实际摩擦，比单纯增加 Agent 数量更有参考价值。

但几个结果需要分开看。

按 U Mobile 内部统计，2026 年 1 月至 9 月，开通与网络类月工单量下降 84.5%，一般咨询下降 81.6%，账单与计费类下降 48.7%。原文没有披露绝对工单数、业务量变化、对照组或其他同期改造，不能把降幅全部归因于 AiDaH，也不能据此计算投资回报。

易用性评分为 4.6/5，同样缺少样本量和调查方法。相比之下，平台被写入 L2 支持标准操作流程，是它已经融入日常工作的更直接证据。

时间线也要谨慎读：2025 年末开始构思，2026 年 Q1 试点有 4 个 Agent、20 个场景，年中扩至 6 个 Agent，Q3 面向 50 名 L2 呼叫中心及门店用户上线时有 8 个 Agent，目前覆盖六个业务部门、超过 150 个已记录场景。原文另称首次试点后九个月达到 Level 7，但没有完整呈现八级能力模型，无法独立核对评级标准。

超过 150 个已记录场景，不等于超过 150 个场景都经过公开效果验证。

对一般团队，还要比较替代方案。如果任务步骤固定，规则引擎或普通工作流可能更容易测试和维护；只有当问题表达多变、证据分散、调查路径需要动态调整时，Agent 编排才更有吸引力。MCP 和 A2A 的组合是否优于单 Agent 加工作流，原文没有对照数据，仍属于团队经验。

能拿来做什么

• 做内部运维助手时，可以先挑一个需要跨系统查证的高频问题，明确所需数据、判断规则和人工确认点，再决定是否引入多个 Agent。
• 为 Node 服务封装 MCP 工具时，应同时写清输入输出、调用权限和脱敏规则；原有业务接口仍要承担参数校验与授权检查。
• 给已有助手增加复杂能力前，可以先统计高频请求，把稳定查询交给确定性路由，并分别记录分类错误、工具失败、延迟和调用成本。
• 推动内部使用时，可以为常见任务提供结构化提问模板，再逐步纳入操作流程。AiDaH 的采用过程说明，让员工知道第一步怎么问，与把服务部署上线同样重要。