从人为CoT到AI CoT：大模型交互范式的演进与工程挑战

April 5, 2026

近期，上海交通大学发布了一篇题为《上下文工程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项目，其核心代码量可能仅在一万行左右，但所依赖和整合的知识库却规模惊人。这种强烈的非对称性导致了一个普遍现象：在复杂AI项目中，团队80%以上的开发时间都投入在处理数据相关的问题上！

正因如此，业界对于复杂AI项目中AI与数据交互的标准化范式与最佳实践抱有极高的关注度。不过，我个人对堆砌各种新名词（如短期记忆、长期记忆、语义记忆、情景记忆等）的做法持保留态度。

甚至，我曾对“上下文工程”这个术语本身也感到不适。在我看来，与模型的交互本质极为简洁：仅包含一套输入和输出（即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实质上是 “算法（SOP）+ 数据” 的组合体。它也正是我们所说的 “AI与数据的交互范式”。

这种交互范式对我们的工程能力提出了明确要求：能够获取数据、能够获取正确的数据、能够获取充足的数据（包括完整的关系链与逻辑链）。在满足这些基本要求的前提下，才谈得上对成本与效率的优化，例如避免获取冗余数据。

所谓人为CoT，即指由开发者自行构建这套SOP与数据结构；而AI CoT的思路则是：何必如此费力？让AI来协助甚至自主完成SOP和数据的组织工作。

这样的表述可能仍有些抽象。我们可以以大家最熟悉的RAG（检索增强生成）场景为例，简要描述其演进逻辑：

范式原理的进一步阐释

在人为CoT的方法论中，问题求解的步骤与逻辑完全由人类开发者预先设计和编排。

我们需要将内在的思维流程（KnowHow）翻译成显式的SOP或Workflow，并严格控制模型严格按照这些既定步骤执行。例如，面对一个复杂任务，我们可能预先定义：“第一步执行分析A，第二步根据A的结果执行操作B，第三步查询数据库C，第四步综合给出最终结论”。模型在这种模式下，更像是在执行一个人类预先编写好的精密脚本，每一步需要何种数据、进行何种处理都被明确规定。

AI CoT方法则将这种规划与控制权在很大程度上交还给模型本身。我们仅向模型提供一个总体目标或高层级提示，由它自行决定如何分解问题、采取哪些具体的推理步骤。模型可能在内部自主生成一系列链式思考（类似于人类在脑海中进行推理的过程），自主决定执行的先后顺序。简而言之，人为CoT是我们替模型规划好每一步路径，而AI CoT则是为模型设定目标，让它自己去探索和开辟路径。

相应地，在数据交互层面，两者也存在显著差异。

在人为CoT范式下，模型推理所需的知识片段是由开发者显式、主动提供的。也就是说，我们确保模型在推理时能够“看到”所有必需的低熵（高确定性）信息。一个典型例子是经典的RAG流程：我们先从知识库中检索出与问题相关的文档片段，经过人工整理或简单拼接后，将其置入提示词中，再让模型基于这些给定的内容生成答案。整个过程中，检索什么、提供什么、以何种顺序提供，都主要由人为决定。

AI CoT则尝试让模型自己去主动“索取”数据。模型在推理过程中，可以自行意识到需要某些额外信息来推进思考，然后自主调用外部工具（如搜索引擎、数据库查询接口、函数API等）来获取新信息，再基于新信息继续推理。换言之，在AI CoT模式下，模型不仅思考“下一步该做什么”，还会自行判断“我需要什么额外信息”并主动尝试获取，使得数据与AI的交互过程更具自主性和动态性。

两者之间最根本的区别之一在于工程上的可观测性与可控性。

AI CoT的简单实现逻辑

阐述完基本原理后，我们来看看这两种思维链范式在实际项目中是如何运作的。人为CoT的流程大家可能比较熟悉，这里我们将重点介绍AI CoT的实现思路。我们继续以大家熟知的RAG场景为例，说明其演进逻辑。

实现AI CoT的关键在于：引导模型输出其内部的思考过程，并为模型提供工具接口，让它能够自主发起检索动作。

在实际运行时，模型会首先接收到用户的问题，并可能产生类似“Thought：我需要先理解问题的核心，并确定缺失哪些关键信息”的思考。接着，它可能输出一个“Action：搜索关于[特定概念X]的详细定义或最新资料”。系统在监听到这个动作指令后，便执行一次知识检索操作，并将检索结果作为新的上下文信息反馈给模型。

模型随后会基于新增的信息，继续进行下一轮的“思考-行动”循环，例如“Thought：根据已获取的资料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 CoT进行细节的微调、补充或验证。例如，广泛使用的Few-Shot CoT（少量示例思维链提示），就是在提示词中提供几个人为编写的推理示例，从而引导模型进行类似的链式思考。这本质上就是一种人为引导下的、受限的AI CoT。

行业表现出来的趋势是，随着模型能力的持续提升和外部工具生态的日益完善，我们正在逐步从以人为CoT为主，向更多融入AI CoT的方向演进。但就目前绝大多数生产环境而言，高度可控的人为CoT或混合模式仍然占据主导地位。

结语：复杂AI系统工程的本质

最后进行总结。论文在讨论上下文工程2.0的抽象定义，而本文探讨的人为CoT与AI CoT之辩，本质上指向的是同一个核心工程问题：如何将一个拥有固有认知局限的模型，有效地接入并应对极其复杂的真实世界。

更进一步说，在当下这个发展阶段，构建一个可靠、高效的复杂AI应用，其本质是一个庞大的系统工程，而远非单纯的模型调优或算法创新。

这个系统工程至少需要跨越三重主要关卡：

知识的有效组织： 如何将人类模糊的认知、隐性的经验或海量的非结构化知识，系统地整理、转化为机器可理解、可高效调用的结构化形态。
数据的精准交互： 如何设计一套完整的软件架构，确保AI在每一次与用户的交互中，都能“拿到、拿对、拿全且不拿多”相关的数据，并能够构建起通过生产环境的数据反馈来持续优化知识库的“数据飞轮”。
意图的精确识别与上下文管理： 在多轮、开放域的对话中，如何持续、准确地理解用户的真实意图，并有效维护对话的上下文状态，这本身就是一个极其复杂的独立课题。

复杂的AI项目是一个高度纠缠、多维度耦合的工程问题。领域知识（KnowHow）、数据建模、技术架构选型以及模型自身的特性，所有这些要素都紧密地交织在一起，牵一发而动全身。

我们通常所说的上下文工程，其终极目标就是为了解决这一复杂系统工程而进行的方法论与最佳实践的探索。只不过，真正领先的工程化方案往往是各公司的核心竞争力，大家通常不会轻易公开核心细节，市场上流传的常常是一些泛化的概念或已过时的思路。因此，若想在AI工程应用上取得实质突破，仍需依靠广大开发者与工程师们持续的、扎根于实践的探索与努力。