我的征尘是星辰大海。。。
The dirt and dust from my pilgrimage forms oceans of stars...
-------当记忆的篇章变得零碎，当追忆的图片变得模糊，我们只能求助于数字存储的永恒的回忆
作者:黄教授
手机视频列表
为什么大模型编程要进入Harness时代1
视频
音频
原始脚本
为什么大模型上下文工程必须进入 Harness 时代？从任务复杂度困境到连续任务工程化引言，从单次交付到连续执行的必然突围。 2024年之前，大模型应用的核心命题是如何用一个 prompt 搞定一个任务。 无论是生成一封邮件、解答一个知识问答，还是完成一段简短的文案，任务的边界清晰、流程单一、信息密度适中，模型的单次上下文能力完全足以承载，一次指令一次交付成为主流模式。 但进入2025年，随着对大模型能力期待值的全面提升，我们开始尝试将其投入更复杂的工作场景。 现实很快暴露了传统模式的瓶颈，绝大多数复杂任务本质上都无法通过单次指令完成。 他们要么面临步骤繁多、需逐次决策的困境，要么遭遇输出体量巨大、超出上下文承载的限制。 最终指向同一个核心问题，如何让大模型在单次能力有限的前提下完成复杂任务规模化的目标。 此时，Harness Engineering 的价值彻底凸显。 它不再是简单的提示词升级，而是一套针对复杂任务的连续执行工程化方案。 若用导演与演员的隐喻破题，过去的大模型像拍单镜头短片，每拍一次就要重新开场、重新说戏。 而 Harness 时代的大模型是拍摄一镜到底的长片，导演提前设计好完整剧本，场景规则与状态流转，演员拿到剧本后，在连续的剧情中自主推进，无需反复解释，最终完成整部作品的呈现。 一、复杂任务的两大核心困境，上下文限制下的任务拆解，刚需大模型的单次上下文容量始终是复杂任务落地的核心瓶颈。 我们可以将无法一次搞定的复杂任务归纳为两种典型形态。 而这两种形态恰恰对应了现实工作中最常见的两类场景，也直接催生了 harness engineering 的诞生。 一，第一种困境，步骤繁多、主次决策、 MUD 探索式任务。 这类任务的核心特征是单次。 信息量小，但步骤数量巨大，且每一步都需模型自主决策。 最典型的代表就是 MUD 迷宫探索、OpenClaw 式搜索、逐步执行的自动化任务等。 以 MUD 探索为例，任务的目标是从起点找到通往终点的路径。 但整个过程无法一次性完成，模型不可能提前获取所有房间的信息，也无法一次性规划出完整路径。 每进入一个新房间，都需要评估周边局势，判断是否有未探索的方向，决策下一步移动的位置，甚至在无路可走时，需要主动回溯至上一节点重新规划。 这意味着任务的每一个环节都依赖大模型对当前场景的理解和判断，无法提前固化为固定程序。 再比如 OpenCL 类的搜索任务，从寻找目标信息、筛选有效内容，到执行后续操作、反馈结果，每一步都需要模型判断是否找到目标、是否需要调整策略、下一步该执行什么动作。 这类任务的本质是连续的决策序列，步骤数量可能成百上千。 若强行将所有信息塞进单次上下文，不仅会超出模型承载上限，还会导致信息冗余，决策效率低下。 若跳过某一步的模型判断，又极易因局势误判陷入错误路径，甚至掉进沟里。 对于这类任务，传统程序无法替代，因为传统程序只能执行固定逻辑，无法应对自然语言判断、局势评估这类模糊动态的决策场景。 因此，唯一的解法就是将任务拆分为无数个微步骤，每一步都调用大模型完成一次决策。 同时用动态上下文维持任务状态的延续，确保模型不会失忆。 二，第二种困境，体量巨大、单次超限、长代码重构式任务。 这类任务的核心特征是步骤数量少，但单次输出信息密度极大，超出模型上下文承载能力。 常见于大型代码修改、长函数重构、长文档编辑、复杂项目整体规划等场景。 举个代码开发的例子，假设要修改一个几千行的代码文件，核心需求是调整某个核心逻辑。 此时模型无法一次性输出整个修改后的完整代码，一方面上下文容量有限，无法承载全部代码内容。 另一方面，即使能承载，一次性修改整体代码也极易出现逻辑漏洞、依赖冲突，且难以定位错误。 更关键的是，若遇到一个超长函数，违背代码规范但实际存在的场景，即便只修改其中一个功能模块，也可能因函数篇幅过长导致模型无法完整理解整体逻辑，最终输出错误结果。 再比如长文档编辑，若要对一篇万字长文进行整体润色、结构调整或内容优化，一次性输入全部文档不仅会超出上下文，还会让模型难以聚焦核心修改点，输出效果大打折扣。 这类任务的痛点在于单次信息密度超过模型上限。 即便任务本身是单一目标，但因输出体量过大，无法通过一次指令完成。 此时解决思路同样是拆解，将庞大的任务拆分为多个细粒度子任务。 比如先修改代码文件的模块 A，再优化模块 B，最后整合整体逻辑。 或将长文档拆分为多个段落，逐段进行润色调整，再拼接整合。 每一步只处理有限的上下文，确保模型能够精准理解，精准输出。 同时通过 harness 控制整体流程与状态衔接，保证子任务之间的逻辑连贯。 二、核心本质，复杂任务等于单次上下文能力的超纲挑战。 无论是 MUD 探索式的步数多、单次小，还是长代码重构式的步数少、单次大，两类困境的本质其实是同一个复杂任务的整体特征。 超出了大模型单次上下文的承载理解与输出能力。 我们可以用一个简单的公式拆解，复杂任务体量等于上下文承载上限乘任务复杂度系数。 当任务体量大于单次上下文承载上限，且任务复杂度系数大于一，即任务非单一、非原子。 存在状态流转，单次交付模式必然失效。 从上下文维度看，模型的单次上下文容量是固定的，无法无限扩大。 即便未来模型上下文持续提升，也总会遇到超纲的复杂任务。 从任务维度看，复杂任务本身具备序列性、状态依赖性、模糊决策性。 MUD 探索依赖每一步的状态变化，长代码重构依赖模块间的逻辑关联，这些都无法通过一次性指令完全覆盖。 而传统提示词工程的局限恰恰在于它只适配单次上下文内的简单任务，无法应对超纲的复杂场景。 它无法解决步骤繁多时的状态延续问题，也无法破解体量巨大时的上下文超限困境。 这就像导演拍电影，若只拍一个镜头，只能呈现一个碎片化的场景。 若要拍完整部电影，必须设计完整的剧本、场景转换、状态流转，让演员在连续的剧情中完成表演。 Harness engineering 的核心价值 正是针对这一本质困境，他不试图突破模型单次上下文的物理限制，而是通过任务拆解、加状态延续、加流程管控，将复杂的、超纲的任务转化为模型可连续执行、可精准完成的系列化任务。
修正脚本
为什么大模型上下文工程必须进入 Harness 时代？从任务复杂度困境到连续任务工程化引言，从单次交付到连续执行的必然突围。 2024年之前，大模型应用的核心命题是如何用一个 prompt 搞定一个任务。 无论是生成一封邮件、解答一个知识问答，还是完成一段简短的文案，任务的边界清晰、流程单一、信息密度适中，模型的单次上下文能力完全足以承载，一次指令一次交付成为主流模式。 但进入2025年，随着对大模型能力期待值的全面提升，我们开始尝试将其投入更复杂的工作场景。 现实很快暴露了传统模式的瓶颈，绝大多数复杂任务本质上都无法通过单次指令完成。 它们要么面临步骤繁多、需逐次决策的困境，要么遭遇输出体量巨大、超出上下文承载的限制。 最终指向同一个核心问题，如何让大模型在单次能力有限的前提下完成复杂任务规模化的目标。 此时，Harness Engineering 的价值彻底凸显。 它不再是简单的提示词升级，而是一套针对复杂任务的连续执行工程化方案。 若用导演与演员的隐喻破题，过去的大模型像拍单镜头短片，每拍一次就要重新开场、重新说戏。 而 Harness 时代的大模型是拍摄一镜到底的长片，导演提前设计好完整剧本，场景规则与状态流转，演员拿到剧本后，在连续的剧情中自主推进，无需反复解释，最终完成整部作品的呈现。 一、复杂任务的两大核心困境，上下文限制下的任务拆解，当前大模型的单次上下文容量始终是复杂任务落地的核心瓶颈。 我们可以将无法一次搞定的复杂任务归纳为两种典型形态。 而这两种形态恰恰对应了现实工作中最常见的两类场景，也直接催生了 harness engineering 的诞生。 一，第一种困境，步骤繁多、逐次决策、 MUD 探索式任务。 这类任务的核心特征是单次信息量小，但步骤数量巨大，且每一步都需模型自主决策。 最典型的代表就是 MUD 迷宫探索、OpenClaw 式搜索、逐步执行的自动化任务等。 以 MUD 探索为例，任务的目标是从起点找到通往终点的路径。 但整个过程无法一次性完成，模型不可能提前获取所有房间的信息，也无法一次性规划出完整路径。 每进入一个新房间，都需要评估周边局势，判断是否有未探索的方向，决策下一步移动的位置，甚至在无路可走时，需要主动回溯至上一节点重新规划。 这意味着任务的每一个环节都依赖大模型对当前场景的理解和判断，无法提前固化为固定程序。 再比如 OpenClaw 式的搜索任务，从寻找目标信息、筛选有效内容，到执行后续操作、反馈结果，每一步都需要模型判断是否找到目标、是否需要调整策略、下一步该执行什么动作。 这类任务的本质是连续的决策序列，步骤数量可能成百上千。 若强行将所有信息塞进单次上下文，不仅会超出模型承载上限，还会导致信息冗余，决策效率低下。 若跳过某一步的模型判断，又极易因局势误判陷入错误路径，甚至掉进沟里。 对于这类任务，传统程序无法替代，因为传统程序只能执行固定逻辑，无法应对自然语言判断、局势评估这类模糊动态的决策场景。 因此，唯一的解法就是将任务拆分为无数个微步骤，每一步都调用大模型完成一次决策。 同时用动态上下文维持任务状态的延续，确保模型不会失忆。 二，第二种困境，体量巨大、单次超限、长代码重构式任务。 这类任务的核心特征是步骤数量少，但单次输出信息密度极大，超出模型上下文承载能力。 常见于大型代码修改、长函数重构、长文档编辑、复杂项目整体规划等场景。 举个代码开发的例子，假设要修改一个几千行的代码文件，核心需求是调整某个核心逻辑。 此时模型无法一次性输出整个修改后的完整代码，一方面上下文容量有限，无法承载全部代码内容。 另一方面，即使能承载，一次性修改整体代码也极易出现逻辑漏洞、依赖冲突，且难以定位错误。 更关键的是，若遇到一个超长函数，违背代码规范但实际存在的场景，即便只修改其中一个功能模块，也可能因函数篇幅过长导致模型无法完整理解整体逻辑，最终输出错误结果。 再比如长文档编辑，若要对一篇万字长文进行整体润色、结构调整或内容优化，一次性输入全部文档不仅会超出上下文，还会让模型难以聚焦核心修改点，输出效果大打折扣。 这类任务的痛点在于单次信息密度超过模型上限。 即便任务本身是单一目标，但因输出体量过大，无法通过一次指令完成。 此时解决思路同样是拆解，将庞大的任务拆分为多个细粒度子任务。 比如先修改代码文件的模块 A，再优化模块 B，最后整合整体逻辑。 或将长文档拆分为多个段落，逐段进行润色调整，再拼接整合。 每一步只处理有限的上下文，确保模型能够精准理解，精准输出。 同时通过 harness 控制整体流程与状态衔接，保证子任务之间的逻辑连贯。 二、核心本质，复杂任务等于单次上下文能力的超纲挑战。 无论是 MUD 探索式的步数多、单次小，还是长代码重构式的步数少、单次大，两类困境的本质其实是同一个：复杂任务的整体特征超出了大模型单次上下文的承载、理解与输出能力。 我们可以用一个简单的公式拆解，复杂任务体量等于上下文承载上限乘任务复杂度系数。 当任务体量大于单次上下文承载上限，且任务复杂度系数大于一，即任务非单一、非原子。 存在状态流转，单次交付模式必然失效。 从上下文维度看，模型的单次上下文容量是固定的，无法无限扩大。 即便未来模型上下文持续提升，也总会遇到超纲的复杂任务。 从任务维度看，复杂任务本身具备序列性、状态依赖性、模糊决策性。 MUD 探索依赖每一步的状态变化，长代码重构依赖模块间的逻辑关联，这些都无法通过一次性指令完全覆盖。 而传统提示词工程的局限恰恰在于它只适配单次上下文内的简单任务，无法应对超纲的复杂场景。 它无法解决步骤繁多时的状态延续问题，也无法破解体量巨大时的上下文超限困境。 这就像导演拍电影，若只拍一个镜头，只能呈现一个碎片化的场景。 若要拍完整部电影，必须设计完整的剧本、场景转换、状态流转，让演员在连续的剧情中完成表演。 Harness engineering 的核心价值 正是针对这一本质困境，它不试图突破模型单次上下文的物理限制，而是通过任务拆解、加状态延续、加流程管控，将复杂的、超纲的任务转化为模型可连续执行、可精准完成的系列化任务。
英文翻译
Why must large model context engineering enter the Harness era? From the dilemma of task complexity to the introduction of continuous task engineering, and the inevitable breakthrough from single delivery to continuous execution. Before 2024, the core proposition of large model applications was how to use a single prompt to complete a task. Whether generating an email, answering a knowledge question, or writing a short piece of copy, the task boundaries were clear, the process was simple, and the information density was moderate. The model's single context capability was fully sufficient to handle it, making one instruction, one delivery the mainstream model. However, entering 2025, with a comprehensive increase in expectations for large model capabilities, we began to attempt deploying them in more complex work scenarios. Reality quickly exposed the bottlenecks of the traditional model. Most complex tasks essentially cannot be completed through a single instruction. They either face the dilemma of multiple steps requiring sequential decisions, or encounter the limitation of output volume being too large, exceeding the context's capacity. Ultimately, they all point to the same core issue: how to enable large models to achieve the goal of scaling complex tasks under the constraint of limited single context capability. At this point, the value of Harness Engineering becomes fully evident. It is no longer a simple upgrade of prompts, but a systematic engineering solution for continuous execution of complex tasks. Using the metaphor of a director and actors to break the ground, past large models were like shooting single-shot short films, where each shot required a fresh start and re-explanation of the scene. In contrast, the Harness-era large model is like shooting a one-take feature-length film. The director designs a complete script in advance, with scene rules and state transitions. After receiving the script, the actors autonomously advance through the continuous narrative without repeated explanations, ultimately completing the entire work. 1. The Two Core Dilemmas of Complex Tasks: Task Decomposition under Context Limitations. The single context capacity of current large models remains the core bottleneck for deploying complex tasks. We can categorize complex tasks that cannot be completed in one go into two typical forms. These two forms precisely correspond to the most common scenarios in real-world work and directly gave rise to Harness Engineering. First, the first dilemma: tasks with numerous steps, sequential decisions, and MUD exploration-style tasks. The core feature of such tasks is a small amount of information per step but a huge number of steps, with each step requiring the model to make autonomous decisions. The most typical representatives are MUD maze exploration, OpenClaw-style search, and stepwise automated tasks. Taking MUD exploration as an example, the task goal is to find a path from the start to the end. However, the entire process cannot be completed in one go. The model cannot obtain information about all rooms in advance, nor can it plan a complete path at once. Each time it enters a new room, it needs to evaluate the surrounding situation, determine if there are unexplored directions, decide where to move next, and even actively backtrack to the previous node and re-plan when there is no way forward. This means every step of the task relies on the large model’s understanding and judgment of the current scene and cannot be pre-fixed into a fixed program. Another example is OpenClaw-style search tasks, from finding target information, filtering effective content, to executing subsequent operations and providing feedback, each step requires the model to judge whether the target has been found, whether the strategy needs adjustment, and what action to take next. The essence of such tasks is a continuous sequence of decisions, with potentially hundreds or thousands of steps. Forcibly stuffing all information into a single context not only exceeds the model's capacity but also leads to information redundancy and low decision-making efficiency. Skipping the model's judgment at a certain step can easily lead to falling into an incorrect path due to misjudgment of the situation, or even hitting a dead end. For such tasks, traditional programs cannot substitute because they can only execute fixed logic and cannot handle vague and dynamic decision-making scenarios involving natural language judgment and situation assessment. Therefore, the only solution is to decompose the task into countless micro-steps, each step invoking the large model to complete a decision, while maintaining task state continuity with dynamic context to ensure the model does not lose memory. Second, the second dilemma: tasks with massive volume, single-exceedance, and long-code refactoring tasks. The core feature of such tasks is a small number of steps but extremely high information density per single output, exceeding the model's context capacity. They are common in scenarios such as large-scale code modification, long function refactoring, long document editing, and overall planning of complex projects. Take code development as an example: suppose you need to modify a code file of several thousand lines, with the core requirement of adjusting a key logic. At this point, the model cannot output the entire modified code at once. On one hand, the context capacity is limited and cannot accommodate all code content. On the other hand, even if it could, modifying the entire code at once easily introduces logic vulnerabilities, dependency conflicts, and makes it difficult to locate errors. More critically, if encountering an excessively long function that violates coding standards but exists in practice, even modifying only one functional module might result in the model failing to fully understand the overall logic due to the function's length, ultimately outputting erroneous results. Another example is long document editing: if you need to globally polish, restructure, or optimize content for a document of tens of thousands of words, inputting the entire document at once not only exceeds the context but also makes it hard for the model to focus on key modification points, significantly degrading output quality. The pain point of such tasks lies in the single-output information density exceeding the model's limit. Even if the task itself has a single goal, the output volume is too large to be completed with one instruction. The solution here is also decomposition: break the massive task into multiple fine-grained subtasks. For example, first modify module A of the code file, then optimize module B, and finally integrate the overall logic. Or split the long document into multiple paragraphs, polish each paragraph sequentially, then splice and integrate. Each step only processes a limited context, ensuring the model can accurately understand and accurately output. Meanwhile, use the harness to control the overall process and state transitions, ensuring logical coherence between subtasks. 2. Core Essence: Complex Tasks Equal a Challenge That Exceeds Single Context Capability. Whether it is the MUD exploration type with many steps and small per-step input, or the long-code refactoring type with few steps and large per-step output, the essence of both dilemmas is the same: the overall characteristics of a complex task exceed the single context’s capacity to carry, understand, and output. We can use a simple formula to break it down: complex task volume = context capacity ceiling × task complexity coefficient. When the task volume exceeds the single context capacity ceiling and the task complexity coefficient is greater than 1—meaning the task is not single or atomic, and involves state transitions—the single-delivery model inevitably fails. From the context dimension, the model's single context capacity is fixed and cannot be expanded infinitely. Even if future models' context continues to improve, there will always be complex tasks that exceed the limit. From the task dimension, complex tasks inherently possess sequentiality, state dependency, and fuzzy decision-making. MUD exploration relies on state changes at each step; long-code refactoring relies on logical associations between modules—none of these can be fully covered by a single instruction. The limitation of traditional prompt engineering is precisely that it only adapts to simple tasks within a single context and cannot handle complex scenarios that exceed the limit. It cannot solve the problem of state continuity when steps are numerous, nor can it overcome the context overflow dilemma when the volume is massive. This is like a director making a movie: if only one shot is taken, only a fragment of a scene is presented. To make a complete film, a full script, scene transitions, and state flows must be designed, allowing actors to perform within a continuous narrative. The core value of Harness Engineering is precisely aimed at this fundamental dilemma. It does not attempt to break through the physical limitations of the model's single context; instead, through task decomposition, state continuity, and process control, it transforms complex, out-of-scope tasks into a series of tasks that the model can execute continuously and complete accurately.
back to top