大多数 coding agent 的权限系统是白名单：读文件可以、写文件可以、跑测试可以，其他都问。直到有人为了不再被打断把 agent 设成「完全信任」，然后它在周五下午执行了 git push --force。
我们的立场是：四类动作，无论 agent 或请求者被信任到什么程度，每一次都要停下来等人。信任级别决定其他动作有多少需要审批，这四类永远不能静默通过。
四类
1. 推送到共享分支。 特性分支上的提交是一个建议，推到 main 或 release 是整个团队都要承担的决定，往往还连着一次部署。问一下很便宜，回滚很贵。
2. 删除。 文件、分支、表、存储桶、资源。删除是唯一一种「猜错了意图，第二次猜也救不回来」的操作。agent 很自信，自信的删除是备份被检验的方式。
3. 花钱。 调付费 API、开资源、买域名、发一轮营销。提请求的人可能不知道这要花钱，付钱的人应该知道。
4. 访问凭证。 读密钥文件、导出环境变量、登录服务、完成两步验证。这一类关乎身份，而身份属于机器的主人，不属于房间里的任何人。
为什么「完全信任」也要在这里停
权限模式描述一个人与 agent 的关系：只读、可改不可推、完全信任。对一次会话里几百次普通调用来说这是合适的粒度；对上面四类却不是——它们罕见、不可逆或昂贵，而且代价落在请求者以外的人身上。
所以 muti 的规则很简单：任何权限模板都不能把这四类设为静默通过。即便是「完全信任」模式，它们也会停下并在时间线里高亮。提示足够少不惹人烦，类别足够明确答案通常显而易见。
与 Claude Code 权限模式的对应
Claude Code 自己有一个梯子：plan（只读）、default（改动和命令都先问）、acceptEdits（改动直接执行，命令先问）、bypassPermissions（什么都不问）。这些模式描述的是 agent 问你多少；四类动作描述的是 别人提请求时，什么必须问主人。两者叠加。
最后一列是房间加上的，每一行都一样。见Claude Code 权限模式详解。
该问谁
大多数设计跳过了这一步。当一个共享 agent 需要人时，需要的是哪个人？
- 凭证问主人。 登录、两步验证码、密钥访问都关乎主人的身份，无论任务是谁发起的都路由给主人。请求者只看到发生了一次接管，看不到秘密。
- 意图问请求者。 「你是指 staging 数据库吗？」是在问那个人想要什么，路由给发起人。
- 两人看同一条时间线。 谁都不用替谁转述上下文，问题和答案就在工作旁边。
凭证与危险动作的提示路由给主人，意图问题路由给请求者，双方在同一条时间线里看到往来。
一张好审批卡片的构成
五秒内能做决定的审批卡片有五个部分。
给它三个按钮：同意、拒绝、只读继续。第三个被低估了：工作继续，只有危险那一步等着。
让主人在任何已经在的地方处理审批：控制台、手机、IM 卡片，一处处理全局生效。设一个过期时间，别让一张被遗忘的卡片一周后突然执行。
审批疲劳才是真正的敌人
每一次提示都在训练看到它的人。太多了，他就会去找那个关掉它的开关。三件事能在不放松四条规则的前提下把频率压低。
- 缩小 agent 的范围。 一个 agent 一个工作目录，能碰的文件少，关于碰文件的提示也少。
- 普通调用用普通模式。 浏览用只读，大部分工作用「可改不可推」。「完全信任」留给那些本来就会坐到你键盘前的人。
- 默认模板要诚实。 把只读、可改不可推、完全信任做成有名字的预设，没人需要从零拼一套策略然后拼错。
审计那一行
每一条请求、每一次需审批的动作，都应该产生一行主人可以导出的记录：谁提的、谁批的、何时、哪条规则、结果、用量。不是因为每天有人读，而是因为出事那天不是开始记日志的日子。
常见问题
每次都问不会拖慢 agent 吗？ 只有这四类会问，正常会话里很少见。停顿的代价以秒计，错误的代价以小时或金钱计。
主人用自己的 agent 呢？ 主人对自己的 agent 不受权限模式限制，但四类动作同样记入时间线，历史完整。
请求者能自己批准吗？ 不能。审批属于机器的主人。请求者可以取消、重试或补充上下文。
muti 的房间默认开着这些规则，也没有关掉它们的开关。如果你觉得这是正确的默认，给你的 agent 一个房间。
发布于 · 更新于