最近,又多了个新的概念,上下文工程,这是从提示工程发展而来的,因为随着LLM上下文的增长以及Agent能力的提升,写好一句prompt已经远远不够了,我们需要为AI Agent处理动态的上下文信息,处理得越好 毕竟底层LLM都是大家就能接入的,而上下文工程,那就非常考验架构和工程能力了。 以下是上下文工程必须要了解的知识点,欢迎查看: # Prompt 工程的局限 Prompt Engineering 是一门设计和优化提示(prompts)的技术,旨在有效利用大型语言模型(LLMs)来执行各种应用和研究任务 - 它被 Cognition 公司称为“构建 AI 代理工程师的首要任务”。Anthropic 也强调,代理在数百轮对话中需要精细的上下文管理策略。 例如,ChatGPT 和 Claude 通过将先前的提示和输出传入上下文窗口来保持短期记忆。 5.
slide=id.p#slide=id.p 1、从提示词工程到上下文工程 2、“上下文工程” 体现了当下所面临的各类挑战 上下文污染(Context Poisoning) 示例:Gemini在玩《宝可梦 而在每一个工业级的 LLM 应用中,上下文工程是填充上下文窗口以提供恰到好处的信息的艺术和科学,以便为下一步提供正确的背景信息。 4、上下文工程5大实践 1、转移上下文负担 利用文件系统存储笔记(see: Drew’s post[1], Anthropic multi-agent[2])。 通过文件系统读写包含大量 token 的上下文(参考:Manus[4])。 将文件用于存储长期记忆(参考:Ambient Agents course[5]/repo[6])。 5、六种上下文管理策略 PPT中附加的一篇文章写的也相当好《# How to Fix Your Context》[23] 文章承接前文 “长上下文如何失效”[24],探讨缓解或避免上下文失效的方法。
缰绳 (架构约束)引导它走正确的路,马车(上下文工程)提供舒适的承载空间,车上的镜子(反馈循环)随时照出它的状态,而车夫(熵管理)则负责清理它奔跑时留下的杂乱痕迹。 谁第一次喊出了这个名字 2026 年 2 月 5 日,HashiCorp 联合创始人在他的博客文章中首次使用了「harness engineering」这个术语。 Harness 到底在做什么 根据 OpenAI 官方报告的描述,Harness 由三个核心类别组成: 第一层:Context Engineering(上下文工程)。 不仅仅是给 Agent 一份文档,而是持续增强的知识库,加上动态上下文——比如可观测性数据、浏览器导航状态。 OpenAI 团队花了 5 个月时间来构建和完善他们的 Harness。 这不是某种「快速见效」的技巧,而是一个需要持续投入的系统工程。
什么是上下文工程 上下文,是在一次 LLM 推断过程中被纳入采样的全部 token 集合,上下文工程的核心任务,是在模型固有约束下,优化这些 token 的效用,以更稳定地获得预期结果。 上下文工程 vs 提示工程 提示工程:编写和组织模型指令以获得最佳输出,通常聚焦系统提示如何写得清晰、有效。 “上下文工程” 的艺术就在于:在有限的上下文窗口中,选取最有价值的子集。 3. 为什么 “上下文工程“ 对强代理至关重要? - semantic_search: 与search类似,但“更智能”,返回更长的上下文片段。 - list_docs: 列出所有文档并返回每个文档的首5页内容,防止错过重要信息。 5. 运行时上下文检索与 “代理式搜索” 我们将 “代理” 简化定义为:LLM 在循环中自主使用工具,随着模型提升,代理自治能力增强,能更好地独立探索与纠错。
至于重要性,下面这张图很好地概括了上下文工程与提示词工程、RAG 等的关系。 在传统的提示工程中,开发者通常侧重于精心设计提示语,以期得到更好的答案。 如今,提供完整且结构化的上下文信息比任何巧妙的提示词更为重要。 上下文工程就是为此诞生的。 上下文工程是构建动态系统,以正确的格式提供合适的信息和工具,从而使得 LLM 能够合理地完成任务。 因此,上下文工程正在成为 AI 工程师可以发展的最重要技能。 什么是上下文工程? 上下文工程是指构建动态系统,以合适的格式提供准确的信息和工具,使 LLM 能够合理完成任务。 上下文工程是一个系统。 上下文工程与提示工程有何不同? 为什么要从提示工程到上下文工程转变?早期,开发者专注于巧妙地给出提示以引导模型给出更好的答案。 但随着应用变得更加复杂,现在越来越明显的是,提供完整且结构化的上下文比任何巧妙的措辞更为重要。 我们可以将提示工程视为上下文工程的一个子集。即使你拥有所有的上下文,如何在提示中组装它仍然至关重要。
没有正确的上下文,AI模型难以保证相关性,常常产生不准确或“幻觉”的响应。上下文工程旨在解决一个根本问题:在正确的时间以正确的格式提供正确的信息,使AI代理能够执行复杂的、特定于用例的任务。 Contextual AI平台由检索增强生成(RAG)的先驱创立,提供了一个全面的上下文工程平台,用于快速构建开箱即用、具有卓越准确性的AI代理。 随着代理和AI系统变得越来越复杂,上下文工程确保它们能够在正确的时间访问并推理正确的信息。 通过将某中心的混合搜索和向量数据库与Contextual AI的上下文工程平台相结合,开发者获得了一个功能丰富的统一体验,可以在准确的企业上下文中落地他们的代理,而无需增加复杂性。 这一联合解决方案使开发者能够:实现前所未有的准确性:通过使用Contextual AI的上下文工程平台和某中心的混合搜索,代理可以检索并推理最复杂的企业数据,包括财务报告、法律文件和工程规范。
然而,随着LLM能力的增强,提示工程已经演变为上下文工程:优化输入LLM的所有数据,以在复杂任务上实现最大性能。本文将深入探讨智能体上下文工程,即专门为智能体优化上下文。 这与传统的上下文工程不同,因为智能体通常需要执行更长时间的任务序列。鉴于智能体上下文工程是一个广泛的话题,本文将深入探讨以下列出的主题,并撰写后续文章涵盖更多内容。 具体的上下文工程技巧缩短/总结上下文工具使用在深入探讨上下文工程的具体细节之前,首先说明为什么智能体上下文工程很重要。 为什么智能体需要上下文工程现在我们知道了为什么需要智能体,但为什么智能体需要上下文工程呢?主要原因是,当LLM的上下文包含更多相关信息且噪音(不相关信息)更少时,其性能总是更好。 我们需要从LLM的上下文中移除这些噪音信息,并确保所有相关信息都存在于LLM的上下文中。具体的上下文工程技巧智能体上下文工程建立在传统上下文工程的基础之上。
斯坦福大学最新提出的主动式上下文工程 Agentic Context Engineering(ACE)技术,正在挑战这一看似理所当然的做法,它让AI第一次拥有了类似人类的"经验积累"能力。
十、 上下文的理解 (一) 查询上下文 1. 定义 简单理解就是通过筛选查询得到的结果。 2. 说明 影响的方式包括:筛选器,切片器,透视表的行和列,透视图的轴等。 (二) 行上下文 根据信息所在的行决定的,并涉及到行的信息数据来计算。 1. 定义 行上下文可以被认为是当前行,如果在当前行创建公式,其参数就对应的是当前行的值。 2. 注意 行上下文也会涉及到关系。例如在多端引用1端数据是使用Related,则会默认当前行关联的数据。 4. 复杂的行上下文 根据行上下文筛选出的表在和原表做比较计算。 例如涉及到行数Earlier (三) 筛选上下文 1. 定义 对于查询上下文的进一步定义。可以直接在公式中指定过滤器表达式或动态获取计算中使用的值的上下文。
Alexa上下文语音识别的工程实现自动语音识别(ASR)是将语音信号转换为文本的技术。某中心的语音系统为每种语言维护统一的核心ASR模型,但其AI团队通过实时适配用户上下文来提升识别精度。 上下文感知的技术实现设备上下文利用 带屏幕的设备可显示查询应答列表,当处理后续指令时,ASR模型会优先识别列表中的条目。 规模化工程挑战 以确认型追问场景为例(如用户说"打电话给Meg"后需选择联系人),上下文感知使ASR错误率降低26%。 )的短文本数据表:独立存储加密的原始语句和上下文数据避免频繁加解密操作,仅在实际需要生成上下文向量时解密实时计算窗口优化利用系统响应时间窗口执行上下文向量计算麦克风重启指令(expect-speech) 系统设计支持离线实验新上下文信号,持续优化模型效果。技术团队强调:将实验室模型转化为海量用户服务需要严谨的系统设计,某中心工程团队通过科学与工程的紧密协作,实现了上下文机器学习在亿级规模下的稳定运行。
不过我觉得,“上下文工程”的基础更扎实一些。 1. 什么是上下文工程? img 可以这样理解: Prompting(提示词):是你直接让模型去做某件事。 上下文工程版本: [角色] 你是一名中年软件工程师,给同行写博客。 [受众] 有经验但对 LLM 持谨慎态度的开发者。 [语气示例] “是啊,Copilot 会写测试。 我提供了: 明确的角色:幽默的中年开发者 真实的语气样本:一句带有特定讽刺的示例 一个具体的玩笑要求:不是真的为了笑话,而是让模型写得不那么正式 5. 那么,该怎么做? 其实你可能已经在做上下文工程了,如果你曾经: 给提示词加过示例 改写提示词以调整语气 描述过目标受众 删除过多余文字以节省空间 ——那你就在做上下文工程。 译者注:所以我觉得所谓的上下文工程,如果只是本文来看的话,和提示词工程有什么区别呢?和我之前高赞原创的似乎没什么区别? 那么你的看法是什么呢?评论区留下你的见解。 敲黑板!
Shell 工具不是上下文工程的灵丹妙药 代理最重要的工具之一是用于构建自身上下文的搜索工具。 上下文工程中有哪些搜索接口? 上下文可以存在于不同的位置,例如网络、本地文件系统或数据库。 Anthropic [5] 和 Cursor [6] 的研究表明,这种方法可以节省 47% 到 85% 的令牌。 总结 文件系统与数据库的争论分散了工程师们应该关注的问题:代理需要什么样的搜索接口来构建自己的上下文? 答案很可能是,不只一种。 5. Anthropic. 在 Claude 开发者平台上引入高级工具使用 (2025)。 6. Cursor. 动态上下文发现 (2026)。 Agent Builder 现已全面上线。
真正拉开差距的,是上下文工程(Context Engineering)和提示词工程(Prompt Engineering)。 一、上下文工程:Agent 开发最被低估的工程问题 什么是上下文窗口管理 LLM 没有持久记忆,它只能看到被塞进上下文窗口里的内容。你塞什么,它就基于什么推理。 上下文工程要解决的核心问题是:在有限的 token 预算里,把最有价值的信息放进去,把噪声排出去。 ~20,000 tokens(浮动,约 20%~40%) ↓ Layer 5 · 实时上下文层(当前轮次) 当前用户输入 + 工具执行输出(截断处理) | ~500~5,000 tokens(约 5% 写在最后 上下文工程和提示词工程这两件事,本质上都是在做同一件事:为模型的每次推理构建一个信息质量尽可能高的输入。这件事没有银弹,但有工程原则可循——分层、模块化、按需加载、明确优先级。
目录 一、混合应用-H5 1.混合应用是什么? 2.怎么样分辨一个 App 页面究竟是原生的还是 Web 的? 5.想定位一个元素怎么操作? 四、代码 一、混合应用-H5 微信小程序的前提都是基于 H5,没有 H5 的情况下来操作微信小程序您可能不太明白。H5 是混合应用,有原生应用和混合应用。 1)在手机/模拟器中点击关于手机中的版本号 5 下,出来开发者选项。 2)在开发者选项中勾选上显示布局边界,再返回到 App 界面。 识别到 Web View 的前提是:下载知乎或者豆瓣,去获取所有当前可以操作的上下文,会发现没有 web view。也就是关闭了 Web View 的显示。 5.想定位一个元素怎么操作? 跟我们之前使用谷歌 F12 的套路是一样的。 ? 一个手机中除了这个 Web View 网页,可能还有别的 Web View 网页。
三、上下文切换 可用的上下文(Contexts) 列出所有可用的上下文(contexts) driver.contexts driver.window_handles 获取所有窗口的 handle,返回 当前上下文(context):列出当前的上下文(context) driver.current_context 切换至默认的上下文(context) 切换回默认的上下文(context)。 driver.current_package 上下文的操作方式在这里,和 Windows 窗口是一模一样的。和 Web 自动化中所谓的窗口是一样的。 首先列出所有可用的上下文。 列出所有可用的上下文,再去切换至需要的上下文。怎么切换呢?他们得到的结果也是个列表啊。 列表当中放的值呢,不是原生控件就是 WebView。所以它也有下标。 如果你想获取当前的窗口,当前的上下文,叫做driver.current_context。 它的做法与窗口是一模一样的。Web 自动化中叫做窗口,这里叫做上下文。
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5. items="${list }" var="u">
${u.id } --${u.uname }--${u.nickname }
</c:forEach>
</body>
</html>
5.
这一转变标志着提示工程(Prompt Engineering)正在自然演进为上下文工程(Context Engineering)。本文我将从技术视角剖析上下文工程的核心逻辑,希望能帮助到各位。 一、什么是上下文工程? 简单来说,上下文工程是将正确的信息以正确的格式在正确的时间传递给LLM的艺术和科学。 下图直观展示了两者的区别:左侧的提示工程流程简单:系统提示+用户消息→生成回复;右侧的上下文工程则是一个动态循环:模型从“可能上下文池”(文档、工具、记忆文件等)中通过“策划”环节筛选最优信息,填入有限上下文窗口 二、为什么上下文工程至关重要? ps:关于上下文工程的工作原理,如果你不清楚,我之前有写过一个很详细的技术文档,建议粉丝朋友自行查阅:《图解Agent上下文工程,小白都能看懂》三、高效上下文工程的三大核心组件 1.
还记得去年各大公司给提示工程师开出30万美元年薪的疯狂时期吗?现在这些招聘信息基本销声匿迹了。从技术角度看,提示工程确实有些"投机取巧"的意味——本质上就是让人们相信自己在做"工程"工作的华丽包装。 人们开始把传统软件工程的严谨方法和大语言模型的能力结合起来。这篇文章会深入探讨如何构建真正可扩展、生产环境稳定的智能体工作流。 上下文工程才是核心 虽然我从一开始就对提示工程持保留态度,但不得不承认这个领域的确积累了不少有价值的经验。没有万能的提示技巧,但针对特定数据集和场景,某些提示方法确实能带来明显的性能提升。 关键在于,单纯的提示远远不够——它只是"上下文工程"的一个小组成部分。 软件开发最初采用有向图结构,类似流程图的形式来表示顺序或分支逻辑。 许多研究表明,LLM在超过32k上下文窗口后可靠性显著下降,即便它们能处理百万级token。上下文越长,产生幻觉的概率就越高。
这揭示了一个重要趋势:AI代理的失败主要源于上下文失败而非模型缺陷,因此构建有效AI系统的关键是工程化上下文管理。 那么对于上下文工程和传统提示词工程的对比如下表: 接着我们再看下对于复杂问题上下文工程完整的处理流程如下图: 从上面的逻辑图,我们也可以看到上下文工程的核心组件包括了: 七个上下文维度 - 按照文章中提到的分类 ,用不同颜色区分 上下文聚合器 - 负责动态组装和优先级排序 智能处理流程 - 5个核心处理步骤 LLM核心 - 大语言模型的推理引擎 智能输出 - 最终的结构化结果 反馈循环 - 持续优化机制 所以看了前面的内容后 ,我的第一感觉就是上下文工程就是一种通用性的Agent,具备了复杂任务感知理解和拆分,任务规划和执行,长上下文记忆和存储,多轮反思和迭代,高度工程化和自主性等关键特点。 5. 简单来说,你要做的事情就是将我大量历史知识库已有的知识基于问题进行重新归纳和整理,形成一篇完整的条理清楚,逻辑性强的回答。 6. 注意列出4到5点最关键的点进行说明。7.
上下文工程是在智能体运行轨迹的每个步骤中,为其上下文窗口填充恰到好处信息的艺术与科学。在本文中,我们通过回顾各类热门智能体及相关论文,拆解了上下文工程的几种常见策略——写入、选择、压缩和隔离。 和RAM一样,LLM的上下文窗口容量有限,无法容纳所有来源的上下文信息。而正如操作系统会精心筛选适合存入CPU内存的内容,“上下文工程”也扮演着类似的角色。 【上下文工程是】“……一种精妙的艺术与科学,旨在为下一步操作的上下文窗口填充恰好所需的信息。” LLM应用中常见的上下文类型 在构建LLM应用时,我们需要管理哪些类型的上下文呢? )——工具调用的反馈 智能体的上下文工程 今年,随着LLM在推理和工具调用能力上的提升,人们对智能体的兴趣急剧增长。 鉴于此,Cognition公司强调了上下文工程的重要性: “上下文工程”……实际上是构建AI智能体的工程师的首要工作。