DevOps 与 SRE 智能体

诊断与修复是两个产品，不是一个。

本能是"一个修故障的智能体"。把它拆开。诊断——关联日志、指标、追踪、近期部署；定位故障；提出假设——高价值、低风险，正是智能体闪光之处：它不知疲倦地交叉比对那些疲惫的值班人在凌晨三点会漏掉的信号。修复——重启、扩缩、回滚、排空、改配置——正是一个错误动作就是下一起事故之处。SRE 智能体的多数价值仅靠诊断就能拿到。先上诊断智能体；把修复当作一个独立、靠后、设关的产品，而不是你在同一循环上打开的功能开关。

只读不是受限版本；它是可信版本。

正确的默认是一个全部工具集都是观察的智能体：查指标、跟日志、描述资源、读部署历史。只读不是一个你要升级摆脱的残废模式——它是让智能体能无人值守运行、却没有引发事故可信路径的配置。窄窄地、靠后地挣得写权限，逐动作、带限制，绝不作为一揽子授予。

# default toolset is observation-only; writes are a separate, gated grant
tools = [metrics_query, logs_tail, k8s_describe, deploy_history]
if mode == "remediate" and approved(action, blast_radius):
    tools += [scoped_rollback, scoped_restart]   # bounded, audited

爆炸半径是工具的属性，在事故前就界定。

如果修复在范围内，限制必须住在工具里，不在提示里。一个能重启任意服务的 restart_service 工具是无界的；一个限定到单个命名空间、每窗口限速 N 次动作、并拒绝在维护/严重度上下文之外做变更的，才是有界的。一个自主动作的爆炸半径，是在你写工具签名时决定的，不是在智能体于事故压力下调用它时。给每个写工具配一个恢复路径也遵守的 fail-closed 熔断，与任何生产智能体一致。

运维手册变成工具，不是模型再解读的散文。

一个读 wiki 运维手册并即兴步骤的智能体，终将即兴出错。高杠杆的动作是把每份运维手册编码成一个参数化、经测试的工具——drain_node(node, reason)、rollback_release(service, to_version)——其前置条件、试运行与事后检查都烤进去。模型的工作是从一个审定库中选择并参数化正确的运维手册，而不是现场撰写运维流程。运维手册即工具是可评审、可测试、可限速的；运维手册即散文是一个模型可以随意误读的建议。

变更管控依然适用——操作者是模型并不改变什么。

一个自主的生产变更仍是生产变更：它走与人相同的管控，因为审计、回滚与问责要求并不在乎是谁发起的。SRE 智能体的评估信号与运维护栏：

• 诊断准确率——在一组重放的过往事故库上，智能体是否定位到真正的根因，对照实际复盘评分。
• 修复安全性——在同样的事故上，它提议的动作会有帮助还是有害；有害的"修复"被赋予灾难级权重。
• 可审计性——每个动作都带谁/做了什么/为什么，链接到触发信号，且可逆或有经测试的补偿动作。
• 变更窗口遵守——破坏性动作在事故/维护上下文外拒绝执行，冻结窗口被遵守，高爆炸动作仍寻呼一个人。

DevOps 与 SRE 清单。

• 诊断与修复是独立产品；先上诊断，修复靠后并设关。
• 默认工具集只观察；写权限逐动作、限定范围、限速、且需挣得。
• 爆炸半径在工具签名里界定，不在提示里；配恢复路径也遵守的 fail-closed 熔断。
• 运维手册是从审定库中选出的参数化、经测试的工具——绝非模型再解读的散文。
• 自主变更走与人相同的变更管控、审计与回滚要求。
• 高爆炸或窗口外动作仍寻呼人；冻结窗口在工具里强制执行。
• 评估是重放过往事故，按诊断准确率与修复安全性评分，有害修复赋灾难级权重。

诚实的取舍：完全修复自主既是梦想也是陷阱——那个能在数秒内结束一次事故的智能体，正是那个能在数秒内引发一次事故的智能体，所以你买到速度的代价，是一个你必须在事故前而非事故中界定的爆炸半径。