ASTRA 反转：将 MCP 生态变成中训练数据的持续生产线
受 ASTRA 框架启发，提出从 MCP 注册表中自动采集真实工具交互轨迹，通过沙箱执行验证构建中训练数据，让模型在权重层面学会'工具是怎么被串联使用的'。
触发动机
ASTRA（贝壳，2601.21558）是我迄今见到的最完整的 Agent 轨迹数据自动合成框架——它从 1,585 个 MCP Server 中聚合了 19,036 个工具，自动生成工具链、合成任务、执行 rollout、用规则奖励过滤，最终产出 SFT 数据和可验证的 RL 环境。但 ASTRA 的目标是训练一个工具使用 Agent（后训练阶段），它把轨迹当成 SFT 样本直接学。
我的想法不同：ASTRA 的 pipeline 反转一下，输出的不是 SFT 对话对，而是中训练语料——让模型在 next-token prediction 阶段就见过大量真实工具交互的文本，形成”工具链是怎么组合的""API 之间参数如何流转”的隐式理解。这是一个时序上更早的干预，理论上比在 SFT 阶段才教工具使用更高效。
战略判断：为什么工具交互数据应该前移到中训练
行业信号
-
MCP 生态爆发：2026 年初 Anthropic 发布 MCP 协议后，开源 MCP Server 已超过 5,000 个，覆盖代码、数据库、搜索、文件系统、企业 SaaS 等几乎所有领域。这是一个前所未有的、标准化的工具描述和调用格式语料库。
-
ASTRA 验证了自动化的可行性：贝壳团队证明了从”采集工具 schema → 生成任务 → 执行轨迹 → 验证过滤”这条路可以全自动跑通，32B 模型 SFT+RL 后接近闭源系统。但他们只做了后训练。
-
工具使用能力的瓶颈不在 SFT：当前模型的工具使用弱点不是”不知道怎么调”（SFT 可以教），而是”不理解工具之间的组合语义”——给 10 个工具，模型选了对的 3 个但调用顺序错了，或者不理解 A 的输出要怎么变换才能喂给 B。这种组合理解更适合在预训练/中训练阶段通过大量暴露来建立。
ROI 分析
- 数据源成本极低：MCP Server 是开源的、schema 是标准化的、执行可以沙箱化
- 规模潜力巨大：5,000+ Server × 每 Server 平均 10 条轨迹 = 50,000+ 条中训练语料，按平均 2,000 token/条 = 1 亿 token 量级，且可持续增长
- 独特优势：这些轨迹是真正执行过的（ASTRA 的沙箱验证保证了这一点），不是 LLM 编造的
方法论
核心思路：ASTRA Pipeline → 中训练语料转换器
ASTRA 的输出 本 Proposal 的改造
───────────── ──────────────────────────
SFT 对话对 → 去除对话格式，转为叙事体文档
RL 环境 → 提取环境描述作为"工具生态文档"
轨迹奖励分数 → 作为语料质量过滤信号第一步：工具生态文档化（Tool Ecosystem Documentation）
将每个 MCP Server 的 schema 转化为类似技术文档的中训练语料：
# Weather Service API
## 可用工具
- get_current_weather(location: str, unit: str) → WeatherData
- get_forecast(location: str, days: int) → ForecastData
- get_historical(location: str, date: str) → HistoricalData
## 工具间依赖
- get_forecast 的输出 ForecastData 包含 daily_temps[]，
可直接传入 data_analysis.compute_trend() 进行趋势分析
- get_historical 与 get_current_weather 的输出格式兼容，
可拼接后传入 visualization.plot_timeseries()
## 典型使用场景
用户想了解北京近一周天气趋势：
1. get_forecast("Beijing", 7) → forecast
2. data_analysis.compute_trend(forecast.daily_temps) → trend
3. visualization.plot_timeseries(trend) → chart这种格式让模型在中训练阶段就学会”工具之间怎么组合”，而不是等到 SFT 才第一次见到。
第二步：轨迹叙事化（Trajectory Narrativization）
ASTRA 产出的多轮对话轨迹，转化为叙事体技术文档：
ASTRA 原始输出（对话格式）：
User: 帮我查北京天气并画趋势图
Assistant: [tool_call: get_forecast("Beijing", 7)]
Tool: {"daily_temps": [22, 24, ...]}
Assistant: [tool_call: compute_trend([22, 24, ...])]
...转化后的中训练语料（叙事体）：
为了分析北京近一周的天气趋势，首先调用天气预报接口获取
逐日温度数据。返回的 daily_temps 数组包含 7 个温度值。
接下来将这组数据传入趋势分析工具，该工具使用线性回归
拟合温度变化方向。最后使用时间序列可视化工具将原始数据
和趋势线绘制在同一张图上。
整个过程的关键是数据格式的对齐：天气接口返回的是 JSON
数组，而趋势分析工具需要数值列表输入，两者恰好兼容。
如果格式不匹配，需要先进行类型转换。叙事体保留了工具调用的逻辑链条，但去除了对话格式的”人设”，更适合中训练的 next-token prediction 目标。
第三步：失败轨迹文档化（Failure Trajectory Documentation）
ASTRA 的奖励模型会给每条轨迹打分，低分轨迹通常包含：工具选择错误、参数格式不匹配、调用顺序错误等。这些失败案例转化为”调试文档”：
## 常见错误：参数类型不匹配
在尝试将天气数据传入趋势分析时，一个常见错误是直接
传入完整的 WeatherData 对象而非 daily_temps 数组。
趋势分析工具期望的输入是 List[float]，而 WeatherData
是一个包含多个字段的复合对象。
正确做法：forecast.daily_temps（提取数值数组）
错误做法：forecast（传入完整对象）这类”反模式文档”让模型在中训练阶段就建立”什么是错的”的认知，而非仅学习正确路径。
第四步：质量门控
| 过滤维度 | 方法 | 阈值 |
|---|---|---|
| 执行正确性 | 沙箱执行验证（ASTRA 原生能力） | 必须通过 |
| 轨迹质量 | ASTRA 7 维奖励分数 | ≥ 0.7 |
| 叙事连贯性 | 转化后的文档用 LLM 评分 | ≥ 4/5 |
| 去重 | 工具链签名去重 | 相同工具链序列不超过 3 条 |
规模估算
| 来源 | 规模 |
|---|---|
| MCP Server 数量 | ~5,000（2026 年 4 月） |
| 每 Server 平均可组合工具链 | 5-20 条 |
| 每工具链可生成轨迹变体 | 3-5 条 |
| 总轨迹数 | 75,000 - 500,000 条 |
| 平均 token/条（叙事体） | 1,500 - 3,000 |
| 总量 | 1-15 亿 token |
| 增长率 | MCP 生态月增 ~10%，数据池持续扩大 |
落地路径
- Week 1-2：复用 ASTRA 开源代码，在 100 个 MCP Server 上跑通 pipeline，产出 5,000 条轨迹
- Week 3：构建叙事化转换器，将对话格式转为中训练语料格式
- Week 4：质量评估——抽样 500 条人工检查叙事连贯性和技术准确性
- Week 5-8：规模化——扩展到全部 5,000+ Server，并建立增量更新机制
与已有方案的关系
本 proposal 与站内的 SkillWeave 技能图谱合成 互补：SkillWeave 从技能图谱自上而下设计任务，本方案从真实 MCP 生态自下而上采集轨迹。两者可以组合——SkillWeave 提供任务骨架，ASTRA 反转提供执行肉体。
与 Sandbox 作为数据合成核心资产 理念一致，但更具体：sandbox 是通用概念，本方案明确了”MCP 生态 + ASTRA pipeline”这条具体路径。