人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载OpenRig 是一个将 Claude Code 与 Codex 编排为统一多 Agent 系统的协作框架harness。本篇文章围绕 v0.5.15 版本展开重点讲解本次发布的三大主线启动与恢复体验含--existing名称消歧、可执行的恢复指引、首次启动受控重试、面向持续运行软件团队的 OpenRig Software Factory 指南手动团队工作 / 队列编排 / 显式 Workflow 三条路径以及用户自选命令权限的落地方法同时给出 macOS arm64 上 Node 版本选择建议与 Pi 回复可见性、终端输入处理的修复细节。读完本文你将掌握 v0.5.15 的升级要点、配套技能文件的读取命令并能依据源码与测试理解这些能力背后的实现边界。版本概览v0.5.15 改了什么v0.5.15 是 OpenRig 的一个修复与引导增强版本核心变化如下启动与恢复更清晰启动器同时识别原生 Codex通过 shell 与 Node launcher启动错误现在同时描述问题本身与对应的恢复动作名称同时命中 starter 与已停止 rig 时rig up name --existing可显式选择既有 rig。新增软件工厂公共指南面向持续运行的软件团队Software Factory覆盖角色分工、上下文、工作归属、独立评审、并发与成本并区分修改运行中的团队与保存更新后的 RigSpec。用户自选命令权限通过rig context get skills/applying-a-permission-policy/SKILL.md获取维护中的权限策略应用流程选择保留提示、记住选定命令或更宽泛的放行。Pi 修复Pi 回复与工具进度可见受支持的 RPC 事件形态shell 工具保留 OpenRig 管理上下文错误信息有界截断重试耗尽后不再重复打印粘贴内容需显式提交终端 runner 突破 canonical buffer 限制并支持恢复。已知兼容性限制macOS arm64 Node 24 下安装 SQLite 依赖可能失败官方建议该平台暂时使用Node 22。发布状态与日期记录在 GitHub release 与 npm 上项目根目录的 README 与 CHANGELOG 保持同步描述。启动与返回更清晰的指引与恢复路径启动前必读与版本核对v0.5.15 明确指出启动前应先阅读 README 中 what OpenRig changes on your machine 一节。原因是 provider 集成会配置可执行 hooks 与工作区信任——只修改OPENRIG_HOME并不能隔离 provider 配置。完整的首次任务引导见 getting-started 指南其中同样强调启动 rig 会写入 provider hooks 与 workspace trust 设置动手前应备份相关文件。安装完成后用三条命令核对本机可用命令rig --version rig --help rig up --help启动与恢复的语义启动与恢复识别原生 Codex经由 shell 与 Node launchers当进程身份无法确立时系统如实报告不确定性而不是猜测。识别到的更新通知会被跳过不会擅自安装 provider 更新认证与信任选择始终归用户所有。启动错误现在同时输出问题描述 恢复动作。若一个名称同时匹配 starter 与已停止的 rigrig up name --existing会选择既有 rig在继续分配工作前应先检查其上报状态。这一名称消歧逻辑在 CLI 实现中有据可查up.ts 中--existing选项的定义为将source视为既有 rig 名称绕过 library-spec 名称解析当名称同时命中 library 匹配与既有 rig 恢复目标时命令会打印歧义提示并指引使用rig up name --existing恢复既有 rig而不是静默导入 starter。若名称既非 library spec 也非既有 rig则继续走既有 rig 名称路径并打印 Recovering ... 提示。相关行为在 up.test.ts、up-restore-decision.test.ts 与 restore-check.test.ts 中有测试覆盖。首次启动失败后的受控重试v0.5.15 为新增座位首次启动失败引入守卫式重试guarded retry当座位在资源投影resource projection阶段失败、启动上下文尚未保存时可在修正配置问题后重试。使用上需要遵守保留完整的原始 member 片段及其 source root——仅凭快照无法重建缺失的启动配置一次只重试一个Use one retry at a time普通会话恢复ordinary conversation resume是另一条独立路径。服务端实现位于 rigspec-instantiator.ts测试 retry-first-start.test.ts 详尽验证了守卫语义投影失败、启动上下文node_startup_context未保存、launchHarness未调用的节点在修正后可通过/api/rigs/:rigId/nodes/:nodeId/launch传入retryStartupFrom: { member, rigRoot }重试成功后节点状态为launched且不触碰兄弟节点、不改变历史、不产生 resume token已就绪ready的 occupant 永远不会被重分类为失败的首次启动——重试请求返回409liveness 检查期间present / transport_unavailable同样409 拒绝且无副作用异步 liveness 检查期间座位被变更如模型被改写时返回 Seat changed during recovery checks; inspect it before retrying.拒绝执行存在 resume token、native session、late-failure、spec 变更、member 变更或 overrides 时一律拒绝投影与启动。这套守卫保证重试只作用于真正的首次启动未完成场景避免误伤正常会话。继续有用且经过评审的工作OpenRig Software Factoryv0.5.15 随包提供OpenRig Software Factory食谱给 Agent 一个真实仓库、一个目标结果、以及你想保留的决策即可支撑直接团队协作、队列编排、或可选的显式 Workflow三种工作方式。读取随包技能rig context show skills/core/openrig-software-factory --json rig context get skills/core/openrig-software-factory/SKILL.md rig context get skills/core/openrig-software-factory/references/worked-example.md仓库中的规范副本位于 skills/_canonical/core/openrig-software-factory/SKILL.md发布镜像在 packages/daemon/specs/agents/shared/skills/core/openrig-software-factory/SKILL.md配套工作示例为 references/worked-example.md。选择团队的工作方式三条递进路径需求起点何时升级一次变更、人类近距离指导手动/团队工作把结果交给 owner使用仓库说明实现并取得选定的独立检查工作需要跨轮次存活或在座位间流转时持续工作、归属可见队列编排rig queue create创建认领工作再用rig queue handoff把候选/证据交给下一 owner记录真实阻塞与续接。无需 Workflow 实例重复步骤需要显式依赖图与允许出口时显式执行契约Workflow先rig workflow compile检查再刻意使用rig workflow instantiate-lifecycle通过 workflow projection 机制推进其 packets实际项目需要可复用 profile、额外角色或门禁时关键提醒路线图、YAML 文件或 wake 并不会执行工作或授权新结果。建立工作约定working agreement读取仓库说明、当前工作与用户期望的可见结果核实目标实例、代码/工作根目录、真实 seat 地址与原生就绪状态。复用合适的小团队现有 agent 可以引导bootstrap新团队。kernel operator 是可选的且并不自动成为项目 owner。约定工作边界、时间/花费上限、未决选择由谁回答、何时停止检查通过 / 无授权后续工作 / 预算耗尽 / 真实的用户-权限-provider 阻塞。成本意识后台 daemon 检查本身不是 model turn但已投递的 wake 与被唤醒恢复的工作会消耗 token优先采用事件驱动等待而非频繁的空提醒。wake 无法回答用户问题、清除权限提示或保证进度。启动或分配工作前先选好权限保留普通提示、为选定命令建立持久规则、或刻意放宽访问三者皆可跟随 Applying a permission policy 执行用户的选择并在目标会话中验证。放宽整个rig家族意味着允许每个 verb不只读取但它不授予新产品权限也不改变其他人的默认值。把目的、验收、决策与证据保留在既有项目文件中检索到上下文不等于peer 已送达。owner 携带候选成果走完选定的检查与有界修复报告如何试用并保留下一项授权任务或如实报告没有。扩容你的工厂Grow your factory使用双 Agent 起点保持既有 owner 与独立 checker直到该组合无法承受工作负载。owner 可同时负责实现与协调。向运行中的 rig 增加一到两个座位这是常规下一步。跟随 worked-example 的 Grow the running team 使用rig grow无需 YAML、无需 down/up 重建既有会话。命令层面见 grow.tsAdd one or more seats to a running rig。典型命令rig grow $RIG_ID a b --pod dev --runtime codex --cwd $PROJECT_ROOT --json--pod加入既有 pod--new-pod build建立新 pod二者互斥runtime 默认claude-code、cwd 默认调用者当前目录因此示例刻意显式选择了 Codex 与仓库目录。新座位不会继承owner 的自定义 agent、模型、上下文、原生权限 profile 或会话必须显式分配职责。自定义 rig需要不同结构时可读取 OpenRig Architect 技能通过rig context get skills/core/openrig-architect/SKILL.md获取请求语例如Design a user-owned rig for [outcome] using the compatible RigSpec/AgentSpec guidance…。扩容语义提醒增加座位不会自动分配工作、改变权限或创造并行需在既有项目文件中显式记录分工、文件/worktree 边界与集成归属并把活跃并发控制在用户的时间/花费预算内。两个座位是入口点不是成品工厂也不是上限。扩容后可用rig export $RIG_ID -o ...保存展开后的拓扑为独立文件并用rig spec validate与rig doctor --spec核对成员一致性注意 export 并非对每个原始 authoring 字段无损。读取兼容版本指引安装前应在与所选包相同的发布 tag 或 commit下使用该技能文件与配套文档安装后核对rig --version rig context list --json rig context show skills/core/openrig-software-factory --json rig context get skills/core/openrig-software-factory/SKILL.md不仅要比较版本号还要比较构建身份。缺失、不可读或更旧的食谱结果应如实保留不要静默替换为较新的 main 或跳过缺失的配套文档。兼容的权限指南在哪里检索维护中的流程rig context get skills/applying-a-permission-policy/SKILL.md。源码/归档读者的路径对照如下这些路径相对于命名根而非本技能文件阅读来源流程与指南与食谱同版本源码检出含skills/_canonical仓库根以下packages/daemon/assets/plugins/openrig-core/skills/applying-a-permission-policy/SKILL.md与docs/reference/getting-started.mdnpm 安装对应npm root -g或本地npm root以下openrig/cli/daemon/assets/plugins/openrig-core/skills/applying-a-permission-policy/SKILL.md与openrig/cli/daemon/docs/reference/getting-started.md解包的 npm 归档解包目录以下package/daemon/assets/plugins/openrig-core/skills/applying-a-permission-policy/SKILL.md与package/daemon/docs/reference/getting-started.md对于已安装的指引使用提供所选rig可执行文件的 npm 安装另一个 prefix 或本地项目可能含有不同版本。配套指南或章节缺失时先报告缺口再继续不要用当前 main 或另一安装的指南替代。给 Agent 的标准请求Help me achieve [observable change] in this repository. Read the compatible Software Factory recipe, choose the lightest useful team/queue/Workflow path, and keep the next owner visible. Preserve existing files and permissions. Agree time/spend limits, perform the authorized work and chosen independent check, and ask only about unresolved decisions or effects outside that scope. Keep publication and destructive changes out of this task.选择命令权限Applying a permission policyv0.5.15 强调由用户选择权限范围Agent 负责检查目标 harness、解释可用范围、在保留既有规则的前提下落地选择。取回维护中的流程rig context get skills/applying-a-permission-policy/SKILL.md仓库中的规范副本位于 packages/daemon/assets/plugins/openrig-core/skills/applying-a-permission-policy/SKILL.md。三选一保留提示 / 记住命令 / 更宽泛放行选择Agent 配置什么保留提示Keep prompts保留当前原生设置按需处理请求记住选定命令Remember selected commands为所选命令族或更窄 verb 增加原生 allow 规则其余规则与 sandbox 设置保持不变更宽泛的放行Broader permissive operation解释文件系统/网络暴露面仅配置显式选定的原生模式与兼容启动设置放行整个rig家族覆盖其所有 verb——包括生命周期、拓扑/配置变更以及能启动其他进程的命令绝非只读授权。请求更窄时提供rig ps、rig queue list之类前缀。不要把选择扩大到任意 shell 执行、整个解释器或通用 shell 包装。落地流程六步定位目标座位、可执行文件/版本、启动设置与配置根HOME、CODEX_HOME或CLAUDE_CONFIG_DIRoperator、daemon、seat 三者可能不同读取既有权限规则与管理限制选定范围单项目或用户全部会话准备具体 diff保留 deny/ask 规则、审批/sandbox 姿态、hooks、auth、MCP、模型设置与无关值allow 不得抹掉更严规则或管理要求遇到真实冲突要报告而非静默绕过备份被改文件仅合并被授权的增补避免重复Agent 负责执行编辑回读 diff、验证格式确认该版本如何加载变更若需新会话则保留工作并走受支持的 resume 路径文件写入不能证明既有会话已加载在目标会话中两次验证一次普通匹配操作并确认无关命令未获得匹配规则用无害读取而非破坏性探测。回滚时只移除本次设置的增补保留后续无关编辑。内置 policy spec 保持只读自定义应在用户空间进行。Codex 与 Claude 的命令规则Codex命令规则可在 sandbox 之外放行匹配命令而不再次提示且不改变其他 sandbox/网络设置。目的地按范围二选一仅此项目验证已安装版本支持项目规则、推导实际项目/worktree 配置根与信任状态仅当repo/.codex/rules/层受支持、已激活且被信任时使用否则报告限制并保持用户层规则不变绝不静默标记项目为可信或代以用户级放行。明确用户级使用目标用户实际CODEX_HOME通常~/.codex/rules下的rules/——这会波及使用该 home 的其他项目。TUI 的 remember-allow 动作同样写入用户层规则不能用来实现仅项目的请求。规则片段前缀本身没有项目限制即使项目层规则也不限制被放行的rig命令影响哪些目标prefix_rule(pattern [rig], decision allow)更窄可用[rig, ps]或[rig, queue, list]。绝对路径调用需推导目标座位实际rig可执行文件并单独加一条精确前缀。验证用codex execpolicy check --pretty --rules /absolute/path/to/openrig.rules -- rig ps --json codex execpolicy check --pretty --rules /absolute/path/to/openrig.rules -- printf permission-check注意检查匹配结果而非仅退出码prompt/forbidden匹配优先于 allow。codex execpolicy check是独立求值器只校验给定 argv原生 shell 解析可能先拆分普通命令/链因此zsh -lc不匹配不能证明原生rig rig会失败需要两个表面都验证且不要把规则放宽到bash、sh、node等通用包装。Claude Code把所选条目合并进既有permissions.allow该片段不是替换性 settings 文件{ permissions: { allow: [Bash(rig *)] } }当前语法用*表示命令族Bash(rig:*)同样受支持更窄示例为Bash(rig ps *)、Bash(rig queue list *)。保留deny/ask与defaultMode不要为了消除不匹配而添加Bash(*)或切到 bypass。范围选择.claude/settings.local.json个人项目设置、.claude/settings.json刻意共享的项目设置或目标CLAUDE_CONFIG_DIR通常~/.claude下的settings.json。项目级权限的边界项目级配置要求受支持、已激活、被信任仅当项目配置可用时才能做 project-only 设置若不可用Agent 应解释限制而不是代之以用户级权限。备份被改文件并在实际会话中验证所选规则。v0.5.15 明确随包提供的 sandbox、审批与权限默认值不变——选择规则或更宽模式不会改变出厂默认。配套细节见 getting-started 指南的 Opt-in permissive operation 一节例如 Codex 命名 profile 的sandbox_mode danger-full-accessapproval_policy never、成员级codex_config_profile字段、以及permission_policy: builtin:yolo选择-s danger-full-access -a never与 Claude--dangerously-skip-permissions的对应关系。权限模式是原生执行选择工作姿态是项目指引二者分离rig seat set-permissions ... --mode full_bypass|floor|inherit记录 actor、理由与新旧选择但不重新启动座位、不改变兄弟座位、不编辑规则/hooks。已知兼容性限制macOS arm64 请用 Node 22v0.5.15 记录了一个已知兼容性限制在 macOS arm64 Node 24 环境下安装 SQLite 依赖可能在以下情形失败合适的预编译二进制不可用且本机无编译能力compilation is not available编译构建的 SQLite 也曾在运行时数据库清理database cleanup期间失败。官方建议macOS arm64 暂时使用 Node 22。该建议不改变已声明的 Node 支持范围本版本也未升级 SQLite。入门指南 getting-started.md 与之呼应支持 Node.js 22 或 24 与 tmuxmacOS/LinuxApple silicon 的 Mac 请使用 Node.js 22原生 Windows 尚不支持WSL2 未经测试Node 20 不再受支持Node 26 及其他版本未经测试。README 同样将 兼容性历史 指向本小节。Pi 回复、输入与恢复本次修复细节Pi 回复与 shell 上下文Pi 回复与工具进度可见对受支持的 RPC 事件形态生效。修复来自社区 PR见下文 Contributors。Shell 工具保留受管理的 OpenRig 上下文身份与路由所需的上下文不再丢失。Provider 错误有界显示错误以受限文本bounded text呈现重试耗尽后不再重复打印同一错误。终端输入处理粘贴的消息等待显式提交explicit submission不会自动执行。终端 runner 接受超出终端 canonical buffer 上限的输入保留编辑与取消能力并在拒绝超大 framed 消息后能够恢复。官方明确这不是通用延迟保证或不受限输入大小的承诺。首次启动失败后的受控重试Pi 相关新增座位若在资源投影阶段、启动上下文保存之前首次启动失败可在修正 setup 问题后使用受控重试。要点已在前文展开保留完整原始 member 片段与 source root快照不足以重建缺失的启动配置、一次只重试一个、普通会话恢复独立。服务端守卫与 409 拒绝语义见 retry-first-start.test.ts。Pi 支持是有资质且受监督的qualified and supervisedv0.5.15 如实声明 Pi 支持的验证范围已用Pi 0.87.1与 OpenRouterz-ai/glm-5.3-flash验证受控编码、追问、汇报与对话连续性普通座位ordinary-seat的身份、工具与回复也可用。未验证完成一个普通有用任务、无人值守的团队操作unattended team operation。上下文 profile 选择与 hook 生成的覆盖有限——不要假定与每个 Codex 或 Claude 集成对等Software Factory 指南同样不构成完全无人值守运行的保证。这些限定说明 Pi 路径当前适合受监督的实验性使用而非生产无人值守。贡献者与本次包含的 Pull Requests感谢社区与维护者的贡献[danielkuykendall23-boop]Pi 回复修复#37[mvschwarz]Codex 启动与恢复指引#38、Software Factory 与权限指引#39、贡献与支持指引#45、首次使用 README#46。此外本版本还包含上述启动身份细化、守卫式首次启动重试、Pi shell/错误处理与终端输入修复。项目工作策略特性project work-policy features与 Node 22/SQLite 13 升级不在本版本范围内——升级到更高版本前请以对应版本的发布说明为准。小结v0.5.15 的定位是把启动与恢复做扎实、把持续协作的方法论落到技能文件里、把权限选择明确交还给用户并顺带修复 Pi 与终端输入的一批实际问题。升级后建议按序执行核对rig --version→ 阅读 README 的机器变更说明 → 走一遍 getting-started 首次任务 → 用rig context get skills/core/openrig-software-factory/SKILL.md与rig context get skills/applying-a-permission-policy/SKILL.md引入协作与权限约定在 macOS arm64 上保持 Node 22。所有关键行为的边界守卫重试、名称消歧、权限三选一都能在本仓库的源码与测试中找到对应实现便于你在实际部署中验证与排障。赞分享人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载相关推荐Garnet AOF文件修复日志损坏恢复工具使用Garnet AOF文件修复日志损坏恢复工具使用 引言AOF日志损坏的致命风险 在分布式缓存系统中数据持久化是保障业务连续性的关键环节。Garnet作为微缓存KV存储后端从安装到高级配置Diffy for Ruby完全使用手册从安装到高级配置Diffy for Ruby完全使用手册 Diffy是一款专为Ruby开发者设计的差异比较工具能够轻松实现文本内容的对比与分析。本文将从基础终极视频修复指南使用ffmpeg-python恢复损坏文件的完整工作流终极视频修复指南使用ffmpeg python恢复损坏文件的完整工作流 视频文件损坏是许多用户面临的常见问题但通过 ffmpeg python 这个强大的P音视频视频处理音频处理创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考