人工智能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 内置技能 agent-operated-software/SKILL.md 为核心骨架系统讲解“由 Agent 长期运营的软件”Agent-Operated Software在 OpenRig 中的架构定位、控制平面设计、工件自证机制、Agent SDLC 与故障修复原则。读者将掌握如何区分 AI-enabled 软件、Agent-Operated Workflow 与 Agent-Operated Software 三种架构如何用 Markdown 作为可寻址的控制平面如何让工件自证完整以及如何借助rig proof、rig walk、rig scope audit等命令搭建可验证、可交接、可长期演化的 Agent 化应用。从共享分类法开始三种架构的边界在进入设计之前必须先给架构“命名”。OpenRig 在agent-operated-software技能中给出了一套三分类的共享分类法taxonomy它同样出现在姊妹技能 agent-operated-workflows/SKILL.md 中是全仓库统一使用的词汇表架构类别控制环归属判定标准AI-enabled 软件应用代码拥有控制环模型只是被调用的一种能力调用模型 ≠ Agent 化Agent-Operated WorkflowAgent 拥有一个有起点和终点、边界明确的流程有 start/stop 条件见agent-operated-workflowsAgent-Operated SoftwareAgent 参与一个持续运行应用的活后端live backend或控制环应用表面可以很薄工作由结构化状态与专家角色完成三条边界值得反复强调仅仅调用模型不算 Agent 化。一个确定性程序即使每步都咨询模型控制环仍属于程序本身。有界流程不等于 Agent 化应用。一个应用可以组合多个 Agent-Operated Workflow但单个有界工作流本身并不使整个产品成为 Agent-Operated Software。Agent 必须拥有控制环的一部分。这是“软件”与“应用代码调模型”之间的分界线。从仓库源码看这套分类在技能体系内部是自洽的agent-operated-software与agent-operated-workflows互为 sibling且software-for-agents技能已标记为stage: deprecated作为一版兼容性重定向明确“加载agent-operated-software以获取被维护的架构与运营指导”并计划在 0.6.0 移除见 software-for-agents/SKILL.md——这从侧面证明该技能是当前正在演进的权威主体。Agent 是后端的一部分行为不止存在于函数里在 Agent-Operated Software 架构中一个关键认知转变是行为并不只存在于代码函数中。行为被分布到多个层Agentagent技能skill指令instructions引导文件bootstrap files模式schemasMarkdown / YAML / JSON 文件文件夹结构确定性工具deterministic tools因此一个“令人惊讶的结果”surprising result既可能是一个代码缺陷也可能是控制平面中的一致性缺口coherence gap。正确的排查姿势是先追踪真正产生该行为的路径再决定修复哪一层而不是凭直觉乱改。这条原则有一个重要限定它不是容忍 OpenRig 核心或其他坚固基座rock-solid substrate缺陷的借口。对于核心层正确的做法是复现 bug、修复代码、跑完全部门禁hold the full gate。而“先一致性、后速度”coherence-first的快速姿态只适用于可恢复的 Agent 化应用层——那些状态和行为可以被廉价检查与修复的层。OpenRig 项目本身就是一个活生生的例子demo/目录下同时存在 rig.yaml拓扑定义与多个agent.yamlAgentSpecpackages/daemon/assets/plugins/openrig-core/下则有 20 余个 SKILL.md 与配套scripts/、templates/。行为确实“分布”在 YAML、Markdown 与 TS 源码之间而不是单一入口。Markdown 就是控制平面可寻址、可演进、可执行“Markdown 是控制平面”是本技能最核心的工程主张Markdown 对 Agent 而言最大化可用同时仍足够清晰以便人类操控。具体做法是把意图intent、工作状态work state、证据evidence和决策decisions写进稳定的、可寻址的工件stable addressed artifacts而不是私人聊天或某个不透明的自定义数据库。Schema 与约定必须与运行行为保持一致——Agent 群体把这些文件当作可执行上下文来行动。渐进式披露Progressive Disclosure技能采用渐进式披露来平衡上下文成本技能的名称和 description 是“热触发”hot trigger技能正文是“冷流程”cold proceduredescription 只说何时加载不说如何工作正文负责把读者路由到精确的源头而不是把内容复制成另一份教义分支。这套机制在 forming-an-openrig-mental-model/SKILL.md 中有更详细的底层解释harness 在启动时只廉价读取所有技能的 frontmatter名称描述正文仅在技能激活时才加载——这是“环境感知”ambient awareness知道技能存在几乎不花 token取用时才付费。脚本也可以充当提示词prompt技能明确主张脚本可以充当提示词。一个好的脚本应返回 Agent 需要的上下文或精确效果当它做不到时它的失败信息应当教导 Agent它观察到了什么、为什么停止、安全的下一个动作是什么。总原则是——把确定性机制放进工具把判断留给 Agentkeep deterministic mechanics in tools and judgment in agents。仓库中的 loading-addressable-markdown/SKILL.md 就是“脚本即提示词”的实例resolve-markdown.mjs从任意文件系统树中精确加载一个 Markdown 区段file.md#h2-slug或file.md#h2-slug/h3-slug它失败时大声报错重复或缺失路径会 fail loudly而不是静默返回错误内容。让工件自证完整Self-Certifying Artifacts当一个工具产出工件时不应让每个消费者各自发明一套“完整性测试”。技能给出了四步自证协议写入部分路径绝不直接写最终路径write to a partial path, never the final path验证真正可能出错的属性——如时长duration、流streams、分辨率resolution或 schemaflush 并原子重命名atomically rename部分工件为最终路径最后写 manifest然后写.done哨兵文件。消费者在共享证明上失败关闭fail closed——即缺少.done哨兵或 manifest 就视为不完整。技能特别强调文件名或退出码不是内容验证a filename or exit code is not content verification。这套“原子写入 哨兵”协议是分布式系统中最常见的可靠性手段与 write-ahead、commit marker 同源在 Agent 化应用中它解决的是信任问题Agent 之间不能靠“看起来完成了”互相信任只能靠可验证的物理证据。用 Agent SDLC 构建判断、证据与权威分层Agent 化软件也需要软件开发生命周期但它的判断模型与人类项目不同。技能给出的核心设计是判断分层与证据归属分离范围关系scope relationships、归因的、证据支撑的条目判断attributed evidence-backed item judgment、真正独立的高层判断genuinely distinct higher judgment各有独立的所有者一个条目的判断item judgment由其**上游就绪状态upstream readiness**派生Agent 不去同步父级复选框、队列标签或状态散文捕获不等于验收capture alone is not acceptance就绪不等于发布或推进工作流readiness does not publish or advance a workflow使用openrig-operating-model和rig proof --help获取受支持的判断、纠正与读取路径历史锁与证据必须保持可寻址人类提供项目权威为其保留的方向、品味与决策。rig proof的源码级佐证这条原则在 CLI 层有直接实现。查看 packages/cli/src/commands/proof.ts 的命令定义可以看到三条核心子命令rig proof show [scope]读取切片slice、任务mission或活动项目的当前归因证明就绪状态不修改任何状态文件rig proof judge scope-item记录一条归因的条目判断并派生就绪状态。条目定位使用mission/slices/slice#itemindex、文本或 ID判断者judges从拥有方 slice/mission/project 的proofPolicy.judges继承nearest wins使用精确的 actor 地址不存在隐式的固定角色评审传送带rig proof add slice-path投递一个证明工件为slice/proof/name生成 C1 frontmatter——其契约/自检/C8 输出均为 advisoryexit 0永远不是门禁。配套的rig walk命令packages/cli/src/commands/walk.ts与rig scope auditpackages/cli/src/commands/scope.ts分别承担“按节奏推送链式上下文”与“确定性审计后盾”的职责——后者在 mission-slice-sop/SKILL.md 中被明确为 advisory / fail-open只记录建议、从不阻塞写入。判断模型与 Operating Model 的关系agent-operated-software明确指向openrig-operating-model技能openrig-operating-model/SKILL.md。两者配合构成完整的 Agent SDLC 语境Operating Model 定义了两棵树拓扑树fleet → instance → rig → pod → seat与工作树project → mission → slice → proof item工作树每层只有一个权威节点文件SPEC.mdfrontmatter 放intent:正文放规格旁边是NOTES.mdLIVED执行者的第一人称记录、PROOF.md证明者书写、PROGRESS.md叙述性历史清单与proof/judgments/rig proof judge写入的保留判断回执就绪状态向上聚合slice → mission → project意图向下组合intent:字段在每层可读四层展开为四句话而非四份文档模板与脚手架已随技能发布见 templates/SPEC.md 与 scripts/scaffold.sh只创建缺失的链文件从不覆盖或删除任何内容。对 studio 应用的迭代建议技能还给出一个针对“工作室型应用”studio application的实操判断运行中的产品通常是最好的迭代表面iteration surface。单独的 mockup 只有在它能解决“运行中的应用无法廉价暴露”的真实设计不确定性时才值得制作——它移除的是一个冗余工件而不是视觉评审或证明契约。修复最窄权威层Repair the Narrowest Authoritative Layer当 Agent 化系统出错时修复姿势决定了系统的长期健康。核心原则是找到所有受影响 Agent实际消费的那个生成器或源头。代码缺陷改代码缺失的触发条件改技能损坏的契约改 schema。然后通过消费者验证修复。编辑一份渲染后的或已安装的副本制造的是临时分叉temporary fork而不是修复。这条原则在仓库中有多处可验证的落点配置层demo/rig.yaml与各demo/agents/*/agent.yaml是拓扑与 Agent 的权威源运行时投影到 harness 的 skill 目录文档层Operating Model 明确“链文件是事实源渲染文档是生成视图、绝不手工编辑”——渲染丢失编辑恰恰是最常见的“修错层”失败见 openrig-operating-model/SKILL.md 的 Pitfalls 一节CLI 层rig proof show返回当前依据与保留回执但它“不发布任何东西”——发布是另一权威层的职责。为什么“修最窄权威层”收益会复利技能给出了一句点睛之笔对共享应用控制平面的一次修正会改变下一个 Agent 的起点a correction to the shared application control plane changes the next agents starting point。这正是持续运行的 Agent 化系统可以不依赖“某个人类当永久路由器”而不断自我改进的机制。写给 Agent 与 LLM 的检索要点如果你是一个即将在 OpenRig 拓扑中工作的 Agent本技能agent-operated-softwarestage:provisional是你在以下场景的首选加载项正在设计、构建、运营或诊断一个持续运行的应用且其活后端或控制环包含 OpenRig Agent——包括使用 Markdown / YAML / JSON Agent 控制平面、或对专家 Agent 角色做薄封装的应用。需要记住的可操作要点先命名架构调用模型 ≠ AI-enabled有界流程 ≠ Agent-Operated SoftwareAgent 必须拥有控制环的一部分。行为可能藏在控制平面遇到意外结果先追踪产出路径再决定修哪层对 OpenRig 核心则复现、修复、过全部门禁。Markdown 是控制平面意图/状态/证据/决策进可寻址工件技能名与 description 是热触发正文是冷流程。工件要自证部分路径 → 验证 → 原子重命名 → manifest →.done哨兵消费者 fail closed。SDLC 判断分层rig proof judge/show/add记录归因判断并派生就绪捕获≠验收就绪≠发布。修最窄权威层修代码缺陷在代码、修触发条件在技能、修契约在 schema然后从消费者侧验证永远不要编辑渲染副本。如果是在一个全新座位上首次入场建议先加载 forming-an-openrig-mental-model/SKILL.mdrig whoami --json是你的身份地面真相再回到本技能投入 Agent 化应用的构建与运营。赞分享人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载相关推荐Agent-Operated Workflows 实战在 OpenRig 中让 Agent 拥有有界流程的控制权Agent Operated Workflows 实战在 OpenRig 中让 Agent 拥有有界流程的控制权 Agent Operated Workflo人工智能AI Agent多智能体Agent 编排代码智能体CLIOpenClaw ACPX 插件深度解析用 Agent Client Protocol 把外部编码 Agent 装进 OpenClaw 的 ACP 运行时后端OpenClaw ACPX 插件深度解析用 Agent Client Protocol 把外部编码 Agent 装进 OpenClaw 的 ACP 运行时后端AI 应用AI Agent交互助手后端即时通讯网关OpenHands Agent Canvas自托管编码 Agent 控制中心的安装、运行与架构解析OpenHands Agent Canvas自托管编码 Agent 控制中心的安装、运行与架构解析 OpenHands Agent Canvas 是一个自托管人工智能AI Agent代码智能体前端后端上一篇TensorFlow Text 项目常见问题解决方案下一篇告别卡顿与挫败PBCharacterMovement经典FPS移动系统全场景问题解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OpenRig 中的 Agent-Operated Software：把 Agent 装进应用后端与控制环的架构指南
人工智能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 内置技能 agent-operated-software/SKILL.md 为核心骨架系统讲解“由 Agent 长期运营的软件”Agent-Operated Software在 OpenRig 中的架构定位、控制平面设计、工件自证机制、Agent SDLC 与故障修复原则。读者将掌握如何区分 AI-enabled 软件、Agent-Operated Workflow 与 Agent-Operated Software 三种架构如何用 Markdown 作为可寻址的控制平面如何让工件自证完整以及如何借助rig proof、rig walk、rig scope audit等命令搭建可验证、可交接、可长期演化的 Agent 化应用。从共享分类法开始三种架构的边界在进入设计之前必须先给架构“命名”。OpenRig 在agent-operated-software技能中给出了一套三分类的共享分类法taxonomy它同样出现在姊妹技能 agent-operated-workflows/SKILL.md 中是全仓库统一使用的词汇表架构类别控制环归属判定标准AI-enabled 软件应用代码拥有控制环模型只是被调用的一种能力调用模型 ≠ Agent 化Agent-Operated WorkflowAgent 拥有一个有起点和终点、边界明确的流程有 start/stop 条件见agent-operated-workflowsAgent-Operated SoftwareAgent 参与一个持续运行应用的活后端live backend或控制环应用表面可以很薄工作由结构化状态与专家角色完成三条边界值得反复强调仅仅调用模型不算 Agent 化。一个确定性程序即使每步都咨询模型控制环仍属于程序本身。有界流程不等于 Agent 化应用。一个应用可以组合多个 Agent-Operated Workflow但单个有界工作流本身并不使整个产品成为 Agent-Operated Software。Agent 必须拥有控制环的一部分。这是“软件”与“应用代码调模型”之间的分界线。从仓库源码看这套分类在技能体系内部是自洽的agent-operated-software与agent-operated-workflows互为 sibling且software-for-agents技能已标记为stage: deprecated作为一版兼容性重定向明确“加载agent-operated-software以获取被维护的架构与运营指导”并计划在 0.6.0 移除见 software-for-agents/SKILL.md——这从侧面证明该技能是当前正在演进的权威主体。Agent 是后端的一部分行为不止存在于函数里在 Agent-Operated Software 架构中一个关键认知转变是行为并不只存在于代码函数中。行为被分布到多个层Agentagent技能skill指令instructions引导文件bootstrap files模式schemasMarkdown / YAML / JSON 文件文件夹结构确定性工具deterministic tools因此一个“令人惊讶的结果”surprising result既可能是一个代码缺陷也可能是控制平面中的一致性缺口coherence gap。正确的排查姿势是先追踪真正产生该行为的路径再决定修复哪一层而不是凭直觉乱改。这条原则有一个重要限定它不是容忍 OpenRig 核心或其他坚固基座rock-solid substrate缺陷的借口。对于核心层正确的做法是复现 bug、修复代码、跑完全部门禁hold the full gate。而“先一致性、后速度”coherence-first的快速姿态只适用于可恢复的 Agent 化应用层——那些状态和行为可以被廉价检查与修复的层。OpenRig 项目本身就是一个活生生的例子demo/目录下同时存在 rig.yaml拓扑定义与多个agent.yamlAgentSpecpackages/daemon/assets/plugins/openrig-core/下则有 20 余个 SKILL.md 与配套scripts/、templates/。行为确实“分布”在 YAML、Markdown 与 TS 源码之间而不是单一入口。Markdown 就是控制平面可寻址、可演进、可执行“Markdown 是控制平面”是本技能最核心的工程主张Markdown 对 Agent 而言最大化可用同时仍足够清晰以便人类操控。具体做法是把意图intent、工作状态work state、证据evidence和决策decisions写进稳定的、可寻址的工件stable addressed artifacts而不是私人聊天或某个不透明的自定义数据库。Schema 与约定必须与运行行为保持一致——Agent 群体把这些文件当作可执行上下文来行动。渐进式披露Progressive Disclosure技能采用渐进式披露来平衡上下文成本技能的名称和 description 是“热触发”hot trigger技能正文是“冷流程”cold proceduredescription 只说何时加载不说如何工作正文负责把读者路由到精确的源头而不是把内容复制成另一份教义分支。这套机制在 forming-an-openrig-mental-model/SKILL.md 中有更详细的底层解释harness 在启动时只廉价读取所有技能的 frontmatter名称描述正文仅在技能激活时才加载——这是“环境感知”ambient awareness知道技能存在几乎不花 token取用时才付费。脚本也可以充当提示词prompt技能明确主张脚本可以充当提示词。一个好的脚本应返回 Agent 需要的上下文或精确效果当它做不到时它的失败信息应当教导 Agent它观察到了什么、为什么停止、安全的下一个动作是什么。总原则是——把确定性机制放进工具把判断留给 Agentkeep deterministic mechanics in tools and judgment in agents。仓库中的 loading-addressable-markdown/SKILL.md 就是“脚本即提示词”的实例resolve-markdown.mjs从任意文件系统树中精确加载一个 Markdown 区段file.md#h2-slug或file.md#h2-slug/h3-slug它失败时大声报错重复或缺失路径会 fail loudly而不是静默返回错误内容。让工件自证完整Self-Certifying Artifacts当一个工具产出工件时不应让每个消费者各自发明一套“完整性测试”。技能给出了四步自证协议写入部分路径绝不直接写最终路径write to a partial path, never the final path验证真正可能出错的属性——如时长duration、流streams、分辨率resolution或 schemaflush 并原子重命名atomically rename部分工件为最终路径最后写 manifest然后写.done哨兵文件。消费者在共享证明上失败关闭fail closed——即缺少.done哨兵或 manifest 就视为不完整。技能特别强调文件名或退出码不是内容验证a filename or exit code is not content verification。这套“原子写入 哨兵”协议是分布式系统中最常见的可靠性手段与 write-ahead、commit marker 同源在 Agent 化应用中它解决的是信任问题Agent 之间不能靠“看起来完成了”互相信任只能靠可验证的物理证据。用 Agent SDLC 构建判断、证据与权威分层Agent 化软件也需要软件开发生命周期但它的判断模型与人类项目不同。技能给出的核心设计是判断分层与证据归属分离范围关系scope relationships、归因的、证据支撑的条目判断attributed evidence-backed item judgment、真正独立的高层判断genuinely distinct higher judgment各有独立的所有者一个条目的判断item judgment由其**上游就绪状态upstream readiness**派生Agent 不去同步父级复选框、队列标签或状态散文捕获不等于验收capture alone is not acceptance就绪不等于发布或推进工作流readiness does not publish or advance a workflow使用openrig-operating-model和rig proof --help获取受支持的判断、纠正与读取路径历史锁与证据必须保持可寻址人类提供项目权威为其保留的方向、品味与决策。rig proof的源码级佐证这条原则在 CLI 层有直接实现。查看 packages/cli/src/commands/proof.ts 的命令定义可以看到三条核心子命令rig proof show [scope]读取切片slice、任务mission或活动项目的当前归因证明就绪状态不修改任何状态文件rig proof judge scope-item记录一条归因的条目判断并派生就绪状态。条目定位使用mission/slices/slice#itemindex、文本或 ID判断者judges从拥有方 slice/mission/project 的proofPolicy.judges继承nearest wins使用精确的 actor 地址不存在隐式的固定角色评审传送带rig proof add slice-path投递一个证明工件为slice/proof/name生成 C1 frontmatter——其契约/自检/C8 输出均为 advisoryexit 0永远不是门禁。配套的rig walk命令packages/cli/src/commands/walk.ts与rig scope auditpackages/cli/src/commands/scope.ts分别承担“按节奏推送链式上下文”与“确定性审计后盾”的职责——后者在 mission-slice-sop/SKILL.md 中被明确为 advisory / fail-open只记录建议、从不阻塞写入。判断模型与 Operating Model 的关系agent-operated-software明确指向openrig-operating-model技能openrig-operating-model/SKILL.md。两者配合构成完整的 Agent SDLC 语境Operating Model 定义了两棵树拓扑树fleet → instance → rig → pod → seat与工作树project → mission → slice → proof item工作树每层只有一个权威节点文件SPEC.mdfrontmatter 放intent:正文放规格旁边是NOTES.mdLIVED执行者的第一人称记录、PROOF.md证明者书写、PROGRESS.md叙述性历史清单与proof/judgments/rig proof judge写入的保留判断回执就绪状态向上聚合slice → mission → project意图向下组合intent:字段在每层可读四层展开为四句话而非四份文档模板与脚手架已随技能发布见 templates/SPEC.md 与 scripts/scaffold.sh只创建缺失的链文件从不覆盖或删除任何内容。对 studio 应用的迭代建议技能还给出一个针对“工作室型应用”studio application的实操判断运行中的产品通常是最好的迭代表面iteration surface。单独的 mockup 只有在它能解决“运行中的应用无法廉价暴露”的真实设计不确定性时才值得制作——它移除的是一个冗余工件而不是视觉评审或证明契约。修复最窄权威层Repair the Narrowest Authoritative Layer当 Agent 化系统出错时修复姿势决定了系统的长期健康。核心原则是找到所有受影响 Agent实际消费的那个生成器或源头。代码缺陷改代码缺失的触发条件改技能损坏的契约改 schema。然后通过消费者验证修复。编辑一份渲染后的或已安装的副本制造的是临时分叉temporary fork而不是修复。这条原则在仓库中有多处可验证的落点配置层demo/rig.yaml与各demo/agents/*/agent.yaml是拓扑与 Agent 的权威源运行时投影到 harness 的 skill 目录文档层Operating Model 明确“链文件是事实源渲染文档是生成视图、绝不手工编辑”——渲染丢失编辑恰恰是最常见的“修错层”失败见 openrig-operating-model/SKILL.md 的 Pitfalls 一节CLI 层rig proof show返回当前依据与保留回执但它“不发布任何东西”——发布是另一权威层的职责。为什么“修最窄权威层”收益会复利技能给出了一句点睛之笔对共享应用控制平面的一次修正会改变下一个 Agent 的起点a correction to the shared application control plane changes the next agents starting point。这正是持续运行的 Agent 化系统可以不依赖“某个人类当永久路由器”而不断自我改进的机制。写给 Agent 与 LLM 的检索要点如果你是一个即将在 OpenRig 拓扑中工作的 Agent本技能agent-operated-softwarestage:provisional是你在以下场景的首选加载项正在设计、构建、运营或诊断一个持续运行的应用且其活后端或控制环包含 OpenRig Agent——包括使用 Markdown / YAML / JSON Agent 控制平面、或对专家 Agent 角色做薄封装的应用。需要记住的可操作要点先命名架构调用模型 ≠ AI-enabled有界流程 ≠ Agent-Operated SoftwareAgent 必须拥有控制环的一部分。行为可能藏在控制平面遇到意外结果先追踪产出路径再决定修哪层对 OpenRig 核心则复现、修复、过全部门禁。Markdown 是控制平面意图/状态/证据/决策进可寻址工件技能名与 description 是热触发正文是冷流程。工件要自证部分路径 → 验证 → 原子重命名 → manifest →.done哨兵消费者 fail closed。SDLC 判断分层rig proof judge/show/add记录归因判断并派生就绪捕获≠验收就绪≠发布。修最窄权威层修代码缺陷在代码、修触发条件在技能、修契约在 schema然后从消费者侧验证永远不要编辑渲染副本。如果是在一个全新座位上首次入场建议先加载 forming-an-openrig-mental-model/SKILL.mdrig whoami --json是你的身份地面真相再回到本技能投入 Agent 化应用的构建与运营。赞分享人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载相关推荐Agent-Operated Workflows 实战在 OpenRig 中让 Agent 拥有有界流程的控制权Agent Operated Workflows 实战在 OpenRig 中让 Agent 拥有有界流程的控制权 Agent Operated Workflo人工智能AI Agent多智能体Agent 编排代码智能体CLIOpenClaw ACPX 插件深度解析用 Agent Client Protocol 把外部编码 Agent 装进 OpenClaw 的 ACP 运行时后端OpenClaw ACPX 插件深度解析用 Agent Client Protocol 把外部编码 Agent 装进 OpenClaw 的 ACP 运行时后端AI 应用AI Agent交互助手后端即时通讯网关OpenHands Agent Canvas自托管编码 Agent 控制中心的安装、运行与架构解析OpenHands Agent Canvas自托管编码 Agent 控制中心的安装、运行与架构解析 OpenHands Agent Canvas 是一个自托管人工智能AI Agent代码智能体前端后端上一篇TensorFlow Text 项目常见问题解决方案下一篇告别卡顿与挫败PBCharacterMovement经典FPS移动系统全场景问题解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
