最近在帮一个朋友看他的AI项目。
他的团队做了大半年，用上了最流行的RAG架构，接了向量数据库，精心设计了chunk策略，还专门训练了Embedding模型。理论上，这套系统应该很强了。
但上线三个月，客户投诉不断。
核心问题只有一个：不稳定。同样的问题，换个问法，答案可能完全不一样。有时候能给出完美答案，有时候就瞎编一气。他们花了很多时间调Prompt，加System Prompt，加 Few-shot示例，能试的都试了。
坦白讲，这套打法他两年前就开始用了。效果嘛，当时觉得还挺新鲜的。
但现在，他跟我说了一句让我印象很深的话：
「感觉怎么调都不对，AI这东西太不可控了。」
我看着他，突然意识到一件事。
他们遇到的问题，可能根本不是Prompt的问题，也不是Context的问题，而是还没想清楚自己在做的是哪一个层级的事。
这三种工程范式之间的关系，一直被讲得很模糊。大家都说自己在做RAG，做Agent，做AI系统，但很少有人把底层逻辑说清楚。
今天我试着把这个事情聊清楚。
Prompt Engineering解决的是「怎么说」的问题。
Context Engineering解决的是「给什么信息」的问题。
Harness Engineering解决的是「怎么让它稳定干成」的问题。
三个东西不是三选一，是包含关系：Prompt ⊂ Context ⊂ Harness。
我先把这个框架抛出来，然后一层层拆开聊。
一
Prompt Engineering，大家最熟悉。
你写一段指令，模型给你一个回复。最典型的场景就是对话。你问它「帮我写一封邮件」，它给你一封邮件。你问它「这段代码有什么bug」，它给你分析。
这个阶段的核心逻辑是：模型是可靠的，问题在于你怎么跟它说话。
所以大家在做的事情就是：设计更好的指令，给它定义角色，给它几个示例，约束它的输出格式。
这套玩法在GPT-3出来的时候被推向了极致。你可能还记得2022年到2023年那段时间，整个社区都在讨论怎么写Prompt。什么Chain-of-Thought，什么Few-shot，什么角色扮演，技巧层出不穷。
我也追过那波热潮。怎么说呢，有用，但有天花板。
天花板在哪？
在于你永远在依赖模型本身的推理能力。它的上限就是你的上限。模型不够强，你的Prompt再精妙也补不回来。你可以让它少犯错，但你没办法让它做它本身做不到的事情。
更关键的问题是：模型没有记忆。
每次对话，它都是「从零开始」的。你问它第一个问题，它回答了。你问第二个问题，它不记得第一个问题你说了什么。
这个在单轮对话里不是问题。但一旦任务变复杂，一旦你需要它跨步骤完成一个事情，一旦你需要它在执行过程中记住中间状态，这个方法就彻底失效了。
我之前用它做过一些自动化的脚本生成。简单的脚本没问题，三五行代码，一气呵成。但一旦涉及到需要查文档、调API、做错误处理的长脚本，它就频繁「失忆」。走到第三步，它忘了第一步的决策依据。走到第五步，它忘了你一开始说的技术栈偏好。
Prompt Engineering解决不了这个问题。
不是Prompt写得不够好，而是这个问题压根不在Prompt的射程范围内。
二
所以Context Engineering来了。
这个名字起的很有意思。它不是简单延续Prompt的思路------继续优化说什么------而是把焦点转向了它能看到什么。
你想想看，模型为什么会在长流程里「失忆」？
因为它的信息窗口是有限的。GPT-4 Turbo的上下文窗口是128K tokens，Claude 3.5能达到200K。听起来很大，但你在里面塞什么，决定了它能做什么。
Context Engineering的核心，就是设计这个信息环境。
怎么设计？
几个关键手段。
RAG，检索增强生成。你让模型能够访问外部知识库。它不是只靠训练数据里的知识来回答问题，而是能实时从你的文档库、数据库里去查资料。客户问了一个和产品相关的技术细节，它能去查最新的产品规格文档，然后给你一个准确的答案，而不是在那瞎编。
记忆管理。你给系统装上一个「记忆」模块。不是模型的内部记忆，而是外部的记忆存储。它会把任务执行过程中的关键状态记下来。下次模型再被调用的时候，这些关键状态会被塞回上下文里，让它「想起来」之前做到了哪一步。
工具调用描述。你把外部工具的能力翻译成模型能理解的格式。搜索、计算、查数据库、调API，这些东西本来是模型做不到的，现在通过工具描述，模型知道「哦，我有一个搜索工具，可以用它来查实时信息」。
状态编排。你精心组织这些信息的排列顺序和呈现方式。chunk怎么切，多个检索结果怎么排序，长期记忆和短期上下文怎么平衡。这些都会直接影响模型的输出质量。
到这里，你已经不是在优化Prompt了，你是在构建一个让模型能够有效工作的信息场。
我做的一个内部工具算是这个阶段的典型例子。一个代码审查Agent，它需要记住用户的技术栈偏好（「TypeScript，不是JavaScript」「注释要中文」），需要阅读团队的代码规范文档，需要调用代码分析工具去扫描提交，需要跟踪审查的进度。这些东西加在一起，才是它能做好这个任务的前提。
但做到这里，问题解决了吗？
还没有。
因为模型的行为仍然是不可预测的。
你可以给它足够好的上下文，可以设计精妙的记忆系统，可以让工具调用描述无比清晰。但模型每次的输出，本质上还是概率性的。它可能这次调用工具A，下次调用工具B。它可能这次校验了输出结果，下次忘了校验。它可能在大多数情况下是对的，但在某些边缘情况下输出一个完全离谱的结果。
你的Context系统再完善，模型的行为还是会有波动。
怎么把这种波动控制在可接受的范围内？
这就把我们带到了第三个阶段，也是我最近花最多时间思考的阶段。
三
Harness Engineering。
Harness这个词，原意是马具，就是套在马身上的那套东西，让马按照你的意图去走。
这个词用在这里，意思非常准确。
它的核心不是让模型更聪明，而是让模型的行为在你的控制范围内。
你不是在优化它的输入，不是在构建更好的信息环境。你是在设计一个系统，用工程化的手段去约束、去验证、去兜底模型的输出。
这才是真正的范式转变。
之前的思维是：模型是核心，你做的所有事情都是围绕模型，让模型发挥最大能力。
Harness Engineering的思维是：模型是不可控的，它会出错，它会随机，它的输出有波动。你必须通过系统设计来管理这种不确定性，而不是试图让模型本身变得可靠。
怎么实现？
几个关键机制。
执行编排。 你不再让模型自己想干什么干什么。你给它设计好任务分解的逻辑，什么时候该调用哪个工具，先做什么后做什么，在系统层面定义清楚。OpenAI的Specialist架构就是这个思路，不是单个模型在那里随机发挥，而是一组专门的子代理各司其职，在编排器的调度下协同工作。
验证闭环。 模型输出的东西，必须经过校验。你设计输出校验规则，用规则引擎去检查结果是否合理。用多模型交叉验证，一个模型生成，另一个模型检查，两边结果对上了才放行。在某些高可靠性要求的场景下，这个验证环节可能是整个系统里最关键的部分。
安全机制。 权限隔离，敏感操作需要二次确认，操作审计日志，高风险行为自动熔断。这些在传统软件工程里习以为常的东西，在AI系统里往往被忽视。但当你的系统开始执行实际操作------发邮件、改配置、下订单------这些东西就必须到位。
可观测性。 你需要能看到系统在干什么。完整的日志记录，指标监控，错误追踪。不是出了问题去猜，而是有数据可以追溯。某个任务为什么失败了，是模型的问题还是工具的问题还是上下文污染的问题，你能快速定位。
生命周期管理。 模型版本迭代了，新的模型能力和老的Prompt可能不兼容了。你的系统必须支持平滑过渡，必须有回滚机制，必须在模型更新的时候不中断业务。
这整套东西加起来，你才真正有了一个工业级的AI系统。
Klarna做过一个案例挺有意思的。他们的智能客服系统上线之后，大家一开始觉得就是接了个大模型API，加了点Prompt。但实际上背后是一整套Harness架构。多个专业Agent分工协作，每个Agent负责不同的任务类型，有完整的验证和升级机制，客户的问题不是扔给一个通用模型去自由发挥，而是在一个严密的系统框架里被处理。
这就是为什么他们的自动化客服能处理那么多问题，而很多团队接了同一个大模型API，做出来的效果却天差地别。
差的那部分，就是Harness。
四
现在我们把这三个阶段放在一起看。
你可能会问：这三个阶段是替代关系吗？我是不是应该直接上Harness，跳过前面两个？
不是。
这三个阶段是包含关系，不是互斥关系。
Prompt是Context的基础。你做Context Engineering，你仍然需要写好Prompt。只不过Prompt不再是唯一的手段了，它只是整个系统里的一个环节。
Context是Harness的基础。你做Harness Engineering，你的编排器、验证器、安全模块，都需要和模型交互，都需要设计好Prompt格式，都需要管理上下文信息。只不过这些不再是终点，只是手段。
你不能跳过前两个阶段直接做第三个。因为Harness的核心不是凭空出现的，它需要基于你对Prompt和Context的充分理解，才能设计出有效的约束机制。
换个角度说，这三个阶段其实代表的是问题域的扩大。
Prompt阶段，你在处理单轮对话，处理一个指令的执行。你的问题是「怎么让它听懂我的话」。
Context阶段，你在处理多轮任务，处理信息环境。你的问题是「怎么让它获得准确的信息」。
Harness阶段，你在处理系统可靠性，处理生产环境部署。你的问题是「怎么让它稳定地、持续地、不出问题地把事情干成」。
问题域在扩大，复杂度在上升，需要的工程能力也在升级。
Prompt阶段，你可能一个人能搞定，加几个示例，调调措辞。
Context阶段，你需要工程化的检索系统，需要记忆存储模块，需要工具集成能力。
Harness阶段，你需要完整的产品工程能力。编排、验证、安全、可观测性、生命周期管理，这些东西加在一起，就是一整套系统设计的功夫。
这不是一个人能搞定的事情了，这是一个团队的工作量。
五
说回开头我那个朋友。
他后来接受了我的建议，开始在他的RAG系统上加Harness层的东西。加了一个验证模块，每次检索结果出来之后，先用规则引擎做一次基础校验，看看返回的知识片段和用户问题是否真的相关。加了一个任务追踪系统，记录每轮对话的任务进度，防止上下文窗口过载的时候丢失关键信息。加了一套日志系统，出问题的时候能快速定位是哪个环节出了问题。
改动不大，但效果是明显的。
客户投诉少了。不是AI变聪明了，是它的行为变得更可预测了。
他后来跟我说了一句话，我觉得特别对。
「之前总觉得AI不行是自己的Prompt写得不够好。现在想明白了，有些问题不是Prompt能解决的，得靠系统。」
这个认知转变，是从Prompt到Harness这条路上最关键的一步。
你什么时候真正理解了这一点，你什么时候就开始从「调参侠」变成「系统工程师」了。
六
最后说几个我观察到的趋势。
Harness会成为AI工程的事实标准。
现在行业里其实已经有这个迹象了。微软的Azure AI平台，谷歌的Vertex AI，Anthropic的Claude Enterprise，这些大厂的东西越来越强调系统层面的可靠性保障，不是没有道理的。当AI开始进入生产环境，进入企业级场景，客户要的不是「AI很聪明」，而是「AI能稳定地完成我交给它的任务」。
工程能力的权重会继续上升。
过去两年，社区的注意力大多在模型能力上。GPT-4出来了，Claude 3出来了，模型能力变强了，大家的应用也跟着变强。但模型能力的提升是有边际效应的，到了一定程度，你在应用层面的差距，更多取决于你的工程能力，而不是你用的模型是哪家公司的。
Prompt写得好，能让你领先三个月。Context管理得好，能让你领先半年。但真正能让你建立护城河的，是Harness层的能力。因为这是最难复制的东西。Prompt可以复制，RAG可以照搬，但一整套系统设计、验证机制、运维体系，不是Copy-Paste能搞定的事情。
会分化出专门做Harness的工程师角色。
这个趋势其实已经在发生了。我了解到的一些AI团队里，已经有人在专职做「Agent架构师」「AI系统工程师」这样的工作，核心职责就是设计AI Agent的执行框架、编排逻辑、验证机制这些东西。不是写Prompt，不是调模型参数，是设计系统。
这是一个新的职业方向，而且是一个很重要的方向。
写这篇文章的过程中，我一直在想一个问题。
AI行业变化太快了。几乎每隔几个月就有新的范式，新的框架，新的buzzword出来。RAG火了一阵，Agent火了一阵，现在又是MCP，又是各种编排框架。追是追不完的。
但如果你能穿透这些表面变化，看到底下那条演进的主线------从Prompt到Context到Harness------你就能在这个快速变化的环境里，找到一个相对稳定的坐标系。
你知道自己在做什么，你也知道下一步应该做什么。
这就是框架的价值。
好了，就聊到这里。
P
王畅 · Polaris