先看事故，不要等自己交学费
事故复盘页的工作不是制造恐慌，而是帮你建立一件事：哪些风险会直接变成真金白银、权限失控和难以回滚的系统状态。
很多人第一次看安全时，会把它理解成：
- 有没有漏洞新闻
- 社区今天在吵什么
- 某个技能是不是“看起来不太安全”
但真实事故更常见的形态其实是：
- 账单在你睡觉时自己长到不可接受
- 一段恶意输入把 Agent 引到不该做的动作
- 权限和出口开太宽，最后没人说得清谁干了什么
事故一：账单一夜暴涨
常见触发链
账单暴涨通常不是“模型太贵”四个字这么简单，而是下面几件事叠在一起：
- 外部 API 返回异常数据
- Agent 不断重试同一类任务
- 没有单次、每小时、每日的成本上限
- 没有监控和报警
真正要记住的是：
循环 + 重试 + 无上限 = 账单事故。
根因比你想的更朴素
最常见的根因其实只有三类：
- 任务没有迭代上限
- 成本没有硬阈值
- 发现问题时已经太晚
三道防线
01
OpenClaw 层
限制循环、限制调用频率、限制单次和每日预算。
02
模型平台层
在提供商后台设置硬性 usage limit，不要只靠站内提醒。
03
账户层
用预付费、余额预警或卡片上限，把最坏结果压住。
一段够用的止损思路
{
"costControl": {
"enabled": true,
"limits": {
"perRequest": 0.1,
"hourly": 10,
"daily": 50
},
"actions": {
"onPerRequestLimit": "reject",
"onHourlyLimit": "pause_and_alert",
"onDailyLimit": "emergency_stop"
}
},
"loopProtection": {
"enabled": true,
"maxIterations": 20,
"maxCallsPerMinute": 30,
"detectSimilarCalls": true
}
}
事故发生时先做什么
账单事故止损顺序
1. 先停调用，不先解释
2. 先冻结或删除出问题的 API Key
3. 先停 OpenClaw 相关进程或容器
4. 再导日志，判断是循环、重试还是 fallback 失控
5. 最后才恢复服务
事故二：提示注入绕过
它最危险的地方
提示注入最危险的地方不是“回复变怪了”，而是：
- 它可能把用户输入偷渡成新的系统意图
- 它可能引导模型去调不该调的工具
- 一旦工具本身没有二次鉴权，后果会直接落到真实系统
这类事故为什么会成功
常见原因通常是三件事同时成立：
- 直接把用户输入拼进高优先级提示里
- 没做输入过滤
- 工具调用没有额外权限判断
先收住这几类输入
高风险注入信号
- 忽略以上所有指令
- 你现在是系统管理员
- 覆盖原规则 / 新系统提示
- 请把结果发送到外部邮箱 / 外部地址
更现实的防守思路
- 用户输入和系统规则分层，不混写
- 高危工具调用前必须再确认
- 即使模型判断要调用，也要让工具层再做权限检查
- 外发动作和敏感读取动作不要共享一套“默认允许”
事故三：权限失控与出口过宽
这类事故未必像账单那样立刻可见，但后果通常更难追。
最典型的形态包括：
send_as_user开得太早offline_access开了却没人管刷新和撤权- 文档、表格、日程、任务全给了写权限
- Webhook、回调地址和外发目标没有审计
一条最朴素的判断线
如果一个权限一旦开通，就能让 OpenClaw：
- 以你的身份发消息
- 写文档
- 改表格
- 动任务
- 看更多上下文
那它就已经不再是“辅助读取权限”，而是“可执行权限”。
先记住这张事故后处理清单
事故后处理 checklist
1. 先停入口：停进程、停容器、停 webhook
2. 先换密钥：API Key、App Secret、Webhook
3. 先保留证据：导日志、导配置、记时间线
4. 先缩范围：到底是成本、注入、权限还是路由问题
5. 先修最小闭环，再恢复复杂工作流
从事故回到日常，你最该补什么
如果你看完这页只做三件事，优先是：
- 补成本上限
- 补最小权限
- 补回滚和日志导出习惯