最近,又多了个新的概念,上下文工程,这是从提示工程发展而来的,因为随着LLM上下文的增长以及Agent能力的提升,写好一句prompt已经远远不够了,我们需要为AI Agent处理动态的上下文信息,处理得越好 毕竟底层LLM都是大家就能接入的,而上下文工程,那就非常考验架构和工程能力了。 以下是上下文工程必须要了解的知识点,欢迎查看: # Prompt 工程的局限 Prompt Engineering 是一门设计和优化提示(prompts)的技术,旨在有效利用大型语言模型(LLMs)来执行各种应用和研究任务 - 它被 Cognition 公司称为“构建 AI 代理工程师的首要任务”。Anthropic 也强调,代理在数百轮对话中需要精细的上下文管理策略。 # 工程师的工作流 Context Engineering 是一个迭代过程,它要求开发者: - 深入理解信息架构、数据策略和用户体验。 - 设计和管理提示链(prompt chains)。
request上下文 应用上下文和请求上下文都是存放在一个‘LocalStack’的栈中,和应用app相关的操作就必须要用到应用上下文,比如通过current_app获取当前的这个app的名字。 如果想要在视图函数外面执行相关的操作,name就必须要手动推入相关的上下文 手动推入请求上下文:推入请求上下文到栈中,会首先判断有没有应用上下文,如果没有那么就会先推入应用上下文到栈中,然后再推入请求上下文到栈中 app上下文 from flask import Flask,current_app app = Flask(__name__) #如果在视图函数外部访问,则必须手动推入一个app上下文到app上下文栈中 # 手动推入一个请求上下文到请求上下文栈中 # 如果当前应用上下文栈中没有应用上下文 # 那么会首先推入一个应用上下文到栈中 print(url_for('my_list')) 使用哪个请求上下文的时候,就把对应的请求上下文放到栈的顶部,用完了就要把这个请求上下文从栈中移除掉。
slide=id.p#slide=id.p 1、从提示词工程到上下文工程 2、“上下文工程” 体现了当下所面临的各类挑战 上下文污染(Context Poisoning) 示例:Gemini在玩《宝可梦 上下文干扰(Context Distraction) 示例:当上下文超过10万个token时,Gemini更倾向于重复之前的行为,而非生成新计划。 而在每一个工业级的 LLM 应用中,上下文工程是填充上下文窗口以提供恰到好处的信息的艺术和科学,以便为下一步提供正确的背景信息。 4、上下文工程5大实践 1、转移上下文负担 利用文件系统存储笔记(see: Drew’s post[1], Anthropic multi-agent[2])。 如果子智能体避免自主决策,可降低风险(参考: open-deep-research[22]). 5、缓存上下文 缓存 Claude-sonnet 的输入令牌,成本可降低 10 倍!
缰绳 (架构约束)引导它走正确的路,马车(上下文工程)提供舒适的承载空间,车上的镜子(反馈循环)随时照出它的状态,而车夫(熵管理)则负责清理它奔跑时留下的杂乱痕迹。 再之后,知名工程师 Martin Fowler 在 Twitter 上为 Thoughtworks 工程师对这份报告的深度分析站台。 Harness 到底在做什么 根据 OpenAI 官方报告的描述,Harness 由三个核心类别组成: 第一层:Context Engineering(上下文工程)。 不仅仅是给 Agent 一份文档,而是持续增强的知识库,加上动态上下文——比如可观测性数据、浏览器导航状态。 OpenAI 团队发现,传统的「一个巨大的 AGENTS.md 文件」方法注定失败:上下文是稀缺资源,过多的指导反而变得无效,那本「1000 页的说明书」会变成「陈旧规则的坟场」。
大模型发展这两年,应用型 AI 的焦点一直在 “提示工程”(prompt engineering),但随着更强大的大语言模型(LLM)走向多轮、长时间的自主行动,一个更关键的概念开始走到台前:上下文工程 什么是上下文工程 上下文,是在一次 LLM 推断过程中被纳入采样的全部 token 集合,上下文工程的核心任务,是在模型固有约束下,优化这些 token 的效用,以更稳定地获得预期结果。 上下文工程 vs 提示工程 提示工程:编写和组织模型指令以获得最佳输出,通常聚焦系统提示如何写得清晰、有效。 “上下文工程” 的艺术就在于:在有限的上下文窗口中,选取最有价值的子集。 3. 为什么 “上下文工程“ 对强代理至关重要? 无论问题是什么,都要先给出10步解决方案和详细解释。
至于重要性,下面这张图很好地概括了上下文工程与提示词工程、RAG 等的关系。 在传统的提示工程中,开发者通常侧重于精心设计提示语,以期得到更好的答案。 如今,提供完整且结构化的上下文信息比任何巧妙的提示词更为重要。 上下文工程就是为此诞生的。 上下文工程是构建动态系统,以正确的格式提供合适的信息和工具,从而使得 LLM 能够合理地完成任务。 因此,上下文工程正在成为 AI 工程师可以发展的最重要技能。 什么是上下文工程? 上下文工程是指构建动态系统,以合适的格式提供准确的信息和工具,使 LLM 能够合理完成任务。 上下文工程是一个系统。 上下文工程与提示工程有何不同? 为什么要从提示工程到上下文工程转变?早期,开发者专注于巧妙地给出提示以引导模型给出更好的答案。 但随着应用变得更加复杂,现在越来越明显的是,提供完整且结构化的上下文比任何巧妙的措辞更为重要。 我们可以将提示工程视为上下文工程的一个子集。即使你拥有所有的上下文,如何在提示中组装它仍然至关重要。
没有正确的上下文,AI模型难以保证相关性,常常产生不准确或“幻觉”的响应。上下文工程旨在解决一个根本问题:在正确的时间以正确的格式提供正确的信息,使AI代理能够执行复杂的、特定于用例的任务。 Contextual AI平台由检索增强生成(RAG)的先驱创立,提供了一个全面的上下文工程平台,用于快速构建开箱即用、具有卓越准确性的AI代理。 随着代理和AI系统变得越来越复杂,上下文工程确保它们能够在正确的时间访问并推理正确的信息。 通过将某中心的混合搜索和向量数据库与Contextual AI的上下文工程平台相结合,开发者获得了一个功能丰富的统一体验,可以在准确的企业上下文中落地他们的代理,而无需增加复杂性。 这一联合解决方案使开发者能够:实现前所未有的准确性:通过使用Contextual AI的上下文工程平台和某中心的混合搜索,代理可以检索并推理最复杂的企业数据,包括财务报告、法律文件和工程规范。
然而,随着LLM能力的增强,提示工程已经演变为上下文工程:优化输入LLM的所有数据,以在复杂任务上实现最大性能。本文将深入探讨智能体上下文工程,即专门为智能体优化上下文。 具体的上下文工程技巧缩短/总结上下文工具使用在深入探讨上下文工程的具体细节之前,首先说明为什么智能体上下文工程很重要。 我们需要从LLM的上下文中移除这些噪音信息,并确保所有相关信息都存在于LLM的上下文中。具体的上下文工程技巧智能体上下文工程建立在传统上下文工程的基础之上。 <example>"10+20等于多少?" 你应该在重试前运行 time.sleep(10)。"
10+ 个神级MCP推荐 AI 写代码总是翻车?Upstash 创始人怒推 Context7 没有这些工具,AI 就拿不到生成正确代码所需要的上下文。所以,上下文工程这事儿,很重要。 提示工程PromptAI上下文工程文档示例规则模式AI 上下文工程,跟传统的提示词工程,是两种思路: 提示词工程 关注怎么巧妙地措辞。 局限于你怎么描述一个任务。 就像给人递了张便利贴。 上下文工程 是一套提供完整上下文的系统。 包括文档、示例、规则、模式和验证。 就像写了个完整的剧本,细节全有。 为啥上下文工程这么重要? 用上下文工程,你会用到所有这些不同的上下文。 几种常见策略——编写、选择、压缩和隔离。 这玩意儿比提示词工程好 10 倍,比 Vibe Coding 好 100 倍。 这个模板能帮你跟任何 AI 编码助手一起用,但它本身是为 Claude Code 设计的。
斯坦福大学最新提出的主动式上下文工程 Agentic Context Engineering(ACE)技术,正在挑战这一看似理所当然的做法,它让AI第一次拥有了类似人类的"经验积累"能力。
Alexa上下文语音识别的工程实现自动语音识别(ASR)是将语音信号转换为文本的技术。某中心的语音系统为每种语言维护统一的核心ASR模型,但其AI团队通过实时适配用户上下文来提升识别精度。 上下文感知的技术实现设备上下文利用 带屏幕的设备可显示查询应答列表,当处理后续指令时,ASR模型会优先识别列表中的条目。 规模化工程挑战 以确认型追问场景为例(如用户说"打电话给Meg"后需选择联系人),上下文感知使ASR错误率降低26%。 )的短文本数据表:独立存储加密的原始语句和上下文数据避免频繁加解密操作,仅在实际需要生成上下文向量时解密实时计算窗口优化利用系统响应时间窗口执行上下文向量计算麦克风重启指令(expect-speech) 系统设计支持离线实验新上下文信号,持续优化模型效果。技术团队强调:将实验室模型转化为海量用户服务需要严谨的系统设计,某中心工程团队通过科学与工程的紧密协作,实现了上下文机器学习在亿级规模下的稳定运行。
任意组件更新Context 某些时候需要在内部组件需要去更新Context的数据,其实我们仅仅需要向上下文增加一个回调即可,看下面的例子: //创建Context组件 const ThemeContext = React.createContext({ theme: 'dark', toggle: () => {}, //向上下文设定一个回调方法 }); function Button() {
“上下文工程”(Context Engineering)是当下的新热词,自从 Andrej Karpathy 在推特上推广它后,大家都为之疯狂。 不过我觉得,“上下文工程”的基础更扎实一些。 1. 什么是上下文工程? img 可以这样理解: Prompting(提示词):是你直接让模型去做某件事。 上下文工程版本: [角色] 你是一名中年软件工程师,给同行写博客。 [受众] 有经验但对 LLM 持谨慎态度的开发者。 [语气示例] “是啊,Copilot 会写测试。 其实你可能已经在做上下文工程了,如果你曾经: 给提示词加过示例 改写提示词以调整语气 描述过目标受众 删除过多余文字以节省空间 ——那你就在做上下文工程。 译者注:所以我觉得所谓的上下文工程,如果只是本文来看的话,和提示词工程有什么区别呢?和我之前高赞原创的似乎没什么区别? 那么你的看法是什么呢?评论区留下你的见解。 敲黑板!
Shell 工具不是上下文工程的灵丹妙药 代理最重要的工具之一是用于构建自身上下文的搜索工具。 最近,LlamaIndex 和 LangChain 的帖子引发了一场讨论:对于上下文工程来说,shell 工具和文件系统是否足够? 不幸的是,这场讨论很快偏离了主题,变成了文件系统与数据库的比较。 上下文工程中有哪些搜索接口? 上下文可以存在于不同的位置,例如网络、本地文件系统或数据库。 任何忽视这些缺点的人都注定会痛苦地重造更糟糕的数据库,而无法享受生产数据库已经提供的事务安全或访问控制的数十年工程经验。 总结 文件系统与数据库的争论分散了工程师们应该关注的问题:代理需要什么样的搜索接口来构建自己的上下文? 答案很可能是,不只一种。
真正拉开差距的,是上下文工程(Context Engineering)和提示词工程(Prompt Engineering)。 一、上下文工程:Agent 开发最被低估的工程问题 什么是上下文窗口管理 LLM 没有持久记忆,它只能看到被塞进上下文窗口里的内容。你塞什么,它就基于什么推理。 上下文工程要解决的核心问题是:在有限的 token 预算里,把最有价值的信息放进去,把噪声排出去。 写在最后 上下文工程和提示词工程这两件事,本质上都是在做同一件事:为模型的每次推理构建一个信息质量尽可能高的输入。这件事没有银弹,但有工程原则可循——分层、模块化、按需加载、明确优先级。 下一步值得探索的方向:Agent 的上下文工程在多 Agent 协作场景下会变得更复杂——多个 Agent 之间怎么共享上下文、传递状态、避免信息重复注入?这是下一阶段值得深挖的问题。
运行环境 DevEco Studio:4.0Release OpenHarmony SDK API10 开发板:润和DAYU200 目前我们能够看到的是鸿蒙已经到API10,甚至今天在看OpenHarmony 这个时候,我们最起码要将API 9工程转换为API 10工程。然后再慢慢的迁移到未来的11上。 接下来我们说一下如何迁移。 1.将工程级build-profile.json5文件中compileSdkVersion和compatibleSdkVersion字段从app下迁移到当前选中的product中。 , "compatibleSdkVersion": 10, "targetSdkVersion": 10, "runtimeOS": "OpenHarmony "targetSdkVersion": 10, //指定OpenHarmony应用/服务目标版本。
这一转变标志着提示工程(Prompt Engineering)正在自然演进为上下文工程(Context Engineering)。本文我将从技术视角剖析上下文工程的核心逻辑,希望能帮助到各位。 一、什么是上下文工程? 简单来说,上下文工程是将正确的信息以正确的格式在正确的时间传递给LLM的艺术和科学。 下图直观展示了两者的区别:左侧的提示工程流程简单:系统提示+用户消息→生成回复;右侧的上下文工程则是一个动态循环:模型从“可能上下文池”(文档、工具、记忆文件等)中通过“策划”环节筛选最优信息,填入有限上下文窗口 二、为什么上下文工程至关重要? ps:关于上下文工程的工作原理,如果你不清楚,我之前有写过一个很详细的技术文档,建议粉丝朋友自行查阅:《图解Agent上下文工程,小白都能看懂》三、高效上下文工程的三大核心组件 1.
还记得去年各大公司给提示工程师开出30万美元年薪的疯狂时期吗?现在这些招聘信息基本销声匿迹了。从技术角度看,提示工程确实有些"投机取巧"的意味——本质上就是让人们相信自己在做"工程"工作的华丽包装。 人们开始把传统软件工程的严谨方法和大语言模型的能力结合起来。这篇文章会深入探讨如何构建真正可扩展、生产环境稳定的智能体工作流。 上下文工程才是核心 虽然我从一开始就对提示工程持保留态度,但不得不承认这个领域的确积累了不少有价值的经验。没有万能的提示技巧,但针对特定数据集和场景,某些提示方法确实能带来明显的性能提升。 关键在于,单纯的提示远远不够——它只是"上下文工程"的一个小组成部分。 软件开发最初采用有向图结构,类似流程图的形式来表示顺序或分支逻辑。 上下文增长会导致智能体"漂移",出现重复动作或失去连贯性的问题。长上下文窗口(10-20轮对话)会严重降低可靠性,即使是高质量的LLM在这种情况下也会表现不佳。
上下文工程具有四个显著特点。首先是系统性,它不依赖静态模板,而是通过动态系统生成上下文。其次是动态性,根据具体任务实时定制信息内容,一个请求可能需要日历数据,另一个可能需要邮件历史。 这揭示了一个重要趋势:AI代理的失败主要源于上下文失败而非模型缺陷,因此构建有效AI系统的关键是工程化上下文管理。 那么对于上下文工程和传统提示词工程的对比如下表: 接着我们再看下对于复杂问题上下文工程完整的处理流程如下图: 从上面的逻辑图,我们也可以看到上下文工程的核心组件包括了: 七个上下文维度 - 按照文章中提到的分类 ,我的第一感觉就是上下文工程就是一种通用性的Agent,具备了复杂任务感知理解和拆分,任务规划和执行,长上下文记忆和存储,多轮反思和迭代,高度工程化和自主性等关键特点。 所以结合我个人的实践,我们来看下个人如何进行上下文工程的一些实践。 1.
上下文工程是在智能体运行轨迹的每个步骤中,为其上下文窗口填充恰到好处信息的艺术与科学。在本文中,我们通过回顾各类热门智能体及相关论文,拆解了上下文工程的几种常见策略——写入、选择、压缩和隔离。 和RAM一样,LLM的上下文窗口容量有限,无法容纳所有来源的上下文信息。而正如操作系统会精心筛选适合存入CPU内存的内容,“上下文工程”也扮演着类似的角色。 【上下文工程是】“……一种精妙的艺术与科学,旨在为下一步操作的上下文窗口填充恰好所需的信息。” LLM应用中常见的上下文类型 在构建LLM应用时,我们需要管理哪些类型的上下文呢? )——工具调用的反馈 智能体的上下文工程 今年,随着LLM在推理和工具调用能力上的提升,人们对智能体的兴趣急剧增长。 鉴于此,Cognition公司强调了上下文工程的重要性: “上下文工程”……实际上是构建AI智能体的工程师的首要工作。