从 Terminal-Bench 种子方案出发，批判性地审视"Skill 图谱 → 采样反推任务 → 轨迹生成 → 训练"的通用数据飞轮思路，提出改进后的研究提案
此前的 Terminal-Bench 数据合成方案以 ClawHub 的 3,000+ Agent Skills 为种子，通过「能力域映射 → 任务生成 → 轨迹合成 → 质量过滤」的管道，为终端 Agent 生成 CPT/SFT/RL 三阶段训练数据。方案结构清晰，核心流程如下：
不局限于终端任务，而是将 Skills 视为一个结构化图谱，通过图采样反推生成覆盖方方面面的任务，然后让 Agent 自然地利用这些 Skills 生成执行轨迹 + 最终结果，这些数据可以用于中训练（CPT/SFT/RL）。
这个思路可以用一句话概括：Skill Graph × Inverse Task Generation × Natural Trajectory Collection → Universal Training Data Flywheel。
这本质上是在问一个很深刻的问题：能不能把 Agent 的能力边界（Skills）当作训练数据的生成函数？
这个思路方向是对的，但从落地角度有几个关键的结构性问题需要解决：
Skills 自带结构信息（输入/输出类型、前置依赖、使用场景），比从互联网随机抓取任务要系统得多。ASTRA（贝壳，2026.01）已验证了"工具图拓扑 → 任务生成"的可行性。
Skill 执行有明确的成功/失败判断（文件是否生成、API 是否返回、测试是否通过），这为 RL 提供了天然的奖励信号，远优于纯 LLM 打分。
如果 Agent 在执行过程中发现新的 Skill 组合，可以反哺图谱 → 生成新任务 → 更多训练数据，形成正循环。Memento-Skills（2026.03）的"让 Agent 设计 Agent"思路验证了这条路径。
从 Skill 图谱采样一组 Skill 节点，反推出"什么真实任务需要这些 Skills"——这本质上是一个逆问题（Inverse Problem）。不是所有 Skill 组合都对应有意义的真实任务。随机的图游走容易产生大量无意义的组合。
例子：随机采样到 {Spotify 播放器, K8s 集群管理, PDF 处理}，很难构造出合理的用户场景。
风险等级：高 需要结构化约束
LLM 生成的合成任务往往不像真人会问的问题。真实用户的任务表述含糊、上下文依赖强、经常省略关键信息。纯从 Skill 组合反推的任务容易过于"教科书化"，导致训练出的模型在面对真实用户输入时泛化能力差。
数据：ToolBench（ICLR'24）的分析表明，合成 query 与真实 query 的分布差异（KL 散度）在 0.3-0.6 之间，这个差距足以导致在真实场景下性能下降 15-25%。
风险等级：高 需要人类偏好注入
现有 Skill 库（如 ClawHub 3,000+ Skills）在某些方向极其密集（DevOps、编程工具），在另一些方向几乎空白（教育、医疗、法律、金融）。直接用 Skill 图谱采样会导致训练数据严重偏向技术运维方向。
ClawHub 分布：DevOps/K8s 类占 ~40%，开发工具占 ~25%，通用工具仅 ~10%，其他领域 <5%。
风险等级：中 可通过合成 Skill 缓解
让 Agent "自然利用 Skills 生成轨迹"听起来优雅，但如果用于生成轨迹的 LLM 本身能力不足，产生的将是低质量甚至有害的轨迹。而如果用最强模型（如 GPT-5/Claude-4）生成，成本极高。
成本估算：每条轨迹平均 8,000 tokens（参考 TermiGen），3,000 任务 × 5 轨迹/任务 = 1.2 亿 tokens。以 GPT-4o 价格计约 $3,600/轮。需要多轮迭代。
风险等级：中 可通过分层策略缓解
原始思路是线性管道（图谱 → 任务 → 轨迹 → 训练），没有从训练效果反哺到数据生成的闭环。如果某类数据对模型提升无效，管道不会自动调整。
风险等级：中 需要增加在线评估反馈
现有的 Agent 评估基准（SWE-bench、Terminal-Bench、GAIA）各自聚焦特定领域。如果目标是"覆盖方方面面的通用 Agent"，目前没有一个评估基准可以全面衡量效果。训练出来的模型"好"在哪里、"好"多少，无从验证。
风险等级：高 需要自建评估体系
在提出改进方案前，先定位相关工作——哪些系统验证了这条路径的哪些子问题：
| 系统/论文 | 核心贡献 | 验证了什么 | 局限 |
|---|---|---|---|
| ASTRA 贝壳, 2026.01 |
工具图拓扑 → 轨迹合成 + 环境合成 → SFT+RL 端到端 | 图结构驱动的任务生成可行 | 仅限工具调用（function calling），非通用 Agent |
| Memento-Skills 2026.03 |
Agent 自主设计 Skill，读写反思学习，无参数持续进化 | Skill 自进化闭环可行 | 推理时学习，未用于训练数据生成 |
| APIGen Salesforce, 2024.06 |
3,673 API → 三层验证 → 60K 函数调用数据 → 7B 超 GPT-4 | 少量高质数据 > 大量低质数据 | 单步函数调用，非多步轨迹 |
| ToolBench OpenBMB, ICLR'24 |
16,464 API → DFSDT 树搜索 → 126K 多步轨迹 | 大规模 API 图谱的训练数据可行 | 合成 query 自然性差，API 不可执行 |
| TermiGen UCSB, 2026 |
420+ CLI → 3,500 Docker 环境 → 纠错轨迹 | 终端领域的纠错轨迹有效 | 仅覆盖终端操作 |
| AgentTrek HKU, 2024.12 |
网络教程 → 引导重放 → GUI Agent 轨迹 | 教程引导的轨迹比自由探索质量高 | 仅限 GUI Agent |
| Synthesize-on-Graph 2025.05 |
知识图谱游走 → 跨文档合成数据 → CPT 数据增强 | 图游走策略可以增强数据多样性 | 面向知识增强，非 Agent 轨迹 |
| Voyager NVIDIA, 2023 |
LLM-powered Skill Library + 自动课程 → 开放世界探索 | Skill 组合 + 课程学习的可行性 | Minecraft 领域特定 |
每个系统都验证了一个子问题，但没有一个系统完整地实现了"Skill 图谱 → 反推任务 → 自然轨迹 → 训练数据飞轮"的完整闭环。ASTRA 最接近，但它的图是工具调用图（function calling DAG），而非通用 Skill 能力图。这恰恰是本提案的机会空间。
针对上述六个薄弱点，我提出 SkillWeave——一个经过结构化改进的通用 Agent 训练数据合成框架。核心改进在三个方面：
不做随机图游走，而是构建语义约束的能力图谱——Skills 之间的边不仅仅是"可组合"，还包含"在什么场景下组合"的语义信息。任务生成时，图游走受场景约束引导。
解决薄弱点 1
引入真实用户查询（从 StackOverflow、GitHub Issues、Slack 日志等）作为"锚点"，合成任务时不是凭空构造，而是围绕真实需求模式做变体生成。
解决薄弱点 2
每轮训练后，在验证集上评估模型，找出薄弱能力维度 → 指导下一轮数据生成倾斜，形成 Data ↔ Model 的闭环而非单向管道。
解决薄弱点 5, 6
| 维度 | Terminal-Bench 种子方案 | SkillWeave（改进版） |
|---|---|---|
| 图谱类型 | Skill → 任务域的平面映射 | 语义能力图（SCG），含场景约束边 |
| 任务生成 | LLM 自由生成 + Evol-Instruct | 真实 Query 锚定 + 约束图游走 |
| 轨迹生成 | 单一强模型 or 多 Agent | 多保真度引擎（弱→中→强分层） |
| 覆盖范围 | 终端操作 | 通用 Agent（终端+浏览器+API+文档+...） |
| 数据流拓扑 | 线性管道 | 带反馈闭环的环形管道 |
| 质量保证 | 执行验证 + LLM 打分 | 四层验证 + 难度标定 + 分布感知采样 |
这是整个框架的基石。与 ASTRA 的工具调用 DAG 不同，SCG 是一个多层异构图：
| 层级 | 节点类型 | 示例 | 数量（估计） |
|---|---|---|---|
| L0: 原子工具 | 单个 CLI/API 调用 | kubectl get pods, git commit | 500+ |
| L1: 基础 Skill | SKILL.md 定义的能力单元 | kubernetes, github, nano-pdf | 3,000+ |
| L2: 组合能力 | 多 Skill 协同的能力模式 | "CI/CD 全链路", "数据管道编排" | ~500 |
| L3: 场景模板 | 真实用户场景的抽象 | "紧急生产故障排查", "项目初始化" | ~200 |
| 边类型 | 语义 | 示例 |
|---|---|---|
DEPENDS_ON | A 执行前必须先完成 B | deploy → build |
ENHANCES | A 可以增强 B 的效果 | monitoring → deployment |
CONFLICTS | A 和 B 不应同时使用 | 两个竞争的包管理器 |
CO_OCCURS | A 和 B 经常一起出现 | Docker + K8s |
REQUIRES_CONTEXT | A 在场景 C 下才与 B 组合 | redis 在"高并发缓存"场景下才与 nginx 组合 |
解析每个 Skill 的依赖声明、工具列表、使用场景描述，构建 L0-L1 层节点和 DEPENDS_ON、ENHANCES 边。
从 GitHub Actions workflows、Terraform modules、Ansible playbooks 等开源配置中，挖掘工具共现模式，构建 CO_OCCURS 边和 L2 组合能力节点。
用 LLM 对高赞问答做场景抽象，构建 L3 场景模板节点和 REQUIRES_CONTEXT 边。这一步引入真实用户意图。
这是对"反推生成任务"思路最关键的改进——不做无约束的反推，而是做有锚点的反推：
从 L3 场景模板出发，沿图谱向下展开到具体 Skills，生成完整的任务描述。保证任务有明确的真实场景根基。
场景: "生产环境数据库迁移"
└→ 展开: {mysql, pg, redis-store, ansible, monitoring}
└→ 任务: "将 MySQL 5.7 在线迁移到 PostgreSQL 15，
保持服务零停机，迁移后验证数据一致性，
并配置 Prometheus 监控迁移进度"从真实用户 query 出发，用 SCG 补全隐含的 Skill 需求，生成扩展版任务。
真实 Query: "我的 K8s pod 一直 OOM" (来自 StackOverflow)
└→ SCG 路径: kube-medic → monitoring → resource-management
└→ 扩展任务: "K8s pod 因内存不足持续重启，
排查 OOM 根因，调整资源限制，
配置 HPA 自动伸缩，验证稳定性"在 SCG 上做受约束的随机游走（只沿有意义的边走），刻意构造跨域组合任务，锻炼模型的组合泛化能力。
约束游走: github → coding-agent → [CO_OCCURS] →
monitoring → [REQUIRES_CONTEXT: "incident response"] →
slack
└→ 任务: "GitHub CI 流水线告警触发后，自动分析
失败的测试日志，生成根因报告，
并通过 Slack 通知值班团队"三种策略按 4:4:2 的比例混合。策略 A 保证场景真实性，策略 B 保证语言自然性，策略 C 保证组合多样性。这比纯随机采样或纯模板化生成都更健壮。
解决"全用强模型太贵、全用弱模型太差"的两难。分三个保真度层级：
| 层级 | 模型 | 用途 | 成本 | 产出占比 |
|---|---|---|---|---|
| Lo-Fi | Qwen2.5-7B / Llama-3-8B | 大规模初筛：生成大量候选轨迹，筛出可执行的 | $0.01/条 | 70% |
| Mid-Fi | Qwen2.5-32B / DeepSeek-R1 | 质量提升：对 Lo-Fi 失败案例做纠错轨迹 | $0.08/条 | 20% |
| Hi-Fi | GPT-4o / Claude-4 | 标杆生成：最难任务的专家轨迹 + 质量验证 | $0.50/条 | 10% |
核心机制：Lo-Fi 的失败轨迹不是废品——它们是 Mid-Fi 纠错轨迹和 RL 负样本的原材料。参考 TermiGen 的纠错轨迹合成思路，但扩展到通用场景。
Lo-Fi: 15,000 × 70% × $0.01 = $105
Mid-Fi: 15,000 × 20% × $0.08 = $240
Hi-Fi: 15,000 × 10% × $0.50 = $750
─────────────────────────────────
Total: ~$1,095/轮（vs 全用 GPT-4o 的 $7,500/轮）
成本降低: ~85%在 Docker/沙箱中实际执行轨迹中的每个命令/API 调用。所有 assertion 必须通过。不通过 = 直接淘汰。
用 LLM 判断：(a) 轨迹是否真正解决了任务？(b) 推理过程是否逻辑自洽？(c) 有没有"碰巧通过测试但方法错误"的情况？
关键创新：用多个不同能力的模型尝试同一任务，根据通过率分布标定任务难度。通过率 >90% 的 → Easy，30-90% → Medium，<30% → Hard。这比人工标注准确且可扩展。
根据 SCG 的能力维度，确保最终数据集在各维度上均衡分布。自动检测并补充稀疏维度的数据。
这是与线性管道的根本区别：
过度倾斜会导致灾难性遗忘——专注补弱项时丢失强项。解决方案：每轮数据中保留 30% 的"回放缓冲区"（固定随机采样），只有 70% 受反馈引导。这借鉴了 RL 中 Experience Replay 的思路。
| # | 创新点 | 解决的问题 | 对比现有最佳 |
|---|---|---|---|
| C1 | 语义能力图（SCG）：4 层异构图 + 5 种语义边 | 随机 Skill 组合无意义 | ASTRA 仅有工具调用 DAG（单层、无语义边） |
| C2 | 锚定式任务生成：三策略混合（场景/Query/组合） | 合成任务不自然 | ToolBench 纯 LLM 生成，无真实锚点 |
| C3 | 多保真度轨迹引擎：弱-中-强分层 + 纠错轨迹 | 成本与质量的权衡 | TermiGen 仅有弱-强两层 |
| C4 | 训练信号反馈闭环 + 分布感知采样 | 线性管道无法自我修正 | 现有方案均为单向管道 |
形式化地说，设 Skill 集合 S = {s₁, ..., sₙ}，任意 k-组合的空间为 C(n,k)。对于 n=3000, k=5，组合空间约 2×10¹⁶。其中有意义的组合远小于 1%。SCG 的语义约束将有效搜索空间压缩 3-4 个数量级，同时保证生成任务的场景合理性。
类比：这就像蛋白质折叠——不是所有氨基酸序列都能折叠成有功能的蛋白质，SCG 就是 Skill 空间的"热力学势能面"。
关键洞察：训练数据的多样性比单条质量更重要（在满足基本质量门槛后）。
DeepSWE（Berkeley, 2025）证明纯 RL 训练中，"模型自发学会边缘案例思考"的前提是见过足够多样的失败模式。
一个简单的数学论证：假设模型在 K 个能力维度上的准确率为 [a₁, ..., aK]，目标是最大化 min(aᵢ)（木桶效应）。线性管道生成的数据分布与能力薄弱点无关，收敛到 min(aᵢ) ≥ τ 需要 O(K²) 轮；有反馈闭环的定向生成只需 O(K) 轮。当 K 很大时（通用 Agent 可能有 50+ 能力维度），这个差距是决定性的。
鉴于没有现成的通用 Agent 基准，我们组合使用以下基准：
| 基准 | 测评能力 | 任务量 | 指标 |
|---|---|---|---|
| Terminal-Bench 2.0 | 终端操作 | 89 | pass@1 |
| SWE-bench Verified | 代码修复 | 500 | resolve rate |
| BFCL-V3-MT | 工具调用 | 多轮 | accuracy |
| GAIA | 通用 Agent | 466 | accuracy |
| τ-bench | 客服/零售 Agent | 多场景 | task success |
| SkillWeave-Bench（自建） | Skill 组合能力 | ~300 | pass@1 + efficiency |
专门测评 Skill 组合泛化能力的基准：
| 实验 | 变量 | 验证假说 |
|---|---|---|
| Ablation A | SCG vs 随机图 vs 无图 | SCG 的语义约束对任务质量的贡献 |
| Ablation B | 锚定生成 vs 自由生成 | 真实 Query 锚定对自然性的贡献 |
| Ablation C | 3 层保真度 vs 全 Lo-Fi vs 全 Hi-Fi | 多保真度的成本效益 |
| Ablation D | 有反馈闭环 vs 无反馈 | 闭环对收敛速度和最终性能的影响 |
| Ablation E | 不同 A:B:C 策略比例 | 最优混合比例探索 |
| 数据类型 | 目标规模 | Token 数 | 训练阶段 |
|---|---|---|---|
| CPT 语料（工具文档+Skill 描述） | - | ~500M tokens | Continual Pre-Training |
| SFT 轨迹（多保真度） | 15,000 条 | ~120M tokens | Supervised Fine-Tuning |
| RL 环境（可验证） | 3,000+ Docker | 按需在线 | Reinforcement Learning |
推荐 Qwen2.5-Coder-32B 或 DeepSeek-R1-32B 作为基座。两者均具备：(1) 足够的代码/推理能力做冷启动；(2) 32B 规模在推理成本和能力之间平衡最优；(3) 开源可控。
| 风险 | 级别 | 影响 | 缓解措施 |
|---|---|---|---|
| SCG 构建质量：边的语义标注不准确 | 高 | 任务质量崩塌 | 人工审核 Top-200 高频边 + 多 LLM 投票标注 + 从真实共现数据反向验证 |
| Skill 覆盖偏倚：DevOps 类占比过高 | 中 | 模型能力偏科 | 分布感知采样 + 虚拟 Skill 合成（用 LLM 为稀疏领域生成 SKILL.md） |
| 反馈闭环过拟合：过度针对评估集优化 | 中 | 泛化能力下降 | 30% 固定随机回放缓冲区 + 定期更新评估集 |
| 成本超支：轨迹生成迭代轮数过多 | 中 | 预算超标 | Lo-Fi 优先 + 严格质量门控减少无效迭代 + 预算上限触发自动停止 |
| 安全风险：合成轨迹含危险操作 | 高 | 模型学会有害行为 | 沙箱隔离 + 危险命令黑名单 + 轨迹级安全审计 |
| 评估偏差：自建基准可能不够代表性 | 中 | 结果不可信 | 主要基准用公开基准，SkillWeave-Bench 作为补充 |
| 阶段 | 时间 | 关键产出 | 里程碑 |
|---|---|---|---|
| P0: SCG 构建 | Week 1-3 | 语义能力图 + 真实 Query 池 | 3,000+ Skill 节点 + 10K+ 边 + 50K 真实 Query |
| P1: 任务生成 | Week 4-6 | 3,000+ 任务 + Docker 环境 | 三策略混合，人工抽检通过率 > 85% |
| P2: 轨迹合成 R1 | Week 7-10 | 15,000 条多保真度轨迹 | 执行验证通过率 > 70%，语义验证 > 60% |
| P3: SFT 训练 | Week 11-12 | SkillWeave-32B-SFT v1 | GAIA > 40%, TB 2.0 > 20%, BFCL > 60% |
| P4: 反馈闭环 R2 | Week 13-15 | 针对性增量数据 + 重训练 | 各基准均有提升，薄弱维度改善 > 10pp |
| P5: RL 训练 | Week 16-18 | SkillWeave-32B-RL v1 | TB 2.0 > 30%, SWE-bench > 40% |
| P6: 论文写作 | Week 19-20 | 完整论文 + 开源 | 投稿 NeurIPS/ICLR |
P0-P2 可部分并行（Query 池收集与 SCG 构建可同步进行）。关键路径：P0 → P1 → P2 → P3 → P4。
"Skill 图谱 → 采样反推任务 → 自然利用 Skill 生成轨迹 → 训练数据"这个大方向是对的。但直接执行会遇到任务自然性、组合爆炸、覆盖偏倚、缺乏闭环四个核心问题。
SkillWeave 框架通过四个关键改进（语义约束图谱 SCG、锚定式任务生成、多保真度轨迹引擎、训练信号反馈闭环）将一个方向性正确但工程上困难的想法，变成一个可落地的研究方案。
每个结构化 Skill（不管是 SKILL.md 还是 API 文档）都是一个潜在的数据生成器。数据团队应该将现有的工具文档、SOP、playbook 视为训练数据的种子，而不仅仅是运维文档。
工具/能力之间的关系比它们各自的描述更有价值。ASTRA 和 ToolBench 都证明了工具图拓扑能显著提升合成数据的结构质量。数据工程师在构建数据管道时，应该优先建立能力依赖图。
APIGen 用 60K 条严格验证的数据训练 7B 模型超过了 GPT-4。关键不是数据量，而是每条数据都能被程序化验证。合成训练数据的核心竞争力不是生成能力，而是验证能力。
"数据飞轮"是一个被过度使用的概念。真正的飞轮需要三个条件：(1) 数据生成过程可自动化；(2) 质量可程序化验证；(3) 训练效果可反馈到生成过程。缺少任何一个，就只是一条管道，不是飞轮。
来自 TermiGen 和 DeepSWE 的共同发现：模型从"失败→诊断→修复→成功"的完整轨迹中学到的，远多于从一步到位的成功轨迹中学到的。这意味着数据采集应该刻意包含失败路径，而不是只保留成功样本。
如果我们能为 Agent 构建出覆盖方方面面的训练数据，本质上我们就是在设计 AI 的"课程体系"。这和 Voyager 在 Minecraft 中的自动课程学习在概念上是同构的——只是从虚拟世界扩展到了真实世界。