90天后，我们收回了AI的这三项写入权限

只读模式的MCP服务器运行得很顺利。AI能读取标签、搜索日志、查询成本、遍历拓扑结构，运维人员每次事故能省下数小时。接下来该问的问题也很自然：哪些写入操作也能交给AI？

我们开启了标记修正、日志保留调整、闲置非生产资源停止等低风险的写入权限。大部分保留了下来。但九十天后，三类写入操作被收回，改为"读取并建议"模式。

留下来的写入操作符合"一级信任"标准：影响范围小、可逆性高、决策维度单一。标记修正、日志保留微调、按14天闲置告警停止非生产EC2实例——AI在这些任务上越来越快，运维人员也不再介入常规操作。

被收回的三类操作有个共同特征：AI选对了指标，却选错了动作。每次失败的模式都一样：代理掌握了所有本地数据，却仍缺少一个全局上下文，而这个缺失让动作变成了事故。

失败一：批量安全组编辑与不可见的依赖链

触发事件：代理执行例行清理，移除了11条标记"90天未使用"的规则。其中一条是10.99.0.0/16网段对5432端口的CIDR放行。MCP工具的富化信息显示"该账户无资源匹配此源地址范围"，代理遂删除规则。

三分钟后，另一个账户的合作伙伴集成任务开始失败。10.99.0.0/16是对方账户与我们VPC对等互联的网段。对等连接位于另一个VPC，不在安全组里，也不在安全组的任何富化上下文中。

MCP工具返回的本地数据是正确的——账户A确实没有资源使用该CIDR访问5432端口。但账户B的ETL任务通过对等连接落到这些规则上的事实，既不在安全组元数据里，也不在工具富化信息里，更不在代理的上下文窗口中。

增加更多本地数据解决不了这个问题。我们试过"在富化中包含所有VPC对等连接"，结果让每次安全组查询从200毫秒变成12秒，而且仍然无法捕获跨账户的流量路由意图。全局上下文不在任何单一API的返回里。

失败二：自动扩展组容量调整与成本优化的盲区

代理识别出一个非生产环境的自动扩展组：两周平均CPU利用率12%，按预留实例定价，当前容量2-4实例。建议调整为1-2以节省成本，执行。

两小时后，该环境承接了一次计划外的负载测试。队列深度飙升，消息处理延迟突破SLA。事后复盘：该ASG服务于一个事件驱动的管道，CPU利用率从来不是正确的容量信号——消息处理速率和队列深度才是，但这些指标在ASG的本地富化数据里不存在。

成本优化代理看不到管道架构。它看到闲置容量，看不到该容量是为"偶尔的大批量"而非"稳定的低负载"设计的。正确的指标（队列深度）在另一个服务里，正确的上下文（这是一个事件驱动管道）在任何API响应里都不存在。

失败三：数据库参数组修改与连接池的隐性契约

代理检测到RDS参数组中max_connections设置为1000，而CloudWatch显示峰值连接数从未超过80。建议降至200以释放内存供缓存使用，执行。

应用团队在凌晨被告警唤醒。连接池耗尽，错误率飙升。事后发现：应用层连接池配置为每个实例150连接，8个实例共1200。数据库的1000设置本就是一种软性约束，迫使应用层保持一定连接回收纪律。降至200后，连接池配置与数据库容量之间的隐性契约被打破。

代理看到了正确的利用率数据，却看不到组织层面的运维约定。这个约定从未写入任何基础设施即代码，只存在于运行手册和某位工程师的笔记里。

为什么更多本地上下文不够

三类失败共享一个结构：正确的局部决策，错误的全局结果。安全组规则、ASG容量、数据库参数——每个都是独立管理的资源，每个的本地数据都完整准确，每个的决策都忽略了跨资源边界的隐性依赖。

我们考虑过三种修复路径，全部放弃。

路径A：扩大富化范围。让安全组查询返回整个组织的VPC拓扑，让ASG查询返回上下游管道的指标，让参数组查询返回应用层的连接池配置。这会让MCP工具变成单体数据仓库，延迟爆炸，权限模型崩溃。

路径B：增加人工审批。每次写入操作前弹出确认框。这消灭了AI的速度优势，运维人员重新成为瓶颈——那当初为什么要做自动化？

路径C：让AI"询问更多问题"。在删除安全组规则前，代理应该问"这个CIDR是否可能来自对等连接？"在调整ASG前，应该问"CPU利用率是否是正确的容量信号？"问题在于：代理不知道它不知道什么。问题空间是开放的，而它的上下文窗口是有限的。

政策感知MCP的下一步：显式能力分层

我们现在的框架把操作分为"读取"和"写入"。这不够。需要四层：

第0层：读取——AI可以自主执行，无需人工介入。标签查询、日志搜索、成本估算。

第1层：写入-局部闭环——AI可以自主执行，因为成功标准完全由工具返回的数据定义。标记修正、日志保留调整、按明确闲置规则停止非生产实例。

第2层：写入-全局依赖——AI生成建议并附带置信度评分，人工在5分钟内审批或拒绝。安全组规则清理、ASG容量调整、跨区域资源迁移。

第3层：写入-组织契约——AI生成建议并标记为需要人工调研，不承诺时间。数据库参数修改、涉及多个团队SLA的变更、任何触及"我们过去如何约定"的操作。

关键洞察：分层不是由技术复杂度决定，而是由隐性知识的位置决定。第1层操作的所有相关上下文都在API响应里。第2层操作需要跨越资源边界的信息。第3层操作需要跨越组织边界的信息——而组织从不把全部约定写入代码。

我们正在把这三类被收回的操作重新实现为第2层建议模式。代理仍然做数据收集和初步分析，但输出是一份结构化的变更提案，附带它知道自己缺少什么的明确声明："此安全组规则清理未分析VPC对等连接，请确认无跨账户依赖。"

这不是退步。这是承认AI的边界——不是计算能力的边界，而是组织知识的边界。那些知识分布在人、文档、历史事故和未言明的约定里。在它们被显式编码之前，AI只能读取并建议，不能擅自写入。