1. 项目概述当网络运维遇上“工具使用”最近和几个在运营商做核心网的朋友聊天大家不约而同地提到了一个共同的痛点网络运维的自动化程度越来越高但“智能”程度似乎遇到了瓶颈。脚本、编排工具、自动化平台比如我们熟知的那些网管系统确实把工程师从重复劳动中解放了出来但面对一些复杂的、需要跨域协同的故障场景或策略调整时依然需要经验丰富的专家介入进行大量的手动判断和操作串联。这感觉就像给汽车装上了自动巡航但遇到复杂的城市路况还是得司机自己来打方向盘。这恰恰是“Tool Use as Action: Towards Agentic Control in Mobile Core Networks”这个标题背后所探讨的核心命题。它不是一个具体的开源项目而是一个极具前瞻性的技术理念和研究方向。简单来说它探讨的是如何让AI智能体Agent在移动核心网这个复杂环境中像人类专家一样自主地、有策略地“使用工具”来完成运维任务从而实现更高层级的“自主控制”。这里的“工具”范围非常广。它可以是调用一个北向API来查询用户状态可以是执行一段Ansible脚本去重启一个网元可以是向策略控制功能PCF下发一个新的QoS规则甚至可以是根据日志分析结果自动生成一份故障报告并发送给值班人员。而“作为行动”as Action意味着这些工具调用不再是孤立的、预设的步骤而是智能体在理解网络状态、分析目标后自主决策并执行的一系列连贯动作。为什么这个概念现在变得如此重要因为5G乃至未来6G的核心网其复杂性已经超出了传统自动化脚本能优雅处理的范围。网络切片、边缘计算、服务化架构SBA引入了前所未有的动态性和灵活性。一个简单的用户体验问题其根因可能涉及接入网、核心网用户面、控制面以及第三方应用服务器。传统的“if-this-then-that”规则引擎会变得无比臃肿且难以维护。我们需要的是一个能理解上下文、能规划步骤、能安全使用各种现有工具的“智能副驾驶”。这个方向的研究和实践正与“Model Context Protocol”MCP、“Agent2Agent”等最新热词紧密相连。MCP可以看作是为智能体提供标准化“工具库”访问能力的协议而Agent2Agent则关注多个智能体之间如何协作。对于核心网工程师、网络自动化开发者和电信软件架构师而言理解并参与构建这种“代理化控制”体系将是未来几年提升网络运维效率和智能水平的关键。2. 核心理念拆解从自动化脚本到代理化控制要理解“工具使用即行动”我们需要先厘清几个关键概念的演进以及它们如何共同指向“代理化控制”这个目标。2.1 工具使用的范式演进从被动执行到主动规划在传统的网络运维中“工具使用”是高度显性化和脚本化的。工程师编写一个Python脚本里面明确调用了requests.get()来查询接口用paramiko执行SSH命令用json.loads()解析返回数据。工具的使用逻辑、顺序、错误处理全部固化在代码中。这本质上是工程师思维的直接翻译。而“代理化控制”中的工具使用是智能体思维的体现。智能体内部有一个“规划器”或“推理引擎”。当它接收到一个高层目标例如“解决切片A中用户视频卡顿问题”时它会自主进行子目标分解诊断当前切片A的性能指标。定位可能的问题域无线核心网用户面传输。针对问题域选择并执行具体的诊断工具。根据诊断结果选择并执行修复或优化工具。在这个过程中具体调用哪个API、使用哪个CLI命令、参数是什么是由智能体在运行时基于其对网络模型的理解和实时上下文动态决定的。工具对于智能体而言就像扳手、螺丝刀对于老师傅是完成任务的手段其调用是目标驱动、上下文感知的。2.2 “代理化控制”的内涵与挑战“代理化控制”不仅仅是“更高级的自动化”。它的核心特征包括目标导向性接受高层、抽象的目标如“保障VIP用户群体验”、“优化XX区域的网络能效”而非具体的操作指令。自主规划与推理具备将抽象目标分解为可执行动作序列的能力并能根据执行反馈动态调整计划。上下文感知持续从网络通过遥测、日志、KPI和环境如业务高峰时间获取信息形成对当前状态的认知。安全与边界意识这是电信网络的生命线。智能体必须明确知道每个工具的“权限边界”例如一个负责性能监控的智能体不能越权执行设备重启操作。这需要一套严格的“工具权限”模型。在移动核心网中实现代理化控制面临独特挑战超高可靠性与实时性要求核心网控制面的操作直接影响千万用户任何决策都必须极度谨慎且往往有严格的时延要求。多厂商、异构环境核心网由多个网元AMF, SMF, UPF, PCF等构成可能来自不同厂商接口和工具API/CLI各异智能体需要具备跨异构工具操作的能力。状态复杂性网络状态是动态、多维且部分可观测的。智能体需要从海量、可能带有噪声的数据中构建准确的状态画像。2.3 Model Context Protocol智能体的“工具插拔”标准这正是“Model Context Protocol”受到关注的原因。MCP本质上定义了一套标准协议使得外部工具数据源、API、函数等能够以一种统一、声明式的方式“注册”到智能体框架中。对于核心网场景我们可以想象华为AMF网元将其北向API如查询用户连接状态、执行信令跟踪通过一个MCP Server进行封装。爱立信SMF网元也将其策略控制API通过另一个MCP Server封装。一个网络运维智能体通过MCP Client协议可以同时发现并调用这两个来自不同厂商的“工具”而无需关心底层是RESTful API、gRPC还是私有协议。MCP协议通常会描述工具的以下信息名称与描述get_subscriber_session_status输入参数模式{“imsi”: “string”, “dnn”: “string”}返回数据结构{“status”: “enum”, “upf_address”: “string”, ...}这极大地简化了智能体集成异构运维工具的过程实现了“即插即用”。智能体无需为每个厂商的每个接口编写适配代码只需通过MCP协议动态加载工具描述就能理解其功能并调用。这为构建大规模、可扩展的代理化控制系统奠定了基础。3. 核心网代理化控制系统的架构设计将理念落地我们需要设计一个可行的系统架构。这个架构并非唯一但结合当前主流实践可以勾勒出一个分层参考模型。3.1 整体架构分层一个面向移动核心网的代理化控制系统可以抽象为以下四层[ 交互层 ] -- [ 智能体核心层 ] -- [ 工具抽象层 ] -- [ 网络资源层 ] | | | | 自然语言 规划/推理/学习 MCP/适配器 网元/API/CLI 图形界面 记忆/目标管理 工具注册发现 数据库/消息队列网络资源层即被管理的对象包括5GC的各个NF网络功能、网管系统、OSS、基础设施服务器、交换机等它们暴露了各种管理接口NETCONF/YANG, RESTful API, CLI, SNMP, Kafka流数据等。工具抽象层这是关键的一层。它通过MCP Server、自定义适配器等方式将下层异构的网络资源接口统一抽象成上层智能体可以理解的“工具”。每个工具都有清晰的输入/输出定义、权限标签和副作用说明。这一层也负责工具的注册、发现和生命周期管理。智能体核心层这是系统的大脑。包含多个可能协同工作的智能体。每个智能体通常由几个模块组成规划模块基于目标、当前状态和可用工具生成动作序列即工具调用计划。推理/学习模块评估动作效果从历史中学习策略优化。可能基于规则、强化学习或大语言模型的推理能力。记忆模块存储交互历史、网络状态快照、知识库为规划和推理提供上下文。执行模块负责安全地调用工具抽象层提供的接口并处理返回结果和异常。交互层提供人机接口。运维人员可以通过自然语言如“检查一下北京数据中心到上海数据中心的SBI链路质量”、图形化看板或传统命令行与智能体交互下达指令或查询状态。3.2 智能体间的协作Agent2Agent模式复杂任务往往需要多个智能体协作完成这就是“Agent2Agent”模式的价值。例如我们可以设计三种角色的智能体诊断专家Agent擅长调用各种监控、日志查询、信令跟踪工具精于定位问题根因。策略执行Agent擅长调用网络策略控制接口如PCF、NSSF进行切片策略、QoS策略的调整。流程协调Agent不直接操作网络而是接收高层任务协调诊断专家和策略执行Agent的工作。当收到“优化切片A视频业务体验”的任务时流程协调Agent会先委托诊断专家Agent进行分析。诊断专家Agent通过调用KPI查询、用户面探针等工具得出结论“UPF-3负载过高导致时延增大”。流程协调Agent随后将“调整切片A用户到UPF-4的负载分担策略”这一子目标交给策略执行Agent去完成。策略执行Agent则调用SMF或负载均衡器的相关API来执行策略变更。Agent2Agent的通信同样可以基于类似MCP的轻量级RPC协议或者通过共享的消息总线如Redis Pub/Sub, Kafka来传递结构化消息。关键在于定义清晰的交互协议和共享的上下文数据模型。3.3 安全与权限管控设计这是架构设计中重中之重、必须前置考虑的部分。绝不能允许智能体拥有“上帝视角”和“万能钥匙”。工具权限最小化为每个工具或工具类定义精确的操作权限。例如query_kpi工具只有读权限modify_policy工具需要关联特定的策略范围和审批流程。智能体权限继承每个智能体被分配一个角色其可使用的工具集合不能超过该角色的权限范围。一个“只读监控Agent”就不能获得任何写操作工具。操作审批与复核对于高风险操作如网元重启、核心配置变更系统应设计“人工在环”机制。智能体可以提出操作建议和完整的影响分析但最终执行需要经过工程师确认。或者采用“双人复核”模式由另一个专门的“安全审核Agent”对计划进行模拟和风险评估。操作溯源与回滚智能体的每一个工具调用都必须被完整记录谁、何时、调用什么、参数、结果并生成可读的日志。系统必须支持基于记录的快速回滚能力。注意在初期实践中强烈建议采用“建议-批准”模式即智能体只提供诊断结论和操作建议由人类工程师做出最终决策并执行。这能极大降低风险建立信任。4. 关键技术实现与工具链选型有了架构蓝图我们需要选择合适的技术来构建它。这不是一个“全家桶”式的解决方案而是一个需要集成的技术栈。4.1 智能体框架的选择目前并没有电信领域专属的智能体框架但我们可以从通用框架中选取适合的进行二次开发。基于大语言模型LLM的框架如LangChain、LlamaIndex。它们优势在于强大的自然语言理解和生成能力以及丰富的工具调用集成生态。非常适合构建交互层的自然语言接口以及让智能体理解复杂的运维工单描述。你可以用LangChain轻松地将一个CLI封装成Tool并让LLM如GPT-4决定何时调用它。适用场景需要高度灵活的自然语言交互、处理非结构化工单、进行复杂推理和规划的环节。基于强化学习RL的框架如Ray RLlib、Stable-Baselines3。它们优势在于可以通过与环境的持续交互进行策略优化适合解决序列决策问题如动态资源调度、节能策略优化。适用场景网络参数调优如负载均衡阈值、资源分配等目标明确、可模拟、可量化奖励的场景。基于规则与状态机的轻量级框架对于许多确定性强的运维场景一个精心设计的、基于有限状态机FSM或业务流程管理BPMN的“智能体”可能更简单、可靠。可以使用像transitionsPython状态机库或Camunda工作流引擎来实现。适用场景标准化的故障处理流程如“收到告警A - 执行诊断脚本B - 如果结果C成立 - 执行修复动作D”。在实际系统中往往是混合模式。用基于LLM的Agent作为“总指挥”和对外接口处理非结构化任务和复杂规划用基于规则或RL的Agent作为“领域专家”执行具体、高频、确定性的操作。4.2 工具抽象层的实现以MCP为例实现MCP Server来封装核心网工具是打通智能体与网络资源的关键。示例将一个查询用户会话状态的REST API封装为MCP Tool假设我们有一个华为核心网的北向APIGET /api/v1/subscriber/{imsi}/session。创建MCP Server可以使用Python的mcpSDK。# mcp_server.py from mcp.server import Server, NotificationOptions from mcp.server.models import TextContent import httpx app Server(core-network-tools) app.list_tools() async def handle_list_tools(): # 声明可用的工具 return [ { name: get_subscriber_session, description: 根据IMSI查询用户在核心网中的会话状态信息包括连接的DNN、UPF地址、PDU会话ID等。, inputSchema: { type: object, properties: { imsi: {type: string, description: 国际移动用户识别码} }, required: [imsi] } } ]实现工具调用函数app.call_tool() async def handle_call_tool(name: str, arguments: dict): if name get_subscriber_session: imsi arguments.get(imsi) if not imsi: raise ValueError(IMSI参数为空) # 这里是实际的网络调用注意加入重试、超时、认证等生产级代码 async with httpx.AsyncClient(timeout30.0) as client: # 假设已有认证机制 headers {Authorization: Bearer YOUR_TOKEN} resp await client.get( fhttps://core-nms.example.com/api/v1/subscriber/{imsi}/session, headersheaders ) resp.raise_for_status() session_data resp.json() # 将API返回结果转换为自然语言描述或结构化数据供智能体理解 formatted_output f用户{imsi}当前会话状态{session_data.get(state)}。连接至DNN{session_data.get(dnn)}服务UPF地址{session_data.get(upf_address)}。 return [TextContent(typetext, textformatted_output)] raise NotImplementedError(f未知工具: {name})运行Server这个MCP Server可以作为一个独立的微服务部署。智能体框架如LangChain通过MCP Client连接到此Server就能动态发现并调用get_subscriber_session这个工具。对于CLI工具可以使用paramiko或pexpect库在MCP Server中封装SSH命令执行对于数据库可以封装SQL查询。核心思想是统一入口、声明式描述、标准化调用。4.3 网络上下文感知的实现智能体做出正确决策的前提是充分了解网络状态。这需要构建一个实时或近实时的“网络数字孪生”或“上下文感知层”。数据源集成遥测数据通过gNMI/gRPC从网元订阅关键性能指标KPI和配置状态。日志流收集网元、基础设施的日志通过Fluentd/Logstash接入用于异常检测和事件关联。告警事件从网管平台如Prometheus Alertmanager接收告警。业务与拓扑数据从OSS或CMDB获取网络拓扑、切片信息、用户订阅数据。上下文建模将上述多源数据融合构建一个统一的数据模型。例如可以用一个图数据库如Neo4j来存储“网元-链路-切片-用户”之间的关系用时间序列数据库如InfluxDB存储性能指标。智能体可以通过查询这个融合后的模型快速获得“与UPF-X相连的所有AMF节点当前负载”这样的复合上下文。变化感知与通知上下文感知层需要能主动将重要状态变化如某链路中断、某网元CPU超过阈值推送给相关的智能体触发其进行诊断或调整。这可以通过消息队列如Kafka实现。5. 典型运维场景的代理化实践让我们通过两个具体场景看看上述技术如何落地。5.1 场景一基于自然语言的跨域故障排查传统方式用户投诉5G上网慢。运维人员需要1. 登录网管系统查用户所在基站和核心网信息2. 登录核心网系统查该用户的PDU会话和UPF信息3. 登录传输网管查相关链路质量4. 登录服务器平台查UPF的VM性能。需要在多个系统间反复切换、关联查询。代理化控制实现运维人员在聊天窗口输入“帮我排查一下IMSI为460001234567890的用户为什么上网慢。”自然语言交互Agent基于LLM理解该请求将其转化为结构化任务目标{action: diagnose_user_experience, imsi: 460001234567890, symptom: slow_internet}。流程协调Agent收到目标启动一个诊断工作流。它首先调用诊断专家Agent。诊断专家Agent规划排查步骤步骤1调用工具get_subscriber_session(imsi)获取用户当前连接的DNN、UPF、AMF。步骤2并发调用工具query_upf_performance(upf_id)、query_gnb_quality(gnb_id)、query_transport_link(src, dst)分别获取UPF性能、基站无线质量和传输链路质量。步骤3分析返回数据。发现UPF CPU使用率达85%且其到Internet出口的链路时延突增。诊断专家Agent将分析结果“根因可能是UPF-X负载过高及出口链路拥塞”连同证据数据返回给流程协调Agent。流程协调Agent可以生成一份包含数据截图和根因分析的自然语言报告直接回复给运维人员。或者在更自主的模式下它可以进一步启动一个优化执行Agent尝试执行“将部分会话迁移至UPF-Y”或“调整该链路的QoS策略”等动作需经审批或符合预设策略。5.2 场景二网络切片资源的动态弹性伸缩传统方式根据历史流量模型为eMBB增强移动宽带切片在忙时和闲时配置固定的资源配额。无法应对突发流量或者造成资源闲置。代理化控制实现监控Agent持续订阅切片级别的KPI如用户数、吞吐量、时延。当检测到“切片A的吞吐量在5分钟内持续超过阈值的80%”且“用户数仍在增长”时监控Agent向切片资源管理Agent发送一个事件。切片资源管理Agent的目标是“保障切片A的SLA时延20ms丢包率0.001%”。它根据当前状态和预测模型可以是简单的线性预测也可以是训练好的ML模型进行规划。规划出的动作可能是scale_up_slice_a_compute(additional_vCPU4, additional_memory8GB)。这个动作对应一个工具。切片资源管理Agent调用该工具。工具的具体实现可能是通过云平台的API如OpenStack Nova为承载该切片UPF的虚拟机扩容或者通过NFVO网络功能虚拟化编排器的接口触发一个VNF虚拟化网络功能的扩容工作流。扩容完成后监控Agent继续观察KPI。如果流量下降资源管理Agent在满足SLA的前提下可能规划缩容动作以节省资源。这个场景中智能体实现了从“监测”到“分析”到“决策”再到“执行”的闭环并且这个策略可以通过强化学习不断优化比如学习在流量即将上涨前提前扩容实现更平滑的资源调整。6. 实施路径、挑战与避坑指南将代理化控制从概念推向生产需要一个循序渐进的务实路径。6.1 分阶段实施建议阶段一工具化与接口标准化1-3个月目标为最常用、最稳定的运维操作创建MCP工具。行动选取2-3个高频、低风险的查询类操作如“查用户状态”、“查网元健康度”开发对应的MCP Server。同时开始统一和规范内部API的设计。产出一个可用的工具库和初步的MCP使用经验。阶段二辅助诊断与报告生成3-6个月目标构建能辅助人类进行故障排查的智能体。行动基于LLM框架如LangChain构建一个诊断助手Agent。它能够理解自然语言问询调用阶段一创建的工具整合信息生成初步的诊断报告。此阶段保持“只读”不执行任何写操作。产出一个能回答“XX用户现在什么状态”“XX基站下用户感知怎么样”等问题的聊天机器人提升一线运维效率。阶段三闭环控制与策略优化6-12个月以上目标在特定、边界清晰的场景实现闭环自主控制。行动选择一个SLA明确、影响范围可控的场景如“互联网切片出口链路负载均衡”。构建一个具备规划-执行能力的Agent允许其在预设策略范围内如“链路利用率超过70%则触发调整”自动执行负载切换动作。必须配备完善的监控、审批或事后复核和回滚机制。产出一个或多个单点场景的自动化闭环验证代理化控制的价值和风险管控能力。6.2 主要挑战与应对策略工具可靠性网络API/CLI本身可能不稳定。智能体必须要有强大的错误处理和重试机制。在工具定义中就要明确可能出现的错误码和语义。智能体的规划模块需要能处理工具调用失败的情况并尝试备用方案。状态一致性网络状态瞬息万变。智能体基于t时刻的状态做出决策到t1时刻执行时状态可能已变。需要设计乐观锁、预检查、补偿事务等机制。例如在执行配置修改前再次快速确认相关网元状态是否与决策时一致。幻觉与错误决策基于LLM的智能体可能“胡言乱语”或做出危险的工具调用规划。必须通过以下方式约束严格的工具权限控制。输出格式强制解析要求LLM的思考过程和最终输出必须符合预定义的结构化格式如JSON Schema便于程序校验。关键操作二次确认对于高风险操作设计必须由另一个“审核Agent”或人类进行复核的流程。性能与规模每个工具调用都有网络开销复杂的规划推理也耗时。需要对智能体的决策进行缓存对工具调用结果进行缓存并考虑将多个细粒度工具聚合成粗粒度工具以减少交互次数。6.3 实操心得与避坑指南从“只读”开始绝对不要一开始就赋予智能体“写”权限。这是用鲜血换来的教训。先让智能体在查询、诊断、报告生成上证明其价值、稳定性和准确性建立团队信任。工具设计要“小而专”不要“大而全”。一个工具最好只做一件事并且有清晰的输入输出。例如不要设计一个handle_user_complaint的万能工具而是拆分成locate_user、check_session_quality、analyze_radio_conditions等多个独立工具。这有利于智能体规划也便于测试和维护。为智能体建立完整的“操作日志”和“可解释性”记录。不仅要记录它调用了什么工具、参数是什么、结果是什么还要尽可能记录它做出该决策的“思考过程”例如LLM的推理链。当出现问题时这是最重要的排查依据。建立“红队”测试机制。定期组织团队模拟各种异常场景和恶意指令对智能体系统进行“攻击”测试检验其安全边界和异常处理能力是否牢固。文化变革与技术变革同等重要。运维团队需要从“操作执行者”转变为“策略制定者和监督者”。要让大家理解智能体是来放大他们能力的工具而不是取代他们的角色。早期就让运维专家深度参与工具设计和场景定义他们的经验是无价的。代理化控制不是一蹴而就的银弹而是一个将人类专家经验、标准化工具和AI推理能力逐步融合的漫长旅程。它始于一个简单的MCP Server成长于一个可靠的诊断助手最终可能在无数个精心设计的闭环场景中悄然改变我们运维移动核心网的方式。这条路充满挑战但回头看每一次让系统更自动、更智能的尝试都让网络更稳定也让运维者能更专注于那些真正需要创造力和战略思考的高价值问题。
