Lab-confirmed：本文的 mitigation pattern，我（Maki）在個人 OpenClaw / inbox automation 流程裡實際用過。Code snippet 仍是整理後的 reference 版本，不等於 production 原碼。
你的 system prompt 在 context 壓縮後還在嗎
很多 builder 一談 safety，第一反應是多寫幾句 system prompt。
提醒模型先確認。
提醒模型不要自作主張。
這些文字在短 context 裡通常有效。
你在 toy inbox 上測過了。
然後一接到真實資料量，整個系統開始變形。
不是因為有駭客進來。
不是因為你被 prompt injection。
而是 runtime 為了塞進更多 token，自己把上下文做了 compaction。
也就是說，系統偷偷改寫了「哪些規則還活著」。
它比較像你把資料庫 transaction 保證寫在 log 註解裡，然後以為 production 還會記得。
只要 safety instruction 會被靜默壓縮掉，它就不是 hard control。
它只是希望。
Context Compaction：不是被駭，是設計 bug
這個邊界的問題，不是模型會不會理解中文。
而是 runtime 會不會保住你最重要的那句話。
Case：
主：2026-02-23，TechCrunch 報導 Summer Yue 的 OpenClaw 刪信事故。她先在小 inbox 上測試 agent，確認它能先建議、後執行，再接到真實大 inbox。結果 agent 開始「speed run」刪信，手機上的停止指令也沒用，她只好跑回 Mac mini 手動終止。隔天 Dataconomy 依據 Yue 自己補充的說明整理出更關鍵的細節：大 inbox 的 token 量觸發 context window compaction，系統把「先確認再行動」那句 safety instruction 靜默壓掉，最後刪了 200 多封 email。這不是外部攻擊。這是 compaction 沒把 safety-critical instruction 當成不可丟失的工程 bug。
次：2026-03-20，The Guardian 報導 Meta 內部 AI agent 建議導致敏感資料暴露給員工約兩小時。情境也很典型：工程師只是問 agent 工程問題，agent 給出的解法改動了 access control，而人類把建議直接套用。這不是「agent 會不會講幹話」的問題。這是 advisory 與 execution 沒分層的工程災難。
核心問題：你的安全約束到底活在 prompt，還是活在 runtime？
Level 1：把 safety instruction 每回合重複一次。
也最貴。
而且它仍然依賴模型在壓縮、摘要、重排之後還能保留原意。
Level 2：把 hard-confirmation gate 從 prompt 移到 tool wrapper。
因為 runtime 可以 deterministic 地拒絕沒有 confirmation token 的 destructive action。
Level 3：把 destructive flow 改成可逆。
例如先 soft delete、先 archive 到 staging、先排程 N 分鐘後才真的刪。
這時候即使 agent 衝出去，你還有把它拉回來的時間。
Rule：不要把 safety 關鍵句只放在 system prompt。真正會傷害資料的限制，應該放進 tool / runtime / action layer。
| 失敗模式 | Mitigation | 落地點 |
|---|---|---|
| safety instruction 被 compaction 砍掉 | 把 hard-gate 從 prompt 移到 tool wrapper / API decorator | tool / runtime layer |
| Agent 不停 speedrun | reversible action flow + N-minute soft delete | action layer |
| 電話 / 外部 stop signal 無效 | external kill switch endpoint 監聽 emergency token | infra layer |
| AI 建議直接 apply | advisory 與 execution 分離 + policy validation gate | application layer |
Reference 實作（示意非 production code，依你環境調整）：
import functools
import time
import uuid
PENDING_ACTIONS = {}
def safe_tool_wrapper(tool_func, requires_confirmation=True, reversible_for_seconds=300):
@functools.wraps(tool_func)
def wrapped(*args, action_id=None, confirmation_token=None, execute=False, **kwargs):
if requires_confirmation and not confirmation_token:
raise PermissionError("missing confirmation token")
if not execute:
action_id = str(uuid.uuid4())
PENDING_ACTIONS[action_id] = {
"tool": tool_func.__name__,
"args": args,
"kwargs": kwargs,
"expires_at": time.time() + reversible_for_seconds,
}
return {"status": "staged", "action_id": action_id}
pending = PENDING_ACTIONS.get(action_id)
if pending and time.time() <= pending["expires_at"]:
return tool_func(*args, **kwargs)
raise TimeoutError("reversible window expired or action not staged")
return wrapped
這段 code 的重點不是 decorator 很漂亮。
而是 destructive action 先進 staging，再執行。
真正的 safety 不是「模型答應你它會小心」。
而是 runtime 把 reversible window 做出來。
如果你真的要讓 agent 動手。
對應 OWASP：這篇先看哪幾條
LLM06:2025 Excessive Agency：當 agent 一旦跨過建議層直接執行，任何 context bug 都會放大成真實動作。ASI03 Identity and Privilege Abuse：OpenClaw 刪信事件不是 output 品質問題，而是 agent 以你的身份去動你的東西。
想動手做？ 這篇文的概念可以接著看： 脈絡邊界
如果你想把 prompt 外硬閘、可逆刪除、kill switch 做成完整實作，直接接： 脈絡邊界 101 →