协作头脑风暴
brainstorming
在实现前澄清需求、探索设计选择,并形成清晰的开发方向。
cst-runtime-optimization【开发与工程】当用户要求使用 CLI/runtime 执行 CST 参数优化循环、S11 指标迭代、多轮仿真对比时调用此 Skill。本 Skill 依赖 cst-runtime-cli 提供基础设施,不携带 runtime scripts,所有 CLI 调用走 base skill 的 uv run python -m cst_runtime 入口。
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
Phase 0: 准备
task 确认(工程/目标/参数/约束) → inspect-project(含category)
[agent: 选几何参数 → 用户确认 → 翻译为objective spec]
Phase 1: 探针(参数≥4强制)
run-probe-phase --objective <spec>
[agent: 看top_params/edge_hit → 选参数/调范围/定算法]
Phase 2: 优化循环
loop:
run-optimization-step --objective <spec>
[agent: objective达标? → break / ask_study_failed? → 换优化器]
Phase 3: 收尾
generate-report → 灵敏度验证 → 经验→docs/
[agent: 收敛质量判断 + 结论沉淀]
关键决策点:
| 阶段 | 节点 | agent 行动 |
|---|---|---|
| 0 | inspect-project | 筛选 category=geometry 的参数作为候选 |
| 0 | task确认 | 向用户确认5项:工程类型、objective函数、目标阈值、参数列表、几何约束 |
| 1 | run-probe-phase 返回 | main_effects_normalized > 0.1 保留,edge_hit=true 扩范围 |
| 1 | 算法选择 | 参数少+线性=TPE,多+交互复杂=CMA-ES,默认 suggested_algorithm |
| 2 | 每轮返回 | objective_value vs 目标阈值 → 达标break |
| 2 | ask_study_failed | 未达标且 study 认为收敛 → 换优化器(最多一次) |
| 3 | 收尾 | 灵敏度验证 + 经验入库 |
本 Skill 专注 CST 参数优化闭环,依赖 cst-runtime-cli 提供底层基础设施。
scripts/ 或 cst_runtime/ 源码;所有 CLI 调用走 base skill。tasks/task_xxx_slug/runs/run_xxx/{projects,exports,logs,stages,analysis} 结构。本 Skill 不实现 CST 操作,以下工具全部由 cst-runtime-cli 提供。所有 CLI 调用通过工作区的 -m cst_runtime 入口执行。
| 职责 | CLI 工具 |
|---|---|
| run 创建 | prepare-run、get-run-context |
| 审计 | record-stage、update-status |
| 进程/session | cst-session-open、cst-session-close、cst-session-quit |
| 参数 | list-parameters、change-parameter |
| 仿真 | start-simulation-async、wait-simulation |
| 结果导出 | export-run-results(统一导出 S11+2D+远场) |
| 结果显示 | generate-report(生成综合报告) |
| 探针阶段 | run-probe-phase(一键探针:设计→仿真→分析→注入 study) |
| 优化迭代 | run-optimization-step(一步迭代:ask→改参→仿真→tell,agent 判断早停) |
| Objective 函数 | 内置在管道中 — s11_min_db, s11_at_freq, gain_max, bandwidth, expression |
优化目标不再硬编码为 S11 min dB。通过在管道工具中传入 --objective <spec> 指定目标函数:
| 类型 | 格式 | 示例场景 |
|---|---|---|
| S11 全局最小值 | {"type": "s11_min_db"} | 默认,最小化反射 |
| 指定频率 S11 | {"type": "s11_at_freq", "freq": 2.4} | 2.4GHz 阻抗匹配 |
| 最大增益 | {"type": "gain_max", "port": 1} | 优化天线增益 |
| 带宽 | {"type": "bandwidth", "below_db": -10} | S11<-10dB 带宽最大化 |
| 自定义表达式 | {"type": "expression", "expr": "min(s11_db)"} | 灵活组合 |
objective 默认方向:s11 类为最小化,gain/bandwidth 类为最大化。可通过 direction 覆盖。
两个管道(run-probe-phase、run-optimization-step)均接受 objective 参数。省略时默认 {"type": "s11_min_db"},与旧行为完全一致。
使用本 Skill:
不使用本 Skill:
cst-runtime-cli)导出文件统一放到 exports/,固定命名:
exports/
s11_run{N}.json ← {N}=CST run_id,无时间戳
farfield/{freq}_port{port}_run{N}_{quantity}.json ← 每轮独立
result_2d_*.json
report.html ← generate-report 输出
所有优化迭代走统一模式:
┌─ agent 循环 ──────────────────────────────────────────────┐
│ run-optimization-step --objective <spec> │
│ → objective_value, study_best, steps_since_improvement │
│ → 达标? → break / ask_study_failed? → switch sampler │
│ → 未达标 → 继续循环 │
└───────────────────────────────────────────────────────────┘
run-probe-phase和run-optimization-step是自包含管道,各自管理完整的 session 生命周期。详见describe-pipeline。如需在标准流程中插入自定义步骤(如改参后验证实体),可回退到原子工具(
prepare-experiment+run-experiment+ask-study+tell-study等)。
适合仅需简单改参仿真对比、不建 study 的场景:
┌─ 每轮迭代 ──────────────────────────────────────────────────────┐
│ prepare-experiment ← 修改参数(支持 names+values 批量改参) │
│ → run-experiment ← 仿真 + 自动导出 S11 + 远场 │
│ → agent 看 objective_value → 早停判断 │
│ → 达标 break / 未达标继续下一轮 │
└─────────────────────────────────────────────────────────────────┘
prepare-experiment和run-experiment是自包含管道,各自管理完整的 session 生命周期。
┌─ 每轮迭代 ─────────────────────────────────────────┐
│ cst-session-open │
│ → change-parameter → save-project │
│ → start-simulation-async → wait-simulation │
│ → cst-session-close --save false │
│ → export-run-results │
│ → 早停判断 → 达标 break / 未达标继续下一轮 │
└────────────────────────────────────────────────────┘
适合改变几何实体或需要完全独立数据。每轮独立 run_00N 目录。
prepare-run(run_00N) → prepare-experiment
→ run-experiment
# 先用 args-template 生成参数,再调用
uv run python -m cst_runtime args-template --tool generate-report
# 编辑模板中的 data_dir、output_html、modules 字段
uv run python -m cst_runtime generate-report --args-file <模板.json>
modules 默认 s11,farfield3d,timeline,可选 metrics,optimization。
generate-report 自动读取 exports/ 下的全部 s11_run*.json 和 farfield/*.json,渲染 S11 曲线、3D 远场、参数变更记录和操作审计。
3D 远场仪表板:使用 WebGL Canvas 渲染,支持鼠标拖拽旋转、滚轮缩放、自动旋转。页面自包含(无 CDN 依赖),可作为独立 HTML 文件离线查看。
早停判断 是本 Skill 区别于照单执行的关键红线。其他通用红线(session 分离、S11 复数处理、远场增益证据约束等)见
cst-runtime-cliSKILL.md。
仿真 → 读结果 → 计算 objective → 判断是否达目标 → 达则 break,不达则继续overruninspect-project(而非 list-parameters)一次性获取全部参数名、值、中文描述。避免逐一 describe-tool 查每个参数。run-probe-phase),筛选关键参数后再进入正式优化循环。跳过探针直接进入正式优化的,任务输出必须标记为 probes_skipped,由此产生的浪费轮次计入 agent 成本。agent 不得为优化循环编写独立 Python 脚本(如 optimize_loop.py、run_optimization.py 等)。
所有优化迭代必须使用现有管道工具(run-probe-phase + run-optimization-step,或降级到 prepare-experiment + run-experiment)或原子工具的 CLI 原生编排。脚本层无法正确处理:
任何偏离管道工具的自定义脚本均视为违规,由此产生的浪费(仿真轮次、时间、结果丢失)由 agent 承担。
run 目录(runs/run_xxx/)是不可逆数据容器。禁止:
exports/ 下的历史导出文件.cst 替换 projects/working.cst——这会丢失所有历史 run_id 和结果当需要干净工程状态(如清除 CST 内部缓存、重置仿真历史)时,必须:
prepare-run → 创建新 run_00N 目录
→ 从源工程拷贝到新 run 的 projects/
→ 新旧 run 各自保留完整数据
这样旧 run_00N-1/ 的 exports/ 和 project 历史保持完整,新 run_00N/ 从零开始,互不干扰。
| 问题 | 原因 | 恢复方式 |
|---|---|---|
| 端口非均匀填充 | 修改 g(脊间距) 导致端口区域出现多种材料 | cst-session-close --save false 丢弃改参,恢复原值 |
| 部分仿真未重跑 | CST 检测到网格未改变时可能返回缓存结果 | run-experiment 内置 run_id 预检对比,输出 warning 字段 |
| 远场导后保存 | 远场导出使 CST 进入错误状态 | close(save=False) 自动处理;不要额外调用 save |
目的: 确保 agent 和用户对优化目标一致理解。
prepare-run → get-run-contextinspect-project → 返回全参数(含 category)category=geometry 的参数作为候选,列出给用户objective 参数格式引导规则:
优化目标必须向用户确认后才能进入探针阶段。参数选择以
category=geometry为主。 用户描述的目标由 agent 翻译为 objective spec。无明确目标时默认最小化 objective。
uv run python -m cst_runtime run-probe-phase \
--project-path <run>\projects\working.cst \
--parameters '{"R":{"min":0.1,"max":0.5},"g":{"min":20,"max":30}}' \
--study-storage <run>\studies\optimization.db \
--study-name horn_matching \
--objective '{"type":"s11_min_db"}'
run-probe-phase 自动完成:
working.cst → working_probe.cst(基线隔离)objective 函数计算值exports/probe/返回: main_effects、interactions、top_params、edge_hit、suggested_algorithm
agent 决策:
| 决策 | 信号 | 规则 |
|---|---|---|
| 选参数 | main_effects_normalized | > 0.1 保留,< 0.05 固定为中心值 |
| 调范围 | edge_hit | true → 扩范围或提示用户 |
| 选算法 | suggested_algorithm | TPE(默认)/ CMA-ES(多参数+强交互) |
uv run python -m cst_runtime run-optimization-step \
--project-path <run>\projects\working.cst \
--study-storage <run>\studies\optimization.db \
--study-name horn_matching \
--objective '{"type":"s11_min_db"}'
run-optimization-step 自动完成:
--sampler)ask-study — Optuna 采样prepare-experiment — 改参 + 保存run-experiment — 仿真 + 导出objective 函数计算值tell-study — 回报结果返回: objective_value、study_best、steps_since_improvement
agent 早停判断:
每轮返回后:
1. objective_value < target? → break ✓
2. ask_study_failed 且未达标且未换过优化器? → --sampler cma-es 切换
3. 否则继续循环
切换优化器: 加 --sampler cma-es 或 --sampler random。pipe 内部重建 study + 迁移历史 trial。
generate-reportstudy_best 在边界?相比 probe mean_value 有改善?objective 函数评估docs/opt-exp-*.md引导规则:
灵敏度验证使用与优化阶段相同的
objective函数。经验入库是验收项,缺少 docs/ 记录的任务标记为incomplete_docs。
每次优化任务完成后,必须提炼可复用的泛用经验,写入工作区根目录的 docs/ 目录。
满足以下任一条件即需总结:
文件命名:docs/opt-exp-{YYYY-MM-DD}-{简短主题}.md
内容结构:
# 经验:{标题}
## 场景
- 工程类型:
- 参数集:
- 优化目标:
## 发现
{具体现象、数据、对比结果}
## 根因
{分析结论,区分 CST 行为 vs 物理规律 vs 工具限制}
## 泛用规则
{可迁移到其他工程的经验,1-3 条}
## 验证状态
- [ ] 单次验证 / [ ] 多次验证 / [ ] 跨工程验证
工作区根目录 docs/ 下,按主题分类:
docs/opt-exp-*.md — 优化经验docs/cst-traps-*.md — CST 陷阱docs/pipeline-patterns-*.md — 管道编排模式exports/ 数据或 stages/ 记录支撑docs/ 是否已有同类经验,有则追加而非新建以下通用规则详见 cst-runtime-cli SKILL.md:
.cst_runtime/tmp/)、project_path 约束prepare-experiment/run-experiment/inspect-project 各自管理 session,无需前置 cst-session-openworkspace_not_initialized、source_project_missing、ambiguous_open_projects、lock_not_released、Access is deniedcst-session-management-gate 管道、硬性停止条件close(save=False) 规则exports/ 下有导出文件(s11_run{N}.json 等)status.json 状态正确.lok 锁文件logs/tool_calls.jsonl 和 stages/ 可追溯run-probe-phase 或 design-probes + analyze-probes + study-add-trials)top_params)已记录到 stages/