管控Agentic云运维冲突，港大×微软这套系统级底座夯爆了！

现代云基础设施早就不是一个人管一台机器的时代了。

计算、网络、安全、监控各自负责不同模块，、命令行、控制台，再加上各种大模型驱动的智能运维 Agent，全部一起接入同一套云管理栈。

人类运维和 AI 会话同时下发操作，最终都落在租户共享的底层云资源上。

这套体系效率很高，但也埋下了明显矛盾：每个会话只能看到自己的局部意图，却无法感知其他会话的并发修改；现有的并发控制要么太粗，要么存在盲区；AI Agent 依赖的“观测-规划-执行”闭环，也因为脏读、模糊报错和状态漂移，变得很不可靠。

行业现在更希望靠大模型“更聪明”地推理冲突，但这条路其实走不通。模型拿到的反馈本身就不完整、不清晰，靠概率推理只会把不确定性放大。真正需要的，是在云 API 上层直接搭一套系统级的协调底座，把会话隔离的局部视图和语义感知的并发约束，做成底层抽象，而不是事后靠人工规范或模型去补救。

基于这个思路，香港大学联合微软提出了 。它是一套面向 LLM 驱动云运维智能体的系统级协调底座，将会话隔离和语义协调做成系统本身的能力，让 AI 运维真正做到可控、可并行、可归因。

总耗时 25.55 秒，六条操作全部成功，比全串行缩短了约 22.6%。它能提前识别共享 VNet 上的拓扑冲突并自动排队，同时让完全无关的操作继续并行，既保证正确性，又保留了效率。

01

AI 运维 Agent 总“看花眼”？

问题出在视角没隔离

多个 Agent 同时改云资源时，最容易出问题的是“看不准”。每个会话只知道自己的意图，却看不见别人在做什么；云端返回的报错又模糊，导致脏读、视图漂移，规划直接失真。

要解决这类问题，关键不在让模型更聪明，而在先把观测环境本身理顺。

提出了第一条原则，给每个 Agent 一套真正隔离的局部视图。它根据权限从全局资源图（  ）投影出只属于当前会话的资源图，全局变化会实时同步回来，执行前还会先预检依赖和容量。这样 Agent 看到的始终是干净、最新的状态，跨会话干扰从源头被挡住。

落地时，系统维护两套图：全局图是唯一可信源，记录所有资源、语义关系、配额和锁占用；每个会话则拥有自己的局部投影图。

Agent 发来的操作先在局部图（  ）上检查合法性，通过后再映射成全局增量（  ）去执行；云端结果再双向写回，让所有相关会话的视图同步更新。

这样一来，Agent 规划时不再被脏数据干扰，冲突反馈也变得清晰可归因，观测层的可靠性才真正立得住。

02

云资源一并发就“打架”？

现有锁根本管不住

多 Agent 一起改云资源时，现有并发控制经常失灵：全串行太慢，IaC 并行看不到其他会话，资源级互斥锁又认不出修改父 VNet、抢配额这类语义冲突，工作空间隔离也挡不住跨分区依赖。结果要么效率低，要么频繁报错。

的第二条原则针对这个问题，不能只靠资源 ID 互斥，必须基于操作的语义影响提前拦截冲突。

拓扑生命周期冲突（改 VM 会挡住磁盘挂载、网卡变更）和容量配额冲突（vCPU、IP、挂载槽）都要管起来，而且要在请求真正下发到云厂商 API 之前就判定完，既避免滞后失败，又让无冲突操作继续并行。

具体靠语义事务执行层实现。

每条 API 被封装成语义事务，并配上两套细粒度锁：多粒度锁（MGL）用分层意向锁管拓扑和生命周期冲突，创建 VM 只给父子网加意向锁，不影响其他子网；

托管容量锁（）则为 vCPU、IP、挂载槽建立独立容量桶，先预留再放行。冲突直接拒绝并给出清晰归因，通过才真正转发。

这样既保证正确性，又不会把无关操作一起拖死。

03

性能评估

实验用三个独立 Agent 会话、共六条 Azure API 操作做了对比。

全串行最稳，33.03 秒全部成功，但完全没并行，时间最长；无约束并行最快，只要 18.33 秒，却有一条操作直接撞上 409 冲突失败； 则用了 25.55 秒，六条全部成功，比全串行快了大约 22.6%。

它的关键在于提前识别出两个子网操作共享同一个 VNet，存在拓扑冲突，于是自动让它们排队，同时让完全无关的 C 继续并行。既避开了云端报错，又没有把无关操作一起拖慢。

简单说，它在“全串行太慢”和“盲目并行容易失败”之间，找到了一个既正确又更高效的折中点。

当然，目前只是小规模验证，大规模场景下的表现还有待进一步测试。

04

工程落地：怎么真正用起来？

部署在云用户接口和云厂商 API 之间，作为一层透明中间件。现有的 CLI、IaC、AI Agent 都不用改，直接兼容。

落地时主要做几件事：

先为不同公有云写插件，把各自的资源拓扑、生命周期和配额规则统一进来；

再维护全局资源图和每个会话的局部视图，全局一变就实时同步，保证 Agent 看到的始终是干净状态；

然后把每条 API 变成语义事务，用多粒度锁管拓扑冲突、用容量锁管配额预留，冲突时直接给出清晰归因，方便 Agent 自动重规划。

整个过程只存元数据和锁状态，不存完整资源数据，规划阶段还能并行计算，开销很轻，短期会话用完还会自动回收缓存。

简单说，它不要求你重做现有工具，而是在中间默默补上协调能力，让多 Agent 并发操作变得既安全又高效。

05

之后，

云运维还能往哪走？

解决了多 Agent 并发时的视图隔离和语义冲突问题，但这只是起点。

未来还有几件事值得继续推进。

一是大规模可扩展性，比如把全局图做成分布式分片，再配上插件自动生成工具，让它能撑住成百上千个 Agent 同时工作。

二是给 LLM 智能体做更原生的接口，不再让它们去拼零散的 API，而是直接用“意图优先”的方式对话。

三是用在强化学习训练里，会话视图隔离可以避免不同 Agent 的轨迹互相污染，让训练既更快，也更接近真实云环境。

四是支持多租户、跨团队的安全协同，让不同权限的团队和 Agent 能一起操作共享基础设施，而不用担心互相踩脚。

这些方向如果落地，云运维可能会从“人 + 工具”慢慢变成“人 + 智能体 + 系统协调”的新形态。

真正的挑战，或许不在于 Agent 有多聪明，而在于我们能不能先把底层协调做好。