Agent=LLM+软件工程

Prompt Engineering

最初你使用LLM时，比如豆包，只需要在输入框输入一句话，模型给你一段回答，这个阶段，软件工程的主要工作围绕于Prompt。

比如为Prompt提供更精准的知识库，改写Prompt让模型更好地理解意图。

Context Engineering

后来，我们对LLM的需求不只是回答问题，而是希望它可以执行一些动作，此时的重心从如何提问，转变为，如何组织上下文。

上下文工程，包括了提示词+输入+工具+工具结果+历史对话+检索的知识片段+记忆。

上下文工程的主要工作，在于如何高效、动态的的组织/组装这些信息，比如何时拉取RAG（动态加载、条件注入），何时调用工具，如何处理工具结果，进行下一轮loop。

Harness Engineering

当一个Agent开始承接大部分执行工作之后，如何让这个Agent更平稳、可靠的运行，它就重新变成了一个软件工程的问题，类比于软件工程的稳定性工作。

Agent稳定工作，其反馈主要来自于运行的环境，Agent在执行过程中，有可能遇到权限问题、网络问题、数据安全问题、数据不完整问题，如何发现、测试、解决、修复，这些都是驾驭工程需要做的事情。

考虑到Agent的自迭代和幻觉特点，我们没有办法要求模型必须如何做，我们能做的就是约束，包括能做什么，不能做什么，具体如何做，模型基于环境的反馈自迭代、自进化。

比如我们要定义好，什么叫任务完成了，什么叫任务失败了，如果任务失败了，它应该去哪里找到错误日志，应该如何基于错误日志进行崩溃恢复。

听起来是不是很像我们多年前做的分布式系统所遇到的问题？

我们在分布式系统时代，也会遇到各种各样的数据一致性、数据延迟、数据不完整、数据冲突、网络延迟、网络故障等问题，分布式的世界同样变幻莫测，我们需要为分布式世界设计各种高可用的机制，比如崩溃恢复算法、分布式调度算法、rebalance机制等。

区别于分布式的世界，Agent的世界多了一个幻觉，就是说它的不可靠性不仅仅来源于数据和网络的抖动，更来源于输入确定性但是输出的不确定性，但无非是在分布式世界中多个一个不确定性状态进行管控。

手段无外乎围绕于上下文窗口压缩、记忆的分类、工具治理展开。

如何做Harness呢？

把你曾经做软件工程的那套思维平移过来，你会非常得心应手。

因为，Agent=LLM+软件工程。

尽管很多人说：Agent=LLM+Harness。

那Harness是什么呢？

如果Harness的目的是让Agent更稳定的运行，那么可以帮助Agent稳定运行的软件工程工作，都属于Harness。

关于Harness的定义，很多人会加很多定语，但这些定语都属于软件工程，不管未来还有什么名词，均是软件工程的世界。