SRE Agent 设计笔记 05：声明式约束与集群分级

发表于 2026-04-15 分类于 SRE Agent 设计笔记

状态：大纲

核心论点

约束 agent 行为有两条路径：命令式（规定步骤顺序）和声明式（定义终态条件）。命令式约束容易被绕过，声明式约束让 agent 自己找路径收敛。K8s 的核心设计哲学（Desired State YAML > kubectl imperative）在 agent 约束设计中同样适用。集群分级是声明式约束的实例：按 failure cost 分级，hook 根据等级做语义门控。

大纲

1. 命令式约束的局限

「coding 之后必须 compile，compile 之后必须 test」
像 checklist 一样规定步骤
Agent 和人类一样会找 workaround：如果目标是「完成任务」而约束是过程性的，它有动机跳过对结果无贡献的步骤
更根本的问题：命令式约束把路径固定了，agent 失去了用更好路径达成目标的自由度

2. 声明式约束的优势

「Done = 编译通过 + 测试通过 + lint clean」
只定义终态，agent 自己找路径
可以先写测试再写代码，也可以反过来
K8s 的核心哲学：声明 Desired State，controller 自己 reconcile

3. Spec 中的 acceptance criteria 必须 machine-verifiable

「写好代码」≠ 合格终止条件
「代码编译通过 + 单测通过 + lint 无警告」= 合格
过去的过程约束（Rules、Scripts、baselines）转化为 Loop 内的验证检查点
这把命令式流程转变为声明式终态

4. 集群按 Failure Cost 分级

为什么不按 RBAC verb（get/list/patch/delete）分级：

verb 不包含语义：delete pod 和 delete namespace 都是 delete，但后果差几个数量级
按 failure cost 分级才能匹配实际风险

分级表：

集群类型	读操作	写操作	删除资源	删除 namespace
Dev/Preprod	自由	确认	确认	阻断
Prod	自由	警告+确认	阻断	阻断
PCI	自由	阻断	阻断	阻断

Hook 做语义门控：读 cluster tier → 匹配操作类型 → 决定 allow/confirm/deny
新增集群只需加一行分级，不需要改 hook 逻辑

5. Permission Mode 是阶段性切换

Claude Code 六种权限模式不应「选一个一直用」
调研阶段 → Default（只读）
执行阶段 → allowlist（预授权操作集）
本地开发 → acceptEdits
类比 K8s：不同 workload 绑定不同 ServiceAccount

6. Mutating 操作后的强制验证

kubectl scale → kubectl rollout status + kubectl get
helm upgrade → helm status + kubectl get pods
验证失败或结果不明确 → 停下来报告，不继续
当前：CLAUDE.md 规则 + 人工抽查；下一步：写进 PostToolUse hook

涵盖的 Topic

Topic 9: 声明式约束 vs 命令式约束
Topic 7: 集群按 failure cost 分级

源文件引用

contexts/thought_review/agentic_control_theory_primitives_20260413.md — 声明式 > 命令式的完整论证，acceptance criteria 必须 machine-verifiable
contexts/thought_review/agent_k8s_safety_infra_2026-03-28.md — 集群分级表，permission mode 阶段切换，强制验证设计，hook exit code 语义
contexts/thought_review/agentic_ai_controllability_design_20260329.md — Scope Declaration，执行合约（execution contract）