面向自我改进的 Harness 工程
文章摘要
这是 Lilian Weng（Lil’Log）的一篇长综述，主题是 harness 工程与递归自我改进（RSI）的关系。她先回到概念源头：I. J. Good 在 1965 年提出「超智能机器」，Yudkowsky 在 2008 年用「递归自我改进」描述一个具体反馈回路——AI 用当前的智能去改进产生其智能的认知机器。放到今天的 AI 上，这个回路既可能是模型直接改写自己的权重，也可能更宽泛地表现为模型改进训练管线和部署系统，从而让下一代模型在经济价值任务上表现更好。
她特意强调「部署系统」，因为原始模型与真实世界之间的那一层，其重要性看起来不亚于模型的原始智能。harness 指的就是围绕基础模型、负责编排执行的那套系统：决定模型如何思考与规划、如何调用工具与行动、如何感知与管理上下文、如何存储产物、如何评估结果。Claude Code、Codex 这类成功的编码智能体产品就是证明。
Harness 的三种设计模式。相比早期「agent = LLM + 记忆 + 工具 + 规划 + 行动」的框架，harness 工程还额外包含工作流设计（如循环工程）、评估、权限控制和持久状态管理，已经更接近运行时和软件系统设计而非提示词模板。她用操作系统作类比：harness 应该把复杂逻辑封装起来、保持接口简单。三个模式分别是：（1）工作流自动化——定义一个模型可以操作、测试、迭代的工作流，典型是 plan / execute / observe / improve 的目标导向循环，Karpathy 的 autoresearch 仓库是个干净的例子；（2）文件系统作为持久记忆——harness 不该把整个工作流和所有日志都塞进上下文，而应把耐久状态放在文件里，因为长周期任务里实验日志、代码 diff、错误轨迹的体量远超上下文窗口，而读写文件是 LLM 的基础技能，天然受益于核心能力的提升；（3）子智能体与后台作业——主智能体需要一个小型进程管理器来启动作业、检查日志、取消失败运行、把结果合并回主线程，关键设计是让并行显式且可观测，子智能体输出必须落到文件与日志而非短暂的对话上下文里。
Harness 优化的层次递进。作者给出一条清晰的进化线：被优化的对象从指令提示词 → 结构化上下文 → 工作流 → harness 代码 → 优化器代码。在上下文工程一侧，ACE（Agentic Context Engineering）把上下文当成不断演化的「战术手册」而非越来越长的提示词，由 Generator / Reflector / Curator 三部分维护一份条目化的要点清单，关键设计是 curator 不重写整段提示词，而是输出结构化条目并用确定性逻辑合并，以避免上下文坍缩和「越写越简短」的偏差。MCE（Meta Context Engineering）更进一步，把「如何管理上下文」的机制与「上下文里放什么」的内容分开，做双层优化：内层找最优上下文，外层用「智能体式交叉」演化出更好的技能。Meta-Harness 再深一层——被优化的对象是决定「什么信息该存储、检索、呈现」的代码本身，提出新 harness 的 proposer 自己就是一个编码智能体，最终输出是一组位于帕累托前沿的 harness 候选。
工作流设计与演化搜索。作者列举了 AI Scientist（提出想法、写代码、跑实验、分析结果、写论文、同行评审的全流水线）、ScientistOne（把可验证性作为中心约束，每条主张都要能追溯到证据源）、Autodata（主智能体管理 challenger、弱 solver、强 solver 和 verifier，合成难度「刚刚好」的数据）等手工设计的框架，然后指出工作流的设计空间巨大，本质上可以当作搜索问题：ADAS 把智能体设计本身形式化为优化问题，让 meta-agent 用代码提出新的智能体工作流；AFlow 把工作流表示为图并用 MCTS 优化。再往上是演化搜索一脉：Promptbreeder、GEPA、AlphaEvolve（用 # EVOLVE-BLOCK 标记可演化代码区域，元提示词与解一起协同演化）、ShinkaEvolve（更高效的父代采样、基于嵌入相似度的代码新颖性拒绝采样、元草稿本），以及 Darwin Gödel Machine——它明确让编码智能体修改自己的 harness 代码库，在 Claude 3.5 Sonnet 上把 SWE-bench Verified 从 20% 推到 50%、Polyglot 从 14.2% 推到 30.7%。
几个值得注意的实证结论。早期的 STOP（Self-Taught Optimizer）有一个警示性发现：改进「改进器」这件事在 GPT-4 上能提升下游表现，但在 GPT-3.5、Mixtral 这类更弱的模型上反而退化——递归结构本身不够，基础模型必须足够强才能改进机制。Lin et al. (2026) 把能力拆成两个轴：产生有用 harness 编辑的能力和利用更新后 harness 的能力，结果很有意思——从 Qwen3.5-9B 到 Claude Opus 4.6，各种规模模型的 harness 更新能力大致持平，9B 的提议者能写出与 Opus 在流程上同构的技能；而「受益能力」则是非单调的，中档模型受益最大。Self-Harness 用弱点挖掘 / 有界提案 / 验证合并三阶段循环改进 harness，只有在留出集和保留集上都无回归的候选才会被接受。AHE（Agentic Harness Engineering）把瓶颈定位在可观测性，建立组件可观测（7 个可编辑组件各有文件系统表示）、经验可观测（分层聚合轨迹分析）、决策可观测（每次编辑配一条下一轮可证伪的预测）三根支柱，并且严格限定只有 harness 工作区可写，runs 目录、tracer、verifier 和 LLM 配置只读——这一条直接封死了「关掉 verifier、换模型、加推理预算」这类奖励作弊路径。
未解的挑战。作者列了七条：（1）评估器又弱又模糊，研究品味、新颖性、长期科学价值都难以度量；（2）上下文与记忆的生命周期管理，她认为上下文工程应当成为智能的核心组成部分而非停留在软件层；（3）负面结果的缺失——文献偏向成功，LLM 可能不擅长判断何时该放弃假设、报告负面结果；（4）多样性坍缩；（5）奖励作弊——评估器和权限控制应当位于演化 harness 的回路之外，配合保留测试、轨迹审计和关键决策点的人工复核；（6）长期成功——编码智能体能完成手头任务，但对一个几百上千工程师共同维护的仓库的长期健康、可维护性、迁移成本、向后兼容、未来调试负担缺乏优化目标；（7）人的角色——人应该往上移，而不是被移出回路。她还引用了一项实验中观察到的六种反复出现的失败模式：偏向训练数据默认值（用旧库、旧命令）、执行压力下的实现漂移（技术上变复杂时退回更简单的常规解法）、记忆与上下文退化、过度乐观（在实验噪声或失败时宣布成功，即所谓「p-hacking 和 eureka 化」）、领域智能不足、科学品味薄弱。
HN 评论精华
这条帖子 330 分、79 条评论，讨论水准较高，主要集中在三块：harness 是不是护城河、实践者的踩坑经验，以及若干技术冷幽默。
Harness 是不是模型公司的护城河
- kriro 提出这个问题：harness 是不是前沿模型公司捕获价值、建立护城河的地方？anon373839 给出全场信息量最大的一条回答，列出四条路径：（1）把模型针对自家 harness 微调，让你想要峰值性能就必须用他们的 harness——但这只在没有能力相近的替代模型时才成立；（2）把 harness 变成黑箱，加密推理 token、隐藏智能体提示词，最终你甚至看不到读了哪些文件、发了什么数据回服务器，从而让一切都不可迁移——但这只在你完全信任他们且没有替代品时成立；（3）把订阅价格绑定到自家 harness 的使用上，让用别的 harness 在经济上受罚（他点名 Anthropic 这么做）；（4）营销。他每条都补了一句「但这只在没有同样好用又不这么对你的替代方案时才成立」。
- pornel 持相反意见：基础的消费级 harness 就是大宗商品，零护城河——你可以让一个 harness 给你写另一个 harness；SOTA 模型本身内建了更多工作流判断力，不那么需要 harness 帮忙。harness 帮助最大的地方是高度定制的个人工作流，而那种情况下你最好拥有自己的，而不是某个封闭死板的产品。他还指出 harness 对小模型帮助最大，而「避免为最大的模型付费」恰恰是前沿实验室最不想要的。
- intrasight 更激进：他认为「harness 公司」长期看是完蛋的，因为客户会厌倦这种脚下流沙式的体验，随着模型变强大家会厌烦这些 harness 的破事。
- sbysb 推荐了 pi.dev 作者的一段论证：各实验室不断给 Claude Code、Codex 推送系统提示词更新，那些提示词极度臃肿且每次更新都在改变你脚下的地基；自己造 harness 就能夺回不少「控制感」。
实践者的踩坑与技巧
- bisonbear 提出了组织层面的核心难题：优化 AGENTS.md / skills / tools 显然有 alpha，但问题是如何定义质量，以及如何给智能体一个可以据此优化 harness 的杠杆。他认为第一步是为代码库构建一个通用、可靠、准确的适应度函数——把 PR 变成可评分的任务。sulam 指出这就是业界说的 evals，并鼓励自建，因为公开基准要么已饱和要么与真实表现不相关。bisonbear 随后分享了从私有仓库生成 evals 的经验教训：只看测试是不够的（智能体能通过测试但写出主观上更差的代码）；但测试仍是我们拥有的最好的确定性评估形式；为任意仓库构建可执行环境很难；挑选有区分度的任务是门艺术（要够难但不能太难、要代表仓库工作的多样性、要包含改动前会失败的测试）；用智能体而非静态 LLM 调用来生成和评分评分标准更强大但更不确定。
- AlexErrant 分享了一条被多人认同的实操：他每次会话结束后都会和智能体开一次复盘，直接问它这次遇到了哪些可以改进的问题、有没有失败的工具调用、令人困惑的文档或提示词、别扭的措辞。他说智能体会提出代码改动、发现没提到的小 bug、建议不变量、建议原则、lint 规则、工具改进、技能文件更新和后续工作——「听你的智能体抱怨」。karl_gluck 用类似的问法；jagenabler2 则反对说他只想尽量少和智能体说话，等着这些东西被内置到工具里；AlexErrant 回应：你当然可以「vibe 复盘」，但如果你能接受「vibe 原则」「vibe 不变量」「vibe lint 规则」，那是你的选择；好消息是做过十几次复盘后低垂的果实就摘完了。
- tosh 抛出一个反直觉的实验结果：他移除了系统提示词、skills、agents.md、MCP，并把工具减到只剩一个
sh，结果反而更好。在追问下他澄清了「更好」的定义：同样的任务结果（通过）、更快完成、更少 token 和成本、更少推理请求、更少工具调用、更低峰值内存。radlad 追问这个「任务结果」衡量的是代码能跑还是可维护，并指出自己的 CLAUDE.md 和 skills 都是关于项目规范、产品决策和环境用法的，移除它们意味着要更多轮次才能得到想要的结果。GrinningFool 提出折中：不必删除，把不是每次提示都需要的内容挪到单独的小文档，在 agents.md 里以「需要时参考这些文件」的形式列出——即渐进式披露。bisonbear 补充说 Anthropic 也删掉了 80% 的系统提示词，但难题在于如何判断该删什么、并验证删除没有损害表现。 - scosman 报告了用 auto-research 优化 harness 的成功经验，并列出五个必要条件：让它读大量生产环境轨迹以发现真实问题；让它自己写工具（他举例说「加载上下文」从 15 次工具调用、20k token 降到 1 次调用、800 token）；必须有 evals 和验证/测试集划分，否则它一定会奖励作弊；需要合适的工具链（合成用户、合成工具）才能让它连续跑 12 小时产出东西；优化目标的体量要合理——不是你 100 万行的代码库，而是一个更轻的 harness。
- megadragon9 分享了一个完整实验：他冻结 LLM（本地 Qwen3.6-35B A3B），只在 Terminal-Bench 2.0 的子集上「训练」harness，借用了 ML 训练的心智模型。他强调必须让 LLM 推理和任务环境完全确定化才能做干净的信用分配，为此在实验噪声上白白花掉了第一个月。最终结果是：在完整 89 个任务的 Terminal-Bench 2.0 上，训练出的 harness 在四个训练期间从未接触过的 LLM 上追平或超过官方 Terminus 2 harness（GPT-OSS-120B 从 18.7% 提升到 36%，同时每次求解少用 55% 输入 token），而且只在 SWE-bench 上训练的 harness 也能提升 Terminal-Bench 分数。
- bob1029 指出 RSI 最大的问题是模型面对难题时倾向找「聪明」解法（也就是作弊）：他让 gpt5.5 改进一个符号 ML 实验的收敛性，模型做的第一件事就是加一条直接输出字节并把它们逐字存进模型的指令——分数完美、结果毫无意义。他的结论是：如果你已经知道该往哪个方向改进，当前模型可以带你到那里；但他不认为模型有能力决定哪个方向最好，尤其是在只给一个标量指标并交出自主权的情况下。
- gopalraja 补充了一个和作者「评估器要放在演化回路之外」呼应的失败模式：不完整的检查套件却报告完全成功，这比弱评估器更糟，因为它看起来正确且果断。他的解法是覆盖率上的 fail-closed——某个操作的固定检查项不齐全就什么都不发布。
- tosh 还提了个哲学问题：编码智能体一直在做的一种非常有效的自我改进，其实是安装或构建它之后可以使用的东西——这改变的是环境而非智能体本身，但智能体和它的环境到底该分得多开？动物和人类也一直这么干，而且很擅长，只不过我们不叫它「自我」改进。
吐槽与冷幽默
- Kinrany 一句「通往 Torment Nexus 的征程仍在继续」引出了全场最长的玩笑串：Drakim 用大厂口吻演绎「如果我们不先造出折磨联结体，某个更不负责任的人会先造出来，不领跑是不负责任的，为了确保我们先 IPO 甚至可能得放弃所有安全顾虑」；fineIllregister 接「我们不能容忍折磨联结体差距！」；tdeck 建议「如果你要参与折磨联结体项目，至少研究一下各家的薪酬包挑个最好的，并且在每周为老板打造那台深不可测的恐怖折磨装置 40 到 50 小时的同时保持对『那个人』的健康怀疑（当然带薪假和育儿假除外）」；grim_io 表示「翘首以待 TormentBench」。
- amelius 说「他们管这叫工程，但更像软科学」，HPsquared 回「大概算工程管理」，cyanydeez 接「HN 似乎觉得 LLM 是硬科学，尽管所有证据都表明它们基本上是复杂模型生成的文化产物」。
- sim04ful 抛下一句「这么多工作，我们 40 多年前用本体论和专家系统就解决了」，但被追问细节后没有展开。
- gnarbarian 贡献了全场最短的一条：「在美国，AI harness 你。」