Skip to main content
Grader 为一次 rollout execution 产生的单个 sample 分配 reward。

Grader 基类

SDK 中的基类签名:
grade() 通过 GraderContext 接收 sample、reference label、metadata 和可选的 artifacts directory。

GraderContext

传递给 grade()ctx 参数提供:
使用 LocalBackend 时,只要 dataset row 包含 label metadata,配置好的 Grader 就会运行,因此可以仅依靠 metadata 驱动 reward。使用 HarborBackend 时,已有 task tests/test.sh 仍是权威来源;只有该文件不存在时,Osmosis Grader 才会作为 verifier 安装。请参见 Harbor reward 优先级
一次 workflow 执行最多生成一个 sample。Evaluation 和 training 仍然可以对同一个 prompt 多次执行 workflow(evaluation config 中的 [evaluation].n,training config 中的 n_samples_per_prompt);每次独立执行都会收到自己的 GraderContext

set_reward

调用 ctx.set_reward(reward) 为 rollout 的 sample 分配 reward。reward 应为浮点数,通常在 0.0 到 1.0 之间。任何有限浮点值均可接受,NumPy 风格的数值标量会被自动规范化为 float
ctx.sampleNone 时,set_reward 会抛出 ValueError。评分前请检查 sample;缺少 sample 通常意味着 workflow 没有在 run() 内构造受支持的 agent 或 session。
NaN、无穷大以及非数值值会触发 pydantic.ValidationError,因为它们违反 reward 的 JSON wire contract。请返回预期的数值 reward,或直接不调用 set_reward 表示该 sample 未评分。

写入 artifacts

Grader 可以通过 ctx.artifacts_dir 持久化评分 trace、diff 或任何其他文件。该目录按 rollout 独立,并与产生 sample 的 workflow 共享,因此 grader 也可以读取 workflow 写入的文件。当执行环境无法提供时为 None,因此写入前请用 if ctx.artifacts_dir: 进行判断 —— 未加判断的写入会抛出异常并导致 grader 失败。
Rollout 结束后,收集到的文件会与对应 sample 一起显示在 Osmosis 平台上 run 的 Artifacts 面板中,并保留你在 ctx.artifacts_dir 下写入的目录结构。Artifact 收集永远不会影响 rewards 或 rollout 状态。

RolloutSample

ctx.sample 是一个包含 AgentWorkflow 输出的 RolloutSample 对象:
messages 列表就是您的 workflow 为该 sample 产出的对话记录。在很多 grader 里,您只需要从最后一条 assistant 消息中提取最终答案文本即可。
真实参考请看 workspace-template 仓库中的 rollouts/multiply-local-strands/main.pyrollouts/multiply-local-openai/main.py。这些文件是平台创建 workspace repositories 时使用的 source of truth。

实现模式

精确匹配评分

最简单的评分策略就是把 Agent 的最终文本和 ctx.label 直接比较。下面的辅助函数演示了如何从最后一条消息中提取文本:

LLM-as-Judge 评分

当正确性具有主观性或难以通过程序化方式检查时,可以使用另一个 LLM 评估 Agent 输出。Judge call 不需要 policy call 使用的 rollout model integration,因此可以直接调用其他 LLM。Grading 仍会在 workflow 结束后同步执行;其延迟和失败会影响 rollout。

基于工具调用的评分

评估 Agent 是否进行了工具调用,而不仅仅检查最终文本输出。Strands 会把工具调用记录为 assistant 消息上的 toolUse content block:
您可以组合多种评分策略 —— 例如,检查 Agent 是否使用了正确的工具并且生成了正确的最终答案,然后对分数进行加权。

GraderConfig

自定义 grader configs 遵循与 AgentWorkflowConfig 相同的模式:继承 GraderConfig、创建 instance,并将它显式传给 backend:
把 config instance 传给 LocalBackend(grader_config=my_grader_config)。Eval 和 training TOML 文件目前不会直接设置 grader config fields。 GraderConfig 扩展自 BaseConfig,并包含与 AgentWorkflowConfig 相同的 concurrency 字段,但当前 backends 不会用它限制 grader concurrency。如果 grader 会调用外部服务,请使用 eval [evaluation].batch_size、workflow/backend concurrency,或在 grader 内部显式加 limiter。

Entry Point 连接

Grader classes 和 config objects 需要显式 wiring。请在 backend constructor 中选择它们:
多个具体 Grader subclasses 可以在 entrypoint 中共存;只有通过 grader 传入的 class 会运行。Submit preflight 会导入 entrypoint 一次以暴露 constructor 和 dependency errors,不会检查它的 module namespace;关于该导入在何种情况下被跳过、以及它在本地执行了什么,参见 Rollout 中的文件

下一步

评估

在训练前提交 evaluation run 测试您的 AgentWorkflow 和 Grader。
最后修改于 2026年8月10日