模型循环（Model Loops）
模型循环（Model Loops） 显示在你的项目中启动的改进循环（RSI 循环）以及每个循环的进展。它位于 Console 侧栏的 RSI 循环 → 模型（RSI LOOPS → Model），RSI 循环分组位于 概览（Overview） 与 实验（Experiment） 之间。这些页面只读：打开它们不会启动、引导或停止循环，也不会分配训练资源。需要启动或引导循环时，请使用下文的 API 或 MCP。
RSI LOOPS 中的改进对象
导航子项简写为“模型（Model）”，页面标题仍为“模型循环（Model Loops）”。Model Loops 跟踪模型能力和训练方法的迭代：比较 baseline 与 candidate 版本，并检查固定评价协议下的证据。页面显示当前模型研究服务实际报告的版本、评分、关卡和审核；缺少评价不等于零分，训练成功也不等于模型提升。
后续导航子项可为 Infra（kernel、训练与推理系统效率）、Harness（Agent 提示、工具、记忆与编排）和 Data（数据方法与版本），子项不重复父分组的 Loops。这些分类尚未提供页面。分类按主要改进对象决定；生成数据的模型循环仍可属于 Model Loops。
规范页面地址为项目作用域下的 /rsi/model-loops，旧 /agent-runs 页面地址会跳转。下文 API/MCP 路径及 metadata 字段保持兼容。CLI 的 el job run list/get 汇总带标签的训练工作，与 Console 的模型循环服务投影不是同一个列表。
打开 Console 分组
- 选择循环所在的工作区和项目。
- 在侧栏打开 RSI 循环 → 模型。
- 查看每个运行的状态、当前轮次与目标轮次、最佳版本、花费和最近更新，最新的排在前面。用 刷新 获取最新视图；窄屏上可用 全部列 查看所有列。
- 打开运行名称查看详情。
满足以下任一条件，运行就会出现在列表中：你所在项目中有训练 Job 带有该运行的 rsi_run 标签；或该运行由你所在工作区和项目中的调用方启动。第二条规则让刚启动的运行（例如通过 MCP 启动）在首个训练 Job 出现之前就已列出。在记录归属之前启动的运行仅通过带标签的训练 Job 出现。
如果当前部署未连接循环服务，页面会如实说明；如果无法连接，页面会提示模型循环不可用并提供 重试。这两种情况都不表示没有运行、花费为零或循环已停止。
阅读一个运行
运行页面分为两部分。
- 循环进度 是实时视图：状态、当前轮次与目标轮次、阶段、正在使用的角色和工具、最近活动（最新在前）、已发送的引导消息及其送达状态、循环启动的作业，以及花费与上限。标签页可见时大约每 3 秒刷新一次，循环完成、失败或停止后不再刷新。
- 循环看板 是循环自己上报的结果：
- 概览： 上报的状态、当前与目标轮次、最佳版本、花费与上限、GPU 花费、机器，以及经典示例的各步骤（数据、检查点、基准、是否超过基座）及其说明。
- 各版本得分： 训练行数，以及评测集和切分上的均值、区间与样本数（如有提供）。
- 最终关卡： 某次上报的关卡中候选版本的得分及相对基线的变化。
- 近期审核： 审核类型、版本、通过或拒绝，以及首要原因。
- 近期轮次： 决策与摘要；详情 展开该轮的计划与干预。
- 所有者指示： 已提交给该运行的指导内容，以文本显示。
显示为 — 的值表示未提供。“最佳”标记、关卡或审核是循环上报的证据；在声称有改进之前，请检查其评测覆盖范围和协议。训练轮次、循环花费与训练估算的统计口径可能不同。
由 RSI 循环创建的训练 Job，其在 Experiment → Jobs 中的详情页同样有 循环进度 标签页，并带有指向对应模型循环页面的链接。
使用 CLI 查看带标签的训练运行
el job run list
el job run get RUN_NAME
el job run get RUN_NAME --json
RUN_NAME 使用列表返回的精确 Run 标签。这些命令按可见训练 Job 分组，展示轮次、各轮 Job 和已记录 checkpoint。默认输出表格，--json 保留完整响应。这类完整列表命令没有 --cursor 或 --limit 参数，也不会创建或停止循环。Loop 专用的分数、审查、指导和实时进度来自独立 RSI API。
同一个 CLI 分组还可以启动并跟踪循环，调用上述 RSI API（见启动循环）：
el job run start arith-carry-1 --brief "Improve multi-digit carries." --model-usd-cap 5 --dry-run
el job run live arith-carry-1 --follow
el job run steer arith-carry-1 "Prefer held-out families."
el job run stop arith-carry-1
start 的选项对应 rsi_start_run 的字段（--brief 或 --brief-file、--model-usd-cap、--usd-cap、--domain、--rounds、--dry-run、--student-model）。live 以 JSON 输出实时视图；加 --follow 则每个新事件输出一行 seq kind: text，直到运行结束；按 Ctrl-C 只退出跟踪，运行继续。stop 另需 training.stop。命令被拒绝时只显示固定说明和错误码，不显示服务端消息；该消息可通过 API 查看。
启动循环
循环只能通过 API 或 MCP 启动，不能在 Console 中启动。启动循环会产生费用：在你设定的上限内的模型花费，以及 live 运行在 EnvLoop 上的 GPU 训练。请确认需要时再启动。
你需要一个具有 training.run 权限的项目 API Key（Project automation 类型包含该权限和 training.stop），或已登录的 Developer / Admin 会话。只读 Key 和 Viewer 会收到 403 ACCESS_DENIED。
通过编码 Agent（MCP）
用 API Key 把 Claude Code 或 Codex 连接到 RSI MCP 端点，再让它启动并跟踪运行。
# Claude Code
claude mcp add --transport http envloop-rsi https://api.envloop.ai/v1/agent-runs/rsi/mcp \
--header "Authorization: Bearer $ENVLOOP_API_KEY"
# Codex：~/.codex/config.toml（Key 保留在环境变量中）
[mcp_servers.envloop-rsi]
url = "https://api.envloop.ai/v1/agent-runs/rsi/mcp"
bearer_token_env_var = "ENVLOOP_API_KEY"
任何支持 Streamable HTTP 和 Bearer 请求头的 MCP 客户端用法相同。服务无状态并返回 JSON，tools/list 会返回每个工具的精确输入 schema。工具如下：
| 工具 | 作用 | 需要 |
|---|---|---|
rsi_list_runs | 你所在项目的运行：状态、轮次、目标、最佳版本、花费、归属。 | 读取 |
rsi_run_status | 单个运行详情：摘要行、classic example 的步骤、带评分的版本、审核、轮次、花费。compact: true 只返回摘要字段（轮询开销小）。 | 读取 |
rsi_status | 运行此刻在做什么，同下文的实时视图。since 为上一次的 next_cursor。 | 读取 |
rsi_round | 单个轮次：决策、计划、干预、审核、摘要（round 为 1 或更大）。 | 读取 |
rsi_start_run | 启动新运行（见下）。 | training.run |
rsi_add_directive | 向运行的 owner directives 追加长期指令（1 到 4000 个字符）。 | training.run |
rsi_steer | 立即向运行中的 operator 发送消息（1 到 4000 个字符）。 | training.run |
rsi_control | extend（设置目标轮次）、stop（当前轮次结束后停止）或 resume。extend 与 resume 会开始付费工作。 | training.run；stop 需要 training.stop |
rsi_start_run 的参数：
| 字段 | 含义 |
|---|---|
run（必填） | 新的运行 ID：1 到 64 个小写字母、数字和连字符，例如 arith-carry-1。ID 已存在会返回冲突。 |
brief（必填） | 目标，最多 4000 个字符，会加入运行的每一轮。 |
limits.model_usd_cap（必填） | 强模型 API 的花费上限（美元），硬性停止。 |
limits.usd_cap | 模型加 GPU 训练合计的花费上限（美元）。设置它可约束 live 运行的总成本。 |
limits.model_request_cap | 模型请求数上限。 |
其他 limits 键 | 可选的正数调优键（计数须为整数）：request_cap、student_request_cap、diag_per_family、dev_n、collect_tasks、collect_k、admission_n、blind_n、max_rows_per_family、dev_use_cap、eval_limit、calib_n。没有单独的 GPU 上限：GPU 花费为 usd_cap 减去模型花费。未知的键会被拒绝。 |
domain | 任务类别，取 arith、code、spatial 或 finance；默认 arith。 |
rounds | 目标轮次，1 到 1000；默认 3。目标很高时实际上不设上限：由花费上限停止运行。 |
dry_run | true 启动不使用 GPU 的运行：不训练任何模型，student 由模型网关作答，因此只用于演练循环，不会提升模型；仍会消耗模型预算。 |
student_model | dry run 的网关 student；仅与 dry_run: true 同用。 |
finance 域让 student 选择一个选项 ID，并用评判器 finance-option-v2 打分。答案只有两种形式有效：仅含选项 ID，或推理文字且最后一个非空行恰好是一个标记 ANSWER: <ID>。含糊其辞、出现第二个选项、出现两个标记，或标记不在最后一行，都视为未选择任何选项，得 0 分。
启动会返回 state: "starting"、运行的 mode（live 或 dry）、归属以及会执行的上限。运行会立即出现在 Console 列表中。用 rsi_status 或 Console 页面跟踪，用 rsi_control 停止。
通过脚本（REST）
同样的操作也是 https://api.envloop.ai/v1/agent-runs/rsi 下的普通 HTTP 路由：
curl -X POST -H "Authorization: Bearer $ENVLOOP_API_KEY" -H "Content-Type: application/json" \
-d '{"run": "arith-carry-1", "brief": "Improve multi-digit carries.", "limits": {"model_usd_cap": 5}, "dry_run": true}' \
"https://api.envloop.ai/v1/agent-runs/rsi/runs"
curl -X POST -H "Authorization: Bearer $ENVLOOP_API_KEY" -H "Content-Type: application/json" \
-d '{"action": "stop"}' "https://api.envloop.ai/v1/agent-runs/rsi/runs/arith-carry-1/control"
POST /runs 返回 201，字段与 rsi_start_run 相同。POST /runs/RUN_NAME/control 接受 action（extend、stop 或 resume），extend 还需 rounds（1 到 1000）。请求被拒绝时返回 422 INVALID_RSI_REQUEST；运行 ID 已存在、运行状态不符或没有空闲机器时返回 409 RSI_CONFLICT，message 会说明具体字段或条件。项目没有运行时，GET /runs 返回空的 items，并附带 start 提示。
el CLI 封装了这些路由：el job run start、live、steer 和 stop（见CLI 一节）。
通过 API 或 MCP 引导运行中的循环
Console 只展示循环，不能发送引导内容，也不能暂停或停止循环；Console 对所有角色都是只读的。这些操作请使用 API 或 RSI MCP 端点。
使用能读取所属项目训练 Job 的 EnvLoop API Key，也可通过 API 获得实时数据：
curl -H "Authorization: Bearer $ENVLOOP_API_KEY" \
"https://api.envloop.ai/v1/agent-runs/rsi/runs/RUN_NAME/live"
curl -H "Authorization: Bearer $ENVLOOP_API_KEY" \
"https://api.envloop.ai/v1/agent-runs/rsi/runs/RUN_NAME/live?since=43"
响应包含 state、round、rounds_target、phase、current（角色、工具和开始时间）、events、next_cursor、steers、jobs、spend 和 updated_at。events 按从旧到新排序，每次最多 200 条，每条包含 seq、kind（message、tool_call、tool_result、steer、round、job 或 error）和简短摘要。把上一次返回的 next_cursor 作为 since 传入，即可只获取更新的事件；since 必须是非负整数。未知的 run，或你所在项目不可见的 run，会返回 404 RSI_RUN_NOT_FOUND。
满足以下任一条件即可见：你所在项目中有训练 Job 带有该 run 的 rsi_run 标签；或该 run 由你所在工作区和项目中的调用方启动（RSI 服务在 run 启动时记录这一归属）。第二条规则让刚启动的 run（例如通过 MCP 启动）在首个训练 Job 出现之前就可见。在记录归属之前启动的 run 仅能通过带标签的训练 Job 可见。同一规则适用于 run 列表、详情、轮次、实时进度、引导和 directive；引导和 directive 仍需下文所述权限。
要引导处于启动、运行或暂停状态的循环，发送 1 到 4000 个字符的文本。这需要已登录会话中的 Developer 或 Admin 角色，或带 training.run 权限的 API Key；只读 Key 和 Viewer 会收到 403 ACCESS_DENIED。
curl -X POST -H "Authorization: Bearer $ENVLOOP_API_KEY" -H "Content-Type: application/json" \
-d '{"text": "选择数据时优先考虑留出的题型。"}' \
"https://api.envloop.ai/v1/agent-runs/rsi/runs/RUN_NAME/steer"
请求返回 202，包含引导消息的 id、status（queued）和时间。循环会在下一个回合边界送达排队中的消息，因此该消息先以 queued 出现在 steers 中，随后变为 delivered，无法送达时为 dropped。作者取自你已认证的身份，而不是请求正文。运行未处于活动状态时返回 409 RSI_RUN_NOT_ACTIVE，文本为空或过长时返回 422 INVALID_STEER。
外部智能体也可以通过 RSI MCP 端点 https://api.envloop.ai/v1/agent-runs/rsi/mcp 使用同样的操作：rsi_status 工具（run 和可选的 since）与 rsi_steer 工具（run 和 text）。通过 MCP 引导遵循相同的权限规则。
Job 如何加入 Run
训练 Job 的 user_metadata 提供分组信息。同时存在通用 agent_* 和对应 rsi_* 字段时，优先使用通用字段。
Job 优先使用 session 的 user_metadata 分组；没有 session metadata 且只有一个训练模型时，使用该模型的 metadata。各模型自己的 metadata 仍可在 Job 的训练 run 详情查看。要从 trainer 找到准确 Job，可分页读取 client.jobs.list(type="train")，以 trainer.model_id 精确匹配 training.model_ids；run 标签用于分组，不是 Job ID。
{
"agent_run": "example-evaluation-loop",
"agent_round": "2",
"agent_purpose": "train candidate",
"agent_method": "sft",
"agent_checkpoint": "candidate-2",
"agent": "example-agent"
}
这是 metadata 示例，不是可单独提交的请求。请通过客户端支持的训练流程传入，见训练入门。agent_run / rsi_run 标识分组，agent_round / rsi_round 标识轮次，purpose、method、checkpoint 字段描述对应训练。仅有标签不能独立证明训练步骤、checkpoint 或评测已经成功。托管的 Qwen/Qwen3.8-27B Job 把这些键作为 labels 字段传入（见选项），并以 training.labels 和 training.user_metadata 返回；run 列表正是从中读取 rsi_run 与 rsi_round。
查看单个资源
单个训练 Job 使用 el job get JOB_ID 或 Console Jobs 页面查看。已保存的权重见 Checkpoints，推理服务见推理。Metadata 标签和训练成功状态不能证明评测改进，应检查实际记录的评测证据。