openrig 测试床 runbook 深度解析：L3 daemon-in-container 容器化守护进程的零令牌拓扑验证-北京尧图网络

人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载导读本文基于 openrig 仓库docker/testbed/runbooks/L3-daemon-in-container.md测试床三级验证阶梯的第三级运行手册完整拆解一条在容器内验证 openrig daemon 的核心链路守护进程如何在容器本地 sqlite 上启动、如何通过发布端口published port暴露/healthz健康检查与受 bearer 令牌保护的管理路由以及rig up如何在零 LLM token 消耗runtime: stub的前提下落定一个容器本地的桩拓扑。读者将获得一份可直接照抄执行的 Docker/Apple 双运行时 A/B 验证流程并理解其背后由源码支撑的四项耦合机制显式绑定地址、强制 bearer 令牌、显式端口分配与字节级一致的探针设计。所有论点均可在当前仓库源码中逐行印证文末给出证据路径索引。一、L3 在测试床阶梯中的定位与核心命题docker/testbed/runbooks/目录按 L0L6 划分了测试床验证阶梯L3 是其中承上启下的一环前置条件L3 在宿主侧运行依赖 L2tmux server 生命周期完成后启动的容器环境本轮职责消化exercise桩负载stub payload——即docker/testbed/stub-assets.list清单中列出的桩rig.yaml、agent fixture 与culture.md验证容器内的 daemon 能够启动并提供可探测的 HTTP 服务面零 token 的构造保证桩拓扑使用runtime: stub确定性 node 脚本 harness见桩 rig.yaml因此整轮验证不调用任何 LLM从构造上保证零 token 消耗Census 范围rig up落定的那组桩资产rig.yaml agent fixture culture.md正是构建清单census的哈希范围构建脚本会将其哈希进字节级可复现的 census receipt见scripts/build-testbed-image.sh:101。L3 运行手册的写作背景是一个真实发生的 A/B 对照组事故旧版 runbook 启动了一个回环绑定loopback-bound的 daemon却通过发布端口去探测它——由构造决定不可达导致 Docker 与 Apple 两个运行时分支的探测全部失败操作者 A/B 收据Q2-AB-d121568ad-20260807-host/AB-RESULT.mdDocker curl 52 / Apple curl 56。一个连控制组都无法通过的实验无法评判实验组。因此本 runbook 的核心是四项耦合机制修复四项全部在源码层落地且对两个运行时分支原样适用机制内容源码锚点(a) 绑定地址显式指定绑定地址绝不依赖默认值packages/daemon/src/index.ts:148读取OPENRIG_HOST绑定计划解析见packages/daemon/src/domain/bind-plan.ts(b) Bearer 令牌daemon 在该绑定下启动的强制前提且被单独证明assertBindAuthInvariant见packages/daemon/src/middleware/auth-bearer-token.ts:240-264(c) 端口分配显式宿主端口绝不用0Apple container 1.2.0 拒绝临时端口发布形式runbook 约定HOSTPORT19433(d) 探针两个运行时分支字节级一致的探针Probe 1 打/healthz无鉴权Probe 2 打受守卫的路由带 bearer二、机制 (a)绑定地址 —— 为什么容器内必须显式OPENRIG_HOST0.0.0.02.1 绑定决策的源码路径packages/daemon/src/index.ts的startServer()是守护进程的启动入口。绑定决策链如下:236读取端口OPENRIG_PORT/RIGGED_PORT默认7433:239通过resolveDaemonDbPath将数据库锚定在OPENRIG_HOME下避免裸 CWD 相对文件名误开共享 fleet 库:265-269调用resolveBindPlan生成绑定计划:284-295依据计划进入显式绑定分支执行assertBindAuthInvariant强制 bearer 校验或默认分支回环探测到的 tailscale 接口多绑定:317-365对每个绑定 host 各启动一个serve()实例Hono 的hono/node-server共享同一个 Hono app。2.2 一个必须注意的演进OPENRIG_HOST已被降级为 ROUTING 环境变量runbook 写作时引用packages/daemon/src/index.ts:148说明OPENRIG_HOST设置时绑定该 host、未设置时默认127.0.0.1。当前源码在此基础上做了关键演进OPR.0.5.5.20见 bind-plan.ts 的注释绑定意图现在只通过专用通道OPENRIG_BIND_HOST声明OPENRIG_HOST/RIGGED_HOST被降级为路由环境变量client 端点任何受管环境都可能注入永远不参与绑定分支选择若路由环境变量被传入daemon 会打印一条 bind-provenance 日志index.ts:270-275说明它被忽略绝不静默演进动因此前父 daemon 从某个受管环境继承了OPENRIG_HOST127.0.0.1导致其 Tailscale 监听器悄然丢失operator batonqitem-20260827070400。因此在容器场景下正确且与当前源码一致的绑定声明是-e OPENRIG_BIND_HOST0.0.0.0 # 当前源码专用绑定意图通道推荐 -e OPENRIG_HOST0.0.0.0 # runbook 原文写法路由变量绑定决策已不读取无论走哪条通道其效果等价让 daemon 绑定到0.0.0.0使容器发布端口可达。绝不要使用默认绑定——默认分支只绑定127.0.0.1外加检测到的 tailscale 接口容器内的回环对宿主发布的端口探针不可达这正是旧 runbook 事故的根源。三、机制 (b)Bearer 令牌 —— 启动即强制且在真正受守卫的表面上单独证明3.1 启动期硬门禁assertBindAuthInvariantpackages/daemon/src/middleware/auth-bearer-token.ts:240-264的assertBindAuthInvariant是启动期的硬门禁HARD-GATE audit row 8。逻辑绑定127.x.x.x/::1/localhost回环→ 短路放行绑定 tailscale 网段IPv4 CGNAT100.64.0.0/10IPv6 ULAfd7a:115c:a1e0::/48→ 短路放行tailnet 自身即鉴权边界主机名绑定 → 先 DNS 解析再按上述两条重判以上均不满足即真正的公网/LAN 绑定0.0.0.0正在此列且OPENRIG_AUTH_BEARER_TOKEN为空 → 抛出AuthBearerTokenStartupErrordaemon 拒绝启动。对容器场景0.0.0.0属于非回环、非 tailscale 绑定因此必须设置非空的OPENRIG_AUTH_BEARER_TOKEN否则 daemon 启动即失败。这个拒绝正是产品诚实的体现——runbook 满足该前提而不是绕过它。3.2 已核实的更正/healthz本身是未鉴权的runbook 特别强调一个已在源码核实的更正不要为了凑预期而修改探针/healthz直接注册在 Hono app 上packages/daemon/src/server.ts:633返回健康 JSON含事件循环楔检测、bind 计划、stuck-sweep 心跳等附加字段app.use(*)server.ts:486只注入依赖到上下文不是全局鉴权中间件authBearerTokenMiddleware只挂载在六个路由模块内compaction、hosts、mission-control、rig-policy、sessions、transport。所以健康探针不需要Authorization 头也绝不能被用 Authorization 头来评分。3.3 Bearer 的单独证明面/api/transport/*runbook 将 bearer 的证明放在一个真正受守卫的表面上packages/daemon/src/routes/transport.ts:26的router.use(*, authBearerTokenMiddleware(...))守卫整个 transport 路由器包括POST /send。于是两个探针对应两个独立事实Probe 1/healthz无鉴权证明绑定/发布路径可达 daemonProbe 2受守卫路由 bearer证明鉴权路径生效负控制同一调用但不带 bearer必须返回 401证明守卫确实在守卫。只记录 Probe 1 的 runbook 根本没有测到 bearer——本 runbook 二者都记录。四、机制 (c)端口分配 —— 显式宿主端口绝不用临时端口Apple container 1.2.0 拒绝临时端口发布形式Error: invalid publish host port range: 0而 Docker 接受——这是被捕获的运行时差异见上文操作者收据。因此 runbook 固定使用一个显式端口HOSTPORT19433让两个运行时分支以完全相同的发布形式运行临时端口分配不是本次 A/B 要测量的差异。Apple 臂另有已捕获的注意点非 workaround回环限定的发布形式127.0.0.1:PORT:7433在 Apple 1.2.0 上会重置而不加限定的PORT:7433可用。因此 runbook 在两个分支上统一使用不加限定的发布形式——完全相同的输入而非 Apple 专属让步。五、完整 Setup双运行时分支的容器启动以下脚本是 L3 的容器启动部分两个分支仅RUNTIME二进制不同其余完全一致GIT_SHA$(git rev-parse HEAD); IMAGEopenrig-testbed:${GIT_SHA}; EVIDdist/testbed-image/evidence/${GIT_SHA}; mkdir -p ${EVID} NAMEorig-l3-${GIT_SHA:0:8} HOSTPORT19433 # (c) 显式端口——绝不用 0Apple 1.2.0 拒绝临时端口 TESTBEARERl3-testbed-$(date %s) # (b) 一次性、容器作用域绝不是真实凭据 RUNTIMEdocker # Apple 臂在此替换其 CLI其余全部一致 ${RUNTIME} run -d -t --name ${NAME} \ -p ${HOSTPORT}:7433 \ -e OPENRIG_HOST0.0.0.0 \ -e OPENRIG_AUTH_BEARER_TOKEN${TESTBEARER} \ -e OPENRIG_SELF_HOST_IDtestbed-l3 \ ${IMAGE}关键参数语义-p ${HOSTPORT}:7433宿主端口19433映射到容器内 daemon 默认端口7433index.ts:236的默认值不加127.0.0.1:前缀以兼容 Apple 1.2.0OPENRIG_HOST0.0.0.0让 daemon 绑定到所有接口发布端口才可达见机制 (a)当前源码推荐改用OPENRIG_BIND_HOSTOPENRIG_AUTH_BEARER_TOKEN非空才能通过assertBindAuthInvariant启动门禁见机制 (b)OPENRIG_SELF_HOST_IDtestbed-l3容器内 daemon 的自标识用于身份溯源。镜像本身由 scripts/build-testbed-image.sh 在宿主侧构建digest 钉死的 base、钉死的 Node默认22.22.1、从本地 pack tarballnpm pack安装的 openrig——绝不从 npm registry 拉取0.5.1 未发布。构建末尾还内置了 effect-proof在容器内rig daemon start --no-kernelcurl /healthz证明 better-sqlite3 原生模块在无工具链的镜像内真实可用scripts/build-testbed-image.sh:95。六、L3.1 —— daemon 在容器本地 sqlite 上启动双探针应答${RUNTIME} exec ${NAME} bash -lc rig daemon start sleep 2 rig status || true | tee ${EVID}/L3-start.txt # PROBE 1 — 绑定按设计无需鉴权 curl -fsS http://127.0.0.1:${HOSTPORT}/healthz | tee ${EVID}/L3-healthz.txt; echo # PROBE 2 — 鉴权路径在真正受守卫的路由器上 curl -sS -o ${EVID}/L3-auth-probe.txt -w %{http_code}\n \ -X POST http://127.0.0.1:${HOSTPORT}/api/transport/send \ -H Authorization: Bearer ${TESTBEARER} -H Content-Type: application/json \ -d {session:nonexistenttestbed,text:auth-path probe} | tee ${EVID}/L3-auth-code.txt # 负控制——同样调用但不带 bearer必须被拒绝 curl -sS -o /dev/null -w %{http_code}\n \ -X POST http://127.0.0.1:${HOSTPORT}/api/transport/send \ -H Content-Type: application/json -d {session:nonexistenttestbed,text:x} \ | tee ${EVID}/L3-auth-negative.txt ${RUNTIME} exec ${NAME} bash -lc ls -l ${OPENRIG_HOME:-$HOME/.openrig}/*.sqlite* 2/dev/null || find $HOME -name *.sqlite* 2/dev/null | tee ${EVID}/L3-db.txt6.1 判定标准PASS的全部条件Probe 1 在发布端口上返回健康的 JSONProbe 2不是 401bearer 被接受——未知会话返回任意应用级 4xx 仍证明鉴权路径通过负控制是 401存在容器本地的 sqlite 文件。FAIL的判定逐条对应机制失效发布端口上无 healthz → 绑定地址错机制 a 失效Probe 2 返回 401 → bearer 路径错机制 b 失效负控制不是 401 → 守卫根本没在守卫sqlite 落在容器外 / 挂载了真实 HOME → 栅栏fence被突破。6.2 探针背后的源码事实POST /api/transport/send要求session与texttransport.ts:47-49未知 session 会走应用级错误分支——所以 runbook 中的nonexistenttestbed会得到非 401 的应用级状态码恰好满足 Probe 2 的 PASS 判据负控制与 Probe 2 只差一个Authorization头authBearerTokenMiddleware在缺头时立即返回带三段式错误体的 401auth-bearer-token.ts:104-105——这就是负控制必须 401 的源码依据token 比较使用crypto.timingSafeEqual常量时间比较长度不同时也会跑一次同长度零缓冲比较以抹平时序差异auth-bearer-token.ts:36-51。七、L3.2 ——rig up落定零 token 桩拓扑7.1 桩负载的嵌套路径这是承重设计不是意外构建动词把每条 census 条目以其完整仓库相对路径复制进构建上下文scripts/build-testbed-image.sh:51-52cp ${REPO_ROOT}/${rel} ${CONTEXT}/stub-assets/${rel}Dockerfile 再把整个stub-assets/目录拷入镜像Dockerfile:52COPY stub-assets/ /opt/openrig-testbed/stub-assets/。因此容器内三件套落在/opt/openrig-testbed/stub-assets/docker/testbed/stub-assets/而不是 stub-assets 根目录。这个嵌套是承重的同一组相对路径正是 manifest 哈希进字节级可复现 census receipt 的对象scripts/build-testbed-image.sh:101经 scripts/testbed-emit-manifest.mjs 生成。若扁平化暂存路径receipt 字节就会改变导致此前 r1 验证过的收据失效。runbook 适配暂存现实暂存保持原样。这一确切故障此前已被预测并划定范围到本 runbook——51-04-STUB-ASSET-TRIO-REVIEW-VERDICT-review-r1.md标记为 Honest forward-flag只是备注一直没进正文直到现在。7.2 显式 source 参数绝不能裸跑rig uprig up的 source 是必选位置参数packages/cli/src/commands/up.ts:79.argument(source, Path to a .yaml rig spec or .rigbundle, or a library name such as secrets-manager)。裸调用会报missing required argument source退出——这正是操作者当初踩到的错误。合法形式包括rig up secrets-manager、rig up ./rig.yaml、rig up ./demo.rigbundle --target ~/work见up.ts:70-75的帮助文本。7.3 执行脚本${RUNTIME} exec ${NAME} bash -lc set -e STAGED/opt/openrig-testbed/stub-assets/docker/testbed/stub-assets # 预检栅栏在构建真正暂存的位置断言负载。暂存变更必须在此 LOUD 失败并点名路径 # 而不是在下游表现为 missing required argument。 [ -f ${STAGED}/rig.yaml ] || { echo L3.2 FAIL: no rig.yaml at ${STAGED} — staged payload moved; reconcile the runbook against scripts/build-testbed-image.sh; ls -R /opt/openrig-testbed/stub-assets | head -40; exit 1; } mkdir -p ~/work cp -r ${STAGED}/. ~/work/ cd ~/work rig up rig.yaml sleep 3 rig ps --json | tee ${EVID}/L3-topology.txt执行要点预检栅栏rig up之前先断言rig.yaml存在于暂存路径暂存布局一旦变更此处在脚本内立即失败并点名路径而不是让下游误报参数缺失实现了响亮失败显式 sourcerig up rig.yaml带显式文件参数不依赖任何库名解析容器本地工作区负载复制进~/work容器内非 root 用户openrig的 home绝不触达宿主判定rig ps --json输出中桩 seat 达到 settled/ready 状态即为 PASS——零 LLM token 消耗runtime: stub拓扑无法落定或调用了非 stub runtime 即为 FAIL。7.4 桩拓扑的三件套内容镜像内 staged 的桩资产census 范围与 runbook 论断完全一致rig.yamlversion: 0.2一个 poddev、一个成员workerruntime: stubagent_ref: local:agents/worker无边edges 为空agents/worker/agent.yaml无 skills 的最小 agent 定义culture.md工作文化提示。runbook 还提示确切的rig ps形态 / ready 判定在运行时刻对着随镜像分发的 stub adapter 落地——不要断言某个记住的字段名要读真实的--json输出。八、Teardown 与证据汇总${RUNTIME} exec ${NAME} bash -lc rig down || true ; ${RUNTIME} rm -f ${NAME} /dev/null { grep -qi health ${EVID}/L3-healthz.txt \ [ $(cat ${EVID}/L3-auth-code.txt) ! 401 ] \ [ $(cat ${EVID}/L3-auth-negative.txt) 401 ] \ echo VERDICT: PASS — published bind reachable, bearer path proven, negative control refused, stub topology settles \ || echo VERDICT: FAIL — see L3-*.txt; } | tee ${EVID}/L3-verdict.txt证据文件全部落在dist/testbed-image/evidence/${GIT_SHA}/下与镜像同 sha 关联形成字节级可追溯的证据链文件内容判定角色L3-start.txtrig daemon startrig status输出启动路径证据L3-healthz.txtProbe 1 健康 JSON绑定/发布路径L3-auth-code.txtProbe 2 HTTP 状态码应非 401鉴权路径L3-auth-negative.txt负控制状态码应恰为 401守卫有效性L3-db.txt容器本地 sqlite 列表数据隔离栅栏L3-topology.txtrig uprig ps --json输出零 token 拓扑落定L3-verdict.txt自动判定的 PASS/FAIL汇总裁决九、验收门ACCEPTANCE GATE先让 Docker 臂单独全绿验收门是不可协商的先只在Docker臂上跑完整流程并证明 GREEN——一个过不了的对照组不是对照组A/B 在 Docker 基线按本手册原文全绿之前保持阻塞只有在那之后Apple 臂才以替换 CLI 的方式跑完全相同的流程。这也是本 runbook 最值得借鉴的工程纪律控制组必须能通过才能评判实验组。任何修复探针去匹配错误预期的做法都被明确禁止——探测对象是源码事实/healthz未鉴权、transport 守卫全路由runbook 顺应事实而不是让事实迁就脚本。十、证据路径索引便于继续深入源码守护进程启动与绑定packages/daemon/src/index.ts端口默认值:236、绑定计划解析:265-269、显式/默认绑定分支:284-295、多绑定 serve:317-365绑定计划解析与OPENRIG_HOST降级说明packages/daemon/src/domain/bind-plan.tsBearer 启动门禁与中间件packages/daemon/src/middleware/auth-bearer-token.tsassertBindAuthInvariant:240-264、常量时间比较:36-51、401 三段式错误体:57-73/healthz注册与全局中间件注入packages/daemon/src/server.tsapp.use(*)依赖注入:486、app.get(/healthz):633transport 全路由守卫packages/daemon/src/routes/transport.ts:26rig upsource 必选参数packages/cli/src/commands/up.ts:79测试床镜像构建与 stub 暂存scripts/build-testbed-image.sh暂存:51-52、manifest 哈希:101、容器内 effect-proof:95镜像层定义与 stub 拷贝docker/testbed/DockerfileCOPY stub-assets/:52桩资产清单docker/testbed/stub-assets.list、docker/testbed/stub-assets/rig.yaml、docker/testbed/stub-assets/agents/worker/agent.yaml同阶梯其他 runbookdocker/testbed/runbooks/README.md与L0-resolve-inputs.md、L1-pty-allocation.md、L2-tmux-server-lifecycle.md、L4-hermetic-fail-closed.md、L5-multi-host-and-51-09.md、L6-container-runner-e2e.md赞分享人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载相关推荐openrig-testbed 验证 Runbooks 全解析L0–L6 主机侧证据驱动测试体系与容器内 daemon 验证实践openrig testbed 验证 Runbooks 全解析L0–L6 主机侧证据驱动测试体系与容器内 daemon 验证实践本篇技术指南以 openri人工智能AI Agent多智能体Agent 编排代码智能体CLITurbo 后台守护进程turborepo-daemon架构与实现深度解析Turbo 后台守护进程turborepo daemon架构与实现深度解析导读 TurborepoRust 编写的 JavaScript / TypeS构建工具开发工具CLIOpenRIG 51-02 Hermetic Fail-Closed 验证容器内拒绝外来 Daemon 目标L4 运行手册深度解析OpenRIG 51 02 Hermetic Fail Closed 验证容器内拒绝外来 Daemon 目标L4 运行手册深度解析导读本文以 Open人工智能AI Agent多智能体Agent 编排代码智能体CLI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

openrig 测试床 runbook 深度解析：L3 daemon-in-container 容器化守护进程的零令牌拓扑验证

相关推荐

模型具备认知校准，却无法做到行动校准：伪造证据促使大模型智能体对不可知问题贸然行动

AI辅助开题报告全流程指南：从模糊想法到答辩通过

游戏藏岁月，合集留住年少欢喜

更多资讯

STM32工程文件管理实战：Keil5新建文件与头文件路径配置详解

WebSpoon 9.0部署全攻略：从源码编译到Tomcat/Docker远程调试

Spring Boot 3旅游系统实战：生产级骨架搭建与高并发避坑

线性代数学习笔记：用几何直观理解矩阵、行列式与特征值

FreeRTOS实战指南：核心机制、STM32移植与调试技巧全解析

ZKFinger SDK 5.0深度解析：Windows双模生物识别开发实战

今日更新

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

本周精选

如何彻底离线使用 Laya-CoreML：Hugging Face 下载、缓存机制与 local_files_only 详解

基于1Panel 部署MySQL MCP 服务：TaoToken 统一 Key 接入与 config.toml 配置实战

崇州园区营销网站建设避坑指南：5大注意事项保备案安全

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？