资讯动态

Freerouting Autopilot 循环实战指南:用 LLM Agent 驱动路由引擎的自我改进实验体系

发布时间:2026/10/15 2:24:32 来源:尧图企业网站定制
硬件开发桌面应用【免费下载链接】freeroutingAdvanced PCB auto-router项目地址https://gitcode.com/gh_mirrors/fr/freerouting点击查看免费下载Freeroutinggh_mirrors/fr/freerouting在scripts/autopilot/目录下维护了一套完整的autopilot自动驾驶实验循环任何 LLM 编程 Agent 都可以按照scripts/autopilot/LOOP.md定义的作业手册以提出假设 → 实现 → 门禁校验 → 评估 → 收尾的标准化流程对 PCB 自动布线算法进行可度量、可回溯的自我改进。本文以该文档为骨架结合仓库内 PowerShell 脚本、评分器与基准测试基础设施的源码实现完整讲解这套循环的硬性规则、五步生命周期、G0–G3 门禁矩阵、字典序评估目标、预算约束、奇偶parity调试与故障处置方案。读完本文你将能够独立创建并跑通一个 autopilot 实验并理解每个门禁背后的判定逻辑。一、Autopilot 是什么一套给 Agent 的算法改进作业手册LOOP.md开宗明义它定义的是任何 LLM 编码 Agent 如何运行 Freerouting 自改进布线优化循环的作业规范。与普通的 CI/CD 不同这套循环面向路由算法本身的持续优化——Agent 提出布线改进假设实现代码或修改RouterSettings配置然后经过一套由门禁Gates与字典序目标构成的自动裁判体系决定实验被接受还是拒绝。这套体系的技术底座在仓库中清晰可循实验编排脚本scripts/autopilot/New-Experiment.ps1、Invoke-Gates.ps1、Invoke-Evaluation.ps1、Close-Experiment.ps1、Start-NightlyLoop.ps1评分器scripts/autopilot/score_experiment.pyPython 版判定器PowerShell 版Invoke-Evaluation.ps1会优先调用它基准数据scripts/benchmark/baselines/baseline-manifest.json基线清单、scripts/benchmark/baselines/noise_floor.json噪声底基准运行器scripts/benchmark/run-benchmarks.ps1及其lib/模块化库。整个循环的设计哲学是路由算法改动必须先测量、后保留——这正是 AGENTS.md 中Measure Every Routing Change原则的工程化落地。任何改动都必须在同一批板上、用相同设置与相同 worker 数做前后对比记录未布线数、间距违规数、CPU/墙钟时间等精确指标只有测量结果能证明改进时才能保留。二、硬性规则Agent 与 CI 都必须遵守的红线LOOP.md列出了六条从 AGENTS.md 继承的硬性规则它们是整个循环的安全护栏规则含义仓库依据永不放宽 ArchUnit 严格规则不得放松ModuleBoundariesArchTest或SpecctraPackageArchTest中的任何约束测试文件位于src/test/java/app/freerouting/architecture/ModuleBoundariesArchTest.java另一份为src/test/java/app/freerouting/io/SpecctraPackageArchTest.javaAGENTS.md 明确Keep every rule green; do not relax strict rules to hide regressions相对基线零新增间距违规硬拒绝任何实验不得引入新的 clearance violations见下文字典序目标第 1 条不自动运行spotlessApply改用spotlessCheck因为spotlessApply会格式化所有 Java 源码产生数百处无关变更AGENTS.mdDo not runspotlessApplyas an automatic cleanup step不自动暂存/提交除非Close-Experiment.ps1 -Accept成功实验收尾必须走脚本化流程Close-Experiment.ps1内部在git add -A后检查git diff --cached --quiet才提交基线为 v2.5.0以baseline-manifest.json声明为准见scripts/benchmark/baselines/baseline-manifest.json的release_baseline.version 2.5.0违规计数必须用DesignRulesChecker.getAllClearanceViolations()不能只看不完整的 outline 计数完整 DRC 入口方法定义于src/main/java/app/freerouting/drc/DesignRulesChecker.java第 59 行的public CollectionClearanceViolation getAllClearanceViolations()它遍历全部板件对full pair iteration最后一条尤其关键BoardStatistics.clearanceViolations.totalCount之所以权威正是因为它由getAllClearanceViolations()计算而来见src/main/java/app/freerouting/core/scoring/BoardStatistics.java的引用。评测与调试若用不完整的统计捷径会得出错误的违规结论。三、五步生命周期从假设到合并/拒绝LOOP.md定义了五个标准化步骤。下面结合各脚本源码逐一展开。步骤 1New-Experiment.ps1 -Hypothesis ...— 创建工作区与实验目录命令形式.\scripts\autopilot\New-Experiment.ps1 -Hypothesis 加速 fanout 阶段 SMD 引脚排序该脚本scripts/autopilot/New-Experiment.ps1的默认行为实验目录experiments/id/id由脚本生成目录名唯一Git 工作树.worktrees/id分支experiment/id基于autopilot/main分支可传-BaseBranch覆盖生成三份初始化文件hypothesis.md记录假设原文、分支与工作树位置、状态pendingmeta.json机器可读的元数据experiment_id、branch、worktree、hypothesis、status pending、created_atverdict.json预置{accept: false, reasons: []}等待评估阶段填充。隔离性是第一原则实验代码绝不在master上直接改而是全部落在独立工作树中保证基线可复现。步骤 2实现假设代码与/或RouterSettings变更Agent 在.worktrees/id中实现假设。可以是修改路由算法源码例如src/main/java/app/freerouting/autoroute/、board/、geometry/、drc/、core/、rules/等核心包调整RouterSettings配置字段参数遵循 AGENTS.md 规定的snake_case与点号嵌套格式如--router.plane_as_obstacletrue、--router.plane_via_costs50两者兼有。步骤 3Invoke-Gates.ps1 -ExperimentId id— 跑门禁.\scripts\autopilot\Invoke-Gates.ps1 -ExperimentId id脚本scripts/autopilot/Invoke-Gates.ps1按 G0 → G1 → G2 →可选 G3顺序执行每步失败立即退出并写gates.log。细节见下一节门禁矩阵。步骤 4Invoke-Evaluation.ps1 -ExperimentId id— 与基线对比产出verdict.json评估脚本scripts/autopilot/Invoke-Evaluation.ps1优先调用 Python 评分器scripts/autopilot/score_experiment.py传参python .\scripts\autopilot\score_experiment.py --candidate g1|g2-results/benchmarks.json --baseline scripts/benchmark/results/benchmarks.json --noise scripts/benchmark/baselines/noise_floor.json --out experiments/id/verdict.json --experiment-id id从源码看评分器score_experiment.py的核心逻辑是逐 fixture 对比取候选运行中每个 fixture 的最新一次运行按run_at排序取最新读取基线库中同一 fixture 的运行记录计算三个 deltaviolations_delta、unrouted_delta、score_delta判定两条硬性拒绝条件c_viol b_viol→REJECTviolations increased(c_unr - b_unr) noise_band→REJECTunrouted regressionnoise_band默认 2.0若noise_floor.json中该 fixture 的unrouted_stddev 0则取max(2.0, 2 * stddev)全部通过则输出ACCEPT: no hard gate violations detected进程退出码 0否则退出码 1。步骤 5Close-Experiment.ps1 -ExperimentId id -Accept | -Reject— 收尾收尾脚本scripts/autopilot/Close-Experiment.ps1要求必须且只能指定-Accept或-Reject之一同时指定会报错。Reject 分支删除工作树git worktree remove --force、删除分支git branch -D、把meta.json状态置为rejected、向台账experiments/experiments.jsonl追加一条 verdict 为reject的记录。Accept 分支更复杂前置条件是verdict.json的accept必须为true在工作树中git add -A并提交autopilot: accept experiment id切到autopilot/main并执行git merge --ff-only快进合并失败则报错要求人工解决重新构建executableJar把新 JAR 复制为scripts/benchmark/binaries/freerouting-current.jar更新baseline-manifest.json的git_sha与created_at——被接受的实验会立即成为新基线这正是自我改进闭环的核心删除工作树与分支状态置为accepted台账追加 accept 记录含git_sha与 reasons向experiments/REPORT.md追加该实验的条目Git SHA、假设文件位置、接受理由。注意硬性规则不得自动暂存/提交的例外正是此脚本内的git add -A 受控提交——这是唯一合法的自动提交路径。四、门禁矩阵G0 到 G3 的通过标准LOOP.md用表格给出了四级门禁Invoke-Gates.ps1给出了实现细节门禁命令通过标准实现要点源码G0gradlew.bat testexecutableJar全部 fast tests 通过、ArchUnit 通过脚本以--no-daemon运行并Tee-Object记录到g0-test.log/g0-build.log失败即exit 1。构建产物复制为scripts/benchmark/binaries/freerouting-current.jar供后续门禁使用G1金丝雀canaryfixtures ×3 次无违规回退未布线数在 2× 噪声底以内脚本内硬编码金丝雀清单DAC2020_bm02.dsn、DAC2020_bm07.dsn、DAC2020_bm08.dsn、ecc83-pp.dsn对每个调用run-benchmarks.ps1参数-MaxPasses 20 -MaxTime 00:10:00 -RunsPerConfig $G1Runs默认 3G2全量 24-fixture 基准相对基线的字典序目标调用run-benchmarks.ps1不加-FilterFixture即全量结果写入g2-results/。可通过-SkipG2跳过G3PCBench 子集可选KiCad DRC 布线指标 vs 真实标注ground truth仅当传-IncludeG3时执行调用scripts/pcbench/Run-PCBenchGate.ps1脚本不存在时记录SKIPPEDG1 与 G2 的判定都依赖scripts/benchmark/run-benchmarks.ps1输出的benchmarks.jsonschema v5包含fixture、binary、quality、drc、phases、bounds、samples等完整记录。其中quality.clearance_violations与drc.final_violations是违规判定读取的字段quality.final_unrouted/drc.final_unrouted是未布线判定读取的字段。G3 的细节可以看scripts/pcbench/Run-PCBenchGate.ps1默认跑 Tier A 的最多 20 块板-MaxBoards可调每块板调用基准脚本并解析最新运行结果Tier A 金丝雀板只要出现 unrouted 0、violations 0 或超时就判定门禁失败并列出失败板名单。五、字典序目标五级指标的裁决顺序LOOP.md明确了评估的字典序目标lexicographic objective并注明在配置了的地方取 n≥3 的中位数median of n≥3 where configured——run-benchmarks.ps1的-RunsPerConfig支持多次采样多采样时对final_unrouted、final_violations、final_score取中位数Get-MedianValue函数实现Clearance violations —— 零新增硬拒绝优先级最高任何新增违规一票否决Unrouted —— 不劣于噪声带未布线数相对基线回退超过噪声带即拒绝Normalized score —— 越高越好路由完成度与合法性综合分即 router score0–1000 制见 docs/scoring.mdgetNormalizedScore()是其废弃别名CPU time —— 越低越好Peak heap —— 越低越好。关键兜底规则即使平均值改善只要单个 fixture 的回退超过 2× 噪声底就整体拒绝。这防止平均分上涨但个别板严重劣化的作弊式改进被接受。其中噪声底noise floor由scripts/benchmark/measure-noise-floor.ps1生成它对 6 个金丝雀 fixtureDAC2020_bm02/bm07/bm08、ecc83-pp.dsn、sonde xilinx.dsn、DAC2020_bm01.dsn各跑默认 5 次-RunsPerFixture可调计算score_stddev、unrouted_stddev、violations_stddev、time_stddev_seconds及各指标中位数写入scripts/benchmark/baselines/noise_floor.json。基线清单scripts/benchmark/baselines/baseline-manifest.json的关键字段{ schema_version: 1, description: Frozen baseline for autopilot accept/reject comparisons. Regenerated when an experiment is accepted on autopilot/main., git_sha: unknown, jar_path: scripts/benchmark/binaries/freerouting-current.jar, benchmarks_json: scripts/benchmark/results/benchmarks.json, noise_floor_json: scripts/benchmark/baselines/noise_floor.json, release_baseline: { version: 2.5.0, git_tag: v2.5.0, jar_path: scripts/benchmark/binaries/freerouting-2.5.0.jar, canonical_log: freerouting-v250.log } }可以看到比对用的候选结果来自实验目录的g1-results/benchmarks.json或g2-results/benchmarks.jsonInvoke-Evaluation.ps1优先 G2、回退 G1而基线则由release_baseline指向冻结的 v2.5.0 版本与每次接受实验后刷新的freerouting-current.jar共同定义。六、预算与资源约束LOOP.md规定了三条预算纪律预算项默认值说明单个实验墙钟上限4 小时可通过-MaxWallClockHours配置每夜nightly run最多实验数3 个见Start-NightlyLoop.ps1的-MaxExperiments 3大板500 nets使用fixtures/metadata.yaml的-MaxItems防止超长 pass 拖垮门禁scripts/benchmark/fixtures/metadata.yaml为每个 fixture 声明了size_class、layers、nets、timeout_budget与tags。其中大板tags: [large]都配置了max_items切片参数例如KiCad_10_demos/vme-wren.dsn1800 nets12 层max_items: 100KiCad_10_demos/video.dsn588 nets4 层max_items: 200KiCad_10_demos/CM5_MINIMA_3.dsn220 nets6 层max_items: 100。这条纪律与 AGENTS.md 中大型 CI 板测试的要求一致通过setMaxItems(n)如 100–200切出有界的工作块让单 pass 在 30 秒内跑完不要只依赖短的jobTimeoutString——超时要在 pass 完成后才触发单个慢 pass 仍会击穿预算。夜间循环的调度逻辑在scripts/autopilot/Start-NightlyLoop.ps1中拉取autopilot/main→ 扫描experiments/下所有meta.json状态为pending的实验 → 依次执行门禁 → 评估 → 收尾Accept/Reject最多处理-MaxExperiments个全部结束后若台账中已累计 ≥3 个 accepted 实验会输出PROMOTION提示建议以gh pr create --base master --head autopilot/main向上游提交 PR。七、禁止行为防作弊清单LOOP.md明确列出四种绝对禁止的操作其目的都是防止用牺牲真实质量的方式刷绿指标禁用 fanout/router/DRC 来刷指标Disabling fanout/router/DRC to game metrics——关闭功能让指标好看属于作弊放松测试断言强行变绿Relaxing test assertions to force green直接提交到masterCommitting directly tomaster——必须走autopilot/main与实验分支把spotlessApply当清理工具运行RunningspotlessApplyas cleanup——会制造大量无关变更。这些约束与硬性规则互为表里G0 的 ArchUnit 红线防止架构边界被悄悄放宽评估器的硬拒绝条款防止质量指标被操纵。八、奇偶Parity调试行为分歧的定位流程当 G1/G2 失败且怀疑是行为分歧behavioral divergence而非简单数值漂移时LOOP.md给出两条调试命令./scripts/tests/compare-versions.ps1 -de fixtures/Issue508-DAC2020_bm01.dsn ./scripts/tests/raw-section-mismatch.ps1第一条命令scripts/tests/compare-versions.ps1是WIP vs 基线的对比运行器用完全相同参数--router.fanout.enabledtrue、--router.optimizer.enabled...、--gui.enabledfalse、--api_server.enabledfalse、--debug.enable_detailed_loggingtrue、--router.job_timeout...、--router.max_threads...、--logging.file.levelTRACE等分别运行当前构建build/libs/freerouting-current-executable.jar与基线 JAR默认从baseline-manifest.json解析 v2.5.0解析各自日志中的 AutoRouter 时长、未布线数、峰值堆与 pass 数最后给出对比摘要。常用辅助参数包括-DebugFilterByNet Net-(C7-Pad2)按网表过滤 TRACE 日志、-max_passes、-max_items、-LogNameSuffix。第二条命令scripts/tests/raw-section-mismatch.ps1定位第一个有意义的不匹配点它从logs/freerouting-current.log与logs/freerouting-v250.log中抽取所有RAW_SECTION (assign|skip)记录将expansion_value与sorting_value这两类易波动数值替换为*然后逐条对齐比较输出FIRST_RAW_MISMATCH_STREAM_INDEX、当前/基线的不匹配行及其前后 ±10~15 行上下文以及两侧 RAW 记录总数写入logs/raw-mismatch-latest.txt。这与 AGENTS.md 的奇偶调查方法论一致先把 WIP 与基线两边的诊断载荷例如[assign_raw]的 section/door 身份字段同步一致再围绕第一个归一化不匹配点以 section、door、from_door、net 等稳定标识做 diff然后施加尽可能小的排序/打破平局tie-break修复重跑确认不匹配点后移或消失且不引入违规。九、失败分类三类典型故障的处置预案LOOP.md对三类典型失败给出了明确预案大 fixture 上的 OOM把 fixture 集减半或按metadata.yaml应用max_items后重试。这与 AGENTS.md 中的 OOM 压力测试模式一致——不可在 CI 时间窗内约束的全规模 OOM/压力测试应放入scripts/tests/作为独立 PowerShell 脚本参考模式见scripts/tests/run_test_Issue420_oom.ps1构建可执行 JAR 后以-XX:HeapDumpOnOutOfMemoryError无头运行并用后台采样器每 30 秒记录 JVM working-set最后输出内存趋势与 pass/fail 摘要。反复出现 G0 失败停止夜间循环并在 GitHub 提交 issue。这是宁停勿劣原则——持续红灯说明工作树状态已不可信不应继续消耗预算。PCBench 转换失败记录日志并跳过该板不要让整个语料导入失败。这与Run-PCBenchGate.ps1中catalog.json 缺失时先跑Convert-PCBenchBoards.ps1再继续的容错设计相呼应。十、PCBench 与 KiCad 环境依赖G3 门禁与地面真值对比依赖两个外部环境LOOP.md给出了默认路径与可覆盖的环境变量组件默认路径覆盖环境变量PCBench 语料克隆C:\Work\PCBenchFREEROUTING_PCBENCHKiCad 10 CLIC:\Program Files\KiCad\10.0\bin\kicad-cli.exeFREEROUTING_KICAD_CLIPCBench 相关工具链位于scripts/pcbench/Fetch-PCBench.ps1、Convert-PCBenchBoards.ps1把kicad_pcb转成 DSN、Run-PCBenchCorpusBenchmark.ps1等转换后的板子以PCBench/board_id/unrouted.dsn形式存放于scripts/benchmark/fixtures/PCBench/。G3 门禁对 Tier A 板要求unrouted 0 且 violations 0 且不超时即用 KiCad 的 DRC 与布线指标对照真实标注ground truth验证。十一、关键文件清单速查LOOP.md最后一节给出了循环涉及的核心文件整理如下均为仓库根目录相对路径文件作用scripts/benchmark/baselines/baseline-manifest.json冻结基线清单声明 v2.5.0 发布基线、当前 JAR 路径与基准结果 JSON 路径实验被接受后自动刷新git_shascripts/benchmark/baselines/noise_floor.json每个 fixture 的测量噪声stddev由measure-noise-floor.ps1生成评估器用它计算 2× 噪声带experiments/experiments.jsonl实验台账每次收尾accept/reject追加一条 JSON 记录含 ts、experiment_id、verdict、git_sha、reasonsexperiments/REPORT.md实验报告被接受实验的追加式摘要Git SHA、假设位置、接受理由此外支撑这套循环的其余关键文件还包括编排脚本scripts/autopilot/New-Experiment.ps1、scripts/autopilot/Invoke-Gates.ps1、scripts/autopilot/Invoke-Evaluation.ps1、scripts/autopilot/Close-Experiment.ps1、scripts/autopilot/Start-NightlyLoop.ps1评分器scripts/autopilot/score_experiment.pyPython 版字典序判定Invoke-Evaluation.ps1优先调用基准运行器scripts/benchmark/run-benchmarks.ps1产出 schema v5 的benchmarks.json、scripts/benchmark/measure-noise-floor.ps1fixture 元数据scripts/benchmark/fixtures/metadata.yaml金丝雀清单、噪声底清单、大板max_items调试工具scripts/tests/compare-versions.ps1、scripts/tests/raw-section-mismatch.ps1PCBench 门禁scripts/pcbench/Run-PCBenchGate.ps1权威 DRC 入口src/main/java/app/freerouting/drc/DesignRulesChecker.javagetAllClearanceViolations()第 59 行起架构约束测试src/test/java/app/freerouting/architecture/ModuleBoundariesArchTest.javaG0 红线严禁放宽评分体系说明docs/scoring.mdrouter score 与 optimizer score 的完整公式与权重默认值。十二、快速上手跑通一个实验的最小路径综合以上内容一个完整的 autopilot 实验最小操作序列如下Windows 环境PowerShell# 1. 创建实验生成独立工作树与实验目录 .\scripts\autopilot\New-Experiment.ps1 -Hypothesis 你的改进假设 # 2. 在 .worktrees/id 中实现假设改代码或 RouterSettings # 3. 跑门禁G0 → G1 → G2可选 -IncludeG3 追加 PCBench 门禁 .\scripts\autopilot\Invoke-Gates.ps1 -ExperimentId id # 4. 评估与基线对比生成 verdict.json .\scripts\autopilot\Invoke-Evaluation.ps1 -ExperimentId id # 5. 收尾接受合并进 autopilot/main 并刷新基线或拒绝 .\scripts\autopilot\Close-Experiment.ps1 -ExperimentId id -Accept # 或 .\scripts\autopilot\Close-Experiment.ps1 -ExperimentId id -Reject夜间的全自动编排则只需.\scripts\autopilot\Start-NightlyLoop.ps1它会自动处理所有pending实验每夜最多 3 个并给出晋升PROMOTION提示。整个体系的核心在于任何改进都必须通过零新增违规 未布线不劣于噪声带的硬性检验并被可复现的基线数据记录在案——这正是 Freerouting 路由引擎能够在不牺牲设计规则安全性的前提下持续演进的工程保障。赞分享硬件开发桌面应用【免费下载链接】freeroutingAdvanced PCB auto-router项目地址https://gitcode.com/gh_mirrors/fr/freerouting点击查看免费下载相关推荐Evolver 智能体自我进化引擎实战指南GEP 协议、Gene/Capsule 资产与可审计进化循环Evolver 智能体自我进化引擎实战指南GEP 协议、Gene/Capsule 资产与可审计进化循环 Evolver 是 EvoMap 生态中一款基于 GE开发工具高性能计算文档深入 WeKnora Agent 引擎ReAct 执行循环、内置工具体系与自定义 Agent 配置实战深入 WeKnora Agent 引擎ReAct 执行循环、内置工具体系与自定义 Agent 配置实战 本文基于 WeKnora 开源知识库平台的 Agent人工智能大模型RAGAI Agent后端前端MCP 服务知识库dsh-plugin工具调用A-Evolve 完全指南用 LLM 驱动的演化循环自动优化 AI AgentA Evolve 完全指南用 LLM 驱动的演化循环自动优化 AI Agent A Evolve 是一套面向任意领域、任意演化算法的 AI Agent 自我进AI 技能人工智能大模型深度学习上一篇Meson 1.11.0 发布详解链接参数、Cargo Workspace、测试断言与 Windows 构建的 18 项关键改进下一篇3大AI开发痛点如何破解CC Switch v3.11.0揭秘跨平台统一管理方案创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑