mcpField
S
spawn-ori-eval

spawn-ori-eval

github.com/openrouterteam测试与质量309150 次安装1 天前更新
代码仓库

关于 spawn-ori-eval

spawn-ori-eval 是指导通过 Ori 对编码 Agent 进行评测的技能,适用于需要按固定模型和流程比较 Agent 的场景。它规范运行目录、任务提示词、交互提问和结果报告,并要求由 Ori 创建和评分评测。

主要功能

  1. 01使用固定运行与评审模型
  2. 02管理评测目录和步骤记录
  3. 03通过 Ori 创建并运行评测
  4. 04处理评测中的用户问题
  5. 05汇报结果、耗时与费用

适用场景

  1. 01按统一设置比较编码 Agent
  2. 02在评测过程中处理用户决策
  3. 03汇总评测分数和失败项

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/openrouterteam/skills --skill spawn-ori-eval

安装后在 Claude Code 中输入/spawn-ori-eval确认已加载。

附带文件README.md

详细介绍

运行 Ori 评测

Ori 会在固定的测试框架和模型上编写并评判评测,确保每个编码 Agent 使用的基准测试完全相同。你负责运行 Ori、让用户随时了解进展,并转达结果。自行编写的评测无法复现,而分数变化必须来自用户的 Agent,而非环境。

固定配置

本节给出两个模型。其他各节会使用名称 <RUN_MODEL> 和 <JUDGE_MODEL>。将每个名称替换为本节给出的模型。若要更改模型,只需更改接下来的两行。

  • RUN_MODEL 是 openai/gpt-5.6-terra。运行使用此模型。
  • JUDGE_MODEL 是 openai/gpt-5.6-terra。评测裁判使用此模型。

步骤

按顺序执行。每行一个操作。附录字母指向详细说明,并按步骤顺序执行,但故障排除表是查询资料,最后查看。

  1. 创建运行目录,并从仓库根目录推导其路径(附录 A)。
  2. 告诉用户运行目录的位置。
  3. 不做任何更改,读取目录中已有的内容,并告诉用户里面有什么以及这些内容有多旧(附录 A)。
  4. 询问用户要如何处理这些内容,然后复用现有的 steps.txt,跳到第 4 步之后第一个尚未完成的步骤;或者归档这些文件,并编写一份涵盖第 5 步及之后步骤的新 steps.txt;或者停止并保持所有内容原样不动。只有当目录中没有它自己的运行文件时,才无需询问,直接编写新的跟踪文件(附录 A)。
  5. 自行查找或安装 ori 二进制文件(附录 B)。
  6. 如果仍然找不到,自行运行 ~/.local/bin/ori 备用方案;如果也失败,则停止。
  7. 自行运行 ori auth,读取其输出,并根据退出状态和消息选择后续操作:当权限问题解决时继续;当没有凭据能解决问题时,停止并提供登录说明;当命令未知,且原因是已安装的 Ori 版本早于此技能所需的无头运行支持时,停止并说明需要使用 0.3.0 或更新版本(附录 B)。
  8. 自行检查是否安装了 bun;如果没有,则停止。
  9. 自行读取评估内容,即使命令报错也继续(附录 B)。
  10. 如果安装了二进制文件,告诉用户它所在的位置。
  11. 根据第 9 步读取的内容,告诉用户本次运行会做什么。
  12. 告诉用户这需要 10 到 30 分钟,而且可能会花费超过其密钥额度的费用。
  13. 告诉用户他们会得到一个带评分的表格,并且可以通过提问重新启动运行。
  14. 编写任务提示词文件(附录 C)。
  15. 从仓库根目录启动一次运行,并捕获其答案文件和错误文件(附录 D)。
  16. 等待运行退出,然后读取答案文件(附录 E)。
  17. 用通俗易懂的语言向用户展示答案文件中 Ori 的叙述内容。
  18. 如果已完成的答案中任何位置包含带标签的问题,或者摘要行上方的助手文本以未加标签的问题结尾,则继续执行第 19 步;只转达第一个问题,如果还出现其他问题,则报告违反了单问题约定;如果出现未加标签的问题,则报告违规,但仍转达该问题(附录 E)。
  19. 在普通消息中打印 Ori 对第一个问题提供的完整上下文,包括任何表格。本步骤不要做其他事情(附录 E)。
  20. 在上下文消息和问题之间,在此处更新 steps.txt,记录实际打印的内容:如果答案中带有表格,则引用打印出来的表头行;如果不带表格,则记录其不含表格(附录 E)。
  21. 使用你自己的问题 UI 询问用户,保留三个简短选项和自由文本选项 Other。问题必须是一句简短的话,不要复述或总结上下文表格(附录 E)。
  22. 将问题和用户自己的回复追加到任务提示词文件;或者,如果回复没有回答问题,则不追加任何内容,通过问题 UI 再次询问同一个问题,并在收到下一条回复后重新执行本步骤(附录 E)。
  23. 使用下一个尝试编号,基于整个提示词文件重新启动,并返回第 16 步;但只有在第 22 步已追加答案时才执行(附录 E)。
  24. 转达结果表格、是否发布的决定,以及引用的失败内容。
  25. 完整转达 Ori 的费用和耗时表(附录 F)。
  26. 根据每个答案文件末尾的摘要行,补充各次尝试各自的耗时和费用(附录 F)。
  27. 用一行说明重新运行的费用更低。
  28. 告诉用户 Ori 将临时工作区放在了哪里,并说明该工作区是一次性的。
  29. 告诉用户,如果评估结果让他们想保留,可以将其移入自己的仓库。

规则

以下规则适用于整个运行过程。

  • 绝不要自己编写评测,也绝不要委派给自己的子 Agent。Ori 的 create-eval skill 会在运行过程中自动执行。
  • 始终传入 --model <RUN_MODEL>,绝不要传入 --harness。固定模型才能确保每个编码 Agent 运行的是同一基准。绝不要替换成其他 slug,也绝不要省略该标志,否则运行会采用用户当前安装所带的默认值。
  • 始终传入 --prompt-file。-p 标志虽然可用,但此处绝不要使用,因为一次性字符串无法在重启后保留状态,而且不带标志的位置提示词会被直接拒绝。
  • 步骤 5 到 9 中的所有命令都由你亲自运行。缺少二进制文件时安装它是预期操作。唯一需要交给用户处理的设置事项是凭据检查。
  • 绝不要自行判断是否恢复之前的运行,也绝不要自行清除之前的运行。该 skill 会在单个会话中加载并运行,因此目录中已有的任何内容都来自另一个会话,而且这是用户付费工作的唯一记录。步骤 4 之后的所有后续操作都必须先得到用户答复;唯一例外是从不含任何运行文件的目录开始全新运行。
  • 随进度更新 steps.txt:开始某一步前将其标为当前步骤,开始下一步前将其标为已完成;并重新读取该文件来判断接下来要做什么,不要依赖记忆。重启会从头重新执行提示词文件,因此这是记录上次尝试进度的唯一依据。
  • 如果某一步的操作是向用户发送消息,只有在该消息已出现在对话中之后,才能将该步骤标为已完成。在工具结果中读取内容并不等于已向用户展示。
  • 一次只运行一个 Ori 进程,绝不要为每个候选模型各运行一个。比较模型由 ori eval 负责。
  • 不要向用户提及 eval run pass 3 之类的内部轮次标签。改用通俗的进度描述。
  • 将运行目录中的 task.txt 视为唯一的任务提示词状态。将之后的每条消息追加到其中,每次重启都重新发送整个文件,绝不使用 --session,并且每次尝试只保留一个答案文件和一个错误日志。
  • 开始运行前,绝不要询问用户要评测什么。Ori 的访谈会了解应用场景、成功标准、真实数据、成本上限和基准模型。即使请求含糊或为空,也要原样传递。
  • 绝不要代替用户回答 Ori 的问题。如果无法联系到用户,就停止并等待。猜测目标会导致评测无效,却看起来像是正确的。
  • 只将用户对当前未回答问题的回复追加到文件中。澄清请求或抱怨不算回答,因此不要追加任何内容;回应用户实际所说的内容,并通过问题 UI 再次提出同一个问题。之后的回复只回答当时待回答的问题,绝不能回填到之前的关卡。
  • 开始运行前,绝不要擅自增设审批环节。步骤 12 和 13 会告知用户所需时间和成本,唯一需要暂停等待用户的情况是步骤 4 中选择运行目录,以及步骤 21 中处理问题。
  • 每轮从开始到结束都保持静默。开始前要明确告知用户这一点。不要把阶段提示当作里程碑汇报,因为它们只会在该轮结束时出现。
  • 绝不要编造数字。每次尝试的答案文件末尾汇总行都会报告该次尝试的耗时和成本;评测自身的模型调用数据则来自 Ori 的结尾表格。只有当某次尝试完全没有写入汇总行时,才能将相关数据称为未测量。
  • 只有当生产模型出现在表格中时,才能宣布获胜者。“不做改动”也是有效结果。
  • 绝不要凭记忆提供模型 ID 或价格。请在 OpenRouter 上查询实时价格。固定项是唯一例外,因为此 skill 会固定它们。
  • 设置检查必须确认 OpenRouter 访问权限是通过 ori auth 验证的。如果无法通过该命令验证,请告知用户运行 ori login;绝不要让用户导出原始密钥。已经继承的密钥也可能满足检查要求。如果 ori auth 命令不存在,说明已安装的 Ori 版本早于此 skill 所需的无头运行支持;请告知用户需要 0.3.0 或更高版本,然后停止。
  • 绝不要将步骤 9 的输出粘贴给用户。你可以阅读它,但用户并没有要求查看。
  • 绝不要输出 credentials.json、.env 文件或配置文件中的机密值。只指出键名及其位置,例如 OPENAI_API_KEY at .env:4。
  • 绝不要把评测写入用户的代码仓库。它是一次性测量工具,不是用户要求保留的内容;用户看过数据后,可以自行决定是否保留。
  • 绝不要将评测放入仓库自己的测试框架中。ori eval 只会查找 *.eval.ts 文件,因此 pytest、vitest 或 Go 测试文件不会运行,且不会给出任何提示。
  • 绝不要将原始 API 调用说成 Ori 评测。如果通过其他方式进行测量,请明确标注。
  • 绝不要向用户展示此 skill 的术语,包括“pre-run”“spawn”“verbatim”和“harness”。
  • 绝不要对用户使用“bakeoff”一词。Ori 的评测文档和解说仍会使用该词,因此每次转述、引用或总结时,以及在你自己的状态消息和命令标签中,都要将其替换为“模型比较”。
  • 每条状态更新都要使用通俗语言。不要向用户展示尝试次数、文件路径、进程 ID、命令标志或退出代码。运行失败时也遵守此规则。附录 E 提供了示例。
  • Ori 的访谈包含七个标签,顺序如下:[surface]、[workspace-files]、[workspace-data]、[criteria-priority]、[evaluation-constraint]、[candidates] 和 [next-step]。如果扫描发现多个调用位置,才会询问 [surface]。仅当扫描未发现模型调用位置,也没有可挖掘的材料时,才会询问 [workspace-files]。这两个条件问题互斥。其余五个问题始终会问,因此最少五个,最多六个。
  • 每轮只转达一个问题。保留每个问题的三个具体选项,不多不少;将 Other 作为自由文本选项呈现。如果 Ori 在同一轮中发出两个问题,只转达第一个,并报告违反了每轮一个问题的约定。
  • 包括中断后或在带外交流后,都要通过问题 UI 提出每个问题。仅用普通文字提问不符合步骤 21 的要求。
  • 提问前,先在普通消息中展示完整上下文,包括任何表格。这样用户就能在对话记录中看到易读的表格,回答后表格也会保留。上下文消息之后、提问之前,更新步骤追踪文件。这适用于每个问题,包括 [next-step]。将完整结果表和成本表展示在问题上方,不要把内容压缩进问题中。绝不要在问题正文中放置 Markdown 表格,因为正文会以普通换行文本呈现,表格会变成原始竖线。附录 E 给出了唯一正确的放置方式。
  • 绝不要将 CLI 细节复制到此 skill 或面向用户的文本中。请重新阅读步骤 9 的输出,了解运行选项、报告、基准、超时和评测文件 API,因为 CLI 会变更,复制的内容会过时。

附录 A:运行目录和步骤跟踪器

你需要在用户仓库之外创建一个临时目录,其名称由正在评估的仓库唯一确定。有两个属性很重要。同一个仓库必须始终对应同一个目录,包括从子目录启动运行时也是如此,因此应根据仓库根目录的绝对路径生成名称;如果没有仓库,则使用工作目录。两个不同的仓库绝不能对应同一个目录,因此名称必须随路径变化;生成名称的方法还必须同时适用于 Linux 和 macOS,因为某个步骤若在其中一个系统上悄悄地什么也不输出,就会导致所有仓库都对应到同一个目录。每个需要该名称的 shell 中都要重新计算,不要指望变量能保留下来,因为 shell 状态通常不会在命令之间持久存在。

名称必须精确到字节可复现,因为此技能的后续运行会通过得到相同路径来找到先前的运行,而不是通过搜索。因此名称格式为 /tmp/spawn-ori-eval-<hash>,其中 hash 是对用于标识该目录树的确切路径计算所得的十六进制 SHA-256 的前 12 个字符;该路径是仓库根目录,或在没有仓库时的工作目录,计算时不能有尾随换行符,也不能输入其他内容。只有这个值是固定的,至于如何计算则不作规定;但值得确认你使用的方法只对这些字节计算哈希,不包含其他字节,因为尾随换行符会生成不同的目录,从而找不到先前的运行。使用 /tmp,而不是环境中所称的临时目录,因为后者在不同机器上可能有所不同,导致同一台机器上的下一次会话也找不到之前的运行。

外层运行生成的每个文件都必须且只能存放在该目录中:steps.txt、task.txt,以及每次尝试对应的 answer-<n>.txt 和 error-<n>.log。ori/ 子目录专供 Ori 的跟踪器使用,以及存放运行自身写入的所有文件。临时工作区由 create-eval 自身的界面创建,因此要将 Ori 报告的路径记录在 ori/ 中。该目录按仓库区分,因此同一台机器上评估的两个仓库绝不会读取彼此的提示词或答案。

steps.txt 的第一行保存用户请求,之后每行对应一个从 5 开始的步骤,并标记为 todo、current 或 done。步骤 1 到 4 不跟踪,因为这些步骤负责生成该文件。

request: which model should we use for the support triage agent
5 done look up the ori binary
6 done fallback lookup not needed
...
15 current start one run
16 todo wait for it to exit and read the answer file

如果目录中没有运行自身的文件,就无需询问,因为没有需要决定的事项。这意味着该目录除了 previous/ 之外为空,并且没有 steps.txt、task.txt、尝试文件或 ori/ 子目录。这样既涵盖了空目录,也涵盖只存放先前归档的目录,因为归档后会永久保留 previous/。其他所有情况都要交由用户决定,无论目录中有什么。跟踪器若是为其他请求启动,或其所有步骤都已完成,理由都是要告诉用户他们看到的是什么,而不是清空目录的许可,因为答案文件就是用户付费获得的运行结果,他们可能想在任何内容被移动之前先阅读。

因此,读取目录并向用户说明情况。提供用户无需自行打开目录就能做出决定所需的信息:旧跟踪器启动时对应的请求、它停止时所处的步骤(用通俗语言说明)、已运行的尝试次数,以及最近一次写入内容距今多久。然后使用操作员自己的问题 UI 提问并等待。

只有当旧跟踪器的第一行与当前处理的请求一致,且仍有未完成的步骤时,才提供继续运行的选项。继续其他运行会把另一个请求的提示词文件再次发送给 Ori。始终可以选择开始新运行或停止,因此问题最多有三个答案,至少有两个。 恢复任务会在现有基础上继续:标注同一份 steps.txt,追加写入同一份 task.txt,在成本表中保留每次先前的尝试,并保留 ori/ 目录及其中记录的临时工作区路径,因为用户已经为这些工作付过费用。开始新一轮会归档跟踪文件、提示词文件、每份答复和错误日志,以及 ori/ 目录;这样会丢弃用户已经提供给 Ori 的答复,还要再次为仓库探索付费。停止不会更改任何内容,并在此处结束任务;用户想先阅读旧文件再进行任何操作时,就应这样做。说明你建议哪种做法及原因,并让用户决定。

恢复任务前有一点需要确认:如果第 15 或第 16 步仍标记为 current,说明已启动一次尝试,但结果未知。开始另一次尝试前,先确认该进程是否仍在运行;如果仍在运行,就等待它结束,因为对同一提示词文件同时运行两个进程违反单进程规则。其他任何仍标记为 current 的步骤都只是被中断,并未启动;包括第 22 步,它会在等待回答问题的回复时保持 current 状态。

归档意味着旧一轮的文件(包括 ori/)会放到运行目录中的 previous/ 目录下,并放入以移动时间命名的独立子目录中;不会删除任何内容。不带时间戳会导致两个问题:后续归档会覆盖之前的归档,而且归档目录会被移入自身。因此,只移动该轮运行自己的文件,并将 previous/ 留在原处。

附录 B:安装命令

使用 curl -fsSL https://openrouter.ai/labs/ori/install.sh | bash 安装二进制文件。它会安装到 ~/.local/bin,该目录在非登录 shell 的 PATH 中经常不存在,因此报告失败前,请先尝试 ~/.local/bin/ori --version。Ori 使用 Bun 执行 *.eval.ts,因此必须安装 Bun。

使用 ori eval -h 和 ori eval skill 查看 eval 接口;如果第二条命令报错,则改用 ori skills get create-eval。Ori 在运行过程中也会遵循这些内容,因此它们会告诉你本次运行将执行哪些操作,以及会提出哪些问题。它不会阻塞任务:如果两条命令都报错,继续进行。

开始前运行 ori auth。它会解析 CLI 将使用的凭据,包括继承的环境密钥;当访问可用时,它会以状态码 0 退出。阅读其输出,以区分未知命令和缺少凭据,但不要向用户显示该输出,也不要重复任何凭据值。如果由于未能解析出凭据而以非零状态码退出,请告知用户运行 ori login,然后停止。如果二进制文件报告 auth 是未知命令,请告知用户,已安装的 Ori 版本早于此技能所需的无头运行支持版本;他们需要安装 0.3.0 或更新版本,然后停止。

附录 C:任务提示词模板

将以下内容写入运行目录中的 task.txt,并填写所有尖括号字段;<JUDGE_MODEL> 的值取自 pins。

在提示词中传入运行目录,以便外层运行可以归档自己拥有的所有 文件,并仍能干净地启动下一次会话。

Use the create-eval skill. Follow its five phases in this order: workspace
context, criteria and narrowing, model comparison, routing, close. There are
seven possible question tags in this order: `[surface]`, `[workspace-files]`,
`[workspace-data]`, `[criteria-priority]`, `[evaluation-constraint]`,
`[candidates]`, and `[next-step]`. The first two are mutually exclusive
conditional questions, so each run asks five or six questions.
Ask exactly one question per turn and end the turn after asking it. Give each
question three concrete options plus a free-text `Other` option. Never combine
questions in one turn.

Judge with <JUDGE_MODEL> rather than the SDK's default judge model: pass it
to setupJudge as its own agent.

User request: <verbatim request>
Repo context pointers: <paths>. Read these first.

The Ori directory is <absolute run directory>/ori. Create it if it is absent.
Keep the step tracker and every file you write outside the scratch workspace
under that directory. Record the scratch workspace path you report in the
tracker directory. Do not derive another tracker path, and do not adopt or
resume tracker state outside it. The scratch workspace path you report is the
only other location this run may use for its eval and supporting files. Any
other tracker or state files outside these locations belong to a different
session. Keep the eval and supporting files in that scratch workspace outside
the user's repository. Run the eval with ori eval. Do not create or modify
anything in the user's repository.

附录 D:启动一次运行

完成此步骤后,你需要得到一个 ori code 进程:从仓库根目录启动,使用固定的模型,并将完整的提示词文件传给它。该进程的助手文本和诊断信息应分别写入运行目录下的两个文件,且文件名使用相同的尝试编号。

尝试编号应为尚未使用过的最小编号,不能固定使用某个编号,因为成本表会从每次尝试的文件中读取,覆盖答案也会一并覆盖该次尝试的成本。将两个输出流分开也很重要,原因相同:只有答案流包含助手文本和成本表所需的摘要行,混入诊断信息会导致两者都无法使用。记下本次运行使用的尝试编号,因为后续每个步骤都会引用该次尝试的文件。

在前台运行。如果操作人员的 shell 调用在运行结束前中断,则改为在后台运行,并使用操作人员自己的进程管理工具轮询状态。

附录 E:答案格式

当前运行的答案文件是运行目录中的 answer-<n>.txt。流程会在回合结束时写入完整的助手答案,因此请在流程退出后读取答案文件。诊断信息会写入错误日志。回合进行期间,没有实时进度来源,也无法检测问题。

答案文件的最后一行是 Ori 自己的摘要行,而不是答案的一部分,格式如下。

summary  model=served/model  duration=200ms  input=100 tok  output=25 tok  context=90 tok  $0.012346

每次尝试都会写入该行,包括在提问时停止的尝试,因此可以从中获取该次尝试的耗时和成本。如果回合未完成便中断,则不会写入摘要行。请从摘要行上方的助手文本中读取问题,因为真正结束文件的是摘要行。

摘要行上方的助手文本包含 Ori 的旁白:简短的普通文本行,说明它做了什么,例如“现在正在扫描这个仓库中调用模型的位置,这需要几分钟。”回合结束时,请先向用户展示这些行,再展示问题或结果。它们能让用户了解静默期间发生了什么。如果行数较多,请简要概述。若 Ori 的原话已经通俗易懂,就保留原话。

重新开始不等于重试。Ori 无法进行实时对话,因此每个答案都会启动一个新会话,重新读取完整的提示词文件并继续。绝不要向用户显示“重新开始”或“尝试”这些字眼,因为它们会让人以为发生了其实并未发生的故障。

向用户展示的状态更新必须通俗易懂。例如:

不要这样说应该这样说
第 2 次尝试以带标签的问题退出;请查看 answer-2.txt。Ori 已阅读你的仓库,在继续之前有一个问题要问你。
eval run pass 3 已完成。Ori 已完成阅读。我正在检查它返回的内容。
正在使用 n=3 重启 ori code --prompt-file。我已将你的回答发送给 Ori。它会重新读取项目和完整的上下文,然后从停止处继续。大约需要 15 分钟。
后台命令“将 Ori 运行重启为第 4 次尝试,并优先处理答案”已完成(退出代码 0)Ori 已完成阅读。我正在检查它返回的内容。
进程 48210 正在运行;error-1.log 为空。本次运行仍在继续。没有消息是正常的。
本次运行未写入摘要行。本次运行在报告耗时和成本之前就已停止。
烘焙赛已启动。模型对比正在进行。
一次已完成的轮次,其助手文本要么以一个问题结束,要么以最终报告结束。在已完成的回答文本中查找所有带标签的问题,并将第一个问题之后的任何叙述视为噪声,而不是轮次在此之后继续的证据。如果一个轮次包含多个问题,只转达第一个问题,报告违反了单问题约定,然后按照下方规则追加并重启。助手文本末尾未带标签的问题也要转达,并以同样方式处理,同时报告违反了约定。向用户展示第一个问题及其三个选项,使用操作员自己的提问 UI,保留 Other 作为自由文本;只有当回复回答了问题时,才将问题和用户自己的答案追加到 task.txt。如果回复是在请求澄清或以其他方式没有回答问题,就不算答案,因此不要追加任何内容;回应用户所说的内容,再次询问同一个问题并等待,而不是重启,因为提示文件没有变化时重启只会付费重新读取代码仓库,然后又回到同一个问题。不要自行回答问题。如果 Ori 回答了自己的范围界定问题,则丢弃该次尝试,不要将其作为结果转达;询问用户、追加答案并重启。中断或通过其他渠道交流后,仍然必须使用问题 UI 提出每个问题;普通文本问题不满足此步骤。

问题不只有选项标签。它还包含标签未呈现的上下文,例如表明界面和当前模型的 Markdown 表格,用户作答时必须看到这些上下文。先通过普通消息打印叙述和完整上下文,包括任何表格,然后在同一轮提问前更新步骤跟踪器。只有在相应消息已出现在对话中后,才能将上下文步骤标记为已完成,并记录实际打印的表头行;如果没有表格,则明确注明不存在表格。用户作答后,打印的表格仍应在对话记录中保持可读。此规则适用于每个问题,包括 [next-step]。在问题上方完整打印结果表和费用表,不要将它们压缩进问题中。

使用精简的问题 UI,其中只包含一个简短句子、三个简短选项标签和自由文本 Other。绝不要在问题正文中放置 Markdown 表格。它会以普通换行文本呈现,因此表格会变成难以阅读的原始竖线文本。三个选项必须一一对应,Other 必须保留为自由文本,并将措辞翻译成简单语言。

之后追加的内容必须是问题的完整通俗表述和单个答案字符串;如果用户选择 Other,则包括其输入的文本。

附录 F:费用和耗时表

每次尝试都必须占一行,包括以提问结束的尝试,因为重启会重复探索代码仓库。每次尝试的耗时和费用取自其回答文件末尾的摘要行;评估本身的模型调用和评审费用取自最终回答中 Ori 的收尾表。开始时间由操作员观察记录,因为摘要行只报告耗时。若某次尝试的回答文件没有摘要行,则表示没有报告数据,应标记为“未测量”,而不是零;只要有任意一行未测量,总费用就必须标为下限。用通俗语言标注各行,因为这张表会展示给用户,通俗语言规则在此同样适用。

步骤开始时间耗时费用
阅读项目,在此暂停并向你提问观察记录 20:2939s$0.42
你回答后再次阅读项目观察记录 20:3015m 10s$3.20
评估模型调用20:462m$0.46
评审20:481m$0.05
…
总计$4.13

接着用一行说明,例如:本次运行总费用为 $4.13,重新运行的费用仅为 Ori 收尾表中所示的金额。

附录 G:故障排除

症状请执行以下操作
运行目录中已有运行文件报告目录中的内容并询问用户。切勿继续使用该目录,也不要自行清理。
安装成功后出现 ori: command not found运行 ~/.local/bin/ori。安装程序对 PATH 的更改不会应用于当前 shell。
缺少凭据停止。告知用户运行 ori login。
首次运行时长时间停顿首次运行会创建 ~/.ori/global 并下载模板。此过程约需 30 秒,并不代表运行已停止。
Ori 没有任何反应,提示词看起来是空的启动命令中的路径与您写入文件的路径不匹配。
Ori 报告某个模型 id 不可用告诉 Ori 重新查找该 id。不要凭记忆提供 id。
评估文件位于用户的仓库内将该文件及其相关文件移至临时工作区,并在新路径上运行 ori eval。
Ori 恢复了自己在先前会话中的跟踪器丢弃这次尝试,不要转述其内容。明确告知用户 Ori 恢复了先前会话的状态,并在进行任何操作前征求同意。用户同意后,只将遗留的 ori/ 状态移至 previous/<timestamp>/,保留当前跟踪器、提示词文件和成本表不动,然后从完整提示词文件开始,并使用下一个尝试编号重新启动。
Ori 自行选定了目标丢弃这次尝试,不要接受猜测的目标。询问用户,将其回答追加进去,然后从完整提示词文件重新开始。
回答中没有带标签的问题,但运行看起来已停止阅读最终回答。转达未带标签的问题,报告违反了约定,然后从步骤 19 继续。
用户表示看不懂表格在普通消息中重新打印上下文。切勿将 Markdown 表格放在问题正文中,因为它会以原始竖线符号显示。
ori code 因需要终端而拒绝重定向运行停止。这次尝试没有花费任何费用,而且此二进制文件无法继续运行。告知用户使用 Ori 0.3.0 或更新版本。
出现 403 Key limit exceeded 或 402 付款错误密钥已达到消费限额。请见下文。

因密钥限额或付款错误而在几秒内终止的运行,并非 Ori 或评估本身存在缺陷。明确告知用户该密钥没有可用额度、没有写入任何评估内容,而且这次尝试没有花费任何费用。提供错误信息中的确切 Manage it using <url> 链接,并询问用户是要提高限额还是添加额度。只需在控制面板中更改设置即可,因为凭据仍然有效,无需再次运行 ori login。用户确认后,重新启动同一运行,并从任务中断处继续,因为该错误是可恢复的暂停,而非终止性故障。

评论

支持 Markdown