448个服务组合训练，小红书Agent成功率翻三倍

处理一批逾期工单，要先从数据库找出待处理记录，再查阅操作手册确定处理规则，最后通知对应的负责人和客户。每一步都有工具可以调用，但要把整件事办好，Agent必须将前一步得到的信息，准确地带到后续操作中。

查询对象是否正确，处理方式是否符合规则，通知是否发给了对应的人，任何一个环节出错，都可能让整个任务失败。小红书AllSpark团队提出的CompoWorld，正是冲着这个难题去的——在组合层面扩展训练环境，把448个可复用服务组合成训练环境，在八项Agent基准上较基座模型平均提升9.17分。

跨应用任务需要什么样的训练环境

Agent的动作会改变外部世界。发送一封邮件、修改一条工单或者创建一个日程，都意味着环境状态发生变化，后续决策需要建立在这些变化之上。训练Agent需要可交互、可反馈、可验证的环境。

已有工作通过自动构建工具环境和任务，扩大训练数据的覆盖范围。CompoWorld进一步关注服务之间的依赖：在一项任务中，数据库返回的记录可能决定要查阅哪份文档，文档中的规则又决定后续应当执行什么操作。

如果训练只覆盖各个应用内部的独立任务，模型获得的跨应用协作经验就会受到限制。把更多工具放进同一个列表，也不足以保证任务中存在有意义的信息流。CompoWorld将每个服务设计为可以独立运行、反复使用的组件，再根据任务需要连接这些组件。邮件、日历、数据库等服务可以参与不同组合，承担不同环节的工作。服务之间如何传递信息、如何相互约束，由此成为训练环境可以扩展的一个新的维度。

可复用环境组件是怎么造出来的

组合的前提，是每个服务本身能够可靠运行，并且具有兼容的接口。CompoWorld从公开的MCP工具规范出发，收集工具名称、功能描述和参数类型，再由Coding Agent构建对应的模拟服务。一个服务包含自己的状态、工具集合，以及工具调用引起的状态变化。例如，邮件服务需要维护邮件记录，日历服务需要维护事件及其相关字段。

团队使用统一的Python类型模型约束服务状态，使工具调用后的更新可以被检查。各个服务采用一致的执行约定和JSON返回格式，便于组合后共同运行。

生成之后还需要验证。Coding Agent在隔离环境中编写实现与测试，运行测试并修复问题；随后，独立的Agent会话直接依据工具规范构造额外测试，检查边界条件等情况。未通过检查的工具不会被当作已验证的确定性实现使用。

对于依赖外部系统、难以可靠地用本地代码实现的工具，CompoWorld选择性地使用语言模型模拟返回结果和必要的状态更新。模拟产生的更新仍然要经过同一套类型校验，并进入服务状态，供后续工具使用。最终，7.1%的工具依赖世界模型模拟，约10%的样本调用了至少一个这样的工具。通过这套流程，团队构建了448个可复用服务，覆盖10,130个工具，涵盖广泛的领域，为后续的任务组合提供执行基础。

多个服务如何构成一项完整任务

多个服务可以共同运行，只解决了"工具是否可用"的问题。任务生成还要回答，为什么完成这件事必须同时使用这些服务？

CompoWorld采用随机游走过程选择和连接服务，形成服务级依赖图。图中的节点表示服务，连接表示信息依赖：后一个服务正确执行所需要的信息，要从前一个服务的返回结果中获得。

任务还可以要求Agent再次访问某个服务。例如，中间操作改变了相关状态，先前读到的信息已经过时，Agent就需要重新查询。这样，任务能够覆盖多次访问、状态更新和信息同步等交互结构。Agent还需要通过list_services、list_tools、describe_tool和call_tool等元工具逐步发现服务、查看实际工具、获取参数定义并执行操作。

依赖图用于组织任务，但不指定唯一的工具调用顺序。Agent可以自行规划执行路径，只要最终满足任务要求。任务生成随后经历四个阶段：

1. 探索服务。实际调用工具，了解接口和状态结构。
2. 设计任务。根据服务依赖构造初始状态、用户指令和验收条件。
3. 执行验证。通过真实工具调用尝试完成任务，确认目标可达，并检查验收程序能否接受参考结果。
4. 提交任务。保留通过验证的指令、环境状态与评估材料。

这种设计让同一批服务能够支持大量不同的任务。以448个服务为例，每次选择5个服务，就有约1.47 × 10¹¹种候选组合。当然，候选组合并不等于有效任务；哪些组合具有实际意义、能够完成，仍要通过任务生成和执行验证来确定。

让强化学习关注尚未完成的要求

有了可执行、可验证的任务，CompoWorld先使用成功轨迹进行监督微调，再在组合环境中进行强化学习。

跨应用任务往往包含多个必须同时满足的条件。模型可能已经找对记录、完成修改，却漏发了一条关键通知。此时，大部分步骤已经完成，用户的目标仍未达成。

只用"全部成功或全部失败"的二元奖励，很难体现部分进展。将验收条件逐项评分，可以提供更细的结果反馈；但如果每项条件始终等权，已经很容易完成的要求又会占据较大比例，使剩余难点不够突出。

为此，团队提出Completion-Focused Rubric Reward，即面向完整任务完成的评分项奖励。它根据同一组采样轨迹的表现，为通过率较低的验收条件分配更高权重。例如，一组轨迹大多能够正确更新记录，却只有少数成功发送通知，那么"通知是否完成"就会获得更高权重。模型依然能因部分完成获得奖励，同时会受到更强的激励，去满足当前尚未稳定完成的要求。这一奖励与GRPO配合使用，权重随新的采样组重新计算。

CompoWorld带来了怎样的提升

团队以Qwen3.6-35B-A3B为基座，使用3K条SFT轨迹和1K个RL任务，在覆盖业务流程、规划、工具使用和长程任务的八项基准上进行评估。

在AutomationBench上，CompoWorld的成功率达到32.33%，较基座提升22.00个百分点。在论文报告的比较中，这一结果高于GPT-5.4的27.67%和Claude Opus 4.6的25.50%，也领先所比较的六个同为35B-A3B规模的Agent专用模型。其中，相比该组表现最好的Occamy-1.0，提升4.73个百分点。

相同数据预算下，组合训练是否更有效？为了考察组合环境本身的作用，团队在相同SFT流程、相同环境数量和1K条训练轨迹的预算下，比较单环境训练与组合环境训练。在四项已完成的比较中，组合环境训练均取得更好结果。其中，AutomationBench从单环境训练的12.83%提升至组合环境训练的33.33%，增加20.50个百分点；τ³-Banking从9.62提升至17.53，增加7.91分。这说明，训练数据中的跨服务依赖和交互结构能够带来额外收益，也支持将"服务如何组合"作为环境扩展的重要方向。

更多组合环境，是否总能带来更高分数？在仅进行SFT的规模实验中，团队比较了100、500、1,000和3,000条训练样本（环境），每条样本对应不同的组合环境。四项基准在仅使用100条样本时就均优于基座，但后续增长并非在所有基准上都单调上升。这也提示，扩大组合数量需要与服务质量、任务选择和验证相配合。

总结和展望

对于通用Agent，现实任务中的难点经常出现在应用交互之间：把一处查到的事实用于另一处操作，在状态变化后重新确认信息，并将多个局部结果汇成完整的任务成果。

CompoWorld为这些能力提供了一条可扩展的训练路径：将服务构建为可复用的交互组件，通过依赖关系生成任务，再用执行验证和面向任务完成的奖励支持学习。随着服务库扩展，同一个服务可以进入更多任务组合，已有组件也能被持续复用。如何选择更有价值的组合、验证更复杂的信息依赖，是这一方向接下来值得推进的问题。