更好的理解Context Engineering

上下文的核心是提供模型不知道的信息。

上下文窗口基本上就是我们输入到大模型中的token，它可以是当前的Prompt，也可以是在与用户交互过程中的内容，也可以是用户上传的文件。

模型的知识有两个来源：

1、权重记忆，即预训练记忆，这是大语言模型对一部分互联网内容训练时学到的知识，这是模型中已经存在的记忆。

2、上下文记忆，这是你提供给模型的记忆，相比权重记忆更容易修改和更新。

在模型推理时，你需要以某种方式更新上下文记忆，比如将私人数据输入到上下文中。

Agent既能作为长上下文的使用者，也能充当长上下文的提供者。

具备高度自主性的Agent，一般来说是由agent loop驱动的运行模式。

在每一个循环迭代中，它借助LLM动态决策，自动调用适当的工具，存取恰当的记忆，向着任务目标不断前进，最终完成原始任务。

然而，这种agent loop的运行模式，直接拿到企业生产环境中却很难长时间稳定运行。

根据工程师Dex Horthy在他的大作《12-Factor Agents》中的描述[1]，这种所谓的「tool calling loop」在连续运行10~20轮次之后一般就会进入非常混乱的状态，导致LLM再也无法从中恢复。

Dex Horthy质疑道，即使你通过努力调试让你的Agent在90%的情况下都运行正确，这还是远远达不到“足以交付给客户使用”的标准。想象一下，应用程序在10%的情况下会崩溃掉，没有人能够接受这个。

Agent无法长时间稳定运行的原因，大部分都能归结到系统送给LLM的上下文 (Context) 不够准确。

至于Agent执行会失败的具体技术原因，更进一步拆解的话，可以归结为两个方面：

• 第一，模型本身不够好或者参数不够，即使有了正确的context还是生成了错误结果。
• 第二，模型没有被传递恰当的上下文。 第二个原因，又可以细分成两类：
• 上下文不充分，缺失必要的信息 (missing context) 。
• 上下文的格式不够好 (formatted poorly) 。类比人类，如果说话没有条例，颠三倒四，即使所有信息都提到了，仍然可能无法传达核心信息。

Context Engineering这一概念的提出，对于Agent开发的交付质量提升到了专业工程学的高度，它要求你的系统要尽最大可能确保LLM上下文准确无误。

资深的AI从业者Nate Jones，最近在他的YouTube视频中指出，他把Context Engineering大体分成两部分。

第一部分 (the smaller part)，称为deterministic context。

这部分指的是我们直接发送给LLM的上下文，包括指令、规则、上传的文档等等，总之它们是可以确定性地进行控制的 (deterministically control）。

第二部分 (the larger part) ，称为probabilistic context。

这部分指的是，当LLM需要访问web以及外部工具的时候，会不可避免地将大量不确定的信息引入到LLM的上下文窗口。

Deep Research就是属于这一类的技术。在这种情况下，我们能直接控制的上下文内容，只占整个上下文窗口的很小一部分（相反，来自web搜索和工具返回的内容，占据了上下文窗口的大部分）。

因此，针对probabilistic context这一部分的上下文，你就很难像针对deterministic context那样，对prompt进行精细地微控制 (micro control) 。

Prompt Engineering可以认为是Context Engineering的一个子集。

Prompt Engineering解决一次性的prompt设计问题，一般来说由工程师手工编辑prompt，并提前写入程序代码或配置中；而Context Engineering解决的是Agent系统在长时间运行过程中的context组装问题。

Prompt不再是由工程师提前写好（工程师可以设计动态的prompt模板），而是会由系统来根据程序的执行情况动态组装prompt。程序在组装prompt时会考虑多种信息来源，包括web搜索结果、工具调用结果、LLM的决策输出等等。

Context Engineering的概念就告诉我们，下一步我们不应该一味地追求模型提供更长的上下文窗口，而是应该追求更聪明的上下文管理机制。系统发送给LLM的上下文最好恰到好处，不能太多也不能太少。