拓冰网站定制 
人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载openrigMulti-agent harness将 Claude Code 与 Codex 组织为一个统一系统在 release-0.5.4 的 Wave 1 S3 中定义了一个名为Delivery Honesty交付诚实的切片Slice 06其核心主张是Sent 必须意味着 CONSUMED被对方真正消费而绝不仅仅是 typed文本被敲进了终端。本文基于仓库中的规格文档 .evidence/SPEC-before-F4-amendment.mdOPR.0.5.4.6结合 CLI 与 daemon 两端的真实实现完整讲解send --verify如何通过 pane 效果区分已消费与暂存未提交staged、如何诚实报告检测证据以及如何用单次 Enter 提交路径作为唯一补救手段而绝不盲目重发。读完本文你将掌握 openrig 交付验证的完整机制、底层判定算法与可验证的测试证据。背景为什么 Sent 可能撒谎在多 Agent 协作场景中一个 Agentseat向另一个 Agent 的终端发送指令是家常便饭。但 openrig 在 0.5.3 的实际运行中发现了两个真实的交付谎言send-staging 现象文本被发送后停留在对方的输入提示符prompt处处于暂存staged状态——打字了但没有提交。对方从未真正消费这条消息而发送方却看到了已发送/已通过验证。T1 walk saga在 walk 流程逐段投递并逐段验证中这种 staged 文本造成的误解被完整记录下来度量了它的真实成本。当时的处理方式是座位纪律seat lore操作者需要自己capture 看一眼来区分文本是否被消费出了问题就盲目重发结果常常双重投递double-deliver。0.5.4 的 S3 切片OPR.0.5.4.6正是要把这条纪律从人工经验升级为产品行为由产品自己检测并诚实报告 staged 状态让发送这个动词恢复它应有的含义。核心意图与设计约束规格文档开宗明义Sent must mean CONSUMED, never merely typed。这意味着send --verify必须按效果effect判断消息是否被消费——即检查对方 pane 在发送后的实际状态而不是依赖传输层的返回码。文档特别强调传输返回码的负向信号被度量过、并不可靠例如超时可能发生在消息已经送达之后两条真实案例证明了报未发送但实际已投递。整个切片遵循四条 mini-requirements按效果区分send --verify通过 pane 发送后的状态区分 CONSUMED 与 STAGED把 walk 已泛化的模式推广到普通发送永远不依赖传输返回码。诚实报告staged-unsent 检测报告必须诚实——说明检查了什么checked与观察到了什么observed补救面是现有的 submit 路径不重发、不双重投递。领域边界只涉及packages/daemon/src/routes/transport.ts、packages/cli/src/commands/send.ts、packages/cli/src/commands/broadcast.ts及它们对应的聚焦测试。保持接缝S2 切片OPR.0.5.4.3确立的 unknown-sender 行为是基础本切片不重新打开它door07 证据链继续有效。文档还记录了一条重要的纪律性表达现在变成了产品行为而非人工常识text sitting AT the prompt staged, not consumed; the fix is one Enter, not a re-send实现剖析CLI 端的交付效果分类效果判定的主战场在 packages/cli/src/commands/send.ts。rig send命令在--verify选项下在输出编码之前先做效果分类源码注释称为 r2 F2确保人类可读输出、--json输出与 fan-out 输出渲染的是同一条效果真相。从传输应答到效果真相发送请求返回后若--verify且传输层状态码 400CLI 调用classifyDeliveryEffectsend.ts 中的实现其流程是调用detectStagedAtPrompt探测 pane 是否残留本发送的暂存文本若探测不可用unchecked如实返回未检查及其原因若未发现暂存残留返回no-staged-residual——注意pane 重绘可能导致残留读不到因此没有残留不构成消费证明此时传输层的裁决原样保留若发现暂存残留走一次且仅一次的 guarded submit见下文然后复查一次停止。EffectCheck是一个纯分类类型无副作用、不打印type EffectCheck | { checked: true; state: staged; remedy: submitted-cleared | submitted-still-staged | submit-refused; detail?: string } | { checked: true; state: no-staged-residual } | { checked: false; why: string };关键设计staged 是唯一可以推翻传输层已发送结论的证据而未发现残留什么也不推翻见 send.ts 中的判定注释。staged 探测器只看当前输入区身份先行detectStagedAtPromptsend.ts 实现是效果判定的核心算法有三条铁律只隔离当前输入区从 pane 的最后一个提示符行❯/›开始到 pane 末尾其上方的一切都算历史scrollback历史中的占位符永远不算 staged 证据——guarded submit 绝不允许对历史开火。身份先行identity first字面残留匹配使用 daemon submit 预检查同款的归一化去掉所有空白、连续包含即stagedIdentityForsend.ts 实现产出的payloadHead用户负载头部、去空白后前 24 字符。这样探测器判为 staged与guarded submit 的预检查天然兼容。占位符归属判定输入区若出现[Pasted text #N X lines]占位符只有当其行数与本次发送的期望行数绑定|extra - expectedLines| 2且多于一行时才认定是本次发送的 staged 证据否则返回unchecked并明确声明不可验证、不作为本次发送处理、不发起提交。StagedIdentity三要素send.ts 定义字段含义用途expectedStagedTextguarded submit 预检查要验证的字节与 pane 残留逐字节比对expectedLines文本行数绑定 pasted-text 占位符的行数payloadHead负载头部去空白前 24 字符字面残留的包含匹配guarded submit单次 Enter 的补救绝不重发当 staged 被确认后CLI 通过POST /api/transport/send发起一次submitOnly: true的请求send.ts 中的调用——只敲一次 Enter不重新输入任何文本因此不可能重复投递。daemon 端在 packages/daemon/src/routes/transport.ts 中接收submitOnly、expectedStagedText、expectedStagedLineCount并透传给SessionTransporttransport.ts 中的透传 与 提交参数。真正的守卫在 packages/daemon/src/domain/session-transport.ts 的 submitOnly 分支中约 第 855-963 行submitOnly发送时text 参数必须为空否则拒绝invalid_submit_only必须提供expectedStagedText因为Enter 只能落在完全一致的暂存内容上提交前预检查 pane 是否真的显示了期望的暂存文本不匹配则拒绝提交——在这里按 Enter 可能驱动完全不同的东西什么都不会被提交staged_mismatchHTTP 409Enter 实际落地后若失败返回submit_failedHTTP 502。CLI 端对补救结果做一次复查输出三种诚实结局send.ts 中的 renderersubmitted-cleared一次 guarded Enter 提交暂存文本离开提示符已消费submitted-still-staged提交了但文本仍在提示符——不是已消费停在这里单次提交是契约提示rig capture session人工检查submit-refused单次 guarded Enter 被拒绝如预检查不匹配同样停下绝不重试。任何未以submitted-cleared收场的 staged 都通过effectUnresolvedsend.ts 定义被判定为非静默失败人类输出设置非零退出码--json输出的信封里携带verified: false与outcome: staged-not-consumed不再附带任何 delivered 声明。三种输出编码同一条效果真相S3 的一个关键修复是让所有输出路径渲染同一条效果真相人类路径Verified: no之后紧跟三行式报告例如Delivery: staged, not consumed (checked: post-send pane capture; observed: the sent text is still at the prompt — typed, never submitted) Remedy: one guarded Enter submitted — the staged text left the prompt.Verified: yes行被保留逐字不变因为现有脚本会 grepVerified:真正的三态词汇在随后的Delivery:行delivered/rendered-unconfirmed/ staged 报告。--json路径信封内携带effectCheck字段staged 未解决时强制verified: false、outcome: staged-not-consumed退出码为 1。fan-out 路径rig send --to/--pod/--rig --verify对每个成功投递的接收者逐一做 pane 效果分类daemon 逐个包裹信封因此 guarded submit 的期望文本就是裸负载包裹渲染天然包含它。任何 staged 未解决的接收者该行输出staged, not consumed不再称其为 sent汇总行的 delivered 计数会扣除 staged 未解决者send.ts 中的聚合逻辑--json的机器可读聚合从分类后的编码结果推导绝不引用原始传输计数send.ts 中的 F1 实现。跨主机边界诚实的未检查效果检查是 pane 级的而跨主机发送--host含 ssh 与 http 两种传输无法在本机运行远程 pane 检查。实现选择诚实声明未检查而不是假装验证send.ts 中 ssh 路径说明 与 http 路径说明http 路径在--verify时输出Verified:与Delivery:的远程路由原始裁决远程权威、逐字呈现并追加一行Effect: UNCHECKED — the pane-effect check does not run cross-host; the verdict above is transport-level only.--json信封同样携带effectCheck: { checked: false, why: cross-host http — the pane-effect check does not run cross-host }。这延续了本切片的诚实基调能验证就验证验证不了就明说验证不了绝不把传输层裁决包装成消费证明。与传输失败处理的衔接本切片还明确了传输失败与staged两类情形的边界send.ts 中的 printTransportFailure超时 交付未确认delivery-UNCONFIRMEDdaemon 可能已收到并投递两条真实案例证明了报未发送后实际已送达因此补救建议是先按效果核对再考虑重发rig capture session绝不诱导盲目重发硬连接失败 未发送才给出was not sent的结论与诊断路径检查OPENRIG_URL/RIGGED_URL、daemon.host/port确认后rig daemon start。两类输出都遵循事实/后果/行动fact / consequence / action三段式--json下输出可解析的结构化信封。Proof Contract四项可验证契约规格文档定义了四个证明项全部可以在 packages/cli/test/send.test.ts 的 S3 — delivery honesty (OPR.0.5.4.6) 测试分组中找到对应用例STAGED-UNSENT DETECTED BY EFFECTPROOF-1文本落在提示符staged、未消费时send --verify如实报告 staged——判别证据是 pane 效果不是传输返回。CONSUMED MEANS CONSUMEDPROOF-2真正被消费的发送验证为正向两种结局绝不可互换staged 报告必须点名检查了什么。NO DOUBLE DELIVERYPROOF-3staged 的补救是 submit 路径单次 Enter测试断言普通发送含hello there文本的 POST恰好一次、submitOnly提交恰好一次产品从不建议盲目重发。INTERIM LORE RETIRED产品自身的报告使旧的座位纪律暂存在提示符修复是敲一次 Enter不再必要并在传授该纪律的 guidance 中记录退役按路径引用。测试还覆盖了防御性细节send.test.ts 相关用例scrollback 中的过期占位符不构成staged 证据不触发报告、不触发 guarded submit--json --verify信封携带效果分类且 staged 未解决时退出码为 1fan-out 逐接收者报告效果、staged 命名、已消费者绝不被称 staged。实操速查rig send --verify的完整参数面结合 send.ts 命令定义与交付验证相关的完整选项如下选项作用与 Delivery Honesty 的关系--verify发送后检查 pane 是否出现内容本切片的主角发送后做 pane 效果分类--wait-for-idle 秒目标明确空闲后再发送可与--verify组合不能与--force/--dangerously-interact组合--force向后兼容空操作忙碌 pane 默认带提示发送永不绕过交互提示/权限守卫--raw发送精确文本/按键不带 From/To 信封仍受守卫--dangerously-interact --reason why刻意驱动交互提示/权限块唯一绕过守卫的开关要求 reason写入审计日志--jsonAgent 可解析的 JSON 输出携带effectCheck、verified、outcome字段--host id跨主机发送效果检查跨主机不运行输出Effect: UNCHECKED典型组合# 单席位发送并验证 pane 效果staged 会自动走单次 Enter 提交 rig send dev-implmy-rig Context update: QA approved. Proceed. --verify # 等待空闲后发送并验证 rig send dev-implmy-rig safe proof prompt --wait-for-idle 30 --verify # fan-out 到两个席位逐接收者报告效果 rig send --to dev-implmy-rig,dev-qamy-rig message to two seats --verify # Agent 消费的结构化输出 rig send dev-implmy-rig message --json # 跨主机http 注册主机远程权威裁决 诚实的 UNCHECKED 声明 rig send --host remote-dev dev-implmy-rig remote message --verifystaged 场景下的输出形态Sent to dev-implmy-rig Verified: no Delivery: staged, not consumed (checked: post-send pane capture; observed: the sent text is still at the prompt — typed, never submitted) Remedy: one guarded Enter submitted — the staged text left the prompt.小结Delivery HonestyOPR.0.5.4.6把 openrig 的交付语义从传输层说成功就算成功升级为pane 效果证明已消费才算成功探测器只认当前输入区的真实证据、身份先行防止误判他人的暂存内容、guarded submit 以expectedStagedText预检查保证单次 Enter 只落在本次发送的文本上、所有输出编码渲染同一条效果真相跨主机场景则诚实声明未检查。四个 proof contract 项均以聚焦测试锁定使Sent means consumed从口号变成可验证、可回归的产品契约。对于任何依赖 Agent 间可靠指令传递的编排场景send --verify都是消除暂存即假装已发送这一整类误会的标准工具。赞分享人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载相关推荐Scenario: Send a chat message and verify responseScenario: Send a chat message and verify response Steps 1. Type explain the cod开发工具代码编辑器ChatGLM3-6B Code Interpreter 部署实战让大模型真正动手执行代码ChatGLM3 6B Code Interpreter 部署实战让大模型真正动手执行代码 本文是一篇基于《开源大模型食用指南》self llm 项目教程大模型本地部署微调GraphRAG实体消歧技术如何让AI真正理解文本中的多义实体GraphRAG实体消歧技术如何让AI真正理解文本中的多义实体 你是否遇到过这样的情况AI系统把苹果理解为水果而实际上上下文讨论的是科技公司或者AI人工智能RAG知识图谱数据工程大模型创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 openrig Delivery Honesty 实战解析：用 `send --verify` 让 “Sent“ 真正代表 “已消费“
人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载openrigMulti-agent harness将 Claude Code 与 Codex 组织为一个统一系统在 release-0.5.4 的 Wave 1 S3 中定义了一个名为Delivery Honesty交付诚实的切片Slice 06其核心主张是Sent 必须意味着 CONSUMED被对方真正消费而绝不仅仅是 typed文本被敲进了终端。本文基于仓库中的规格文档 .evidence/SPEC-before-F4-amendment.mdOPR.0.5.4.6结合 CLI 与 daemon 两端的真实实现完整讲解send --verify如何通过 pane 效果区分已消费与暂存未提交staged、如何诚实报告检测证据以及如何用单次 Enter 提交路径作为唯一补救手段而绝不盲目重发。读完本文你将掌握 openrig 交付验证的完整机制、底层判定算法与可验证的测试证据。背景为什么 Sent 可能撒谎在多 Agent 协作场景中一个 Agentseat向另一个 Agent 的终端发送指令是家常便饭。但 openrig 在 0.5.3 的实际运行中发现了两个真实的交付谎言send-staging 现象文本被发送后停留在对方的输入提示符prompt处处于暂存staged状态——打字了但没有提交。对方从未真正消费这条消息而发送方却看到了已发送/已通过验证。T1 walk saga在 walk 流程逐段投递并逐段验证中这种 staged 文本造成的误解被完整记录下来度量了它的真实成本。当时的处理方式是座位纪律seat lore操作者需要自己capture 看一眼来区分文本是否被消费出了问题就盲目重发结果常常双重投递double-deliver。0.5.4 的 S3 切片OPR.0.5.4.6正是要把这条纪律从人工经验升级为产品行为由产品自己检测并诚实报告 staged 状态让发送这个动词恢复它应有的含义。核心意图与设计约束规格文档开宗明义Sent must mean CONSUMED, never merely typed。这意味着send --verify必须按效果effect判断消息是否被消费——即检查对方 pane 在发送后的实际状态而不是依赖传输层的返回码。文档特别强调传输返回码的负向信号被度量过、并不可靠例如超时可能发生在消息已经送达之后两条真实案例证明了报未发送但实际已投递。整个切片遵循四条 mini-requirements按效果区分send --verify通过 pane 发送后的状态区分 CONSUMED 与 STAGED把 walk 已泛化的模式推广到普通发送永远不依赖传输返回码。诚实报告staged-unsent 检测报告必须诚实——说明检查了什么checked与观察到了什么observed补救面是现有的 submit 路径不重发、不双重投递。领域边界只涉及packages/daemon/src/routes/transport.ts、packages/cli/src/commands/send.ts、packages/cli/src/commands/broadcast.ts及它们对应的聚焦测试。保持接缝S2 切片OPR.0.5.4.3确立的 unknown-sender 行为是基础本切片不重新打开它door07 证据链继续有效。文档还记录了一条重要的纪律性表达现在变成了产品行为而非人工常识text sitting AT the prompt staged, not consumed; the fix is one Enter, not a re-send实现剖析CLI 端的交付效果分类效果判定的主战场在 packages/cli/src/commands/send.ts。rig send命令在--verify选项下在输出编码之前先做效果分类源码注释称为 r2 F2确保人类可读输出、--json输出与 fan-out 输出渲染的是同一条效果真相。从传输应答到效果真相发送请求返回后若--verify且传输层状态码 400CLI 调用classifyDeliveryEffectsend.ts 中的实现其流程是调用detectStagedAtPrompt探测 pane 是否残留本发送的暂存文本若探测不可用unchecked如实返回未检查及其原因若未发现暂存残留返回no-staged-residual——注意pane 重绘可能导致残留读不到因此没有残留不构成消费证明此时传输层的裁决原样保留若发现暂存残留走一次且仅一次的 guarded submit见下文然后复查一次停止。EffectCheck是一个纯分类类型无副作用、不打印type EffectCheck | { checked: true; state: staged; remedy: submitted-cleared | submitted-still-staged | submit-refused; detail?: string } | { checked: true; state: no-staged-residual } | { checked: false; why: string };关键设计staged 是唯一可以推翻传输层已发送结论的证据而未发现残留什么也不推翻见 send.ts 中的判定注释。staged 探测器只看当前输入区身份先行detectStagedAtPromptsend.ts 实现是效果判定的核心算法有三条铁律只隔离当前输入区从 pane 的最后一个提示符行❯/›开始到 pane 末尾其上方的一切都算历史scrollback历史中的占位符永远不算 staged 证据——guarded submit 绝不允许对历史开火。身份先行identity first字面残留匹配使用 daemon submit 预检查同款的归一化去掉所有空白、连续包含即stagedIdentityForsend.ts 实现产出的payloadHead用户负载头部、去空白后前 24 字符。这样探测器判为 staged与guarded submit 的预检查天然兼容。占位符归属判定输入区若出现[Pasted text #N X lines]占位符只有当其行数与本次发送的期望行数绑定|extra - expectedLines| 2且多于一行时才认定是本次发送的 staged 证据否则返回unchecked并明确声明不可验证、不作为本次发送处理、不发起提交。StagedIdentity三要素send.ts 定义字段含义用途expectedStagedTextguarded submit 预检查要验证的字节与 pane 残留逐字节比对expectedLines文本行数绑定 pasted-text 占位符的行数payloadHead负载头部去空白前 24 字符字面残留的包含匹配guarded submit单次 Enter 的补救绝不重发当 staged 被确认后CLI 通过POST /api/transport/send发起一次submitOnly: true的请求send.ts 中的调用——只敲一次 Enter不重新输入任何文本因此不可能重复投递。daemon 端在 packages/daemon/src/routes/transport.ts 中接收submitOnly、expectedStagedText、expectedStagedLineCount并透传给SessionTransporttransport.ts 中的透传 与 提交参数。真正的守卫在 packages/daemon/src/domain/session-transport.ts 的 submitOnly 分支中约 第 855-963 行submitOnly发送时text 参数必须为空否则拒绝invalid_submit_only必须提供expectedStagedText因为Enter 只能落在完全一致的暂存内容上提交前预检查 pane 是否真的显示了期望的暂存文本不匹配则拒绝提交——在这里按 Enter 可能驱动完全不同的东西什么都不会被提交staged_mismatchHTTP 409Enter 实际落地后若失败返回submit_failedHTTP 502。CLI 端对补救结果做一次复查输出三种诚实结局send.ts 中的 renderersubmitted-cleared一次 guarded Enter 提交暂存文本离开提示符已消费submitted-still-staged提交了但文本仍在提示符——不是已消费停在这里单次提交是契约提示rig capture session人工检查submit-refused单次 guarded Enter 被拒绝如预检查不匹配同样停下绝不重试。任何未以submitted-cleared收场的 staged 都通过effectUnresolvedsend.ts 定义被判定为非静默失败人类输出设置非零退出码--json输出的信封里携带verified: false与outcome: staged-not-consumed不再附带任何 delivered 声明。三种输出编码同一条效果真相S3 的一个关键修复是让所有输出路径渲染同一条效果真相人类路径Verified: no之后紧跟三行式报告例如Delivery: staged, not consumed (checked: post-send pane capture; observed: the sent text is still at the prompt — typed, never submitted) Remedy: one guarded Enter submitted — the staged text left the prompt.Verified: yes行被保留逐字不变因为现有脚本会 grepVerified:真正的三态词汇在随后的Delivery:行delivered/rendered-unconfirmed/ staged 报告。--json路径信封内携带effectCheck字段staged 未解决时强制verified: false、outcome: staged-not-consumed退出码为 1。fan-out 路径rig send --to/--pod/--rig --verify对每个成功投递的接收者逐一做 pane 效果分类daemon 逐个包裹信封因此 guarded submit 的期望文本就是裸负载包裹渲染天然包含它。任何 staged 未解决的接收者该行输出staged, not consumed不再称其为 sent汇总行的 delivered 计数会扣除 staged 未解决者send.ts 中的聚合逻辑--json的机器可读聚合从分类后的编码结果推导绝不引用原始传输计数send.ts 中的 F1 实现。跨主机边界诚实的未检查效果检查是 pane 级的而跨主机发送--host含 ssh 与 http 两种传输无法在本机运行远程 pane 检查。实现选择诚实声明未检查而不是假装验证send.ts 中 ssh 路径说明 与 http 路径说明http 路径在--verify时输出Verified:与Delivery:的远程路由原始裁决远程权威、逐字呈现并追加一行Effect: UNCHECKED — the pane-effect check does not run cross-host; the verdict above is transport-level only.--json信封同样携带effectCheck: { checked: false, why: cross-host http — the pane-effect check does not run cross-host }。这延续了本切片的诚实基调能验证就验证验证不了就明说验证不了绝不把传输层裁决包装成消费证明。与传输失败处理的衔接本切片还明确了传输失败与staged两类情形的边界send.ts 中的 printTransportFailure超时 交付未确认delivery-UNCONFIRMEDdaemon 可能已收到并投递两条真实案例证明了报未发送后实际已送达因此补救建议是先按效果核对再考虑重发rig capture session绝不诱导盲目重发硬连接失败 未发送才给出was not sent的结论与诊断路径检查OPENRIG_URL/RIGGED_URL、daemon.host/port确认后rig daemon start。两类输出都遵循事实/后果/行动fact / consequence / action三段式--json下输出可解析的结构化信封。Proof Contract四项可验证契约规格文档定义了四个证明项全部可以在 packages/cli/test/send.test.ts 的 S3 — delivery honesty (OPR.0.5.4.6) 测试分组中找到对应用例STAGED-UNSENT DETECTED BY EFFECTPROOF-1文本落在提示符staged、未消费时send --verify如实报告 staged——判别证据是 pane 效果不是传输返回。CONSUMED MEANS CONSUMEDPROOF-2真正被消费的发送验证为正向两种结局绝不可互换staged 报告必须点名检查了什么。NO DOUBLE DELIVERYPROOF-3staged 的补救是 submit 路径单次 Enter测试断言普通发送含hello there文本的 POST恰好一次、submitOnly提交恰好一次产品从不建议盲目重发。INTERIM LORE RETIRED产品自身的报告使旧的座位纪律暂存在提示符修复是敲一次 Enter不再必要并在传授该纪律的 guidance 中记录退役按路径引用。测试还覆盖了防御性细节send.test.ts 相关用例scrollback 中的过期占位符不构成staged 证据不触发报告、不触发 guarded submit--json --verify信封携带效果分类且 staged 未解决时退出码为 1fan-out 逐接收者报告效果、staged 命名、已消费者绝不被称 staged。实操速查rig send --verify的完整参数面结合 send.ts 命令定义与交付验证相关的完整选项如下选项作用与 Delivery Honesty 的关系--verify发送后检查 pane 是否出现内容本切片的主角发送后做 pane 效果分类--wait-for-idle 秒目标明确空闲后再发送可与--verify组合不能与--force/--dangerously-interact组合--force向后兼容空操作忙碌 pane 默认带提示发送永不绕过交互提示/权限守卫--raw发送精确文本/按键不带 From/To 信封仍受守卫--dangerously-interact --reason why刻意驱动交互提示/权限块唯一绕过守卫的开关要求 reason写入审计日志--jsonAgent 可解析的 JSON 输出携带effectCheck、verified、outcome字段--host id跨主机发送效果检查跨主机不运行输出Effect: UNCHECKED典型组合# 单席位发送并验证 pane 效果staged 会自动走单次 Enter 提交 rig send dev-implmy-rig Context update: QA approved. Proceed. --verify # 等待空闲后发送并验证 rig send dev-implmy-rig safe proof prompt --wait-for-idle 30 --verify # fan-out 到两个席位逐接收者报告效果 rig send --to dev-implmy-rig,dev-qamy-rig message to two seats --verify # Agent 消费的结构化输出 rig send dev-implmy-rig message --json # 跨主机http 注册主机远程权威裁决 诚实的 UNCHECKED 声明 rig send --host remote-dev dev-implmy-rig remote message --verifystaged 场景下的输出形态Sent to dev-implmy-rig Verified: no Delivery: staged, not consumed (checked: post-send pane capture; observed: the sent text is still at the prompt — typed, never submitted) Remedy: one guarded Enter submitted — the staged text left the prompt.小结Delivery HonestyOPR.0.5.4.6把 openrig 的交付语义从传输层说成功就算成功升级为pane 效果证明已消费才算成功探测器只认当前输入区的真实证据、身份先行防止误判他人的暂存内容、guarded submit 以expectedStagedText预检查保证单次 Enter 只落在本次发送的文本上、所有输出编码渲染同一条效果真相跨主机场景则诚实声明未检查。四个 proof contract 项均以聚焦测试锁定使Sent means consumed从口号变成可验证、可回归的产品契约。对于任何依赖 Agent 间可靠指令传递的编排场景send --verify都是消除暂存即假装已发送这一整类误会的标准工具。赞分享人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载相关推荐Scenario: Send a chat message and verify responseScenario: Send a chat message and verify response Steps 1. Type explain the cod开发工具代码编辑器ChatGLM3-6B Code Interpreter 部署实战让大模型真正动手执行代码ChatGLM3 6B Code Interpreter 部署实战让大模型真正动手执行代码 本文是一篇基于《开源大模型食用指南》self llm 项目教程大模型本地部署微调GraphRAG实体消歧技术如何让AI真正理解文本中的多义实体GraphRAG实体消歧技术如何让AI真正理解文本中的多义实体 你是否遇到过这样的情况AI系统把苹果理解为水果而实际上上下文讨论的是科技公司或者AI人工智能RAG知识图谱数据工程大模型创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考