外卖这类业务场景里，直接在真实环境训练 Agent 基本行不通。原因就两个：

第一,你真分不清它是蒙对的还是真会了。Agent 成功完成一单外卖退款,是因为推理正确,还是碰巧参数没报错?这种信号没法教它什么是对的。

第二,真实数据又少又贵。靠人工标注喂一个通用 Agent,成本根本扛不住。

所以 Skill-Env 干脆不碰真实环境,自己搭了一套合成训练场。

三层结构

Skill-Env 把训练环境拆成三层,从抽象到具体:

Domain Foundation(领域地基) 规定这个领域有哪些数据、能做什么操作。比如外卖场景要有订单表、商家表、用户表,支持查询订单、创建退款、修改地址这些工具。地基完全由 LLM 根据关键词自动生成,不参考现有业务逻辑,为的是避免被已有代码带偏。

所有数据库逻辑和工具都用 Python 代码实现。写代码不是为了好看,是为了能跑单元测试。每个工具都得过三关:正常输入能跑、边界情况能兜住、胡闹输入能拦下(比如下个"大象"或"核弹"得报错,不能崩)。

Environment(运行环境) 在地基上填充具体数据,生成一批模拟订单和商品名称。到这里环境已经是个能用的 mock 平台了,能实际调工具跑流程。

Task(任务目标) 规定具体要干什么:把订单 A 地址改成 B。验收方式很直接,查数据库那条订单的地址到底改没改对。

怎么保证逻辑能跑通

一堆工具随便拼,类型不对、参数对不上怎么办?Skill-Env 画了一张 PCD 图,把 Parameter(参数)、Tool(工具)、Database(数据库)三样东西用数据流依赖串起来。"创建退款"工具需要的"订单 ID",必须是从"查询订单"工具的输出里来的。

图建好了得验证。系统会随机采样一条路径实际跑一遍,看会不会卡在中间某个环节。还会用一种"先射箭再画靶"的办法:先随机找一条能走通的工具链(比如查用户 -> 选订单 -> 改地址),然后围绕这条线索造数据库初始状态和任务指令。这样任务天然有解,不会出现"环境里根本做不出来"的废题。

评估怎么评

Skill-Env 只用规则评估,不用 LLM 当裁判。不是因为 LLM 评估不好,是因为它不稳定:会有偏见、会幻觉、会被绕过。规则评估就一句话:看数据库最终状态对不对。不管 Agent 中间绕了多远,只要结果对,就算过。

这种确定性信号对强化学习很关键。Agent 试了一百次,对的就反馈对,错的就反馈错,它才能学出靠谱的策略。

不验证的后果

实验发现两件事。

性能确实随合成的领域数量涨。领域越多,Agent 在标准 benchmark 上表现越好,合成环境也遵循 scaling law。

但如果不加验证,盲目堆低质量环境,模型表现反而会变差。垃圾数据喂多了,Agent 不是变聪明,是变糊涂。

验证环节就是把大数据筛成有用数据的网。没有这步,堆再多数据也没用。