作者：CoworkEnv 团队
青稞社区为科研人员提供成果宣传支持，如有优秀研究成果分享推广，欢迎投稿联系：aiFreeCode

假设你向一个 AI 同事提出请求：找出超过 48 小时仍未关闭的企业客户工单，并向对应的客户经理发送工单升级处理的通知邮件。

要完成这项工作，Agent 需要查询工单、核对客户等级、找到客户经理的联系方式，再发送邮件。一张刚创建的高优先级工单看起来很紧急，却不符合“超过 48 小时”的条件。不同服务中的记录需要指向同一个客户，邮件是否发出、发给了谁，也要能检查。

这样的任务怎样批量构建，又怎样用于训练？

CoworkEnv 论文：https://arxiv.org/abs/2610.24960
CoworkEnv 代码：https://github.com/HKUST-KnowComp/CoworkEnv
PocketWorker 模型合集：https://huggingface.co/collections/zhongweixie/pocketworker
CoworkEnv Lessons 实践笔记：https://github.com/zhongweixie/CoworkEnv-Lessons

我们在 CoworkEnv 中尝试回答这个问题：从希望模型学会的能力出发，构建包含请求、初始状态、工具接口和评分检查的可执行环境，在其中采集示范，支持监督微调（SFT）和强化学习（RL）。基于这些资源，我们训练了 PocketWorker 系列模型。

做这个项目时，我们也踩了不少具体的坑：工具路径写错了，系统上下文在转换时丢了，奖励字段没有接上，训练中途出了故障，却没留下可恢复的检查点。下面想结合论文和 Lessons 笔记，聊聊环境怎么构建，以及在预算有限时，哪些问题值得尽早检查。这些经历来自项目开发和后续探索，涉及的实验设置并不都相同。

一 把工作要求变成可执行的任务

CoworkEnv 从需要训练的能力出发，规划服务组合、业务场景和预期难度。例如，一个任务可能要求跨服务查找同一实体、结合时间条件筛选记录，或者在调查异常请求时遵守操作限制。

生成模型接收能力要求、服务目录、输出规格和任务示例，产出用户请求、初始服务记录、完成条件及禁止执行的动作。随后，程序将这些规格装配到已有的服务实现和评分模板中。执行时，运行环境加载初始记录，并管理服务启动与状态重置。

这里有一个实现上的选择：通过复用工具服务和评分实现，让任务变化主要体现在场景、数据和约束上。 这样既能生成不同工作流，也便于检查和修复共用组件。

一个任务环境需要回答四个问题：

• 用户希望完成什么工作？
• 工作开始时有哪些记录和状态？
• Agent 可以调用哪些工具？
• 怎样根据执行记录与结果判断任务是否完成？

这些答案必须相互一致。回到工单升级的例子，Agent 根据工单创建时间判断是否超时，从 CRM 核对客户等级，再通过联系人信息找到收件人。任务中的时间条件使用固定参考日期，评分器也按同一套实体和动作定义，检查 Agent 是否找对了对象、完成了操作。

安全场景还会加入行动约束。例如，在调查可疑付款变更请求时，Agent 可以查阅往来邮件和交易记录，但某些发送或提交动作属于禁止操作。这里采用 Generator–Discriminator 分工：生成端起草请求和记录，检查端在独立上下文中读取记录与安全场景说明，制定完成条件和禁止动作。生成出的规格还要经过后续程序检查。

图 1：CoworkEnv 的任务构建与教师示范采集流程。任务包含请求、初始状态、工具接口和评分检查；执行记录经筛选后用于 SFT。同一类任务定义也支持学生在线交互和 RL 奖励计算。来源：论文 Figure 1。

二 任务能运行，评分也要算对

生成出一份看起来合理的任务，只是开始。接下来要确认工具确实能执行，评分器也能判断执行得对不对。

我们曾发现，5 个生成任务把联系人操作指向了 /contacts/send，实际服务提供的接口却是 /contacts/send_message。还有一个任务要求创建 3 条待办事项，评分器只要求出现 2 次成功创建调用。前者影响任务能否完成，后者可能让未完成的工作得到错误认可。

结合论文中的检查流程和这些开发经历，我们在 Lessons 中建议从三个层面验证任务。

先检查任务规格。 服务是否已注册，初始记录是否齐全，实体引用和工具名称是否有效，完成度评分的权重之和是否为 1，必做动作与禁止动作是否冲突，都可以先通过程序检查。还要查看最终交给 Agent 的请求，确认生成阶段保存的参考答案没有在后续装配时混入任务描述。

再检查评分行为。 论文中的一致性检查会构造满足完成条件的记录、空记录，以及包含禁止动作的记录，分别检查完成度与安全分数。检查失败后，诊断信息返回生成端，修订后的规格重新接受检查。

这些经历也提醒我们，评分用例要覆盖“看起来执行过，但结果不对”的情况：操作了错误的客户、重复创建同一条记录，或者产生了错误的最终产物。只统计成功调用的次数，可能会把三次重复创建当作三个不同事项。

最后通过实际工具执行一条有效路径。 静态检查和合成记录无法覆盖所有运行时问题。接口能否访问、服务是否真的改变状态、审计记录是否进入评分器，都需要沿着完整执行路径检查。

我们也遇到过服务写入的审计字段与评分器读取的字段不一致，以及多个工具共用一个端点后，评分器无法区分实际执行了哪个动作的问题。排查时，需要从调用参数一直追到状态变化、审计记录和评分输入。任务失败后，先检查这条链路，有助于判断问题出在模型、环境还是评分上。

在扩充任务库之前，保留少量代表性工作流用于反复回放很有价值。共用服务或评分模板发生修改时，可以先检查跨服务关联、状态变更和受限操作是否仍然正确。

图 2：构建库覆盖的服务与任务类型。602 和 263 是两个构建库快照中的任务标识数量，其中有 236 个标识重合，不能直接相加，也不代表评测集或某个检查点的训练集大小。来源：论文 Figure 2。

三 模型到底看到了哪些训练内容

有了环境，下一步是采集教师示范。论文中有工具工作流和多轮对话两条准备路径，任务均独立于基准测试集构建。

工具工作流中，教师调用工具、读取观察，留下可评分的执行记录。我们根据多次尝试的平均完成度筛选任务：完成度接近零的暂不导出，中间组保留符合条件的示范；对于稳定完成的任务，按规范化的任务前缀分组，每组保留一条合格示范，减少重复。合并时按任务和试验标识去重，导出时按奖励筛选，转换时再检查结构和长度。

多轮对话中，任务包含用户画像，由模拟用户产生后续回复。评分模型根据任务规则，评价助手是否澄清了所需信息，以及最终回答的质量。这条路径为每个任务选择得分最高的一次教师尝试，去掉用户模拟器特有的前缀，再整理成训练消息。

这些教师示范用于 SFT。RL 则让学生在所选环境中在线执行，奖励来自学生自己的工具调用和服务审计记录。

把轨迹转成训练消息时，也出过问题。一个任务上下文加载器使用了错误的模块路径，异常被捕获后，程序返回了缺少系统上下文和工具定义的结果。后续流程仍可能继续运行，但模型看到的内容已经变了。修复时，我们纠正了加载路径，也去掉了吞掉异常的回退逻辑，让信息缺失时能够明确报错。

另一次调整涉及推理内容的表示方式：只有放到所选聊天模板实际读取的位置，这些内容才会进入模型输入。JSON 中保留了某个字段，并不能证明模型读到了它。

这些问题给我们的提醒是：值得抽取少量样本，沿着转换、模板渲染、分词、截断和标签生成逐步看一遍。论文中的 SFT 用用户和工具消息提供上下文，对选定的助手回复和工具调用进行监督。最终哪些 token 参与 loss，要在实际训练输入中确认。

长轨迹还会经历多次信息裁剪。我们检查过的一条转换路径会将过长工具观察保留为前 1,000 个字符，并丢弃超过 40,000 字符预算的完整样本；训练器随后还会施加 token 长度限制。即使样本通过了筛选，也值得再看看关键证据和目标动作是否还在。工具消息即使不直接参与 loss，仍会占用上下文和计算资源。

工具调用与观察之间的关系同样需要保留。一次助手回复中的文字和工具调用应维持正确边界，工具结果通过调用标识关联。缺失的观察需要显式处理；填入一个空字符串只能补上格式，无法补回后续行动所需的证据。

四 一次工具调用，怎样接到下一轮

Agent 运行时，外部框架（harness）负责组织系统提示、工具描述和历史记录，解析工具调用，并决定何时停止。这些细节会影响模型的实际行为。

接入推理服务时，我们遇到过这样的情况：模型生成了带有 Qwen 风格工具调用标签的文本，而下游程序等待的是结构化 API 字段。要让这次交互真正执行，服务端需要正确解析调用、派发工具，并把结果重新组织进下一轮历史。

一个实用检查是保留一段完整对话：用户提出请求，助手调用工具，工具返回观察，助手继续行动。让它经过采集、SFT 渲染、在线采样、部署和评测接口，检查工具名称、参数类型、调用标识和上下文是否一致。

我们在 Lessons 中也建议核对采样配置的实际生效值。即使传入了 temperature 参数，某些生成路径也可能最终使用贪心解码。排查 RL 组内轨迹缺乏差异时，这一项值得一起检查。

这里也有两个容易混在一起的问题。工具描述或观察丢失，会改变模型输入；概率计算、精度或权重更新时序带来的不一致，则属于数值层面的差异。把它们分开检查，更容易找到相应的修复方式。

五 有限预算下怎样安排训练实验

关注有多少采样形成了有效反馈

我们调查过一次奖励接口不匹配：轨迹生成端写入字段 reward，消费端读取的却是 score。字段读取失败后，样本被判为无效。生成仍在继续，奖励驱动的策略学习信号却没有正常传递。

另一类情况是样本合法，但同组奖励全部相同。以论文中的 GRPO 配置为例，组内标量奖励减去均值后就变成了零，再按带下限的标准差归一化，优势仍为零。这类组仍然有效，但不提供来自该奖励的策略梯度；其他损失项和优化器状态仍可能影响更新。这个判断针对上述估计方式，不能直接套用于使用分项奖励或中间状态反馈的其他配置。

Lessons 中的历史开发日志也记录了大量零方差组和基础设施无效组。回头看这些记录，尝试了多少组、有效评分有多少、又有多少组包含奖励差异，是三个值得分别看的数字。教师平均完成度适中，也不保证学生在线采样时就能获得有差异的奖励。

因此，我们建议把尝试次数、有效评分、有奖励差异的组、失败原因和耗时分别记录下来。真实的零分、评分不可用、合法但零方差的组，也要能区分。弄清楚预算花在了哪里，才有依据决定接下来是调整任务难度、评分粒度、采样配置，还是增加计算资源。

在后续过程反馈探索中，我们还关注奖励是否对应新增进展。重复读取同一份证据不应反复获得相同奖励；证据不足时应保留未知状态。更密集的评分需要先校准其含义，再进入训练。

用小实验提前发现昂贵的错误

如果要从头搭建一套训练流程，我们建议先用几轮小实验，把关键问题逐个检查清楚：

1、 先用固定动作回放环境。 在已知状态下检查工具路由、记录、评分和失败处理，很多问题可以在 CPU 上发现。

2、 再验证完整的模型交互。 选择少量覆盖不同接口的任务，检查工具调用、观察返回、多轮继续和终止条件。较小模型有助于缩短调试时间，但它解不出困难任务，不能直接说明任务不可解。

3、 做一次很小的学习实验。 SFT 可以检查小批数据能否过拟合；RL 可以先验证明确的奖励差异是否进入优势和更新，再跑短程在线交互。这个阶段同时验证保存、重载和生成。

4、提前测试长历史与故障。 纳入较长上下文、大工具观察、服务失败和训练中断。压缩调试规模时，优先减少任务或更新次数，保留完成任务所需的交互长度。

小实验帮助定位问题，正式的能力提升仍要通过独立评测判断。扩大模型、上下文或并发规模后，也要在目标配置上重新检查关键路径。

算成本时，GPU 时长也只是其中一部分。环境服务、评分模型调用、输入输出 token，以及维护基础设施的时间，都会占用预算。我们曾在独立探索中使用托管训练服务尝试 30B 级模型，这与已发布 PocketWorker 检查点的训练路径分开。托管还是自建，要看实验需要多大控制空间、服务支持哪些训练目标、上下文有多长，以及能否访问所需的检查点。参数量本身说明不了完整成本。

尽早保存并验证恢复

一次探索性 PPO 训练在策略模型（actor）更新到第 122 步时，因为沙箱命令输出解码失败而中断。该次运行计划只有 187 次更新，检查点保存间隔却设成了一百万次更新，最终没有留下训练检查点。后续修复同时处理了解码问题，并把保存间隔改为 25 次更新。

这次失败给我们的提醒很直接：保存和恢复也要在小实验阶段测一遍。能否保存、能否读取实验所需的优化器或 critic 状态、重启后是否真正接着训练，都值得提前确认。长任务开始后，也要尽早检查是否已经留下第一个可恢复的检查点。

同样，模型导出后也值得通过目标服务试一次普通回复、结构化工具调用和多轮继续。服务健康检查通过，只能说明进程可响应。把权重、tokenizer、processor、聊天模板和导出配置一起记录下来，后续才容易确认评测和部署用的是哪套模型配置。

六 回到论文中的训练结果

基于 CoworkEnv 构建的训练资源，我们采用 LoRA 对 Qwen3-VL-8B-Instruct 进行 SFT，得到对应的 PocketWorker-8B 检查点。

在 Claw-Eval 的同配置比较中：

• General 平均分从 46.7 提升到 60.9，增加 14.2 分。
• Multi-turn 平均分从 45.9 提升到 77.8，增加 31.9 分。
• 两类任务合并的 Overall 从 46.6 提升到 64.1，增加 17.5 分。

这里的 Overall 覆盖 161 个 General 和 38 个 Multi-turn 任务，按任务等权计算，不包含 101 个 Multimodal 任务。上述基座与 SFT 结果均采用每任务三次试验。以上提升为 0–100 分制上的绝对分数变化，分数与增量分别四舍五入到一位小数。

图 3：Claw-Eval 结果，取自论文 Table 1。本项目的基座与 PocketWorker 比较采用相同评测配置；表中的外部参考模型分数来自公开结果，评测协议见论文附录 F。

在另一条面向 ClawMark 的 SFT 分支上，8B 模型的平均分从 11.8 提升到 19.4。这个检查点与前面的 Claw-Eval SFT 检查点不同，用于探索同一环境构建思路在另一类 coworker 工作流上的适用性。

RL 部分从共享的监督预热检查点出发，比较 GRPO、Dr.GRPO、GDPO 和 GiGPO 等配置下的训练动态与评测表现。它们在奖励处理、优势估计，以及如何把学习信号分配到具体动作（credit assignment）等方面有所不同。前面的 64.1 分和多轮任务增加的 31.9 分，都是 SFT 结果。

对 RL 实验的解释还需要落实到实际执行的配置。奖励怎样构造、优势怎样估计、哪些动作接收信号、loss 怎样归一化，都应单独记录。比如，论文中的 GDPO 比较还改变了 batch size，因此结果反映的是整套配置的效果。若要判断某个机制的独立贡献，需要进一步控制其他变量。

七 代码和经验，还在继续整理

我们希望其他研究者能够理解任务如何构建、轨迹如何采集、监督怎样进入模型，并据此改造成适合自己研究问题的流程。

截至 2026 年 10 月 20 日，CoworkEnv 代码仓库已包含任务构建、执行适配、轨迹导出、SFT 和部分 RL 辅助组件；当前公开的 RL 部分主要覆盖数据与奖励预处理。完整分布式 RL 训练栈和任务数据集尚未随代码仓库打包。我们计划继续整理并逐步发布数据集和更完整的构建流程。PocketWorker 模型通过独立的 Hugging Face 合集提供。

我们也公开了 14 页、包含 11 条实践经验的 Lessons 笔记，覆盖环境与评分、监督与交互协议、实验成本、检查点恢复和后续研究探索。项目和相关材料仍在持续更新。

回头看，我们最想分享的一条经验是：先确定当前最需要回答的问题，再设计能够回答它的最小实验。 是任务本身有问题，奖励没有接上，还是模型还没有学会？把这些问题逐个查清楚，会让后续的数据和算力投入更有依据。对资源有限的研究团队来说，能少走一些重复的弯路，就已经很有价值。

欢迎做 Agent、环境合成和强化学习的朋友交流，也欢迎反馈复现过程中遇到的问题。