我的征尘是星辰大海。。。
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 的核心价值 正是针对这一本质困境，它不试图突破模型单次上下文的物理限制，而是通过任务拆解、加状态延续、加流程管控，将复杂的、超纲的任务转化为模型可连续执行、可精准完成的系列化任务。
back to top