对于标题中这三者的概念，今天又有了更深刻的理解；
prompt engineering：
提示词工程，最简单的我们向大模型发出的每一句都属于prompt。prompt的主要作用就是提需求，告诉模型要做什么；
context engineer：
上下文工程。这个其实就是在搭建agent过程中，如何组装上下文，然后注入给大模型，context engineering决定了告诉给大模型哪些信息。
大模型的上下文窗口是有限制的，一种最简单的策略就是直接将所有的上下文记录一次性发送给大模型，然后获得一次响应。但是随着任务的越来越复杂，这么做不仅容易引入很多冗余信息，也非常的浪费token，占用大模型上下窗口。
所以在实际agent开发过程中，往往不会采用上面提到的那种"最简单策略"，而是每次对话的时候，都会使用各种策略或者算法，重新拼装上下文，比如某次的上下文可能是这样拼装出来的：
系统提示词+前N轮对话+RAG检索到的信息+之前会话中压缩得到的关键信息+长期记忆信息+Agent状态信息。
harness engineering：
上面两种工程其实还是针对某个小点来说的，到了harness engineering就是一个系统层面的工作了。一个agnet需要设计各种安全机制、包括agent的编排（比如langgraph中节点图的编排），执行逻辑等等，这些都属于harness engineering。
随着agent需要处理的上下文越来越长，尤其针对长流程的工作。简单的提示词已经不能够约束模型，保证agent合规操作了，所以需要采用一些传统的、强制手段，比如代码层面的硬性约束（而不是继续让agnet自由发挥调用工具），来保证agent的合规运行。
补充一点：
现在更新的概念是叫loop engineering。但就我个人理解来说，他和harness engineering之间并没有严格区分开来，loop engineering也不是harness engineering的超集，但更像是和harness engineer同一层级。
loop engineering更加强调模型自主性，执行完一遍之后会继续进行下一轮的执行。