上下文的转向:工程化下一代人机协作范式
- 本报告基于Google Deep Research生成
- 上下文工程:下一代人机交互范式
引言:超越提示词
近期,著名人工智能(AI)研究者Andrej Karpathy的一则推文引发了业界的广泛讨论,他提出上下文工程(Context Engineering)是比提示工程(Prompt Engineering)更精确、更具扩展性的术语1。这一提法并非简单的语义偏好,而是标志着一种范式转移的信号。它预示着我们正在从早期与大语言模型(LLM)交互时那种依赖直觉、充满氛围感编码(vibe coding)和精妙措辞(clever phrasings)的阶段,迈向一个更结构化、可扩展的软件架构时代。
提示工程的局限性
在过去几年中,“提示工程”风靡一时,爱好者们精心雕琢着各种复杂的提示词。然而,随着模型能力的飞速进化,许多这类精巧的努力在更强大的模型面前显得如同花拳绣腿,简单的几句话便能达到同样甚至更好的效果2。这种现象揭示了提示工程范式的内在局限性。它过度关注于构造一个静态的、单一的文本字符串,试图以此来引导模型的行为。这种方法在公众认知中,也逐渐被简化为一种“给聊天机器人输入文字的可笑的自命不凡的术语”,这极大地限制了其在构建工业级应用中的概念效用。
论文主旨
本报告旨在论证,上下文工程并非提示工程的简单演进,而是一门独特的、新兴的工程学科。它代表了一个全新的软件架构层,其核心任务是动态地编排信息流,并将其注入大语言模型的“工作内存”中。这门学科是构建可靠、可扩展且真正具有“魔力”的AI应用的关键,它使我们能够超越简单的ChatGPT包装器1,进入一个全新的软件范式。
第一部分:上下文的剖析
本部分将从第一性原理出发,解构“上下文”这一概念,为后续的讨论建立一个清晰的词汇表和概念框架。
1.1 从“咒语”到架构:定义新范式
上下文工程的核心定义是“在下一步操作前,用恰到好处的信息填充上下文窗口的精妙艺术与科学”。它是一门设计和构建动态系统的学科,旨在为大语言模型在正确的时间、以正确的格式,提供正确的信息和工具。其最终目标是提供所有必要的上下文,使任务对于LLM来说是貌似可以解决的(plausibly solvable)。
为了更清晰地阐明这一新范式,下表对提示工程与上下文工程进行了详细的比较分析,从目标、活动、范围和隐喻等多个维度揭示了二者的根本区别。
表1:提示工程 vs. 上下文工程:一个比较框架
特征 | 提示工程 (Prompt Engineering) | 上下文工程 (Context Engineering) |
---|---|---|
主要目标 | 从模型中引出特定的响应 | 构建一个由模型驱动的、可靠且可扩展的应用 |
核心活动 | 手工精心制作一个静态的文本字符串 | 设计一个能够动态组装上下文的系统 |
范围 | 关注即时输入(“for the moment”) | 关注整个信息环境 |
隐喻 | 咒语(Incantation)或命令(Command) | 架构(Architecture)或剧本(Screenplay) |
焦点 | 说什么(What to say) | 当你说的时候,模型知道什么(What the model knows) |
本质 | 一种技巧(Hack)或技能(Skill) | 一门软件架构(Software Architecture)或学科(Discipline) |
如果说提示工程关注的是“如何提出正确的问题”,那么上下文工程则关注“如何确保AI拥有正确回答该问题所需的知识和环境”。前者是一种战术层面的技巧,而后者则是一种战略层面的系统设计。
1.2 丰富上下文的构成要素
一个精心设计的上下文窗口,并非单一信息的堆砌,而是由多个不同类型的组件动态组合而成的。这些组件共同构成了模型的思维世界。
- 指令/系统提示 (Instructions / System Prompt): 这是对模型行为的初始定义,通常包括角色设定(“你是一位专业的金融分析师”)、行为准则、任务说明以及少量示例(few-shot examples)。这曾是传统“提示”的核心领域,但现在只是整个上下文拼图中的一块。
- 用户提示 (User Prompt): 用户提出的直接问题或任务指令。
- 状态/历史记录 (State / History - Memory):
- 短期记忆: 正在进行的对话历史,为模型提供直接的交流背景。
- 长期记忆: 一个持久化的知识库,记录了用户的偏好、事实以及过去交互的摘要。这通常通过便笺本(scratchpads)或专门的记忆系统来管理。
- 检索到的知识 (Retrieved Knowledge - RAG): 从外部文档、数据库或API中检索到的、最新的或专有的信息,用于将模型的回答“锚定”在事实上,减少幻觉。
- 可用的工具 (Available Tools): LLM可以调用的外部函数或API的结构化描述(Schema),例如calculate_mortgage(计算抵押贷款)或search_database(搜索数据库)。
- 结构化输出 (Structured Output): 对模型响应格式的定义,例如要求输出一个JSON对象。
这些组件并非静态存在,而是由一个在每次LLM调用之前运行的“上下文组装系统”动态编排的。上下文工程师的核心工作正是设计这个预处理流水线。例如,针对一个用户查询,该系统可能会:1)检索用户的长期记忆档案;2)总结最近20轮的对话;3)基于当前问题对向量数据库执行RAG查询;4)选择一个相关的工具子集;5)将所有这些信息与系统提示结合,形成一个最终优化过的上下文块。这个过程揭示了LLM应用开发的核心逻辑正在发生转移:关键不再仅仅是后处理LLM的输出,而更多地在于预处理和组装其输入。这正是ChatGPT包装器这一说法为何具有误导性的根本原因1。
1.3 上下文窗口:LLM的工作内存(RAM)
上下文窗口是LLM进行交互的“竞技场”,可以被视为其“工作内存”或RAM 。其大小以“令牌”(token)为单位衡量,近年来经历了从4K到超过200万的爆炸式增长,这为开发者解锁了全新的范式。
然而,巨大的窗口容量并非万能药。简单地将信息填满窗口并不能保证高质量的输出,反而可能引发一系列问题。这些已知的长上下文失败模式,是驱动上下文工程走向精细化的重要原因。
- 迷失在中间(Lost in the Middle)问题: 研究表明,放置在长上下文开头或结尾的信息比放置在中间的信息更容易被模型准确回忆。
- 上下文稀释/干扰 (Context Dilution/Distraction): 大量不相关或多余的信息会稀释关键信号,干扰模型对核心任务的注意力,从而降低性能。
- 上下文污染 (Context Poisoning): 如果一个幻觉或错误事实进入了上下文,它可能会像毒药一样污染后续的生成内容,导致错误链的产生。
- 上下文冲突 (Context Clash): 上下文中包含相互矛盾的信息会让模型感到困惑,导致输出不稳定或不可靠。
- 成本与延迟 (Cost and Latency): API的计费、响应延迟和内存使用量都与令牌数量成正比。这为高效的上下文管理提供了强大的经济动机。
第二部分:上下文工程师的工具箱:核心策略与架构
本部分将从理论转向实践,详细介绍构成上下文工程学科核心的技术策略和架构模式。
2.1 检索增强生成(RAG):将模型锚定于现实
RAG是上下文工程的基石。它直接解决了LLM的两个核心局限:知识截止日期(导致信息过时)和幻觉风险(凭空捏造事实)。通过从外部知识源检索相关信息并将其注入上下文,RAG能够将模型的输出“锚定”在事实、最新或专有的数据之上。
一个现代的RAG流水线通常包括以下步骤:
- 数据摄取与分块 (Ingestion & Chunking): 将大型文档(如PDF、网页)分解成更小、易于管理的文本块(chunks)。分块的大小、边界和重叠度是需要仔细调整的关键超参数。
- 嵌入与索引 (Embedding & Indexing): 使用向量模型将每个文本块转换为高维向量(embedding),并存储在专门的向量数据库中,以便进行高效的语义相似度搜索。
- 检索与重排 (Retrieval & Re-ranking): 当用户提问时,系统首先将问题也转换为向量,然后在数据库中检索语义最相似的文本块。先进的系统会采用混合搜索(结合语义相似度和关键词匹配),并使用重排器(re-ranker)对检索结果进行二次排序,以确保最顶部的结果是与问题最相关的。
随着长上下文窗口的出现,RAG的角色也在演变。过去,在小窗口的限制下,RAG的目标是精确检索到少数几个最关键的片段。如今,在百万级令牌的窗口中,RAG可以一次性检索整篇文档或数百个文本块。这使得问题从“精确检索”转变为在更大、可能更嘈杂的数据集上进行“上下文内综合”。这在性能和成本之间创造了一个新的权衡空间,开发者需要根据具体应用场景来决定是追求极致性能(提供更多上下文)还是控制成本(提供更精简的上下文)。
2.2 扩展能动性:工具使用与函数调用
如果说RAG为模型提供了“知识”,那么工具使用(Tool Use)则为模型提供了行动能力。通过函数调用(Function Calling),LLM从一个被动的文本生成器转变为一个主动的代理(Agent),能够与外部世界进行交互,例如预订航班、查询数据库或发送电子邮件。
函数调用的机制可以被形象地描述为一场三步舞:
- 提供工具清单: 开发者首先向模型提供一份结构化的工具清单(通常是JSON Schema格式),详细描述每个可用函数的功能、所需参数及其类型。重要的是,模型本身并不执行这些函数。
- 模型决策: 应用将用户的提示和这份工具清单一同发送给模型。模型会根据用户的意图判断是否需要以及需要调用哪个函数。如果需要,它不会直接生成文本回答,而是返回一个包含待调用函数名称及其参数的JSON对象。
- 应用执行并返回结果: 应用代码接收到这个JSON对象后,在本地执行指定的函数,并将函数的返回结果(例如,数据库查询的数据、API调用的状态)作为新的上下文信息,再次发送给模型。模型在获得了这次行动的结果后,最终生成一个面向用户的、综合了所有信息的自然语言回答。
随着技术的发展,更先进的工具使用技术也已出现。例如,并行函数调用(Parallel Function Calling)允许像GPT-4o这样的新模型在一个回合中决策调用多个函数,应用可以并行执行这些函数,从而显著降低任务的总体延迟。此外,开发者还可以通过tool_choice参数来精确控制模型的行为,例如强制模型调用某个特定工具,或禁止其使用任何工具。
2.3 管理信息流:上下文的压缩、选择与隔离
面对有限且昂贵的上下文窗口,高效管理信息流至关重要。LangChain等框架总结了四种核心的上下文管理策略,它们共同构成了上下文工程师的日常操作手册。
- 写入 (Write - Memory): 将信息持久化到上下文窗口之外,以备后续使用。
- 便笺本 (Scratchpads): 用于任务执行过程中的短期笔记,帮助模型跟踪中间步骤或复杂逻辑。
- 长期记忆 (Long-Term Memories): 用于跨会话存储用户的偏好、关键事实等信息。这些记忆甚至可以由LLM自身通过对历史对话的反思来生成和综合。
- 选择 (Select - Retrieval): 动态地从外部存储中选择最相关的信息并注入到当前的上下文窗口中。这包括从长期记忆库中检索、从庞大的工具集中选择一个子集,或者通过RAG从知识库中获取事实。选择的质量至关重要,一次糟糕的选择(例如,ChatGPT在生成图片时错误地注入了用户的地理位置信息)可能会导致意想不到的负面结果。
- 压缩 (Compress - Summarization & Pruning): 在保留核心信息的前提下,减少上下文的令牌数量。
- 隔离 (Isolate - Partitioning): 将上下文进行结构化分区,以防止不同信息之间的干扰,提高模型的专注度。
- 多智能体系统 (Multi-Agent Systems): 将一个复杂任务分解为多个子任务,每个子任务分配给一个拥有独立、隔离的上下文窗口的专业智能体来处理。这能提升每个智能体的表现,但也带来了智能体之间协调困难和总体令牌成本增加的挑战。
- 沙箱化 (Sandboxing/Environments): 在一个隔离的环境中执行工具调用,只将必要的、经过处理的结果返回给LLM,从而避免原始的、可能非常庞大的数据污染上下文窗口。
这些策略并非孤立存在,应用它们时往往需要面对效率(Efficiency)与保真度(Fidelity)之间的内在张力。压缩和选择策略优先考虑效率(更少的令牌、更低的成本和延迟),但存在丢失关键细节的风险。而直接使用原始的长上下文则优先考虑保真度,代价是高昂的成本和潜在的性能下降。例如,“隔离”策略中的多智能体方法,虽然能让每个智能体更专注,但却可能与Cognition AI提出的“共享完整的智能体轨迹以维持一致性”的原则相冲突。因此,上下文工程师的真正价值不仅在于懂得应用这些技术,更在于能够深刻理解并驾驭这些权衡。一个优秀的LLM应用架构,必然是一个精心平衡的系统,它可能会对高保真度任务使用长上下文,对背景聊天记录进行积极压缩,并对工具使用进行精确选择。这正是一个定义了高级LLM应用设计的、复杂的多变量优化问题。
第三部分:产业格局:实践中的上下文工程
本部分将分析和比较三大领先AI实验室(Google, OpenAI, Anthropic)在上下文工程方面的不同理念和技术实现,从而勾勒出当前技术的最前沿图景。
3.1 谷歌的长上下文赌注:规模与充分性
谷歌的核心战略,尤其体现在其Gemini 1.5 Pro模型上,是极大地扩展原始上下文窗口的容量,达到了100万至200万令牌的惊人规模。这种规模压制的策略使得许多过去难以想象的应用成为可能,例如在一次调用中分析整个代码库、多部小说或数小时的视频内容。
然而,谷歌并不认为长上下文会完全取代RAG。他们清醒地认识到,RAG对于访问超出窗口限制的信息、以及将模型锚定在最新事实上仍然至关重要。他们的研究提出了一种混合策略:对于大多数查询,使用RAG以实现成本效益;而对于少数需要极致性能的关键查询,则利用完整的长上下文能力。
更进一步,谷歌的研究重心之一是量化上下文充分性(Sufficient Context)5。他们开发出一种方法,能够利用一个经过提示的Gemini 1.5 Pro模型,以超过93%的准确率来判断当前提供的上下文是否足以正确回答一个问题。这一技术可以直接应用于改进RAG系统,通过根据“充分性”得分对检索到的内容进行重排,从而在长上下文的新范式下,更有效地解决“垃圾进,垃圾出”的问题。
3.2 OpenAI的行动生态:作为上下文的工具
OpenAI的策略,尤其是在GPT-4、GPT-4o以及最新的o1系列模型中,更侧重于通过强大的函数调用能力来扩展模型的能动性(agency)。其API从早期的functions
参数演进到更通用的tools
参数,本身就标志着对这一范式的深度战略承诺。
在OpenAI的生态中,RAG本身就是通过工具来实现的,这是上下文工程的一个绝佳范例。在其定制GPT(Custom GPTs)产品中,名为myfiles_browser
的工具并非一个简单的功能,而是一个被打包成工具集(包括search()
, click()
, quote_lines()
等函数)的RAG系统。模型通过学习按顺序调用这些工具,自主完成“搜索-打开-引用”的检索流程,从而将信息检索无缝地整合到其推理链中。
性能基准测试显示,OpenAI的新o1模型在高达128k令牌的长上下文RAG任务上达到了业界顶尖水平6,这表明其研发重点不仅是让模型能“容纳”长上下文,更是要让模型能有效地“利用”这些上下文。
3.3 Anthropic的精细化上下文:精确与检索
Anthropic则为开发者提供了一套更为精细的手段,来控制其Claude模型在200K令牌窗口内的注意力。这些官方推荐的最佳实践本身就是上下文工程的一部分:
- 使用XML标签: 开发者被建议使用
<document>
、</document>
这样的XML标签来清晰地划分提示的不同部分。Claude模型经过专门的微调,能够特别关注这些标签,从而更好地理解指令、上下文和示例之间的区别。 - 优化信息位置: 建议将长篇文档放置在提示的顶部,位于具体指令和问题之上,以利用模型对开头信息更强的记忆力。
- 引导思维过程: 鼓励开发者在提示中加入“请在
<thinking>
标签内一步步思考”这样的指令,引导模型进行更深入、更条理的推理,从而提升复杂任务的表现。 - 预填充回答: 通过在
assistant
角色消息中提供回答的开头,可以有效地引导模型输出指定的格式,避免其产生多余的寒暄。
在RAG方面,Anthropic的研究直击传统方法的痛点。他们提出的上下文检索(Contextual Retrieval)方法7通过一个巧妙的预处理步骤来提升检索质量:在对文本块进行嵌入之前,先用一个强大的模型(如Claude 3 Haiku)为每个文本块生成一个简短的、富含上下文的摘要,然后对这个摘要进行嵌入。这种方法为检索系统提供了更丰富的语义信号。得益于Anthropic独特的提示缓存(prompt caching)功能,这种方法的成本效益极高,并被证明能将检索失败率降低49%7。
表2:OpenAI、Google与Anthropic的上下文策略比较分析
公司 | 核心理念 | 关键技术/技巧 | 主要优势 |
---|---|---|---|
规模与综合 (Scale and Synthesize) | 200万令牌上下文窗口;“上下文充分性”分析;RAG重排器 | 无与伦比的原始上下文容量,适用于大规模、单次调用的深度分析。 | |
OpenAI | 行动生态 (Ecosystem of Action) | 先进的(并行)函数调用;集成的RAG即工具 (myfiles_browser);高性能o1模型 | 业界领先的智能体能动性和工具集成能力。 |
Anthropic | 精确与控制 (Precision and Control) | XML标签化提示;“上下文检索”RAG优化;提示缓存 | 对模型行为的精细化控制和高度优化的检索准确性。 |
这张表格清晰地揭示了,上下文工程并没有唯一的“正确答案”。三大实验室正沿着不同的技术路径进行探索和下注,分别在原始规模、工具集成和检索质量上构筑自己的核心竞争力。
第四部分:人的维度:与数十年研究的对话
本部分将提升讨论的层次,将现代上下文工程的实践挑战与人机交互(Human-Computer Interaction, HCI)和设计领域的长期理论框架联系起来,论证这实际上是对核心原则的一次再发现。
4.1 一门“显学”的复兴:人机交互中的上下文
为AI提供上下文的挑战并非一个新问题。事实上,人机交互(HCI)领域数十年来一直在与“上下文”这个概念进行搏斗。HCI的根本目的,就是研究人们如何在特定的上下文中,使用系统来完成任务。
现代上下文工程的理念与HCI的多个基础理论不谋而合:
- 活动理论 (Activity Theory)8: 这是一个HCI的理论框架,它强调为了设计有效的系统,必须理解一个活动的完整上下文——包括用户、目标、社区和工具。这与上下文工程所倡导的整体性、系统级的视角如出一辙。
- 情境行动 (Situated Action) 与分布式认知 (Distributed Cognition)9: 这些理论认为,智能和行动并不仅仅存在于用户的大脑中,而是情境化并分布在环境和工具之中的。这与上下文工程将AI的“知识”外化到检索的文档、可用的工具和对话历史中的做法,形成了直接的类比。
这些理论的共通之处在于,它们都强调了理解和设计整体环境的重要性。然而,在LLM出现之前,传统的软件系统往往是僵化的、基于规则的,很难动态地适应人类活动的丰富而混乱的真实上下文。LLM作为第一种能够大规模摄取并响应非结构化自然语言的计算媒介,为这些HCI理论的实践应用打开了大门。因此,可以说,上下文工程是HCI核心原则在AI时代的大规模、工程化的实现。LLM的崛起,使得HCI理论变得前所未有地具有现实意义和可操作性。伊利诺伊大学提出的情境工程(Contextual Engineering)概念10,虽然主要关注物理基础设施,但也同样分享了这种对上下文的深刻、整体的看法,将社会理解和利益相关者价值观等因素都囊括其中,显示了这一理念的广泛适用性。
4.2 设计人机对话
随着AI变得越来越健谈和具有能动性,一门新的设计学科——AI交互设计(AI Interaction Design)——正在兴起。该领域融合了用户体验(UX)设计和对AI/ML的理解,旨在为AI系统创造直观、可信赖的交互界面。
在生成式AI时代,用户与产品的交互路径可以是无限多样的。这意味着设计师不能再像过去那样,只为少数几个预设的用户旅程进行设计。取而代之的是,他们必须设计交互设计策略(interaction design policies)——这是一套治理准则,用于定义产品应如何响应各种输入,以及如何在关键时刻处理不确定性和错误。
有效的人机协作,其基础是共享上下文。当AI能够访问与人类用户相同的上下文信息时(例如,过去的对话、相关的文档),它就能提供更个性化、更具适应性且更值得信赖的响应。像OpenMemory这样的工具正在尝试创建一个通用记忆层11,在不同的AI助手之间同步上下文,试图在用户层面解决上下文碎片化的问题。
第五部分:上下文驱动的AI之未来
本部分将展望未来,分析上下文工程的职业发展和技术演进轨迹。
5.1 上下文工程师的崛起:一个新职业的画像
“上下文工程师”是一个正在兴起的新兴职位。它是一个混合型角色,要求从业者同时具备数据工程、系统架构、提示词撰写,以及对AI行为的直觉理解(可称为AI心理学)等多方面能力。
我们可以通过分析一份真实的招聘启事——来自初创公司Harper的“AI上下文工程师”职位12——来具体了解这个角色的职责:
- 核心职责: 架构和开发可扩展的数据流水线,为AI系统提供高质量的上下文。
- 具体任务:
- 构建从数据库、API等多种来源拉取信息的数据工程流水线。
- 将处理后的信息推送到AI智能体的记忆存储中(例如向量数据库)。
- 与应用AI工程师合作,理解并优化智能体所需的上下文。
- 参与提示工程,但只是作为更广泛的上下文设计的一部分。
下表综合了多个来源的信息,构建了上下文工程师的核心能力模型。
表3:上下文工程师的核心能力模型
能力领域 | 关键技能与职责 |
---|---|
数据与系统架构 | 设计和构建数据流水线;掌握数据建模、事件溯源、向量数据库等技术。 |
AI/LLM集成 | RAG系统实现;工具/函数调用设计;上下文组装逻辑;提示词设计。 |
领域知识转化 | 将隐性的业务知识(例如公司内部流程、行业术语)转化为AI可以理解的显性上下文。 |
实验严谨性与优化 | 对不同的上下文格式进行A/B测试;衡量结果(如精确率/召回率);在成本、延迟和准确性之间进行优化。 |
AI心理学与调试 | 凭直觉判断不同上下文结构如何影响AI行为;通过分析上下文质量来调试AI的异常输出。 |
5.2 提示工程的演变:专业化抑或消亡?
关于“提示工程师”这一职位的未来,业界存在不同的看法。一些预测认为其需求将大幅增长,而另一些则认为它是一种过渡性技能,最终将演变为一个高度专业化的细分领域,或者对大多数用户来说变得不再必要。
推动其“消亡”的力量主要有二:
- 更智能的模型: 随着模型本身越来越善于理解模糊指令和推断上下文,普通用户对精巧提示的需求将大大降低。
- 自动化与框架: 像DSPy这样的框架正在兴起,它们旨在将程序逻辑与提示本身分离,并自动优化与模型的交互。自适应提示(AI自我优化提示)等技术也将减轻用户的负担。
然而,共识似乎正在形成:虽然“基础的”提示能力将成为一项普及性技能(就像使用电子表格一样),但“高级的”提示工程将被吸收到更资深、更具技术性的角色中,如上下文工程师或AI交互设计师。在金融、医疗等高风险、高价值的应用场景中,对AI输出进行精确控制的需求将永远存在,这需要专家的介入。就业市场上已经涌现出大量相关的职位名称,如“LLM交互工程师”、“对话设计师”等,这预示着一个更加细分和专业的未来。
5.3 结论:一个新软件范式的浮现
本报告的核心论点是,上下文工程是构建下一代软件的核心学科。这项工作远非创建简单的包装器1,而是要架构一个复杂的、动态的、绝非平凡的软件层,以精心编排流入和流出大语言模型的信息。
在未来,最有价值的AI技能将不再是掌握神秘的“魔法咒语”,而是理解如何架构能够“在正确的时间访问正确信息”的智能系统。那些能够精通上下文工程的公司,将获得巨大的竞争优势。如果说提示词告诉模型如何思考,那么上下文工程则赋予模型完成工作所需的知识和工具13。AI的未来,是一个建立在上下文之上,并由上下文所定义的未来。
参考文献
Reddit Community-2025-Context Engineering : Andrej Karpathy drops a new term for Prompt Engineering after "vibe coding."↩
用户请求↩
arXiv Authors-2025-Sentinel: Attention Probing of Proxy Models for LLM Context Compression with an Understanding Perspective↩
Hugging Face-Ongoing-Daily Papers: Reversible Context Compression↩
Google Research-2025-Deeper insights into retrieval augmented generation: The role of sufficient context↩
Databricks Blog-2025-The Long Context RAG Capabilities of OpenAI o1 and Google Gemini↩
Anthropic-2025-Introducing Contextual Retrieval↩
MIT Press-Context and Consciousness: Activity Theory and Human-Computer Interaction↩
ResearchGate (Table)-Theories Applicable to the Using of Context in HCI↩
University of Illinois-What is Contextual Engineering?↩
Anmol Baranwal-How to sync Context across AI Assistants (ChatGPT, Claude, Perplexity...) in your browser↩
Harper (Y Combinator)-AI Context Engineer - Member of Technical Staff at Harper↩