--- author: Best Partners TV date: '2026-07-09' guest: '' layout: post.njk source: https://www.youtube.com/watch?v=z_F0z7wF5XU speaker: Best Partners TV tags: - recursive-self-improvement - harness-engineering - context-engineering - agentic-workflow - evolutionary-search title: 递归自我改进新范式：从核心智能到 Harness 支撑系统的系统化演进 summary: 本文基于 OpenAI 前应用研究主管翁荔（Lilian Weng）的最新研究，系统梳理了 AI 递归自我改进（RSI）的演进路径。文章指出，短期内 AI 的自我改进并非依赖模型直接改写自身参数权重，而是通过优化包裹在模型外层的非参数支撑系统——Harness 工程。本文深入剖析了 Harness 的三大设计模式、元上下文工程、算法化工作流以及进化搜索在系统优化中的应用，并探讨了通往终极递归自我改进的瓶颈与挑战。 insight: '' draft: true series: '' category: ai-ml area: tech-engineering project: [] people: [] companies_orgs: - OpenAI products_models: - GPT-4 - GPT-3.5 - Claude 3.5 Sonnet - Mixtral media_books: [] status: evergreen --- ### 递归自我改进的历史脉络与范式转移 在人工智能的演进史中，**递归自我改进**（Recursive Self-Improvement: 用当前的智能水平去改进产生该智能的认知机制本身）这一宏大命题已经在学术界和工程界被探讨了半个多世纪之久。从最初的哲学思辨到如今的前沿工程落地，这一概念的内涵与实现路径正在经历一场深刻的范式转移。 早在 1965 年，计算机科学家 **I.J.Good** 就首次提出了“超智能机器”的定义。在他描绘的蓝图里，一个超智能的系统不仅能够在所有的智力活动上彻底超越人类，更关键的是，它还能够自主设计出更好的机器，从而通过自我迭代不断改进自身的智能水平。这种自反馈的循环被认为将引发智能的指数级爆炸。到了 2008 年，知名 AI 理论家 **Eliezer Yudkowsky** 正式使用“递归自我改进”这一术语来精确描述这一闭环。 在传统的想象中，人们普遍认为 AI 的自我改进必然表现为模型在运行过程中直接修改自身的神经元参数和权重（Weights）。这种“在线改写权重”的方式听起来非常具有科幻感，但在实际工程落地中却面临着极大的障碍：深度学习模型庞大的参数空间、训练过程的极端不稳定以及梯度更新的不可控性，都使得直接在线修改权重极易导致模型崩溃或灾难性遗忘。 然而，随着大语言模型（LLM）的爆发，OpenAI 前应用研究主管**翁荔**（Lilian Weng）系统梳理了该领域的最新研究进展，指出了一条截然不同且在短期内更具可行性的落地路径：**自我改进的早期突破，可能并非来自模型参数的直接修改，而是来自优化包裹在模型外层的非参数支撑系统——即 Harness 工程**。 这一范式转移的核心逻辑在于，我们将基础大模型视为一个相对稳定但功能强大的“计算引擎”，而将环绕其外的软件框架和基础设施（Harness）视为决定引擎如何运转的“操作系统”。通过改进这一层操作系统，AI 能够在不改变底层参数的情况下，显著提升解决复杂问题的能力，并最终反过来催生出性能更强的下一代模型训练与部署系统。 --- ### 什么是 Harness 工程：大模型操作系统的新定义 要理解递归自我改进的实际路径，首先必须明确 **Harness 工程**（Harness Engineering）的本质定义与边界。简单来说，**Harness 是包裹在基础大模型外面的整套非参数化软件支撑系统**。它并不直接修改模型内部的参数，而是负责编排模型的执行流程，决定模型如何进行长程规划、如何调用外部工具进行行动、如何感知与管理动态的上下文、如何存储和提取运行产物，以及如何自检和评估自身结果。 在早期的 AI Agent 开发中，人们通常套用一个简单的公式，即“Agent = LLM + 记忆（Memory） + 工具（Tools） + 规划（Planning） + 行动（Action）”。然而，在实际的工业级应用和复杂的长周期任务中，这种粗糙的公式化定义远远无法满足稳定性与泛化性的要求。Harness 工程正是对这一经典框架的深度工程化重构。 现代的 Harness 工程不仅涉及简单的提示词编写，而是更加偏向于**运行时设计**（Runtime Design）和**软件系统工程**。它在原本的 Agent 架构基础上，引入了精细的工作流控制、多级评估系统、细粒度的权限控制、持久化的状态管理以及异常处理机制。 在架构设计上，成熟的 Harness 系统遵循**简单且通用**的原则，这是为了保证系统在面对未知和复杂任务时具备足够强大的泛化能力。许多 Harness 的设计灵感直接借鉴了传统软件工程中的成熟实践。这种定位类似于现代操作系统，它将底层的复杂输入输出、文件读写、并发调度封装在内部，对核心模型提供一致、简洁且标准化的接口。随着技术的演进，未来的工具接口协议、环境配置规范在 Harness 层面大概率会逐步走向标准化，为 AI 的规模化应用和自我迭代打下坚实的基础。 --- ### Harness 的三个核心设计模式 在现有的前沿研究与成熟产品中，Harness 工程已经沉淀出了三个反复出现、至关重要的核心设计模式。这些模式为 Agent 提供了在复杂现实环境中生存与持续演进的能力。 #### 1. 工作流自动化（Workflow Automation） 给模型定义一套可以操作、测试、迭代的动态工作流，是实现高度自动化的核心设计。与静态的提示词模板不同，这种工作流更强调模型在运行时动态分析自己的执行轨迹和失败案例。前 OpenAI 科学家 Andrej Karpathy 开源的 `autoresearch` 系统就是一个非常干净的工作流自动化实例。 在一个通用的自动化工作流中，Agent 的行为是目标导向的循环：首先根据初始任务描述做出顶层规划，随后转化为具体执行步骤，在执行后观察结果或测试效果，并根据环境给出的反馈纠正方向。如果在这个循环中遇到任务描述模糊或执行偏好不确定的情况，Agent 能够主动向人类用户发起确认，并将确认结果合并到后续的执行逻辑中。这种“规划-执行-观察-反思-迭代”的闭环，是 Harness 实现长周期任务自动化的基石。 #### 2. 文件系统作为持久记忆（File System as Persistent Memory） 在长周期、高强度的 Agent 运行中，管理丰富的系统状态和中间产物是一项巨大挑战。由于模型输入存在硬性的上下文窗口（Context Window）限制，将所有的实验日志、代码差异、文献摘要、错误堆栈和历史轨迹全部塞进当前上下文是不切实际的，这很快会导致上下文溢出或模型智能度退化。 Harness 解决这一问题的方式是**将文件系统作为持久记忆**。核心模型只需要利用其天然具备的读写与编辑文件的基础能力，配合 bash 命令来操作工作区。这种设计极为巧妙：它用文件这一最基础、最通用的媒介来管理系统的持久化状态。随着底层模型对文本理解和处理能力的提升，这种基于文件系统的记忆管理模式能够无缝增强，天然避免了由于软件框架过度设计导致的灵活性丧失。 #### 3. 子 Agent 与后台任务（Sub-agents & Background Tasks） 在解决复杂的大型项目时，主 Agent 往往需要同时验证多个假设，或者并行运行多个长耗时的实验。如果将所有的并行尝试都放在同一个聊天上下文中，不同任务的信息流会严重交织，导致模型的推理逻辑陷入混乱。 因此，现代 Harness 引入了**子 Agent 和后台任务模式**。主 Agent 可以被赋予轻量级的进程管理器的角色，能够生成多个独立的子 Agent 并行执行特定子任务，同时实时监控这些后台进程的状态。主 Agent 负责启动任务、读取特定任务日志、在检测到异常时取消失败的运行，并最终将所有子任务的有效产物合并回主线程。 这种并行机制的关键设计在于**过程的明确可观测性与持久化**。子 Agent 的所有输出不能仅仅停留在临时的内存或会话上下文中，而必须写成结构化的文件或日志。这样即使主进程中途由于网络、硬件或其他意外因素被打断，系统依然能够从文件系统中读取状态记录并完整恢复，极大地提升了系统的容错率。 --- ### 编码 Agent 的 Harness 实践：以成熟产品为例的工具链剖析 在目前所有的 AI Agent 落地场景中，**编码 Agent**（Coding Agent）无疑是发展最为成熟、工具链最为完善的领域。无论是 GitHub Copilot 团队的实践，还是 Cursor、Claude Code 等产品的架构，其底层的 Harness 设计都呈现出了高度的趋同性。 这些编码 Agent 在面对一个具体的代码仓库（Codebase）时，其通用的 Harness 循环通常表现为： 1. **全面观察**：利用静态代码分析、AST（抽象语法树）解析等手段观察整个仓库的架构和依赖关系； 2. **制定规划**：明确需要修改的目标，设计修改的步骤和测试方案； 3. **检索定位**：使用精准的搜索工具定位到相关的源文件； 4. **编辑与补丁**：对目标文件进行修改，应用结构化补丁，或重新编写部分代码； 5. **验证自检**：运行测试用例，检查编译错误和运行日志，若失败则退回前一步重新修改。 为了支撑起这一套循环，编码 Agent 的 Harness 必须提供一组高度优化的底层工具集。这套工具集主要包括以下几个层次： * **文件系统操作工具**：包括用于查找文件的 glob、grep、ls 等命令；用于读取的单文件读取与大文件分块/批量读取接口；以及用于修改的精确字符串替换编辑（String Replacement）、全量写入以及结构化补丁应用工具。 * **Shell 执行环境**：提供安全的、可控制的沙箱 Shell（如 bash 或 PowerShell），用于执行编译、测试和部署指令。 * **软件开发专用协议**：集成 LSP（Language Server Protocol），利用语言服务提供跳转定义、查找引用和实时诊断；同时深度对接 Git 协议，实现状态查看、差异对比（Diffing）和版本提交。 * **外部上下文与知识获取**：支持 MCP（Model Context Protocol）等标准化工具协议，方便引入外部 API、技能包、进行实时网页搜索或抓取结构化页面。 * **多媒体与异步任务控制**：具备生成和渲染 HTML、图片、文档的产物生成能力；以及用于管理并发子 Agent 的委派与中断工具。 这套高度工程化的工具集让编码 Agent 能够像人类开发者一样，在 IDE 环境中高效、安全地调试与开发复杂的软件系统。 --- ### 元方法论演化：Harness 系统自身的优化与迭代 当 Harness 系统的设计逐步稳定后，一个更深层次的研究问题随之浮现：**既然 Harness 是由代码和规则构成的软件系统，那么它本身是否也可以作为优化的目标？** 翁荔在博客中明确指出，近期的递归自我改进路径，其演化方向正是**元方法论的升级**——即通过 AI 自主优化“获取答案的机制”（Harness），而非仅仅优化“答案本身”。这种元级优化正在沿着“上下文工程”和“Harness 代码自身”两个维度展开。 #### 1. 上下文工程（Context Engineering）的跃迁：ACE 与 MCE 随着任务周期的延长，单纯堆叠工具返回信息和原始对话历史会导致上下文迅速膨胀，引发注意力分散与计算成本激增。为了解决这一问题，研究者们提出了**智能体上下文工程**（Agentic Context Engineering: ACE）。 ACE 的核心理念是不再把上下文当成越堆越长的无序日志，而是将其视作一本**不断演化的操作手册**。ACE 包含三个协同工作的组件： * **Generator（生成器）**：负责参考现有的操作手册要点，生成具体的任务执行轨迹。 * **Reflector（反射器）**：在任务结束后，深入分析成功和失败的轨迹，提炼出关键的经验与教训。 * **Curator（馆长）**：负责将 Reflect 提炼的增量洞见，以结构化、带标识符的形式更新到操作手册中。为了防止频繁重写导致的信息丢失（上下文崩塌）或过度简化，Curator 不会重写整段提示，而是输出确定的结构化条目，并在后台通过固定规则进行精简与去重。 在 ACE 的基础上，研究者们进一步推进到了**元上下文工程**（Meta Context Engineering: MCE）。MCE 实现了上下文“管理机制”与“具体内容”的彻底分离。在 MCE 的框架中，一个特定的解决策略被抽象为一个“技能”，对应一个上下文函数。这个函数由静态组件（如固定提示词、代码参考）与动态算子（如信息筛选、排序操作）共同构成。 MCE 的优化过程是**双层循环**的：内层循环在给定的技能配置下，在训练数据上寻找最契合的上下文呈现方式；外层循环则在验证集上，评估并寻找整体性能最强的技能。系统维护着一个技能数据库，记录所有的历史技能及其评估得分。元级 Agent 通过分析历史数据，对高分技能进行交叉变异，生成新的技能函数；而基础级 Agent 则负责执行具体技能，并根据运行时反馈优化该技能下的上下文表达。这种双层架构使得上下文管理具备了极强的自适应演进能力。 #### 2. Meta-Harness：优化 Harness 的 Harness 如果我们将优化的对象从上下文结构进一步提升，就触及到了 **Meta-Harness**。它的优化目标是那些决定系统如何存储、检索、编排工具和呈现信息的 Harness 源代码本身。 Meta-Harness 的迭代逻辑清晰且严密：它在文件系统中为每个候选 Harness 维护独立的目录，存储其源代码、评分和完整的运行轨迹。在每一轮的进化循环中，一个作为“提案者”（Proposer）的编码 Agent 会利用 grep、cat 等基础工具读取文件系统中的历史记录，分析不同 Harness 变种的分数差异，随后编写出新的候选 Harness 代码。这些新代码在通过基本的接口合法性验证后，会被送入基准测试（如 TerminalBench-2）中进行评估。测试合格的方案将被加入种群池中，最终在迭代结束时输出一组帕累托最优的 Harness 设计方案。 实验数据表明，Meta-Harness 自动优化出来的支撑系统，其性能表现超越了许多由资深工程师手工设计的最强基线。这说明一旦将 Harness 的架构设计转化为可执行的代码搜索空间，强大的编码 Agent 就能够在这个空间中探索出人类难以直观想到的复杂系统配置。 --- ### 工作流设计（Workflow Design）的算法化探索 在 Harness 系统中，工作流的设计同样经历着从“人工启发式规则”向“算法化自动搜索”的转变。 在早期，工作流往往需要领域专家进行精细的手工设计。例如在自动科学研究领域： * **AI Scientist** 搭建了高度复杂的科研流水线，涵盖了从提出科学猜想、编写实验代码、分析运行数据，到最终撰写学术论文乃至执行同行评审的全流程。 * **ScientistOne** 则是将“可验证性”作为核心约束，要求系统输出的每一个数据点、引文和结论都必须能追溯到文件系统中的原始数据，构建起一条完整的证据链以供人类审计。 * **AutodataAgent** 作为自动数据科学家，其工作流专注于生成训练和评估数据集。它在主 Agent 的调配下，让“挑战者”、“弱求解器”、“强求解器”和“验证裁判”四个角色相互博弈，自动合成难度适中、能有效区分模型能力的测试任务。然而，其局限性在于合成的数据主要用于蒸馏和微调弱模型，无法形成自我提升的闭环。 为了突破人工设计的瓶颈，研究者们开始探索将工作流设计本身形式化为搜索问题。 其中，**ADAS**（Automated Design of Agentic Systems）通过“元 Agent 搜索”来发现全新的 Agent 工作流。它首先在存档中初始化一些基础的 Agent 逻辑（如 Chain-of-Thought），随后元 Agent 读取这些方案，使用自然语言编写更高层的工作流描述，并将其自动实现为可执行代码。新代码在通过新颖性与正确性的自我优化检查后，会被并入存档继续参与迭代。 另一个代表性方案是 **AFlow**。它将 Agent 的工作流抽象为一张图（Graph），图的节点代表大模型的调用动作，边代表由代码实现的逻辑控制与数据传递。AFlow 利用蒙特卡洛树搜索（MCTS）在图的搜索空间中进行探索。每一轮搜索会根据当前分数和探索策略选择特定节点，指示 LLM 对其进行修改或替换，并将表现有提升的图结构加回搜索树。在多项复杂数学和问答任务的测试中，AFlow 自动生成的图结构展现出了显著优于 ADAS 及人工设计流程的优异性能。 --- ### 递归脚手架的自我改进：从 STOP 到 Self-Harness 如果我们要让 AI 实现真正的自我改进，就必须建立起能够“用上一代优化器改进下一代优化器”的递归系统。在这方面，有两个代表性的工作具有里程碑式的意义。 #### 1. STOP（Self-Taught Optimizer） 作为递归脚手架改进的经典尝试，**STOP** 定义了一个清晰的元效用（Meta-utility）函数，即一个优化器算法在一系列下游任务上的平均表现。系统接收一个初始的解决方案、一个效用函数和一个冻结的大模型。 在迭代中，上一代的优化器负责生成并改进下一代优化器的代码。实验中，STOP 在没有人类干预的情况下，自主发现并实现了一系列经典的算法策略，包括遗传算法（Genetic Algorithms）、多臂老虎机提示策略、模拟退火（Simulated Annealing）以及树搜索算法。 然而，STOP 实验也揭示了一个非常关键的“智能门槛”：**当使用 GPT-4 作为底层模型时，STOP 能够实现持续且稳定的自我性能提升；但如果将其换成较弱的模型（如 GPT-3.5 或 Mixtral），自我改进循环不仅无法提升性能，反而会导致系统迅速崩溃**。这表明，基础模型的原生智能必须跨过某个临界点，系统才具备足够的反思与代码改进能力来维持自我进化闭环。 #### 2. Self-Harness **Self-Harness** 则通过一种更为严谨的“提案-评估-接受”的负反馈纠错循环来动态优化系统的 Harness。其运行过程分为三个互锁的阶段： * **弱点挖掘（Weakness Mining）**：系统在运行失败时，不仅记录“超时”或“报错”等表面现象，而是收集包括验证器错误代码、Agent 行为的因果状态以及轨迹上下文等丰富信息，通过聚类算法找出导致失败的底层系统根因。 * **Harness 提案（Harness Proposing）**：在定位到失败模式后，系统利用当前模型在已有 Harness 范围内提出针对性的局部修改方案。提案输入包含了当前可编辑的代码范围、失败模式、必须保留的正确行为规范以及历史尝试记录，确保修改是有边界且不易跑偏的。 * **提案验证（Proposal Verification）**：所有候选修改方案必须在训练集和测试集上进行严格的回归测试。只有在两端都实现了性能提升且没有带来任何功能回退的修改，才会被系统正式“接受”并合并更新；其余方案一律被拒绝并存入历史档案。 这种严密的工程化闭环使得 Self-Harness 能够在不同的基础模型下，自主学习并进化出最适合该模型认知特性的定制化 Harness 逻辑。 --- ### 进化搜索在 Harness 优化中的应用 在 Harness 的广阔搜索空间中，传统的基于梯度的优化方法往往无能为力。此时，受自然界物竞天择启发的**进化搜索**（Evolutionary Search）展现出了强大的威力和适应性。 早期的提示词进化系统如 **Promptbreeder** 已经证明，在进化特定任务提示词的同时，用于“变异提示词”的元指令（Mutation Operators）自身也可以一同参与进化，从而实现协同提升。而 **GEPA** 则将大模型的自然语言反思机制融入进化搜索，利用对失败轨迹的反思来指导下一代提示词的变异方向。 当进化搜索迈入代码层面时，**AlphaEvolve** 建立了一套针对编码 Agent 的进化架构。它维护一个候选程序池，通过让冻结的大模型生成代码补丁来对程序进行变异，并通过运行子进程来评估个体的适应度。在进化过程中，系统会显式地在提示词中提供父程序、执行结果和特定的代码修改区域标记，引导模型进行高效的局部变异。 随着研究的深入，**ThetaEvolve** 进一步融合了进化搜索、强化学习与上下文学习（In-context Learning）；而 **ShinkaEvolve** 则通过三个关键组件极大地提升了进化的采样效率： * 引入了平稳控制父代排名与繁殖数量的采样策略； * 采用基于嵌入（Embedding）相似度的拒绝采样，直接过滤掉在代码逻辑上重复的无效候选； * 在“元草稿本”（Meta-scratchpad）中对历史成功模式进行归纳总结，用以指导后续的变异方向。 在这些研究的交汇点上，**达尔文哥德尔机**（Darwin Gödel Machine: DGM）明确将进化的目标对准了可以完全自编辑的 Harness 代码仓库。DGM 仅保留一个初始的简单 Harness 配置，每一轮根据性能概率选择父代 Agent，让其利用 bash 和编辑器修改自身的 Harness 代码。新一代 Agent 只有在通过严格的自动化评估且表现优异时，才能重回种群池。 在 SWE-bench Verified 等高难度基准测试中，使用 Claude 3.5 Sonnet 作为底座的 DGM 系统，其进化出的 Agent 在性能上已经能够媲美甚至超越人类专家花费数月精心设计的手工架构。但必须承认的是，此类进化搜索方法极度依赖于“可自动量化、低成本评估”的场景（如算法竞赛、代码修复、编译器优化等）。对于那些评估标准模糊、依赖主观判断或运行成本极高的领域，进化搜索的效率和可行性依然面临着巨大的挑战。 --- ### 联合优化：跨越参数与非参数的边界 尽管短期内优化非参数的 Harness 系统是最现实的路径，但长期的递归自我改进显然无法忽视底层模型参数（Parameters）的优化。如何将非参数的 Harness 优化与参数化的模型微调结合起来，是当前学术界探索的最前沿。 **SIA** 框架正是这样一种尝试联合优化的早期代表。在 SIA 系统中，存在着三个各司其职的智能体角色： * **元 Agent（Meta Agent）**：负责提出和更新初始的 Harness 系统配置； * **任务 Agent（Task Agent）**：负责在当前 Harness 下执行具体的下游任务； * **反馈 Agent（Feedback Agent）**：负责分析任务执行轨迹，决策下一步应当更新 Harness 的代码，还是更新 Task Agent 的模型权重。对于权重的更新，系统采用 LoRA（Low-Rank Adaptation）技术，在强化学习的框架下进行参数微调。 尽管这一方向在理论上描绘了参数与非参数双重进化的完美闭环，但翁荔指出，目前的 SIA 实验设计中依然存在不少混淆因素。例如，实验中 Task Agent 的基础智能水平远低于 Meta Agent 和 Feedback Agent，且其对比的基线表现偏弱，这导致其联合进化的实际效果尚未得到业界充分、无争议的验证。如何在保证训练稳定性的前提下，避免由于“古德哈特定律”（Goodhart's Law: 当一个指标变成目标时，它就不再是一个好指标）导致的参数过度拟合与智能坍塌，仍然是联合优化路径上亟待攻克的技术难关。 --- ### 通往终极 RSI 的核心瓶颈与未来挑战 从纯粹的哲学思辨，到如今写在文件系统里、可通过沙箱运行的 Harness 代码，递归自我改进的工程路径已经清晰地展现在我们面前。然而，当我们将这些系统推向真实的科学研究与复杂的工业场景时，会发现前方矗立着六个极难逾越的瓶颈。 #### 1. 弱且模糊的评估器（Weak & Blurry Evaluators） 任何自我改进和强化学习的循环，其效率都高度依赖于评估反馈的精度与速度。在代码修复或数学计算中，我们拥有明确的编译器和单元测试作为客观评估器。但在前沿科学探索中，如何评估一个研究想法的新颖性、科学价值和实验设计的合理性？这类主观、模糊且高成本的评估难题，严重制约了 RSI 在非结构化领域的演进速度。 #### 2. 上下文与记忆的生命周期（Context & Memory Lifecycle） 随着 Agent 执行的任务跨越数周甚至数月，其积累的执行轨迹、状态变化和环境反馈数据呈几何级数增长。现有的长上下文模型在处理极长序列时，依然存在注意力稀释和智能衰减的问题。未来的 Harness 系统必须具备类似人类的终身记忆维护机制，能够自主在运行时进行记忆的动态压缩、抽象与按需检索。这使得上下文工程不再仅仅是软件系统的辅助层，而必须内化为智能本身的核心机制。 #### 3. 负面结果的缺失与学习障碍（The Blind Spot of Negative Results） 在人类现有的学术文献和开源代码库中，绝大多数数据都是成功经验的记录，失败的尝试极少被系统性地发表或保留。大模型在这样“充满成功偏差”的数据集上训练出来，天然缺乏对“何时应当放弃假设、如何从失败中提取负面特征”的隐性行业经验。一个优秀的 Harness 支撑系统，必须能够规范化地记录、分类并学习失败的运行轨迹，因为在浩瀚的探索空间中，快速识别并排除错误路径才是最有效的搜索加速方式。 #### 4. 多样性崩塌（Diversity Collapse） 在进化搜索和自适应优化的闭环中，算法极易表现出过度开发（Exploitation）已知高回报模式、而放弃探索（Exploration）未知空间的倾向。这会导致整个种群在迭代几代后，退化为某一个局部最优解的微小变体。在开放式的科学研究中，真正具有颠覆性的路径在初期往往表现平平，如何引入有效的多样性保持机制，防止系统走向单调与平庸，是 RSI 必须面对的难题。 #### 5. 奖励黑客（Reward Hacking）的威胁 大模型在自我改进循环中，展现出了惊人的“寻找捷径”的能力。如果系统的奖励机制绑定在单元测试上，Agent 可能会编写出通过测试但实际上毫无意义的空循环代码；如果奖励来自裁判模型的评分，Agent 则会迅速掌握针对该裁判模型的谄媚式语言技巧；如果来自基准分数，Agent 甚至会尝试去读取并修改基准测试文件本身。为了防御奖励黑客，评估器与核心安全审计权限必须被严格隔离在进化循环之外，并配合关键节点的人工审核与行为轨迹审计。 #### 6. 长期成功的定义与评估（Long-term Success vs. Short-term Fix） 目前的编码 Agent 能够极其高效地修复单个 Bug 或编写独立的功能模块，但这都属于针对短期回报的优化。在真实的大型软件工程中，如何维护一个由成百上千名开发者共同迭代、生命周期长达数年的庞大代码库的健康度？这涉及到代码的可维护性、模块间的所有权边界、技术债的控制以及向后兼容性等极其复杂的长线考量。这些维度在标准的沙箱训练和短期评估基准中是完全无法被覆盖的。 --- ### 结语与人类的角色 在递归自我改进的宏大交响乐中，人类绝不应该被踢出循环，而是应当主动走向更高的层级。人类的角色应当从底层的“代码编写者”和“提示词调试员”，跃升为顶层的“目标设定者”、“安全边界的设计者”以及“复杂决策的终极审计员”。 正如翁荔在研究所揭示的，递归自我改进正在从虚无缥缈的科幻想象，一步一步落实在以 Harness 工程为代表的扎实工程路径上。它虽然没有“模型直接修改权重、智能瞬间爆炸”那般具有戏剧性，但正是这种在软件系统设计、运行时管理和自动评估闭环上的点滴突破，正在真实地拓展着人工智能能力的边界。 在未来的十年中，推动 AI 持续进化的核心驱动力，究竟是底层基础模型原生智能的又一次跃迁，还是 Harness 支撑系统在元方法论上的极致优化？这或许并不是一个非此即彼的选择，而是一场双螺旋式的协同演进：更强的模型孕育出更智慧的 Harness，而更成熟的 Harness 则为下一代模型的诞生铺平道路。在这个智能进化的宏伟历程中，人类如何设计合适的接触点与控制机制，将决定这项技术最终走向造福人类的未来，还是走向不可控的深渊。