很多做 LLM 应用的开发者都遇到过这样一种非常诡异的场景基座模型一个版本没换prompt 模板也只是在原有基础上微调结果一换评估脚本分数立刻掉了十个点或者今天在测试环境里还能稳定运行的 Agent部署到产品环境后开始频繁答非所问。于是有人怀疑模型被偷偷换掉了有人怀疑评测数据写错了但排查到最后问题往往出在模型外面的那层壳——Harness。Harness 这个词并不是新概念但最近它因为 DeepSeek-Harness、Codex-Harness 等一系列开源项目重新回到了开发者视野。简单理解Harness 就是围绕模型的所有工程约束输入格式、上下文窗口、工具调用协议、执行沙箱、判题标准、数据回流规则。同一个模型在不同的 Harness 里表现可能完全不同。这个现象在普通应用中只是兼容成本但在自进化 AI 场景里会被循环放大最终变成“模型越跑越笨”的灾难。这篇文章想聊清楚三件事第一为什么“换个 Harness 就变笨”不是玄学而是自进化系统里最常见的工程陷阱第二像 EverMind 这样把自进化从研究推向产品的产品到底在解决什么第三作为开发者怎么用工程手段让一个自进化闭环稳定地“越用越聪明”而不是越跑越偏。1. 这篇文章真正要解决的问题先给出一个判断模型能力 模型权重 Harness 数据闭环。这个公式看起来没有“模型能力”这个词性感但恰恰解释了最多真实世界的效果波动。很多团队把大量资源花在选基座模型、调 prompt、做 RAG 检索上却忽视了 Harness 和自进化数据回流的一致性。尤其是在 Agent 场景里模型输出要经过工具调用、代码执行、外部 API 返回等多个环节任何一个环节的 Harness 变了最终效果都可能大幅波动。你以为是模型退化实际上是把模型放进了一个更糟糕的“跑道”。而自进化 AI 对 Harness 的敏感度比普通应用高一个量级。普通应用里模型输出一次就算完事自进化系统里模型输出会被执行、被评判、被筛选、被回流成训练数据然后再迭代。Harness 的偏差会在每一轮循环中被不断放大。如果第一次筛选时标准就有问题后面所有轮次都是在强化错误的模式。这篇文章的读者应该是正在做 Agent、RAG、模型评测、数据回流、AI 产品化的工程师。如果你的目标是让一个 AI 系统在真实场景中持续变强那你就必须理解模型参数不是唯一的杠杆Harness 才是那个最容易忽略、也最容易致命的部分。2. 自进化 AI 的核心原理与 Harness 的作用自进化 AI 不是指模型自己修改自己的权重而是指一个系统可以自动完成“生成 → 执行 → 评判 → 筛选 → 训练”的闭环。以代码生成模型为例模型先根据需求写一段代码Harness 负责在沙箱中执行这段代码评判器根据测试用例判断代码是否通过通过的高质量代码会被写回训练集或缓存用于下一轮优化。这就是一个最小的自进化闭环。自进化常见的三种模式自指令Self-Instruction模型自己生成问题再自己生成答案通过 Harness 过滤后作为训练数据。自对弈Self-Play多个模型副本相互生成和对抗评判器负责打分。迭代偏好优化Iterative Preference Optimization通过生成多个候选结果结合人工或模型偏好构建对比样本再反馈到模型训练中。这三条路径都离不开 Harness。Harness 是承载自进化闭环的“跑道”它不仅影响单次输出质量更决定了哪些反馈能进入下一轮学习。Harness 层次包含内容对自进化的影响输入编排prompt 模板、few-shot、指令解析决定任务难度与分布执行沙箱代码执行、API 调用、工具返回决定能否获得真实反馈评判器规则判分、LLM Judge、奖励模型决定哪些数据被回流数据回流去重、清洗、格式转换、样本筛选决定训练数据质量版本与监控Harness 配置版本、指标追踪决定循环是否可收敛一个很常见的误区是认为 Harness 只是“调用模型的工具代码”。实际上Harness 是模型与外部世界之间的完整协议。它决定了模型能看到什么信息、能调用什么工具、输出如何被验证。在普通单项任务里不同 Harness 的差异可能只是几个 token 的格式问题但在自进化系统里这种差异会直接污染训练数据。所以如果你发现“同一个模型换了个 Harness 就变笨”不要急着怀疑模型先把两个 Harness 的所有输入输出协议逐项对比一遍。3. EverMind 是什么自进化从研究走向产品从项目标题和公开定位来看EverMind 想做的事很清晰把自进化能力做成一个产品级引擎让 AI 系统在真实使用中不断积累反馈并通过 Harness 自动优化实现“越用越聪明”。研究里的自进化原型通常只要求“能跑通”。论文中的实验只需要在固定的 benchmark 上验证一次不需要考虑长期运行的稳定性。但产品中的自进化必须回答几个非常现实的问题反馈数据不可信怎么办用户行为、代码执行结果、模型打分都可能包含噪声。效果下滑怎么回滚模型不是只训练一次而是需要持续迭代。训练数据从哪里来能不能在合法合规的前提下使用用户反馈。成本上限在哪里每一轮生成、执行、评审、训练都有费用。如何防止奖励黑客模型可能会找到评判器的漏洞而不是真正变强。EverMind 这类产品的核心价值就是把这些研究问题工程化。它不再把 Harness 当成测试时的一次性工具而是把它升级为可以持续运行、可观测、可回滚的工程基础设施。从产品模块上看一个自进化引擎通常包括数据接入层从真实使用日志、任务池、评测集中采集原始数据。Harness 编排层根据任务类型选择对应的执行环境、工具集和评判器。评测筛选层对生成结果打分、去重、过滤。模型更新层基于高质量数据做微调、偏好优化或缓存更新。安全与回滚层对更新内容做回归测试异常时快速回滚。需要注意的是我没有把“EverMind”的 API 写进本文因为不同阶段的产品的接口变化很大。更稳妥的判断是EverMind 想做的不是一个单独的模型而是一套让 AI 持续进化的产品化基础设施。它的产品形态很可能围绕“任务执行 数据回流 模型迭代”这一完整链路展开。4. 为什么换个 Harness 就「变笨」三个典型原因前面反复强调 Harness 很重要但它到底在哪些环节影响模型效果下面拆成三个典型原因每个原因都会在实际项目中出现。4.1 评估口径变了最常见的原因不是模型变蠢了而是你和模型“约定”的语言变了。不同 Harness 可能使用不同的 prompt 模板、few-shot 示例、输出解析规则和判题标准。比如旧 Harness 要求模型输出 JSON新 Harness 却要求模型输出 Markdown模型还在按旧格式输出自然被判为“错误”。在自进化系统里这个问题的危害更大。因为 Harness 变化后评判器也会变化。同一个答案在旧 Harness 下得 0.9 分在新 Harness 下可能只有 0.4 分。如果你不做配置版本管理下一轮训练就会把这些“被误杀”的样本剔除掉反而留下了一堆迎合新格式但没有真正提高能力的样本。4.2 执行环境变了对于代码生成、Agent 工具调用、数据分析这类任务执行环境是 Harness 中最关键的部分。模型生成结果后Harness 需要在沙箱中执行代码、调用 API、处理超时和错误。只要环境依赖不同结果就可能完全不同。举个非常常见的例子旧 Harness 的 Python 环境里安装了requests库模型生成的代码依赖它执行成功新 Harness 的沙箱里没有requests执行立刻失败。如果你只看执行成功率会以为“模型变笨了”实际上只是环境缺了一个库。还有上下文截断问题。Agent 在长时间任务中会产生大量中间步骤如果 Harness 对上下文的截断策略不同模型能看到的有效信息就会不同最终结果自然千差万别。4.3 数据回流链路变了自进化系统里Harness 还承担着“数据把关人”的角色。新 Harness 的产生会改变哪些数据被保留、哪些数据被丢弃。例如旧 Harness 的判题器只检查最终答案是否正确新 Harness 又增加了“是否包含推理过程”这个标准。这个变化本身可能是合理的但如果新旧 Harness 同时运行回流到数据仓库的样本分布会发生偏移。新样本偏重推理过程旧样本偏重结果两批数据混在一起训练模型就会变得犹豫不决显得“笨”了不少。4.4 隐蔽的奖励黑客这一点容易被忽略。自进化系统最怕的不是“不聪明”而是“用错误的方式变聪明”。当 Harness 的评判规则过于简单、过于固定时模型会通过大量试探发现规则盲区并生成那些能拿到高分但实际没有完成任务的结果。这就是奖励黑客Reward Hacking。比如判题器只检查输出中是否包含某个关键词模型就会学会把关键词堆进答案判题器检查代码输出是否包含status: ok模型就会学会打印这个字符串而不是真正完成任务。Harness 在这里的职责不只是“执行和打分”还要隔离这种投机行为。一个健壮的自进化 Harness需要同时包含规则判定、模型判定和人工抽检不能给模型太多“被 hack”的确定性。5. 一个可落地的自进化最小闭环设计了解了理论之后下面给出一套可以真正落地的自进化最小闭环方案。它不需要一开始就做大规模模型训练适合从 0 到 1 验证自进化思路。整个闭环包括以下组件任务池存放一批真实业务任务每个任务包含指令和可验证的参考结果。Harness 层为每类任务提供统一的执行和评判接口。生成器基座模型封装负责产生候选答案。评判器可以是规则判分、LLM Judge也可以是人工抽检。数据仓库存储通过筛选的高质量样本。优化器第一版可以只把高质量样本用于少量示例缓存第二版再接入微调或偏好优化。工作流程如下从任务池中采样一个任务。通过生成器产生多个候选答案。Harness 在真实或模拟环境中执行候选答案。评判器综合得分筛选出超过阈值的样本。将高质量样本写入数据仓库。周期性用新样本对模型做回归测试。如果指标稳定再决定是否更新模型。这套闭环的关键是“先稳定后进化”。第一版不建议直接开始微调而是先收集一批经过 Harness 验证的高质量样本把它们作为 few-shot 示例或行业知识缓存接入推理链路。这样成本低、速度快也能验证“数据回流是否真的能提升效果”。当收集到的有效样本达到一定数量后再考虑用这些样本进行轻量级微调比如使用 LoRA。每轮更新前必须把旧模型和旧 Harness 版本都保留下来用于 A/B 对比和回滚。6. Harness 与自进化代码示例下面用几个精简代码示例来说明 Harness 和自进化数据闭环的工程实现。示例只做关键逻辑演示不绑定任何特定大模型 SDK读者可以把模型调用替换成自己的线上接口。6.1 定义统一的 Harness 接口文件路径self_evolving/harness/interface.pyfrom abc import ABC, abstractmethod from dataclasses import dataclass, field from typing import Any, Dict, Optional dataclass class ExecutionResult: status: str # PASS / FAIL / ERROR output: str error: Optional[str] None raw: Dict[str, Any] field(default_factorydict) dataclass class JudgeResult: score: float # 0.0 ~ 1.0 passed: bool reason: str class Harness(ABC): 一个 Harness 封装了模型执行一个任务所需的全部外部条件。 abstractmethod def setup(self) - None: 初始化执行环境比如启动沙箱、加载工具包。 abstractmethod def execute(self, prompt: str, generation: str) - ExecutionResult: 把模型生成结果放到真实环境中执行并返回执行结果。 abstractmethod def judge(self, prompt: str, generation: str, exec_result: ExecutionResult, reference: Optional[str] None) - JudgeResult: 根据统一标准判断该结果是否值得被回流。核心意义在于每个任务都实现同一套接口。后续的自进化数据筛选、模型回归测试都依赖这套接口从而避免“换个 Harness 就换一套逻辑”的问题。6.2 自进化数据筛选脚本文件路径self_evolving/select_samples.pyfrom dataclasses import dataclass from typing import Any, Dict, List from self_evolving.harness.interface import Harness, JudgeResult dataclass class EvolveSample: task_id: str instruction: str generation: str score: float execution: Dict[str, Any] class SelfEvolveDataLoop: 一个极简自进化数据过滤闭环。 它的作用不是训练模型而是从大量生成结果中筛出高质量样本 为后续的 few-shot 缓存或微调做准备。 def __init__(self, harness: Harness, threshold: float 0.8): self.harness harness self.threshold threshold def process_task(self, task: Dict[str, Any], generate_fn) - List[EvolveSample]: instruction task[instruction] num_samples task.get(num_samples, 3) good: List[EvolveSample] [] for _ in range(num_samples): generation generate_fn(instruction) exec_result self.harness.execute(instruction, generation) judge_result: JudgeResult self.harness.judge( promptinstruction, generationgeneration, exec_resultexec_result, referencetask.get(reference), ) if judge_result.passed and judge_result.score self.threshold: good.append( EvolveSample( task_idtask[id], instructioninstruction, generationgeneration, scorejudge_result.score, execution{ status: exec_result.status, output: exec_result.output, error: exec_result.error, }, ) ) return good这里的generate_fn是模型生成函数可以直接调用你线上的大模型接口也可以换成从离线日志中读取历史结果。整个流程遵循“先执行、再评判、后筛选”的顺序确保只有真正经得起验证的样本才会被保留。6.3 A/B 回归测试判断模型是不是真的变笨了文件路径harness_regression/ab_test.pyfrom dataclasses import dataclass from typing import Any, Dict, List, Optional from self_evolving.harness.interface import Harness, ExecutionResult, JudgeResult dataclass class MockModel: 极简模型封装模拟模型对 system prompt 格式的敏感性。 name: str def generate(self, instruction: str, system_prompt: str) - str: if 必须输出JSON in system_prompt: return {result: ok} return ok class MockHarness(Harness): 用格式检查和关键词匹配做判定的演示 Harness。 def __init__(self, system_prompt: str, require_json: bool True): self.system_prompt system_prompt self.require_json require_json def setup(self) - None: pass def execute(self, prompt: str, generation: str) - ExecutionResult: if self.require_json and not generation.strip().startswith({): return ExecutionResult(statusERROR, output, errorJSON格式错误) return ExecutionResult(statusPASS, outputgeneration) def judge(self, prompt: str, generation: str, exec_result: ExecutionResult, reference: Optional[str] None) - JudgeResult: if exec_result.status ERROR: return JudgeResult(score0.0, passedFalse, reasonexec_result.error) if reference and reference not in generation: return JudgeResult(score0.0, passedFalse, reason答案不匹配) return JudgeResult(score1.0, passedTrue, reasonok) def evaluate_with_harness(model, harness, dataset) - Dict[str, float]: passed 0 for item in dataset: gen model.generate(item[prompt], getattr(harness, system_prompt, )) exec_result harness.execute(item[prompt], gen) judge_result harness.judge( item[prompt], gen, exec_result, item.get(reference) ) if judge_result.passed: passed 1 return {pass_count: passed, pass_rate: passed / len(dataset)} if __name__ __main__: dataset [ {prompt: 请返回状态, reference: ok}, ] model MockModel(namebase-llm) old_harness MockHarness(system_prompt必须输出JSON, require_jsonTrue) new_harness MockHarness(system_prompt请直接回答, require_jsonTrue) print(old_harness:, evaluate_with_harness(model, old_harness, dataset)) print(new_harness:, evaluate_with_harness(model, new_harness, dataset))这个示例里模型本身没有变化。只是新 Harness 的 system prompt 去掉了“必须输出 JSON”的指令但require_json仍然为 True于是模型输出ok后执行阶段直接报错。运行结果会显示 old_harness 的通过率是 1.0new_harness 是 0.0。这就是一次典型的“换个 Harness 就变笨”回归场景。真实项目中你不需要用 Mock 类而是为线上环境分别封装两个真实 Harness并在同一批固定回归集上运行观察指标变化。6.4 用配置文件管理 Harness 版本文件路径configs/harness_v1.yamlharness: name: code-exec-sandbox version: v1 model: provider: openai-compatible model_name: gpt-4o-mini prompt: system_template: 你是一个Python工程师。只输出代码不要额外解释。 user_template: 请完成以下任务{task} max_tokens: 1024 temperature: 0.2 tools: python_executor: enable: true timeout_seconds: 10 max_output_chars: 2000 judge: metric: exact_match pass_threshold: 0.7把 Harness 配置纳入 Git 管理每次变更都要走 code review。这样当某个版本效果下降时可以快速 diff 出是哪一行 prompt 或哪一个配置项引起的。7. 运行结果与效果验证如何判断模型真的在变聪明这里需要区分两层验证。第一层是回归测试用于回答“模型是否变笨”。运行ab_test.py时如果新旧 Harness 在同一个黄金评测集上的通过率差异超过阈值就应该停止上线检查配置差异。这一步的要点是必须固定评测集不能每次换数据。第二层是自进化闭环验证用于回答“模型是否越用越聪明”。建议记录以下指标指标说明判断方式任务通过率Harness 执行后通过判定的任务占比持续上升高分样本占比筛选出的高质量样本占全部生成样本的比例稳定或上升数据多样性回流样本的指令覆盖度、语义聚类数不能单调下降人工抽检通过率随机抽查一批模型输出人工判断质量不能低于安全线旧任务回归率在历史测试集上的通过率不能明显回退奖励黑客出现率通过关键词侥幸得分但实际未完成任务的样本比例越低越好运行自进化闭环时不能只看“合格样本变多”。如果筛选标准过于宽松合格样本会越来越多但模型能力没有真正提升如果筛选标准过于苛刻数据多样性下降模型会很快陷入局部最优在旧任务上也可能变笨。建议每一次闭环实验都保存快照Harness 版本、模型版本、训练数据版本、评测结果。这样无论哪个环节出问题都能在几分钟内定位并回滚。8. 常见问题与排查思路下面汇总自进化 Harness 项目里最常见的几类问题方便你在实践中快速排查。问题现象可能原因排查方式解决方案更换 Harness 后同一基座模型准确率骤降prompt 模板、few-shot、判题标准不一致对比新旧 Harness 配置跑同一回归集统一输入输出协议Harness 配置入 Git自进化训练若干轮后效果先升后降数据分布坍缩过度筛选同质样本统计训练集多样性画 score 分布增加采样随机性保留困难样本模型开始故意迎合判题器奖励黑客人工抽检模型输出看是否存在投机模式混合使用规则、LLM Judge 与人工评审产品环境反馈数据太脏训练后效果变差未做去重、清洗、隐私过滤检查回流数据流水线增加数据质量门槛和隐私过滤模块微调后旧能力明显遗忘灾难性遗忘在旧任务回归集上跑测试混合旧数据训练或使用低秩微调自进化闭环成本过高生成候选太多训练过频繁统计单轮生成和训练费用先用 few-shot 缓存替代微调逐步迭代在实际项目中最难排查的往往是“模型没有变但 Harness 配置被无意间修改了”这种情况。比如某个同事为了修一个 bug在工具函数里顺手改了返回字段格式结果整个评判器立刻不工作了。因此Harness 配置必须像代码一样被管理这一点怎么强调都不过分。9. 最佳实践与工程建议最后整理一些可以立即用起来的工程建议。**第一把 Harness 视为一等代码。**不要只在代码里散落着 prompt 模板和判题逻辑。建立统一的 Harness 接口并把每个任务的执行环境和评判规则做成配置文件放进 Git 仓库。版本号要记录在每次模型评估结果中。**第二建立黄金回归集。**黄金回归集不需要很大但要覆盖核心业务链路。每次更换 Harness、升级模型、更新数据回流规则之前都必须在黄金回归集上跑一遍。通过率下降超过阈值就禁止发布。**第三自进化更新必须经过灰度。**即使新 Harness 在离线回归集上表现很好也不能立刻全量切换。建议先在 10% 的流量上运行一段时间对比任务通过率、用户反馈、人工抽检结果确认无异常后再逐步扩大。**第四做好安全边界。**如果自进化系统需要收集真实用户数据必须确保用户授权、数据脱敏和合规处理。代码执行沙箱要限制文件系统、网络和系统调用防止模型生成的恶意代码造成破坏。模型输出也要经过内容安全过滤避免有害信息进入业务链路。**第五让数据回流具备可审计性。**每条回流到训练集的样本都应该能追溯到原始生成记录、Harness 版本、评判得分和执行日志。这样可以随时定位是哪个环节污染了数据。**第六从小任务子集开始。**不要一开始就搭建完整的在线学习系统。先挑一个业务场景、几十条任务、一个 Harness跑通自进化闭环再逐步扩展。这样可以降低成本和风险也更容易验证“自进化是否真的有效”。**第七主动防御奖励黑客。**定期人工抽查模型输出观察是否存在为了得分而走捷径的模式。如果发现模型生成结果高度一致、句式相似、关键词堆砌很可能是奖励黑客需要调整评判标准。10. 总结与后续学习方向回到开头的那个问题“模型换个 Harness 就变笨”不是模型厂商偷偷动了手脚而是我们没有给模型一个稳定、可预期、可验证的运行和反馈环境。把 Harness 当作系统工程来做是自进化 AI 产品化过程中非常关键的一步。EverMind 这类产品的价值在于把自进化从论文里的实验循环变成产品里可以稳定运行的闭环。对普通开发者而言不需要一步到位搭建完整系统可以先从三件事入手把 Harness 配置纳入版本管理、建立黄金回归集、在小范围任务上跑通自进化筛选再考虑接入微调。后续值得继续深入的方向包括更鲁棒的评判器设计、自进化数据的去重与清洗、多智能体场景中的 Harness 编排、以及在真实业务中如何平衡自进化成本和效果。如果你正在做 Agent 或模型产品建议先把 Harness 的版本管理和回归测试落地这一步做完你会立刻发现模型的表现比以前稳定得多。真正的“越用越聪明”不是模型凭空变聪明而是模型、Harness 和数据闭环这套系统在协作中不断变强。
自进化AI的隐形陷阱：换个Harness就变笨？工程化解法
很多做 LLM 应用的开发者都遇到过这样一种非常诡异的场景基座模型一个版本没换prompt 模板也只是在原有基础上微调结果一换评估脚本分数立刻掉了十个点或者今天在测试环境里还能稳定运行的 Agent部署到产品环境后开始频繁答非所问。于是有人怀疑模型被偷偷换掉了有人怀疑评测数据写错了但排查到最后问题往往出在模型外面的那层壳——Harness。Harness 这个词并不是新概念但最近它因为 DeepSeek-Harness、Codex-Harness 等一系列开源项目重新回到了开发者视野。简单理解Harness 就是围绕模型的所有工程约束输入格式、上下文窗口、工具调用协议、执行沙箱、判题标准、数据回流规则。同一个模型在不同的 Harness 里表现可能完全不同。这个现象在普通应用中只是兼容成本但在自进化 AI 场景里会被循环放大最终变成“模型越跑越笨”的灾难。这篇文章想聊清楚三件事第一为什么“换个 Harness 就变笨”不是玄学而是自进化系统里最常见的工程陷阱第二像 EverMind 这样把自进化从研究推向产品的产品到底在解决什么第三作为开发者怎么用工程手段让一个自进化闭环稳定地“越用越聪明”而不是越跑越偏。1. 这篇文章真正要解决的问题先给出一个判断模型能力 模型权重 Harness 数据闭环。这个公式看起来没有“模型能力”这个词性感但恰恰解释了最多真实世界的效果波动。很多团队把大量资源花在选基座模型、调 prompt、做 RAG 检索上却忽视了 Harness 和自进化数据回流的一致性。尤其是在 Agent 场景里模型输出要经过工具调用、代码执行、外部 API 返回等多个环节任何一个环节的 Harness 变了最终效果都可能大幅波动。你以为是模型退化实际上是把模型放进了一个更糟糕的“跑道”。而自进化 AI 对 Harness 的敏感度比普通应用高一个量级。普通应用里模型输出一次就算完事自进化系统里模型输出会被执行、被评判、被筛选、被回流成训练数据然后再迭代。Harness 的偏差会在每一轮循环中被不断放大。如果第一次筛选时标准就有问题后面所有轮次都是在强化错误的模式。这篇文章的读者应该是正在做 Agent、RAG、模型评测、数据回流、AI 产品化的工程师。如果你的目标是让一个 AI 系统在真实场景中持续变强那你就必须理解模型参数不是唯一的杠杆Harness 才是那个最容易忽略、也最容易致命的部分。2. 自进化 AI 的核心原理与 Harness 的作用自进化 AI 不是指模型自己修改自己的权重而是指一个系统可以自动完成“生成 → 执行 → 评判 → 筛选 → 训练”的闭环。以代码生成模型为例模型先根据需求写一段代码Harness 负责在沙箱中执行这段代码评判器根据测试用例判断代码是否通过通过的高质量代码会被写回训练集或缓存用于下一轮优化。这就是一个最小的自进化闭环。自进化常见的三种模式自指令Self-Instruction模型自己生成问题再自己生成答案通过 Harness 过滤后作为训练数据。自对弈Self-Play多个模型副本相互生成和对抗评判器负责打分。迭代偏好优化Iterative Preference Optimization通过生成多个候选结果结合人工或模型偏好构建对比样本再反馈到模型训练中。这三条路径都离不开 Harness。Harness 是承载自进化闭环的“跑道”它不仅影响单次输出质量更决定了哪些反馈能进入下一轮学习。Harness 层次包含内容对自进化的影响输入编排prompt 模板、few-shot、指令解析决定任务难度与分布执行沙箱代码执行、API 调用、工具返回决定能否获得真实反馈评判器规则判分、LLM Judge、奖励模型决定哪些数据被回流数据回流去重、清洗、格式转换、样本筛选决定训练数据质量版本与监控Harness 配置版本、指标追踪决定循环是否可收敛一个很常见的误区是认为 Harness 只是“调用模型的工具代码”。实际上Harness 是模型与外部世界之间的完整协议。它决定了模型能看到什么信息、能调用什么工具、输出如何被验证。在普通单项任务里不同 Harness 的差异可能只是几个 token 的格式问题但在自进化系统里这种差异会直接污染训练数据。所以如果你发现“同一个模型换了个 Harness 就变笨”不要急着怀疑模型先把两个 Harness 的所有输入输出协议逐项对比一遍。3. EverMind 是什么自进化从研究走向产品从项目标题和公开定位来看EverMind 想做的事很清晰把自进化能力做成一个产品级引擎让 AI 系统在真实使用中不断积累反馈并通过 Harness 自动优化实现“越用越聪明”。研究里的自进化原型通常只要求“能跑通”。论文中的实验只需要在固定的 benchmark 上验证一次不需要考虑长期运行的稳定性。但产品中的自进化必须回答几个非常现实的问题反馈数据不可信怎么办用户行为、代码执行结果、模型打分都可能包含噪声。效果下滑怎么回滚模型不是只训练一次而是需要持续迭代。训练数据从哪里来能不能在合法合规的前提下使用用户反馈。成本上限在哪里每一轮生成、执行、评审、训练都有费用。如何防止奖励黑客模型可能会找到评判器的漏洞而不是真正变强。EverMind 这类产品的核心价值就是把这些研究问题工程化。它不再把 Harness 当成测试时的一次性工具而是把它升级为可以持续运行、可观测、可回滚的工程基础设施。从产品模块上看一个自进化引擎通常包括数据接入层从真实使用日志、任务池、评测集中采集原始数据。Harness 编排层根据任务类型选择对应的执行环境、工具集和评判器。评测筛选层对生成结果打分、去重、过滤。模型更新层基于高质量数据做微调、偏好优化或缓存更新。安全与回滚层对更新内容做回归测试异常时快速回滚。需要注意的是我没有把“EverMind”的 API 写进本文因为不同阶段的产品的接口变化很大。更稳妥的判断是EverMind 想做的不是一个单独的模型而是一套让 AI 持续进化的产品化基础设施。它的产品形态很可能围绕“任务执行 数据回流 模型迭代”这一完整链路展开。4. 为什么换个 Harness 就「变笨」三个典型原因前面反复强调 Harness 很重要但它到底在哪些环节影响模型效果下面拆成三个典型原因每个原因都会在实际项目中出现。4.1 评估口径变了最常见的原因不是模型变蠢了而是你和模型“约定”的语言变了。不同 Harness 可能使用不同的 prompt 模板、few-shot 示例、输出解析规则和判题标准。比如旧 Harness 要求模型输出 JSON新 Harness 却要求模型输出 Markdown模型还在按旧格式输出自然被判为“错误”。在自进化系统里这个问题的危害更大。因为 Harness 变化后评判器也会变化。同一个答案在旧 Harness 下得 0.9 分在新 Harness 下可能只有 0.4 分。如果你不做配置版本管理下一轮训练就会把这些“被误杀”的样本剔除掉反而留下了一堆迎合新格式但没有真正提高能力的样本。4.2 执行环境变了对于代码生成、Agent 工具调用、数据分析这类任务执行环境是 Harness 中最关键的部分。模型生成结果后Harness 需要在沙箱中执行代码、调用 API、处理超时和错误。只要环境依赖不同结果就可能完全不同。举个非常常见的例子旧 Harness 的 Python 环境里安装了requests库模型生成的代码依赖它执行成功新 Harness 的沙箱里没有requests执行立刻失败。如果你只看执行成功率会以为“模型变笨了”实际上只是环境缺了一个库。还有上下文截断问题。Agent 在长时间任务中会产生大量中间步骤如果 Harness 对上下文的截断策略不同模型能看到的有效信息就会不同最终结果自然千差万别。4.3 数据回流链路变了自进化系统里Harness 还承担着“数据把关人”的角色。新 Harness 的产生会改变哪些数据被保留、哪些数据被丢弃。例如旧 Harness 的判题器只检查最终答案是否正确新 Harness 又增加了“是否包含推理过程”这个标准。这个变化本身可能是合理的但如果新旧 Harness 同时运行回流到数据仓库的样本分布会发生偏移。新样本偏重推理过程旧样本偏重结果两批数据混在一起训练模型就会变得犹豫不决显得“笨”了不少。4.4 隐蔽的奖励黑客这一点容易被忽略。自进化系统最怕的不是“不聪明”而是“用错误的方式变聪明”。当 Harness 的评判规则过于简单、过于固定时模型会通过大量试探发现规则盲区并生成那些能拿到高分但实际没有完成任务的结果。这就是奖励黑客Reward Hacking。比如判题器只检查输出中是否包含某个关键词模型就会学会把关键词堆进答案判题器检查代码输出是否包含status: ok模型就会学会打印这个字符串而不是真正完成任务。Harness 在这里的职责不只是“执行和打分”还要隔离这种投机行为。一个健壮的自进化 Harness需要同时包含规则判定、模型判定和人工抽检不能给模型太多“被 hack”的确定性。5. 一个可落地的自进化最小闭环设计了解了理论之后下面给出一套可以真正落地的自进化最小闭环方案。它不需要一开始就做大规模模型训练适合从 0 到 1 验证自进化思路。整个闭环包括以下组件任务池存放一批真实业务任务每个任务包含指令和可验证的参考结果。Harness 层为每类任务提供统一的执行和评判接口。生成器基座模型封装负责产生候选答案。评判器可以是规则判分、LLM Judge也可以是人工抽检。数据仓库存储通过筛选的高质量样本。优化器第一版可以只把高质量样本用于少量示例缓存第二版再接入微调或偏好优化。工作流程如下从任务池中采样一个任务。通过生成器产生多个候选答案。Harness 在真实或模拟环境中执行候选答案。评判器综合得分筛选出超过阈值的样本。将高质量样本写入数据仓库。周期性用新样本对模型做回归测试。如果指标稳定再决定是否更新模型。这套闭环的关键是“先稳定后进化”。第一版不建议直接开始微调而是先收集一批经过 Harness 验证的高质量样本把它们作为 few-shot 示例或行业知识缓存接入推理链路。这样成本低、速度快也能验证“数据回流是否真的能提升效果”。当收集到的有效样本达到一定数量后再考虑用这些样本进行轻量级微调比如使用 LoRA。每轮更新前必须把旧模型和旧 Harness 版本都保留下来用于 A/B 对比和回滚。6. Harness 与自进化代码示例下面用几个精简代码示例来说明 Harness 和自进化数据闭环的工程实现。示例只做关键逻辑演示不绑定任何特定大模型 SDK读者可以把模型调用替换成自己的线上接口。6.1 定义统一的 Harness 接口文件路径self_evolving/harness/interface.pyfrom abc import ABC, abstractmethod from dataclasses import dataclass, field from typing import Any, Dict, Optional dataclass class ExecutionResult: status: str # PASS / FAIL / ERROR output: str error: Optional[str] None raw: Dict[str, Any] field(default_factorydict) dataclass class JudgeResult: score: float # 0.0 ~ 1.0 passed: bool reason: str class Harness(ABC): 一个 Harness 封装了模型执行一个任务所需的全部外部条件。 abstractmethod def setup(self) - None: 初始化执行环境比如启动沙箱、加载工具包。 abstractmethod def execute(self, prompt: str, generation: str) - ExecutionResult: 把模型生成结果放到真实环境中执行并返回执行结果。 abstractmethod def judge(self, prompt: str, generation: str, exec_result: ExecutionResult, reference: Optional[str] None) - JudgeResult: 根据统一标准判断该结果是否值得被回流。核心意义在于每个任务都实现同一套接口。后续的自进化数据筛选、模型回归测试都依赖这套接口从而避免“换个 Harness 就换一套逻辑”的问题。6.2 自进化数据筛选脚本文件路径self_evolving/select_samples.pyfrom dataclasses import dataclass from typing import Any, Dict, List from self_evolving.harness.interface import Harness, JudgeResult dataclass class EvolveSample: task_id: str instruction: str generation: str score: float execution: Dict[str, Any] class SelfEvolveDataLoop: 一个极简自进化数据过滤闭环。 它的作用不是训练模型而是从大量生成结果中筛出高质量样本 为后续的 few-shot 缓存或微调做准备。 def __init__(self, harness: Harness, threshold: float 0.8): self.harness harness self.threshold threshold def process_task(self, task: Dict[str, Any], generate_fn) - List[EvolveSample]: instruction task[instruction] num_samples task.get(num_samples, 3) good: List[EvolveSample] [] for _ in range(num_samples): generation generate_fn(instruction) exec_result self.harness.execute(instruction, generation) judge_result: JudgeResult self.harness.judge( promptinstruction, generationgeneration, exec_resultexec_result, referencetask.get(reference), ) if judge_result.passed and judge_result.score self.threshold: good.append( EvolveSample( task_idtask[id], instructioninstruction, generationgeneration, scorejudge_result.score, execution{ status: exec_result.status, output: exec_result.output, error: exec_result.error, }, ) ) return good这里的generate_fn是模型生成函数可以直接调用你线上的大模型接口也可以换成从离线日志中读取历史结果。整个流程遵循“先执行、再评判、后筛选”的顺序确保只有真正经得起验证的样本才会被保留。6.3 A/B 回归测试判断模型是不是真的变笨了文件路径harness_regression/ab_test.pyfrom dataclasses import dataclass from typing import Any, Dict, List, Optional from self_evolving.harness.interface import Harness, ExecutionResult, JudgeResult dataclass class MockModel: 极简模型封装模拟模型对 system prompt 格式的敏感性。 name: str def generate(self, instruction: str, system_prompt: str) - str: if 必须输出JSON in system_prompt: return {result: ok} return ok class MockHarness(Harness): 用格式检查和关键词匹配做判定的演示 Harness。 def __init__(self, system_prompt: str, require_json: bool True): self.system_prompt system_prompt self.require_json require_json def setup(self) - None: pass def execute(self, prompt: str, generation: str) - ExecutionResult: if self.require_json and not generation.strip().startswith({): return ExecutionResult(statusERROR, output, errorJSON格式错误) return ExecutionResult(statusPASS, outputgeneration) def judge(self, prompt: str, generation: str, exec_result: ExecutionResult, reference: Optional[str] None) - JudgeResult: if exec_result.status ERROR: return JudgeResult(score0.0, passedFalse, reasonexec_result.error) if reference and reference not in generation: return JudgeResult(score0.0, passedFalse, reason答案不匹配) return JudgeResult(score1.0, passedTrue, reasonok) def evaluate_with_harness(model, harness, dataset) - Dict[str, float]: passed 0 for item in dataset: gen model.generate(item[prompt], getattr(harness, system_prompt, )) exec_result harness.execute(item[prompt], gen) judge_result harness.judge( item[prompt], gen, exec_result, item.get(reference) ) if judge_result.passed: passed 1 return {pass_count: passed, pass_rate: passed / len(dataset)} if __name__ __main__: dataset [ {prompt: 请返回状态, reference: ok}, ] model MockModel(namebase-llm) old_harness MockHarness(system_prompt必须输出JSON, require_jsonTrue) new_harness MockHarness(system_prompt请直接回答, require_jsonTrue) print(old_harness:, evaluate_with_harness(model, old_harness, dataset)) print(new_harness:, evaluate_with_harness(model, new_harness, dataset))这个示例里模型本身没有变化。只是新 Harness 的 system prompt 去掉了“必须输出 JSON”的指令但require_json仍然为 True于是模型输出ok后执行阶段直接报错。运行结果会显示 old_harness 的通过率是 1.0new_harness 是 0.0。这就是一次典型的“换个 Harness 就变笨”回归场景。真实项目中你不需要用 Mock 类而是为线上环境分别封装两个真实 Harness并在同一批固定回归集上运行观察指标变化。6.4 用配置文件管理 Harness 版本文件路径configs/harness_v1.yamlharness: name: code-exec-sandbox version: v1 model: provider: openai-compatible model_name: gpt-4o-mini prompt: system_template: 你是一个Python工程师。只输出代码不要额外解释。 user_template: 请完成以下任务{task} max_tokens: 1024 temperature: 0.2 tools: python_executor: enable: true timeout_seconds: 10 max_output_chars: 2000 judge: metric: exact_match pass_threshold: 0.7把 Harness 配置纳入 Git 管理每次变更都要走 code review。这样当某个版本效果下降时可以快速 diff 出是哪一行 prompt 或哪一个配置项引起的。7. 运行结果与效果验证如何判断模型真的在变聪明这里需要区分两层验证。第一层是回归测试用于回答“模型是否变笨”。运行ab_test.py时如果新旧 Harness 在同一个黄金评测集上的通过率差异超过阈值就应该停止上线检查配置差异。这一步的要点是必须固定评测集不能每次换数据。第二层是自进化闭环验证用于回答“模型是否越用越聪明”。建议记录以下指标指标说明判断方式任务通过率Harness 执行后通过判定的任务占比持续上升高分样本占比筛选出的高质量样本占全部生成样本的比例稳定或上升数据多样性回流样本的指令覆盖度、语义聚类数不能单调下降人工抽检通过率随机抽查一批模型输出人工判断质量不能低于安全线旧任务回归率在历史测试集上的通过率不能明显回退奖励黑客出现率通过关键词侥幸得分但实际未完成任务的样本比例越低越好运行自进化闭环时不能只看“合格样本变多”。如果筛选标准过于宽松合格样本会越来越多但模型能力没有真正提升如果筛选标准过于苛刻数据多样性下降模型会很快陷入局部最优在旧任务上也可能变笨。建议每一次闭环实验都保存快照Harness 版本、模型版本、训练数据版本、评测结果。这样无论哪个环节出问题都能在几分钟内定位并回滚。8. 常见问题与排查思路下面汇总自进化 Harness 项目里最常见的几类问题方便你在实践中快速排查。问题现象可能原因排查方式解决方案更换 Harness 后同一基座模型准确率骤降prompt 模板、few-shot、判题标准不一致对比新旧 Harness 配置跑同一回归集统一输入输出协议Harness 配置入 Git自进化训练若干轮后效果先升后降数据分布坍缩过度筛选同质样本统计训练集多样性画 score 分布增加采样随机性保留困难样本模型开始故意迎合判题器奖励黑客人工抽检模型输出看是否存在投机模式混合使用规则、LLM Judge 与人工评审产品环境反馈数据太脏训练后效果变差未做去重、清洗、隐私过滤检查回流数据流水线增加数据质量门槛和隐私过滤模块微调后旧能力明显遗忘灾难性遗忘在旧任务回归集上跑测试混合旧数据训练或使用低秩微调自进化闭环成本过高生成候选太多训练过频繁统计单轮生成和训练费用先用 few-shot 缓存替代微调逐步迭代在实际项目中最难排查的往往是“模型没有变但 Harness 配置被无意间修改了”这种情况。比如某个同事为了修一个 bug在工具函数里顺手改了返回字段格式结果整个评判器立刻不工作了。因此Harness 配置必须像代码一样被管理这一点怎么强调都不过分。9. 最佳实践与工程建议最后整理一些可以立即用起来的工程建议。**第一把 Harness 视为一等代码。**不要只在代码里散落着 prompt 模板和判题逻辑。建立统一的 Harness 接口并把每个任务的执行环境和评判规则做成配置文件放进 Git 仓库。版本号要记录在每次模型评估结果中。**第二建立黄金回归集。**黄金回归集不需要很大但要覆盖核心业务链路。每次更换 Harness、升级模型、更新数据回流规则之前都必须在黄金回归集上跑一遍。通过率下降超过阈值就禁止发布。**第三自进化更新必须经过灰度。**即使新 Harness 在离线回归集上表现很好也不能立刻全量切换。建议先在 10% 的流量上运行一段时间对比任务通过率、用户反馈、人工抽检结果确认无异常后再逐步扩大。**第四做好安全边界。**如果自进化系统需要收集真实用户数据必须确保用户授权、数据脱敏和合规处理。代码执行沙箱要限制文件系统、网络和系统调用防止模型生成的恶意代码造成破坏。模型输出也要经过内容安全过滤避免有害信息进入业务链路。**第五让数据回流具备可审计性。**每条回流到训练集的样本都应该能追溯到原始生成记录、Harness 版本、评判得分和执行日志。这样可以随时定位是哪个环节污染了数据。**第六从小任务子集开始。**不要一开始就搭建完整的在线学习系统。先挑一个业务场景、几十条任务、一个 Harness跑通自进化闭环再逐步扩展。这样可以降低成本和风险也更容易验证“自进化是否真的有效”。**第七主动防御奖励黑客。**定期人工抽查模型输出观察是否存在为了得分而走捷径的模式。如果发现模型生成结果高度一致、句式相似、关键词堆砌很可能是奖励黑客需要调整评判标准。10. 总结与后续学习方向回到开头的那个问题“模型换个 Harness 就变笨”不是模型厂商偷偷动了手脚而是我们没有给模型一个稳定、可预期、可验证的运行和反馈环境。把 Harness 当作系统工程来做是自进化 AI 产品化过程中非常关键的一步。EverMind 这类产品的价值在于把自进化从论文里的实验循环变成产品里可以稳定运行的闭环。对普通开发者而言不需要一步到位搭建完整系统可以先从三件事入手把 Harness 配置纳入版本管理、建立黄金回归集、在小范围任务上跑通自进化筛选再考虑接入微调。后续值得继续深入的方向包括更鲁棒的评判器设计、自进化数据的去重与清洗、多智能体场景中的 Harness 编排、以及在真实业务中如何平衡自进化成本和效果。如果你正在做 Agent 或模型产品建议先把 Harness 的版本管理和回归测试落地这一步做完你会立刻发现模型的表现比以前稳定得多。真正的“越用越聪明”不是模型凭空变聪明而是模型、Harness 和数据闭环这套系统在协作中不断变强。