跳转到主要内容
AgentWorkflow 是 rollout 行为的 SDK contract。您需要继承它、实现一个 async run() 方法,并通过返回 message history,或通过 Osmosis 支持的 agent integration 调用当前策略并注册 sample source,来创建一个 sample。 Workflow 应该回答一个问题:给定这个数据集 prompt,agent 在 grader 打分之前应该做什么?

基类

SDK 形状如下:
run() 会为每次 workflow execution 调用一次。在方法内部构造任何 per-execution agent 或 session objects 并运行 agent。然后直接返回 sample,或让 integration 把生成的 conversation 注册到活跃的 RolloutContext。

Workflow 返回值

run() 接受三种形状,都会被规范化为单个 sample: 受支持的 integrations 会为您注册 sample source,因此大多数 workflow 返回 None:OsmosisStrandsAgent 注册其 Strands history,OsmosisMemorySession 注册 OpenAI Agents SDK session。当您自己构建 message history 时返回 AgentWorkflowOutput:
AgentWorkflowOutput.info 是保留字段,目前不会传给 grader。有限数值的 sample measurements 请放在 metrics 中,文件请写入 ctx.artifacts_dir。
AgentWorkflowOutput 拒绝未知的顶层字段和非有限的 metric 值(NaN、inf、-inf)。相同的校验会在 Local 与 Harbor/container 执行中运行。

AgentWorkflowContext

ctx object 为 workflow 提供输入和 config: 如果您的数据集行包含 system_prompt、user_prompt 和 ground_truth,prompt 字段会被组装进 ctx.prompt。参考答案不会传给 workflow;它会作为 ctx.label 暴露给 grader。AgentWorkflowContext 和 GraderContext 上的 metadata 对象相同,因此 workflow 和 grader 可以读取同一份按行的上下文。
不要把 task answers 放进 AgentWorkflow.run()。Workflow 应该产出行为;Grader 应该决定该行为是否值得 reward。

写入 artifacts

使用 ctx.artifacts_dir 写入不适合放进 sample payload 的文件 —— 日志、trace、截图或其他大文件/二进制输出。每次 rollout 都有独立目录,但当执行环境无法提供时为 None,因此写入前请用 if ctx.artifacts_dir: 进行判断 —— 未加判断的写入会抛出异常并导致 workflow 失败。
Rollout 结束后,收集到的文件会与对应 sample 一起显示在 Osmosis 平台上 run 的 Artifacts 面板中,并保留你在 ctx.artifacts_dir 下写入的目录结构。Artifact 收集永远不会影响 rewards 或 rollout 状态。 请像上面的示例一样,使用 asyncio.to_thread 在事件循环之外写入 artifacts。在托管运行中,ctx.artifacts_dir 可能由远程存储支持,关闭文件时可能需要等待上传完成。同步写入会阻塞 server 上的所有 rollout,并延迟结果轮询。

保存的 Trajectory

使用 create_rollout_server() 创建的 rollout server 会把已完成的 samples 作为 ATIF(Agent Trajectory Interchange Format)文档保存在 run artifacts 旁。Persistence 采用 best-effort 策略,永远不会改变 reward 或 rollout 状态。在自定义 harness 中直接调用 LocalBackend.run_workflow() 或其他 backend 方法不会安装这个 server lifecycle;该 harness 必须自行保存所需 trajectory。 文件位于平台管理的主机路径下:
RolloutSample.messages 会保留 grader 读取的 framework-native history。对于 ATIF persistence,内置 integrations 会在 trajectory_messages 中创建一份独立的 best-effort normalized copy;normalization 失败时 native sample 保持不变,并跳过 trajectory persistence。显式 workflow output 在可复制时会将返回的 messages 用于两个 views。
如果你构建的自定义 sample source 的原生历史不是 OpenAI chat-completions 形式,请在返回的 sample 上设置 RolloutSample.trajectory_messages 来控制持久化内容(显式设为 None 会跳过该 sample 的 trajectory 保存)。
只有 source messages 或 server report 提供 usage、model 和 timestamp 数据时,ATIF 才会包含这些字段。缺失的 metadata 会保持缺失;SDK 不会虚构它们。

实时 Trajectory 预览

实时 trajectory 预览默认关闭,只有 host 环境启用预览发布后才会生效。启用后,rollout server 大约每三秒对支持的对话采样一次,并发布最多最近 100 个 ATIF steps;大小限制可能会进一步缩短预览。 预览仅用于诊断,不会替换用于 grading 的 sample、影响 rewards 或改变保存的 trajectory.json。发布前,SDK 会脱敏配置的 LLM API key 和可识别的凭据模式,包括 authorization headers 和 URL credentials。 Host 启用预览后,以下 sources 会自动提供快照: 只在完成时从 run() 返回 messages 的 workflows 没有实时 source,因此不会产生预览。使用旧版 SDK 构建的 bundles 也不会产生预览,并保留原有的最终结果行为。只在退出时写入 trajectory 的 mini-swe-agent 版本无法提供运行中的预览。

为某个 rollout 关闭预览

要让某个 rollout 不出现在实时预览中,请在当前 rollout context 上设置 preview_enabled = False。请在 run() 开始时、构造 agent 或 session 之前以及第一个 await 之前设置:
之后再设置该标志只会停止后续快照,不会撤回 SDK 已捕获的预览。

为自定义 sample source 添加预览

自定义 SampleSource 实现默认不发布预览。要启用预览,请重写 async get_preview(max_messages),并返回一个包含最多 max_messages 条最近 messages 副本的 RolloutSample:
请在 run() 中通过当前 rollout context 的 set_sample_source() 注册实例;每个 rollout 只接受一个 source。get_preview() 必须返回有界、只读的快照。不要在其中调用 get_sample(),也不要修改 graders 读取的 history。来自自定义 sources 的预览会显示未知的 step IDs 和 turn 数。

模型路由要求

run() 内的 LLM 调用必须通过执行后端安装的 RolloutContext 路由。训练集群使用该 context 中的 rollout-scoped chat-completions URL 服务当前策略、收集 traces,并把 reward 连接到 sample。
请使用以下受支持 integrations 之一: 不要在 run() 中用硬编码 policy model 直接调用 litellm、OpenAI SDK 或其他 provider SDK。直接调用会绕过 rollout context,无法用于训练。

Strands 模式

对于 Strands,直接把 ctx.prompt 作为 messages 传入,并调用 invoke_async():
在 run() 内构造 OsmosisStrandsAgent 会将其绑定到活跃的 rollout context,并把 agent 注册为 sample source。 工具 examples、迁移步骤和 OsmosisRolloutModel 细节请参见 Strands 集成。

OpenAI Agents 模式

对于 OpenAI Agents,请构造 OsmosisAgent,附加 OpenAI Agents ModelSettings,创建一个 OsmosisMemorySession,并把该 session 传给 Runner.run():
Session 会记录 OpenAI Agents SDK conversation 以供 grader 使用。请在 run() 内创建它,使其注册到当前 RolloutContext。 Session 行为、tracing 说明和迁移步骤请参见 OpenAI Agents 集成。

自定义配置

自定义 configs 继承 AgentWorkflowConfig。请在 rollout entrypoint 中定义 module-level config instance,并把它传给 backend:
请把 config instance 显式传给 backend constructor,例如 LocalBackend(workflow=SearchWorkflow, workflow_config=search_workflow_config)。Eval 和 training TOML 文件目前不会直接设置 workflow config fields。 BaseConfig 允许额外字段,因此简单 rollout configs 通常不需要额外的 Pydantic 样板代码。

使用工具的 Workflows

工具使用属于 agent framework,而不是 backend。请按您的 framework 期望的方式定义 tools,把它们传给 Osmosis-wrapped agent,并让 integration 记录生成的 messages。 例如,Strands workflow 可以把 tool list 放在 config 中:

Entry Point 连接

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

下一步

Strands 集成

使用 tools 和 OsmosisStrandsAgent 构建基于 Strands 的 rollout。

OpenAI Agents 集成

使用 OsmosisAgent 和 OsmosisMemorySession 构建 OpenAI Agents SDK rollout。

Grader

为 workflow 生成的 sample 定义 reward 逻辑。

评估

在训练前提交 evaluation run 测试 workflow 和 grader。
最后修改于 2026年10月8日