人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】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点击查看免费下载51-09 是 openrig 构建链路的第 5 个增量目标是在 QA 阶段、两台真实 daemon 之间端到端证明 sender 三元组memberrighost的身份印章。本文以仓库中随构建交付的 QA 可执行 runbookpackages/daemon/test/fixtures/self-host-live-legs/RUNBOOK.md为骨架逐段拆解其供给PROVISIONING、自证主机 ID、双向注册、LEG A 三个发送表面send / queue / broadcast与 LEG B 同名 rig 冲突的全部步骤、通过判据与失败控制并深入对应源码session-name、sender-identity、broadcast、queue-repository、require-sender-identity解释底层原理。读完本文你将掌握如何在 docker testbed 中复现这套跨主机身份验证并理解3 部分地址诚实化、2 部分静默铸造不承诺消除这一诚实范围的由来。一、51-09 LIVE 证明的定位单元层已证端到端补证runbook 开篇即说明51-09 的单元层证明已经在增量 14b 落地包括持久化的自证 IDdurable self-id自解析 E1self-resolution E1注册表对齐registry alignment恒定后缀信封孪生 中继守卫always-suffix envelope twin relay guardsender 三元组写入时盖章 转发时盖章stamp-at-write stamp-at-forward目标主机教学性拒绝destination-host teaching refusal。而这两条 LIVE-LEGLEG A / LEG B要证明的是同一批行为在两端真实 daemon 之间的端到端成立——单元层证明的是行为存在LIVE 层证明的是跨链路行为一致。runbook 明确要求这些步骤由真正未暴露的 QA seat 在 live 阶段执行构建阶段不得在构建 lane 或 live seat 上运行它们do NOT run them from the build lane / against live seats during the build。二、环境与拓扑三份随 runbook 提交的 fixtureLEG 需要三台真实 rig它们作为 fixture随 runbook 一同提交在topologies/目录runbook 特别注明2026-08-07 之前这些 LEG 指向的 rig 并不存在导致此前两条 LEG 在裸容器上于供给阶段即双双失败本次修正是把 rig 提交进来文件rig规范 seatpod-memberrig主机topologies/rig-a.yamlrig-aorch-mainrig-aH_Atopologies/rig-b.yamlrig-bdev-mainrig-bH_Btopologies/shared.yamlsharedlead-mainshared两台主机都部署以rig-a.yaml为例其 fixture 结构为# 51-09 live-leg fixture — LEG A origin rig (runs on H_A) # Canonical seat pod-memberrigName (deriveCanonicalSessionName) orch-mainrig-a version: 0.2 name: rig-a culture_file: culture.md pods: - id: orch label: Orch members: - id: main agent_ref: local:agents/orch profile: default runtime: stub cwd: . edges: []rig-b.yaml结构相同seat 为dev-mainrig-bshared.yaml则刻意在两台主机上字节完全一致seat 为lead-mainshared这正是 LEG B 冲突测试的前提——详见下文。seat 名必须是派生名不可手写runbook 强调SEAT NAMES ARE THE DERIVED ONES会话名永远是deriveCanonicalSessionName(pod, member, rig) pod-memberrig像orchrig-a这种单 token 形式不可派生因此 runbook 中所有步骤都使用真实的派生名。对应实现位于 packages/daemon/src/domain/session-name.ts它是纯拼接、无归一化、无启发式export function deriveCanonicalSessionName( podName: string, memberName: string, rigName: string ): string { return ${podName}-${memberName}${rigName}; }该函数在 daemon 的多个关键链路被复用例如 rigspec-instantiator.tsseat 实例化时生成规范名、claim-service.ts、restore-orchestrator.ts。会话名字符校验由同文件的validateSessionComponents/validateSessionNameChars完成合法字符集为a-z, A-Z, 0-9, -, _, ., parseSessionName把memberrig解析为 canonical 形状且rig 段可含多个贪婪解析这是后面主机绝不内嵌进会话字符串BR-1这一契约的载荷点。三、供给PROVISIONING以产品自己的用户身份交付runbook 的供给部分包含三条核心纪律每一条都对应一个真实缺陷场景。3.1USER openrig决定了交付方式testbed 镜像在 docker/testbed/Dockerfile 中声明USER openrig与WORKDIR /home/openrig因此默认docker exec以openrig用户运行而openrig无法穿越 root 的家目录。fixture 因此必须 stage 在 openrig 用户自己的家目录下与 L3.2 已经证明过的~/work拷贝是同一姿态。绝不以 root exec 去够到它们——daemon 以openrig运行root-exec 探针测的是一个产品从不使用的用户而且恰好会掩盖这类权限缺陷。STAGE/home/openrig/topologies # openrig-readable by construction (its own home) # DELIVER AS THE PRODUCTS OWN USER. docker cp preserves ROOT ownership, which # yields a stage that is readable but NOT WRITABLE to openrig — and rig ups # pre-launch delivery WRITES into the stage (AGENTS.md), so a root-owned stage # fails EACCES before any seat exists. Tar-piping into a default docker exec # extracts AS openrig, so ownership is correct BY CONSTRUCTION — no chown step, # no root exec anywhere in the procedure (same principle as the probe: the user # the product runs as is the user that does the work). SRCpackages/daemon/test/fixtures/self-host-live-legs/topologies for h in H_A H_B; do docker exec $h mkdir -p ${STAGE} tar -C ${SRC} -cf - . | docker exec -i $h tar -C ${STAGE} -xf - done这里的关键洞察docker cp保留root 属主会得到一个对openrig可读但不可写的 stage而rig up的启动前交付pre-launch delivery会向 stage 写入AGENTS.md所以 root 属主的 stage 在任何 seat 存在之前就以EACCES失败。改用 tar 管道 默认docker exec提取属主按构造即为openrig——全程无 chown、无 root exec。3.2 预检围栏PRE-FLIGHT FENCE用做来探测不用读权限位runbook 强调stage 不只是被读取rig up的启动前交付还会写入它因此只读式 staging 会通过读围栏、随后在 EACCES 处失败。围栏的两个半边都用真实操作touch/rm探测而非读 mode bit——mode bit 在属主、ACL 或只读挂载下可能说谎for h in H_A H_B; do AS$(docker exec $h id -un) docker exec $h test -r ${STAGE}/shared.yaml || { echo ABORT: ${STAGE}/shared.yaml not READABLE as ${AS} on ${h} — image declares USER openrig (Dockerfile:61); stage where that user can read, never exec as root; docker exec $h ls -la ${STAGE} 21 | head -20; exit 1; } docker exec $h sh -c touch ${STAGE}/.fence-write rm -f ${STAGE}/.fence-write || { echo ABORT: ${STAGE} not WRITABLE as ${AS} on ${h} — rig up delivers AGENTS.md into the stage, so a root-owned (docker cp) stage fails EACCES at instantiate; deliver as the exec user (tar-pipe), never chown mid-proof; docker exec $h ls -lad ${STAGE} 21; docker exec $h ls -la ${STAGE} 21 | head -20; exit 1; } done3.3 字节一致性BYTE-IDENTITY是冲突的前提——断言它不要假设它shared.yaml是一个文件复制到两台主机。runbook 在两条 LEG 运行前先按哈希校验二者相等# ASSERT byte-identity of the collision spec across hosts, BEFORE any leg runs SA$(docker exec H_A sha256sum ${STAGE}/shared.yaml | cut -d -f1) SB$(docker exec H_B sha256sum ${STAGE}/shared.yaml | cut -d -f1) [ $SA $SB ] || { echo ABORT: shared.yaml differs across hosts ($SA vs $SB) — the collision premise is void; exit 1; }随后在两端分别rig up全部三份拓扑docker exec H_A bash -lc cd ${STAGE} rig up rig-a.yaml rig up shared.yaml docker exec H_B bash -lc cd ${STAGE} rig up rig-b.yaml rig up shared.yaml四、自证主机 IDADOPT-BY-READ唯一共享流程两条 LEG 都依赖主机 ID来断言来源主机。runbook 要求使用与 L3/L5相同的身份解析方式从 daemon 自己的表面捕获绝不预测也绝不使用rig whoami——rig whoami报告的是seat身份而主机没有 seat它无法回答我是哪台主机。ID_A$(docker exec H_A bash -lc curl -fsS http://127.0.0.1:7433/healthz | python3 -c import json,sys; print(json.load(sys.stdin).get(selfHostId,))) ID_B$(docker exec H_B bash -lc curl -fsS http://127.0.0.1:7433/healthz | python3 -c import json,sys; print(json.load(sys.stdin).get(selfHostId,)))下文所有A/B均指捕获到的${ID_A}/${ID_B}——因为这些 ID每次启动随机生成绝不能硬编码或预测。这对应 51-09 增量 1 的永不重写的单例语义selfHostId在 daemon 侧铸造并持久化且在同一容器内 daemon 重启后保持稳定。/healthz的selfHostId字段在 packages/daemon/src/server.ts 附近发出L5 runbookdocker/testbed/runbooks/L5-multi-host-and-51-09.md还专门记录了一条 PM 裁决OPENRIG_SELF_HOST_ID不是旋钮——entrypoint 只是把它回显到docker logsdaemon 并不读取它。五、注册必须是双向的REGISTRATION IS BIDIRECTIONALL5.2 在 H_A 上注册 H_B使出站发送可解析。但两条 LEG 还要求逐字回复从 H_B 回到 H_A——这需要 H_A 从 H_B 可解析。因此必须用同一套 adopt-by-read 流程反向注册只注册单方向的 LEG 会在回复步骤死掉而不是在发送步骤。# forward (H_B known to H_A) — as L5.2 does: docker exec H_A bash -lc rig host add --id ${ID_B} --transport http --url http://H_B:7433 --bearer-env OPENRIG_AUTH_BEARER_TOKEN rig host ls --json # REVERSE (H_A known to H_B) — required by the reply half of both legs: docker exec H_B bash -lc rig host add --id ${ID_A} --transport http --url http://H_A:7433 --bearer-env OPENRIG_AUTH_BEARER_TOKEN rig host ls --json注意 bearer 的传递方式注册行携带的是bearer 指针--bearer-env指定的环境变量名而不是 token 值本身见 L5 runbook 对该语法的说明对应 packages/cli/src/commands/host.ts--id与--transport必填http 传输取--url。这台测试床的两容器启动参数OPENRIG_HOST0.0.0.0、OPENRIG_AUTH_BEARER_TOKEN与守卫逻辑auth-bearer-token.ts在 L5 runbook 中有完整可复现脚本这里是其直接消费者。六、LEG A跨主机盖章三元组——两个表面、两个动词runbook 解释了这个 LEG 为何被拆分为三个子 LEG。锁定证明契约第 3 条原文为ALWAYS: send, broadcast, and queue sender surfaces all render the sender triple memberrighost unconditionally — local sends included — with the host token in one fixed deterministic position.它点名三个发送表面所以该性质不是某处有一个身份而是同一三元组在每个表面上独立出现。早期单 LEG 形式用rig sendtransport驱动、然后断言转发 qitem 上的存储source_sessionqueue——这是两个动词够不到的两个不同存储rig send根本不创建 queue 行所以那个断言只能读到零行。runbook 据此立下铁律动作必须匹配断言——绝不要从渲染出的终端信封推断一条 queue 记录每个表面都由真正写它的动词来证明。FixtureoriginH_A${ID_A}、destinationH_B${ID_B}seat 为 H_A 上的orch-mainrig-a与 H_B 上的dev-mainrig-b两方向均已注册回复半边依赖反向行。LEG A1 — transport 表面rig send渲染信封 逐字回复自证 ID 来自上文 adopt-by-read 捕获${ID_A}/${ID_B}不是rig whoami它回答 seat主机没有 seat。在 H_A 上以orch-mainrig-a身份执行rig send dev-mainrig-b ping --host B。在 H_B 上捕获dev-mainrig-b的 pane。期望From: orch-mainrig-a${ID_A}——origin 主机绝不出现${ID_B}。将↩ Reply: rig send orch-mainrig-a${ID_A} ...提示逐字复制并在 H_B 上执行。期望它路由到 H_A 并投递给orch-mainrig-a而不是一个本地同名者。A1 通过判据渲染签名点名${ID_A}逐字回复落在 H_A 上。A1 不对 queue 做任何断言——rig send不产生 qitem声称有 queue 记录就是把存储从渲染里推断出来。失败开放控制fail-open control停掉 H_A 的 daemon重做步骤 2 →From:降级为 2 部分形式不崩溃对应增量 3 的 C1。LEG A2 — queue 表面rig queue create --host持久化的存储溯源锁定契约把 queue sender 表面单列而只有 queue 动词写 queue 行。因此驱动真实的跨主机 queue 写入并对行本身断言# from H_A, create a qitem ON H_B with a unique body (the discriminator) export BODYlega2-$(date %s) # exported: the python assertion below reads it from the environment docker exec H_A bash -lc rig queue create --source orch-mainrig-a --destination dev-mainrig-b --host ${ID_B} --summary leg-a2 provenance --body ${BODY} # assert on H_Bs DURABLE row — the stored identity, not a rendered line docker exec H_B bash -lc rig queue list -A --json | python3 -c import json,sys,os rows[q for q in json.load(sys.stdin) if os.environ[BODY] in (q.get(body) or )] assert len(rows)1, fexpected exactly 1 row for the discriminator, got {len(rows)} rrows[0]; print(sourceSession:, r.get(sourceSession), | tags:, r.get(tags)) A2 通过判据唯一 body 恰好匹配一行其存储的sourceSession是点名origin的主机限定三元组orch-mainrig-a${ID_A}增量 4a 的 stamp-at-forward随行交付的from-host:tag 存在且未变锁定契约第 6 条。A2 不对 pane 做任何断言——信封是 A1 的表面。LEG A3 — broadcast 表面rig broadcast --host第 3 条点名的第三个表面runbook 用一段 PM 裁决解释了为什么这是 LIVE-LEG 而不能被已有测试覆盖所替代测试侧的读数建立在 send 与 broadcast 共享同一组合咽喉composition chokepoint上但在关键处并非如此——broadcast 的envelopeSender是客户端从原始 env 书写的且会落到字面unknown sender兜底packages/cli/src/commands/broadcast.ts其溯源路径与 send在种类上就不同。因此 live 的 send 捕获证明不了 broadcast而且没有任何 hermetic 测试断言 broadcast 的 sender 三元组已检索pane-envelope.test.ts/send-header.test.ts中的 broadcast 用例只断言To:scope 行三元组套件self-host-envelope-triple.test.ts/-sweep.test.ts直接驱动共享 root未命名任何 broadcast 用例。# (i) STAMP PATH, NOT FALLBACK: set the sender env EXPLICITLY. Without this the container # exec may carry no OPENRIG_SESSION_NAME and the capture would render unknown sender — # testing the fall-open instead of the property, a fixture defect wearing a product face. export BBODYlega3-$(date %s) docker exec -e OPENRIG_SESSION_NAMEorch-mainrig-a H_A bash -lc \ rig broadcast --rig rig-b --host ${ID_B} broadcast triple probe ${BBODY} | tee ${EVID}/L5-leg-a3-send.txt # capture the RECIPIENT pane on H_B and assert the full triple, host token in its fixed position docker exec H_B bash -lc rig capture dev-mainrig-b | tee ${EVID}/L5-leg-a3-recv.txt grep -q From: orch-mainrig-a${ID_A} ${EVID}/L5-leg-a3-recv.txt || { echo LEG A3 FAIL: recipient envelope does not carry the ORIGIN triple orch-mainrig-a${ID_A}; exit 1; } grep -q unknown sender ${EVID}/L5-leg-a3-recv.txt { echo LEG A3 FAIL: rendered the FALL-OPEN sender — the capture tested the fallback, not the stamp path (set OPENRIG_SESSION_NAME on the exec); exit 1; }A3 通过判据逐字引用锁定契约第 3 条作为谓词收件方渲染信封携带 sender 三元组memberrighost——orch-mainrig-a${ID_A}——无条件……且 host token 位于一个固定确定位置点名origin主机绝不出现${ID_B}也绝不出现兜底字面量。P21 CENSUS 观察记录在案不作为 LEG 门槛broadcast 的envelopeSender是从原始 env 客户端书写、带unknown sender兜底的——是 body-identity 类中的第 14 号 census 位点。本 LEG 通过钉死 env 来测试盖章路径溯源问题本身属于 P21 的合并扫荡不属于本 LEG 的裁决范围。从源码看A3 的钉死操作直接对应 sender 解析链路packages/cli/src/sender-identity.ts 中resolveSenderSession()读取OPENRIG_SESSION_NAME兼容旧名RIGGED_SESSION_NAMESENDER_FALLBACK unknown sender是唯一的兜底字面量定义点——send.tswrapSendBody与broadcast.ts信封化扇出标记都导入这同一 CLI 源头任何在 src 中出现的第三个字面量定义都会被send.test.ts的 canonicity 守卫按名捕获。broadcast 侧的赋值即 broadcast.ts:133 的body.envelopeSender seatSender ?? SENDER_FALLBACK;跨主机直连路径 broadcast.ts:196 同构——这正是 runbook 所说P18 递送并标记deliver-and-label语义env 缺失时 broadcast照常投递并携带诚实标记而不是拒绝。七、LEG B创始人冲突FOUNDER-COLLISION证明项 5E2 类杀手主张当两台主机存在同名 rig时接收到的签名点名 origin回复落在 origin 主机上而不是本地同名者。Fixture名为shared的 rig 同时存在于H_A自证 IDA与H_B自证 IDB每台主机各有一个lead-mainsharedseatH_B已在H_A上注册为B。步骤在 H_A 上以lead-mainshared身份执行rig send lead-mainshared collision test --host B。在 H_B 上捕获lead-mainshared。期望From: lead-mainshared${ID_A}——origin 主机消歧了两个同名 rig这正是创始人叙述的冲突现在诚实可观测。在 H_B 上执行逐字↩ Reply: rig send lead-mainshared${ID_A} ...。期望它落在 H_A 的lead-mainshared后继/回复跟随三元组点名的 host不是H_B 上同名的lead-mainshared。负面用例D10 诚实范围从 H_B 执行rig send lead-mainshared x裸地址无--host→ 在 H_B 的shared上本地铸造LOCALLY mint。这是预期行为且不由本 slice 修复——2 部分同名歧义只能通过--host/ sender 侧三元组闭合daemon 的教学性拒绝只针对 3 部分lead-mainsharedX形式unknown_destination_rig use --host。须在证明中如实声明51-09 让 3 部分诚实化并给出教学但不神奇地消灭 2 部分静默铸造。通过判据跨主机签名点名 origin逐字回复往返到 origin 主机D10 负面用例被记录在案而非宣称已被消除。LEG B 的教学性拒绝在源码中确有对应实现packages/daemon/src/domain/queue-repository.ts 中 51-09 增量 4b 添加的 additive teaching对未知目的 rig 拒绝并给出unknown_destination_rig错误码queue.ts:142映射为 HTTP 400提示use --host而对memberrighost这类 3 部分形状require-sender-identity.ts 的canonicalSenderSession只对本机后缀做归一化本地 seat 裸形memberrig外来 host 限定符原样保留、目的地址绝不自动剥离——这正是3 部分诚实、2 部分不承诺的边界在代码中的落点。八、C5 诚实范围承自裁决 c9964404runbook 收尾明确划界origin-host-in-sender-identity 这个 slice 使 3 部分形状的主机盲寻址不可能被静默书写恒定后缀From: 回复往返 教学性拒绝三件套。而2 部分同名静默铸造D10由--host信封 sender 侧剥离增量 3闭合不是由 daemon 内的字符串解释器闭合。上述两条 LEG 的证明正是这么说的LEG B 步骤 4。这一诚实范围的工程意义在于系统不假装消灭了所有歧义而是把能被诚实证明的3 部分形状与只能靠操作纪律约束的2 部分裸地址清晰分离并在证明文档中逐字声明。配合pane-envelope.test.ts/send-header.test.ts信封渲染与头、self-host-envelope-triple.test.ts/-sweep.test.ts三元组套件与self-host-triple.test.ts等测试用例读者可以沿 docker/testbed/runbooks/ 的 L3→L4→L5 路径完整复现这套多主机身份验证体系。九、总结这套 runbook 教给我们的三件事身份必须被捕获不能被预测主机 ID 从/healthz的selfHostId读取、seat 名由deriveCanonicalSessionName派生、reply 提示逐字执行——每一个身份都从系统自己的表面取杜绝硬编码与单 token 手写。动作必须匹配断言send 不写 queue 行broadcast 的 sender 溯源路径与 send 在种类上不同三个发送表面各自由真正写它的动词独立证明绝不从渲染推断存储。诚实范围是产品的一部分3 部分形状被教学性拒绝与回复往返彻底闭合2 部分同名静默铸造被明确标记为不承诺消除——工程证明与源码queue-repository 的 teaching、require-sender-identity 的归一化边界彼此印证构成一份可执行、可复现、可引用的跨主机身份验证文档。赞分享人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】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 L5 多主机拓扑验证用 Docker 网络模拟 N 个命名自宿主机并执行 51-09 跨主机实况用例OpenRig L5 多主机拓扑验证用 Docker 网络模拟 N 个命名自宿主机并执行 51 09 跨主机实况用例 导读 本文档是 OpenRig 仓库人工智能AI Agent多智能体Agent 编排代码智能体CLIPaddleSpeech 端到端 ASR 解码核心beam_search 模块原理与源码级解析PaddleSpeech 端到端 ASR 解码核心beam_search 模块原理与源码级解析 导读 本文聚焦 PaddleSpeech 中 paddlesp人工智能语音音频openrig testbed 容器模式端到端验证L6按镜像清单身份驱动真实场景、主机模式字节级对等与失败关闭openrig testbed 容器模式端到端验证L6按镜像清单身份驱动真实场景、主机模式字节级对等与失败关闭 本指南基于 openrig 仓库 dock人工智能AI Agent多智能体Agent 编排代码智能体CLI上一篇meilisearch-php动态搜索规则如何实现个性化搜索体验的5个步骤下一篇PyGWalker 安装部署完整指南3 条路线快速上手创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考