人工智能AI Agent深度研究自主智能体Agent 编排【免费下载链接】OpenResearchTurn your coding agents into research agents项目地址https://gitcode.com/GitHub_Trending/op/OpenResearch点击查看免费下载导读orx-compute是 OpenResearch 仓库中面向编码 Agent 变成研究 Agent场景的计算编排技能SKILL.md它定义了所有实验运行的通用启动契约无论目标机器是本机、Kubernetes、Slurm、Ray、Modal、Hugging Face Jobs、SSH 主机还是 OpenResearch 自营的临时 GPU 实例都统一通过orx exp run提交、orx exp wait/orx exp wake监控。读完本文你将掌握实验分支不可变快照的运行模型、九大后端的选型与参数、--flavor/--timeout等关键标志的语义、以及wait与wake两种等待策略的取舍并看到这些规则在 src/compute.rs 中的源码级落地。一、核心运行模型一切运行都基于不可变提交快照所有后端共享同一条铁律每个运行run都使用实验分支已记录提交recorded commit的不可变快照而不是当前工作区里的编辑内容。工作区worktree只用于编辑代码、操作 Git、编排和轻量检查真正的训练、评测等重活必须在快照环境中执行。快照的流向因后端而异远程后端hf、modal、k8s、ssh、slurm、ray、openresearchorx把已提交快照流式传输/暂存到目标机器Tinker 后端快照被解包给一个本地控制器local controller由控制器的 SDK 把模型运算发送到远端执行。对应地各后端文档都强调无需 push 到 GitHub例如 references/hf.md 明确指出orx 把已提交快照上传进私有作业卷作业永远不会 clone 仓库、也不需要仓库凭据。这意味着未提交的文件绝不会进入运行环境——先git commit再orx exp run。二、命令速览一条命令完成浏览 → 过滤 → 启动 → 取消命令作用orx exp status expId查看分支、父分支、run command、最近一次运行及提交orx compute跨所有 Provider 浏览 GPU 报价orx compute --gpu H100_SXM --count 1按 GPU 型号与数量过滤报价orx compute --cpu浏览纯 CPU 报价orx exp run expId在配置的默认后端上启动运行orx exp cancel expId取消进行中的运行其中orx compute的实现位于 src/commands/compute.rsGPU 目录通过GET /compute/catalog拉取返回结果已按价格升序排列命令再按--gpuGPU id大小写不敏感、--countGPU 数量、--provider三级过滤最终以GPU | COUNT | $/HR | DISK | VCPUS | RAM(GB) | REGION | PROVIDER表格打印。--cpu分支走list_cpu_catalog输出FLAVOR | VCPUS | $/HR | DISK | RAM(GB) | REGION | PROVIDER表格当前 CPU 报价仅来自 RunPod见文件头部注释。没有匹配时打印No matching compute offers.。三、通用启动契约Universal Launch Contract这是本技能最核心的规则集任何一次启动/重启前都必须遵守3.1 所有计算都用orx exp run启动严禁直接调用 Provider 的 CLI、调度器、裸 SSH 或训练命令本身。原因很直接绕过orx的直接作业是不被追踪的可能运行的是非记录提交上的代码破坏可复现性。3.2 保持 run command 固定在基线分支上设置一次 run command之后通过子分支child branches去变化代码或配置而不是每次改命令。若尚未设置用orx project edit projectId --run-command cmd先行设置再启动。从源码看提交时命令的解析顺序在 src/compute.rs 的submit()中优先取实验的run_command为空则回落到项目的run_command再为空则取空字符串。3.3 启动前必须提交每个后端都运行记录提交的不可变源码快照未提交文件被排除且不需要 GitHub push。3.4 启动是异步的orx exp run会入队并立即返回后续用orx runs、orx logs、orx exp wait或orx exp wake跟进。3.5 并发控制--force不加--force时若同一节点上已有运行在飞in flightorx会拒绝再次启动同一实验。只有刻意要并发跑同一实验时才加--force。四、后端路由先解析默认再读且只读一份指南会话剧本session playbook会写明配置的默认后端。裸orx exp run expId就使用它只有在用户点名某个后端时才切换——已连接凭据不是切换后端的理由例如连了 HF token 不代表就该用 hf。在构造启动命令前必须且只能阅读与目标后端对应的一份参考文档见 SKILL.md后端必读指南Hugging Face Jobshfreferences/hf.mdModalmodalreferences/modal.mdKubernetesk8sreferences/k8s.mdSSHsshreferences/ssh.mdSlurmslurmreferences/slurm.mdRay Jobsrayreferences/ray.mdOpenResearchopenresearchreferences/openresearch.mdTinkertinkerreferences/tinker.md本机localreferences/local.md注意两条边界不要读没用到的后端指南Kubernetes manifest 相关操作必须先读references/k8s.md。若本地参考文档不可读orx skill compute/backend会打印同一份规范文档。在源码层面后端的注册与参数校验都集中在 src/compute.rsbackend(id)把九个字符串 id 映射到对应后端实现L629-L642validate_run_args则强制了标志与后端的配对关系L652-L694例如--manifest只能配--backend k8s--host只能配--backend ssh或slurm--org、--disk、--provider只能配--backend openresearch--backend tinker不接受--flavor、--image、--timeout。违反上述任一约束会直接返回错误如--host only applies with --backend ssh or slurm.。每个后端提交前还会先跑preflight就绪检查未就绪则拒绝提交——例如 OpenResearch 后端要求必须有--flavor且已执行orx loginsrc/compute.rs。4.1 Hugging Face Jobs--backend hf仅在用户明确要求或为默认后端时使用token 已连接只代表可用不代表自动选中。作业运行在用户 HF 账号下并据此计费鉴权用环境变量HF_TOKEN。orx exp run expId --backend hf --flavor a10g-small orx exp run expId --backend hf --flavor a100-large --timeout 8h orx exp run expId --backend hf --flavor cpu-upgrade --image python:3.12--flavor必填除非配置的默认值已包含。常见 GPU flavort4-small、a10g-small、a10g-large、l4x1、l40sx1、a100-large、h100、h200以及x2/x4/x8多卡变体CPU 选项为cpu-basic与cpu-upgrade。超时默认4 小时覆盖整个作业超时会被记录为失败运行。--image覆盖容器镜像GPU 形状默认 CUDA PyTorch 镜像CPU 形状默认python:3.12。4.2 Modal--backend modalModal 在用户账号下运行临时 Sandbox按秒计费。鉴权使用MODAL_TOKEN_ID/MODAL_TOKEN_SECRET或modal token new生成的凭据orx在首次启动时预置其托管的 Modal 环境。orx exp run expId --backend modal --flavor a10g orx exp run expId --backend modal --flavor a100-80gb --timeout 8h orx exp run expId --backend modal --flavor h100:2 orx exp run expId --backend modal --flavor cpu --image python:3.12--flavor必填除非默认值包含。GPU 值t4、l4、a10g、a100、a100-80gb、l40s、h100、h200追加:N表示多卡CPU 值为cpu、cpu-large。超时默认 4 小时覆盖整个 Sandbox。4.3 Kubernetes--backend k8s鉴权来自用户的 kubeconfigcontext 与 namespace 来自其 Kubernetes profile。没有 flavor 概念——运行形态由提交在实验分支上的 Kubernetes manifest 决定默认路径为.orx/k8s.yaml可用--manifest path覆盖。orx exp run expId --backend k8s orx exp run expId --backend k8s --manifest infra/run.yaml --timeout 8h最小 manifest 示例apiVersion: batch/v1 kind: Job metadata: name: train-{{ORX_RUN}} spec: template: spec: restartPolicy: Never containers: - name: run image: pytorch/pytorch:2.6.0-cuda12.4-cudnn9-runtime command: [bash, -c, $ORX_SCRIPT] resources: requests: { nvidia.com/gpu: 4, cpu: 32, memory: 128Gi } limits: { nvidia.com/gpu: 4 }提交时契约submit-time contract要点只允许一个 Job代表主结果有多个 Job 时需给主 Job 打标签orx-primary: true。Parallel / Indexed Job 会被拒绝因为不可变归档只会暂存进一个 pod。主 Job 中必须有一个容器执行$ORX_SCRIPT通常写法即command: [bash, -c, $ORX_SCRIPT]。所有资源必须有metadata.name禁用generateName、不得设置外来 namespace名字里带上{{ORX_RUN}}防止重跑冲突。orx会向主容器注入运行标签与orx-envSecret缺失时会补默认的activeDeadlineSeconds、ttlSecondsAfterFinished与backoffLimit: 0。可携带辅助资源取消时一并删除辅助资源需要时须自行引用orx-envSecret。运行日志跟随主 Job 的唯一 pod。4.4 SSH--backend ssh在用户自己的机器/服务器上跑分离进程环境取自该主机。orx exp run expId --backend ssh --host my-gpu-box--host每次启动都必须给且必须是~/.ssh/config里的别名没有 flavor。鉴权用用户 SSH 密钥或 agentorx调用 SSH 但从不读取私钥。主机需具备bash与tar。快照流式传输到主机解包后才启动固定 run command。无 image、无 timeout 标志直接用主机环境远端运行目录为~/.orx/runs/runId/取消会终止远端进程组。4.5 Slurm--backend slurmorx经 SSH 登录 login node暂存已提交快照再用sbatch提交固定命令。orx exp run expId --backend slurm --host login-node --flavor h100:2 --timeout 4h orx exp run expId --backend slurm--host是~/.ssh/config别名仅当配置了 Slurm 默认主机时可省略。--flavor为可选的 GRES GPU 请求如h100:2CPU 作业省略即可。无 image 标志集群环境modules、conda、login profile原样使用超时默认 4 小时覆盖批处理作业。4.6 Ray Jobs--backend ray通过 Ray Jobs/Dashboard API 提交使用集群的 runtime environment。orx exp run expId --backend ray orx exp run expId --backend ray --flavor gpu:1 orx exp run expId --backend ray --flavor cpu:2,mem:8GiB地址解析顺序已保存的 Ray 配置 →ASTROAI_RAY_JOBS_ADDRESS或RAY_DASHBOARD_URL→ 兜底http://127.0.0.1:8265。可选--flavor提示使用cpu[:N]、gpu[:N]、mem:size逗号连接内存只是调度预留不是强制上限。省略 flavor 表示不预留任何资源可避免小 head 节点上出现 Pending。无 image/host/timeout 标志请在 run command 内部约束时长Ray 接收的快照作为其working_dir包。4.7 OpenResearch--backend openresearch仅在用户明确要求 OpenResearch 机器或其为默认后端时使用。它预置一台按用户组织计费的临时机器运行结束即删除需要orx login与已注册的 SSH 密钥。orx exp run expId --backend openresearch --flavor h100_sxm:2 --timeout 4h orx exp run expId --backend openresearch --flavor cpu5c:32 --org orgId--flavor是orx compute输出的 GPU id可带数量或 CPU 家族如cpu5c、cpu5g、cpu5m可带:vcpus。可选标志--org、--disk、--provider源码校验确认这三个仅限本后端使用。没有 image 标志——平台镜像固定。超时默认4 小时运行结束时机器与存储一起消失因此所有证据必须落到运行日志里。4.8 Tinker--backend tinker实验控制器作为orx所在机器上的受监督进程运行Tinker SDK 的模型运算远程执行。orx exp run expId --backend tinker环境要求进程环境或~/.openresearch/env中配置非空TINKER_API_KEY禁止打印或提交Python ≥ 3.11用实验已有的包管理器添加并锁定tinker或tinker-cookbookorx 不装 SDK、不建托管 Python 环境。选模型前先查询 Tinker 服务器能力不要硬编码模型可用性。读取ORX_RUN_ID并作为ServiceClient用户元数据附加让运行在 Tinker 侧可识别。日志与恢复把训练模型 id、指标与每个tinker://checkpoint 路径打印进 orx logs周期性创建可恢复的save_statecheckpoint需要推理时另建 sampler checkpoint以最近一次周期 checkpoint 作为恢复边界不要承诺取消时的最终 checkpoint。取消语义orx exp cancel停止本地控制器因此不再发出新的 Tinker 请求已受理的请求可能继续跑完不要宣称 Provider 侧已终止。无 flavor/host/image/manifest/超时选项控制器活跃期间运行orx的机器必须保持唤醒与联网。4.9 本机--backend local仅在用户要求在本机运行或为默认后端时使用以分离进程使用本机环境与本机其他任务共享 CPU、RAM、GPU。orx exp run expId --backend local无 flavor/host/image/timeout 标志。适合小规模或 CPU 级工作重型作业默认走远程除非用户另有要求。已提交快照被解包进隔离的运行目录再执行固定命令——绝不直接从 worktree 训练。运行目录位于orx data dir/local-runs/runId/取消会终止整个进程组。五、等待与唤醒orx exp wait与orx exp wake5.1 阻塞等待orx exp wait需要在运行一结束就立刻行动时用它阻塞到运行状态变化orx exp wait expId # 等待该实验最近一次运行 orx exp wait --project projectId # 首个项目完成即返回 orx exp wait expId --interval 10 --timeout 3600expId与--project二选一只能传一个。--project是预算循环原语只在首个完成时返回而非开始、也非排队→运行等转换每个循环 tick 重新发起一次。wait 只是睡到变化的信号不是事实来源每次返回后都要读orx runs projectId对账所有新进入终态的运行。无运行在飞时project wait 返回drained: no runs in flight。默认--interval为5 秒、--timeout为1800 秒超时以非零退出含义是尚无变化不代表运行失败。5.2 失败与对账失败运行带有reason:行。Provider 容量类失败通常可重试启动之后的失败则需要读orx logs runId。失败不是新节点按orx-experiment-tree描述的流程修复后重跑同一个实验。5.3 挂起退出orx exp wake想结束当前回合、等该运行成功/失败后再续时用orx exp wake expId。唤醒是opt-in只在done或failed时触发且排在已排队用户消息之后。wait 与 wake 对同一运行二选一不要都用。六、计算规模选择Sizing先定 GPU 还是 CPUAPI 驱动的评测与数据准备往往在 CPU 上更省钱。选能装下模型和最小 batch 的最小规格。出现真实的 OOM 或慢到无望时才升级而不是一上来就最大加速卡。只为真正长的运行提高超时。源码层面OpenResearch 后端的 preflight 会强制--flavor必填与orx login前置src/compute.rs而orx compute的价格升序目录让你在选型前就能横向对比 GPU/CPU 的$/HR与VCPUS/RAM(GB)src/commands/compute.rs。七、源码级验证运行提交、描述符与参数护栏把技能规则映射到实现能看到三层保障不可变快照submit()从 store 取出实验与项目执行后端preflight就绪检查后调用stage_source暂存源码再生成run_id与BackendDescriptorsrc/compute.rs。描述符kind形如{backend_id}_job定义在 src/jobs/mod.rs 的BackendDescriptor中运行日志与后端识别都依赖它。参数护栏validate_run_argssrc/compute.rs在提交前拦截所有标志与后端不匹配的组合并把后端白名单限定为九种含中文报错文案hf (Hugging Face Jobs)、modal、k8s、ssh、slurm、ray、openresearch、tinker、local。统一入口九种后端全部从backend(id)工厂解析src/compute.rs与技能只经orx exp run启动的契约一一对应。八、结语orx-compute把选择计算 → 启动 → 监控 → 对账收敛为一套可复制的固定流程先orx compute摸底报价确认默认后端或用户点名后只读一份对应指南遵守run command 固定 提交后启动 用wait/wake跟进的通用契约最后按先 CPU 后 GPU、先小后大的规模策略控制成本。所有规则都能在 src/compute.rs 与 src/commands/compute.rs 中找到实现依据九个后端的完整参数细节则沉淀在 agent-skills/orx-compute/references/ 目录下随时可通过orx skill compute/backend重新获取。赞分享人工智能AI Agent深度研究自主智能体Agent 编排【免费下载链接】OpenResearchTurn your coding agents into research agents项目地址https://gitcode.com/GitHub_Trending/op/OpenResearch点击查看免费下载相关推荐OpenResearch 后端实战用 orx exp run --backend openresearch 按次计费拉起临时 GPU/CPU 沙箱OpenResearch 后端实战用 orx exp run backend openresearch 按次计费拉起临时 GPU/CPU 沙箱 本指南讲解 O人工智能AI Agent深度研究自主智能体Agent 编排OpenResearch 的 Slurm 后端用 orx exp run --backend slurm 把实验批量提交到 HPC 集群OpenResearch 的 Slurm 后端用 orx exp run backend slurm 把实验批量提交到 HPC 集群 导读 本指南讲解 Ope人工智能AI Agent深度研究自主智能体Agent 编排OpenResearch 接入 Modal 无服务器 GPU用 orx exp run --backend modal 按秒计费跑实验OpenResearch 接入 Modal 无服务器 GPU用 orx exp run backend modal 按秒计费跑实验 OpenResearch人工智能AI Agent深度研究自主智能体Agent 编排创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
人工智能AI Agent深度研究自主智能体Agent 编排【免费下载链接】OpenResearchTurn your coding agents into research agents项目地址https://gitcode.com/GitHub_Trending/op/OpenResearch点击查看免费下载导读orx-compute是 OpenResearch 仓库中面向编码 Agent 变成研究 Agent场景的计算编排技能SKILL.md它定义了所有实验运行的通用启动契约无论目标机器是本机、Kubernetes、Slurm、Ray、Modal、Hugging Face Jobs、SSH 主机还是 OpenResearch 自营的临时 GPU 实例都统一通过orx exp run提交、orx exp wait/orx exp wake监控。读完本文你将掌握实验分支不可变快照的运行模型、九大后端的选型与参数、--flavor/--timeout等关键标志的语义、以及wait与wake两种等待策略的取舍并看到这些规则在 src/compute.rs 中的源码级落地。一、核心运行模型一切运行都基于不可变提交快照所有后端共享同一条铁律每个运行run都使用实验分支已记录提交recorded commit的不可变快照而不是当前工作区里的编辑内容。工作区worktree只用于编辑代码、操作 Git、编排和轻量检查真正的训练、评测等重活必须在快照环境中执行。快照的流向因后端而异远程后端hf、modal、k8s、ssh、slurm、ray、openresearchorx把已提交快照流式传输/暂存到目标机器Tinker 后端快照被解包给一个本地控制器local controller由控制器的 SDK 把模型运算发送到远端执行。对应地各后端文档都强调无需 push 到 GitHub例如 references/hf.md 明确指出orx 把已提交快照上传进私有作业卷作业永远不会 clone 仓库、也不需要仓库凭据。这意味着未提交的文件绝不会进入运行环境——先git commit再orx exp run。二、命令速览一条命令完成浏览 → 过滤 → 启动 → 取消命令作用orx exp status expId查看分支、父分支、run command、最近一次运行及提交orx compute跨所有 Provider 浏览 GPU 报价orx compute --gpu H100_SXM --count 1按 GPU 型号与数量过滤报价orx compute --cpu浏览纯 CPU 报价orx exp run expId在配置的默认后端上启动运行orx exp cancel expId取消进行中的运行其中orx compute的实现位于 src/commands/compute.rsGPU 目录通过GET /compute/catalog拉取返回结果已按价格升序排列命令再按--gpuGPU id大小写不敏感、--countGPU 数量、--provider三级过滤最终以GPU | COUNT | $/HR | DISK | VCPUS | RAM(GB) | REGION | PROVIDER表格打印。--cpu分支走list_cpu_catalog输出FLAVOR | VCPUS | $/HR | DISK | RAM(GB) | REGION | PROVIDER表格当前 CPU 报价仅来自 RunPod见文件头部注释。没有匹配时打印No matching compute offers.。三、通用启动契约Universal Launch Contract这是本技能最核心的规则集任何一次启动/重启前都必须遵守3.1 所有计算都用orx exp run启动严禁直接调用 Provider 的 CLI、调度器、裸 SSH 或训练命令本身。原因很直接绕过orx的直接作业是不被追踪的可能运行的是非记录提交上的代码破坏可复现性。3.2 保持 run command 固定在基线分支上设置一次 run command之后通过子分支child branches去变化代码或配置而不是每次改命令。若尚未设置用orx project edit projectId --run-command cmd先行设置再启动。从源码看提交时命令的解析顺序在 src/compute.rs 的submit()中优先取实验的run_command为空则回落到项目的run_command再为空则取空字符串。3.3 启动前必须提交每个后端都运行记录提交的不可变源码快照未提交文件被排除且不需要 GitHub push。3.4 启动是异步的orx exp run会入队并立即返回后续用orx runs、orx logs、orx exp wait或orx exp wake跟进。3.5 并发控制--force不加--force时若同一节点上已有运行在飞in flightorx会拒绝再次启动同一实验。只有刻意要并发跑同一实验时才加--force。四、后端路由先解析默认再读且只读一份指南会话剧本session playbook会写明配置的默认后端。裸orx exp run expId就使用它只有在用户点名某个后端时才切换——已连接凭据不是切换后端的理由例如连了 HF token 不代表就该用 hf。在构造启动命令前必须且只能阅读与目标后端对应的一份参考文档见 SKILL.md后端必读指南Hugging Face Jobshfreferences/hf.mdModalmodalreferences/modal.mdKubernetesk8sreferences/k8s.mdSSHsshreferences/ssh.mdSlurmslurmreferences/slurm.mdRay Jobsrayreferences/ray.mdOpenResearchopenresearchreferences/openresearch.mdTinkertinkerreferences/tinker.md本机localreferences/local.md注意两条边界不要读没用到的后端指南Kubernetes manifest 相关操作必须先读references/k8s.md。若本地参考文档不可读orx skill compute/backend会打印同一份规范文档。在源码层面后端的注册与参数校验都集中在 src/compute.rsbackend(id)把九个字符串 id 映射到对应后端实现L629-L642validate_run_args则强制了标志与后端的配对关系L652-L694例如--manifest只能配--backend k8s--host只能配--backend ssh或slurm--org、--disk、--provider只能配--backend openresearch--backend tinker不接受--flavor、--image、--timeout。违反上述任一约束会直接返回错误如--host only applies with --backend ssh or slurm.。每个后端提交前还会先跑preflight就绪检查未就绪则拒绝提交——例如 OpenResearch 后端要求必须有--flavor且已执行orx loginsrc/compute.rs。4.1 Hugging Face Jobs--backend hf仅在用户明确要求或为默认后端时使用token 已连接只代表可用不代表自动选中。作业运行在用户 HF 账号下并据此计费鉴权用环境变量HF_TOKEN。orx exp run expId --backend hf --flavor a10g-small orx exp run expId --backend hf --flavor a100-large --timeout 8h orx exp run expId --backend hf --flavor cpu-upgrade --image python:3.12--flavor必填除非配置的默认值已包含。常见 GPU flavort4-small、a10g-small、a10g-large、l4x1、l40sx1、a100-large、h100、h200以及x2/x4/x8多卡变体CPU 选项为cpu-basic与cpu-upgrade。超时默认4 小时覆盖整个作业超时会被记录为失败运行。--image覆盖容器镜像GPU 形状默认 CUDA PyTorch 镜像CPU 形状默认python:3.12。4.2 Modal--backend modalModal 在用户账号下运行临时 Sandbox按秒计费。鉴权使用MODAL_TOKEN_ID/MODAL_TOKEN_SECRET或modal token new生成的凭据orx在首次启动时预置其托管的 Modal 环境。orx exp run expId --backend modal --flavor a10g orx exp run expId --backend modal --flavor a100-80gb --timeout 8h orx exp run expId --backend modal --flavor h100:2 orx exp run expId --backend modal --flavor cpu --image python:3.12--flavor必填除非默认值包含。GPU 值t4、l4、a10g、a100、a100-80gb、l40s、h100、h200追加:N表示多卡CPU 值为cpu、cpu-large。超时默认 4 小时覆盖整个 Sandbox。4.3 Kubernetes--backend k8s鉴权来自用户的 kubeconfigcontext 与 namespace 来自其 Kubernetes profile。没有 flavor 概念——运行形态由提交在实验分支上的 Kubernetes manifest 决定默认路径为.orx/k8s.yaml可用--manifest path覆盖。orx exp run expId --backend k8s orx exp run expId --backend k8s --manifest infra/run.yaml --timeout 8h最小 manifest 示例apiVersion: batch/v1 kind: Job metadata: name: train-{{ORX_RUN}} spec: template: spec: restartPolicy: Never containers: - name: run image: pytorch/pytorch:2.6.0-cuda12.4-cudnn9-runtime command: [bash, -c, $ORX_SCRIPT] resources: requests: { nvidia.com/gpu: 4, cpu: 32, memory: 128Gi } limits: { nvidia.com/gpu: 4 }提交时契约submit-time contract要点只允许一个 Job代表主结果有多个 Job 时需给主 Job 打标签orx-primary: true。Parallel / Indexed Job 会被拒绝因为不可变归档只会暂存进一个 pod。主 Job 中必须有一个容器执行$ORX_SCRIPT通常写法即command: [bash, -c, $ORX_SCRIPT]。所有资源必须有metadata.name禁用generateName、不得设置外来 namespace名字里带上{{ORX_RUN}}防止重跑冲突。orx会向主容器注入运行标签与orx-envSecret缺失时会补默认的activeDeadlineSeconds、ttlSecondsAfterFinished与backoffLimit: 0。可携带辅助资源取消时一并删除辅助资源需要时须自行引用orx-envSecret。运行日志跟随主 Job 的唯一 pod。4.4 SSH--backend ssh在用户自己的机器/服务器上跑分离进程环境取自该主机。orx exp run expId --backend ssh --host my-gpu-box--host每次启动都必须给且必须是~/.ssh/config里的别名没有 flavor。鉴权用用户 SSH 密钥或 agentorx调用 SSH 但从不读取私钥。主机需具备bash与tar。快照流式传输到主机解包后才启动固定 run command。无 image、无 timeout 标志直接用主机环境远端运行目录为~/.orx/runs/runId/取消会终止远端进程组。4.5 Slurm--backend slurmorx经 SSH 登录 login node暂存已提交快照再用sbatch提交固定命令。orx exp run expId --backend slurm --host login-node --flavor h100:2 --timeout 4h orx exp run expId --backend slurm--host是~/.ssh/config别名仅当配置了 Slurm 默认主机时可省略。--flavor为可选的 GRES GPU 请求如h100:2CPU 作业省略即可。无 image 标志集群环境modules、conda、login profile原样使用超时默认 4 小时覆盖批处理作业。4.6 Ray Jobs--backend ray通过 Ray Jobs/Dashboard API 提交使用集群的 runtime environment。orx exp run expId --backend ray orx exp run expId --backend ray --flavor gpu:1 orx exp run expId --backend ray --flavor cpu:2,mem:8GiB地址解析顺序已保存的 Ray 配置 →ASTROAI_RAY_JOBS_ADDRESS或RAY_DASHBOARD_URL→ 兜底http://127.0.0.1:8265。可选--flavor提示使用cpu[:N]、gpu[:N]、mem:size逗号连接内存只是调度预留不是强制上限。省略 flavor 表示不预留任何资源可避免小 head 节点上出现 Pending。无 image/host/timeout 标志请在 run command 内部约束时长Ray 接收的快照作为其working_dir包。4.7 OpenResearch--backend openresearch仅在用户明确要求 OpenResearch 机器或其为默认后端时使用。它预置一台按用户组织计费的临时机器运行结束即删除需要orx login与已注册的 SSH 密钥。orx exp run expId --backend openresearch --flavor h100_sxm:2 --timeout 4h orx exp run expId --backend openresearch --flavor cpu5c:32 --org orgId--flavor是orx compute输出的 GPU id可带数量或 CPU 家族如cpu5c、cpu5g、cpu5m可带:vcpus。可选标志--org、--disk、--provider源码校验确认这三个仅限本后端使用。没有 image 标志——平台镜像固定。超时默认4 小时运行结束时机器与存储一起消失因此所有证据必须落到运行日志里。4.8 Tinker--backend tinker实验控制器作为orx所在机器上的受监督进程运行Tinker SDK 的模型运算远程执行。orx exp run expId --backend tinker环境要求进程环境或~/.openresearch/env中配置非空TINKER_API_KEY禁止打印或提交Python ≥ 3.11用实验已有的包管理器添加并锁定tinker或tinker-cookbookorx 不装 SDK、不建托管 Python 环境。选模型前先查询 Tinker 服务器能力不要硬编码模型可用性。读取ORX_RUN_ID并作为ServiceClient用户元数据附加让运行在 Tinker 侧可识别。日志与恢复把训练模型 id、指标与每个tinker://checkpoint 路径打印进 orx logs周期性创建可恢复的save_statecheckpoint需要推理时另建 sampler checkpoint以最近一次周期 checkpoint 作为恢复边界不要承诺取消时的最终 checkpoint。取消语义orx exp cancel停止本地控制器因此不再发出新的 Tinker 请求已受理的请求可能继续跑完不要宣称 Provider 侧已终止。无 flavor/host/image/manifest/超时选项控制器活跃期间运行orx的机器必须保持唤醒与联网。4.9 本机--backend local仅在用户要求在本机运行或为默认后端时使用以分离进程使用本机环境与本机其他任务共享 CPU、RAM、GPU。orx exp run expId --backend local无 flavor/host/image/timeout 标志。适合小规模或 CPU 级工作重型作业默认走远程除非用户另有要求。已提交快照被解包进隔离的运行目录再执行固定命令——绝不直接从 worktree 训练。运行目录位于orx data dir/local-runs/runId/取消会终止整个进程组。五、等待与唤醒orx exp wait与orx exp wake5.1 阻塞等待orx exp wait需要在运行一结束就立刻行动时用它阻塞到运行状态变化orx exp wait expId # 等待该实验最近一次运行 orx exp wait --project projectId # 首个项目完成即返回 orx exp wait expId --interval 10 --timeout 3600expId与--project二选一只能传一个。--project是预算循环原语只在首个完成时返回而非开始、也非排队→运行等转换每个循环 tick 重新发起一次。wait 只是睡到变化的信号不是事实来源每次返回后都要读orx runs projectId对账所有新进入终态的运行。无运行在飞时project wait 返回drained: no runs in flight。默认--interval为5 秒、--timeout为1800 秒超时以非零退出含义是尚无变化不代表运行失败。5.2 失败与对账失败运行带有reason:行。Provider 容量类失败通常可重试启动之后的失败则需要读orx logs runId。失败不是新节点按orx-experiment-tree描述的流程修复后重跑同一个实验。5.3 挂起退出orx exp wake想结束当前回合、等该运行成功/失败后再续时用orx exp wake expId。唤醒是opt-in只在done或failed时触发且排在已排队用户消息之后。wait 与 wake 对同一运行二选一不要都用。六、计算规模选择Sizing先定 GPU 还是 CPUAPI 驱动的评测与数据准备往往在 CPU 上更省钱。选能装下模型和最小 batch 的最小规格。出现真实的 OOM 或慢到无望时才升级而不是一上来就最大加速卡。只为真正长的运行提高超时。源码层面OpenResearch 后端的 preflight 会强制--flavor必填与orx login前置src/compute.rs而orx compute的价格升序目录让你在选型前就能横向对比 GPU/CPU 的$/HR与VCPUS/RAM(GB)src/commands/compute.rs。七、源码级验证运行提交、描述符与参数护栏把技能规则映射到实现能看到三层保障不可变快照submit()从 store 取出实验与项目执行后端preflight就绪检查后调用stage_source暂存源码再生成run_id与BackendDescriptorsrc/compute.rs。描述符kind形如{backend_id}_job定义在 src/jobs/mod.rs 的BackendDescriptor中运行日志与后端识别都依赖它。参数护栏validate_run_argssrc/compute.rs在提交前拦截所有标志与后端不匹配的组合并把后端白名单限定为九种含中文报错文案hf (Hugging Face Jobs)、modal、k8s、ssh、slurm、ray、openresearch、tinker、local。统一入口九种后端全部从backend(id)工厂解析src/compute.rs与技能只经orx exp run启动的契约一一对应。八、结语orx-compute把选择计算 → 启动 → 监控 → 对账收敛为一套可复制的固定流程先orx compute摸底报价确认默认后端或用户点名后只读一份对应指南遵守run command 固定 提交后启动 用wait/wake跟进的通用契约最后按先 CPU 后 GPU、先小后大的规模策略控制成本。所有规则都能在 src/compute.rs 与 src/commands/compute.rs 中找到实现依据九个后端的完整参数细节则沉淀在 agent-skills/orx-compute/references/ 目录下随时可通过orx skill compute/backend重新获取。赞分享人工智能AI Agent深度研究自主智能体Agent 编排【免费下载链接】OpenResearchTurn your coding agents into research agents项目地址https://gitcode.com/GitHub_Trending/op/OpenResearch点击查看免费下载相关推荐OpenResearch 后端实战用 orx exp run --backend openresearch 按次计费拉起临时 GPU/CPU 沙箱OpenResearch 后端实战用 orx exp run backend openresearch 按次计费拉起临时 GPU/CPU 沙箱 本指南讲解 O人工智能AI Agent深度研究自主智能体Agent 编排OpenResearch 的 Slurm 后端用 orx exp run --backend slurm 把实验批量提交到 HPC 集群OpenResearch 的 Slurm 后端用 orx exp run backend slurm 把实验批量提交到 HPC 集群 导读 本指南讲解 Ope人工智能AI Agent深度研究自主智能体Agent 编排OpenResearch 接入 Modal 无服务器 GPU用 orx exp run --backend modal 按秒计费跑实验OpenResearch 接入 Modal 无服务器 GPU用 orx exp run backend modal 按秒计费跑实验 OpenResearch人工智能AI Agent深度研究自主智能体Agent 编排创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
