我的征尘是星辰大海。。。

The dirt and dust from my pilgrimage forms oceans of stars...

-------当记忆的篇章变得零碎，当追忆的图片变得模糊，我们只能求助于数字存储的永恒的回忆

作者:黄教授

手机视频列表

为什么大模型编程要进入Harness时代2

视频

音频

原始脚本

三、Harness Engineering 的核心解法，把复杂任务变成连续长镜头剧本。
面对复杂任务的两大困境，Harness Engineering 并非提供万能公式，而是构建了一套通用的工程化逻辑。
核心是将复杂任务转化为可连续执行的长镜头剧本，让大模型在导演设计的规则下一步一步完成任务。
这套逻辑可拆解为三个核心环节，适配所有复杂任务场景。
一，第一步，任务拆解，把超纲任务拆成可执行微任务。
任务拆解是 harness engineering 的基础，也是解决上下文超限的核心手段。
拆解的核心原则是适配模型单次上下文能力，同时保留任务核心逻辑。
具体分为两种拆解思路，针对步骤繁多、逐次决策的任务如 MUD 探索，采用序列微拆解。
不改变任务的核心逻辑，而是将完整的决策流程拆分为多个独立的微步骤。
每一个微步骤对应模型一次完整的决策，一次上下文交互。
比如 MUD 探索中，进入起点评估周边，移动至相邻房间是一个微步骤。
在相邻房间判断是否有新路径移动或回溯是另一个微步骤。
每个微步骤的信息量都在模型单词上下文承载范围内，且都需要模型自主决策。
针对体量巨大单词超限的任务，如长代码重构，采用力度微拆解，将庞大的任务主体拆分为多个细力度的子任务主体。
比如将一个几千行的代码文件拆分为多个功能模块。
将一个超长函数拆分为多个小函数，将一篇万字长文拆分为多个段落或章节，每个子任务的体量都控制在模型单次上下文可承载的范围内，确保模型能够完整理解，精准输出。
同时子任务之间保留核心逻辑关联，避免出现拆分后逻辑断裂。
二，第二步，状态延续，用动态上下文搭建剧情桥梁。
如果说任务拆解是把大任务拆成小任务，那么状态延续就是让小任务串联成完整作品。
大模型的天然缺陷是无状态，单次交互结束后无法主动记忆之前的任务状态。
而复杂任务的核心痛点正是每一步都依赖之前的状态。
Harness Engineering 通过动态上下文传递完美解决了这一问题。
简单来说就是将每一步任务的执行结果、状态变化完整转化为下一步任务的核心上下文，让模型在连续交互中始终保持记忆，如同演员在长镜头剧情中始终记得自己的台词、动作与前续情节。
以 MUD 探索为例，第一步执行移动至相邻房间 A 后，模型会记录当前路径为起点 A，以探索区域为起点 A。
这些状态信息会作为新的上下文传递给第二步交互。
第二步中，模型基于这些状态判断房间 A 的所有邻居均已探索，进而决策回溯至起点，并再次更新状态为当前路径为起点，已探索区域为起点 A。
 每一步的状态更新都无缝传递，确保模型从未迷路，始终在正确的路径上推进。
对于长代码重构任务，第一步修改完模块 A 后，模型会记录模块 A 已完成修改，核心逻辑为叉叉叉。
这些状态信息会作为第二步的上下文，让模型在修改模块 B 时能够兼顾模块 A 的修改逻辑，避免出现依赖冲突。
这种动态的状态延续正是 Harness Engineering 区别于传统提示词工程的核心。
传统提示词无法维持状态，每一次交互都是重新开始。
而 Harness Engineering 让模型实现了一镜到底的连续执行。
三，第三步，流程管控，用规则设计导演式剧本。
任务拆解和状态延续解决了能不能做的问题，而流程管控则解决了做的对、做的稳的问题。
Harness Engineering 的流程管控本质是导演设计剧本，为大模型设定清晰的角色、规则、状态边界与输出格式。
确保模型在连续执行中不偏离轨道。
具体来说，流程管控包含三个核心要素。
一、角色与规则设定，为模型赋予清晰的身份与行为准则。
比如 MUD 探索任务中，将模型设定为资深地图探索者，规则明确优先探索未访问区域，无路可走时回溯，禁止重复遍历。
长代码重构任务中，将模型设定为资深后端开发者，规则明确修改需保留原有核心逻辑，保证代码兼容性，输出完整修改后代码。
清晰的角色与规则能让模型快速进入状态，避免输出偏离任务目标。
二、状态边界定义。
明确任务中需要维护的核心状态，以及状态的更新传递规则。
比如 MUD 探索的当前路径、已探索区域，长代码重构的已修改模块、待修改模块。
通过定义状态边界，模型能清晰知道需要记住什么、该传递什么，避免状态混乱或丢失。
三、输出格式规范，统一模型的输出格式，确保结果可直接使用、可衔接。
比如 MUD 探索中要求输出下一步行动加状态更新摘要，长代码重构中要求输出修改说明加完整修改后代码片段。
标准化的输出格式不仅提升了任务执行效率，也便于人工或程序校验结果的准确性。
这三个要素共同构成了 Harness 的剧本框架。
导演、Harness 设计者通过设计这个框架，让大模型这个演员在连续的任务执行中始终有章可循、有规可依，最终完成复杂任务的整体交付。
四、关键分界，能写程序的任务 vs 需模型决策的任务。
在复杂任务的处理中，还有一个关键的判断维度，哪些任务可以用传统程序完成？哪些任务必须依赖 Harness Engineering 加大模型？这个分界决定了 Honey's engineering 的适用边界，也让其价值更加凸显。
一、可写程序的任务，固定流程，无需模糊决策。
这类任务的核心特征是流程固定、规则明确、无模糊语义判断，传统程序可以完全覆盖，无需依赖大模型的决策能力。
比如，标准化的文件备份、整理任务、固定的源路径、目标路径复制规则 程序可自动遍历、复制、重命名。
格式转换任务，固定的输入格式、输出格式，程序可直接解析并转换。
固定流程的自动化操作，如按固定顺序执行一系列指令，无任何条件判断。
这类任务本质上是确定性任务，传统程序的执行效率、稳定性远高于大模型，因此无需引入 Harness Engineering。
二、需模型决策的任务，模糊场景需自主判断。
这类任务的核心特征是流程不固定，存在模糊语义判断，需基于场景自主 决策，传统程序无法表达，必须依赖大模型，且需要 harness engineering 进行任务拆解与状态延续。
比如， MUD 探索、 OpenClaw 搜索，需要模型判断局势、选择路径、调整策略，无法通过固定程序实现。
代码逻辑修改重构，需要模型理解代码意图、分析依赖关系、判断修改边界，传统程序无法完成。
长文档编辑、内容优化，需要模型把握整体风格、调整逻辑结构、优化语言表达，依赖自然语言理解能力。
复杂项目规划、方案设计，需要模型整合多维度信息、权衡不同方案、输出个性化规划。
无固定流程，这类任务的核心是不确定性，而 而大模型的优势正是处理不确定性、模糊场景。
但正因为其不确定性，无法通过单次指令完成，必须借助 harness engineering 拆分为连续步骤，维持状态延续，确保任务精准完成。
五、结语。
Harness 时代，大模型从工具到生产力的跨越，从 MUD 探索的逐次决策，到长代码重构的力度拆解，从上下文限制的客观约束，到复杂任务的本质需求。
Harness Engineering 的诞生，本质上是大模型应用从单点工具走向规模化生产力的必然选择。
过去我们把大模型当成一次性工具，追求用一个指令解决一个问题。
未来我们要把大模型当成连续创作的演员，用 Harness 搭建完整的舞台与剧本，让它在复杂的、长城的、连续的任务中发挥出真正的价值。
Harness engineering 不是技术的堆砌，而是思维的转变，它不再纠结于如何突破模型单次上下文的限制，而是聚焦于如何适配模型的能力边界，设计出可连续执行的工程化方案。
它让复杂任务的落地从不可控走向可控，从碎片化走向系统化，也让大模型真正成为适配复杂工作场景的核心生产力工具。
这就是 Harness 时代的核心意义，让每个复杂任务都能在精密的剧本设计下，由优秀的演员完成一场完美的长镜头表演。

修正脚本

三、Harness Engineering 的核心解法，把复杂任务变成连续长镜头剧本。
面对复杂任务的两大困境，Harness Engineering 并非提供万能公式，而是构建了一套通用的工程化逻辑。
核心是将复杂任务转化为可连续执行的长镜头剧本，让大模型在导演设计的规则下一步一步完成任务。
这套逻辑可拆解为三个核心环节，适配所有复杂任务场景。
一，第一步，任务拆解，把超纲任务拆成可执行微任务。
任务拆解是 harness engineering 的基础，也是解决上下文超限的核心手段。
拆解的核心原则是适配模型单次上下文能力，同时保留任务核心逻辑。
具体分为两种拆解思路，针对步骤繁多、逐次决策的任务如 MUD 探索，采用序列微拆解。
不改变任务的核心逻辑，而是将完整的决策流程拆分为多个独立的微步骤。
每一个微步骤对应模型一次完整的决策，一次上下文交互。
比如 MUD 探索中，进入起点评估周边，移动至相邻房间是一个微步骤。
在相邻房间判断是否有新路径移动或回溯是另一个微步骤。
每个微步骤的信息量都在模型单次上下文承载范围内，且都需要模型自主决策。
针对体量巨大单次超限的任务，如长代码重构，采用粒度微拆解，将庞大的任务主体拆分为多个细粒度的子任务主体。
比如将一个几千行的代码文件拆分为多个功能模块。
将一个超长函数拆分为多个小函数，将一篇万字长文拆分为多个段落或章节，每个子任务的体量都控制在模型单次上下文可承载的范围内，确保模型能够完整理解，精准输出。
同时子任务之间保留核心逻辑关联，避免出现拆分后逻辑断裂。
二，第二步，状态延续，用动态上下文搭建剧情桥梁。
如果说任务拆解是把大任务拆成小任务，那么状态延续就是让小任务串联成完整作品。
大模型的天然缺陷是无状态，单次交互结束后无法主动记忆之前的任务状态。
而复杂任务的核心痛点正是每一步都依赖之前的状态。
Harness Engineering 通过动态上下文传递完美解决了这一问题。
简单来说就是将每一步任务的执行结果、状态变化完整转化为下一步任务的核心上下文，让模型在连续交互中始终保持记忆，如同演员在长镜头剧情中始终记得自己的台词、动作与前续情节。
以 MUD 探索为例，第一步执行移动至相邻房间 A 后，模型会记录当前路径为起点 A，已探索区域为起点 A。
这些状态信息会作为新的上下文传递给第二步交互。
第二步中，模型基于这些状态判断房间 A 的所有邻居均已探索，进而决策回溯至起点，并再次更新状态为当前路径为起点，已探索区域为起点 A。
 每一步的状态更新都无缝传递，确保模型从未迷路，始终在正确的路径上推进。
对于长代码重构任务，第一步修改完模块 A 后，模型会记录模块 A 已完成修改，核心逻辑为叉叉叉。
这些状态信息会作为第二步的上下文，让模型在修改模块 B 时能够兼顾模块 A 的修改逻辑，避免出现依赖冲突。
这种动态的状态延续正是 Harness Engineering 区别于传统提示词工程的核心。
传统提示词无法维持状态，每一次交互都是重新开始。
而 Harness Engineering 让模型实现了一镜到底的连续执行。
三，第三步，流程管控，用规则设计导演式剧本。
任务拆解和状态延续解决了能不能做的问题，而流程管控则解决了做的对、做的稳的问题。
Harness Engineering 的流程管控本质是导演设计剧本，为大模型设定清晰的角色、规则、状态边界与输出格式。
确保模型在连续执行中不偏离轨道。
具体来说，流程管控包含三个核心要素。
一、角色与规则设定，为模型赋予清晰的身份与行为准则。
比如 MUD 探索任务中，将模型设定为资深地图探索者，规则明确优先探索未访问区域，无路可走时回溯，禁止重复遍历。
长代码重构任务中，将模型设定为资深后端开发者，规则明确修改需保留原有核心逻辑，保证代码兼容性，输出完整修改后代码。
清晰的角色与规则能让模型快速进入状态，避免输出偏离任务目标。
二、状态边界定义。
明确任务中需要维护的核心状态，以及状态的更新传递规则。
比如 MUD 探索的当前路径、已探索区域，长代码重构的已修改模块、待修改模块。
通过定义状态边界，模型能清晰知道需要记住什么、该传递什么，避免状态混乱或丢失。
三、输出格式规范，统一模型的输出格式，确保结果可直接使用、可衔接。
比如 MUD 探索中要求输出下一步行动加状态更新摘要，长代码重构中要求输出修改说明加完整修改后代码片段。
标准化的输出格式不仅提升了任务执行效率，也便于人工或程序校验结果的准确性。
这三个要素共同构成了 Harness 的剧本框架。
导演、Harness 设计者通过设计这个框架，让大模型这个演员在连续的任务执行中始终有章可循、有规可依，最终完成复杂任务的整体交付。
四、关键分界，能写程序的任务 vs 需模型决策的任务。
在复杂任务的处理中，还有一个关键的判断维度，哪些任务可以用传统程序完成？哪些任务必须依赖 Harness Engineering 加大模型？这个分界决定了 Harness Engineering 的适用边界，也让其价值更加凸显。
一、可写程序的任务，固定流程，无需模糊决策。
这类任务的核心特征是流程固定、规则明确、无模糊语义判断，传统程序可以完全覆盖，无需依赖大模型的决策能力。
比如，标准化的文件备份、整理任务、固定的源路径、目标路径复制规则，程序可自动遍历、复制、重命名。
格式转换任务，固定的输入格式、输出格式，程序可直接解析并转换。
固定流程的自动化操作，如按固定顺序执行一系列指令，无任何条件判断。
这类任务本质上是确定性任务，传统程序的执行效率、稳定性远高于大模型，因此无需引入 Harness Engineering。
二、需模型决策的任务，模糊场景需自主判断。
这类任务的核心特征是流程不固定，存在模糊语义判断，需基于场景自主决策，传统程序无法表达，必须依赖大模型，且需要 harness engineering 进行任务拆解与状态延续。
比如， MUD 探索、 OpenClaw 搜索，需要模型判断局势、选择路径、调整策略，无法通过固定程序实现。
代码逻辑修改重构，需要模型理解代码意图、分析依赖关系、判断修改边界，传统程序无法完成。
长文档编辑、内容优化，需要模型把握整体风格、调整逻辑结构、优化语言表达，依赖自然语言理解能力。
复杂项目规划、方案设计，需要模型整合多维度信息、权衡不同方案、输出个性化规划。
无固定流程，这类任务的核心是不确定性，而大模型的优势正是处理不确定性、模糊场景。
但正因为其不确定性，无法通过单次指令完成，必须借助 harness engineering 拆分为连续步骤，维持状态延续，确保任务精准完成。
五、结语。
Harness 时代，大模型从工具到生产力的跨越，从 MUD 探索的逐次决策，到长代码重构的粒度拆解，从上下文限制的客观约束，到复杂任务的本质需求。
Harness Engineering 的诞生，本质上是大模型应用从单点工具走向规模化生产力的必然选择。
过去我们把大模型当成一次性工具，追求用一个指令解决一个问题。
未来我们要把大模型当成连续创作的演员，用 Harness 搭建完整的舞台与剧本，让它在复杂的、长程的、连续的任务中发挥出真正的价值。
Harness engineering 不是技术的堆砌，而是思维的转变，它不再纠结于如何突破模型单次上下文的限制，而是聚焦于如何适配模型的能力边界，设计出可连续执行的工程化方案。
它让复杂任务的落地从不可控走向可控，从碎片化走向系统化，也让大模型真正成为适配复杂工作场景的核心生产力工具。
这就是 Harness 时代的核心意义，让每个复杂任务都能在精密的剧本设计下，由优秀的演员完成一场完美的长镜头表演。

英文翻译

III. The Core Solution of Harness Engineering: Transforming Complex Tasks into Continuous Long-Take Scripts.

Facing the two major challenges of complex tasks, Harness Engineering does not offer a one-size-fits-all formula but instead builds a set of universal engineering logic.

The core is to transform complex tasks into continuously executable long-take scripts, allowing the large model to complete tasks step by step under the rules designed by the director.

This logic can be broken down into three core steps, applicable to all complex task scenarios.

1. Step One: Task Decomposition - Breaking Over-the-Top Tasks into Executable Micro-Tasks.

Task decomposition is the foundation of harness engineering and the core method for solving context overflow.

The core principle of decomposition is to adapt to the model's single-context capability while preserving the core logic of the task.

There are two specific decomposition approaches. For tasks with many steps and sequential decisions, such as MUD exploration, sequential micro-decomposition is used.

Without changing the core logic of the task, the complete decision-making process is split into multiple independent micro-steps.

Each micro-step corresponds to one complete decision by the model and one context interaction.

For example, in MUD exploration, entering the starting point, evaluating the surroundings, and moving to an adjacent room is one micro-step.

Judging whether there is a new path to move or backtrack in the adjacent room is another micro-step.

The information volume of each micro-step is within the model's single-context capacity, and each requires the model's independent decision-making.

For tasks with a huge volume that exceed the limit at once, such as long code refactoring, granularity micro-decomposition is used. The massive task body is split into multiple fine-grained subtask bodies.

For example, splitting a code file of several thousand lines into multiple functional modules.

Splitting an overly long function into multiple small functions, splitting a ten-thousand-word article into multiple paragraphs or chapters. The volume of each subtask is controlled within the model's single-context capacity, ensuring the model can fully understand and output accurately.

At the same time, core logical associations are preserved between subtasks to avoid logical disconnection after splitting.

2. Step Two: State Continuation - Building Plot Bridges with Dynamic Context.

If task decomposition breaks a big task into small tasks, state continuation connects the small tasks into a complete work.

A natural flaw of large models is statelessness; after a single interaction ends, they cannot actively remember the previous task state.

The core pain point of complex tasks is that each step depends on the previous state.

Harness Engineering perfectly solves this through dynamic context transfer.

Simply put, it transforms the execution result and state changes of each step into the core context for the next step, allowing the model to maintain memory during continuous interactions, just like an actor in a long-take story always remembers their lines, actions, and preceding plot.

Taking MUD exploration as an example: after the first step executes moving to adjacent room A, the model records the current path as starting point A and the explored area as starting point A.

This state information is passed as the new context to the second interaction.

In the second step, based on this state, the model judges that all neighbors of room A have been explored, then decides to backtrack to the starting point, and updates the state again: current path is starting point, explored area is starting point A.

Each state update is seamlessly transferred, ensuring the model never gets lost and always advances along the correct path.

For long code refactoring tasks: after the first step modifies module A, the model records that module A has been modified, with its core logic being XXX.

This state information serves as the context for the second step, allowing the model to consider the modification logic of module A when modifying module B, avoiding dependency conflicts.

This dynamic state continuation is the core difference between Harness Engineering and traditional prompt engineering.

Traditional prompts cannot maintain state; each interaction starts from scratch.

In contrast, Harness Engineering enables the model to achieve a one-shot continuous execution.

3. Step Three: Process Control - Designing Director-Style Scripts with Rules.

Task decomposition and state continuation solve the "can it be done" problem, while process control solves the "done correctly and stably" problem.

The essence of Harness Engineering's process control is that the director designs the script, setting clear roles, rules, state boundaries, and output formats for the large model.

This ensures the model does not deviate from the track during continuous execution.

Specifically, process control includes three core elements.

1. Role and Rule Setting: Assign a clear identity and behavioral guidelines to the model.

For example, in a MUD exploration task, the model is set as an experienced map explorer, with rules clearly prioritizing unexplored areas, backtracking when there is no path, and prohibiting repeated traversal.

In a long code refactoring task, the model is set as a senior backend developer, with rules specifying that modifications must retain the original core logic, ensure code compatibility, and output the complete modified code.

Clear roles and rules allow the model to quickly enter the state and avoid output diverging from the task goal.

2. State Boundary Definition: Clearly define the core states that need to be maintained in the task, as well as the rules for updating and transferring states.

For example, in MUD exploration: current path and explored area. In long code refactoring: modified modules and modules to be modified.

By defining the state boundaries, the model clearly knows what to remember and what to pass on, avoiding state confusion or loss.

3. Output Format Specification: Unify the output format of the model to ensure that results are directly usable and connectable.

For example, in MUD exploration, require output of the next action plus a state update summary. In long code refactoring, require output of modification explanation plus the complete modified code snippet.

Standardized output formats not only improve task execution efficiency but also facilitate manual or programmatic verification of result accuracy.

These three elements together form the script framework of Harness.

The director, i.e., the Harness designer, designs this framework so that the actor, i.e., the large model, always has rules to follow during continuous task execution, ultimately completing the overall delivery of the complex task.

IV. Key Distinction: Tasks That Can Be Programmed vs. Tasks Requiring Model Decision-Making.

In handling complex tasks, there is also a critical judgment dimension: which tasks can be completed with traditional programs? Which tasks must rely on Harness Engineering + large models? This boundary defines the applicable scope of Harness Engineering and highlights its value.

1. Tasks That Can Be Programmed: Fixed Processes, No Ambiguous Decision-Making.

The core feature of such tasks is fixed processes, clear rules, and no ambiguous semantic judgment. Traditional programs can fully cover them without relying on the decision-making ability of large models.

For example, standardized file backup and organization tasks with fixed source paths, target paths, and copy rules; programs can automatically traverse, copy, and rename.

Format conversion tasks with fixed input and output formats; programs can directly parse and convert.

Automated operations with fixed processes, such as executing a series of instructions in a fixed order without any conditional judgment.

These tasks are essentially deterministic. Traditional programs have far higher execution efficiency and stability than large models, so Harness Engineering is not needed.

2. Tasks Requiring Model Decision-Making: Ambiguous Scenarios Requiring Autonomous Judgment.

The core feature of such tasks is non-fixed processes, ambiguous semantic judgment, and the need for autonomous decision-making based on the scenario. Traditional programs cannot express this, so they must rely on large models and require harness engineering for task decomposition and state continuation.

For example, MUD exploration and OpenClaw search require the model to judge the situation, choose paths, and adjust strategies, which cannot be achieved through fixed programs.

Code logic modification and refactoring require the model to understand code intent, analyze dependencies, and determine modification boundaries; traditional programs cannot do this.

Long document editing and content optimization require the model to grasp the overall style, adjust logical structure, and optimize language expression, relying on natural language understanding.

Complex project planning and solution design require the model to integrate multi-dimensional information, weigh different options, and output personalized plans.

There is no fixed process; the core of such tasks is uncertainty. The advantage of large models is precisely handling uncertainty and ambiguous scenarios.

However, because of their uncertainty, they cannot be completed with a single instruction. They must be broken down into continuous steps with the help of harness engineering, maintaining state continuity to ensure precise task completion.

V. Conclusion.

The Harness Era: The Leap of Large Models from Tools to Productivity.

From sequential decision-making in MUD exploration to granularity decomposition in long code refactoring, from the objective constraint of context limits to the essential needs of complex tasks, the birth of Harness Engineering is essentially the inevitable choice for large model applications to move from standalone tools to large-scale productivity.

In the past, we treated large models as one-time tools, pursuing solving one problem with one instruction.

In the future, we must treat large models as actors in continuous creation, using Harness to build a complete stage and script, allowing them to realize their true value in complex, long-range, and continuous tasks.

Harness Engineering is not a stack of technologies but a shift in thinking. It no longer struggles with how to break through the model's single-context limit but focuses on how to adapt to the model's capability boundaries and design continuously executable engineering solutions.

It makes the implementation of complex tasks move from uncontrollable to controllable, from fragmented to systematic, and truly makes large models a core productivity tool suitable for complex work scenarios.

This is the core significance of the Harness Era: enabling every complex task, under precisely designed scripts, to be performed by excellent actors as a perfect long-take performance.