背景
自从2026年以来， AI 行业近乎以N倍的速率进行了疯狂的更新和迭代，从 opencode ，openclaw ，nanobot ，hermes agent以及最近的 openhuman，这些新的agent的出现，大部分都是来解决一个问题，那就是让自己可以躺着干活，不再像以前传统的工作方式一样。虽然说每一次新的agent的出现是一种进步，但是总的来说里面的原理还是一样，
它们都是基于大模型基模以及再在基模的基础上进行工程化的约束。
说到基模，各个公司也是卷的飞起，各种模型也在进行疯狂式的迭代，从 opus minmax deepseek glm 几乎每个月模型都会有个大的版本更新，性能以及准确性也是有很大的提高。
除去基模以外，这些工程化的agent，都深藏着三个基础工程：Prompt Engineering ,Context Engineering, Harness Engineering。
学得慢就不用学了？学得快就一直学？你的明白这三个基础工程，你才能差异化的学习各个agent框架，至于基模，就让大公司去卷吧。
Prompt Engineering
Prompt Engineering 是告诉大模型做什么以及怎么做。
也就是说你得告诉大模型，你要做什么，以及做什么。比如说 直接让大模型写算法，但是随着做的事情越来越复杂，prompt就变成了一个有层次的多维度的工程化的事情，比如说经常prompt会由一下几个部分组成：
- 身份与标识
- Bootstrap 文件，AGENTS.md、SOUL.md、USER.md、TOOLS.md 等
- 长期记忆
- 常驻技能
- 技能目录
- 历史对话
这里的 Bootstrap 文件 就包括了 agent的工作指南，以及行为规范。
之所以会分成这么几大类,是因为有些是固定的，有些是可以扩展的，有些是可以压缩和裁剪的。分为这种几种类型的话，可以分而治之，各司其职，这就是很明显的工程化的思维，而不是一股脑的全部塞进prompt中。
Context Engineering
Context Engineering 是告诉大模型如何做的更好。
随着你和大模型的交互越来越多，历史的对话信息就会越来越长，这就会带来一个问题，那就是大模型的 context 窗口的限制问题，现阶段所有的大模型你一次性输入的上下文信息都是有限制的，如果超出了这个限制，大模型就不能完全理解你的意思，进而给出错误的回答，所以这里就会引出了Context Engineering的概念。
Context Engineering的宗旨就是尽可能让我们和大模型的对话信息压缩在基模的上下文窗口内。所以一般会从 RAG，上下文压缩与裁剪来进行工程化操作：
- RAG
不把所有的知识都写进prompt中，而是存储索引，一般来说就是进行索引存储，之后在真正获取对应的信息的时候，再从外部存储系统中获取对应的信息，组装到prompt中
比如说 这里的 Skills机制（只列出有哪些skill 描述，真正用的时候调用对应的工具读取），从某种角度上来说也算是一种RAG - 上下文压缩与裁剪
这里把历史信息进行进行总结为事实与偏好，从而替代大量冗余的历史信息。
裁剪，主要是对工具返回的结果进行裁剪，有些工具返回结果往往占用大量的token，采用某种策略，最大可能的保留核心语义。
利用Context Engineering可以让用户和大模型的对话不会超过大模型的上下文窗口，从而让大模型稳健的运行.
Harness Engineering
Harness Engineering 是确保模型可控的做。它是在大模型之外构建的一套外部的运行环境与约束机制。通过接口，钩子等手段，约束，引导，检测，评估Agent的行为，使其能够可靠的完成复杂的任务。
假如你已经把 Prompt 和 Context Prompt做的很完美了，但是在运行中你会发现大模型或多或少的会提前结束任务，这些不是通过 Prompt和 Context能够做到的，因为这两个只是告诉大模型去怎么做，大模型做好了与否以及是否满足我们的预期，这些我们都是不可知的。所以这才是Harness Engineering的作用。
比如在软件开发过程中，我们可以通过Harness Engineering来强制要求：
- 分步执行：限制每次只完成一个功能，而不是所有的功能模块都完成
- 强制验证：对每个模块得有对应的单元测试或者集成测试
- 自身修复：如果测试环节出现问题，必须进行修复，直至通过为止
- 最终验收：在一项任务完成后，必须进行完整性检查
当然在实践中，可以采用Hook的机制进行自定义逻辑，从而实现事前预防和事后校验与纠正
基模与三者的关系
随着基础模型的能力的越来越强，这三种工程化的能力要求就越来越低，因为模型的越强自身可控的能力就越来越强，这三种 Prompt Context Harness的能力需要要的就越来越简单，在当下时代，谁能更加深入了解模型的能力边界，谁就能够更好的调整工程化的复杂度，从而更好的掌控Agent。