过去两年我在技术社区里看到 AI 工程方向的讨论十个里面至少七个还在聊 Prompt。写提示词的人拿到一个新需求先不做系统层面的架构判断而是立刻开始堆措辞、调 few-shot 样例甚至为了一个转折词反复对比跑分。我不否认提示词有它的价值但这个方向确实已经被卷成了一个低边际收益的领域。2026 年再看 AI 工程的落地现场真正拉开差距的地方已经变成了构建在模型外面的那层 Harness——也就是把模型调用、工具使用、数据检索、人工反馈、评测回放串成一条可靠流水线的执行骨架。这篇内容就用我实际把某个内部知识问答系统从重度 Prompt 迁移到 Harness 架构的过程聊聊为什么 Prompt 的权重正在快速下降以及 Harness 为什么值得你把主要精力挪过去。1. 别再把注意力耗在 Prompt 上模型的进化正在抹平你的技巧1.1 你为 Prompt 投入的每一分钟可能都已经被下一版模型自动覆盖了我先讲一个真实到有点尴尬的场景。某次内部项目评审开发团队里有三位工程师就“同一个模型在温度参数 0.1 和 0.3 之间哪个更稳定”这件事争论了整整两周。他们做了一个庞大的对比矩阵不同任务类型、不同措辞模板、不同样例数量加起来跑了几千条测试。最后的结论是整体成功率差异不到 1%。这两周的人力如果用在搭建一条工具调用链路上产品可能已经能接入实时数据了。这就是 Prompt 内卷的典型特征——大家拼的不是系统的可达能力而是同一个模型极限边缘的那一点点浮动空间。以前模型能力弱的时候你调措辞确实能换来肉眼可见的提升少一个歧义句输出格式就稳一点多几个样例任务理解就准一点。但现在的主流模型在指令遵循、格式约束、意图理解上的进步已经把这些“手工调校”的收益吃掉了大半。你花三天写出来的复杂提示词模板很可能还没有模型自己默认行为表现好。更关键的是Prompt 是一种极难复用的资产。它绑定在特定模型版本上模型一升级你可能要重新调一遍业务场景一变模板又得重写。你在这上面积累的所谓“工程经验”本质上是在一个不断被模型能力覆盖的沙地上盖房子。1.2 模型能力提升如何压低提示词的边际收益我习惯用一个很朴素的曲线来理解这件事模型能力越强Prompt 对最终结果的影响越小。早期模型像一台老式收音机你得精确调到某个频率才能听清内容提示词就是那个旋钮。现在的模型更像一个现代接收器自动搜台、自动降噪你把旋钮放在大致范围内它都能给你清晰的输出。具体到日常开发这种变化非常明显。以前要让模型稳定输出 JSON你需要在提示词里写满格式说明、禁止 Markdown、强调不要输出多余内容甚至还要放上一两个正反例。现在的主流模型只要你给出明确的输出格式定义它基本能稳定遵守。以前要让模型学会调用某个工具你得在提示词里手写工具名称、参数说明、调用时机现在工具选择更多变成了模型原生能力你只需要把工具清单和 schema 注册进去。这不是说 Prompt 完全没用了而是它的边际收益在快速递减。你今天还能通过优化提示词拿到 2% 的提升但因为模型版本升级或者输入扰动同样的改动可能下个月就失效了。相比之下Harness 层面的优化——比如增加一个结果校验器、改进工具调用重试策略、优化上下文回填逻辑——带来的往往是几个百分点到十几个百分点的稳定性提升而且是可维护、可测试、可回滚的。1.3 什么时候你还需要认真挖 Prompt我得把话说全面避免读者走向另一个极端。Prompt 在两类场景下依然重要第一你被迫使用小参数量模型、本地部署模型或者成本极度敏感的离线场景时。模型能力受限提示词就成了少数几个你可以控制的杠杆之一。这时候把风格约束、知识范围、输出格式写清楚依然有效。第二强创作型任务比如文案风格迁移、角色扮演、特定叙事结构生成。这类任务的主观评价标准强模型的默认行为不一定符合你的美学要求提示词仍然是主要调节手段。但即便在这些场景里我也建议把问题拆开看哪些内容是“模型能力问题”哪些是“系统控制问题”。如果是模型能力问题提示词能救如果是系统控制问题——比如需要实时查数据、需要做条件分支、需要控制输出必须通过业务校验——那再好的提示词也救不了你得靠外部的执行框架。我给团队定的一个判断标准如果一次提示词迭代只能带来 0.5% 以内的提升而系统抖动一次带来的损失是 5%那你的精力显然放错了位置。你真正该做的是把那 0.5% 的收益让渡给模型能力演进把精力投到能产生系统级杠杆的地方。2. 先搞清楚 Harness 是什么模型外面那层执行骨架2.1 用最不玄乎的方式理解 Harness我第一次听到 Harness 这个词是在工程体系里讨论测试框架的时候。Test Harness 指的是驱动被测代码运行、收集结果、校验行为的一套外围系统。到了 AI 工程里Harness 的含义类似它是模型之外、业务之内的一整套控制层。用开车的比喻来说模型是发动机Prompt 是司机对车辆风格的偏好设定而 Harness 是底盘、变速箱、刹车、仪表盘和导航系统的总和。发动机决定动力上限但真正决定这辆车能不能安全、稳定、准时到达目的地的是底盘和控制系统。所以在实际工程里Harness 不是一个特定软件而是一个职责集合。它包含请求入口、上下文组装、工具注册与调度、规划-执行循环、结果校验、重试与回滚、缓存与记忆管理、成本与配额控制、可观测性与离线评测。这些职责以前分散在应用代码和 Prompt 的各种“奇技淫巧”里但随着 Agent 类应用越来越多它们逐渐凝聚成了一个值得被当作独立系统层来设计和维护的东西。为什么需要把这一层“显性化”因为它直接决定了产品体验的稳定性。同样的模型有人接入后表现像抽风上下文越聊越乱、工具调用时好时坏、同一问题换个措辞结果就跑偏。而有人接入后表现稳定该调工具时调工具、该拒绝时拒绝、失败时自动重试、出了事故能回溯到具体某一步。差别不在模型而在模型外面这层骨架的工程质量。2.2 为什么 2026 年 Harness 才成为主战场单轮问答时代你用一个 Prompt 带一堆上下文就能解决大部分问题。那时的工程重心确实在提示词本身怎么写得更清楚、更不容易触发幻觉。但从 2025 年到 2026 年AI 应用的核心形态明显从“单次问答”迁移到了“多轮任务执行”。用户不再满足于让模型回答一个问题而是期望模型能连续完成一系列操作查库存、算价格、生成合同、校验字段、发送通知。一个完整任务往往涉及多次模型调用、多个外部工具、多个条件分支。在这种情况下Prompt 能控制的只剩“模型自身怎么想”控制不了“系统该怎么做”。比如模型第一轮选择了一个错误的工具你要不要在调用之前加一道规则检查模型调用工具返回了异常你要不要把这个异常回填给模型让它自行修正多轮对话里前面的上下文已经快把上下文窗口占满了你要不要压缩摘要、丢弃旧消息这些问题没有一个是 Prompt 能回答的全部是执行框架的职责。还有一层现实因素主流模型的函数调用、结构化输出、多模态理解能力在这一两年内越来越成熟。模型侧的“接缝”变小了外部系统侧的接缝就变大了。以前团队不敢做 Agent是因为模型经常听不懂工具调用指令现在模型听得懂了大量精力就转移到工具编排、权限控制、流程编排、评测反馈这些外围工程上。Harness 不是被某个框架发明出来的新概念而是工程实践自然汇聚的产物。2.3 Harness 的核心模块拆解我习惯把 Harness 拆成六个核心模块每个模块对应一类你能明确投入精力的工程任务。第一工具注册与调用层。你给模型提供哪些函数每个函数的名字、参数 schema、鉴权信息、并发上限、超时设置都在这层管理。它决定了模型能触碰外部世界的边界。第二上下文与记忆管理层。包括短期会话上下文、长期用户画像、知识库片段的选择性回填、上下文窗口预算分配。它决定了模型“看得到什么”也就间接决定它“编得出什么”。第三规划与执行循环。这是 Agent 模式的核心引擎模型生成下一步动作系统执行动作并返回结果模型观察结果决定下一步。这里的循环步数上限、去重策略、自我修正机制、终止条件都要由 Harness 掌控。第四输出约束与校验层。不要指望靠 Prompt 里的“不要撒谎”来控制幻觉你需要在输出侧加 schema 校验、业务规则检查、事实性核对。这一层是防止模型乱来的最后闸门。第五异常处理与降级策略。模型超时、工具报错、上下文溢出、内容审核不通过、预算踏空——每一种异常都要有明确的处理方案而不是让用户面对一个停滞的界面。第六可观测与评测层。链路追踪、成本核算、离线样本回放、线上失败标注这些都是 Harness 的一部分。没有评测反馈你前面的所有模块都是盲调。这六个模块单独拎出来都不复杂但把它们做成一个易维护、可复用的系统层就是 2026 年 AI 工程的主战场。3. 一次真实的 Prompt 到 Harness 迁移实录某知识问答系统的重构3.1 迁移前为什么必须做这次手术我接手某个内部知识问答系统时它已经处于典型的 Prompt 内卷晚期。系统的核心逻辑是一条四百多行字符的超长 Prompt里面混着角色设定、知识边界、若干条业务规则、十几个工具调用示例、各种“如果用户问到 X 就怎么回答”的手写分支。上下文里还要塞进大量知识库文本经常一个请求就逼近模型上下文窗口上限。最直接的问题是用户开始要接入实时业务数据比如查订单状态、查审批进度。这些数据根本不在静态知识库里模型靠猜只能给出错误答案。团队尝试过把实时数据查询伪装成“系统提示里的知识”结果是数据更新不及时、答案时常过期。这时候我心里很清楚纯 Prompt 方案已经走到头了必须把控制逻辑从提示词里迁出去。长痛不如短痛在一个试用期需求量不大但场景足够完整的模块上启动迁移。3.2 第一步盘点 Prompt 里的隐性职责动手改架构之前我没有急着重写代码而是先带着团队把那条超长 Prompt 逐段拆开搞清楚每一句话到底承担了什么职责。结果拆出来五类内容第一格式约束比如“必须输出 JSON”“不要输出多余解释”第二静态知识定义比如“你是公司的内部助手业务范围包括……”第三流程控制比如“如果用户问 A就执行 B再根据结果决定 C”第四工具调用样例比如“当你需要查订单时调用查询函数参数是订单号”第五防幻觉提示比如“没有依据时不要编造回答‘不知道’”。拆完以后每一条都有了明确的迁移去向。格式约束迁移到结构化输出 schema 和输出校验器静态知识定义迁移到系统级配置或者检索增强流程控制迁移到 Harness 的工作流状态机工具调用样例迁移到工具注册表里的函数描述防幻觉提示则变成结果校验层的规则引擎。这一步是整个重构里最值得做的事因为它逼着团队把原来堆在模型面前的“模糊控制指令”变成系统层面清晰可执行的模块。如果没有这一步就盲目重写结果往往是新系统只是换了一种方式堆 Prompt问题原封不动保留在 Harness 里反而增加了一层复杂度。3.3 第二步用 Harness 接管控制流迁移后的核心是一个简单的执行循环。我以 Python 伪代码的形式先在团队内部跑通原型核心逻辑大致是这个样子def run_task(user_message, state): # 1. 组装上下文从记忆中取出相关片段加上系统级配置 messages build_messages(user_message, state) # 2. 让模型决定下一步动作 step model.call(messages, toolsregistry.get_all()) # 3. 根据模型的输出判断是直接回复还是需要调用工具 if step.is_final_answer(): return validate_and_reply(step.text) if step.is_tool_call(): # 4. 调用工具并处理异常 result registry.execute(step.tool_name, step.arguments) # 5. 把工具结果作为可观察信息回填给模型进入下一轮循环 state.add_observation(step.tool_name, result) return run_task(user_message, state) # 6. 兜底达到最大步数、连续调用同一工具等场景强制执行终止策略 if state.reached_limit(): return graceful_fallback(state)这个循环本身不复杂但它带来的变化是结构性的。原来那条 4000 字的 Prompt 被拆成了三部分系统配置只保留一两句话的角色与边界定义每次任务描述聚焦在当前用户问题上工具结果通过观察消息动态回填。提示词从核心逻辑变成了轻量配置长度降到了原来的二十分之一。团队很快发现两个好处。第一可调试性大幅提升。工具调用失败、模型选错工具、校验不通过这些都能在日志里一目了然不用再猜是提示词里哪句话出了问题。第二可扩展性增强。新增一个业务工具时只需要在注册表里加一个函数定义不用去改那几十行逻辑混杂的 Prompt。3.4 第三步把评测和反馈装进闭环迁移到 Harness 只是第一步真正让它持续变好的是接入评测反馈闭环。我们建立了一个包含两类样本的评测集一类是历史日志里的真实用户问题另一类是人工构造的边界场景比如“超出业务范围的问题”“需要多步工具调用的复合请求”。每次改动团队都会跑一遍评测集记录三个核心指标任务成功率、单任务平均模型调用次数、单任务平均成本。另一个重要环节是线上反馈回流。当用户对回答进行“没用”操作或者同一个问题连续追问两次系统会把这轮完整链路日志标记出来进入人工复盘池。前三周复盘下来最集中的问题不是模型回答错而是工具选择混乱模型在面对相近的两个查询函数时经常选错。这个问题在纯 Prompt 阶段是完全不可见的因为当时根本没有工具层所有数据都在静态知识里。迁移完三个模块后对比数据是这样的同样的任务类型任务成功率从 68% 提升到了 91%平均单任务的模型调用次数从 4.2 次降到了 2.8 次单次请求成本下降了接近三分之一。Prompt 从“核心资产”变成了系统里一条不起眼的配置项。这个结果不算惊艳但它说明了一个趋势把控制权从模型内部的偏好设置转移到外部执行框架整体稳定性会明显上一个台阶。4. Harness 落地时最容易翻车的三个工程决策4.1 选框架还是自研先租积木但别直接买毛坯房市面上已经有不少现成的 Agent 框架、工作流编排框架它们能帮你省掉最开始的搭建成本。我给团队的建议从来不是“必须自研”或者“必须用某框架”而是分阶段处理。第一步用现成框架把原型跑起来验证你的核心流程是否成立第二步在产品需求逐渐稳定后把最关键的 Harness 控制逻辑收敛到自己的中间层里对外暴露一组不依赖特定框架的业务接口。为什么第二部更重要因为框架的抽象往往只解决了“通用”。一旦你的业务出现特殊需求比如某个工具只能串行调用、某些结果必须经过人工审批、某类上下文需要特殊压缩策略你会在框架的上层抽象里绕很大的弯子。更麻烦的是框架本身也在快速演进今天用的 API 明天可能就废弃你的业务代码被迫跟着框架升级。实操建议是把框架当作底层引擎把 Harness 当作你的业务控制面。框架负责基础的循环调度、消息格式转换你自己负责工具注册规范、评测逻辑、权限策略、异常分支。这样即使你未来换掉底层框架业务层的稳定性也不会被毁掉。我见过不少团队一开始用框架写得很爽半年后框架一升级整个 Agent 链路全断就是因为没有这一层中间隔离。4.2 工具调用的召回与容错模型选错工具怎么办工具一多模型选择工具的准确率就会下降这是个被低估的工程问题。最初我们系统里注册了 30 多个工具模型经常在一些名字相似、职责相近的函数之间犹豫甚至出现同一个任务连续调用两三个无关工具才找到正确选项的情况。解决方法其实很朴素。第一收敛工具数量。很多工具可以合并成通用参数接口没必要每个细分操作都暴露成一个独立函数。第二工具描述要写清楚“什么时候用、什么时候不用”。比如“查询订单状态”和“查询物流轨迹”这两个工具如果你在描述里只写了一句“查询订单相关信息”模型大概率分不清但如果你写清楚“用户问发货后到哪了用这个用户问订单金额和状态用那个”准确率立刻上来。第三Schema 尽量做严格校验参数不合法时优先返回给模型一次修正机会而不是直接失败。容错策略同样重要。我给工具执行设置了三类兜底超时重试两次参数归一化比如把模糊的时间表达转换为标准日期范围还有结果解析失败时的二次修正。校验器发现工具返回结果结构不对时会把错误信息喂回给模型让它自行调整下一步动作。这套容错逻辑在纯 Prompt 时代根本没法实现——因为它需要的是外部代码对真实世界的检查能力。4.3 评估指标与线上体感的落差别被离线指标骗了做 Harness 最怕的一件事是离线评测集上分数很高上线后用户体感却很差。我们遇到过这种困惑。离线评测集是人工精挑细选的几百条问题覆盖了主要业务场景跑分稳定在 90% 以上。上线后却发现真实用户的问题语言更随意、指代更模糊、上下文依赖更强很多在评测里压根没覆盖到。后来我们调整了评估策略离线评测只负责回归线上体验靠真实信号来监控。具体会盯着几个指标——用户重问率、用户对回答点“没用”的占比、连续对话提前退出率以及工具调用失败率。这些指标任何一个出现异常就自动触发失败样本采样。每两周做一次失败样本复盘把新发现的问题类型补充进离线评测集。这个循环跑起来之后整体体验才逐渐稳定下来。别再迷信模型排行榜或者自制评测集的漂亮分数真正的标准是你的用户在真实对话里遇到的问题能否在你设计的 Harness 环路里被捕获、被诊断、被修复。5. 常见问题与排查技巧实录5.1 工具调用死循环怎么给 Agent 装刹车我在多个项目里都遇到过同样的现象模型在同一个工具上反复打转。比如它调用查询函数拿到结果后不是直接给用户答案而是非要再把同样的查询再调一遍或者用同一个参数换一个说法连续调三次。最离谱的一次模型为了确定一个订单号把查询工具连续调用了七次费用肉眼可见地往上跳。排查下来根因往往出在终止条件缺失。Harness 必须有硬性的执行预算单任务最大模型调用次数、单任务最大工具调用次数、单次请求的 Token 消耗上限、连续相同参数调用的去重策略。我这里设置了两道保险一是全局步数阈值超过就直接终止二是同工具同参数在相邻两次循环中出现时直接判为重复调用强制中断并向模型提示“你已经在使用相同参数调用过该工具请基于已有结果回答问题”。这两道保险用上之后类似死循环基本绝迹了。5.2 Prompt 变短之后的“幻觉回潮”有段时间我们把系统提示词压得非常短只留了一句角色定义和一句输出格式说明。结果发现模型反而开始“自由发挥”了。原本那些写在 Prompt 里的业务边界约束没了模型会自作主张回答超范围的问题或者自己脑补一些不存在的数据字段。这个现象说明一个道理Prompt 里如果删掉了一段控制信息你必须确保 Harness 里有对应的等价控制能力否则就等于裸奔。解决方式不是把提示词加回去而是在模型输出之后加一层校验器。校验器检查输出内容是否符合业务规则、字段是否存在、范围是否越界。校验不通过时系统自动触发一次修正循环把错误信息回填给模型让它推翻重答。我踩过这个坑之后每次裁剪 Prompt 都会先回答一个问题这段信息承载的控制职责外部系统能不能兜住兜不住就先加外部控制再删提示词。5.3 上下文被工具结果塞爆预算怎么分配多轮工具调用还有一个副作用每轮工具返回的结果都会塞进上下文历史对话长了以后上下文窗口很快被撑满。以前单轮问答时不存在这个问题因为一次请求看完就结束了但 Agent 的循环结构会把历史消息全部累积下来。我的经验是给上下文做预算分级。系统配置、最近的用户消息、最关键的几轮工具观察结果优先占用上下文预算较早的对话轮次逐渐压缩成摘要已经超过保留窗口的历史片段再通过向量检索按需捞回。我通常会把总预算的百分之四十留给当前任务的无关历史压缩与检索片段剩下的全部给当前任务本身。这套分配策略可以让长对话的稳定性显著提高同时避免每轮调用都临近上下文上限带来的成本飙升。5.4 常见问题速查表问题现象可能根因优先排查点模型反复调用同一工具缺少终止条件是否配置了最大步数、去重策略输出违反业务规则Prompt 裁剪后失去约束校验器是否覆盖新增业务规则工具调用经常超时工具接口响应慢或并发超限工具调用是否设置了超时与限流长对话后回答质量下降上下文窗口被历史消息占满是否有摘要压缩与检索回填策略离线评测好但线上差评测集和真实输入分布不一致是否建立线下失败样本抽样回归闭环模型频繁选择错误工具工具描述含糊、数量过多工具描述是否写清适用与不适用场景多步任务中途崩溃异常处理分支缺失是否有降级回答与重试机制成本突然大幅上涨循环步数过高、工具调用冗余是否记录单任务成本并设置阈值告警我自己在实际项目中踩过这么多次坑之后最深的体会是AI 工程的重心正在从“让模型听懂人话”转移到“让系统替模型兜住一切可能出错的地方”。Prompt 没死但它从核心地位退到了配置层你真正要精雕细琢的是模型外面那整条执行链路。团队里原来最擅长措辞优化的同事现在都在写工具注册规范、设计校验规则、调评测闭环工作成果也从“某句话改得怎么样”变成了“整个任务成功率稳定在多少”。这个转变就是你该提前布局的战场。哪怕你的团队还没有接手 Agent 类项目也建议先拿一个高频小场景练手把 Harness 的六个核心模块搭起来半年后的差距会非常明显。