从Prompt到Harness：大模型工程化三代范式演进与落地实践

两年前我接手一个内部订单语义解析的优化任务当时觉得把需求文档写得足够细模型输出就能稳定复现。结果上线第一周就翻车同一句话换了一种问法解析结果就多出一个假字段。那段时间到处刷Prompt技巧的文章好像把提示词调好就能解决一切。回头折腾大半年从一版接一版的Prompt补丁一直做到带状态约束的编排系统才真正想明白大模型工程化的分水岭从来不是提示词写得妙而是让模型从主角退成组件让一套可测试、可观测、可回退的Harness来兜底。这篇文章就聊聊我从Prompt到Harness这段实践中看到的第三代范式演进逻辑和具体落地方案。1. 大模型工程化的两道分水岭从能跑到敢上生产先说结论我把过去几年看到的工程方式粗分成三代每一代背后都不是技术名词的变化而是我们到底把不确定性放在哪里的思路变化。第一代是纯Prompt主导配合少量脚本和向量库。模型是主角几乎所有业务逻辑都以自然语言写进提示词代码只负责调用接口、把结果塞进下一个业务系统。这套方案胜在轻快想验证一个场景一两天就能搭出Demo。问题也明显结果好不好几乎只能靠人眼抽查来保证prompt稍微一改可能有几十条历史case悄悄变坏你根本不知道。第二代是代码优先的可编程编排。社区里出现了一批开源框架把调用模型这件事从裸API变成可组合的流程对象。你可以用代码描述先总结、再抽取、最后判断可以在中间插工具调用、插向量检索。这比第一代强在流程可见了、断点可调试了、分支逻辑可以写测试了。我一度觉得这就是终局。但用着用着就发现不对劲这类框架的思路是把语言模型嵌进一段一段的代码流程里可是最终真正送到模型嘴边的还是大段大段的Prompt字符串。所谓编排很多时候只是把原来堆在变量里的提示词换个地方堆进了框架的节点模板。跑一个链路中间某个Agent忽然返回JSON聊爆了你翻日志只能看到模型产生了非预期输出至于为什么、怎么补偿框架基本不管。第三代就是我说的Harness范式。它不是某个具体框架而是一套工程主张把大模型当成一个不可靠但能力很强的组件放入确定性系统中。系统负责解析输入、调度节点、校验输出、失败重试、超时熔断、离线回放、在线监控。模型只在一个被严格控制边界的窗口里做语义生成其余全部交给确定性的代码和规则。Prompt仍然存在但它只是Harness内部一个可替换的部件配置而不是整个系统的行为来源。三代范式在几个关键维度上的差异我整理成了一张表维度第一代Prompt主导第二代可编程编排第三代Harness治理行为来源自然语言提示词代码流程提示词确定性约束受控生成可测试性靠人审流程可测生成环节不可测离线回放Golden Set语义校验可观测性只有日志和结果链路可见心智负担高每个环节有结构化状态与指标失败处理重试/人工介入部分重试补偿逻辑自己写默认含重试/回退/熔断策略变更成本改prompt影响全局改代码结构影响全局改单个节点有回归保障面向对象对话流程持续运行的生产任务强调一下敢上生产这四个字。绝大多数团队的瓶颈根本不在模型效果而在于你不敢对一个概率系统做SLA承诺。Harness解决的就是这种事让不确定的部分足够小并且被卡在确定性的盒子里。2. 第一代范式的隐形天花板一份订单解析Prompt的失控复盘讲个具体的失控过程。当时某业务线的订单解析任务输入是客户通过工单系统提交的自然语言诉求要抽取出商品、数量、地址、加急标记、特殊备注这五个字段。团队里一位同学精心设计了一份Prompt前面是角色设定和输出JSON格式说明中间是五个字段各自的抽取规则后面附了六个few-shot例子。第一版上线准确率大概有93%大家都挺兴奋。之后两周开始迭代运营反馈某些地域简称识别错了就在Prompt里加注意以下地址别名映射紧接着又有漏抽规格的情况再加一条如果出现规格关键词务必抽取到spec字段。到第四版光输出格式部分已经写了十几条约束。问题开始批量出现修好了地址别名几天后一个新的few-shot例子让模型在另外一个case上把数量填进了价格字段。最崩溃的是有一次只删掉一个示例全量回归直接掉了三个百分点。复盘时我们意识到第一代范式的天花板不在于提示词技巧而在于几个结构性缺陷。第一是上下文漂移。Prompt越写越长模型注意力的重心分布不可见。你以为新增一条规则只是添加信息实际上它在改变模型对已有信息的权重排序。没有任何工具能告诉你这条规则到底影响了哪部分注意力。第二是输出契约不可强制。你可以要求请只返回合法JSON但当模型返回一段插在Markdown代码块里的JSON注释时整条链路就断了。代码里要么堆一堆容错正则要么直接失败人工处理。这不是个别现象这是概率系统下必然存在的长尾。第三是回归测试只能靠人眼。自然语言的改动没有diff概念。你不能说这版Prompt相对上版只改了第13行到第17行因为模型不是按行执行的。想验证改动的副作用唯一的办法就是把历史case全部跑一遍然后肉眼对比这是纯劳动力还带主观性。后来我们给这份Prompt外挂了RAG建了一个客户备注常见用语的向量库每次请求先检索相似表达作为上下文注入。RAG的确把一部分低频表达覆盖掉了准确率回到94%左右。但这解决的是资料外挂不是行为控制。模型仍然可能无视检索到的内容直接按自己的理解输出也仍然可能伪造一个看起来合理的字段。基本盘不稳资料再全也没用。这段经历让我形成一个判断第一代路径里人一直在迁就模型。你把规则写成自然语言、把示例排好顺序、把输出格式期望写进角色设定本质上是在一个不可测试的表面上持续打补丁。这种模式适合快速验证不适合持续交付。3. 第二代范式的得与失可编程编排把复杂度外置之后第一代走到头之后我把目光转向当时已经火起来的一类开源编排框架。这类框架的核心贡献我现在依然承认它第一次把调用大模型从发一个请求变成描述一段流程。你可以在代码层面声明输入、输出、工具、内存甚至把多个模型角色串成一个图状流水线。这对工程团队的吸引力是巨大的毕竟代码是能review、能单测、能上CI的。做一个具体对比就知道差别在哪。第一代方案里地址校验只能靠Prompt写一句请确认地址格式是否正确如不正确请给出修正建议。模型回一句地址看起来没问题然后就没有然后了。在第二代框架里你可以挂一个真实的地址解析函数让模型只负责抽取原始地址字符串标准化处理交给确定性的算法。光是这一点地址字段的错误率就下降了一大截。所以我说第二代范式是复杂度外置。框架逼着你把一段模糊的任务拆成多个可命名、可调用的环节每个环节有输入输出定义这本身就是工程化的一大步。尤其对我这种习惯写后端的开发者来说用代码描述AI流程就像从写自由文本的说明书进步到写有类型的函数整个体验是代际级别的。但第二代也留下了两笔很重的债务。一是节点内部黑盒。框架让你拆出了节点但每个节点内部做的事依然是把几段Prompt拼接一下发给模型。节点可以命名成Summarizer、Extractor、Router可从外部看它就是一个不可控的生成函数。你不清楚它内部Prompt长什么样不知道它在什么条件下会跑偏也不知道它输出多大体积的文本。调试的时候你面对的还是模型说了一堆废话这种没有结构化原因的异常。二是编排逻辑与调试心智的撕裂。越复杂的图状链路越容易藏着隐式依赖。A节点的输出格式是B节点Prompt里的示例来源C节点期待D节点在某种分支下返回空列表这些约束散落在代码各个文件里运行时才暴露。框架本身的抽象能力强不代表使用者的业务复杂度能被自动消化。我在第二代框架上做了一个多节点的工单分类器最后代码结构长得像一棵圣诞树策略路由、模型节点、工具节点、校验节点层层嵌套每个节点里都是一大段Prompt模板加解析逻辑。线上出问题时我经常要同时打开四五个文件才能定位一次异常输出发生在哪个环节。那段时间我深刻体会到编排框架能外置复杂度却不能自动降低复杂度它只是把提示词不可调试的问题暂时转移成了代码流程不可见但有迹可循的问题。也正是这些债催生了第三代思路既然模型是不可靠组件那就不该让它承载系统级的行为决策。系统的行为应该由可测试的结构定义模型只负责在特定约束窗口里做生成。4. 第三代范式Harness的第一性原理把模型从主角降为组件先给个我自己的定义Harness是一套围绕大模型推理建立的确定性控制结构它接管输入、输出、校验、纠偏、路由、重试、监控等全部周边能力让模型生成只发生在最小的必要环节。它的设计出发点不是如何让模型更聪明而是如何让一套包含不可靠模型的系统仍然有可靠行为。我在落地时把它拆成四个物理层每一层都有明确职责4.1 解析层用确定性代码处理入口信号所有外部输入先走解析层把原生文本、工单信息、日志片段改造成结构化的中间表示。这个阶段不使用大模型。比如对订单解析任务我先用模板匹配和正则在入口处把客户ID提交时间渠道来源这些元信息剥出来剩下的自然语言诉求才进入模型窗口。这样做的好处是模型永远看不到整包脏数据它只处理被裁剪好的核心片段。4.2 语义层模型只在受限窗口内作业语义层就是真正调用大模型的节点但它的输入不是用户原始全文而是解析层输出的受控中间表示。我在这一层强制指定输出schema并且用结构约束让模型只能输出JSON对象任何多余解释、Markdown包裹、对话式语气都会在下一层被拒绝。Prompt仍然存在但它的角色降级为面向单一任务的作业指导书不再承担全局规则。4.3 策略层校验、纠偏、路由、回退模型输出出来后立即进入策略层。第一步是schema校验字段缺失、类型错误、枚举越界直接判定失败。第二步是语义校验用规则或小模型检查字段值是否符合业务约束比如加急标记只能是true/false地址必须包含省市区三级结构。第三步是路由通过校验的结果进入正常出口失败的结果根据失败类型进入不同处理分支——格式错误就原样重试一次语义错误就带着校验错误信息让模型重新生成连续失败则降级为规则兜底或人工队列。4.4 控制层状态、度量、回放、熔断控制层是Harness区别于普通代码编排的本质所在。它给每个任务分配状态和上下文ID记录从进入到出口的每一跳事件。每一跳都打点模型调用耗时、tokens消耗、校验结果、重试次数。控制层还负责超时熔断和全局频率限制。更重要的是它把所有交互记录成结构化的事件流喂给离线回放系统。任何一次线上异常都能在回放环境里复现成为下一轮调整的输入。这套分层设计回答了我在第二代框架时期最大的困惑当模型行为不符合预期时系统应该有一个异常被拦截、被诊断、被纠正的内建机制而不是依赖开发者写一堆散落的if-else去猜。从对话到运行单元的转变也很关键。第一代、第二代本质上都在为一次问答设计进来一段文本返回一段文本。Harness则为一个持续运行的任务设计它关心这个任务今天处理了多少量、失败率有没有超过1%、某类输入是否在最近一次模型更新后表现退化。对话是一次性的任务是可追踪、可改进、可决定继续还是下线的。5. 从Prompt到Harness的一次完整迁移日志解析Agent实战光讲概念容易飘拿我们落地过的一个日志解析Agent来拆解。场景是这样某运维平台需要从几十种历史遗留服务的日志中提取时间段、错误级别、模块名、影响范围、建议动作五个字段原先由一个同学维护一份超长Prompt准确率长期在85%左右。85%意味着每100条日志有15条需要人工修正周均人工量非常大。平台并不要求这个Agent能做复杂的推理要求只有一个高准确率地把结构化字段稳定提取出来新格式日志接入时修改成本要低。第一代方案为什么只有85%因为几十种日志格式差异太大Prompt里塞的few-shot例子再多也覆盖不了长尾。格式稍有变化比如时间戳从ISO变成2024-05-01 13:22:33.12308:00模型就可能把时区信息塞进错误级别字段。纯Prompt方案对输入的排列组合爆炸无能为力。迁移到Harness的步骤我按顺序记录一下第一步定出口契约。五个字段的类型、取值范围、缺失策略全部写成JSON Schema在策略层强制生效。没有这一步后面全是虚的。第二步拆解析层。先用正则识别日志的公共骨架时间戳、级别、服务名、消息体。有一类老服务日志没有标准级别关键词需要模型判断严重程度这部分单独标记为一个严重度推断子任务。这一步让大部分输入根本不进模型。第三步写知识兜底。针对常见的时间格式、服务名缩写、错误码建立字典映射。校验失败时策略层先走字典兜底兜底不了再让模型重试。顺序有讲究宁可让模型减少承担也不让它用猜测覆盖已知事实。第四步搭状态机。每个日志解析任务经历入口归一化 → 规则预提取 → 模型抽取(按需) → schema校验 → 语义校验 → 出口格式化。任何节点失败都会带着失败原因回到上一跳但重试次数有上限超限直接进人工队列。代码骨架大致长这样示意class LogParseHarness: def __init__(self, validator, retry_policy): self.validator validator self.retry_policy retry_policy def run(self, raw_log: str) - ParseResult: skeleton preprocess(raw_log) # 解析层正则提取骨架 fields rule_extract(skeleton) # 规则预提取 if not fields.need_model_inference(): return self.finish(fields, skeleton) with self.trace(model_inference): candidate self.infer_with_schema(skeleton) # 语义层模型按schema输出 for attempt in range(self.retry_policy.max_attempts): errors self.validator.validate(candidate) # 策略层schema语义校验 if not errors: break if errors.is_fatal(): return self.fallback(candidate, errors) candidate self.infer_with_feedback(errors) # 带着错误信息重试 return self.finalize(candidate, skeleton)第五步搭离线回放与回归集。我们把历史上三个月的人工修正结果整理成Golden Set每条日志带标准答案。任何一次Prompt或规则变更必须先跑全量回放准确率低于99%不允许上线。这一步直接把改一版Prompt心里没底的问题消灭了。改完上线跑了两个月实际效果对比如下指标原Prompt方案Harness方案字段级准确率85%99.3%人工修正比例15%0.7%新日志格式接入时间2~3人天1小时左右失败任务可定位性靠日志猜事件流直接定位节点Prompt平均长度约1800词约200词/子任务一个很有意思的细节迁移后模型本身没换Prompt能力也没发生质变准确率提升主要来自模型只处理它擅长的部分其余部分由确定性规则兜底。过去模型什么都得干现在它只干一件事——在几个候选值里选最可能的那个选完还有校验和回退盯着它。6. 落地Harness期间最容易踩的三类坑说点实际的迁移过程中我自己和身边团队踩过的坑至少有三个很典型。6.1 把Prompt模板塞进代码就以为做好了Harness这是最常见的误解。有些同学把策略层的校验函数写出来把模板放进一个配置文件就觉得已经从Prompt范式升级到Harness范式了。但Harness的关键不是代码里有校验而是模型输出被校验结果驱动地纠偏。如果校验失败后你只是记一条日志然后返回失败那这还是第一代方案只是穿了件代码外套。校验必须和路由、重试、回退形成闭环让每次失败都成为系统自我修正的输入。6.2 状态机过度设计把简单任务拆成一棵圣诞树我刚做日志解析Agent时一度想模仿某种通用Agent框架把链路拆成十几个更细的节点甚至为每个节点配了独立的记忆策略。结果调试成本比第一代方案还高。后来复盘发现Harness分层的核心动机是把不确定性关在笼子里不是追求流程图的漂亮。如果一个环节用规则就能做好就绝不引入模型如果一个重试就能解决就绝不设计三种失败模式。简单的确定性结构永远优先于复杂的弹性结构。6.3 跳过离线回放直接在线调整还有一次为了赶一个上线窗口我没等回归集跑完就改了语义校验规则结果新规则对某类历史日志的误杀率极高线上人工队列直接爆掉。那次之后我定了条铁律所有变更必须先进回放系统golden set全绿才能走发布流程。回放系统不需要很复杂核心是事件流存档加对比脚本但它给每一次Prompt或规则调整提供了可追溯的基准线这是Harness范式最值得的投入之一。个人体会是大模型工程化推进到这个阶段从Prompt到Harness并不是说提示词不重要了它依然在语义理解环节发挥作用。改变的其实是责任边界模型不再需要对整个任务的成败负责它只需要对给定受控输入、生成符合类型约束的输出这件事负责其他的交给确定性的管道。这个思路听起来朴素但真正做到位你会发现那种改一行Prompt就提心吊胆的日子基本到头了。