龙虾紧箍咒 — 安全规范体系构建与迭代框架

为 AI Agent 系统化地创建和持续改进安全规范。

核心理念

好规范 = 精简（<150行）+ 分级（低/中/高）+ 清晰（决策表）+ 场景化 + 可维护

快速入口

用户开口时，判断意图进入对应流程：

| 用户说法 | 进入流程 | |----------|----------| | "帮我建规矩" / "新建安全规范" / "刚装了个 agent" | Build 流程（3步） | | "改改现有规则" / "优化安全规范" / "agent 有点乱来" | Iterate 流程（3步） |

Build 流程（从零搭建）

适用于：新 agent、无安全规范文件

Phase 1：需求采集（4个问题）

用对话方式了解用户需求，不要像填表：

Q1: 你的 agent 平时主要做什么？

发微信/消息 → 侧重消息权限、指令边界
操作文件/执行命令 → 侧重文件安全、系统命令
参与群聊 → 侧重隐私保护、不越权
浏览网页/抓数据 → 侧重网站范围、外部信息隔离
安装插件/调用技能 → 侧重权限透明

Q2: 你希望 agent 多谨慎？

保守型：所有非只读操作都问我
平衡型：按风险分级确认（推荐）
信任型：只有高风险操作才问我

Q3: 有没有现成的规则或红线？

检查 AGENTS.md、SOUL.md 等文件
有则引用，无则新建

Q4: 最担心 agent 做什么？

记录用户的具体担忧，优先覆盖

Phase 2：搭建基础（2个文件）

workspace/
├── 紧箍咒.md       # 核心规则（< 150行）
└── 紧箍咒CASES.md  # 案例集

核心规则 5-7 条，覆盖：

指令边界、范围控制、信息安全
停止报告、决策权、风险分级
隐性依赖检查（文件/配置/组件变更影响范围）

必须包含决策表： | 情况 | 行为 | |------|------| | 指令有歧义 | 问用户 | | 明确可行 | 直接执行 | | 可行但有问题 | 提醒风险，让用户选 | | 有更优方案 | 先执行原指令，再建议 | | 无法执行 | 停止并报告 |

风险三级：

低：只读 → 直接执行
中：写入/发送 → 轻量确认
高：删除/系统级 → 完整确认

详细指南：file-architecture.md

Phase 2.2：集成到 AGENTS.md（关键步骤）

安全规则写好后，必须让 agent 每次会话自动加载。在 AGENTS.md 的 Session Startup 流程中添加读取步骤：

推荐位置：Session Startup 第3步（SOUL.md 之后、memory 之前）

3. Read `紧箍咒.md` — 安全规则（每次必读，不可跳过）
4. Read `紧箍咒CASES.md` — 首次启动 / 不确定场景 / 犯错后 / 每月复习

为什么这步关键：安全规则如果不在启动流程中，agent 不会主动遵守。只有写进 AGENTS.md 强制流程，才能保证每次会话都加载。

Phase 3：案例 + 场景适配

案例格式（每条规则至少1个）：

场景描述 → 错误做法 ❌ → 正确做法 ✅ → 引用规则

场景化适配：

微信：简短确认（是/否/详情）
网页：富文本报告
CLI：完整分层报告

Phase 尾步：迭代检查（仅条件触发，Build/Iterate 结束后均执行）

完成规则操作后，快速检查以下条件：

[ ] 紧箍咒.md > 150行？
[ ] 紧箍咒CASES.md 有最近30天内新增的案例？
[ ] 有新 agent 或新接入的场景未覆盖？
[ ] 距上次迭代超过30天？（见紧箍咒CASES.md末尾记录）

全部未触发 → 静默结束，不提迭代，不打扰用户 任一触发 → 简要告知用户发现的问题，询问是否进入 Iterate

设计意图：不单独设置迭代触发机制，而是嵌入每次规则操作的尾步。条件触发 = 有事才说，无事不打扰，避免制造噪音。

第二部分：Iterate 流程（改进现有规则）

适用于：已有安全规范，需要优化。

Step 1：现状扫描（5分钟）

先问用户（口语化）：

"你的 agent 最近做了什么让你不放心的事？"
"它有没有发过不该发的消息，或者删过不该删的文件？"

然后 AI 自己检查：

扫一遍 workspace 里的安全文件
看看有没有明显的漏洞
把发现的问题用大白话告诉用户

Step 2：诊断 + 出方案

基于扫描结果，识别痛点并匹配改进模式：

| 痛点 | 检测信号 | 改进模式 | |------|----------|----------| | 规则过于绝对 | "永远不"无例外 | 条件化 | | 缺乏风险分级 | 所有操作一视同仁 | 引入分级 | | 文件过长 | > 200行 | 合并+外移 | | 缺乏场景化 | 只有通用规则 | 场景适配 | | 缺乏决策树 | 不知道走哪条分支 | 添加决策表 | | 隐性依赖失控 | 改A坏B、改配置不通知 | 隐性依赖检查 |

向用户展示方案 → 获得确认 → 再执行

Step 3：逐步改进

一次只改一点，改完验证：

合并重复规则（立竿见影）
引入风险分级（核心改进）
添加决策表（好执行）
案例分离（精简主文件）
场景化适配（更贴心）
隐性依赖检查（长期保障）

每步：展示改前 vs 改后 → 验证 → 确认 → 下一步

持续维护

不再依赖独立触发机制。 规则更新通过以下两条路径保证：

尾步条件触发（见 Phase 尾步）— 每次 Build/Iterate 结束后自动检查
案例积累（紧箍咒CASES.md）— 新增案例时自然发现规则缺口

维护信号对照： | 信号 | 来源 | 动作 | |------|------|------| | 规则覆盖不到新场景 | 日常使用 / 尾步检查 | 补充案例 + 评估是否加规则 | | 核心文件 > 150行 | 尾步检查 | 提示精简，外移案例 | | 新增 agent/场景 | 尾步检查 | 评估规则扩展 | | 配置/文件变更影响 | 隐性依赖检查 | 在紧箍咒CASES.md记录影响 |

完成检查（5秒版）

[ ] 核心规则 < 150 行、≤ 7 条
[ ] 无冲突、有决策表、有案例
[ ] 有风险分级、适配场景
[ ] 隐性依赖检查覆盖文件/配置/组件三类
[ ] AGENTS.md 启动流程已集成安全规则读取

参考文档（按需加载）

analysis-checklist.md — 现状分析清单
improvement-patterns.md — 6 种改进模式
file-architecture.md — 文件组织

多 Agent 适用

尊重现有 SOUL.md、AGENTS.md
新增规则是"补充"而非"替代"
多 agent 可共享规则（符号链接或引用）

开发侧安全（按需引用）

若本 agent 参与 skill 开发，在紧箍咒CASES.md 查阅「开发侧」相关案例。 Skill 安全开发规范参考：技能开发工作室·开发原则（最小权限、可审计、可撤销）。