企业官网建设流程全解析

OpenRig权限与信任模型全解：YOLO为何默认关闭，danger-full-access的真实边界是什么

【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work.项目地址: https://gitcode.com/GitHub_Trending/op/openrig

OpenRig 是一个 AI 智能体团队编排工具，它把 Claude Code、Codex 和 Pi 组成拥有角色分工、共享上下文和独立工作区的持久化团队。正因为这些智能体会在你的机器上直接执行命令，OpenRig 设计了一套分层的权限与信任模型：默认安全、逐级放权、全程可审计，其中最具争议的 YOLO 模式默认关闭。本文带你从零看懂这套模型，搞清楚danger-full-access到底给了什么、又没给什么。

🧭 第一眼看懂：四档内置权限姿态

OpenRig 用四个"姿态（posture）"来描述团队启动时的权限等级，从紧到松依次是Locked → Standard → Open → YOLO：

四份内置策略的完整定义可以逐一阅读：

• locked.policy.md
• standard.policy.md
• open.policy.md
• yolo.policy.md

一个关键设计：策略里区分ASK ≠ deny。Standard 对发布类操作的处置是"交给人类决定"，而不是偷偷静默拦截——这是官方称之为"best-effort-safe"的原则。

🛡️ 永远存在的"地板"：可用性底线（Floor）

即使什么都不配置，OpenRig 也为每个智能体保留一条始终开启的地板（flag surface，不依赖配置文件）：

• Claude：--permission-mode acceptEdits—— 编辑可以顺畅进行，但权限模式不越界；
• Codex：-s workspace-write—— 沙箱被显式限定在工作区内，这是 OpenRig 主动写入的标志，而不是 Codex 的默认值；
• Pi：--no-approve—— 注意这是**资源信任（resource trust）**姿态，Pi 本身没有权限策略面。

这条地板的意义在于：权限策略是"意图"，地板是"硬约束"。Locked 的智能体仍然可以编辑文件，但它无法越出最小允许集去碰网络、密钥或远程操作。

🚨 YOLO 默认关闭：开关、覆盖与优先级

源码注释第一行就写明了态度：OpenRig YOLO mode (opt-in, DEFAULT OFF)（见 yolo-mode.ts）。YOLO 开启后，每个受管 seat 以各自运行时最大放行的启动标志启动：

优先级：三层裁决顺序

1. 成员策略 > rig 策略 > 环境开关：某个 seat 挂载了自己的策略时，它对该 seat 权威生效，且双向覆盖OPENRIG_YOLO环境变量——全局开了 YOLO，挂载了builtin:locked的 seat 依然保持地板；反之，挂载 full_bypass 策略的 seat 无需环境变量即可放行。
2. YOLA 是确定性标志，不经过技能翻译：YOLO 属于surface: flag策略，直接解析为稳定的启动标志，由运行时确定性应用；而 Standard/Open/Locked 这类配置面策略则由applying-a-permission-policy技能翻译成各运行时的具体规则（见 applying-a-permission-policy/SKILL.md）。
3. 零配置写入：YOLO 路径不写任何权限配置文件，它只选择启动标志。记录策略 ≠ 改写原生配置。

官方文档在 README.md 中强调：YOLO默认关闭，只有被显式选择的 full-bypass 策略才会触发绕过。

🔍 解剖 danger-full-access：它给了什么，没给什么

很多用户把danger-full-access理解为"上帝模式"，但 OpenRig 对它划定了清晰边界：

它给了什么

• Codex 的最大化沙箱（-s danger-full-access）；在 full_bypass 策略下还附带-a never，即永不走审批；
• Claude 跳过所有权限提示；
• 适用于"你刻意信任的工作与环境"（源码原话：Use only for work and an environment you deliberately trust）。

它没有给什么（常见误解）

• ❌不替代原生托管限制：YOLA 是启动参数，各运行时的原生配置、托管策略仍然生效——"选择策略"不会把配置规则翻译成新的权限；
• ❌不是全局通行证：独立运行codex --yolo并不等于 OpenRig 的配置；仅靠遗留环境变量OPENRIG_YOLO=1开启的路径，甚至只选沙箱、不选审批策略；
• ❌不等于任务授权：权限规则授予的是"执行能力"，不是发明任务、发布成果或改动其他主机的"权威"。

策略文档还特意澄清了 Pi 的措辞纪律：--approve是资源信任，不是权限策略——信任位与权限面在 OpenRig 中是两类控制，不应混为一谈。

📋 场景速查：我该选哪一档？

• 陌生代码 / 敏感仓库：选Locked。默认拒绝，只放行构建、测试和 rig 启停。
• 日常开发（有你在场）：保持Standard（默认）。推送自由，PR、发布、合并、强推会先问你一句。
• 自治舰队（无人值守）：选Open。"毁灭级"操作（清空删除、丢弃持久存储、重置版本库）会触发询问并故意冻结该 seat——这正是设计好的安全网。
• 可信环境全速运行：YOLA。记住代价：没有任何停顿，包括毁灭级动作。

💡 判断口诀：ASK 会冻结自治智能体。如果你的团队需要"永不暂停"，那是 YOLO 的语义；如果只是想少弹窗，Standard 或 Open 就够了。

🎛️ 逐席精细控制与审计留痕

团队级姿态之外，OpenRig 支持按 seat 覆盖，且必须留审计理由：

# 查看 / 应用 rig 级策略 rig policy permissions list rig policy apply yolo --spec ./my-rig/rig.yaml # 审计式修改某个 seat 的下次启动权限（floor / full_bypass / inherit） rig seat set-permissions owner@first-project --mode full_bypass \ --reason "Operator selected broader access"

注意几个诚实的设计声明：

• rig seat set-permissions不会重启 seat、不改写原生历史，只记录"期望选择"，下次启动时生效；
• rig seat status会区分"期望值"与"上次实际启动参数"，但两者都不等于原生强制的证据——OpenRig 从不假装能证明运行时的最终执行权限；
• 修改权限的正确姿势是先暂停工作、用原生/permissions检查，而不是重启 rig"重置"权限。

完整的权限操作指南见 getting-started.md，rig 规格中策略字段的定义见 rig-spec.md。

总结

OpenRig 的权限与信任模型可以浓缩成三句话：

1. 默认不放任——地板恒开，YOLO 默认关闭，放行永远要显式选择；
2. 权限分层清晰——启动标志、配置策略、原生托管限制是三条独立通道，互相不替代；
3. 诚实不越权——ASK 就是交给人类，选策略不等于改写配置，状态显示也不假装是原生强制的证明。

理解danger-full-access的边界之后，你才能真正回答那个问题：这个团队、这个仓库、这个环境，值不值得让智能体"完全放手"？答案在四档姿态里，选择权始终在你手里。🔐

【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work.项目地址: https://gitcode.com/GitHub_Trending/op/openrig