附录 D 实践实施建议

Meta-Harness 在很大程度上与领域无关：我们预期它适用于任何语言模型被任务专属 Harness 包装的场景。然而，将其应用于新领域需要在一个相对较新的 LLM 辅助编码范式中操作——提议器需要基于长时间跨度的先前运行历史进行条件生成，并编写效果可能在多步之后才显现的程序。在使这一工作流程可靠运行的过程中，我们发现了一小组在本文研究的三个领域中始终重要的实践选择。以下指南本身并非关于该方法的科学论断；它们是构建和运行系统过程中的工程经验，我们希望能帮助未来的工作更容易地将 Meta-Harness 应用于其他领域。

• 编写一个好的技能描述（skill）。技能文本是引导搜索的主要接口，其质量是决定循环能否成功的最强杠杆。提议器接收一段自然语言技能描述 [^3]，定义其角色、目录布局、CLI 命令和输出格式。在实践中，技能描述应约束输出和安全相关行为，而非约束提议器的诊断过程：它应指定哪些行为被禁止、需要产出哪些制品（artifacts）、需要优化哪些目标，同时让模型自由地检查分数、执行轨迹和先前代码。我们从检查 Meta-Harness 运行日志中获得的直觉是，经过足够多的迭代后，累积的执行轨迹对提议器行为的塑造往往超过技能描述本身。根据我们的经验，迭代修改技能文本比改变迭代次数或种群大小对搜索质量的影响更大。建议专门运行几次短进化（每次 3-5 轮迭代）来调试和完善技能描述，然后再执行完整的运行。
• 从基线 Harness 和一个对其而言较难的搜索集开始。编写一个简单的基线（如少样本提示），然后通过筛选基线做错的样本或选择多样化的高难度实例来构建搜索集。如果基线已经使评估饱和，搜索将没有多少可优化的空间。保持搜索集足够小，使每次运行大约可进行 50 次完整评估（在我们的分类实验中为 50-100 个样本，数学检索为 88 个问题）；一个快速且具区分度的评估比一个大规模评估更有价值。
• 以易于浏览的格式记录所有内容。评估代码应以提议器可以可靠查询的形式写入代码、分数和执行轨迹。在实践中，这意味着使用机器可读格式如 JSON，按层次结构组织制品，选择合理且一致的文件名，以及采用使正则表达式搜索等简单工具能良好工作的命名方案。
• 通过小型 CLI 使日志可查询（可选但有帮助）。每个 Harness 有一个包含源代码、分数和执行轨迹的目录，但随着历史记录的增长，仅靠原始文件系统访问会变得繁琐。一个能列出帕累托前沿、显示 top-k Harness、以及对比两次运行之间的代码和结果差异的短 CLI 可以使经验存储更易于使用，而且查询此类 CLI 与编码智能体训练时的工作流程高度一致。如果存在相关的离线经验（来自其他模型的 Rollout、已解决的问题语料库、相关论文），将其转换为相同的目录结构也可以帮助热启动探索和锚定新思路。这一层帮助提议器节省可能在导航上浪费的 token。
• 在昂贵的基准测试之前进行轻量验证。编写一个小型验证测试，导入模块、实例化类，并在一小组样本上调用两个方法。搜索过程中提出的 Harness 应先通过此测试再进行完整评估。一个简单的测试脚本可以在几秒内捕获大多数格式错误或无法运行的候选方案，并将失败的代价保持在接近零的水平。
• 将评估自动化，放在提议器之外。运行评估足够简单，不值得让提议器来执行。应由单独的 Harness 对候选方案评分并将结果写入文件系统。