这次 HN 上这个项目的切入点有点反直觉大家都在卷 LLM 权重它给出的结论却是——先把模型外围那层 harness“训练”好比继续卷基座模型更划算。原项目标题是 “Show HN: Auto-train the harness, not the LLM. cross-model, cross-benchmark gains”。一句话理解不微调 LLM而是自动优化调用 LLM 的整套“脚手架”提示词模板、工具调用策略、上下文管理、任务拆分方式并且让优化结果在一个模型上生效后还能迁移到另一个模型、另一个 benchmark 上继续带来稳定收益。这个方向目前在社区讨论里和 “harness engineering”“codex harness”“agent harness” 这些热词是同一类问题模型能力之外的那层工程正在成为效果差异的主要来源。1. 核心概念与项目定位1.1 一次看懂项目的四个关键词项目标题里的信息密度很高拆开看更清楚关键词含义技术指向Auto-train自动化训练不是人工手调而是让优化过程自己搜索最佳策略the harness模型外围系统prompt、工具调用、记忆、上下文管理等组装层not the LLM不调整模型权重不微调、不重训基座模型降低算力依赖cross-model, cross-benchmark跨模型、跨基准泛化优化结果可迁移不止在一个模型或一个数据集上有效从标题看这个项目的核心主张可以概括成把 harness 当作“可学习的策略层”用自动化的方式搜索出能稳定提升模型表现的组合策略同时保证策略不绑定在某个具体模型上。1.2 这是不是又一个评测框架很多人看到 harness 第一反应是 LangChain、LlamaIndex或者 lm-evaluation-harness 这类评测工具。从方向上看这个项目更像是一套“harness 策略优化器”它把模型当黑盒把外部调用策略当白盒然后用训练思路来优化这层白盒。这比单纯的评测框架多了“训练动作”比 LangChain 这类手动组装框架多了“自动搜索”。如果这个项目的路线能走通它解决的是当前 Agent 开发里最浪费时间的问题工程师花大量精力手调 prompt、试工具描述、设计上下文压缩策略但这些经验很难沉淀成可复用、可迁移的系统。1.3 适用读者与前提知识适合三类人看做 LLM Agent 应用开发的工程师想减少手调 prompt 的时间。做 LLM 评估与优化的算法工程师关注 benchmark 泛化和过拟合问题。对低成本增强模型能力感兴趣的独立开发者没有大规模微调资源。前提知识很简单了解 LLM API 基本调用方式知道什么是 system prompt、工具调用、评测集就够了。项目本身不涉及模型训练不需要分布式训练经验。2. 为什么“训练 harness”是一个值得关注的新思路2.1 模型能力之外的那层差异过去一段时间业内对 LLM 应用的共识是同一个模型用不同方式调用效果差异可以非常大。公开讨论中经常提到的 Codex 案例就很典型Codex 在真正大规模使用前工程团队花了大量精力处理脚手架、工具定义、上下文工程让模型在一个“设计良好的工作环境”里发挥能力。这类外部环境就是 harness。它至少包含以下组件系统提示词设定模型角色和行为准则。上下文组织如何选择历史消息、如何压缩、如何排序。工具描述给模型看的工具 Schema 怎么写得准确。任务分解复杂任务拆成多少步、每步怎么校验。输出约束json 模式、格式规范、错误重试逻辑。过去这些组件靠人工经验调整。这个项目的反直觉之处是为什么不把“调这些组件”本身变成可自动训练的问题2.2 harness 优化和微调的本质区别传统微调是把知识“烧进”权重取得效果的同时也锁定了模型版本每次基座模型升级都要重新评估成本并不低。而 harness 优化是在推理时生效它的调整对象是模型输入侧和调用侧对比维度微调 LLM训练 harness调整对象模型权重输入组织、工具策略、上下文策略算力成本高需要 GPU 训练相对低主要是推理调用成本生效速度训练 部署周期长搜索到即可应用迁移性绑定模型理论上可跨模型迁移风险灾难性遗忘、过拟合benchmark 过拟合、策略脆弱这个对比就是项目标题里“not the LLM”的底气很多场景下不需要牺牲模型本身的通用能力只需要给模型配上一套更聪明的调用策略。2.3 为什么现在才出现这种思路一个原因是模型能力到了一个临界点基座模型本身已经能处理复杂任务瓶颈转移到“怎么把任务交给模型”。另一个原因是 Agent 工程实践积累了足够多的“手工 harness 经验”到了可以用自动化方法去搜索经验的空间。加上推理 API 成本下降用反复调用来搜索策略在成本上开始变得可行。3. 核心方法论拆解让“训练目标”和“训练对象”清晰起来尽量按工程直觉拆一下这种思路要落地必须解决的关键问题。3.1 定义“harness 参数空间”第一次看到“训练 harness”最大的疑问是harness 不是神经网络怎么训练它不是离散状态没有传统意义上的梯度。要让训练成立第一步是把 harness 变成可枚举、可组合的参数空间提示词模块库不同风格的 system prompt、few-shot 示例、输出格式说明。工具策略工具数量、工具描述写法、工具返回截断长度。上下文策略窗口选择策略、压缩阈值、摘要触发条件。任务路由是否拆分子任务、是否多轮反思、是否调用外部检索。每一个维度都可以设计成离散选项或可调参数。这样“训练”就从模型权重空间迁移到了“harness 配置空间”。3.2 搜索策略与优化信号没有梯度本质就是黑盒优化问题。可以参考的技术路径包括随机搜索 / 网格搜索小规模场景可跑但成本高。贝叶斯优化对离散和连续混合空间有效。进化搜索维护一组 harness 配置不断变异和选择。基于 LLM 的“策略生成器”让一个强 LLM 分析当前失败案例提出新的 harness 修正方案然后自动评估是否保留。从工程实现看最后一种做法最容易起步用一个“meta LLM”观察模型在验证集上的失败生成新指令、新工具策略再跑一轮评测留下的配置就是一次“训练更新”。3.3 跨模型、跨 benchmark 如何保证这是项目标题里野心最大的一部分。如果一套 harness 只在一个模型上有效换个模型就失效那价值就小很多。真正难点在于同一个优化目标在不同模型上的最优解可能不同。保守的判断是部分 harness 能力可以跨模型迁移例如任务拆分的通用模式、工具调用的结构化习惯部分能力则绑定了模型能力分布例如一个模型本身不会复杂推理时再好的 prompt 也难以弥补。因此“cross-model gains”更可能是在一组能力相近的模型之间实现而不是从 7B 模型迁移到 70B 模型都能保证同样的提升幅度。跨 benchmark 的难点在过拟合。如果优化过程反复在同一个测试集上搜索最终得到的 harness 大概率是“背下”了这道题的偏好。要缓解这个问题需要在优化循环里塞入多组风格差异明显的 benchmark并在训练集和验证集之间做严格切分。4. 系统架构与工程组件根据标题和这个方向的一般技术形态可以画出一个参考系统。实际项目代码可能不完全一致但功能模块大概率接近。4.1 参考架构整个系统可以分成五层策略搜索层 - 配置生成器 - 变异/进化算子 - Log 分析与失败模式聚类 评估调度层 - Benchmark 数据集管理 - 任务批量跑批 - 结果评分与显著性判断 Harness 执行层 - Prompt 模板渲染 - 工具调用循环 - 上下文压缩与记忆管理 - 多轮 Agent 调度 模型接入层 - 本地模型推理服务 - OpenAI/Anthropic/DeepSeek 等 API 兼容适配 - 统一请求协议 存储与观测层 - 每次运行的完整 Trace - 各 benchmark 得分 - 策略配置与效果归档策略搜索层是核心它决定下一轮尝试哪种 harness 配置评估调度层负责执行 batchharness 执行层承载实际“被训练的”逻辑模型接入层保证跨模型切换。4.2 为什么需要统一 Trace跨模型迁移和跨 benchmark 迁移都依赖对运行过程的完整回溯。只记录最终得分很难定位是哪个模块造成失败。建议至少记录完整对话历史工具调用顺序与参数token 消耗每次重试的触发原因最终得分与失败类型有了 Trace 才能做后续的“失败模式分析”才能让优化过程有方向而不是随机乱试。4.3 离线训练与在线生效分离工程上建议把“harness 搜索”和“harness 应用”拆成两个阶段。搜索阶段离线跑大批量任务产出一份“harness 策略配置包”线上推理环境只加载这份配置不执行搜索逻辑保证响应速度和成本可控。这份策略配置包可以用 JSON 或 YAML 描述包含{ harness_name: math_reasoning_v3, base_model: qwen2.5-72b, components: { system_prompt: prompt_templates/deep_reasoning.md, tool_strategy: use_tool_when_certainty_low, context_window: 16000, max_reflection_steps: 2 }, validated_on: [gsm8k_val, math_val], transfer_checked_on: [mmlu_pro], score_delta: 8.2% }这样设计的好处是模型升级后可以快速重放验证判断旧策略是否仍然有效。5. 环境准备与本地实验注意事项虽然项目处于早期阶段如果要在本地或服务器环境做验证先按通用清单过一遍。5.1 显存与推理资源考量重点说清楚训练 harness 通常不直接更新权重但搜索过程需要反复调用模型推理。如果接入的是第三方 LLM API主要成本是 token 消耗不需要本地 GPU。如果接的是本地模型则需要关心推理速度和显存大小。一个典型的搜索实验可能需要数百次推理调用。用 API 模式时需要预算足够的 token 成本用本地模型时7B~14B 级别的量化模型单卡可跑70B 级别需要多卡或者高显存方案。具体显存占用取决于所选模型和推理框架需要以实际环境为准不要轻信任何“固定占用 X G”的说法。5.2 推荐检查清单检查项说明Python 版本建议 3.10 以上很多新库已不支持 3.8包管理优先使用 venv 或 conda 建立独立环境避免冲突PyTorch / vLLM如果用本地推理需要按 CUDA 版本安装对应版本CUDA 驱动本地 GPU 推理前先跑 nvidia-smi 确认版本磁盘空间模型文件和评测数据集需要预留足够空间网络环境访问模型 API、拉取代码依赖需要网络连通评测数据集提前下好任务集避免运行中断5.3 起步最小配置第一次试跑不必追求完整架构建议最小化一个模型API 更省事两个差异明显的 benchmark一套初始的 baseline prompt一个最简单的“手动改配置再重新跑”的评估循环先跑通这个循环再逐步加入策略搜索和自动优化。6. 接口调用与批量任务设计这个方向的项目通常不会只提供 Web 界面更多是以 Python SDK 或 CLI 形式出现。即使项目当前没有开放完整 API实验时也需要自己搭建一条可批量执行的自动评估流水线。6.1 通用请求接口示例下面是适合接入大多数 OpenAI 兼容 API 的 Python 调用模板。替换模型名和 base_url 后可以在不同后端之间切换。import json from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY ) def run_harness(prompt_builder, tools, user_task): messages [{role: system, content: prompt_builder.system_prompt}] messages.append({role: user, content: user_task}) response client.chat.completions.create( modellocal-model-name, messagesmessages, toolstools, temperature0.2, max_tokens2048, ) return response这个模板只解决“单轮请求”实际 harness 可能需要循环工具调用伪代码逻辑如下for step in range(max_steps): result call_model(messages, tools) if result.is_final_answer(): return normalize_output(result) elif result.requires_tool(): tool_output execute_tool(result.tool_call) messages.append(format_tool_message(tool_output)) else: # 反思、摘要或任务再拆分的分支 messages.append(reflection_instruction(result))6.2 跨模型切换与配置管理验证 cross-model 效果时要保证同一份 benchmark 输入不变化只切换模型后端。建议用后端接入层做统一管理models: qwen_api: type: openai_compatible base_url: https://your-endpoint.example.com/v1 model_name: qwen-max deepseek_api: type: openai_compatible base_url: https://your-endpoint.example.com/v1 model_name: deepseek-chat local_vllm: type: openai_compatible base_url: http://127.0.0.1:8000/v1 model_name: local-model每次跑批前指定使用哪个模型并确保任务ID、随机种子一致才能比较不同模型上的 harness 收益。6.3 批量跑批与失败重试Harness 优化需要大量重复实验。批量任务设计建议满足每个任务有唯一 ID写入结果表。支持断点续跑失败任务单独标记。限制并发数避免触发上游限流。失败重试要带指数退避而不是无脑重打。一个简化版的批量循环import time from concurrent.futures import ThreadPoolExecutor def evaluate_one(record): for attempt in range(3): try: result run_harness(record[prompt_id]) return {ok: True, result: result} except Exception as e: time.sleep(2 ** attempt) return {ok: False, error: timeout} with ThreadPoolExecutor(max_workers5) as pool: outputs list(pool.map(evaluate_one, dataset))7. 效果验证方案如何证明“训练 harness”真的有效这类项目最容易犯的错是“在随机噪声里找规律”。LLM 本身的输出方差较大一次得分上升可能是运气不是 harness 策略变好。验证时建议做以下几步7.1 同一 benchmark 重复跑取均值每个配置至少跑 3 遍报告平均分和方差。如果方案 A 比方案 B 平均高 5%但方差也是 5%还不能下结论。要增加重复次数并对比中位数和分位数。7.2 拆分验证集与训练集如果优化过程会用 benchmark 分数来选择下一个配置那么这一份数据就是“训练集”。一定要预留一份没有参与策略选择的 benchmark 作为验证集。否则 final score 会被严重高估。7.3 跨模型迁移验证矩阵设计一张迁移验证表harness 配置来源模型验证模型 A验证模型 B验证模型 C模型 A 上搜索原生得分高是否迁移是否迁移模型 B 上搜索是否迁移原生得分高是否迁移如果从模型 A 上搜索到的 harness 配置在模型 B 上相比模型 B 的 baseline 依然有正向收益才能证明 cross-model gains 不是巧合。7.4 跨 benchmark 泛化验证同样不能只在数学 benchmark 上搜然后在代码 benchmark 上验证。建议选三到四个任务形态差异大的 eval避免策略退化成“针对特定题型的 hack”。8. 常见问题与排查方法基于这类系统的开发经验列出高频问题问题现象可能原因排查方式解决方案搜索过程中模型输出格式不稳prompt 模板与模型格式偏好不匹配查看失败 Trace对比 system prompt针对目标模型调整输出约束描述某一配置在 A 模型提升、在 B 模型下降策略对模型能力分布敏感检查两个模型对同一任务的错误类型缩小迁移范围做能力分层的策略适配benchmark 分数越优化越高但真实任务没变好评测集过拟合更换全新任务做盲测增加验证集、更换 benchmark 或任务扰动批量跑批频繁限流并发过高或请求频率过大查看 429 错误降低并发、加入指数退避上下文超过模型窗口多轮反思或工具结果太长查看 token 消耗增加压缩、截断或摘要模块重试无效任务反复失败问题从根源不可解查看错误日志增加不可恢复失败判定避免死循环“训练”过程成本失控搜索步数太多或评测集太大统计 token 成本先采样小数据集验证方向再全量跨模型 API 返回字段不一致各家 API 兼容度不同对比返回结构封装统一响应层9. 最佳实践与合规边界9.1 工程实践建议第一次实验先做 10 个配置的穷举而不是直接上进化搜索。把 baseline 配置固化下来每次改动只做单点控制变量。所有运行结果落盘不要只在终端看。搜索出来的 harness 策略要有可读性不要接受一段“熵增巨大”的 prompt 黑盒。记录 benchmark 细节包括题目来源、数量、few-shot 数量、评估指标。9.2 版权与数据合规如果项目使用第三方评测集或自有业务数据需要确认数据来源和合规要求。私有业务数据不要盲目上传到外部模型 API。涉及代码库数据时需要关注代码许可协议。评测类项目更多是“跑分数”但一旦把策略迁移到业务 Agent 中就要注意 prompt 中是否包含敏感信息。9.3 Agent 与工具调用的安全边界Harness 优化的不只是 prompt还有工具调用策略。优化出来的策略可能会让模型更积极地调用工具这时必须给工具执行加权限边界例如文件删除、外部请求、数据库写入等高风险操作要人工审批。不能因为“这是测试 harness 优化”就放开工具权限。10. 如何低成本复现这个思路目前标题信息有限最终还是要参考原项目仓库的代码和文档。但在没有完整源代码前完全可以用以下方式低成本复现核心思想先选一个开源评测集加上一个 API 模型写一个最简单的循环预置多个 prompt 模板 - 同一批题目各跑一次 - 统计得分排序 - 人工看最高分模板和最低分模板差异。这一步的收获往往就很大不同 prompt 写法之间的分数差距可能超过换一个模型带来的提升。接着再增加一层自动化让一个强模型分析 top 和 bottom 模板的差异生成少量新模板跑下一轮。这种“半自动 harness 训练”不需要高级算法先验证收益再决定是否加入贝叶斯优化或进化搜索。11. 总结与判断标准这个项目最值得关注的点不是“又一个 LLM 框架”而是它把发力点从模型训练转移到了模型调用策略的自动化。这个方向一旦跑通意味着以后每次基座模型升级不需要重新微调业务逻辑只需要重新搜索或校验一套 harness 配置就能把模型能力“包装”成可复用的业务智能。先要验证三件事优化出来的 harness 配置是否比人工手调的 baseline 稳定高出一截。换一个模型时收益是否还在。到一个没参与优化的 benchmark 上收益是否还在。如果这三件事都能通过项目就不只是 HN 上的一个实验而是 Agent 工程里可复用的基础设施。最容易踩的坑也先说清楚不要在一个评测集上反复搜索还觉得分数上升是真实进步过拟合 harness 和过拟合模型一样容易。后续值得扩展的方向包括分层策略库把任务类型和策略解耦、模型能力画像驱动的自动 harness 选择、以及跨团队共享的“harness 策略仓库”。这块市场的本质是把过去一年工程师手调 prompt、调工具描述的经验变成一次性的系统化基础设施。建议对这一方向保持关注等仓库放出更多代码后先用最小实验验证它的迁移假设再决定是否接入正式业务链路。