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

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 时代的核心意义，让每个复杂任务都能在精密的剧本设计下，由优秀的演员完成一场完美的长镜头表演。