1. 从“工具调用”到“行动执行”移动核心网智能化的新范式最近在跟几个做运营商网络自动化的朋友聊天大家普遍有个感觉现在的网络运维尤其是移动核心网这块越来越像在玩一个“打地鼠”游戏。告警来了脚本跑一下配置要改手动点一点策略要调又是一堆命令行。工具是不少自动化脚本也攒了一堆但总觉得是“散装”的工具和工具之间是孤岛动作和动作之间没逻辑。这背后反映的其实是传统“工具使用”模式的局限性——它把人的智能固化成了一个个孤立的、被动的操作指令。而“Tool Use as Action: Towards Agentic Control in Mobile Core Networks”这个标题恰好点出了破局的关键。它不再把“工具使用”看作一个独立事件而是将其升维为“行动执行”并最终导向“智能体控制”。这不仅仅是语义上的变化更是一种架构思想和控制模式的根本性转变。简单来说过去是我们告诉工具“做什么”现在是智能体理解“为什么做”并自主规划“如何做”。这个转变的核心驱动力正是近期在开发者社区和网络自动化领域被热议的MCP以及与之相关的A2A架构。如果你关注过cursor、vscode的AI插件生态或者尝试过dify、codebuddy这类AI应用开发平台大概率已经接触过MCP。MCP即 Model Context Protocol它本质上定义了一套标准化的协议让大模型能够安全、结构化地“感知”和“操作”外部工具、数据源乃至整个系统。而A2A在这里可以理解为 Agent-to-Agent 或 Action-to-Action它描述了在MCP框架下智能体之间如何协同动作如何编排以完成更复杂的任务。把这两者放到移动核心网这个复杂系统里想象空间就打开了。我们不再需要为每一个网元、每一类操作编写特定的适配脚本而是通过MCP Server将核心网的各种能力——比如查询用户会话状态、动态调整QoS策略、触发网络切片重配置——封装成标准的“工具”。然后一个具备网络领域知识的智能体能够根据高层目标如“保障VIP用户体验”、“应对突发流量高峰”自主理解这些工具并规划、执行一系列有序的“行动”。这就是标题所指向的“Agentic Control”——一种由智能体主导的、目标驱动的、具备一定自主性的网络控制方式。这篇文章我将结合对MCP协议、A2A交互模式的理解以及移动核心网运维的实际场景深入拆解“工具即行动”这一理念如何落地。我们会探讨其背后的技术架构、核心组件、在5G核心网中的具体应用案例以及开发实践中必然会遇到的挑战比如mcp server的稳定性、a2a协议的协同逻辑、技能与上下文的权衡等。无论你是网络工程师想了解AI如何改变运维还是开发者想探索MCP在垂直领域的应用相信都能从中获得可直接参考的实操思路。2. 核心概念解耦Tool, Action, Agentic Control 与 MCP/A2A 的关系要理解整个范式首先得把几个关键概念掰扯清楚。它们听起来有点抽象但用网络运维的日常一对照就非常具体了。2.1 Tool被封装的能力端点在传统脚本或自动化工具里一个“工具”可能就是一个Python脚本、一个Ansible Playbook或者一个REST API接口。它的特点是输入明确输出固定功能单一。例如一个名为get_ue_session的工具输入是用户IMSI输出是该用户当前的会话信息JSON。在MCP范式下“工具”的定义被标准化和丰富了。一个MCP Tool 不仅包含名称、描述、输入参数模式更重要的是它通过MCP Server暴露给智能体。智能体不需要知道这个工具背后是调用了一段C代码、查询了一个数据库还是通过CORBA接口与网元通信。它只需要按照MCP协议定义的格式去“调用”它。这就好比给智能体提供了一个标准化的“能力插座”任何符合MCP规范的“能力插头”都可以即插即用。2.2 Action目标导向的行为序列这是“Tool Use as Action”的核心升华点。一次单纯的“工具调用”不是一个完整的“行动”。行动是具有意图和上下文的。例如智能体的目标是“解决用户XXX的语音通话质差问题”。这本身就是一个行动意图。为了实现这个意图智能体可能需要规划并执行一个行动序列行动A诊断调用工具get_ue_measurement获取该用户的无线测量报告。行动B分析根据报告数据判断问题可能出在无线侧信号弱还是核心网侧承载建立失败。行动C执行如果判断为核心网问题则调用工具modify_qos_policy尝试调整该用户的QoS等级如果是无线问题则调用工具generate_trouble_ticket向无线部门派发工单。行动D验证再次调用get_ue_measurement或get_ue_session验证行动效果。你看这里的每一个步骤都可能涉及一次或多次工具调用但这些调用被一个更高的“目标”所串联前后步骤之间有逻辑依赖和状态传递。这就是“行动”和“工具调用”的本质区别行动是智能的、有状态的、目标驱动的而工具调用是机械的、无状态的、功能驱动的。2.3 Agentic Control智能体主导的控制回路“Agentic”强调自主性和主动性。在移动核心网中实现Agentic Control意味着控制回路的主体从人变成了智能体。传统的OMC操作维护中心是人看告警、人做决策、人执行操作。而Agentic Control是智能体实时监控网络KPI和事件流自动识别异常模式如某个区域流量异常激增自主决策采取何种缓解措施如触发扩容或流量疏导并自动通过MCP工具执行一系列行动最后闭环验证。这个过程中智能体需要具备感知通过MCP连接到各种数据源网管、信令跟踪、性能计数器。规划基于领域知识网络运维规则、SLA要求分解目标生成行动序列。执行通过MCP调用各类执行工具。学习根据行动结果反馈优化未来的决策和规划。这构成了一个完整的“感知-决策-执行-学习”闭环。2.4 MCP与A2A实现Agentic Control的“骨架”与“神经”现在我们把MCP和A2A放进来。可以把MCP看作是实现上述愿景的“骨架”或“基础协议”。它解决了智能体与五花八门的网络系统之间“如何连接、如何对话”的问题。MCP Server部署在核心网运维侧将每一个网络操作如查询、配置、诊断封装成一个标准的MCP Tool。一个复杂的核心网可能由多个MCP Server组成分别对应网管、策略控制、用户数据等不同子系统。MCP Client集成在智能体内部。智能体通过MCP Client发现可用的Tools并按照协议发起调用。而A2A则是运行在这个骨架上的“神经”或“协同逻辑”。它定义了在一个复杂任务中多个智能体或一个智能体的多个子模块之间如何协作。例如垂直协同编排式A2A一个“总指挥”智能体接收高层任务“准备春节话务保障”它将其分解为子任务并“雇佣”或“调用”多个具备专项技能的智能体如“容量评估智能体”、“应急预案智能体”、“配置下发智能体”来共同完成。这些智能体之间的任务派发、结果汇总、异常协调就需要一套A2A协议来规范。水平协同协作式A2A多个同级的智能体如分别负责“接入网”、“核心网”、“传输网”的智能体在监控到跨域故障时需要相互通信、共享上下文、协同定位根因和制定修复方案。目前像openclaw-a2a-gateway这类项目就是在探索和实现这样的A2A交互网关。它需要解决的核心问题包括智能体间的通信协议是直接用MCP扩展还是定义新的A2A消息格式、上下文共享机制、任务编排与依赖管理、以及冲突消解策略。注意在具体技术选型时你会遇到skills和mcp的区别讨论。一个常见的理解是Skill更像是智能体内部固化的一种“能力”或“子程序”它可能调用多个MCP工具来完成一个特定子目标比如“诊断接入失败”这个Skill内部会按顺序调用信令跟踪、用户状态查询等多个工具。而MCP Tool则是更原子化、更通用的外部能力接口。智能体通过组合不同的Skills和Tools来实现复杂行动。因此在架构设计时需要仔细规划哪些能力应该沉淀为平台级的MCP Tool哪些应该实现为智能体内部的Skill这直接影响到系统的灵活性、复用性和智能体的决策负担。3. 移动核心网中的MCP Server实战封装网络能力理论说得再多不如看一个实际例子。我们以5G核心网中常见的“会话管理”功能为例看看如何为其构建一个MCP Server将网络操作暴露给智能体。3.1 场景定义与工具设计假设我们有一个AMF接入和移动管理功能和SMF会话管理功能的北向接口能够提供查询和修改能力。我们的目标是构建一个session-mcp-server让智能体可以管理用户会话。首先我们需要设计这个Server要提供哪些Tools。这取决于我们想让智能体具备哪些“行动”能力。例如list_ues列出当前在线的用户列表可用于监控或抽样分析。get_ue_session_detail获取指定用户的详细会话信息包括PDU会话、QoS流、UPF地址等。modify_session_qos修改指定会话的QoS参数如保障带宽、优先级。release_session释放拆除指定用户的会话用于强制用户重附着或故障隔离。每个Tool都需要在MCP Server中明确定义其输入参数的模式JSON Schema和自然语言描述。描述至关重要因为智能体主要靠这些描述来理解工具的用途。例如对于modify_session_qos工具的描述可能是“修改一个已建立的PDU会话的QoS规则。需要提供用户的SUPI或GPSI以及要修改的QoS流ID和新的QoS参数如5QI、ARP、GFBR、MFBR等。”3.2 技术实现选型与示例MCP Server可以用多种语言实现Python因其在AI和运维领域的生态而成为热门选择。我们可以使用mcp这个Python SDK来快速搭建。下面是一个极度简化的概念性代码示例展示Server的结构# 文件名session_mcp_server.py import asyncio from mcp.server import Server, NotificationOptions from mcp.server.models import InitializationOptions import pydantic from typing import Any, List # 假设我们有一个模拟的5G核心网客户端库 from my_5g_core_client import CoreNetworkClient class SessionQoSModificationRequest(pydantic.BaseModel): 修改会话QoS的请求参数 supi: str pdu_session_id: int qos_flow_id: int new_5qi: int new_gfbr_ul: str # 上行保障比特率如 “100 Mbps” new_gfbr_dl: str # 下行保障比特率 class SessionMCPServer: def __init__(self): self.server Server(session-management-server) self.core_client CoreNetworkClient() # 连接真实核心网的客户端 self.setup_tools() def setup_tools(self): self.server.list_tools() async def handle_list_tools() - List[Any]: # 返回此Server提供的所有工具列表 return [ { name: get_ue_session_detail, description: 根据SUPI获取用户的详细PDU会话信息包括状态、IP地址、QoS流等。, inputSchema: { type: object, properties: { supi: {type: string, description: 用户的SUPI标识} }, required: [supi] } }, { name: modify_session_qos, description: 修改指定PDU会话中特定QoS流的服务质量参数。, inputSchema: { $ref: #/definitions/SessionQoSModificationRequest } }, # ... 其他工具定义 ] self.server.call_tool() async def handle_call_tool(name: str, arguments: dict) - dict: # 根据工具名分发处理 if name get_ue_session_detail: supi arguments.get(supi) session_info await self.core_client.get_session_detail(supi) return {content: [{type: text, text: json.dumps(session_info, indent2)}]} elif name modify_session_qos: request SessionQoSModificationRequest(**arguments) # 调用底层网络接口执行修改 result await self.core_client.modify_qos( request.supi, request.pdu_session_id, request.qos_flow_id, {5qi: request.new_5qi, gfbr: {ul: request.new_gfbr_ul, dl: request.new_gfbr_dl}} ) return {content: [{type: text, text: fQoS修改请求已提交结果{result}}]} else: raise ValueError(f未知工具: {name}) async def run(self): async with self.server.run_over_stdio() as (read_stream, write_stream): # 这里简化了传输层实际可能是stdio、HTTP或WebSocket await self.server._run(read_stream, write_stream, InitializationOptions()) if __name__ __main__: server SessionMCPServer() asyncio.run(server.run())这个Server启动后智能体通过MCP Client连接就可以发现get_ue_session_detail和modify_session_qos这两个工具并按照定义的Schema来调用它们。3.3 部署、安全与性能考量在实际部署中我们需要考虑更多传输协议MCP支持stdio、HTTP、SSE等多种方式。对于网络运维场景通常通过HTTP/SSE部署在内部网络便于管理和安全控制。你需要根据mcp的各种传输协议特性进行选择例如对实时性要求高的监控场景可能更适合SSE。认证与授权MCP Server是网络操作的入口必须加固。需要在传输层如mTLS和应用层如API Token、OAuth实施严格的认证。同时基于角色的访问控制RBAC也必不可少确保智能体只能调用其被授权的工具。错误处理与重试网络操作可能失败网元不可达、资源不足。MCP Server需要返回结构化的错误信息并且智能体端或A2A编排层需要设计重试、回退或升级告警的策略。性能与超时像mcp client for \codex_apps timed out after 30 seconds 这样的错误提示我们必须为每个工具设置合理的超时时间。对于长时间运行的操作如全网配置备份应考虑设计为异步工具先返回一个任务ID再提供另一个查询任务状态的工具。4. 智能体端从目标到行动序列的规划与执行有了标准化的能力接口MCP Tools智能体端的工作就是理解目标、规划行动、执行并学习。这部分是“Agentic”智能的集中体现。4.1 目标理解与任务分解智能体接收的可能是自然语言指令如“请优化小区A的拥塞状况”。它首先需要利用其大模型能力结合网络领域知识可以通过RAG从运维手册、案例库中获取将这个模糊目标分解为具体的、可操作的任务。分解过程可能如下澄清与确认什么是“优化”指标是什么可能是降低PRB利用率、提升用户速率。时间范围是立即生效还是夜间执行。诊断先行要优化先得知道现状。因此生成第一个子任务“诊断小区A的当前负载和用户分布”。方案生成根据诊断结果结合知识库中的优化策略如负载均衡、参数调整、容量扩容生成候选行动方案。方案评估与选择评估每个方案的影响范围、风险、实施复杂度选择一个最优或折中的方案。生成行动序列将选定的方案转化为具体的、有序的MCP工具调用序列。4.2 行动规划与上下文管理规划出的行动序列不是静态的而是动态的、依赖上下文的。智能体需要维护一个“工作记忆”或“上下文”。例如在诊断阶段调用get_cell_load工具返回了高负载信息这个信息上下文会影响后续“选择优化方案”的决策。在MCP交互中智能体需要巧妙地将这些上下文信息作为后续工具调用的输入参数或者作为与大模型进行下一轮推理的提示词的一部分。这里就涉及到skills rules mcp 上下文占用情况的权衡。如果智能体把所有中间结果都塞进与大模型的对话上下文很快就会触及token长度限制。合理的做法是将结构化的、关键的结果如小区ID、用户列表、关键KPI值提炼出来作为上下文保留。将大量的原始数据如完整的信令跟踪文件存储到外部缓存如向量数据库只将其索引或摘要放入上下文。设计清晰的Skill边界每个Skill负责处理一个子问题并输出结构化的结论供上层智能体或下一个Skill使用。4.3 执行、监控与闭环学习行动序列开始执行后智能体并非一发了之。它需要监控执行状态对于每个工具调用监控其返回结果成功、失败、超时。对于失败能根据错误码进行初步分类网络错误、参数错误、权限错误等。处理异常与重试设计重试逻辑如指数退避。对于某些“柔性”失败如资源暂时不可用可以重试对于“硬性”失败如参数非法则应停止当前序列并可能触发人工干预或更高阶的修复流程。验证行动效果行动序列执行完毕后必须调用验证工具如再次get_cell_load来确认优化目标是否达成。如果没有需要分析原因是行动本身无效还是出现了新的问题从而可能触发新一轮的规划-执行循环。经验沉淀将本次任务从目标到最终结果的全链路信息决策依据、采取的行动、实际效果记录下来形成可检索的案例。这可以通过RAG存入知识库用于未来相似任务的决策支持实现闭环学习。4.4 一个简化的智能体决策循环伪代码# 伪代码展示智能体核心循环 class NetworkAgent: def __init__(self, mcp_clients, knowledge_base): self.mcp_clients mcp_clients # 连接多个MCP Server的客户端 self.kb knowledge_base self.context {} # 当前任务上下文 async def solve_problem(self, goal: str): # 步骤1理解与分解目标 sub_tasks await self.llm_planning(goal, self.context, self.kb) for task in sub_tasks: # 步骤2为每个子任务选择或组合工具 tool_sequence await self.select_tools(task, self.context) for tool_call in tool_sequence: # 步骤3执行工具调用 mcp_server_name tool_call[server] tool_name tool_call[name] arguments self._build_arguments(tool_call, self.context) try: result await self.mcp_clients[mcp_server_name].call_tool(tool_name, arguments) # 步骤4处理结果更新上下文 self.context.update(self._extract_key_info(result)) # 判断是否成功是否需要重试或调整计划 if not self._is_success(result): recovery_plan await self.llm_replan(self.context) # 根据新的恢复计划调整后续步骤 break except TimeoutError as e: # 处理超时例如记录日志、尝试备用工具或上报 self._handle_timeout(tool_call, e) except Exception as e: # 处理其他异常 self._handle_error(tool_call, e) # 步骤5子任务完成后进行阶段性验证 verification_passed await self.verify_subtask(task, self.context) if not verification_passed: # 验证失败可能需要重新规划该任务或整个目标 return await self.solve_problem(f修正任务{task}因为验证失败。上下文{self.context}) # 所有子任务完成进行最终验证和总结 final_result await self.final_verification(goal, self.context) await self.record_experience(goal, self.context, final_result) return final_result5. 挑战、陷阱与最佳实践来自前线的经验将MCP和智能体引入移动核心网这样的生产系统绝非易事。下面分享一些实践中必然会遇到的挑战和对应的思考。5.1 稳定性与可靠性网络操作无小事挑战mcp server崩溃、网络抖动导致mcp error -32000: connection closed、工具调用超时如前文提到的30秒超时。在生产网任何不稳定都可能导致自动化动作失败甚至引发二次故障。实践服务高可用MCP Server必须实现多实例部署和负载均衡具备健康检查和自动故障转移能力。可以考虑使用Kubernetes部署并配置就绪和存活探针。客户端重试与熔断智能体端的MCP Client必须实现健壮的重试机制如带抖动的指数退避和熔断器模式。当某个Server连续失败时应暂时熔断对其的调用并尝试备用Server或上报告警。操作幂等性与补偿设计工具时尽可能保证其幂等性多次调用产生相同效果。对于非幂等操作智能体需要记录操作流水并在失败时能执行补偿操作Compensation即“回滚”。例如修改QoS失败后应能尝试恢复到修改前的状态。5.2 安全与权限守住最后一道防线挑战智能体被恶意提示词诱导执行危险操作如release_session释放所有用户会话、权限过度集中、操作审计缺失。实践最小权限原则为每个智能体或每个任务会话分配最小必要的MCP Tool调用权限。例如一个只负责监控的智能体不应该拥有modify_session_qos的权限。操作确认与审批流对于高风险操作如删除配置、重启网元不能完全自动化。MCP Server可以在工具实现中加入“模拟执行”和“真实执行”两种模式。智能体先请求模拟执行生成影响报告然后通过人工审批或另一套安全令牌机制来触发真实执行。类似dify访问mcp返回503的错误有时也可能是服务端出于安全策略的主动拒绝需要清晰的错误信息。完整的审计日志所有MCP工具调用无论成功失败都必须记录详尽的审计日志包括调用者身份、时间、参数、结果。这是事后追溯和责任认定的基础。5.3 性能与规模当工具数量爆炸时挑战一个核心网可能有成百上千个可操作点。如果每个点都对应一个MCP Tool那么智能体在规划时如何从海量工具中快速找到合适的skills rules mcp 上下文占用情况也会成为瓶颈。实践工具分层与聚合不要暴露过于原子的操作。例如与其暴露“修改单个网元的一个参数”的工具不如设计“根据KPI趋势自动优化小区群参数”这样的高阶工具。底层原子操作由MCP Server内部的业务逻辑封装。动态工具发现与描述优化MCP Server应支持按类别、功能标签动态发布工具。智能体端可以利用工具的描述description和输入输出Schema通过嵌入向量相似度搜索快速定位相关工具。Skill作为工具导航器将常用的、固定的工具组合模式固化为智能体内部的Skill。这样智能体在规划时优先考虑这些已知的、高效的Skill而不是每次都从零开始组合海量原子工具大大减轻了规划和上下文管理的压力。5.4 可观测性与调试给智能体装上“黑匣子”挑战智能体的决策过程像个黑盒当它执行了一个错误行动时很难快速定位是目标理解错了、规划逻辑有bug还是某个MCP Tool返回了误导性数据。实践全链路追踪为每一个用户请求如“优化小区A”生成一个唯一的Trace ID并贯穿智能体的每一次LLM调用、每一次MCP工具调用、每一次内部决策。使用OpenTelemetry等标准来收集这些追踪数据。决策过程记录记录智能体在关键决策点如目标分解、方案选择的“思考过程”Chain-of-Thought包括它考虑了哪些选项、依据了哪些上下文信息。这对于事后复盘和模型调优至关重要。工具调用监控面板建立实时监控面板可视化展示所有MCP Server的健康状态、工具调用频率、成功率、延迟等指标。这对于发现性能瓶颈和异常模式非常有用。从“工具使用”到“行动执行”最终迈向“智能体控制”是移动核心网乃至整个电信网络运维自动化的必然演进路径。MCP协议为这一演进提供了标准化的“连接器”而A2A协同机制则描绘了多智能体协作的蓝图。然而这条路上最大的障碍可能不是技术而是思维方式和组织流程的转变。在我和团队尝试将这类理念落地的过程中最深的一点体会是不要试图一开始就打造一个全知全能的“超级智能体”。那会陷入复杂性的泥潭。最务实的做法是从一个个具体的、高价值的、边界清晰的“行动”场景开始。例如先实现“自动诊断并修复常见的VoLTE呼叫失败问题”这个单一行动。为此你需要封装相关的诊断工具查询用户状态、获取失败信令封装修复工具重置会话、调整IMS注册参数然后训练或引导智能体学会在特定场景下组合这些工具。这个过程中你会遇到本文提到的所有挑战——工具设计的粒度、智能体规划的可靠性、安全边界的设定。但每解决一个场景你就沉淀了一组可靠的MCP Tools、一个可复用的行动模式Skill、以及一整套运维和保障经验。这些资产会像滚雪球一样逐步构建起你的智能体控制能力。最后关于mcp可以进行智能体编排吗这个问题我的看法是MCP本身主要定义的是智能体与工具之间的接口协议其核心是“让智能体能用工具”。而复杂的、涉及多个智能体协作的“编排”逻辑可能需要在MCP之上通过专门的A2A网关如openclaw-a2a-gateway或编排引擎来实现。这个引擎负责任务的分解、派发、依赖管理和结果汇总。因此未来的架构很可能是“编排层 智能体层 MCP工具层”的三层结构各自专注通过标准协议协同。这条路很长但起点或许就是从今天开始为你网络中的一个常用操作编写第一个MCP Server开始。