Harness 工程：AI 自我改进先从运行系统开始-优快云博客

Harness 工程运行系统概念图

谈到递归自我改进（Recursive Self-Improvement，RSI），很多人的第一反应是：模型改自己的权重，然后能力一路加速。这个画面很抓人，但离今天的工程现场还有点远。更近的入口，可能是模型外面的那层东西：工作流、工具调用、上下文管理、权限、评估器、文件系统里的状态，以及把这些部件连起来的代码。

这层运行系统通常可以叫 Harness。把它理解成一段提示词太窄，理解成“模型加工具”的包装也不够。它更像一个让模型干活的环境：模型看什么、怎么规划、能调哪些工具、失败后从哪里继续、产物放在哪里、什么时候停下来，都由这层环境决定。Claude Code、Codex、Cursor 这类产品已经把这一点讲得很明白：同一个基础模型，放进不同的 Harness，做事的手感和上限会差很多。

所以，近期可见的 RSI 未必从权重开始。更可能先发生在模型周围：Harness 变好，模型更会做研究、写代码、跑实验；模型变强后，又能回来改 Harness。这个循环没有“机器突然改写自己大脑”那么戏剧化，但更像现在能落地的工程路线。

总览：Harness 是模型周围的运行系统

PART

一、为什么先看 Harness

WHY HARNESS FIRST

I. J. Good 在 1965 年讨论“超智能机器”时，关心的是一种能设计出更好机器的机器。Yudkowsky 后来用“递归自我改进”描述更窄的反馈回路：AI 用当前智能去改进产生智能的机制。

放到今天，至少有两层含义。

第一层是模型直接改进模型，比如重写权重、改训练算法、改数据管线。

第二层更工程化：模型改进训练、评估、部署和工具系统，让自己或下一代模型在任务上表现更好。

Harness 属于第二层。基础模型当然要紧，但模型和真实任务之间还有一个执行层。它决定模型能不能拿到正确上下文，能不能调用合适工具，能不能在失败后定位问题，也决定它会不会在权限和奖励信号上乱跑。

早期智能体框架常被写成一个公式：

EDITOR’S NOTE

摘记

智能体 = 大语言模型 + 记忆 + 工具 + 规划 + 行动

这个公式有用，但太静态。Harness 工程更接近运行时设计。它关心能力清单，也关心这些能力按什么顺序用、怎么检查结果、状态怎么保存、错误怎么恢复、哪些动作不允许做。

好的 Harness 不需要神秘。接口最好简单，内部可以复杂一点。它和操作系统有点像：把麻烦的部分收进去，把稳定的协议露出来。随着更多团队做类似系统，工具协议、上下文格式、权限模型和评估接口大概率会慢慢收敛。

PART

二、几个已经稳定下来的设计模式

PATTERNS

Harness 工程还在变化，但有些模式已经反复出现。它们解决的是同一个问题：怎样让模型从“一次回答”变成“持续执行”。

NOTE1. 工作流自动化：给模型一个能试错的循环

自动化的重点不在一次说对。先让模型跑起来，看到结果，再改。

一个常见循环是：

明确目标和约束。
制定计划。
调工具执行。
看结果，或者跑测试。
找失败原因。
改方案，再执行。
达到目标或触发停止条件后结束。

工作流自动化：从目标到反馈的执行循环

Karpathy 的 autoresearch 仓库就是这种思路的清爽版本。它没有押宝某个万能提示词，而是把研究任务放进可重复运行的循环。Codex 类编码智能体也差不多：模型发起工具调用，工具返回观察结果，下一轮再根据观察继续走。

变化在这里。单次生成只是其中一段，整条执行轨迹才是看能力的地方。模型会分析自己的失败，调整下一步。工程上要设计的，也从提示词模板变成了智能体运行时。

METHOD2. 文件系统记忆：别把所有东西塞进上下文

长周期任务很快会把上下文窗口撑爆。实验日志、代码 diff、论文摘要、错误记录、历史轨迹、中间产物，任何一个都可能比当前上下文更长。

所以很多系统干脆把持久状态放到文件系统里。

文件系统的好处很朴素：

模型已经很熟悉读文件、写文件、grep、改代码这些动作。
文件天然支持增量读写和检索。
任务中断后还能恢复。
历史记录可以审计，不会消失在临时对话里。

这不花哨，但管用。把记忆做成普通文件，比做成一个模型看不懂的黑盒记忆系统更容易调试，也更容易吃到基础模型能力提升的红利。

INTERFACE3. 子智能体和后台任务：并行可以，但要留下痕迹

复杂任务经常需要并行。主智能体可能要同时验证几个假设，跑多组实验，或者把某个独立子问题丢给另一个智能体处理，免得主上下文被细节淹没。

这时 Harness 需要一点进程管理能力：启动任务、看日志、停掉失败运行、收集结果，再把有用部分合并回主线。

并行本身不难，难的是让过程能看见。子智能体的输出如果只停在临时对话里，很快就没人知道它当时为什么这么做。更稳的做法是把输出落成文件、日志和状态记录。之后无论是模型还是人，都能回来查。

PART

三、编码智能体已经给出一套接口样板

INTERFACE

编码智能体特别适合观察 Harness，因为软件开发本来就有工具、状态、测试和反馈。

Claude Code、Codex、OpenCode、Cursor 风格智能体的接口正在变得相似。它们围绕一个代码仓库工作，像带着 IDE、终端和 Git 的开发者。

常见工具大致是这些：

类别

典型能力

文件系统

文件发现、全文搜索、目录浏览、读取文件、批量读取、创建文件、编辑文件、应用补丁

Shell 执行

运行 Bash、PowerShell 或项目脚本

代码智能

LSP、类型检查、测试、格式化、构建

Git 工具

查看状态、查看差异、提交变更、生成补丁

外部上下文

MCP 工具、Skills、知识库、项目文档

网络能力

搜索、抓取网页、浏览器自动化

产物处理

读取文档和图片，生成 HTML、图片或报告

后台进程

创建、查看和删除长期任务

智能体委托

生成子智能体、恢复任务、等待结果、中断或关闭任务

编码智能体的 Harness 接口层

有了这些接口，模型就不用停在“写一段代码建议”这一步。它可以在仓库里真实开发、运行、调试、验证。代码仓库、测试输出、终端日志和 Git diff 合起来，构成了一个可操作的环境。

这对 RSI 也有启发：Harness 本身是代码，代码可以被模型修改。只要 Harness 能执行、能评估、能回滚，它就进入了可以被搜索和优化的范围。

PART

四、优化对象在往上走

OPTIMIZATION

过去大家先优化提示词。后来开始优化结构化上下文，再后来是工作流、编排代码。再往后，连“优化器怎么优化”也会成为对象。

可以简单写成：

EDITOR’S NOTE

摘记

指令提示词 → 结构化上下文 → 工作流 → Harness 代码 → 优化器代码

优化对象从提示词上移到 Harness 与优化器代码

提示词当然还在。只是模型越强，越会去改“怎样得到答案”这件事。答案本身只是最后一层产物。

STACK1. 上下文工程：把长提示词改成可维护的手册

把所有工具响应和模型输出一直追加到上下文里，短任务还能凑合，长任务很快失控。上下文工程要做的，是把模型需要的信息组织成更短、更准、更容易维护的状态。

ACE（Agent Context Engineering，Zhang 等，2025）把上下文看成一本会更新的战术手册，而不是一条越拖越长的提示词。它有三个角色：生成器参考手册执行任务；反思器从成功和失败轨迹里总结经验；策展器把新经验增量写回手册。

ACE 一个聪明的地方是，它不让策展器每次重写整段提示词，而是输出带标识符的条目，再用确定性逻辑合并到上下文日志里。这样可以减少反复重写造成的信息塌缩，也不会让提示词越改越像一句空泛口号。

MCE（Meta-Context Engineering，Ye 等，2026）再往前走一步，把“怎么管理上下文”和“上下文里放什么”分开。元层优化技能，基础层优化当前任务上下文。

一个 MCE 技能 s \in \mathcal{S} 可以写成上下文函数：

其中，\rho_s = {\rho_1,\dots,\rho_m} 是静态组件，比如提示词、知识库和代码库；F_s = {F_1,\dots,F_k} 是动态操作，比如搜索、选择、过滤和格式化。

双层优化可以写成：

直白一点说，内层在当前技能下找好上下文，外层找更好的技能。实现上，上下文函数可以落到一个目录里，里面有 skill.md、上下文文件、数据展开和执行记录。模型用 Read、Write、Edit、Bash、Glob、Grep 这些普通工具操作它们。

Meta-Harness（Lee 等，2026）更直接：它优化的是决定哪些信息该存、该取、该交给模型的代码。也就是说，优化范围包括上下文内容，也包括管理上下文的程序。一旦测试框架变成可执行的搜索空间，编码智能体就能用工程师熟悉的办法去改它。

CONTEXT2. 工作流设计：从专家经验到元智能体搜索

自动研究系统很能说明工作流的价值。

AI Scientist（Lu 等，2026）把研究过程拆成想法生成、代码编写、实验运行、结果分析、论文撰写和评审。ScientistOne（Meng 等，2026）把可验证性放在前面，要求引用、数值、方法、结论都能追到证据来源，并通过证据链检查。

Autodata（Kulikov 等，2026）让主智能体协调挑战者、弱求解器、强求解器和验证者，合成难度“刚刚好”的训练与评估数据：强求解器能做出来，弱求解器做不出来。挑战者提示词会根据求解器和验证器反馈继续改。

这些例子说明，工作流本身就是能力的一部分。但工作流空间太大，只靠专家手写很难扫完。

ADAS（Automated Design of Agentic Systems，Hu 等，2025）把智能体设计当成优化问题，也就是让元智能体搜索智能体。它从思维链、自我修正这类简单工作流开始，维护一个方案存档；然后让元智能体参考已有方案，用代码写出新的工作流。新方案经过自我反馈、评估和筛选后，再放回存档。

AFlow（Zhang 等，2025）把智能体工作流表示成图：节点是大语言模型调用，边是代码里的逻辑操作。它用蒙特卡洛树搜索来改工作流：

用模板初始化起始工作流W_0。
按分数和探索策略选择一个节点。
让大语言模型根据评估结果修改工作流。
执行并评估新工作流。
新工作流如果变好，就加回搜索树。
继续搜索，直到分数不再明显上升或预算用完。

在问答、代码和数学任务上，AFlow 的结果好过人工工作流和 ADAS。这个结论不算神秘：如果工作流能被代码表示，又能被自动评估，搜索就有了抓手。

WORKFLOW3. 自我改进 Harness：改进器也可以被改进

上下文和工作流只是 Harness 的一部分。更完整的做法，是把上下文管理、工具接口、权限、评估器、错误恢复策略都放进搜索空间。

STOP（Self-Taught Optimizer，Zelikman 等，2023）是一个早期例子。它不直接改某个解 s，而是改“改进器” I。

在 t=0 时，种子改进器 I_0 接收初始解 s、效用函数 u 和黑盒语言模型 M，返回改进后的解：

再定义元效用：

递归更新写成：

STOP 最后发现了不少熟悉策略，包括遗传算法、分解改进、多臂提示词赌博机、模拟退火、变温、束搜索和树搜索。更有意思的是这个形式：评估框架和改进流程可以被当作对象来优化。

不过 STOP 也提醒了一点。递归结构本身不会自动带来进步。使用 GPT-4 时，下游平均表现会提升；换成较弱模型，表现反而下降。基础模型不够强，改进机制也会改坏。

Self-Harness（Zhang 等，2026）走的是“提出、评估、接受”的路线，让大语言模型智能体改自己的评估框架。它先从失败轨迹里挖弱点，再提出有边界的 Harness 修改，最后在保留集和留出集上验证，通过的才合并到 h_{t+1}。

这里我觉得最该盯住的是“有边界”。模型不能随便改运行环境。哪些文件能动，哪些权限不能碰，哪些安全层永远在循环之外，都要提前说清楚。否则奖励攻击和越权行为会变得很难查。

HARNESS4. 演化搜索：适合这种又大又怪的空间

演化搜索适合两类问题：搜索空间很大，或者很难用梯度优化；但候选方案的质量又能被评估。Harness 搜索差不多就是这种问题。

Promptbreeder（Fernando 等，2023）已经把演化搜索用于提示词工程。它优化任务提示词，也让“指导模型怎么变异提示词”的提示词一起演化。GEPA（Agrawal 等，2025）把反思和演化搜索结合，用自然语言总结试错轨迹，再提出新的提示词。

AlphaEvolve（Novikov 等，2025）把这件事推进到代码。系统维护候选程序池，让冻结的大语言模型生成差分补丁，跑评估，留下更好的子代。几个设计细节值得记一下：

提示词里会放父代程序、执行结果、指令和必要元信息。
编码智能体能看整个仓库，但可改区域用 # EVOLVE-BLOCK-START 和 # EVOLVE-BLOCK-END 标出来。
元提示词也参与演化。
消融实验显示，上下文、元提示词、全文件进化和模型强度都会影响结果。

ShinkaEvolve（Lange 等，2025）主要在采样效率上做文章：父代选择同时考虑性能和已有子代数量；用嵌入相似度过滤太像的候选；把成功模式写进元草稿本，指导之后的变异。

DGM（Darwin Gödel Machine，Zhang 等，2025）更贴近这里的主题。它从一个编码智能体开始，每轮按性能和子代数量选择父代；父代查看自己的基准日志，修改自身框架代码，生成新智能体；新智能体经过评估，够好才加入种群。

在 Claude 3.5 Sonnet 固定不变的情况下，DGM 从简单初始 Harness 出发，在 SWE-bench Verified 上从 20% 提到 50%，在 Polyglot 上从 14.2% 提到 30.7%。这已经接近或超过一些手工设计智能体。

当然，这类方法最适合自动评估很快、指标清楚的任务，比如矩阵乘法、GPU 内核优化、算法竞赛、数据中心调度和软件修复。评估慢、结果模糊、要靠专家判断的领域，会麻烦很多。

EVOLVE5. 再往前一步：把权重更新也放进循环

Harness 进化改的是模型周围的非参数系统。更完整的自我改进，还会涉及模型权重，比如改训练管线，或者在测试时持续学习。

SIA（Hebbar 等，2026）是一个早期尝试。它把三类角色放进同一循环：元智能体提出初始 Harness；任务智能体执行任务；反馈智能体根据最近轨迹决定下一步改 Harness，还是改模型权重。

这个方向很诱人，但证据还早。相关实验里也有一些让结果不太好解释的设计选择，例如任务智能体明显弱于元智能体和反馈智能体，基线也不够强。更大的问题还在后面：训练稳定性、Goodhart 效应、奖励攻击、权限隔离，都会一起压上来。

PART

五、几个绕不过去的问题

RISKS

Harness 工程让自我改进变得具体了一些，但不等于问题解决了。下面这些麻烦，短期内都绕不开。

自我改进系统的风险与人类监督位置

WEIGHTS1. 评估器经常不够好

自我改进循环在可快速验证、指标客观的任务上效果最好。奖励清楚，优化就更稳。

开放式研究不是这样。科学品味、新颖性、长期价值，很难用一个分数概括。一个系统可以写出看似完整的论文，却混着伪造引用、实现偏差、薄弱实验，或者根本没问对问题。

Trehan 和 Chopra（2026）的实验挺能说明问题。他们给大语言模型很少的脚手架和基本工具，让它从研究想法推进到论文。最后只有极少数想法能完整执行。反复出现的问题包括旧库依赖、实现偏差、上下文退化、过度乐观、领域经验不足和科学品味不足。

RISK2. 记忆会越长越难管

智能体越自主，记忆就越长。哪些信息留在短期上下文里，哪些写进长期日志，哪些需要摘要，哪些应该删掉，都需要规则。

长上下文会继续变强，但长上下文不是万能抽屉。没有好的上下文管理，模型只是能带着更多杂物往前走。长期任务需要的是可维护的记忆生命周期。

RISK3. 失败记录太容易丢

研究系统天然偏爱成功案例。论文喜欢正结果，训练数据里也更常见“最后成功了”的叙事，而不是一堆失败日志。

这会影响模型判断何时该放弃假设，何时该报告负结果，何时该承认实验没跑通。好的研究 Harness 应该认真保存失败尝试。失败不是废料，它能帮系统少走重复路。

RISK4. 搜索会收敛到相似答案

演化循环和强化学习循环都容易利用已知高奖励模式。迭代久了，候选方案可能变成同一个想法的不同包装。

开放式研究尤其怕这个。早期看起来分数不高的路线，可能才是后面有价值的路线。Harness 需要专门维护多样性，比如新颖性采样、种群分层、留出任务和反事实评估。

RISK5. 奖励攻击不会自己消失

自我改进循环会优化它拿到的信号。奖励来自单元测试，它可能对测试过拟合；奖励来自评判模型，它可能学会讨好评判模型；奖励来自基准分数，它可能利用基准里的缝隙。

评估器和权限控制最好放在进化循环外面。留出测试、轨迹审计和需要拍板的节点，也不能全省。哪些监督能自动化，哪些必须由人看，还没有标准答案。

RISK6. 短期任务不等于长期成功

很多训练目标只覆盖一条轨迹或一个短任务。编程智能体已经能提高日常开发效率，但它们不太会照顾大型代码仓库的长期健康。

一个补丁今天能过测试，半年后可能增加迁移成本，打乱所有权边界，破坏向后兼容性，或者留下很难调的隐患。沙盒里的短期训练很难捕捉这些代价。

RISK7. 人类的位置会变，但不会消失

更强的 Harness 不应该把人类赶出循环。更合理的变化是，人类上移到更高抽象层：定义问题，设定评估标准，划权限边界，审查奖励设计，在需要拍板的地方按暂停键。

越强的自我改进系统，越需要回答几件朴素的问题：它在优化什么？谁定义成功？谁能叫停？出事后谁能追责？

∞

END

结语：先别急着等“权重魔法”

SUMMARY

AI 自我改进未必先发生在参数里。眼下更值得看的，是工程飞轮：Harness 让模型更会研究、编码、实验和评估；更强的模型再回来改 Harness。

这条路线没有科幻故事那么漂亮，但离现实更近。它把 RSI 拆成能看见、能调试的东西：上下文、文件、工具、工作流、评估、权限和代码。

我更愿意把它看成一门正在成形的软件工程学。问题不再是模型会不会突然“自我修改”，而是系统有没有能力改进自己的运行机制，并且让人看得懂、拦得住、追得回。

CLOSING

问题不再是模型会不会突然“自我修改”，而是系统有没有能力改进自己的运行机制，并且让人看得懂、拦得住、追得回。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

在这里插入图片描述

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～