黄昏落在驯马场的围栏上，把木头的纹理染成深褐色。
一匹枣红色的马站在场地中央，尾巴甩动，像某种不耐烦的抗议。它的鬃毛被风吹起，又落下，在暮色中起伏如潮。驯马师站在角落，手里攥着缰绳，却没有抛出去。
他在等。
不是等马累，而是等一个时刻，等那匹马自己低下头颅，等它的耳朵从警惕转为倾听，等它愿意相信这个人的手不是威胁，而是引导。这可能需要几分钟，也可能需要几个小时。但驯马师知道，真正的驯服从来不是征服，而是某种契约的建立。
我常常想起那个黄昏的场景。在AI来到我生命中的第一个夜晚，我也曾面对过一匹类似脾气的野马。
那是我第一次向GPT-3提问。我打了一行字：「生命的意义是什么？」
光标闪烁了十几秒。屏幕开始流淌出答案，起初是关于宇宙的渺小，然后是存在的偶然，意义的自我赋予。我在屏幕前坐了很久，不是因为答案有多精妙，而是因为在那一刻，我意识到自己正在与一种全新的思维方式相遇。这不是搜索引擎，不是数据库，这不是任何我曾经用过的东西。这是一匹野马。你问它问题，它给你答案，而你永远不知道它会说出什么。
后来的日子，我开始频繁地使用AI。用它写文章，用它分析代码，用它翻译文字，用它做那些本该由我完成的工作。我发现自己像那个驯马师一样，总是需要不断地「调试」。我给它越来越精确的指令，越来越详细的例子，越来越明确的格式要求。我想让它「听话」，但它总是不那么听话。有时候它忘记了角色设定，有时候它输出的格式乱七八糟，有时候它干脆编造了一些根本不存在的参考文献。
后来有了GPT-4，有了Claude，有了更多的模型。我以为更强的马会更听话。但事实并非如此。强壮的模型依然会跑偏，依然会在某些时刻让你失望，依然会给你一些看似正确但实际错误的答案。我开始意识到，问题不在于马的强壮程度，而在于骑手的方法。
那段时间，我尝试了很多技巧。「你要扮演一个资深的科技记者」，这是角色定义。「请按照以下格式输出」，这是格式约束。「参考这个例子」，这是示例引导。技巧越学越多，提示词越写越长。我甚至开始编写一套「提示词工程手册」，记录那些有效的指令和那些无效的尝试。
但渐渐地，我感到一种隐约的瓶颈。
我发现，无论我的提示词写得多么精妙，系统的可靠性依然高度依赖于模型本身的能力。当模型能力不足时，再精妙的提示词也难以弥补。我还发现，模型无法处理需要跨步骤保持状态的长期任务。每次对话，它都像是「从零开始」，不记得五分钟前我们讨论了什么。我更发现，模型无法调用外部工具，它只知道自己被训练时学到的知识，而那些知识是有截止日期的，有边界的。
有一天，我尝试让模型帮我分析一段代码的性能问题。我写了很长的提示词，描述了代码的功能，要求它找出可能的性能瓶颈。模型给出了几个建议，看起来头头是道。但当我实际运行那些建议时，发现其中一条会导致死循环。
我盯着那段代码，感到一阵沮丧。我明明说得很清楚了，为什么它还是会给出错误的建议？我开始怀疑，是不是我的提示词还不够精确？是不是我应该用更专业的术语？是不是我应该给出更多的上下文？
后来我才明白，那不是提示词的问题。那是范式的局限。
Prompt Engineering的核心，是通过精心设计的指令表达使模型理解并执行特定任务。这个范式假设了一个前提：只要你给模型正确的指令和足够的信息，它就能把事情做好。但这个前提本身是有裂缝的。模型不是机器，它不会严格按照你的指令执行。模型是有「脾气」的，是有「遗忘」的，是会在某些时刻走神的。
我需要的不只是更精确的指令。我需要的是一种更稳固的架构，能够容纳模型的不确定性，能够在模型的「疏忽」和「固执」之间建立缓冲。
就像那个驯马师，他的技巧再纯熟，也无法用手势和口哨驯服一匹在风暴中奔跑的马。他需要围栏，需要水井，需要一间可以遮风挡雨的厩房。他需要的不只是自己的技巧，而是整个系统的支持。
这，就是Context Engineering诞生的前夜。
Context Engineering解决的不再是「如何让模型听懂指令」的问题，而是「如何让模型获得精准信息」的问题。它的核心是设计、构建并管理AI智能体得以做出决策的完整信息环境。
我想起自己开发一个编程助手的经历。用户希望助手能记住他的偏好，比如「用TypeScript而不是JavaScript」，比如「代码注释要中文」，比如「缩进用两个空格」。这些偏好信息不能只放在提示词里，因为每次对话都会重新构建上下文，旧的记忆可能丢失。
我开始为模型构建一个「记忆系统」。我把用户的偏好存储在一个外部数据库里。每次调用模型时，我把这些偏好作为上下文信息传递给模型。这样，模型就「记得」了用户的习惯，就像一个有经验的助理记得老板的喜好一样。
这个系统还连接了代码搜索引擎。当用户询问某个API的用法时，系统会先检索相关的文档和示例，然后把检索结果拼接到模型输入中。这样，模型就不只是依赖自己训练时学到的知识了，它能获取最新的、来自真实互联网的信息。
我开始意识到，Context Engineering的本质，不是让模型更聪明，而是让模型获得更好的信息环境。就像那个驯马师，他不只是用手势指挥马匹，他还在场地周围设置了围栏，为马匹提供了水源和草料，让马匹在合适的环境中工作。
Context Engineering的技术包括RAG，检索增强生成，从外部知识库中检索相关信息，拼接至模型输入。我还开发了记忆管理技术，实现长期记忆的存储和压缩，以及工具描述与调用，让模型能够理解和使用外部工具。
我想起那段开发编程助手的时光。我需要让模型分析一段代码的性能问题。在Prompt Engineering的范式下，我会写一长串指令，让模型「分析这段代码的时间复杂度」「找出可能的性能瓶颈」「给出优化建议」。但效果总是不理想，因为模型有时候会「漏看」某些关键信息，有时候会给出过于笼统的建议，有时候根本抓不住问题的核心。
后来我改用了Context Engineering的方法。我先让模型检索相关的性能优化知识库，然后让它列出代码中的函数调用链，再分析每个函数的时间复杂度，最后生成优化建议。每个步骤都有明确的信息输入和输出，模型不需要「记住」上一步说了什么，因为它可以直接读取上一步的输出。
这个过程就像一条流水线，每个环节都有明确的输入和输出，上一个环节的产出直接传递给下一个环节。模型不再需要「背诵」整个任务，它只需要处理当前的信息片段。
Context Engineering让AI系统能够处理更复杂的、需要多步骤协作的任务。但它依然有局限性。上下文窗口会过载，当信息过多时，模型会「失焦」，被无关的信息干扰。状态管理不完善，当任务失败时，系统可能不知道该从哪里恢复。工具调用不稳定，模型可能无法准确规划工具调用的顺序和频率。
这些局限性指向一个更深层的问题：当任务变得足够长、足够复杂时，我们需要的不是更好的指令，也不是更好的信息环境，而是更好的系统设计。
2026年的某一天，我访问了一家北欧金融科技公司的数据中心。这家公司，据说它的AI客服系统已经能处理超过三分之二的客户咨询，而不需要人工介入。我站在服务器机房外面，透过玻璃窗往里看。机房里没有想象中那么多闪烁的灯光，大多数服务器安静地运行着，只有墙上的几块屏幕在显示实时的数据流。
那些屏幕上的数据流不是混乱的。每一个数据包，每一条消息，每一个状态变更，都被记录在系统日志里。当一个AI代理出现异常时，系统会自动检测到这个问题，然后触发一个预设的恢复流程。如果异常无法自动处理，系统会生成一个告警，通知值班人员介入。整个过程不需要人工干预，不需要有人盯着屏幕等待问题发生。
我意识到，这就是Harness Engineering的意义。
Harness Engineering解决的不再是「如何让模型听懂指令」或「如何让模型获得精准信息」的问题，而是「如何让模型稳定执行任务」的问题。它的核心是通过系统设计而非提示词调优来解决模型的不确定性，确保AI系统在机制里稳定执行任务。
这与前两个阶段有本质的不同。Prompt Engineering关注的是「输入」，如何写更好的提示词。Context Engineering关注的是「信息环境」，如何给模型更好的上下文。而Harness Engineering关注的是「系统」，如何让整个系统可靠地运行。
我想起自己早期开发AI应用的经历。那时候，我以为最大的挑战是「如何写出好的提示词」。我花了大量时间研究指令的写法、示例的设计、格式的约束。但后来我发现，即使提示词写得再好，系统依然不可靠。模型会「遗忘」角色设定，会输出错误的JSON格式，会在某些边缘情况下给出荒谬的答案。
我开始意识到，问题不在于提示词，而在于模型的本质。模型不是机器，不是严格按照你的指令执行。模型是有概率性的，是会「发挥失常」的，是会在某些时刻「走神」的。Prompt Engineering试图通过更精确的指令来避免这些问题，但这种做法有天花板。
Harness Engineering选择了另一条路。它承认模型的不确定性，然后通过系统设计来对冲这种不确定性。与其相信模型不会出错，不如让它在输出后自我校验，或者用另一个模型来交叉验证。与其让模型自己规划任务执行流程，不如设计明确的执行编排和任务调度机制。与其假设模型能处理所有异常情况，不如实现权限隔离、风险熔断和操作审计。
这种思路让我想起那个驯马师的故事。最早的驯马师靠声音和鞭子指挥马匹。后来，有些驯马师学会了构建环境，他们用围栏限制马的行动范围，用水槽和草料引导马的注意力，用规律的马厩生活建立马的「条件反射」。而现在，最好的驯马师不只是依赖这些技巧。他们设计一整套系统：围栏的结构，鞍具的材质，缰绳的弹性，蹄铁的形状。每个部件都有其功能，每个设计都经过考量。
这不是单纯的技巧，而是工程。
Harness Engineering也是这样。它不试图让AI「更听话」。它构建一个框架，让AI的不确定性变得可管理。这不是控制，而是共处。不是征服，而是设计。
三个阶段的关系，不是简单的替代，而是包含。Prompt Engineering ⊂ Context Engineering ⊂ Harness Engineering。
这不是说Prompt Engineering过时了，而是说，Harness Engineering的实践者，依然需要掌握Prompt Engineering的技巧，依然需要设计好的上下文环境。只不过，这些只是整体系统的一部分，而非全部。
这种演进让我意识到一个更深层的思维转变。
从「依赖模型能力」到「通过系统设计弥补模型不足」，这不只是技术策略的调整，而是认知框架的更新。最初的我们，以为AI是一把锤子，拿起来就能用。后来我们发现，AI更像一块璞玉，需要打磨，需要雕琢，需要放在特定的光线下才能看到它的价值。再后来，我们意识到，AI更像一匹野马。它有力气，有速度，有自己的想法。你不能只是骑上去指望它跑。你需要了解它的脾性，建立与它的默契，为它创造合适的环境，甚至需要一套鞍具和缰绳来引导它的力量。
这不是技术问题，这是哲学问题。AI工程的三个阶段，反映的是我们与AI关系的三次转变：从把它当作工具，到把它当作伙伴，到把它当作一个复杂系统中需要管理的组件。每一次转变，都让我们更接近AI的本质，也更接近我们自身的局限。
我想用一个比喻来结束这篇文章。
深海的水压，可以压碎最坚硬的钢铁。但深海潜航器不需要「打败」水压。它不需要让水变得温顺，不需要让水学会「听话」。它只需要设计一个耐压舱，一个能够在极端环境中保护内部生命的壳体。这不是水的失败，而是工程的胜利。
AI工程做的，是同样的事。我们不试图让模型变得更「乖」。我们构建耐压舱，构建验证机制，构建执行编排，构建安全边界。我们在模型的不确定性中，找到让它可靠运行的方法。
Harness。这个词原本的意思是「马具」，是缰绳，是套在牲口身上的皮具。它的词根，与「艺术」和「技艺」有关。但在AI工程的语境里，它有了新的含义。它不是束缚，而是连接。不是压迫，而是承载。不是征服，而是与野性共处的方式。
黄昏的驯马场已经暗了下来。驯马师收起了他的笔记，走向那匹枣红色的马。马还在原地，耳朵竖起，眼睛里有警觉，也有好奇。驯马师伸出手，不是抓向缰绳，而是摊开手掌，让马自己靠近。
马蹄声由远及近，又停住。
驯马师没有动。马看了他一会儿，然后低下头，开始嗅闻他掌心的温度。
这个画面没有终点。它是一个正在进行的过程，是人与野马之间永恒的试探、试探、试探，直到有一天，骑手跨上马背，不再需要鞭子，不再需要呵斥，只需要缰绳的轻轻一勒，就能让马明白他的心意。
那或许是AI工程的最终图景：不是人类控制AI，也不是AI替代人类，而是两个不同的存在，在彼此的边界中，找到共处的方式。
技术终究是为人服务的。而最好的服务，不是让人成为技术的附庸，而是让技术成为人的延伸，让人的能力在技术的加持下，抵达更远的地方。Harness Engineering或许就是这种精神的体现：约束一匹野马，不是为了限制它，而是为了让骑手能够安全地抵达远方。
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～ 谢谢你读到这里。下次见。