Harness Engineering

前言

　　为什么同样的模型，别人做出来的Agent，可以连续跑很久且成功率很高？到自己手里，总是差强人意？

　　很多人在思考是不是模型不够强？提示词不够好？RAG问题？

　　当然这些都有影响；

　　真正决定系统能不能稳定跑起来，往往不是模型本身，而是模型外面运行的系统（Harness）；

Harness是怎么一步步演进来的？

　　过去2年，AI工程经历了3次明显的重心转移：

　　　　promot engineering、　　context engineering、　　Harness engineering

　　这3个词，分别对应了AI系统发展的3个阶段性问题：

　　　　模型有没有听懂你在说什么？　　模型能不能拿到足够且正确的信息？　　模型在真实的执行里，能不能持续作对？

promot engineering

　　最早大模型刚火起来的时候，同一个模型，换一种问法，结果可能会差很多...

　　这个阶段，大家都相信一件事情：模型不是不会，而是你没有把问题说清楚。

　　于是大家开始疯狂研究promot。

　　为什么这些东西有效呢？

　　　　大模型本质上是一个对上下文非常敏感的概率生成系统；

　　　　你给它什么身份，它很容易沿着这个身份去回答；

　　　　　　给它什么示例，很容易按照这个范式去补全；

　　　　　　强调什么约束，更容易把约束当重点；

　　promot engineering的本质：

　　　　不是命令模型；

　　　　而是塑造一个局部的概率空间；

　　　　这个阶段最重要的不是系统设计，而是语言设计；

Context engineering

　　promot engineering很快遇到了瓶颈，因为很多任务 不是你说清楚就行，而是你得真的知道；

　　　　比如：让模型分析一下公司的内部文档、回答产品的最新配置、按照非常长的规范生成代码、多个工具之间完成复杂的任务...

　　promot engineering

　　　　擅长：澄清任务、约束输出、激发模型已有能力；

　　　　不擅长：凭空补齐缺失知识、管理大量动态信息、处理长链路变化；

　　当只是做聊天机器人的时候，promot作用很大，因为任务短、链路短、状态少，很多问题确实靠把话说明白就可以解决；

　　但后来Agent火了，模型不只是要回答问题，而是要进到真实环境里做事情：

　　　　多轮对话、调用浏览器、写代码...还要在多个步骤之间传递中间结果；

　　　　系统面对的已经不是一次回答对不对，而是整条链路能不能跑通；　

　　context engineering的核心：

　　　　模型未必知道，所以系统在调用时必须把正确的信息送进去；

　　　　context不只是几段背景资料，而是所有影响模型当前决策的信息总和；

　　promot只是context的一部分；

　　agent skills本质上也是context的高级实践因为它解决了一个特别现实的问题：

　　　　如果你把十几个不同的工具、工具的说明、所有的参数定义全部一上来就塞个模型，理论上模型会知道的更多，但是实践往往会更糟糕，为什么呢？

　　　　因为context的窗口是非常稀缺的资源，信息一多注意力就会涣散，所以skill采用的是一个非常典型的思路叫渐进式披露：

　　　　　　不是一开始就把能力全部给模型看，而是只给他看最少量的原信息，等他真正的要触发某些能力的时候，再把那部分的SOP详细的参考信息、脚本动态的加载进来；

　　　　那这个思路呢其实非常重要，因为它告诉我们：

　　　　　　context的优化不只是给的更多，而是按需给、分层给、在正确的时机给；

　　但是上下文工程其实也不只是终点，因为后来大家又发现了一个更麻烦的问题：就算信息给对了，模型也不一定能稳定的执行的正确，它可能计划做的很好，但是执行跑偏了，调用了工具但理解错了，返回结果在一个很长的链路里已经慢慢偏航了，但是系统却没有发现；

　　这个时候我们发现，promot和context 其实主要的解决都在输入侧的问题：提示词优化意图的表达，上下文优化的是信息的供给；

　　但是复杂的任务里还有一个更难的问题：当模型开始连续行动的时候，谁来监督它、约束它、纠偏它呢？