企业官网建设流程全解析

• 人工智能
• AI Agent
• 多智能体
• Agent 编排
• 代码智能体
• CLI

OpenRig 是运行 Claude Code、Codex 与 Pi 于一体的多 Agent 编排系统，其内置权限策略以"姿态（posture）"为单位统一描述各 harness 的启动行为。builtin:yolo是其中唯一的surface: flag内置策略，将每个托管席位（seat）的启动参数一次性切换到各 harness 最大权限档位：Claude 跳过权限提示、Codex 进入 danger-full-access 且永不审批、Pi 开启完全资源信任。本文以 yolo.policy.md 为骨架，结合 OpenRig 源码与测试，完整讲解 YOLO 策略的前置契约、每个 harness 的具体启动参数、确定性应用机制（为何不经过 skill 翻译）、选择与原生强制相互独立的边界，以及通过rig policy命令记录与回退的完整操作路径，帮助读者在充分信任的工作与环境中选择性地启用最宽松的启动姿态，并理解何时不应使用它。

策略定位：四种内置姿态中的"全绕过"档位

OpenRig 将权限策略抽象为语义中立的 Markdown 规范文件：文件头部是 YAML frontmatter 契约（解析与校验逻辑见 policy-spec.ts），正文是给人读的说明。packages/daemon/policies/builtin/目录下打包了四个只读的内置策略，统一由 picker 展示：

从 policy-ref.ts 的BUILTIN_POLICY_NAMES定义可见，内置策略集为["locked", "standard", "open", "yolo"]，且必须通过builtin:前缀引用——裸名字一律不解析（反遮蔽规则），例如写permission_policy: builtin:yolo而绝不能写permission_policy: yolo。

YOLO 之所以与其余三个内置策略有本质区别，关键在于其 frontmatter：

--- source: builtin name: yolo surface: flag launch_posture: full_bypass policy_schema_version: 1 description: Permissive launch opt-in. Claude skips permission prompts; Codex selects danger-full-access and never approval policy. Pi enables resource trust. ---

契约：flag surface 与 config surface 的排他校验

OpenRig 把权限策略分成两个 surface，二者互斥且不可混用。validatePolicySpec（policy-spec.ts）按此契约做约定式校验：

• flag surface（YOLO 所属）：必须携带launch_posture（取值floor或full_bypass），禁止携带default_posture及allow/ask/deny/destructive_class动作列表——因为这些是 config surface 的字段；
• config surface（locked / standard / open / 自定义）：必须携带default_posture（allow/ask/deny三选一）以及全部四个动作列表字段（没有就用[]），禁止携带launch_posture。

这套排他设计保证了语义不混淆：flag surface 的策略只决定"启动时传什么参数"，不做任何动作级语义翻译；config surface 的策略只描述语义意图，不直接落到启动参数。校验是 advisory + fail-open 的（与rig scope audit一致），即校验结果只报告、不强制。

确定性映射：每个 harness 各自的 full-bypass 启动参数

YOLO 的实质行为全部体现在 yolo-mode.ts 的四个函数中，它们被应用到每一条受管理的启动路径（全新启动 fresh、恢复 resume、fork、legacy restore），保证行为均匀、绝不随路径分化：

对应源码依据：

• claudePostureFlag（yolo-mode.ts）：YOLO 开启返回--dangerously-skip-permissions，否则返回地板参数--permission-mode acceptEdits；
• codexPostureArg（yolo-mode.ts）：resolved 的full_bypass一次性同时选择沙箱与审批行为（-s danger-full-access -a never）；仅环境变量开启时只选沙箱（-s danger-full-access）；关闭且有命名 profile 时透传 profile（profile 自己管理沙箱）；关闭且无 profile 时显式给地板-s workspace-write——注意这里不是"不传参交给 harness 默认"，而是 OpenRig 显式钉死 workspace 沙箱地板；
• piTrust（yolo-mode.ts）：Pi 的--approve/--no-approve管理的是**资源信任（resource trust）**而非权限策略，YOLO 开启强制approve。

一个需要强调的细节：Codex 在 YOLO 路径上不会收到任何命名 profile 参数。yolo-mode.ts 头注释明确记录：YOLO 路径写入零配置文件，只做启动参数选择。

测试佐证

packages/daemon/test/yolo-mode.test.ts 以黑盒方式验证了上述映射：

• 关闭态 Claude 启动命令包含--permission-mode acceptEdits且不含--dangerously-skip-permissions；开启态恰好相反（yolo-mode.test.ts#L67-L77）；
• Codex resume：关闭态为codex -s workspace-write resume '<tok>'，开启态为-s danger-full-access，且开启态会覆盖命名 profile（#L79-L94）；
• Claude restore 与 Codex native fork 两条路径同样携带姿态参数（#L98-L139）；
• piTrust：关闭态保持配置值或默认no-approve，开启态强制approve（#L147-L152）。

确定性应用，而非 skill 翻译

YOLO 文档中最重要的一个设计决策是：YOLO 的应用是确定性的，不做 skill 翻译。

config surface 策略（locked / standard / open 及自定义策略）描述的是 harness 中立的语义意图，真正的落地由applying-a-permission-policyskill（SKILL.md）翻译为各 harness 的原生格式（Claude 前缀规则 / Codex posture / Pi 位），并带版本戳与注意事项。而 YOLO 属于surface: flag策略：它解析为一个稳定的启动参数，由运行时 flag surface 的选择直接应用，不会经过 skill 翻译——skill 只是指向这个设置本身。

原因也很直白：flag surface 足够稳定，值得用确定性代码处理，不值得付出 skill 间接跳转（skill-indirection tax）的代价。这也是"两 surface 规则"的体现：启动参数可以做确定性代码，配置文件级策略不允许。

选择与原生强制是两件事

YOLO 文档反复强调的第二个设计边界：记录策略 ≠ 翻译原生配置规则。

• 成员策略覆盖 rig 策略。优先级为member > rig > floor（见 policy-ref.ts 的resolvePermissionPolicyRefValue）：某个成员挂builtin:locked时，即使全局开启 YOLO，该席位也保持地板姿态；反之，成员挂一个自定义full_bypassflag 策略，则无需环境变量即可单独抬起该席位。
• resolved 的 config surface 选择优先于环境中的 YOLO：ResolvedLaunchPosture一旦存在即对OPENRIG_YOLO环境变量读取在两个方向上都具有权威性（yolo-mode.ts）。
• 原生配置与受管限制仍然有效：记录 YOLO 不会把原生规则翻译或覆盖掉。yolo-mode.ts 头注释中的"零权限配置文件写入"属性正是这一点——它只选启动参数，不写任何 Claude/Codex 权限配置。

REF 解析的三种来源

permission_policy字段存的是一个 REF 而非策略正文，policy-ref.ts 完整实现了三类来源的解析：

• builtin:<name>：解析进打包的内置集合，名字必须是locked/standard/open/yolo之一，未知名字给出结构化错误并列出已知集合；
• 相对自定义路径：相对声明它的 RigSpec 目录解析，绝对路径、..穿越、空路径段、非法字符段都是结构化错误（规范缺陷，绝不静默降级为地板）；
• none：被记录的故意选择（deliberate none），永不解析到任何文件，姿态与缺省完全相同（floor），但"缺省"是明确记录、可见的。

builtin:yolo的解析结果：surface: flag、launchPosture: full_bypass、contentResolved: true（名字即语义）。

实操：通过 rig policy 命令记录与查看

CLI 侧的rig policy命令（packages/cli/src/commands/policy.ts）是"教学 + 记录"型动词，头注释中钉死了一条诚实话语（HONESTY_PIN）：

OpenRig 不内置任何 allow/ask/deny 权限策略——harness 原生权限才是控制面。OpenRig 把姿态记录进 RigSpec，由 harness 原生权限执行——绝无运行时强制。

这意味着rig policy只把选择写进 RigSpec（permission_policy: builtin:<name> | none），运行时执行仍由各 harness 的原生权限系统负责。它提供的四个子命令：

• rig policy list [--spec]—— 列出内置策略 + 保留的 deliberate-none + 指定 spec 上下文中可见的自定义策略；
• rig policy show <name-or-ref> [--spec]—— 展示某个内置策略或（经校验的）自定义策略；
• rig policy current --spec <path>—— 展示当前生效的已记录策略与"将应用什么"，走权威的 validator/resolver；
• rig policy apply <name> --spec <path>—— 记录选择（与rig setup --policy同一写入流）。

关键保证：这些命令的每一个 REF 都经过validatePermissionPolicyRef+resolvePermissionPolicyAttachment，与 daemon 侧是字节级等价的双胞胎（由permission-policy-parity.test.ts钉住），无效 REF 以退出码 1 报权威错误，绝不让 CLI 表面放行 daemon 校验拒绝的规范缺陷。

针对 YOLO 的实际命令序列（来自 getting-started.md 的 Opt-in permissive operation 章节）：

# 记录 builtin:yolo 到用户自有 rig 的 RigSpec rig policy apply yolo --spec ./my-claude-rig/rig.yaml # 查看生效记录与将要应用的启动姿态 rig policy current --spec ./my-claude-rig/rig.yaml

应用后，下一次托管启动对 Claude 传--dangerously-skip-permissions，对 Codex 传-s danger-full-access -a never（替换掉命名 profile 参数）。回到受限制状态：rig policy apply none --spec ./my-claude-rig/rig.yaml并移除任何成员级 bypass 覆盖，下一次启动即回到 Claude 的--permission-mode acceptEdits与 Codex 的显式-s workspace-write地板。

环境变量开关 OPENRIG_YOLO

除了策略 REF，还存在一个纯环境变量开关OPENRIG_YOLO：取值精确匹配"1"或"true"时开启（yoloEnabled，见 yolo-mode.ts），其他取值一律关闭——"0"、"yes"都不是开启值，测试用例对此有精确覆盖。注意两点边界：legacy 环境变量路径在无 resolved 策略时只选沙箱（-s danger-full-access，不含-a never）；且文档明确"在客户端 shell 里 export OPENRIG_YOLO=1 不是可靠的按团队配方"——per-team 的确定性做法是写进 RigSpec 的permission_policy。

已运行的席位如何变更

YOLO 不是运行时拨杆：对已运行的席位，改文件或rig policy apply都不会吊销其已生效的权限，也不会在 restore 时改写已存储 rig 的策略。对正在进行的会话，正确做法是暂停工作、使用 harness 原生权限控制（当前 Codex 与 Claude CLI 均暴露/permissions）处理该会话，并再次检查生效模式；若原生版本无法就地应用，则保留工作并使用受支持的同一席位 stop/resume 路径（resume 会重新应用存储的启动模式，因此恢复后要先核验原生模式再继续工作）。全新 launch 才使用新的姿态参数。

使用边界与安全提醒

YOLO 文档的结尾部分是全篇最重要的安全说明：

• 只用于你刻意信任的工作与环境。开启后 Agent 以你账号的文件系统与网络访问权限行动，权限停靠点大幅减少——它们可能损坏文件或在无需再次确认的情况下发送数据；
• skill 与 starter 指南描述的是"预期行为"，不取代文件系统/网络边界；
• 原生受管限制仍然重要：记录策略不会翻译原生配置规则；
• 一个 headless 席位仍可能停在原生提示处等待：无人值守工作不是绕过许可的默示同意。

对于需要显式 Codex 沙箱 + 审批选择、或希望回到受限设置的读者，getting-started 的 Opt-in permissive operation 提供了完整的命名 profile 配方（sandbox_mode = "danger-full-access"+approval_policy = "never"，或回退配方workspace-write+on-request）与 per-seat 的rig seat set-permissions <seat> --mode full_bypass路径，可作为 YOLO 的互补手段。

小结

YOLO 是 OpenRig 权限姿态体系中最激进、也最克制的内置策略：激进在于它把三个 harness 全部切换到最大权限启动参数；克制在于它把自己限定在 flag surface 的确定性参数选择上，不写配置、不翻译规则、不承诺原生边界之外的安全。理解surface: flag与 config surface 的排他契约、member > rig > floor的优先级、以及"记录 ≠ 强制"的边界，是正确使用 YOLO 的前提。源码层面，yolo-mode.ts 与 policy-ref.ts 构成了这套机制的完整实现，yolo-mode.test.ts 则为每一条映射提供了可复核的测试证据。

• 人工智能
• AI Agent
• 多智能体
• Agent 编排
• 代码智能体
• CLI