"agent 能做什么"是产品力，"agent 不能做什么、什么时候必须问"是产品力 × 工程力。后者决定它能不能出手做关键事。
建议先读《Default System Prompts / agent 的"宪法"》；如果你是跳读，至少先看本章索引与本页 TL;DR。
课程中段的能力层，用来回答“一个 harness 为什么需要这些补丁”。
"agent 能做什么"是产品力，" agent 不能做什么、什么时候必须问 "是产品力 × 工程力。后者决定它能不能出手做关键事。
先看失败模式，再看能力补丁；能力不是越多越好，而是要能对症下药。
课程主线：稳定能力抽象 + 官方机制 + 跨框架共性。
allow / ask / deny × (tool, path, domain, command pattern, ...)。比"per-tool 全开/全关"细得多。00 · 06 节 把 agent loop 的 Decide 拆成 Plan / Decide / Execute 三段。Execute 段的失败模式包括："执行了不可逆动作 / 越权访问 / 误删文件 / 把秘密泄漏给外部"。
这些失败模式都不是"模型不够聪明"导致的——是"没有外置守门"导致的。即便最强的模型，也会：
rm -rf .）守门的工程答案分两层：Permission 是声明式策略（"什么允许 / 什么要问 / 什么禁止"），HITL 是策略里"要问"那一类的实际兑现（"问的时候人怎么介入、怎么改、怎么 resume"）。
朴素方案：每个 tool 全开或全关。问题是同一个 tool 在不同 scope 里风险完全不同——shell("ls") 安全，shell("rm -rf /") 致命。
主流方案是3 态决策 × 多维 scope：
| 3 态 | 含义 | 典型用法 |
|---|---|---|
allow |
无需询问，直接执行 | 纯读操作（read_file / ls / grep） |
ask |
暂停，把动作展示给用户，等批准 | 修改工作目录文件、执行 shell 命令、git commit |
deny |
硬拦截，不执行也不问 | 访问工作目录外文件、网络 egress、写 ~/.ssh 等 |
多维 scope 的常见维度：
# Cursor 风格的多维 scope rule
{
"read_file": {"default": "allow"},
"write_file": {
"default": "ask",
"rules": [