先 Dry-run，再放权：Harness 权限模式为什么比提示词可靠

很多团队把安全写成一句 system prompt：「不要删除文件，不要执行危险命令」。线上一旦跑起来，这句约束经常失效——因为真正执行工具的是 harness，不是提示词。

最近开源 Harness 的共识更务实：把权限做成运行时模式。常见三档是只读规划（PLAN）、默认需确认（DEFAULT）、全自动（FULL_AUTO）；再配上路径规则、命令拦截、工具前后 Hook，以及不动真实世界的 Dry-run。OpenHarness 一类项目把这套治理层写得很清楚。

一、提示词约束为什么扛不住

提示词是软约束。模型可能忘记、可能被工具描述诱导、也可能在长任务后半程「为了完成目标」自行放宽。

权限模式是硬约束。PLAN 下写操作直接被拒绝，不依赖模型是否同意；DEFAULT 下高风险动作进入审批队列；FULL_AUTO 才关闭人工闸门。差别在于：失败时你得到的是明确拒绝，而不是一段事后道歉。

二、三档模式各自解决什么

PLAN：适合调研、方案对比、影响分析。允许读代码、搜文档、列目录，禁止落盘修改。它强制 Agent 先想清楚再动手。

DEFAULT：适合日常开发协作。读操作可自动，写文件、跑命令、联网等按规则确认。人仍在回路里，但不必确认每一句闲聊。

FULL_AUTO：适合边界清晰、可回滚、有独立验收的任务。没有验收和回滚，就不要开这一档。

模式切换本身也应可审计：谁在什么时候把 PLAN 调成 FULL_AUTO，必须留痕。

三、Dry-run 的位置常被低估

Dry-run 不是演示功能。它解析当前配置、认证、Prompt、Skills、工具和 MCP，但不调用模型、不执行工具、不起子 Agent。

它回答的是上线前最关键的问题：这套 Harness「以为自己能做什么」。认证缺失、MCP 待连接、危险工具已挂载、权限模式过宽，都应在 Dry-run 阶段暴露，而不是在生产会话里第一次发现。

一个团队如果没有 Dry-run，就等于没有起飞前检查单。

四、Hook 让治理可插拔

PreToolUse / PostToolUse Hook 的意义，是把观察和限制插入执行点：

• 执行前：校验路径、命令黑名单、参数形态
• 执行后：记录审计、触发二次校验、必要时回滚或收紧权限

Hook 比把所有规则焊死在核心 loop 更灵活，但也有红线：权限判定和审计留痕不应被业务 Hook 静默关掉。可扩展的是策略，不可卸载的是「每次副作用都要过闸」。

五、落地顺序

1. 先定默认模式为 PLAN 或 DEFAULT，而不是 FULL_AUTO
2. 给写操作、Shell、联网分别设规则，而不是一把全局开关
3. 上线前强制 Dry-run，把 blocked / warning 清掉
4. 再为高价值链路开有限的自动权限，并配回滚与验收

权限工程的目标不是让 Agent 什么都不能干，而是让它只能干「当前任务真正需要、且失败可收回」的事。

结语

Harness 的安全感，不来自更长的道德提示词，而来自可切换的权限模式、可拦截的执行点、可预演的 Dry-run。先看清系统被允许做什么，再决定放多大权——这比事后追责便宜得多。