我如何使用19个AI代理来设计物理引擎（Tournament Architecture）
Source: Dev.to
我正在构建一个名为 PISTON 的发动机模拟器。
它基于第一性原理预测马力和扭矩——真实的热力学，不进行曲线拟合，也没有任何修正系数。目前在 22 台经过验证的发动机上，误差为 8.08 % HP，涵盖从本田 Beat 轻型车到雪佛兰 LT4 增压 V8。
有趣的并不是物理本身，而是 我 的构建方式。
每个主要功能都会经历一次 tournament（竞赛）：
8 planners → 8 reviewers → 3 judges
19 个 AI 代理各自独立工作，竞争产生最佳实现。
单代理开发的问题
当单个 AI 代理设计并实现一个复杂功能时，会出现：
- 锚定偏差 – 它首先想到的方法会占主导。
- 盲点 – 没有人挑战它的假设。
- 局部最优 – 它在最初的框架内进行优化，而不是探索其他方案。
- 自我群体思维 – 相同的偏差在设计 → 实现 → 测试的各阶段叠加。
对于诸如预测燃烧模型（错误的燃烧速率方程可能导致 30 % 的误差）之类的任务，单一代理并不足够。
赛事结构
第1阶段：规划（8名代理）
八位独立的规划者各自收到相同的简报：
- 特性描述（例如，“排气调校模型”）
- 技术要求（例如，“特征线法波传播”）
- 集成约束（它如何适配现有代码库）
- 验证目标（预期的精度提升）
每位规划者需输出一份完整的设计文档，涵盖数据结构、算法、方程式、文件组织以及测试策略。规划者之间相互隔离——不会看到其他人的成果。
为什么是8？
八个能够产生真正多样的方案。少于这个数目往往只能得到同一主题的变体；而八个则可靠地出现 3‑4 种根本不同的架构。
第2阶段：评审（8名代理）
八位独立的评审者各自收到全部八份方案。他们的任务是：
- 对每份方案进行评分，从五个维度评估：
- 物理精度
- 代码质量
- 性能
- 可维护性
- 集成风险
- 识别所有方案中的最强要素。
- 推荐一个混合方案，将最佳部分组合起来。
- 标记物理错误或概念误解。
评审非常严苛。常见的发现包括：
- “方案 C 使用了未进行解离修正的绝热火焰温度——这会导致 NOₓ 预测偏高 40 %。”
- “方案 F 的数据结构在每个曲轴角步需要 O(n²) 遍历——在每个循环 720 步的情况下不可接受。”
- “方案 A、 D、 G 都使用了相同的 Woschni 关联式，但系数约定不同——只有 D 的是正确的。”
第3阶段：判决（3名代理）
三位评委收到全部八份方案 以及 全部八份评审。每位评委独立进行：
- 选出获胜方案（或推荐特定要素的混合方案）。
- 撰写详细的理由说明。
- 提供具体的实现指导。
决策逻辑
| 评委一致性 | 结果 |
|---|---|
| 全部 3 人一致 | 采用该方案。 |
| 3 人中 2 人一致 | 采用多数方案，并记录异议。 |
| 无一致意见 | 依据更明确的标准进行第二轮评审。 |
Source: …
实际案例：预测燃烧
燃烧模型大赛是最具影响力的环节。它用基于物理的燃烧速率预测取代了我们的 Wiebe 曲线拟合（本质上是查找表）。
产生的方案
| # | 方法 |
|---|---|
| 2 | Tabaczynski 吞噬‑燃烧（最终获胜者） |
| 2 | 分形火焰模型 |
| 1 | 带 PDF 的准维模型 |
| 1 | Blizard‑Keck |
| 1 | 带 k‑ε 湍流的 Eddy‑燃烧 |
| 1 | 混合方法 |
关键审稿人发现
- Tabaczynski + Zimont 湍流火焰速度 提供了最坚实的物理基础。
- 分形方法 优雅，但实现复杂度约 3 倍。
- 两个方案出现了 层流火焰速度误差（Metghalchi‑Keck 与 Gülder —— 审稿人指出 Gülder 需要不同的曲线拟合系数）。
法官决定
所有三位法官 一致选定 Tabaczynski 吞噬‑燃烧方案，具体如下：
- Zimont 湍流火焰速度（校准系数 (A_z = 0.56)）
- k‑K 湍流模型（考虑翻滚/旋涡，(C_K = 0.50)）
- Metghalchi‑Keck 层流火焰速度
- 敏感性测试：点火正时、压缩比、凸轮正时
两次独立的校准运行后收敛到 (A_z = 0.52) 和 (0.56)。最终模型仅依据 发动机几何形状 预测燃烧——无需针对每台发动机进行调校。
结果： 8.3 % HP MAPE，与之前的曲线拟合方法相差不到 1 %，但现在它 能够推广 到未见过的发动机。
为什么这样有效
- 真正的多样性 – 八个代理独立解决同一问题，产生根本不同的解决方案，而不是“八个略有差异的 GPT 第一次直觉”。
- 对抗性审查 – 审查者有充分动机寻找缺陷；他们从不审查自己的工作。
- 合成胜于选择 – 混合方案（“采用方案 C 的数据结构、方案 A 的核心算法以及方案 F 的错误处理”）往往优于任何单一方案。
- 有据可查的推理 – 每场比赛产生约 100 页的技术文档，保留了选择特定方法的原因，附有引用和量化比较。
数字
跨越 12 场锦标赛（燃烧、敲击、强制增压、VE/赫姆霍兹、排气调校、热传递、摩擦、发射…
原始内容已截断；如有需要请继续。
统计概览
- 每场比赛的平均计划数: 8
- 每场比赛的平均评审数: 8
- 裁判一致率: 83 % 全体一致，17 % 2‑1 多数
- 零 需要第二轮评审（全部在首次评审中解决）
- 审稿人捕获的物理错误: 34 起，遍及所有比赛
- 整体验证的引擎数量: 22 个引擎，44 个数据点（每个包含 HP + TQ）
何时 不 使用此方法
此方法对以下情况来说是大材小用：
- 简单功能（例如，添加 CLI 标志，修正拼写错误）
- 已经充分理解且有明确最佳实践的问题
- 时间紧迫的修复
适用场景
- 物理错误会导致错误结果的功能
- 逆转成本高的架构决策
- 任何“够好”还不够好的情况
亲自尝试
该方法适用于任何能够进行技术写作的 AI。关键要素包括：
- 相同的简报 – 每个规划者获得相同的信息
- 真正的隔离 – 规划者彼此看不到对方的工作
- 交叉审查 – 审稿人查看 所有 计划，而不仅仅是一个
- 独立评判 – 法官之间不相互咨询
- 保存的产物 – 保留所有内容以供将来参考
PISTON 代码库位于 .
- 1,141 个测试
- 22 个已验证的引擎
- 全部通过锦标赛构建。
⚡