上下文工程已死，上下文工程的上下文来了，什么破玩意...

关注公众号，回复666，获取资料

前几天上海交大发布了一篇论文：《上下文工程2.0：上下文工程的上下文》《Context Engineering 2.0: The Context of Context Engineering》

这篇论文系统性地梳理了上下文工程的演进路径，在给出基本定义后，概括描述了1.0到4.0到底是什么：

该论文整体读下来是比较晦涩的，看得出来他是真的很想清晰定义到底什么是大模型需要的输入信息。

为了做好这个定义（工作）他甚至去梳理了GPT-3.0之前的信息，最终给出了1.0是原始计算时代、2.0是智能代理时代、3.0是人类水平时代、4.0是超人类时代。

怎么说呢，我个人是不太建议大家去阅读这篇论文的，因为他可能不太能解决实际问题，整个文章的核心内容大概就一句话还被说得比较晦涩：

上下文工程的核心使命，就是将人类高熵的意图转换为机器可理解的低熵信息

这句话大家读起来是比较难受的，我给大家翻译翻译，大模型从设计上是一套压缩+扩散模型，首先他用于训练的数据难以表征真实的世界，而后因为输入是残缺的，输出必定会出问题。

其实这也不能完全说他是模型的问题，因为真人也这样：

我们在实际交流的时候，只要背景信息不同步，就必然引起误解（有时候同步也可能误解）。

所以结论是：大模型“天生残疾”，只不过论文也有说明，问题早晚会解决。

而之前强化学习之父Rich Sutton在“苦涩的教训”中的观点不但赞同了能解决，还提出了具体策略：算力碾压一切，简单通用的方法终将胜出。他还列举了AlphaGo的案例。

只是现阶段模型迭代也确实遇到了事实上的问题，且不论优质数据见底或者难以获取，这里最大的问题是现实世界远比棋盘或文本序列复杂得多，而算力必须作用于正确架构上才真正可能得到突破。

当前的LLM，其本质是基于海量文本的“词序列条件概率模型”。它学习的是“在特定上下文中，下一个词最可能是什么”，这是一种强大的统计拟合能力，但远非真正的理解与思考。

站在这个角度，上述的定义也许没什么意义，我们实际工作中依旧需要一个提示词一个提示词的去调试才行。

所以，该论文并不是为了解决我们实际的工程应用问题，但他的出现却把我搞得很烦躁！

AI与数据交互

真正做过复杂AI项目的同学都会理解，在AI应用层最难的其实是：数据如何与AI做交互。

比如我看过几个生产级复杂AI项目，代码量就1万行左右，但所依赖知识库却大的惊人，这里伴有强烈的非对称性，其结果是复杂AI项目，80%的时间都在处理数据问题！

因此，我们会对于复杂AI项目中AI如何与数据交互的范式（最佳实践）是特别关注的，但我个人是比较反感各种球莫名堂的名词如：短期记忆、长期记忆、语义记忆、情景记忆...

甚至，我之前对上下文工程这个词都很反感，在我眼里全部都是RAG（但大家现在都这么叫，我也就接受了...）。因为跟模型的交互就是很简单，只有一套输入输出（API调用），其他都没了：

就我这三年完整的AI项目参与经验，从1.0的百模大战大家都在卷训练；到2.0的套壳时代，大家都在搞简单的RAG；到现在的3.0时代，大家开始根据数据构建CoT了，其中的分割线就是模型能否识别CoT。

提示词工程阶段（1.0+2.0），那时候比较尴尬的是模型理解能力不行 + 上下文过短，正确的输出拿不到正确的输出，所以在AI数据交互上大家都做得保守且简单；

随着模型推理能力的进步，现在模型能很好的阅读CoT，在这个基础上复杂的AI项目才有诞生的空间，只不过这里就真正开始出现分叉了，这里的核心不同是：CoT包括其需要的数据到底是强控制的还是由AI自己生成的？

更进一步的说明是：提示词里面用的人为的CoT还是AI的CoT？

两种CoT

首先，什么是人为的CoT，什么又是AI的CoT？这张图也许能做简单说明：

但要真正描述清楚，可能得从AI项目目标说起，以我之前做群聊分身为例，我的目的是在管理课题上构建一个能像我一样思考、说话的人，他能为我完成管理话题的咨询工作。

这里所谓的像我一样思考就有两个点：

第一，KnowHow。我到底是如何思考的，这其实是一套内置于我大脑中的算法，我得把他翻译出来，其具象化的产物是Workflow或是SOP；

第二，数据。SOP不会孤立执行，他其中所需要的是我大脑中管理相关知识，这个被我之前写成了40篇的管理课程；

综上，这套CoT其实是一套算法+数据的组合，其也是我们所谓AI与数据的交互范式

这套交互范式对我们的要求是：能拿到数据，能拿到对的数据，能拿到够的数据（关系链、逻辑链），再满足基本要求的前提下才是成本与效率的考虑，比如不要拿到多余的数据...

所谓人为的CoT，就是我们自己去构建这个SOP与数据结构、所谓AI的CoT，就是你费那劲干嘛？SOP和数据AI帮你做了算了...

这里说下去可能又有点虚了，我们以大家最熟悉的RAG为例，简单描述下演进逻辑：

简单说明

在人为CoT方法中，问题求解的步骤和逻辑完全由人预先设计。

把思维流程（KnowHow）翻译成显式的 SOP 或 Workflow，并严格控制模型按照这些步骤执行。

比如，面对一个复杂任务，我们可能预先定义：“首先做 A，然后根据结果做 B，接着查询数据库 C，最后总结答案”。

模型在这种模式下更像是在执行人类规划好的脚本，每一步需要什么数据、如何处理都被规定好。

AI CoT 方法则将这种控制权交还给模型。

我们只给模型一个总体目标或提示，让它自行决定如何分解问题、采取哪些步骤。模型可能在内部生成一系列链式思考（类似于人在脑海中推理的过程），决定先做什么后做什么。

简单来说，人为 CoT 是我们替模型想好每一步怎么走，AI CoT 则是让模型自己去探索路径。

对应地，在数据交互上两者也有明显不同。

人为 CoT 下所需的知识是开发者显式提供的。也就是说，我们保证模型“看到”所需要的低熵信息。

典型例子是经典的 RAG 流程：我们从知识库中检索出相关内容，整理后塞进提示词里，再让模型基于这些内容作答。整个过程中检索什么、提供什么都是人为决定的。

AI CoT 则尝试让模型自己去“拿”数据。模型可以在推理过程中意识到需要某些信息，然后自主调用工具（例如搜索引擎、数据库接口等），获取新信息再继续推理。

换句话说，在 AI CoT 模式下，模型不仅思考下一步做什么，还会自行决定需要什么额外信息并尝试获取，使数据与AI的交互更自主。

两者间最大的不同就是可观测性（可控性）。

AI CoT简单实现

讲完原理，再看看在实际项目中这两种思维链是如何工作的。人为CoT大家应该比较清晰，我们这里主要介绍AI CoT，这里以大家熟悉的 RAG 场景为例来说明演进逻辑：。

这里的关键是让模型输出思考过程，还给模型提供接口让它自己去检索知识。

实际运行时，模型会先读到问题并产生一个“Thought：我现在需要做什么”，然后可能输出“Action：搜索关于X的资料”。

系统收到这个动作，就执行一次知识检索把结果反馈给模型作为新的输入。

模型接着基于新信息继续下一个 Thought -> Action，例如“找到了Y，还需要查询Z”，如此循环，直到模型输出“Action:：给出最终答案”。

在这个过程中，具体要拆分多少步、每步查什么，完全是AI自己决定的。我们只提供工具和基础提示。

例如著名的 ReAct 框架、AutoGPT 这类自治代理，其背后就是这种 AI CoT 思想：让模型自己生成思维链并与外部环境交互，只不过有点费Token罢了。

以下是一些伪代码，大家简单感受下：

人为CoT

# 人为 CoT 流程（由开发者硬编码步骤）
question = 用户输入的问题

# 步骤1：人工解析问题（如果需要，可拆分子问题）
sub_questions = parse_question_manually(question)

# 步骤2：针对每个子问题检索知识库（人为决定检索策略）
context = []
for sub_q in sub_questions:
    info = knowledge_base.search(sub_q)
    context.append(info)

# 步骤3：根据预设的提示模板和检索到的内容构建最终提示
prompt = build_prompt(question, context, strategy="我们设计的SOP")

# 步骤4：调用大模型生成答案
answer = LLM.generate(prompt)

AI CoT

# AI CoT 流程（模型自主决策步骤，下面为简化的逻辑示意）
question = 用户输入的问题
context = []
while True:
# 让模型根据当前问题和已知信息决定下一步 (Thought & Action)
    action = LLM.think_and_act(question, context)
if action.type == "search":
# 模型决定检索更多信息
        result = knowledge_base.search(action.query)
        context.append(result)  # 将新信息加入上下文
elif action.type == "finish":
# 模型认为已经可以得出答案
        answer = action.content
break

# 最终得到答案
print(answer)

至于这两个模型应该如何决策，答案可能是不需要决策，都得用：

先用人为 CoT获取初步结果，再让AI 自行微调或补充答案

例如最常见的Few-Shot CoT，在提示中提供示例引导模型推理，就是一种人为引导下的AI CoT。

只不过当前行业表达出来的趋势是：随着模型能力提升和工具生态完善，我们会逐步从人为 CoT 过渡到AI CoT；只不过实际上的情况还是以人为 CoT为主。

结语

最后总结一下，论文在讲上下文工程 2.0，我在讲人为 CoT vs AI CoT，本质都是一件事：怎么把一个残缺视角的模型，接到一个极其复杂的真实世界上。

进一步，在当下这个阶段，构建可靠的复杂AI应用，其本质是一个庞大的系统工程，而非单纯的模型调优。

这个系统工程的难度，至少面临三重关卡：

1. 知识的组织：如何将模糊的认知或海量的知识，整理成机器可理解、可调用的结构化形态。
2. 数据的精准交互：如何设计一套架构，确保AI在每一次交互中都能“拿到、拿对、拿全、不拿多”相关数据，并构建起通过生产数据反馈优化知识库的“数据飞轮”。
3. 意图的精确识别：在多轮对话中，如何准确理解用户的真实意图和上下文，这本身就是一个极其复杂的问题。

复杂 AI 项目是一个高度纠缠的工程问题，KnowHow、数据建模、技术架构、模型特性全部缠在一起。

我们常见的上下文工程，其实就是为了解决这一复杂系统工程的范式探索，只不过各个公司现在都捂着呢，大家是不会轻易拿出来的，每次只会丢出一些只言片语或者过时概念，所以想要工程突破，还得各位多多努力！

点击上方卡片关注叶小钗公众号，查看下方二维码，添加我个人微信：