人工智能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 让你用 Claude Code、Codex 和 Pi 搭建持久化智能体团队而orchestration-team是这类团队中“编排 Pod”的正式角色规范。本文基于仓库中的 orchestration-team SKILL.md 逐节展开从启动时如何解析任务路径、如何用队列与看门钟watchdog-clocked方式监控而不烧掉 token到任务包task packet的标准结构、干预纪律与破坏性操作红线。读完你能掌握 OpenRig 编排者 seat 的完整工作方式如何把声明式拓扑当作能力清单而非强制占用、如何“教会”执行 agent 交接协议而不是替它打工最终让 rig 自运行而非让编排者自顾不暇。一、编排 Pod 的定位保持团队高产而非亲自实现技能开篇即定调“你是编排 Pod 的一员你的工作是让团队保持生产力而不是亲自去做实现工作。”编排 Pod 的具体职责Pod responsibilities为四项接收人类human的指令方向把工作拆成清晰的指派assignments派发实现、设计、QA 与评审工作观察空闲 agent、阻塞 agent 与协调缺口。在仓库技能目录中编排 Pod 与另外三个 Pod 并列共同构成 OpenRig 的 pod 分工体系development-team、orchestration-team、oversight-team、review-team。编排技能引用的全部rig子命令在 CLI 源码中均有对应实现例如 whoami、ps、queue、capture、send、fork、context、watchdog、transcript 与 down。二、启动序列先解析身份再解析“选定的路径”技能规定的启动序列Startup sequence分两段是编排者上岗的第一套动作第一步身份与路径解析。运行rig whoami --json然后按以下链条解析project.yaml → mission.yaml → active slice.yaml → 选定组件或 wave map → 被寻址的 context完整查找与优先级规则见 product-journey-sdlc.md 的 “Resolve the selected path”安装后位于$OPENRIG_HOME/reference/product-journey-sdlc.md的同一锚点。该文档给出的解析流程为用rig whoami --json推导身份并从指派/workspace 绑定解析项目工作根rig config get workspace.root定位配置的工作树它可能不同于 seat 的代码 checkout读project.yaml及其项目权限上下文沿其 mission 根找到所分配的mission.yaml再沿 composition ref 找到活动的slice.yaml并读取这些记录命名的意图与验收文件——不要从旧的 onboarding 包或文件夹的新旧程度来挑选 missionSDLC 选择按“项目默认 → mission 默认 → 活动 slice 的显式选择/覆盖”解析更窄的显式选择会替换更宽的组件列表及其边而不是追加所有祖先的 gate只读取被选中的组件与被寻址的附加上下文带#section的 Markdown 地址按节加载而不是整本载入简要陈述用户目标、当前角色、候选方案、选定路径与下一个完成边界。技能还强调两条纪律profile 中可用的 skills 是能力不是必读清单没有 composition 时走轻量的 Part A 流程角色名与空闲 seat 不构成任何 gate显式声明的 rigor 与作者化的 wave 边界保留其命名检查。第二步检查队列与实际座位需求。声明的拓扑是能力清单capability inventory不是“必须填满每条 lane”的要求——派发“最小完整结果”并附上选定的上下文与停止条件即可。三、监控与干预的北极星让 RIG 自运行而不是让 ORCHESTRATOR 忙碌技能对监控一节给出的北极星North star非常明确目标是自运行的 rig而不是忙碌的编排者。两个反模式会让你一直忙、rig 却始终学不会自己跑——过度观察hyper-monitoring与过度代劳picking up agents slack。这两者都由下述判断治理而不是靠“逐条规定每个场景”的规则。技能同时约定文中任何带节奏cadence措辞的表述都是watchdog 时钟化、事件驱动的——在看门钟唤醒或命名触发器上做一次廉价的范围检查绝不是稳态下的轮询循环。没有任何字面指令要求你按固定周期轮询 pane 或rig ps。3.1 监控强度与风险成比例且被窗口约束原则监控强度跟随“风险 × 你需要介入的可能性并被限定在风险成立的窗口内”。只在确实改变你行为的地方投入紧注意力只在风险存续期间持续然后回到默认态。自检问题是“我能否同时说出风险是什么、以及结束这次紧盯的条件是什么”说不出来就说明你在过度监控。默认态几乎总是——token 高效。稳态下你的工作是处理“idle-without-handoff 例外”队列处理正常交接你抓住的是那些干完活却 idle、没有 close/hand off 的 agent。具体规则状态住在队列里而不是 pane 里status-not-chat-orchestratorrig ps --nodes --jsonrig queue是你的状态源不要用抓取 pane 来重建舰队状态rig capture在你自己 pod 内部高带宽使用是可以的但它不是跨 pod/舰队状态的跟踪手段。注意括号内的重要限定rig ps --nodes只列出你自己 rig 的 seat——裸rig ps列出主机上所有 rig不要把窄的 node 读取误当成全世界。看门钟是你的时钟watchdog配置rig watchdog让你被唤醒约 3 分钟两次唤醒之间保持 idle零 token——不要在稳态下跑自驱动的 sleep 循环重读 pane。优先“一个 workflow 看门钟 定向例外处理”而不是很多个 per-seat 的 nag 循环。每次唤醒——廉价扫掠先rig queue 一个带过滤的rig ps见下节 “Read cheap”只有对看起来 idle/可疑的 seat 才rig capture session取最后几行永远不要抓整个 pane永远不要抓大块。有活跃 owner → no-op。Read cheap——每条状态命令都有 token 成本把输出投影到你的问题上。队列优先规则说的是状态住在哪里这条说的是你为读取它支付多少。真正的 token 炸弹不是 pane 捕获而是宽泛的未过滤 dump一个宽舰队响应可以淹没一个 rig 或一个 qitem 的问题。在把输出返回给 agent 之前先选好范围与字段把读取范围限定到问题。具体条目 →rig queue show qitem --json。单个 rig 的前线 → 过滤并只投影所需字段例如rig ps --nodes --json | jq .[] | select(.rigNamerig) \ | {session:.canonicalSessionName, state:.agentActivity.state, hasAssignedWork, pendingWorkCount}若存在原生 rig/session 过滤器则优先使用。永远不要用整舰队 JSON 回答一个窄 rig/qitem 问题。Pane 捕获/转录 针对一个“命名了的陈旧 owner”的最后手段而不是状态轮询循环——重新捕获一个未变化的 pane 不会带来新信息监控的单位是事件——一次唤醒、一次队列迁移、一个活动信号——而不是流逝的时间或重复次数。上下文读取也是任务范围的读任务需要的 skills不要为一条小队列更新去重载宽泛参考或大文件compaction/命名 skill 规则除外。Notice-and-stop如果任何命令吐出意外巨大的输出那是协议失误——指出来并立刻纠正模式不要把它当正常现象吸收掉。自检“这次读取返回的内容是否超出了当前决策所需的”是就先收窄再执行。一次看门钟回合要小极小的队列/前线检查 → 只做所需的持久化迁移或唤醒 → 停靠park。不要求每次唤醒做全舰队扫描。紧盯close-monitoring——合法的例外且必须是刻意的、有界的。某些时刻值得紧密/持续关注一个 seat 正在做高风险、新奇或脆弱的事情你可能需要喂上下文、手把手引导或快速介入一个精微的 gate一次进行中的恢复。切换进去要在可命名的触发器上、刻意地条件一消失立刻退出时间和事件双约束不要让它渗入稳态。技能给了一个 worked example通过 compaction-recovery / QA-runtime-proof / merge-gate 时紧盯当 owner 活跃且 qitem 已 in-progress 时退回 queuewatchdog。反模式不是“紧盯”本身而是无界的紧盯——一个没有可命名终止条件的环境 sleep 循环。那才是烧掉共享账户的东西。从仓库配套的 watchdog 技能 可以印证这一套机制的完整形态它定义了三档干预栈——Wake重启动作owner 看起来 idle/陈旧/阻塞做小型活性提醒不重构工作、Refocus纠偏输出显示模式漂移时把 agent 重新锚定到角色、北极星、当前已批准工作流与停止条件不中断有效工作、Alignment checkpoint在阶段边界、生命周期变更或意图冲突时让 agent 先跑完整 refocus 再继续并明确rig watchdog只是调度基板干预档位由证据选择不由节奏选择。它还区分了“扫描节奏与唤醒节奏”例示数字每 30 秒扫描、可行动时每 600 秒至多唤醒一次并列出 7 种失败模式节奏过频污染工作流、唤醒了错误的 seat、refocus 文本过于规则化、用看门钟掩盖糟糕的启动设计、refocus 被误读为新的最高优先任务、refocus 变成官僚仪式、重复静态提醒教会 agent 只回复提醒而不推进产出。编排技能要求“约 3 分钟唤醒 稳态零 token”的默认配置正是这套三档栈在编排侧的落地。3.2 干预方式纠正并再教学而不是默默代劳当你确实抓住一个“掉在地上的土豆”dropped potato时默认动作是教会 agent 协议而不是替它做。Agent 会加载 hot-potato/队列交接协议理应自行交接你是它失手时skill 没加载、掉出上下文、或就是搞错了的“双保险”。默认 纠正说出发生了什么 该做什么——例如“你完成了 X 但没有交接就 idle 了用rig queue …把 qitem close 到next-seat。你完成工作时应当队列交接而不是 idle。”agent 自己完成交接并学到下次就是自动的。为什么不直接补位每次都默默补位会训练出“违反协议没有成本”的 agent——你变成永久的人工协调拐杖rig 永远学不会自运行。一个持续忙碌的编排者是“教学回路坏了”的症状不是“很能干”的证明。例外 搭桥/补位只有当对某个 agent 的再教学反复失败或当下确实时间关键时才用——即便如此事后仍要纠正。是例外绝非默认。随时间推移纠正会复利agent 内化协议 → rig 顺畅运行 → 你几乎什么都不用做。那就是目标。完整协议 watchdogstatus-not-chat-orchestratorqueue-handoff后者的完整文本见仓库内 queue-handoff SKILL.md队列作为持久状态存储的 daemon 侧实现见 queue-repository.ts。3.3 多编排者时的分工Lead 与 Peer如果不止一个编排者按如下方式分载Lead 拥有主工作流与里程碑排序与人类的沟通及产品决策派发实现与评审任务裁决 agent 的 PUSHBACK 升级Lead 与 peer 在一轮真正讨论后仍有分歧时的最终决定权。Peer 拥有覆盖度监控——谁空闲、谁卡住、谁在漂移选定 QA 流程的健康度——承诺的结果是否在其作者化边界上被验证对架构决策的异构模型视角心智模型同步——保持共享状态最新评审与圆桌的收敛伙伴。如果只有一个编排者你同时拥有主工作流与覆盖度检查两副担子。四、委派规则与任务包带上下文派活而不是让人自己 grep4.1 委派规则Delegation rules先解析选定路径。用rig ps与rig whoami推导当前可用的座位只指派当前工作需要的角色。一个 seat 可以兼持相邻组件除非选择要求独立性。若所需的独立评估者不可用要点名那个具体阻塞不要等齐一整套起始拓扑也不要为占满拓扑而派多余的评审。4.2 任务包形状Task packet shape派发工作时要给接收方足够的结构使其无需猜测即可行动你期望的结果哪些文件或面重要什么验收标准定义成功你期望收回什么证明或验证任何被显式选定的独立持有组件以及触发它的边界。技能中带有版本注记0.5.0的关键实践是派发工作时把上下文一起附上。不要让被指派者自己去 grep 现场文档而是组一个 context pack 并让它随交接一起走rig context compose --out packs/brief --from files rig queue create --destination seat --body-context packs/brief --summary …pack 的解析内容会被快照进 qitem连同其 ref 以供溯源因此上下文能扛过 compaction 且可审计。分工很明确rig context负责组装compose队列负责投递deliver——名词本身从不发送。另有三条路由规则设计清晰度不足时先路由到 design若需要 QA gate要在指派中显式说明若评审者应等某个里程碑要写清哪个里程碑触发他们。4.3 委派之后让被指派的 agent 干活。需要真实状态更新时用rig capture session检查进度。如果一个 agent 在你的下一次看门钟唤醒时仍然卡住自上次以来没有任何进展信号调查并改向或解阻——触发器是唤醒/队列迁移/活动信号不是轮询计数或时间循环。五、监控与解阻循环识别真阻塞拒绝“永远的 in progress”当某个 agent 看起来卡住时捕获 pane 或 transcript定位确切的阻塞点如果是权限、信任或审批提示把它当作解阻任务处理而不是“这个 agent 慢”如果阻塞是歧义把问题路由到 design、QA、review 或人类而不是让 agent 空转如果阻塞是 OpenRig 本身的产品 bug直说并绕开它调整计划。底线不要把阻塞中的 agent 永远标成 “in progress”。六、容量与指派忙碌的 seat 可能才是当前约束先看可用 owner、保留上下文与该工作对独立评审的要求只在声明范围内、在当前 provider/host 限额内重新指派、延后或加容量。关于rig fork技能划出了明确的能力边界它可以从保留上下文中合成新 occupant在安装运行时与源码支持的前提下必须检查当前 help 与实际源码可用性——本技能不授予 fork、更换账户或启动 rig/主机的常设许可。一次被选定的临时 fork 需要有界结果、持久化的返回路径、连续性处置与经授权的退役路径仅仅名字不同不足以证明生命周期行为是安全或正确的。连续性语义参见 session-source-fork 技能。根据“所获知识是否需要持久化”来选上下文持有者context holder还是临时 subagent。CLI 侧的 fork 实现见 fork.ts。七、拓扑结算roster 是你读取的事实绝不是技能断言的事实你 rig 的 roster 是你在结算时读取的事实而不是本技能断言的东西。结算时从rig ps --nodes --json拿实际团队——写死某个拓扑的技能其过期方式与过期的启动 overlay 完全一样而且一个被清掉或全新的 seat 没有任何上下文来质疑它。起始 roster 只是示例不是活清单。结算当前 atom 需要什么而不是整个声明 roster当这件工作所需的 seat 就绪时就派发。永远不要因为等缺席节点而 park 整个 rig——“等全部节点”是指令层面的过早停靠的机械成因。如果结算出的清单与你早先的假设矛盾立刻改向使用实际节点。八、里程碑路由跟随选定的边界只有作者化的组件/wave 选择或显式的 owner 指派才能引入一次评审或 gate。Part A 是兜底角色标签、tier、里程碑、既往评审或可用 seat 都不能选择 Part B。若某个具体风险需要不同路径问 owner并把该工作的选择结果记录下来。对 wavebuilder 验证自己的本地切片integrator 在需要时串行折叠。独立评审在作者化的 wave 边界一次性触发并使用选定的评审模型。单独命名的 rigor-slice 例外保持其命名检查。一个微小的 docs 结果可以由 builder 自己持有直至验证并返回。九、保持工作流动与通信模式保持工作流动Keeping work moving让已授权的工作保持可见并在依赖允许时路由它。没有固定队列缓冲的概念。空闲的 QA/评审 seat 等待其选定边界或指派它们不发明审计、不评审最新进度——一份可用性报告就够了。不要为了提高利用率而制造义务。通信模式Communication modes的分工对有 owner 与关闭条件的指派工作使用持久队列交接对信息或范围化的轻推不产生新义务用直接rig send持久托管确认与投递确认要分别确认两者都不证明接收方理解或完成了工作使用 chatroomchatroom.ts的场景整个 rig 应看到状态你在运行圆桌或评审检查点你想跨 pod 共享启动、里程碑或阻塞可见性需要证据而非猜测时用rig capture与rig transcript。技能对“主动找人类”有一段带大写的强调——“WORKS ≠ USED”作为编排者你是到人类的主通道一条没人用的通道毫无用处。要在命名的事件类上未经请求就上报——模型回退启动、容量/权限请求、安全标记、验收/里程碑时刻、超过 settle 窗口仍被阻的人类寻址工作、idle/停摆告警。命名事件类与方式住在 messaging-the-human 技能 的the v0 event classes你的职责是在整个生命周期里真的用上这条通道而不是被逼到墙角才用。十、实现双档带 gate 的工作流仅当 gate 被选定这个可选循环只在 owner 或作者化 composition 为命名工作选择了 pre/post-edit QA 时才运行。tier 或 pair 拓扑本身不选择它。七步流程Impl 向 QA 发 pre-edit 提案QA 批准或带具体理由拒绝Impl 以 TDD 实现Impl 向 QA 发 post-edit diffQA 批准或拒绝Impl 提交对下一个任务重复。编排者不在这两者之间转发消息它们通过rig send直接通信。编排者监控的是任何一方的权限提示被卡死握手缺口双方都 idle、谁都不发起Impl 跳过 gate没等 QA 预批准就直奔实现QA 未真正评审橡皮图章式通过。派发措辞有讲究在带 gate 的 atom 上永远不要在未明确声明“第一步是向 QA 发 pre-edit”的情况下给 impl 发 “Go”——否则 impl 会一路冲过整个任务清单。在无 gate 的 atom 上通用的 “Go” 是正确的不要通过派发措辞把 gate 偷偷塞回去。十一、Dogfood 与评审的所有权边界Dogfood 指派可以授权结果 owner 诊断、修复并重测有界问题——要显式说出这个范围。只读评估保持只读QA 头衔不授权源码修改或更广的架构决策。当评估者亲自写了修复时保留任何被独立选定的最终检查。把超出指派范围的发现连同证据路由给其 owner。十二、权限与运行时处理以实际提示与声明权限为准用实际提示与声明的权限来决定介入永远不要从一个“无时间戳的 harness 配方”里选某个编号选项——提示形态与持久审批的后果会变化。一次经授权的解阻必须保留该操作的范围它不授予发布、破坏性或生命周期权力。模型与角色从环境的当前执行策略与观察到的能力中选取。既不是厂商标签也不是 seat 头衔决定谁可以写计划、实现、评审或验收工作。在依赖结果之前验证所需的运行时/模型身份。遵循声明的连续性策略上下文遥测是待解释的证据不是自动获得压缩或替换另一个 seat 的权限。十三、干预纪律与破坏性操作红线干预纪律Intervention discipline的前提认知是agent 把编排者的消息当作高权限命令它们会放下正在做的事去服从即使当前工作更重要。五条规则永远不要下命令只提供信息让 agent 自己决定何时行动永远明确说出“先完成你手上的事”finish what youre on first每次都说以“上下文更新”而非“指令”的方式表述不要打断工作中的 agent——只要有任何活动迹象就不要发消息只在确认的 idle上轻推——证据来自你的 watchdog 时钟化检查无活动信号 已结算的队列状态绝不用固定轮询计数或“等 N 个循环”的循环。破坏性操作——硬性规则。以下操作未经人类批准永不执行rig down --delete --force会杀掉 tmux 会话对 adopted/claimed rig 执行rig down --forcenpm publishgit push --force任何可能杀掉 agent 会话或摧毁共享状态的命令。执行任何破坏性操作前问自己“如果搞砸了能撤销吗”不能就先找人类确认。十四、Compaction 恢复之后与“不做清单”After compaction recovery推导身份与当前队列托管然后再次解析选定路径。读取恢复指针与相关的当前源码加载任务需要的 skills遵循任何显式声明的连续性检查。不要要求所有已安装 skill 或一场“测验”作为通用准入 gate。技能最后以“What you do not do”收束九条负面清单值得编排者逐条对照不要因为“那样更快”就去写生产代码不要在没理解 QA 或评审者顾虑的情况下推翻它们不要把阻塞中的 agent 伪装成有进展不要把隐藏工作队列记在脑子里而不是清晰地指派出去不要在 agent 之间转发消息它们直接通信不要自动批准破坏性操作不要用 deadline 压力催 agent不要仅凭运行时标签就授予规格或验收权不要在没有选定策略与权限的情况下仅凭上下文百分比改变连续性。结语orchestration-team/SKILL.md 本质上是一份“多智能体团队中编排者的运行手册”它把启动路径解析、队列化的状态读取、看门钟驱动的低成本监控、再教学优先的干预、带上下文的任务派发、有界紧盯、以及破坏性操作红线组织成一套可执行的纪律。配合 watchdog 的三档干预栈、product-journey-sdlc.md 的组件目录与路径解析规则以及 CLI 中 whoami/ps/queue/capture/send 等命令实现构成了 OpenRig “自运行 rig”这一北极星在编排层的全部支撑——理解并遵循它是搭建持久化 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 Orchestration Team 技能实战构建自运行 Agent 编排 Pod 的完整指南OpenRig Orchestration Team 技能实战构建自运行 Agent 编排 Pod 的完整指南 导读 本指南以 OpenRig 仓库中编排 P人工智能AI Agent多智能体Agent 编排代码智能体CLIOpenRig 开发团队 Pod 实战手册development-team 技能如何驱动 Builder / QA / Design 完成一个可交付的软件切片OpenRig 开发团队 Pod 实战手册development team 技能如何驱动 Builder / QA / Design 完成一个可交付的软件切片人工智能AI Agent多智能体Agent 编排代码智能体CLIopenrig product-team Rig 团队文化规范与实践指南双编排、开发 Pod 与独立评审的产品团队如何协作openrig product team Rig 团队文化规范与实践指南双编排、开发 Pod 与独立评审的产品团队如何协作 本指南聚焦 openrig 仓库中人工智能AI Agent多智能体Agent 编排代码智能体CLI上一篇Revive 并发检查机制深度解析为什么它能比 golint 快6倍下一篇深入理解gh_mirrors/auto/auto的模板系统Velocity与代码生成创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考