OpenRig product-team Rig Craft 实战：多 Agent 团队的队列交接、对账与协作纪律规范

人工智能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 的 product-team 是面向人机协作的产品开发型 rig两名编排者orch1.lead、orch1.peer、一个含实现/QA/设计的开发 pod、两名独立评审rev1.r1、rev1.r2全部座位由 Claude Code 与 Codex 承载。本文以该 rig 随包附带的 rig 海拔规范文件 CRAFT.md 为主体逐条拆解六条团队级协作纪律并结合 queue.ts 的源码证据讲解rig queue handoff、rig queue transitions的底层语义同时覆盖同一海拔的 ORCHESTRATION-CRAFT.md跨座位干预纪律与规范的安装、追加、沉淀机制。读完后你将掌握在多 Agent 持久化团队中正确传递工作、避免重复投递与分叉、以及把本地经验沉淀为随包默认规范的一整套可操作方法。CRAFT.md 是什么rig 海拔的“团队级规范”文件在 OpenRig 的拓扑树instance → rig → pod → seat中每层节点都可以挂载名为CRAFT.md的链路文件chain file。本文件位于 rig 海拔即topology.root下的rigs/rig/CRAFT.md位置见 chain-file-convention.md其职责是承载每个成员都必须遵守的 rig 级规范——它比 instance 海拔全实例通用事实更具体比 pod/seat 海拔单一团队/单一座位的上下文更通用。文件头注释明确了它的两种关键机制随包附带shipped defaultsproduct-team rig 规范在安装时通过 copy-if-absent 机制写入用户侧拓扑树可自由追加append freely后续任何一次rig-up都不会覆盖该文件——已存在的文件永远优先团队可以在默认规范之后追加自己沉淀的实践。因此这份文件是“先有纪律、后有自由”的起点六条规范约束的是所有座位共同的交接与分诊行为而追加空间留给团队在实践中验证过的经验。同一海拔还有一份分工不同的 ORCHESTRATION-CRAFT.md专门给出“在对其他座位采取行动的当下”需要的跨 pod 战术提醒rig 海拔之外instance 的 CRAFT.md 承载“机器级事实”配置路径、拓扑树与项目树之分各 seat 的 CRAFT.md 承载座位专属职责。规范一他人必须行动时先落一条队列行If another seat must ACT, it needs a queue row.A send informs; only a row creates an auditable obligation.这是整份规范中最重要的一条rig send只能“告知”只有队列行qitem才能产生“可审计的义务”。当工作需要另一个座位真正行动时单纯发一条消息是不够的——消息没有状态机、没有责任人、没有履历无法被审计也无法在故障后对账。规范给出的正确动作是rig queue handoff把“关闭当前行”和“创建新行”合并为一次事务即“close and create are one transaction”。在 queue.ts 中可以看到该命令的完整契约rig queue handoff qitemId \ --to session \ --summary 1-2 句人话摘要 \ --body 新行的完整正文缺省继承源行正文 \ --note 交接备注 \ [--priority p] [--tier t] [--tags tags] \ [--gate role] [--target-repo name] \ [--evidence-ref path] [--host id] [--no-nudge] [--json]命令描述原文是 “Transactional handoff: closes source as handed-off creates new qitem owned by --to”即原子地完成两件事源行关闭状态为 handed-off同时创建一条归属--to座位的新行。关键参数语义如下参数含义说明--to session必填接收新行的目标座位交接方身份由传输头X-OpenRig-Session推导--from已废弃忽略P21 I3 起--summary text新行的短摘要缺省时命令会向 stderr 打印警告并继续摘要应是人眼在 needs-you 视图里能快速扫读的 1-2 句人话--body/--body-file新行正文两者互斥-表示读 stdin都省略则继承源行正文--gate role标记门禁工作翻译为gate:role标签如 guard、spec-review供 idle-gate watchdog 消费可与--tags组合并去重--evidence-ref path持久产物指针新行目标是人工路由时 daemon 要求必须提供否则可选--no-nudge抑制对新接收者的默认 nudge默认会通知新行主人值得注意的两个工程细节一是--summary缺省时的“警告而非硬断”warn-on-authorOPR.0.4.1.18 FR-7因为 handoff 会创作一条新行新行必须自带人类可读的摘要二是--body-file的存在是为了消灭 backtick-shell 注入这一类正文损坏问题。若需要让源行彻底终结而不是停留在 handed-off 状态还有变体rig queue handoff-and-complete原子完成“关闭源行statedoneclosure_reasonhanded_off_to 创建新行”。规范二持活的回合必须以交接或点名阻塞收尾A turn holding work ends by handing off or naming a live blocker.Ending a turn with a summary in your own terminal is going dark.第二条规范解决的是**“幽灵收尾”问题一个回合如果手里还握着工作结束方式只有两种——要么交接出去rig queue handoff要么点名一个仍然存活的阻塞者**。如果只是在自己终端里写一段总结然后结束回合从外部视角看一次干净的收尾和一次崩溃是没有任何区别的没有队列行、没有阻塞记录旁观者无法判断该座位是完成了、卡住了还是死掉了。这与 CULTURE.md 中“诚实错误优先于优雅降级”Honest errors over graceful degradation的文化一脉相承失败必须大声浮出水面不能静默。被阻塞时的标准动作在 CULTURE.md 中也有明确流程rig send session Im waiting on specific thing --verify直接消息对方超时未响应则升级给编排者绝不静默停滞do not stall silently。规范三按接力棒分诊看板不按数量分诊Triage your board by baton, never by count.A claimed row with an owner is work; an informational row is not.看板上的行并不等价被认领、有主人的行是“工作”仅用于告知的行不是。因此分诊时不能数行数——一堆没人认领的告知行不等于一堆待办工作。要区分“刻意搁置”deliberate park与“断线搁置”strand看的是行的状态履历而不是行的“脸面”当前显示状态工具就是rig queue transitions qitemId # 查看某行的追加式append-only变迁日志 rig queue transitions qitemId --json # 结构化输出供 Agent 程序化消费在 queue.ts 中该命令的实现是GET /api/queue/:qitemId/transitions其命令描述为 “Show the append-only transition log for a qitem”。append-only是这条命令的核心价值行从创建到认领、搁置、解封、交接、完成的每一次状态迁移都留下不可篡改的日志分诊者依据日志判断当前行处于何种真实状态而不是依据行当前展示的一格画面。这一条与规范四的“按 ID 对账”互为表里状态履历是唯一可信的判据。规范四传输层负信号是谎言——先按 ID 对账再重试Transport negatives lie.A timeout is INDETERMINATE, not failed: reconcile by ID before any retry, or you fork the row.这是分布式系统语义在多 Agent 协作上的直接应用传输层的一切“负信号”都不可信。一次超时timeout意味着“结果不确定”INDETERMINATE而不是“失败”failed——请求可能根本没到达、可能到达了但响应丢了、也可能已经在远端执行完成。在这三种可能都无法区分的情况下直接重试最危险的后果是分叉fork the row同一行被处理两遍两个副本从此各说各话。规范的处方是任何重试之前先按 ID 对账reconcile by ID——用rig queue transitions qitemId查远端的状态履历确认行到底处于什么状态绝不在负信号上直接重发never re-send on a negative signal而是通过读取远端来确认。这与 instance 海拔的 CRAFT.md 中“以效果验证而非以成功消息验证”Verify by effect, never by success message是同一纪律在不同层面的体现内存中的记忆是“对过去的断言”文件系统和数据库永远比记忆领先一步。规范五统计方法不统计投票Count methods, not votes.Seats that ran the same command in the same tree are one datapoint wearing several hats.当多个座位得出相同结论时要问的是它们是否用了同一种验证方法。同一个仓库里跑同一条命令的五个座位只是“一顶帽子下的同一个数据点”one datapoint wearing several hats——它们共享同一份代码、同一个环境、同一种失败模式五票赞成并不比一票更有说服力。反之用不同方法如实现者跑测试、QA 复核契约、评审者读 diff 与文件系统交叉验证得到的“同一结论”才是真正独立的证据。这条规范直接支撑 CULTURE.md 的“求真”Truth-seeking文化每次评审、圆桌与分歧都要找真相——每一个论断都要有证据每一条发现都要有file:line引用或命令输出。而“座位是平等的”这一文化条款也在此落地证据质量取决于方法独立性而非角色权威。规范六被派发的任务用一行声明其严谨度等级State the rigor level you chose for a dispatched task, in one line.Heavy process is earned by irreversibility, not importance.最后一条规范是过程成本控制派发任务时派发方必须用一行说明“我为这个任务选择的严谨度等级”。其背后的定价原则是重型过程是由“不可逆性”irreversibility挣来的而不是由“重要性”importance挣来的。越不可逆的操作如对外发布、破坏性迁移、删除数据越值得重流程再重要的任务只要可逆、可回滚就不必扛全套门禁。这一原则在 product-team 的实际工作流中也有对应落点CULTURE.md 明确规定“拓扑不会预选 pre-edit、QA、guard、review 或 lock 门禁”——门禁按任务需要显式指派对 wave 的本地检查按 slice 进行、独立评审在整个 wave 累积后一次性触发“命名的严谨 slice 保留其选定的检查”。也就是说严谨度是逐任务显式选择的而不是团队默认全开的选择的结果必须随任务一行说清让接收方知道该以什么标准交付与自检。同海拔配套ORCHESTRATION-CRAFT——对他人座位的操作纪律rig 海拔还有一份与六条规范配套的 ORCHESTRATION-CRAFT.md它定位于“在对另一个座位采取行动的当下”需要的提醒跨 pod 战术提醒留在 rig 海拔pod 目录只放单一团队专属上下文。四个主题值得与六条规范并读读取他人 pane 的判读纪律Claude Code 与 Codex 都会在输入框渲染自动补全的“幽灵文本”ghost text而捕获画面无法显示字体颜色因此必须以光标位置和行为做判别——光标在文本末尾可能是“已输入待提交”staged光标在文本开头则基本是幽灵文本行为上一个按 Enter 却没有被消费掉的内容就是幽灵文本。误读幽灵文本曾真实造成过误诊。已停在提示符处的文本是“staged 而非已消费”修法是一次C-m绝不再发送再发就是投递两次。在不烧光资源的前提下观察观察只能“瞥一眼”glance每次瞥一眼都消耗一次回合必须轮询时间隔至少两分钟且“连续两次输出完全相同”意味着应停止轮询而不是更用力轮询——在共享 provider 上打紧循环可能耗尽用量上限拖垮该 provider 上的所有座位。同时要区分“存活”liveness与“健康”healthpane 能渲染不等于在推进判断卡死前必须交叉rig capture与claimedAt、rig queue transitions。干预他人的三档动作wake唤醒、refocus重新聚焦、checkpoint检查点是三种不同的干预——wake 只恢复存活、不得重构工作refocus 纠正漂移、以“先完成你当前的动作”开头checkpoint 是刻意的阶段边界暂停。用错一上来就上重型干预是最常见的自伤式停滞。另外永远不要为解锁而对同伴做压缩compact压缩回来的座位“自认为什么都知道、实际已经不知道”而只有你知道发生了什么——必须先落盘deposit、公告、并说明该座位现在不再拥有什么。把实践加进这些文件的路径发现在它挣得它的地方出现——LEARNED、现场笔记、评审观察→ 策展判断是否普遍适用还是项目专属→ 随包发布以“每条一行动机事件”的形式加进 spec 的topology/默认值。改本机已安装副本只对当前 rig生效随包发布才对每个未来安装生效。详见 chain-file-convention.md。规范如何安装、追加与沉淀回随包默认整棵拓扑树instance → rig → pod → seat都遵循 chain-file-convention.md 的“一文件同名”规则同一文件名在每个海拔保持一致读者从自己所在位置向根方向逐层阅读同名文件即可完成定向无需指针、无分支、无分层命名。product-team 是第一个随包附带默认链路文件的 rig其规范文件位于仓库内的 specs/rigs/preview/product-team/topology/ 目录rig-up 时按 copy-if-absent 语义安装到topology.root该路径由env OPENRIG_TOPOLOGY_ROOT config file $OPENRIG_HOME/topology解析任何机器上都用rig config get topology.root查询绝不硬编码。整套规范文件的分层布局一目了然海拔文件承载内容instanceinstance/CRAFT.md全实例每个座位都适用的机器级事实查证不回忆、路径从配置推导、双树之分、以效果验证、作用域搜索不等于全局缺席rigrig/CRAFT.md本文主题——六条团队级协作纪律rigrig/ORCHESTRATION-CRAFT.md跨 pod 战术提醒读 pane、观察、干预、实践沉淀seat各 seats/*/CRAFT.md座位专属职责如 lead“只在源处验证、只做缓冲不做导线、只有本座位可 park 且必须挂 watchdog”配套的 rig.yaml 定义了座位的运行时布局两编排、开发 pod 三人、两评审Claude Code 与 Codex 混编与delegates_to/can_observe边如orch1.lead → dev1.impl、rev1.r1 → dev1.impl是这些规范得以执行的拓扑前提。把一条在实战中挣得的经验沉淀为随包默认的完整闭环是发现 → 策展 → 随包发布。值得特别强调的是最后一步的边界编辑已安装副本只帮助当前 rig发布到packages/daemon/specs/rigs/…/topology/的默认文件里才会在下一个发布版本被新安装继承而正在运行的 rig 只能通过显式投递refocus 通道接收更新——编辑文件不等于投递给运行中的座位。这保证了“规范”与“运行中的行为”之间始终存在一个可审计的传递动作而不是靠偷偷改文件来改变团队纪律。赞分享人工智能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 product-team Rig 团队文化规范与实践指南双编排、开发 Pod 与独立评审的产品团队如何协作openrig product team Rig 团队文化规范与实践指南双编排、开发 Pod 与独立评审的产品团队如何协作 本指南聚焦 openrig 仓库中人工智能AI Agent多智能体Agent 编排代码智能体CLIOpenRig Demo Rig 实战指南多 Agent 团队的协作协议、工作选择与团队文化OpenRig Demo Rig 实战指南多 Agent 团队的协作协议、工作选择与团队文化 导读本文以 OpenRig 仓库中 launch/demo 这人工智能AI Agent多智能体Agent 编排代码智能体CLIOpenRig Conveyor Starter用队列交接与工作流实例打造多 Agent 流水线教学 rigOpenRig Conveyor Starter用队列交接与工作流实例打造多 Agent 流水线教学 rig Conveyor 是 OpenRig 0.3.0人工智能AI Agent多智能体Agent 编排代码智能体CLI上一篇如何通过DriverStore Explorer解决Windows驱动存储空间占用问题下一篇3分钟极速备份GetQzonehistory帮你一键保存QQ空间全部历史说说创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考