0.6.28a2 版本吞吐缓慢，超参数调优复杂：考虑自动探测后端 API 动态吞吐

[370025263]

Problem

这是某个后端 API 的测试结果：

mode: plain text
不会显示 api_key
 conc   req  http    ok  seconds     rps     p50     p95  errors
   1     6     6     3    28.82    0.21    3.99    7.31  invalid_content:3
   2     6     6     4    17.53    0.34    4.34    6.74  invalid_content:2
   4     8     8     2    18.50    0.43    7.19   11.08  invalid_content:6
   6    12    12     8    13.89    0.86    4.77    7.09  invalid_content:4
   8    16     4     1    31.29    0.51    4.97   31.29  upstream_keys_exhausted:12,invalid_content:3
停止：上游模型组再次报告所有密钥耗尽。

最高通过阶梯: 6
建议生产 max_inflight 起点: 4（通过值的约 75%）

可以看到，该后端在并发提高后会变得很不稳定，AI 脚本建议生产环境最多使用 4 个并发。

幸运的是，XSkill 为 TaskSplitter、ClusterAgent 和 EditAgent 分别提供了 worker 和 weight 参数：

• worker 用于控制能够承接的并发任务数。
• weight 用于控制其获得 LLM 请求的优先级。

AI 最初给出了如下配置：

max_concurrent: 4
agent_worker:
  pools:
    split:
      workers: 4
      llm_weight: 6
    cluster:
      workers: 2
      batch_size: 4
      llm_weight: 3
    edit:
      workers: 1
      llm_weight: 1
    embed:
      workers: 4

但是，上面的配置运行很久后，发现吞吐劣化严重。原因是 Splitter Agent 分配的权重太高，大量轨迹被拆分为轨迹原子；但轨迹原子需要经过 Cluster 后，轨迹才会进入 done。分析后发现，瓶颈位于 Cluster 阶段。

调整为：

max_concurrent: 4
agent_worker:
  pools:
    split:
      workers: 1
      llm_weight: 1
    cluster:
      workers: 4
      batch_size: 6
      llm_weight: 8
    edit:
      workers: 1
      llm_weight: 1
    embed:
      workers: 4

一晚上处理了 200+ 条轨迹，效果很好。

公司内部的 LLM 通常具有以下明显特征：

• 时段性：夜间算力相对充足，并发可以适当调高。
• 低可用性：白天吞吐能力较低，容易频繁出现 429。

XSkill 当前主要依赖手动调参来规避这些问题、提高吞吐并适配公司内部后端的特性。但是，用户不能每天在下班前手动调高并发，也不应该依赖 Agent 或 Cron 工作流每天修改配置。

Proposed solution

考虑引入定期自动探测后端并发能力的功能，由 XSkill 根据探测结果自主调整 max_concurrent 和 agent_worker 内部参数。

Alternatives considered

也可以不在 XSkill 内引入该能力，而是让用户自行使用 Agent/Cron 工作流定期更新配置。