shinka-run

Shinka Run CLI 技能

使用 ShinkaEvolve 的 CLI 接口运行一批程序变异。

何时使用

在以下情况下使用此技能：

• evaluate.py 和 initial.<ext> 已存在
• 用户希望使用 ShinkaEvolve/Shinka 库运行代码演化
• 你希望通过明确的 CLI 参数配置程序演化运行

以下情况下不要使用此技能：

• 你需要从头搭建新任务（使用 shinka-setup）

什么是 ShinkaEvolve？

由 SakanaAI 开发的框架，结合大模型与演化算法来提出程序变异，然后对其进行评估并归档。目标是优化性能并发现新颖的科学见解。

仓库和文档：https://github.com/SakanaAI/ShinkaEvolve 论文：https://arxiv.org/abs/2212.04180

工作流

1. 检查任务目录

ls -la <task_dir>

确认 evaluate.py 和 initial.<ext> 存在。

2. 快速查看 CLI 参考

shinka_run --help

3. 提议运行前检查模型是否可用

shinka_models
shinka_models --verbose

根据 shinka_models 验证确切的运行配置：

• 变异模型：evo.llm_models 中的每个条目都必须出现在 llm 列表中。
• 元推荐模型：如果设置了 evo.meta_rec_interval 和 evo.meta_llm_models，则每个元模型都必须出现在 llm 列表中。
• 提示词演化模型：如果 evo.evolve_prompts=true，则在提供 evo.prompt_llm_models 时使用它，否则使用 evo.llm_models；每个选定的模型都必须出现在 llm 列表中。
• 嵌入模型：如果设置了 evo.embedding_model，它必须出现在 embedding 列表中。
• LLM 和嵌入模型可以使用与 OpenAI 兼容的本地模型，格式为 local/<model>@http(s)://host[:port]/v1；这些本地模型无需出现在 shinka_models 中。

重要的运行规则：

• 不要假设元推荐会回退到 evo.llm_models。在当前运行器中，只有明确设置了 evo.meta_llm_models 时才会启用元推荐。
• 如果未设置 evo.prompt_llm_models，提示词演化会回退到 evo.llm_models。
• 将 local/<model>@http(s)://host[:port]/v1 值视为 shinka_models 成员资格检查的明确例外。运行前应另外确认本地端点 URL 和服务状态。
• 如果 shinka_models 中缺少任何必需模型，请停止并询问用户是要更改配置，还是先设置缺失的凭据。

4. 与用户确认首批配置

• 最低限度：预算范围、生成代数、关键覆盖项。
• 根据 shinka_models 检查后，明确确认变异 LLM、元推荐 LLM、提示词演化 LLM 和嵌入模型。
• 如果不明确，请在运行前询问。
• 不要覆盖任何未经确认的参数。

5. 使用明确参数启动主运行

shinka_run \
  --task-dir <task_dir> \
  --results_dir <results_dir> \
  --num_generations 40 \
  --set db.num_islands=3 \
  --set job.time=00:10:00 \
  --set evo.task_sys_msg='<task-specific system message guiding search>'\
  --set evo.llm_models='["gpt-5-mini","gpt-5-nano"]' \
  --set evo.meta_llm_models='["gpt-5-mini"]' \
  --set evo.prompt_llm_models='["gpt-5-mini"]' \
  --set evo.embedding_model='text-embedding-3-small' \
  # Concurrency settings for parallel sampling and evaluation
  --max-evaluation-jobs 2 \
  --max-proposal-jobs 2 \
  --max-db-workers 2

6. 交接前验证输出

ls -la <results_dir>

预期会生成运行日志、代文件夹和 SQLite 数据库等产物。

7. 批次间交接（除非明确要求自主运行）

• 总结已完成批次的结果。
• 再次运行前，询问用户下一批的配置。
• 明确询问：“下一批我们应探索哪些新方向？请提供算法思路、约束条件以及需要避免的失败模式。”
• 将用户反馈转化为修订后的系统提示，并在下一次 shinka_run 调用中通过 --set evo.task_sys_msg=... 传入。
• 如果提示较长或包含多行内容，请将其放入配置文件，并使用 --config-fname，不要在 shell 中转义。
• 除非用户明确要求全新运行或派生分支，否则后续批次沿用相同的 --results_dir。

根据反馈生成的下一批命令示例：

shinka_run \
  --task-dir <task_dir> \
  --results_dir <results_dir> \
  --num_generations 20 \
  --set evo.task_sys_msg='<new system prompt derived from user feedback>' \
  --set db.num_islands=3

批次控制策略（必需）

将一次 shinka_run 调用视为一批程序评估/生成任务。

• 默认模式：批次之间由人工参与。
• 每批结束后，以及开始第一批之前，务必询问用户接下来要运行什么配置（预算、--num_generations、模型/设置覆盖项、并发数、岛屿数、输出路径）。
• 在用户确认下一批配置之前，不得启动下一批。
• 在后续批次中保持 --results_dir 不变，以便 Shinka 重新加载之前的结果。
• 例外：如果用户明确要求完全自主运行，则可以在各批次之间继续运行，无需再次询问。