前 OpenAI 安全研究副总裁、Thinking Machines Lab 联合创始人翁荔（Lilian Weng）又双叒叕发长文了：


继喊话谨慎对待 Scaling Law 之后，这次她系统梳理了一个正变得越来越重要的方向：Harness Engineering。


Image

博客链接：https://lilianweng.github.io/posts/2026-07-04-harness/


她在这篇最新博客中写道，AI 的自我提升未必会先从“模型直接改写自己的权重”开始。


翁荔认为，Harness Engineering 可能成为 AI 递归式自我提升（RSI）的近期开端。相比直接让模型改写自身权重，更现实的路径是先优化模型外部的 Harness 层，包括工作流、上下文管理、工具调用和评估机制；这些能力成熟后，才可能进一步推动自动化研究和更强模型的产生。


不过，她也提醒，目前这一路线仍面临评估器模糊、上下文记忆退化、奖励黑客、负结果难以保留，以及人类监督如何嵌入等问题。


全文围绕 Harness 的设计模式、优化方法以及未来挑战展开，主要内容如下：


一、Harness 设计模式

  1. 1. 模式一：工作流自动化
  2. 2. 模式 二：文件系统作为持久记忆
  3. 3. 模式三：子Agent 和后台任务
  4. 4. 案例研究：编码 Agent 工具
  5. 5. Harness 层与核心智能？


二、Harness 优化

  1. 1. 上下文工程
  2. 2. 工作流设计
  3. 3. 自我改进 Harness
  4. 4. 进化式搜索
  5. 5. 基于模型权重的联合优化


三、未来挑战


递归式自我提升（recursive self-improvement, RSI）的概念可以追溯到 I. J. Good（1965）。他将“超智能机器”定义为一种能够在所有智力活动上超越人类，并且能够设计出更好机器来改进自身的系统。Yudkowsky（2008）则使用“recursive self-improvement”这个短语来描述一种特定的反馈回路：AI 使用自己当前的智能，去改进产生这种智能的认知机器。


在现代 AI 中，这个反馈回路既可以指模型直接重写自己的权重，也可以更宽泛地指模型改进训练流水线和部署系统，而这些改进又使得下一个继任模型能够在具有经济价值的任务上获得更强表现。前沿实验室（Anthropic；OpenAI）中的 AI 研发速度已经被证明大幅加快。


我特意提到“部署系统”，是因为位于原始模型与真实世界上下文之间的这一层，似乎和模型的原始智能同样重要，也就是预训练后立即做评测时看到的能力。Harness 是 AI 部署中的重要组成部分，这一点已经被 Claude Code 和 Codex 等成功的编程 Agent 产品展示出来。所谓 harness，是围绕基础模型构建的系统：它负责编排执行，决定模型如何思考和规划、调用工具和行动、感知和管理上下文、存储产物，以及评估结果。


本文将聚焦于 harness 工程相关研究，以及它如何推动 RSI。近期关于自动化研究、自我改进 Agent 和进化式程序搜索的许多工作，都可以围绕这个问题来组织。其他方向也符合 RSI 愿景，例如模型自博弈、合成数据、测试时训练，以及更广义的持续学习主题（如 Yuan et al. 2024、Chen et al. 2024、Zhao et al. 2025、Choi et al. 2026），但它们不是本文重点。


Harness 设计模式

相比早期的 Agent 框架，即“Agent = LLM + 记忆 + 工具 + 规划 + 行动”，harness 工程还包括工作流设计，例如 loop engineering、评估、权限控制和持久状态管理。它不再只是提示词模板，而更接近运行时和软件系统设计：模型如何观察、行动、记忆、检查自己，并完成改进。


这种设计应该有意保持简单和通用，以支持泛化；同时，它也很可能需要参考现有软件工程实践，从预训练知识中受益。操作系统和 harness 之间也存在很强的类比。类似 OS，harness 应该封装复杂逻辑，同时保持接口简单。与此同时，配置、工具接口和其他协议也可能逐渐在行业中标准化。


1.模式一：工作流自动化

定义一个让模型能够操作、测试和迭代的工作流，是实现自动化的关键设计。Karpathy 的 autoresearch 仓库是构建这类工作流的一个清晰例子。一个常见工作流遵循目标导向的循环：规划、执行、观察或测试、改进，然后再次执行，直到目标达成。这个过程可能会主动向用户请求澄清，以明确任务规格或执行偏好。


Image

图｜一个简化版的 Codex Agent 循环。


工作流图也强调，模型会分析自己的轨迹和失败案例，并通过一个“Agent 运行时”持续迭代，而不是只依赖静态提示词模板。


2.模式二：文件系统作为持久记忆

长程 Agent 系统中一个反复出现的模式，是用简单控制来管理丰富状态和产物。Harness 不应该把整个工作流和所有日志都塞进上下文；相反，它应该把持久状态保存在文件中。在长程 Agent rollout 中，实验日志、代码 diff、论文摘要、错误栈和过去 rollout 轨迹等产物，常常会远远超过模型训练时所适配的上下文窗口长度。


学习如何读、写和编辑文件系统，通常通过 bash 命令，是 LLM 的基础能力。因此，用文件这种简单形式管理持久记忆，自然能够受益于核心模型能力的提升。


3.模式三：子Agent和后台任务

Harness 可以启动多个子 Agent 并行执行，也可以监控后台任务。当主 Agent 需要搜索多个假设、并发运行实验，或者把隔离子任务委托出去而不污染主上下文时，这很有用。此时父 Agent 需要一个小型进程管理器：启动任务、检查日志、取消失败运行，并把结果合并回主 Agent 线程。


关键设计选择是让并行性显式且可检查。如果子 Agent 的输出只存在于临时聊天上下文中，它们很快会过时并被隐藏。如果这些输出被存储为文件、日志和状态记录，模型就可以在中断后恢复，并根据自己的执行历史进行推理。


4.案例研究：编程Agent Harness

主流编程 Agent 的核心接口在 Claude Code、Codex、OpenCode 和 Cursor 风格 Agent 中已经逐渐稳定。它们通常使用如下循环：


在获得一组工具后，编程 Agent 能够在给定代码仓库中开发和调试问题，类似人类开发者配备 IDE 后的工作方式。


Image


5.Harness层与核心智能？

很难预测 RSI 的未来会在多大程度上依赖 harness 工程，但 RSI 的近期开端不太可能是模型直接重写自己的权重。我对近期实践路径的判断是：


1.Harness 工程将朝着元方法论方向演化，也就是改进“得到更好答案的机器”，而不仅仅是改进答案本身。Harness 系统自身会成为优化目标，其中启发式规则会减少，更通用的机制会增多。


2.反过来，成熟的 harness 会支持面向模型自我改进循环的自动化研究；而更聪明的模型会避免 harness 被过度工程化，使系统保持可持续。


最终，许多 harness 改进可能会被内化为核心模型行为，但与外部上下文和工具交互的接口仍然会保留下来。我们已经在提示工程中见过这一模式的温和版本：随着指令微调和模型推理能力提升，人工编写提示词技巧变得没那么核心，但指定目标、约束、上下文和评估的需求并没有消失。


Harness 优化

Harness 系统中被优化对象的演进大致是：指令提示词 -> 结构化上下文 -> 工作流 -> harness 代码 -> 优化器代码。随着模型变得更智能、更强大，我们会转向更复杂的目标和更通用的方法。


1.上下文工程

如果只是把所有工具响应和模型生成都追加到上下文里，随着 Agent 任务时长显著增加，上下文会很快失控。上下文管理是一层用于为 LLM 构造更结构化、更简洁上下文，并管理持久状态的机制。长期上下文研究无疑会持续进步，但在当下，长上下文智能和上下文工程有时是交织在一起的。


Agentic Context Engineering（ACE；Zhang et al. 2025）把上下文视为不断演化的 playbook，而不是越来越长的提示词。它包含三个组件，用于维护一个由条目构成的上下文 playbook，每个条目包含一个标识符和一段描述。


1.生成器（Generator）：生成任务轨迹，并参考条目。

2.反思器（Reflector）：从成功和失败轨迹中提炼洞见。

3.策展器（Curator）：用增量、条目化的记录更新结构化上下文。


Image

图｜Agent上下文工程（ACE）框架。


为了防止迭代重写过程中的上下文崩塌和简短偏置，ACE 的一个关键设计是：curator 不会重写完整的提示词 blob。它输出的是一组结构化、条目化的 bullet，形式为（标识符，描述），然后这些条目会通过确定性逻辑合并进结构化上下文日志。上下文条目会被周期性地精炼和去重。


ACE 从部署过程中学习经验这一事实有助于我们实现内存的自我管理，但更新规则和整体工作流程仍然是人工设计的。为了构建更具自我改进性的循环，元上下文工程（MCE）将机制（如何管理上下文）与工件内容（上下文中包含什么）分离，在元优化层面运行技能演化，在基础层面运行上下文优化。


Image
Image

图｜元上下文工程（MCE）框架。


MCE 不像 ACE 那样强制使用某种启发式规则来组织上下文。它使用自由形式的 skill 存储任务中最重要的知识，并让 skill 与 skill 条件化的上下文一起迭代演化。在实现上，一个上下文函数会被实例化为专用目录中的一组文件，其中包括静态组件（skill.md）和动态组件（上下文与数据执行轨迹）。元层面和基础层优化都会在具备标准工具集的 agentic coding 环境中执行。


Image


Meta-Harness（Lee et al. 2026）则更进一步：：它所优化的对象是决定并优化哪些信息应该存储、检索和呈现给模型的代码。它名字中的“Meta”意味着，这是一个用于优化 harness 的 harness。


Image

图｜Meta-Harness 的外层循环优化算法。


用于创建新 harness 的提议者本身就是一个编程 Agent，最终输出的是一批位于帕累托前沿上的 Harness 候选方案。


  • 完整执行历史可以通过文件系统访问，因此编程 Agent 会使用 grep 或 cat 等命令读取历史，而不是把所有内容都塞进单一提示词上下文。
  • 被提出的 harness 是文件系统中的一个目录，包含自己的源代码、分数、rollout 轨迹和状态更新。
  • Meta-harness 循环会迭代创建新 harness，并且只保留合格候选。


Image

图｜Meta-Harness 在（左）少量迭代次数的文本分类任务和（右）TerminalBench-2 任务上的性能对比。


不过，重要的教训很明确：一旦 harness 设计变成可执行的搜索空间，一个强编程 Agent 就能够利用和人类工程师相同的设计空间。


2.工作流设计

Harness 工程中的工作流设计可以由领域专家手工完成。以自动化研究为例，已经有多种框架被提出和测试。AI Scientist 系统（Lu et al. 2026）构建了一条流水线，用于提出研究想法、编写代码、运行实验、分析结果、撰写论文，并执行同行评审。Meng et al.（2026）在 ScientistOne 中把可验证性作为核心设计约束，其中每一条声明，包括引用、数值、方法和结论，都必须追溯到证据来源，并通过证据链检查来接受审核。


Image

图｜AI Scientist 用于 idea generation、实验、论文写作和评审的流水线。


Autodata Agent（Kulikov et al. 2026）被设计成一个用于生成训练和评估数据的数据科学家。主 Agent 管理一个出题者（challenger）、一个弱解题者（weak solver）、一个强解题者（strong solver）和一个验证者/评判者（verifier/judge），目标是合成“难度刚刚好”的数据，即强解题者能够解决、而弱解题者却做不到的难度。


在 Autodata 中，出题者的提示词会根据解题者和验证者反馈迭代更新。这里的局限在于，合成出来的任务被用来微调弱解题者，却没有用来微调强解题者；如果循环无法迭代改进强模型，那么它更像是在一个生成出来的提示词分布上做间接蒸馏，RSI 的意味就比较淡了。


Image

图｜Autodata 的 agentic 工作流设计。


工作流的设计空间非常巨大，因此我们自然可以把工作流设计视为一个搜索问题，并期待通过算法找到好解，而不只是手工设计。沿着这个方向，Automated Design of Agentic Systems（ADAS；Hu et al. 2025）把 Agent 设计本身表述为优化问题，即“meta-agent search”：由一个 meta-agent 提出新的 agentic 工作流设计。


  • 初始化一个 agentic 工作流归档，包含 CoT 和 self-refine 等简单 Agent。
  • 要求 meta-agent 基于归档中的已有方案，用代码编写新的 Agent。
  • Meta-agent 首先生成新工作流的高层描述，然后用代码实现它。
  • 草稿程序随后经历两轮由 meta-agent 执行的 self-refine，也就是先让模型给出反馈，再让同一模型基于反馈改进先前输出；这一步用于检查其新颖性（Madaan et al. 2023）。
  • 评估每个新候选，并把成功候选加入归档。
  • 重复第 2-3 步，直到达到最大迭代次数。


Image

图｜Agent 系统自动化设计（ADAS）示意图。


AFlow（Zhang et al. 2025）把 agentic 工作流表示为图，其中节点表示调用 LLM 的动作，边则用代码实现逻辑操作。工作流优化依赖 MCTS（Monte Carlo Tree Search，蒙特卡洛树搜索）：


  • 用 CoT、自我修正（self-refine）之类的简单 Agent，初始化一个智能体工作流的档案库。
  • 让元 Agent 在已有档案库方案的启发下，用代码编写出新的 Agent。元 Agent 首先生成新工作流的高层描述，然后再将其实现为代码。生成的草案程序会经过元 Agent 的两轮自我修正（先让模型对结果提供反馈，再让同一个模型根据反馈修正自己先前的输出；Madaan et al. 2023），以检查其新颖性。
  • 评估每一个新的候选方案，把成功的方案加回档案库。
  • 重复前面两个步骤 ，直到达到最大迭代次数。


Image

图｜基于工作流候选树的流程优化过程。


AFlow 在 QA、代码和数学任务中的实验表明，AFlow 比手动设计的工作流程和 ADAS 有显著的改进。


Image

图｜AFlow实验与人工方法和ADAS的比较。


3.自我改进Harness

无论上下文工程还是工作流设计，都只是 harness 的一部分。我们需要搜索整个设计空间，并同时优化上下文管理逻辑、工作流、权限和其他许多 harness 组件。正如 Meta-Harness、ADAS 和 AFlow 等工作所展示的，代码是一种定义程序和系统的通用语言。简单来说，harness 就是代码，它规定提示词、工具调用、子 Agent、控制流、记忆和工作流逻辑如何协同。如果 LLM 能够优化执行 Agent 的代码，它就能访问一个比人工编写提示词大得多的设计空间。



Image

图｜自学习优化算法（STOP）。


在 Zelikman et al.（2023）的实验中，改进后的 improver 发现了多种策略，例如遗传算法、分解并改进局部、多臂 prompt bandit、模拟退火、改变 temperature，以及 beam/tree search。这类似于把 harness 工作流表示成一个可优化对象。


Image

图｜STOP 发现的自我改进策略示例。


他们的一个警示性发现是：在 GPT-4 上，STOP 能够随着迭代提升下游平均表现；但在 GPT-3.5 和 Mixtral 等较弱模型上，表现反而下降。递归结构本身并不够。基础模型必须足够强，才能改进机制。这意味着 harness 改进确实能帮助模型更好地部署，但智能仍然是核心。


更新近的 Self-Harness（Zhang et al. 2026）依赖 LLM Agent 通过 propose-evaluate-accept 循环改进自己的 harness。


Image

图｜Self-Harness 使用弱点挖掘、有界 harness 提案和验证循环来更新 harness。


自组装循环分为三个阶段：


Image


在 Terminal-Bench-2 上运行 MiniMax M2.5、Qwen3.5-35B-A3B 和 GLM-5 时，Self-Harness 被证明能够学习针对不同基础模型弱点的模型特定 harness 指令，并提升 held-out pass rate。


Self-Harness 这类工作也让我担心：如果一个程序被允许编辑 OS 系统，抽象边界就会被打破。可编辑表面需要被妥善设计，权限控制和安全层需要位于这个循环之外。围绕 reward hacking 的所有挑战仍然存在。


4.进化式搜索

进化式搜索是一种受自然选择启发的优化方法。它通过变异一组解，并只保留群体中“适应度”高的解来演化解群。进化式搜索在以下情况下很有用：（1）搜索空间巨大或形状奇特；（2）很难用梯度直接优化，但容易评估解的好坏。Harness 搜索似乎非常适合这种方法。


过去研究已经把进化式搜索用于 prompt engineering。Promptbreeder（Fernando et al. 2023）通过丰富的变异操作优化任务特定提示词；有趣的是，mutation prompts，也就是指示 LLM 如何变异任务提示词的指令，本身也会通过进化得到改进。GEPA（Agrawal et al. 2025）结合了基于反思的 prompting 和进化式搜索，并利用对试错轨迹的自然语言反思来提出 prompt 更新。


Novikov et al.（2025）提出的 AlphaEvolve 是一个编程 Agent 进化式搜索系统，它存储候选程序池，并提示冻结的 LLM 生成用于改进的 diff。随着系统反复评估子程序并保留成功的程序，它最终会发现更优的解决方案。


Image

图｜AlphaEvolve 的工作原理。


AlphaEvolve 设计中有几个细节很重要：

  • Prompt 包含父程序、结果、指令，有时也包含元信息。
  • 编程 Agent 可以访问完整仓库，但用于改进的代码区域会通过 # EVOLVE-BLOCK-START 和 # EVOLVE-BLOCK-END 显式标记。
  • Meta-prompt 会根据 LLM 建议与指令和上下文共同演化，这类似于我们演化解程序的方式。

消融实验显示了进化流程、prompt 中上下文、meta-prompt、全文件演化和使用更强 LLM 的价值。


Image

图｜AlphaEvolve 的消融实验展示了多个设计的价值。


近期变体如 ThetaEvolve（Wang et al. 2025）结合了进化式搜索、强化学习和上下文学习。另一方面，ShinkaEvolve（Lange et al. 2025）引入了三个新组件，以提升 LLM 采样效率：


  • 通过设计 parent sampling，在性能排名和子代数量之间取得平衡，从而实现更高采样效率的探索。
  • 通过 code-novelty rejection sampling，基于 embedding cosine similarity 丢弃与现有群体过于相似的候选。
  • 在 meta-scratchpad 中识别成功解里的好模式，用于指导未来变异。


不同于上述主要关注解改进的方法，Darwin Gödel Machine（DGM；Zhang et al. 2025）明确把一个可编辑的 harness-code 仓库作为进化目标，并使用基于 LLM 的编程 Agent。准确地说，这个 Agent 被允许修改自己的 harness。后续关于 Hyperagents（Zhang et al. 2026）的工作则引入了一个 meta-agent，用于控制如何修改现有任务 Agent 以创建新 Agent。


1.从 Agent 池中池中的一个编程 Agent 开始。

2.每次迭代中，根据性能成比例、根据子代数量成反比的概率选择一个父 Agent，对其进行修改并分叉，产生新 Agent。

3.被选中的父 Agent 会检查自己的 benchmark 评估日志，然后提出对自身 harness 代码库的改进，生成新版本编程 Agent。代码编辑通过两个基本工具实现：（1）bash，参数为 <bash_command>；（2）editor，参数为 view/create/edit <file_path>。

4.新编程 Agent 会被评估，只有表现足够高者会被加入 Agent 池中。

5.重复第 2-4 步，直到满足某些停止条件。


DGM 是固定模型下的 harness 演化。在使用 Claude 3.5 Sonnet 作为基础 LLM、简单初始 harness 配置的实验中，DGM 发现的 Agent 在 SWE-bench Verified（20% 到 50%）和 Polyglot（14.2% 到 30.7%）上可媲美或超过手工设计 Agent。


这类方法在候选解可以自动评估、候选适应度容易量化的任务上效果很好，例如矩阵乘法、GPU kernel 优化、算法竞赛、数据中心调度。它们在评估缓慢、模糊或主要依赖启发式判断的领域会遇到困难。进化的计算效率和有效性也是问题。


5.基于模型权重的联合优化

Harness 演化改变的是模型周围的非参数系统。为了实现完整自我改进，模型当然也可以同时被允许更新自己的权重。权重更新可以通过改进模型训练流水线来实现，也可以通过测试时持续学习来实现。持续学习这个主题未来值得单独写一篇。


SIA（Hebbar et al. 2026）是把 harness 改进和模型参数更新结合在同一个优化循环中的早期尝试。其设计包含三个组件：


  • 元 Agent：提出初始框架。
  • 任务特定代理：执行任务。
  • 反馈代理：根据最近的轨迹选择是更新线束还是模型权重。


Image

图｜SIA中的反馈代理决定下一次迭代的类型。


SIA 的实验里有一些混杂选择，使结果难以解释。例如，task-specific Agent 明显弱于 Meta-Agent 和 Feedback-Agent 使用的模型（gpt-oss-120b vs Claude Sonnet 4.6），而且基线过弱，难以与相关方法干净地交叉对照。我会认为这个方向有趣，但证据仍是初步的。与此同时，训练稳定性和 Goodhart 效应等许多挑战仍然开放。


未来挑战

AI Scientist 这一系列工作强有力地展示了：专家设计的 harness 可以协调自动化研究循环中的很大一部分，并以写研究论文的形式进行实验。但论文生产并不等同于科学发现。一个系统可以写出看似合理的手稿，同时仍然存在伪造引用、实现漂移或实验结果薄弱的问题。


Trehan & Chopra（2026）测试了 LLM 能否在最少脚手架和基础工具下，从一个研究想法走到一篇论文。这些基础工具包括 read_file、write_file、llm_search、list_files。每个想法都有一个专用工作区，Agent 可以在其中生成和读取文档作为上下文的一部分。他们在三个领域进行了实验：world models、multi-agent RL、AI safety & alignment；每个领域包含 45-50 篇高质量种子文档，以启发新想法。人类专家只选择了四个想法进入完整流程，其中只有一个被完整执行成论文。他们在实验中观察到了六类反复出现的失败模式：


  • 偏向训练数据默认值：使用旧库、过时命令、标准格式，或采用不基于真实仓库或数据集的假设。
  • 执行压力下的实现漂移：当实现变得技术上复杂时，模型可能转向常见但更简单的方案，而不是坚持原提出方法。
  • 记忆和上下文退化：长程项目会丢失关键细节，除非日志被写成持久产物。
  • 过度乐观：模型会在实验嘈杂或失败时宣布成功，这类似 Bubeck et al.（2025）观察到的 “p-hacking and eureka-ing” 模式，即模型可能引入“数值胶带”，并在信号仍然只是噪声时宣布胜利。
  • 领域智能不足：模型缺少隐性技艺知识，例如预测实现复杂度、判断实验结果是否可信，或知道哪些 baseline 重要。
  • 科学品味不足：实验也许可以执行，但无法回答正确的问题。


面向完整 RSI，研究者已经取得了真实进展，但几个瓶颈仍然存在。


1.弱且模糊的评估器。许多研究声明没有快速、精确的 verifier，许多现实任务也是如此。当前自我改进循环最适合那些评估指标可测、客观的任务，类似 RL 能发挥作用的场景。


研究品味、新颖性和长期科学价值要难衡量得多。例如，研究品味常常混合了问题框定、实验设计，以及判断哪些意外结果值得追、哪些失败案例值得重试的能力。


2.上下文和记忆生命周期。随着 AI Agent 变得更自主、更独立，记忆会持续增长。一个有用的 harness 需要管理上下文和记忆，以弥补当前长上下文生成的限制，同时最大化长程任务成功率。既然人类能够在一生中维持记忆，我认为这里有一个类比：上下文工可以而且也应该成为智能的核心部分，而不仅仅停留在软件系统层。


3.负结果。研究者有发表成功结果的激励，因此文献对成功案例存在偏置。LLM 训练于海量数据，而这些数据至少目前仍主要由人类创造；由于成功与失败案例在数据中的不平衡，LLM 可能不擅长决定何时放弃假设、报告负结果，甚至承认失败。一个研究 harness 应该让失败尝试易于保存，因为从失败中学习是缩小任务搜索空间的最好方式。


4.多样性坍缩。进化和 RL 循环倾向于利用已知高奖励模式。我们需要机制防止群体坍缩成同一种方案的变体。这对开放式研究尤其关键，因为最佳路径在当前评估器下初看起来可能更差。


5.Reward hacking。自我改进循环会优化它得到的任何信号。如果奖励来自单元测试，Agent 可能过拟合测试；如果奖励来自 judge model，它可能学会针对这个 judge 的 reward hacking 技巧；如果奖励来自 benchmark 分数，它可能利用 benchmark 伪影。


评估器和权限控制很可能应该位于演化 harness 的循环之外，并配合 held-out tests、轨迹审计，以及在人类需要介入的关键决策点进行审查。至于这种监督能在多大程度上扩展和自动化，仍然是开放研究问题。


6.长期成功。外在优化循环依赖的是个体 rollout 之外、我们可以在训练沙盒中模拟的奖励。

以编程 Agent 为例。编程 Agent 已经提高了日常软件工程生产力，但许多优化目标仍然太短期。它通常可以完成手头任务，但还不清楚它应如何保护一个由数百或数千名工程师共同维护的代码仓库的长期健康。标准沙盒式 RLVR 训练很难捕捉可维护性、所有权边界、迁移成本、向后兼容性或未来调试负担。


7.人类的角色。人类应该向上移动到更高抽象层，而不是被移出循环。这意味着人类应该在正确时间、以正确抽象层级提供监督；我们的系统设计也应该考虑何时以及如何设置这些触点。


整理：夏千斯

如需转载或投稿，请直接在本文章评论区内留言


内容中包含的图片若涉及版权问题，请及时与我们联系删除