真正决定 LLM 能不能跑出生产力的，不是模型本身的能力曲线，而是模型外面那层把它从聊天对象变成生产要素的工程结构。这层结构就是 harness。
一、同一枚硬币的两面
围绕大模型的日常讨论里，几乎总是有两种声音同时存在。
一边在骂：
- “让它写个深度报告，满嘴跑火车。”
- “上下文一长就崩，根本处理不了大文档。”
- “复杂一点的活就露馅，也就润色翻译还行。”
- “幻觉太严重，正式场合根本不敢用。”
一边在等：
- “下一代模型肯定能解决。”
- “Agent 自己会规划、会反思、会调工具，等着就行。”
- “以后它自己跑完全程，我只要最后点个头。”
- “AGI 快来了，这些到时候都不是问题。”
听起来一悲一喜，骨子里却是同一件事：把模型当成一个孤立的、会自动进化的智能体来审判或等待——一个嫌它现在笨，一个赌它以后神。它们漏掉的是同一个东西。
二、被忽略的那一层
模型在单次调用里的能力差距，比大多数人感知到的要小得多。 同代旗舰模型之间差距远没有传闻里那么大，跨代升级也没有想象中那么跳跃。如果一件事在 GPT-5 上做不出生产价值，换下一代模型，往往只是从”经常错”变成”偶尔错”——而偶尔错的产出在严肃场景里和经常错没本质区别，因为你依然不知道这一次错没错。
真正的能力跃迁，几乎从不来自模型本身，而是来自模型外面那层结构。 任务怎么拆、中间结果怎么存、哪步错了怎么发现、发现后从哪接着跑、产出怎么验证、不同次运行之间怎么比对——这些全都不是模型的事，但它们决定了模型这一次输出能不能变成可被使用的成果。这并不是个人观察：Forrester 2026 年的调研显示，约 88% 的企业 agent 项目卡在试点进不了生产，失败原因几乎全在验收标准不清、数据接入不足、评测漂移这些工程问题上，不在模型本身的能力上。
对话模式的根本问题就在这里：它把模型扔进了一个最裸的工程环境——没状态、没验证、没恢复、没审计、没评测。在这种姿态下消费一个昂贵的推理能力，结果必然是”惊艳的时候惊艳，致命的时候致命”，而且你永远猜不到下一次是哪一种。
骂的人把锅甩给模型，等的人把希望寄给模型。可模型其实已经够用了——是它周围什么都没有。这层被忽略的结构，行业里已经有了名字，叫 harness engineering。
打个比方：一台高精度车床，放在一张没有夹具、没有量规、没有工序单、没有质检流程的空台面上，然后抱怨它精度不够，或者指望它哪天自己学会造汽车——都问错了对象。车床的精度从来不是瓶颈，承载车床的那套工程化程度才是。
三、harness 到底是什么
补上夹具、量规、工序单和质检——这件事靠的不是更好的车床，而是一整套让不稳定的单点能力变成稳定产出的工程结构。harness 这个词在软件工程里早有用法（如 test harness），核心意思就是”把不稳定的对象包起来、给它输入、检查它输出”——放到 LLM 上，含义完全一致。
harness 是把不稳定的 LLM 包装成稳定、可恢复、可审计的工作流的工程结构。它不改变模型本身的能力，但决定这个能力能不能被持续、可靠、可验证地兑现。
用工厂的语言来分层看，非常清楚：
- prompt 是单个工位的操作说明。 它告诉模型这一刻该干什么、按什么格式输出。必不可少，但远远不够——一条打磨得再漂亮的 prompt，在没有上下文管理、没有质检、没有重试机制的环境里，只是一个孤零零的工位。
- skill 或 pipeline 是多个工位串成的工序。 任务被拆开，每步有自己的输入和产出，工位之间靠约定的格式传递。这一层开始有结构了，但还不够——工序本身不解决”中间出错怎么办""怎么确认这一步是对的""怎么单独重跑某一步”。
- harness 是整条生产线的工程语言。 工位之间有缓冲区（持久化的中间产物），有质检站（程序化校验），有断点续跑机制，有完整的审计轨迹，有端到端的验证。它关心的不是某一个工位干得漂不漂亮，而是整条线在各种异常情况下，能不能稳定产出合格品。
说”生产线”不是要搞单向、僵死的流水线——它允许局部返工、允许分支、允许人机混合。借用工厂的语言，是为了引入工程化的姿态，不是引入工厂的僵化。
四、一条生产线必须有的六个基本面
接受了”要为任务造一条生产线”这个视角之后，这条线至少得具备六个基本面。它们不是六条孤立的清单，而是一组互相咬合的结构——契约定义”什么算对”，状态和质检让”对不对”可以被外部判定，可恢复和可审计让生产线在长时间、多次出错之后依然不崩，可评测让整条线本身能被持续打磨。
flowchart TB
Truth["契约：唯一真理源"]
State["状态：可持久化"]
QC["质检：程序化"]
Resume["可恢复：断点续做"]
Audit["可追溯：审计留痕"]
Eval["可评测：触发与产出"]
Truth --> State
Truth --> QC
State --> Resume
QC --> Audit
Audit --> Eval基本面一：契约先于实现
产线上每一个工位、每一道质检、每一份文档，都面向同一份契约。契约定义的是”什么算合格产出”——这不仅是字段名、数据类型、取值范围这种结构性约束，也包括来源规则、事实引用要求、风格边界、风险等级、什么情况下要升级到人工。结构化数据流水线只是 harness 的一种形态，凡是有”合格定义”的产出，都需要先有契约。所有人、所有脚本、所有评审者只读这份契约，不互相抄对方的实现。
契约一立，工位之间就有了共同语言；契约一旦漂移，整条线就会出现”生产的写 A、消费的读 B、质检的查 C”这种隐形断裂。
对话模式没有这一层——每次对话都在重新协商”什么算好”，所以”它每次输出都不一样”的抱怨永远在循环。
在 harness 里，这意味着你会有一份独立于任何具体实现、被全员视作唯一真理源的产出验收标准。
基本面二：状态必须落盘
产线上每一步的中间产物，都必须以结构化形式离开模型的上下文，存到外部可读写的地方。下一步从硬盘读，不从对话历史里翻；外部脚本能直接打开、校验、复用。
只要中间状态还活在上下文里，整条线就脆得像玻璃——上下文一满就丢、一断就没、换个对话窗口就消失。把状态落到上下文之外，是一切工程化的起点。
对话模式没有这一层——所有”中间结果”都只活在对话里，所以”上下文一长就崩""会话断了就要从头来”这类问题不是模型的缺陷，是使用姿态的必然结果。
在 harness 里，这意味着你会有一组和模型上下文解耦的中间产物盒子——一个命名规整的文件夹就够了，每一步的成果先落进盒子，再传给下一步。
基本面三：质检要程序化
每一道工序结束，必须有一个不依赖 LLM 的程序，能在秒级判断”这一步合格还是不合格”。它读契约、读产物，比对、计算、检查边界，输出明确的通过或失败。
让 LLM 自己检查自己，等于让工人自己给自己签验收单，本质上不构成质检。程序化质检的价值不在于它比模型更聪明，而在于它绝对一致、永远在场、不会被说服。
这里需要诚实地承认一个边界：程序化质检覆盖的是硬约束——字段、加总、链接、格式、引用是否真实存在。对于软判断（论点是否原创、表达是否准确、研究是否到位），程序无能为力，得交给样例集、人工抽检或多轮评审。但软判断和硬约束并不互斥——能交给程序的部分坚决不要交给模型自检，剩下的部分再设计人工流程。“模型自称检查过了”不构成质检，这条在软任务里同样成立。
在 harness 里，这意味着每一道工序后面都立着一个不依赖 LLM 的独立校验器——硬约束由它兜底，软判断由它之外的样例集和人工流程兜底。
基本面四：失败要能局部恢复
产线必须能精确回答：“失败发生在哪一步？哪些中间产物还能用？从哪里重跑？“——而且重跑的粒度是单个工位，不是整条线。
一处出错就要整条线重来的工作流，没有生产经济性：每次失败都是全损，任务越长越赔不起。能局部恢复的工作流，把失败成本压到最小的那一步上，整体稳定性从”单次成功率”跃升到”长期可用性”。
在 harness 里，这意味着你会有一种进度感知机制：随时能查出”哪些工位已经过了、哪些还没过、从哪里继续”，重做的最小单位是工位而不是整条线。
基本面五：过程要可审计
每一步的产出都要带上时间戳、数据来源、依赖版本、当时用的 prompt 和参数。事后任何一刻，都能回答”为什么这次的结果是这样”。
顺利的时候这些看起来是冗余，出事的时候就是救命稻草。没有审计留痕的产线，一旦输出有问题，所有人只能猜——而猜出来的结论既不能验证，也不能复用，同样的错误就会换着花样反复出现。
在 harness 里，这意味着每一次运行都会留下一份可回放的运行记录：输入是什么、模型版本是什么、外部依赖是什么版本，事后都能精确还原。
基本面六：行为要可评测
整条线本身要有一套可重复的评测：哪些输入应该触发、哪些不该触发、产出的关键属性是否稳定。每次改动之后跑一遍，立刻知道是变好还是变坏。
这一面和”质检独立”容易被混在一起，区别在工作的时间尺度：质检管每一次跑——拦下这次的不合格产出；评测管每一次改——判断改动让整条线变好还是变坏。只有质检没有评测，你不敢动这条线；只有评测没有质检，单次错产出拦不住。
没有评测的工作流不能被持续打磨——你不知道这次改对了还是改坏了，于是要么不敢动，要么乱动。可评测，才让工作流进入持续优化的轨道，而持续优化是对话模式从根上做不到的事情。
对话模式没有这一层——它的”好不好用”只能靠感觉判断，所以”这个工具有时管用有时不管用，没法预测”几乎是对话模式工具的宿命。
在 harness 里，整条线本身也是产品——一组固化的测试样本立在那里，每次改动跑一遍，“好没好”由数据回答，不由感觉回答。
把这六个基本面摞在一起，得到的就是一条真正意义上的生产线：契约稳定、状态外化、质检独立、失败可恢复、过程可追溯、整体可评测。缺任何一条，整条线都会退化回手工作坊；六条全到位，模型那点内在的不稳定就被结构吃掉了。
五、什么任务值得这么搞
在把这套视角应用回手头任务之前，先承认三件事，避免它被当成”什么都该上 harness”的口号。
第一，不是所有任务都值得造 harness。 一次性的脑暴、闲聊式的咨询、用完就扔的草稿，强行包一层工程结构反而是负担。值得动手的，是同时具备下面几条的任务：高频（会反复发生，沉淀下来才有规模效应）、长链路（多步骤、有中间产物，失败容易积累）、高损失（错了用户会真正受伤，或者重做代价大）、可验证（哪怕只有部分维度能被程序化校验，也比完全靠感觉强）。
第二，模型在某些维度的跃迁确实会带来质变。 长上下文、多模态、工具使用的成熟度，会让一些原本”不可能用 LLM 做”的任务变成可能。对这类任务，等模型是对的——只是等到之后，照样要为它造 harness 才能投产。
第三，harness 不能把不及格的模型变成生产线。 它要解决的是”模型够格但不可控”——在单步上勉强能跑通、只是输出不稳定的能力，靠工程包装兑现成可靠产出。如果模型连单步都给不出可用的结果（比如领域知识完全欠缺、关键推理稳定失败），再精巧的 harness 也只是把不及格的产出更整齐地排列出来。这种情况下确实要等模型，或者换个任务。
六、问题会换一种问法
“AI 能不能做这件事”——这个问法把自己从这件事里摘出去了，留给模型厂和产品厂去回答。但 harness 这层结构，模型厂不会替你建，产品厂也只能给到通用脚手架；贴着具体任务的那条产线，只能自己搭。
所以这件事能不能成，从一开始就不是问给别人的问题，而是问给自己的：愿不愿意把自己当成这个任务的 harness 工程师。回答这个问题之前，“AI 行不行”是个伪命题——因为根本没人在让它行。