夜雨聆风AI技术工程实践 · AI技术演进
从Prompt到HarnessAI工程化体系的四代演进
梳理从提示词工程、上下文工程、智能体工程到驾驭层工程的技术脉络说明每一代如何解决上一代的局限性
2023年初，一个会写Prompt的人可以在几秒内让大模型输出令人惊艳的结果。到了2025年，同样的Prompt技巧已经不够用了——生产环境的AI系统需要管理上下文、调度工具、协调多个智能体、还要在出错时自动恢复。这不是模型变弱了，而是应用场景从"演示"走向了"生产"，工程化的要求彻底变了。
很多人把注意力放在模型能力的提升上——参数量从百亿到万亿，上下文窗口从4K到1M。但有一条暗线容易被忽视：围绕大模型的工程化体系本身也在经历代际更替。每一次更替，都是因为上一代体系碰到了结构性的天花板，不得不引入新的抽象层来突破。
这条暗线可以划分为四代：提示词工程（Prompt Engineering）、上下文工程(Prompt Engineering)、智能体工程(Agent Engineering)、驾驭层工程(Harness Engineering)。每一代都不是凭空出现的，而是对前一代瓶颈的工程回应。梳理这条演进脉络，不仅能理解当下AI技术栈为什么长这样，也能预判下一阶段的演进方向。
第一代：提示词工程——"把话说明白"
提示词工程是AI工程化最原始的形态。它的核心假设很简单：大模型已经具备了足够能力，只要人把需求描述清楚，模型就能给出好结果。
这个阶段的技术工具箱包括角色设定、思维链（Chain-of-Thought）、少样本示例、结构化输出指令等。开发者花大量时间打磨Prompt的措辞，寻找最佳的表达方式。一个好的Prompt被当作"秘方"对待，团队内部甚至会建立Prompt库来积累经验。
这个范式在2023年效果显著。但很快，三个结构性问题暴露出来。
问题一：Prompt的脆弱性
同一个Prompt换一个模型版本、换一个对话上下文，效果就可能大幅波动。开发者发现自己陷入了"打地鼠"模式——修了A场景的Prompt，B场景又开始出问题。根源在于自然语言本身就是模糊的，模型对Prompt的"理解"存在固有的概率波动。
问题二：知识注入的低效
当任务需要模型掌握特定领域知识时，Prompt的长度就成了硬约束。早期模型的上下文窗口只有4K~8K tokens，塞不进完整的产品文档或代码库。开发者只能把知识压缩成摘要塞进Prompt，信息损失不可避免。
问题三：缺乏状态管理
Prompt是一次性的——每次调用都是独立事件，模型不记得上一次对话发生了什么。对于需要多轮交互的任务，开发者不得不把之前的对话历史全部拼进Prompt，既浪费tokens又容易超出窗口限制。
这三个问题的共同指向是：Prompt工程解决的是"单次交互的质量"，但生产环境需要的是"持续可靠的系统"。单靠优化措辞，无法跨越这道鸿沟。
第二代：上下文工程——"把环境管起来"
上下文工程是对Prompt工程瓶颈的直接回应。它的核心转变是：不再只关注"对模型说什么"，而是系统性地管理"模型在每次调用时能看到什么"。
这个阶段引入了一批关键的技术抽象。RAG（检索增强生成）让模型可以在推理时动态检索外部知识，不再受限于Prompt的静态容量。向量数据库成为基础设施的标配，文档被切块、向量化、按需检索。会话状态管理通过摘要压缩和滑动窗口机制，让长对话可以在有限上下文内持续进行。系统提示词和用户提示词的分离，让行为约束和任务指令可以独立维护。
上下文工程的效果是立竿见影的。RAG让知识注入不再受窗口限制，会话管理让多轮对话成为可能，系统提示词分离让行为一致性大幅提升。2024年大部分企业级AI应用，其技术底座都属于这一代。
但上下文工程也有自己的天花板。
天花板一：检索质量
RAG的效果高度依赖检索的准确率。当知识库规模增大、查询意图模糊时，召回率和精确率的平衡变成一个持续调优的工程难题。检索后的排序、去重、截断流程本身也会引入信息损失。
天花板二：注意力稀释
虽然上下文窗口已扩展到几十万甚至上百万tokens，但模型对长上下文中中间位置信息的遵循率会下降——"lost in the middle"现象。窗口大了不代表模型能用好，反而可能因信息过载导致关键指令被淹没。
天花板三：静态流程
上下文工程的典型流程是"检索→拼接→生成"，一个固定管道。但很多实际任务需要条件分支：如果检索结果不够，应该主动追问用户；如果生成的内容有误，应该自动修正。静态管道无法表达这种动态决策逻辑。
上下文工程把"环境管理"做到了不错的程度，但它本质上还是一个"增强版的单次调用"——模型仍然是被动地接收上下文然后生成回答，没有主动性和迭代能力。
第三代：智能体工程——"让模型自己决策"
智能体工程的核心理念是：把"决策权"从开发者的硬编码流程中移交一部分给模型自身。模型不再只是一个"接收输入、生成输出"的函数，而是一个能够感知环境、规划行动、调用工具、观察结果、调整策略的自主实体。
这一代引入的技术抽象包括：工具调用（Function Calling）让模型可以主动发起API请求；ReAct框架将"思考-行动-观察"组织成循环；规划器负责将复杂任务分解为子任务序列；记忆系统（短期/长期/工作记忆）让智能体可以跨步骤积累和复用信息；技能将可复用的能力封装为模块化单元。
智能体工程解决了一个根本问题：复杂任务的动态性。上下文工程的静态管道无法处理"执行过程中发现新情况需要调整计划"的场景，而智能体通过循环迭代机制天然支持这种动态适应。一个典型的例子是代码调试智能体——它先分析报错信息，然后定位代码，生成修复方案，运行测试，如果测试失败就分析原因再修一轮，直到问题解决。这种多步骤、带反馈的工作流程，在前两代体系下是不可能实现的。
但智能体工程引入了新的复杂性，也暴露了新的天花板。
天花板一：可靠性
智能体每多一步决策，就多一层出错的可能。一个五步的Agent循环，如果每步准确率90%，整体准确率只有59%。在原型阶段看着惊艳的Agent演示，放到生产环境往往频繁出错。让智能体"能做"不难，让它"稳定做对"极难。
天花板二：成本与延迟失控
智能体的循环特性意味着一次任务可能调用模型十几次甚至几十次。每次调用都消耗tokens和算力，延迟也成倍增加。一个简单的数据分析任务，如果Agent循环了20轮，用户可能要等好几分钟才能拿到结果。在生产环境中，这种成本和延迟往往不可接受。
天花板三：安全与可控性
当智能体拥有了工具调用权限后，它的行为空间急剧扩大。一个配置不当的智能体可能删除重要文件、发送错误邮件、或者执行超出预期范围的操作。如何确保智能体的行为始终在安全边界内，成为一个必须解决的工程问题。
这些问题的共同指向是：智能体工程让AI"能做"了，但缺乏一套系统性的工程框架来确保它"做对"、"做稳"、"做得安全可控"。这就催生了第四代。
第四代：驾驭层工程——"让智能体可生产"
驾驭层工程（Harness Engineering）是目前AI工程化体系的最新一代。它的核心命题不是"让AI更聪明"，而是"让智能体系统可生产、可运维、可治理"。
"Harness"这个词的本义是"驾驭"——不是限制马的力量，而是让力量可控地转化为有用功。在AI工程语境下，驾驭层是包裹在智能体外围的一层工程基础设施，负责解决智能体工程遗留的可靠性、成本、安全和可控性四大问题。
安全沙箱
为智能体的每次工具调用提供隔离的执行环境，限制文件系统访问范围、网络权限和资源配额，确保即使智能体决策出错，影响范围也可控。类似于浏览器对JavaScript的沙箱机制。
编排逻辑
将智能体的"自由循环"替换为"受控编排"。开发者可以定义执行流程的检查点，在关键决策节点插入验证逻辑、人工审批或自动回退机制。把智能体从"全自主"调整为"自主+受控"的混合模式。
状态管理与容错恢复
引入检查点（Checkpoint）机制，定期持久化智能体的执行状态。当某个步骤失败时，系统可以从最近的检查点恢复，而不是从头重来。解决了智能体长任务中"一步失败全盘重来"的痛点。
可观测性体系
为智能体的每次决策、每次工具调用、每次状态变更建立完整的追踪链路。开发者可以回放任意一次执行过程，定位问题发生在哪一步、为什么发生。把传统软件工程的可观测性理念适配到智能体场景。
成本与质量治理
通过模型路由（简单任务用小模型、复杂任务用大模型）、调用频率限制、预算熔断等机制，把运行成本控制在可预测范围内。同时引入输出质量评估机制，在结果不达标时自动触发重试或降级。
驾驭层工程的价值不在于让AI"多做了什么"，而在于让智能体系统从"能演示"变成"能上线"。一个配备了完整驾驭层的智能体系统，其运行特性更接近传统的分布式服务——可监控、可回滚、可灰度发布、可故障恢复。这才是AI真正进入生产环境的前提。
四代演进的核心逻辑：抽象层的递进
回顾这四代演进，可以发现一个清晰的规律：每一代都在原有体系之上增加一层新的抽象，以解决上一代无法绕过的结构性瓶颈。
提示词工程关注"指令质量"，但无法管理环境
上下文工程增加了"环境管理"抽象，但流程是静态的
智能体工程增加了"动态决策"抽象，但缺乏可靠性保障
驾驭层工程增加了"工程治理"抽象，让智能体系统具备生产级品质
这个规律也预示了未来的方向。当驾驭层工程成熟后，下一代的瓶颈很可能出现在"多智能体协作治理"——几十个甚至上百个智能体如何在共享目标下高效协同、如何防止级联故障、如何实现全局最优而非局部最优。这些问题的答案，将构成第五代工程化体系的核心。
对于AI开发者而言，理解这条演进脉络的实际价值在于定位自己的工作坐标。你当前面对的问题，属于哪一代的范畴？你试图解决的瓶颈，是否已经被下一代体系提供了答案？很多团队在生产环境中遇到的困难，本质上是试图用第一代或第二代的工具，去解决第三代甚至第四代的问题。意识到这种"代际错位"，是找到正确工程路径的第一步。
从Prompt到Harness，表面上是技术栈的扩展，本质上是工程思维从"优化单次交互"到"构建可靠系统"的跃迁。
这个跃迁还没有完成，但方向已经清晰。那些能够率先完成思维转换的团队，将在AI从"能用"到"好用"的最后一公里中占据先机。
大数据与微服务 · 技术前沿 · 深度观察 · 价值思考
