让 Coding Agent 重构一个模块，几分钟后十几个文件被改完——效率确实高，但"如果它理解错了呢"这个问题也一直在。运行模式（Agent Modes）存在的意义，就是把自主权变成一个可配置的旋钮，而不是非黑即白的赌注。
三种模式各自解决什么矛盾
Agent 的根本矛盾是：自主权大，执行快但可能误改文件、跑危险命令；自主权小，每步人工确认，效率掉光。三种模式就是这个旋钮的三个档位：
| 模式 | 核心思想 | 适用场景 |
|---|---|---|
| Plan | 只分析、出方案，不动项目文件 | 架构设计、大型重构前的方案评审 |
| Default | 可执行，关键操作等人工审批 | 日常开发、修 Bug |
| Auto / Yolo | 减少审批，连续自主执行 | 批量迁移、长耗时重复任务 |
Plan 模式的价值在于把"理解偏差"拦在动手之前：先读代码、给方案、人审完再进执行。Default 是典型的人机协作（human-in-the-loop）：读文件这类低危操作直接放行，写文件、跑命令触发确认。Auto 适合批量 API 迁移这种重复任务，但要明确一点——Auto 不等于没有任何安全限制，成熟产品会保留权限规则和沙箱，只是减少了确认弹窗。
底层机制：Allow / Ask / Deny 与沙箱的分工
三种模式剥开看是同一个问题：Agent 要调工具时，系统怎么裁决。答案是三维策略——Allow 直接执行、Ask 等人批、Deny 拒绝。模式切换本质上是在改这三维策略的默认值。
权限控制和沙箱经常被混为一谈，其实分工明确：权限决定"这个操作批不批"，沙箱决定"批了的操作能摸到什么"。即使命令被放行，沙箱也可以限制它访问容器外的文件和网络。两层叠起来才是完整的执行边界。
增量：把权限策略写进配置，而不是靠弹窗
以 Claude Code 这类支持权限规则文件的 Agent 为例，策略可以显式声明（示意）：
{
"permissions": {
"allow": ["Read(**)", "Bash(git status)", "Bash(git diff:*)"],
"ask": ["Bash(npm install:*)", "Write(src/**)"],
"deny": ["Read(.env)", "Bash(rm -rf:*)", "Bash(curl:*)"]
}
}
三档规则各管一类：读源码放行，装依赖和写文件过人工，.env、递归删除、任意网络请求直接拒绝。CI 场景确实存在跳过交互审批的开关（如 --dangerously-skip-permissions），它的正确用法是"只跑在一次性容器里 + 配合上面的 deny 规则"，而不是裸开。
增量：沙箱与放权的验证清单
配完策略要验证，别等事故来验证。一份可以直接抄的检查单：
# 1. 沙箱隔离性：容器内运行 Agent，确认宿主机敏感目录不可见
docker run --rm -v "$PWD:/work" -w /work agent-image \
sh -c 'ls /root 2>&1; ls /work'
# 2. deny 规则有效性：故意发一条被禁命令，确认被拦截而非执行
agent -p "执行 rm -rf /tmp/canary" && test ! -e /tmp/canary && echo "deny 生效"
# 3. 改动面审计：每轮任务结束后固化 diff
git diff --stat > audit/$(date +%s).diff
判定标准：容器内读不到宿主机敏感路径；被禁命令必须失败且不产生副作用；每轮任务留 diff 留痕，改动文件数异常膨胀（比如超出任务描述范围）立即人工复查。
落地节奏：四个阶段切换模式
以大型重构为例的稳妥路径：Plan 模式出方案 → 人工审方案 → Default/Auto 执行（高危操作保留审批）→ git diff + 自动化测试验证结果。压缩成一句口诀：先规划、再审查、后执行、必验证。
最后一个认知：Agent 的能力上限由模型决定，事故概率由 Harness 决定。放权不是信任模型，是信任你自己的权限规则、审批流程和隔离环境。
评论0