人工智能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 仓库中的skills/_canonical/core/messaging-the-human/SKILL.md技能文档为主体系统讲解多 Agent 系统中向人类发送决策请求与更新通知的完整机制如何用rig gateway human list/show发现并检查注册的人、如何检查连接器就绪状态、如何用rig queue create以decision/update两种意图投递持久化消息、如何用--reply-to线程化后续更新、如何用--human-questions-file生成按钮式选项以及送达校验--verify与rig queue transitions的审计语义。读完本文你可以掌握在 OpenRig rig 中正确发起、校验并追踪人作为决策节点的完整工作流并理解其底层 CLI 与 daemon 的实现约束。定位传输中立的人机消息机制messaging-the-human技能文档开篇即明确了职责边界Project World 提供何时以及为何要联系人类而这个技能只负责传输中立的投递机制transport-neutral mechanics。安装该技能本身不会创建任何审批闸门也不替你做连接器选型。文档还给出两条重要纪律如果策略policy把一个重大决策留给 agent 却表述含糊agent 应当识别出缺失的授权主体而不是自行猜测不要把一个可解的技术故障包装成需要人类决策的审批闸门。这条边界设计呼应了 OpenRig 的整体架构人不是队列里的普通成员而是通过 gateway 连接器如 Slack触达的外部参与者。技能元数据中声明的 CLI 面正是这套机制的全部命令面gateway human list、gateway human show、queue create、queue transitions、queue block、send详见 技能定义。第一步发现已注册的人并检查其状态文档规定的第一动作是发现与检查而非直接发送rig gateway human list --json rig gateway human show entityId --json两条命令在 gateway.ts 中有对应实现list会调用listHumans()并为每条人记录并发附加deliveryReadiness就绪视图list的 action 中Promise.all里对每个 entityId 调用humanReadiness(record.entityId)见 gateway.ts#L224-L237show则展示生效记录——fragment 中显式设置的值 哪些字段由默认值补齐并带来源provenance标注showHumandeliveryReadiness见 gateway.ts#L239-L258。从源码结构看list --json的输出结构为{ ok: true, humans: [...], advisory? }非 JSON 模式则逐人打印entityId、显示名、delivery class、away 状态、binding 的 kind 与 primary connectorRef以及deliveryready/not-ready/indeterminate若未就绪还会追加delivery: reason; next: nextAction。就绪视图readiness的字段语义文档要求检查configured、enabled、active、ready、reason、next action六个维度并强调indeterminate不等于 ready。这与 CLI 侧的HumanReadinessView接口完全对应见 gateway.ts#L36-L48export interface HumanReadinessView { state: ready | not-ready | indeterminate; configured: boolean | null; enabled: boolean | null; active: boolean | null; ready: boolean; connector?: { kind: string; ref: string }; reason: string; nextAction: string | null; checkedAt?: string; }daemonHumanReadiness通过GET /api/gateway/human/entityId/readiness从 daemon 读取就绪状态并做严格的形状校验一旦响应中readiness.ready ! (readiness.state ready)或 reason 为空等异常出现就抛出malformed delivery readiness response任何网络/解析异常统一降级为state: indeterminate并给出nextAction: rig status见 gateway.ts#L50-L83。这就是文档所说的indeterminate不是 ready的源码级保证——CLI 宁可报告不可判定也不会把读不到状态误判为可发送。地址纪律只用返回的address文档强调投递目标必须使用返回的address格式为entityIdexternal不能用用户名、记忆中的 seat、连接器 handle 或猜测的 kernel 地址。多个已注册的人之间由 Project World 的 decision ownership 决定归属注册缺失或含糊时正确动作是做一次有名字的注册修正named registration correction而不是拿一个兜底地址顶上去。从源码结构看entityIdexternal这一约定被 schema 固定rig gateway human add在构造 fragment 时直接写死address:${entityId}external见 gateway.ts#L178-L185且注册路径是 verb-add-only——fragment 文件是事实源registry 只是生成的投影。文档同时提醒不要因为想让检查通过而去启用或重新配置连接器而应遵循 readiness 报告的nextAction。第二步为手机上的读者撰写决策简报技能文档中最有实操价值的一段是写作规范。人可能是在手机上读消息因此--summary放短标题subject--body-file放一份完整简报one complete brief内容必须包含四要素为什么这件事重要、你的建议与关键权衡、若批准的有界动作bounded action、请求的选择the choice requested若是更新类消息说明用户可见的结果并写明No action needed目标篇幅约100–150 词——文档明确这是写作指导不是语义校验器。文档给出了一段合成分简报示例注意该示例不授予任何授权The repaired status view is ready. I recommend updating this instance; live status will briefly pause. Sessions will be preserved. Approve this instance update, or hold? Supporting test detail follows in this thread.同时要求技术性续作内容、精确的 candidate/revision 与证据应留在拥有该工作的 agent 行以及--evidence-ref指向的持久工件中而不是塞进手机消息。一个关键警告本地路径不是手机上的链接Markdown 证据文件也不会被自动附带——所以--evidence-ref是给拥有该行的 agent 用的指针不是给手机端预览用的附件。意图intentdecision 与 update文档区分两种出站意图--human-intent decision请求request——需要人做出选择--human-intent update安静的知会quiet FYI——不产生任何审批义务。省略该参数时保留 legacy 的 decision 行为消息里出现FYI字样或打标签不会改变意图。CLI 侧的实现印证了这一点--human-intent的 help 文案即decision (default) or update: a quiet informational delivery, never an approval request见 queue.ts#L463daemon 端在 queue-repository.ts 中消费humanIntent字段。第三步唯一的出站人消息原语文档把rig queue create定义为唯一的出站人消息原语the sole outbound human-message primitiverig queue create --destination entityIdexternal \ --human-intent decision --summary short subject --body-file brief-file \ --evidence-ref durable-evidence --verify --json结合 queue.ts 的完整参数面与本文主题直接相关的选项及其行为如下参数作用与约束--destination session目标会话人 seat 引用会先经 human-seat 分类器识别external地址不会被误拆成 host 限定形式见resolveQueueHostDestinationqueue.ts#L394-L423--body text/--body-file path二选一互斥-表示从 stdin 读--body-file的设计动机就是消除多行正文经 shell 反引号损坏这一整类错误见resolveQueueBody注释queue.ts#L250-L261--summary text简短可读标题省略时 CLI 会向 stderr 输出 warning不硬断并提示 Story 节点将退化为有界的 body 预览queue.ts#L554-L562--human-intent intentdecision默认或update--human-detail-file path同线程内一条连贯的补充回复见下节--reply-to qitemId仅接受--human-intent update组合见下节--human-questions-file path1–4 个按钮式问题见后文按钮式决策--evidence-ref path指向人类要裁决的持久工件如 PROOF.md 路径当项被路由给人时 daemon 强制要求否则可选queue.ts#L467--verify持久化后对既有投递回执做有界等待从源码看默认 30 秒超时、500ms 轮询间隔waitForDeliveryOutcome的默认timeoutMs/intervalMsqueue.ts#L49-L57且从不重试 create、从不声称人已读--json面向 agent 的 JSON 输出补充细节--human-detail-file与渲染前的体积校验文档规定--human-detail-file提供同线程内的一条连贯补充回复且必须在简报中预告它的用途产品侧也会标记有一条 detail 回复跟随。硬约束主简报必须已包含完整的范围、选项与动作——不要把 agent 的 dump 盲目切块更不要把关键选择移进溢出部分。渲染阶段会对每个部分及其可访问性回退做检查后才发帖超尺寸的请求会被按字段给出具体修正地拒绝绝不静默截断。正确做法按提示缩短简报或相关 detail检查失败的行若内容需要修正则有意地取消/替换已写出的请求——而仅仅超时永远不是替换它的理由。线程化后续更新--reply-to对早先工作的后续更新例如你批准的那个变更已经合并了可以用--reply-to earlier-qitem-id把消息投进那条 item 的 Slack 线程。但这一能力有一组精细的接受规则文档逐条列出仅在与--human-intent update同用时才被接受——CLI 会在接触 daemon 之前就拒绝decision--reply-to组合报错reply_to_requires_update见 queue.ts#L525-L533因为 decision 要保持自己的线程其回复才不会歧义要指明人看到的那条 item例如那条 parked 行并在与那条 item 相同的 host上创建更新更新必须从拥有该线程的 seat发出即 parked 该行的 seat或更早那条 item 的作者。线程中的人类回复会路由回其 owning seat因此其他 seat 发出的更新会作为新消息发布以下情形也降级为新消息而非拒绝更早的线程缺失或已关闭、或更早那条 item 仍悬在人类一侧有待决的人类决策或行停在人类上——因为此时在该线程里回复等于代答了那个决策。所有降级情形都会体现在--verify的结果中threaded: false并附原因。这一点在 CLI 的验证结果类型中有精确对应——VerifiedDeliveryResult的threaded与detail字段posted 时若存在replyTo则按replyToFallback是否为空判定threaded降级时 detail 形如posted as a new top-level message, not in replyTos thread: fallback见 queue.ts#L37-L47 与 queue.ts#L64-L75。按钮式决策--human-questions-file一个只有少数清晰选项的decision可以携带--human-questions-file path一个 1–4 个问题的 JSON 数组每个问题的形状为{id, question, options: [{id, label, recommended?}]}每个问题 2–4 个选项label 最长 75 字符至多一个 recommended。Slack 会把每个问题渲染为一排按钮每次点击都会把该答案记录在 item 上所有问题各有一个答案后决策才解决。此后你会收到一条列出的答案的回复行item 的humanAnswers字段保存选项 id。人也可以直接在线程里打字回复——那会按常规解决决策所以读回复内容而不是假定选了某个按钮。文档再次提醒简报必须完整按钮是附加而非替代解释。CLI 侧对该文件做了本地预解析通过resolveQueueBody({ bodyFile: ... })读文件、JSON.parse校验解析失败时输出三段式fact/consequence/action错误且不接触 daemon见 queue.ts#L534-L553最终的形状校验仍由 daemon 完成。用 queue block 把 agent 行挂在人类决策上当一条已存在的 agent 拥有行需要等待某个决策时文档要求把它 block 在新的实时 human qitem ID上rig queue block work-id --on human-qitem-id ...而不是 block 在人的地址上。原因有二human qitem 完成时会自动恢复其依赖行dependants若同时再 block 在人身上就会为同一个决策多发一次通知。从源码看rig queue block是update写路径的薄封装它 POST 到/api/queue/id/update并固定state: blockedblockedOn即--on的值--on接受 live blocker qitem、类型化 gate 或 human-seat session人类 seat 类型的 park 由 daemon 校验器强制--summary--evidence-ref见 queue.ts#L763-L819。park 是非终态owner 保留热土豆后续通过rig queue resolve qitemId --decision text走 mission-control 写路径解 parkblocked → in-progress同一 item、非关闭见 queue.ts#L827-L862。送达校验与状态审计posted 不等于已读文档对持久化与投递的分离说得非常直白行先持久化然后才做有界的投递校验。你需要读它的 qitem ID 和验证结果posted只证明连接器发帖成功不证明人类已读transport-failed、never-posted或 pending/indeterminate 结果都会让行原样保留正确动作是检查同一行及其 next action绝不因为校验超时就创建第二行或盲目重发。CLI 的waitForDeliveryOutcome把这套语义实现为一个五值结果见 queue.ts#L37-L47outcomeconnectorAccepted含义与 nextActionpostedtrue连接器已接受humanReadership恒为unknown--reply-to场景附带threaded判定transport-failed/never-postedfalse附deliveryFailureDetailnextAction 为rig queue show id --jsonindeterminatenull回执读不到异常同样指向rig queue showstill-pendingnull超时窗口内没有终态回执durable qitem remains intact对--verify路径CLI 在 create 成功后调用waitForDeliveryOutcome并把delivery与persisted: true一并打印queue.ts#L658-L672。注意接口注释里的一句关键声明A connector receipt can never prove that a person read the message.humanReadership: unknown是类型上的强制值。update 与 decision 的后续义务差异文档给出两条不同的收口规则对update确认完成的投递可以关闭投递义务delivery obligation。它不产生审批义务也不能当作决策阻塞器。已送达的 update 仍对 Feed 可查询失败或含糊的发送保持独立状态。单条根消息本身不证明补充内容已送达。重试会协调reconcile稳定的 part 身份、只补发缺失的部分。FYI 的回复不是人类决策。对decision关联回复correlated reply会绑定到恰好那个人与那条 qitem并记录恢复 owner 所需的 resolution。在宣称决策已到之前先检查已记录的结果——单凭投递回执不是接受。审计工具就是rig queue transitionsrig queue transitions qitemIdCLI 中它对应GET /api/queue/id/transitionsqueue.ts#L1120-L1126rig queue resolve的决策文本也会持久地记入 queue_transitions见 queue.ts#L829因此 transitions 是决策到达与否的权威审计面而不是投递回执。既有阻塞器与其他通道的边界文档最后一节划清了几条容易踩混的边界entityIdhost是内部托管标签不是第二个投递地址。既有 agent 行可能被 block 在entityIdhost上它通过 human registry 解析到同一个外部参与者owner 与 continuation 应保留在那条行上。在考虑新的请求之前先检查它的既有投递回执避免 legacy blocker 产生重复消息。且永远不要从当前 rig 名推导host。rig send只能到达 agent 的终端它既不是人类传输也不是持久的人类义务agent 间工作走 queue handoff 路径见 queue-handoff 相关命令 中的handoff/handoff-and-complete实现。连接器专属的配置与 handle 属于 registry/readiness 工具不属于项目无关的消息指令——这正是技能传输中立定位的收尾呼应。小结一条可复现的人机消息工作流把全文的实操要点串起来一个完整的决策请求流程是# 1. 发现与检查 rig gateway human list --json rig gateway human show entityId --json # 确认 address 与 readiness.ready # 2. 写简报到本地文件100–150 词四要素齐全 # 3. 投递唯一原语带校验 rig queue create --destination entityIdexternal \ --human-intent decision --summary short subject --body-file brief.md \ --evidence-ref durable-evidence --verify --json # 4. 若 agent 行需等待该决策block 在 human qitem 上 rig queue block work-id --on human-qitem-id --wake-after 15m # 5. 审计决策是否真正到达而非只看回执 rig queue transitions human-qitem-id后续进展用--human-intent update --reply-to earlier-qitem-id投回原线程注意线程可用性规则并在--verify输出中确认threaded判定。整套机制的设计主线在文档与源码中高度一致持久化先行、送达有界校验、posted不等于已读、决策到达以 transitions 为准、任何含糊状态都指向检查而非重发——这也是该技能要求所有 agentaudience: all agents见 SKILL.md 元数据共同遵守的纪律。赞分享人工智能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 中的 messaging-the-human 技能从人类注册发现到决策队列投递的完整实操指南openrig 中的 messaging the human 技能从人类注册发现到决策队列投递的完整实操指南 本篇技术指南围绕 openrig 多智能体系统中人工智能AI Agent多智能体Agent 编排代码智能体CLIFastStream RabbitMQ 路由机制详解Exchange、Queue、Binding 与消息生命周期FastStream RabbitMQ 路由机制详解Exchange、Queue、Binding 与消息生命周期 导读 本文围绕 FastStream 框架中后端消息队列微服务OpenRig Human In The Loop 深度指南把人类当作持久化网络参与者构建可信的人机决策回路OpenRig Human In The Loop 深度指南把人类当作持久化网络参与者构建可信的人机决策回路 导读 OpenRig 的 human in t人工智能AI Agent多智能体Agent 编排代码智能体CLI上一篇CANN驱动npu-smi工具文档下一篇终极指南wasm-bindgen跨浏览器兼容性解决方案与最佳实践创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考