如果你这几年把不少精力花在让大模型“听懂人话”上那你大概率已经感受到一种微妙的变化最难的早就不再是写出一段漂亮的 Prompt 了。我在几个真实业务项目里反复体会到一个清晰的转向——第一代我们靠 Prompt 调教模型第二代靠 RAG 帮模型找资料、靠 Agent 让模型学会调工具到第三代大家开始给模型套上一个叫 Harness 的“工程骨架”。只有走到这步才敢说自己做的是大模型工程化而不是大模型实验。这篇内容适合正在做 LLM 应用开发的同学、准备搭建 AI 业务系统的技术负责人以及想搞清楚“提示词之后还有什么”的研究者。我会把三代范式的演进逻辑、每一代的关键手段、踩过的坑以及 Harness 的落地方式一起拆开讲。没有太多理论铺垫全都是我在项目里实际验证过的东西你可以直接拿去参考。1. 三代范式到底在解决什么问题1.1 大模型应用化的核心矛盾先聊一个经常被忽略的事实大模型本身是一个概率系统。同样的输入它这次回答和下次回答可能不一样你给了足够多的上下文它可能理解对了也可能一本正经地胡说八道。而业务系统对输出的要求恰恰是确定性的——用户希望每个请求都能得到稳定、合法、可复现的结果出了任何异常都能追溯原因。这两个特性放在一起就是大模型工程化最核心的矛盾模型的“不确定”和系统的“确定性”天然对抗。早期做项目时我们经常遇到一类问题一个人在对话框里测试某个功能感觉效果不错但一上线同样的 Prompt 在上午和下午返回的结果完全不一样前端直接展示出格式错误。问模型为什么它只会道歉而日志里根本没有记录它思考的过程。纯靠 Prompt 根本管不住这种不确定性。于是工程化的演进本质上就是一代一代地把模型的不确定性“圈起来”用一层一层的外部机制去约束它。每一代范式都在扩大这种“约束圈”的范围但同时也带来新的复杂度。理解这个脉络是决定你要不要在项目里引入 Harness 的前提。1.2 三代范式如何一步步把“不确定”框住我把三代范式按“控制点”做了个对比这样最容易看明白范式主要控制点核心手段能力边界第一代 Prompt 工程模型的输入和输出文本提示词设计、少样本示例、思维链只能约束“话语”约束不了“知识来源”和“动作行为”第二代 RAG 与 Agent知识来源和工具调用向量检索、外部知识注入、多步工具调用知识可以约束但流程容易失控第三代 Harness 工程整个工作流生命周期策略注入、状态管理、工具网关、可观测性、评估回归把不确定性收进可控的工程边界内从这个表可以很清楚地看出Prompt 只算是第一层“围栏”RAG 和 Agent 是第二层“围栏”Harness 则试图把整片“责任田”都圈起来。后面的内容会一层层展开这里先记住一句话范式演进的本质是把“依赖模型聪明”变成“依赖系统可控”。2. 第一代Prompt 工程——把模型当“黑盒咨询师”2.1 Prompt 为什么能撑起一个技术方向Prompt 工程在早期是一个很有价值的岗位原因很简单大模型刚进入应用视野时大家对其能力边界一无所知。你给模型一句含糊的要求它就回一段含糊的结果你给它一个结构化的指令它可能就能给你一份结构化的答案。于是大家开始琢磨如何通过“设计指令”来调动模型能力这就像请了一个黑盒咨询师你只能用语言去引导它但看不到它脑子里的推理过程。初期确实有效。比如做客服工单分类我们写一段包含分类枚举和格式要求的 Prompt再加上几个人工标注的示例模型就能把工单归到正确类别里。做摘要、改文案、生成结构化数据Prompt 都扮演过“调教开关”的角色。少样本提示、思维链提示也是在那个阶段被广泛验证的。这些手段的本质是在模型的参数空间里找到一条“最能触发正确行为”的路径。那时候我们还会专门维护一个 Prompt 模板库积累各种场景下的“最佳话术”。团队成员之间讨论最多的问题是“这句话到底要不要加”“示例放两个还是三个”“温度参数设多少”。说实话那个阶段真的像在做语言炼金术成就感很足但隐患也在同步累积。2.2 当年我们踩过的 Prompt 坑第一批坑来自“换模型”。我们在一款中文闭源模型上调好的 Prompt切换到另一款开源模型后效果直接腰斩。原因很简单不同模型的指令遵循能力分布不一样对同样措辞的敏感度也不同。你在这里用“请严格输出 JSON”有效换一个模型它就理解成“输出带 JSON 字段的文本”。于是所有 Prompt 都要重写模板库形同虚设。第二批坑来自格式不稳定。要求模型返回 JSON它偶尔会在结果前面加一段“好的这是你要的 JSON”。为了处理这种情况我们不得不在代码里写一堆字符串清理逻辑甚至专门写一个“垃圾前缀过滤函数”。这其实很荒谬每个开发者都在重新发明同一个轮子因为模型输出是概率性的你永远无法预测它会在哪个边角给你来一下。第三批坑是 token 预算爆炸。为了让模型理解业务背景我们把知识库摘要、历史会话、用户画像全部塞进 Prompt。结果 Prompt 越来越长单次请求费用越来越高响应越来越慢。更难受的是上下文里的内容一旦互相冲突模型就会“挑着信”最终输出一团混乱。Prompt 工程在这个阶段已经触碰到了天花板它只能约束表面文本无法阻止错误知识进入上下文。2.3 Prompt 工程的不可扩展性拐点桶里的水漫出来的时候我们才开始反思Prompt 本质上只是一种“接口协议”不是系统。业务一复杂你会为了几十个场景去维护几十条 Prompt每条 Prompt 里还嵌套着分支规则。改一个业务规则要先在 Prompt 里搜关键词然后小心翼翼调整措辞再跑几轮人工验证。如果其中一条 Prompt 影响了另一个场景你根本不知道除非用户投诉。还有更严重的问题没法自动化测试。Prompt 是自然语言不是代码你不能用传统 CI 对它做断言。有的团队尝试给 Prompt 写“黄金集合”和“评估脚本”让模型输出通过关键词匹配或者规则校验但稍微复杂一点的任务就失效。这导致 Prompt 工程始终停留在手工作坊阶段无法形成可持续的迭代闭环。所以我的看法是Prompt 工程并没有过时它会一直存在就像编程语言里的函数签名永远存在一样。但它只能作为“最后一步的表达层”不能作为整个工程化体系的支点。当业务规模跨过某个临界点就必须引入新的范式来接管“控制系统”的职责。3. 第二代RAG 与 Agent——给模型配上“外脑”和“手脚”3.1 RAG 的工程化本质RAG检索增强生成出现时一度被很多人当成解决幻觉的银弹。它的思路很简单回答问题之前先从外部知识库里把相关信息检索出来和用户问题一起交给模型让模型基于检索到的内容来生成回答。这个动作的本质是把“模型的记忆”从参数里搬到外部存储里让知识来源可控。真正落地时RAG 的三段式技术都藏满了细节。切分阶段很多人想的是“按字数切”但我试下来发现按章节标题和语义边界切效果更稳。检索阶段向量检索召回不准确时要配合关键词召回或者重排模型一起用。注入阶段不是把所有召回结果都塞给模型而是要做一个“压缩器”只保留与问题强相关的片段否则上下文一长模型又会开始迷路。我对 RAG 的一个重要心得是检索质量决定了答案质量Prompt 只是最后一步的收音机。你Prompt写得再好检索出来的内容驴唇不对马嘴也不会生成正确答案。所以我们后来把项目核心精力放在知识库清洗、切分策略、召回评测上而不再是调 Prompt。3.2 Agent 的范式价值与失控隐患RAG 只是让模型“知道更多”Agent 则让模型“能做更多”。通过工具调用、多步推理、记忆管理Agent 可以把一个复杂任务拆成多个子任务然后一步步调用外部工具完成任务。比如要查一个订单的物流状态它需要先查订单号再调物流接口再整合结果回答用户。这个过程是动态决策的模型自行决定下一步调用哪个工具。这个范式的价值在于它把大模型从一个“参谋”变成了“执行者”。但也是从这里开始工程化难度急剧上升。Agent 的决策路径是不可枚举的同一个任务上一轮还在正常调工具下一轮可能就进入死循环有些模型甚至会调用一个权限范围之外的接口如果没有权限控制后果很严重。我见过一个真实的失控现场一个 Agent 为了完成“帮用户改地址”的任务反复调用订单修改接口因为它在每次调用前都认为上一次没有成功。要不是监控告警及时发现它可能真的会把一个订单改几十遍。这个例子说明Agent 时代不能只追求“智能”必须配套护栏、沙箱、人工审批等机制。3.3 第二代范式仍然缺的那块拼图RAG 和 Agent 分别解决了“知识不确定”和“动作不确定”的一部分问题但它们仍然有一个共性缺陷缺少统一的生命周期管理。它们更像是几个强大的组件被拼在一起组件之间没有标准接口没有统一状态管理也没有从开发到上线的完整回归机制。举个例子一个 Agent 应用里可能有多个模型协同工作一个负责意图识别一个负责工具调用一个负责最终回答。如果某个模型升级了你怎么知道它对意图识别的影响如果没有一套自动评估和回归机制你只能上线后碰运气。这不叫工程化这叫测试版上线。这也是为什么第二代范式虽然能力很强但在很多企业里只能做 PoC无法真正运行核心业务。缺的这块拼图就是让系统具备“自我控制、自我观测、自我评估”能力的工程层。这个工程层就是我说的 Harness。4. 第三代Harness——从“魔法”走向“工程系统”4.1 Harness 是什么一个可观测、可约束、可测试的“模型容器”Harness 这个词最初来自测试领域叫 test harness意思是“测试夹具”用来把被测对象固定住然后给它输入、观察输出、校验行为。工程化语境下的 Harness可以理解成给大模型应用套上的“安全带”它不改变模型本身的智能水平但会限制模型的工作范围、定义它的输入输出边界、跟踪它的每一步决策、并在出错时强制回退。如果你觉得抽象可以想象开车发动机是动力来源但不能为了跑得快就不要刹车和仪表盘。Harness 就是刹车、仪表盘、限速器和安全带的总和。它把模型这个“发动机”装进一个受控的驾驶舱里让它只能在业务允许的路径上行驶。和 Prompt、RAG、Agent 相比Harness 关注的不再是某一次“生成”而是整个调用链路的生命周期。从输入进入系统开始到中间的路由决策、工具调用、策略校验、模型生成再到最后的输出校验、日志记录、效果评估全部纳入一个统一的运行时框架里。这个框架会持续观察系统内部状态并对不符合预期的行为进行拦截和纠偏。4.2 Harness 设计的核心部件分解我把一个足够实用的 Harness 拆成六个核心部件部件职责关键点任务路由器判断当前请求属于哪个场景选择对应处理链路路由不一定用模型规则优先上下文管理器统一管理历史消息、知识片段、状态变量防止上下文无限膨胀和相互污染工具网关统一封装外部 API、数据库、内部服务做权限控制、超时和重试策略检查器在关键节点校验输出是否符合业务规则可插入规则、正则、模型校验评估器对模型输出进行质量和安全评分支持规则评分、模型评分、人工回看观测与回归记录全量 trace、指标、异常事件支持自动化回归测试和告警这六个部件不是每个项目都要完整搭建但至少前四个是必须有的。任务路由器解决“这个请求走哪条链路”上下文管理器解决“模型该看哪些信息”工具网关解决“模型能碰哪些资源”策略检查器解决“模型输出的东西能不能放出去”。有了这四层模型的自由度就被压到了可控范围内。4.3 一种可参考的 Harness 实现架构我在实际项目中比较喜欢的做法是用一份声明式配置来描述整套 Harness。下面是一个简化示例场景是工单自动分类与回复harness: name: ticket-assistant model: gateway: internal-llm-gateway name: business-chat-v2 temperature: 0.2 context: max_context_tokens: 4000 history_round: 8 knowledge_bucket: product-manual router: type: rule-plus-llm rules: - if: message contains 退款 then: scenario.refund - if: message contains 订单 then: scenario.order fallback: scenario.general tools: order_api: scope: read timeout_ms: 1200 retries: 2 refund_api: scope: write need_approval: true policies: - before_output: check: response_contains_required_fields - after_tool_call: check: tool_exit_code_must_succeed evaluator: rules: - output_length_lt_500 - no_markdown_in_chat model_scorer: enabled: true threshold: 0.7 trace: storage: local-clickhouse sample_rate: 1.0这份配置对应的执行流程大致是请求进来先进路由器路由器根据规则判断场景上下文管理器组装该看的历史记录和知识片段如果调用工具必须经过工具网关的权限校验模型生成结果后策略检查器先做一轮校验不合格就重试或者降级评估器给最终输出打分整个过程写入 trace 存储用于后续回溯。有人会问这是不是把简单问题复杂化了我的回答是取决于你对错误成本的容忍度。如果只是写个个人助手不搭 Harness 完全没问题但如果是面向真实用户、涉及资产变更、需要审计溯源的业务没有这套机制你晚上根本睡不好觉。5. Harness 工程化落地实战从零搭一个稳定业务案例5.1 业务问题与选型判断去年我们接手了一个模拟项目某跨平台系统的用户工单自动分类与回复。用户每天产生几千条工单内容包括退款、订单问题、产品咨询、投诉抱怨等。传统解法是用规则引擎加人工客服但规则引擎覆盖不了口语化的表达人工客服成本又太高。我们最初打算直接用 Prompt 调用模型但考虑三个现实问题第一输出格式必须严格结构化否则下游流程没法处理第二涉及退款操作时必须有人工审批不能让模型自主决定第三出了错误必须能追溯不然就是事故。于是我们很明确地选择了 Harness 方案而不是单纯堆 Prompt 或 Agent。核心考虑是这个场景有较高的工具调用权限控制需求有严苛的输出格式要求且需要持续迭代和回归保障。只有 Harness 能把模型、工具、策略、评估全部整合到一个闭环里。5.2 实施步骤与关键细节整体实施我分成五个步骤每一步都有容易忽略的细节。第一步定义输入输出与业务策略。我们把工单分类枚举固定为五类退款、订单、产品咨询、投诉、其他。每类对应一个回复模板和一组工具权限。关键是先定义“不允许模型做什么”而不是让它自由发挥。比如退款工单只能生成处理建议草案真正执行退款必须由人工确认。第二步准备评测集。我们从历史工单里拉了两千条人工标注分类结果和理想回复关键点做成评测集。这一步最耗时间但也是后面迭代的地基。没有评测集你改任何配置都无法判断是变好还是变坏。第三步搭建上下文管理器。工单内容往往包含多轮用户消息我们的做法是把历史消息压成最近八轮同时拼接用户的基本信息和工单状态。知识库只放产品手册按章节切块。上下文管理器会限制“该看什么”避免模型被无关历史带偏。第四步接入工具网关和权限控制。订单查询接口给模型的权限设为只读退款接口不仅设为写权限还得带审批标记。工具网关里我们统一做了超时和重试。这一步特别重要模型偶尔会构造一个不存在的订单号工具返回失败后如果不让模型停下来它可能反复调用同一个失败接口浪费资源。第五步跑回归与灰度发布。每次修改 Prompt、调整策略或者替换模型我们都先在评测集上跑一次完整回归对比准确率、超时率、策略违规率。回归通过后再发布到灰度环境让 20% 的流量先走新链路观察一个周期没问题再全量放量。5.3 效果数据与复现建议灰度稳定后我们统计了一组数据工单分类准确率从最初纯 Prompt 方案的 76% 提升到 94%格式合规率从 82% 提升到 99.5%因为输出格式错误引起的工单回退数量基本归零。策略违规拦截率大概是 1.2%也就是每一百次请求里会有一到两次被策略检查器拦住避免了可能产生的事故。这个数据并没有夸张到“完美”但它说明一个关键问题系统的稳定不是靠模型变聪明而是靠 Harness 把每一个不可控输出都拦截在系统边界之内。如果你想复现这套做法我建议不要一开始就做大而全的 Harness先选择一条核心业务链路定义好策略、接好评测集、跑出第一个版本再逐步推广到全部场景。6. 常见问题与避坑清单6.1 三代并存时的选择策略很多朋友会问一个问题“是不是所有场景都要上 Harness”我的答案是否定的。范式选择要看业务风险、调用频率和迭代速度。我一般用这个判断框架场景特征推荐范式原因一次性的文本生成、翻译、摘要Prompt 工程足够错误成本低迭代快依赖私有知识、答案需要溯源RAG知识可控引用明确需要调用外部工具完成多步操作Agent 轻量护栏动作能力强但必须有沙箱和审批面向核心业务、下游强依赖格式、需审计Harness全链路可控、可回归、可观测如果你发现同一个应用的 Prompt 数量已经超过二十条而且改动了一条会影响另外的场景那就是转向 Harness 的信号。不要迷信范式越新越好关键是找清楚当前最大的失控点在哪里。6.2 高频故障与排查速查表以下是我在 Harness 落地过程中遇到的几个高频故障整理成速查表供参考症状可能原因解决方法模型回答突然风格漂移底层模型版本被隐含升级固定模型版本升级前跑评测集工具调用循环不退出缺少调用次数上限在工具网关里设置最大调用次数输出格式偶发不合格模型温度过高或 Prompt 约束弱温度调低在策略检查器加正则强校验知识库内容互相冲突上下文管理器拼接了多个矛盾片段提高重排精度只保留最相关片段系统延迟明显变高Harness 串行校验太多把部分校验改成异步或合并策略节点评测集通过但线上出错评测集与实际分布不一致定期从线上日志补充评测样本还有一个比较隐蔽的坑策略检查器如果写得过于严格会把正常输出也拦掉导致大量错误回退。这时候不能只盯着“准确率”看还要看“重试率”和“拦截率”。我们曾经把一条规则写得太宽结果 20% 的工单都要走人工异常流程返工成本飙升。后来在策略里加了白名单和例外条件才把这个比例降下来。6.3 个人经验总结走到这一步我对大模型工程化最大的体会是模型能力始终在进步但这不会自动降低工程复杂度。每个新模型都可能带来新的行为模式而工程系统的价值恰恰在于把这种“新行为”限制在业务可接受的范围内同时在行为异常时给出清晰的信号。我现在接手一个新的项目第一件事永远不是写 Prompt而是画一张链路图输入从哪里来在哪个节点可能让模型自己做决定这个决定如果错了会造成什么损失谁能观测到错误以及出错后如何回退。这张图画完Harness 的骨架也就出来了。最后再分享一个小技巧做 Harness 不要急着写代码先把你眼下最痛的五个错误场景列出来逐个设计应对策略。如果这些策略都能落进一套统一的运行时你其实已经做出一个非常实用的 Harness 了。工程化的起点从来不是追求新技术而是正视你自己系统里那些没人管得住的“意外”。