最近,又多了个新的概念,上下文工程,这是从提示工程发展而来的,因为随着LLM上下文的增长以及Agent能力的提升,写好一句prompt已经远远不够了,我们需要为AI Agent处理动态的上下文信息,处理得越好 毕竟底层LLM都是大家就能接入的,而上下文工程,那就非常考验架构和工程能力了。 以下是上下文工程必须要了解的知识点,欢迎查看: # Prompt 工程的局限 Prompt Engineering 是一门设计和优化提示(prompts)的技术,旨在有效利用大型语言模型(LLMs)来执行各种应用和研究任务 - 它被 Cognition 公司称为“构建 AI 代理工程师的首要任务”。Anthropic 也强调,代理在数百轮对话中需要精细的上下文管理策略。 2. 知识(Knowledge):包括事实、记忆等信息。 3. 工具(Tools):可供 LLM 使用的工具定义,以及来自工具调用的反馈。
slide=id.p#slide=id.p 1、从提示词工程到上下文工程 2、“上下文工程” 体现了当下所面临的各类挑战 上下文污染(Context Poisoning) 示例:Gemini在玩《宝可梦 而在每一个工业级的 LLM 应用中,上下文工程是填充上下文窗口以提供恰到好处的信息的艺术和科学,以便为下一步提供正确的背景信息。 4、上下文工程5大实践 1、转移上下文负担 利用文件系统存储笔记(see: Drew’s post[1], Anthropic multi-agent[2])。 2、精简上下文 总结智能体的消息历史(参考:Drew’s post[7]、Claude Code) 删减消息历史中不相关的部分(参考:Drew’s post[8]) 总结或删减工具调用的输出内容(参考: 正如Andrej Karpathy所说: 除了上下文工程本身之外,一个 LLM 应用还需要: 将问题恰当地拆分成控制流 把上下文窗口调整得刚刚好 分配合适的 LLM 调用 处理生成-验证的 UI/UX
缰绳 (架构约束)引导它走正确的路,马车(上下文工程)提供舒适的承载空间,车上的镜子(反馈循环)随时照出它的状态,而车夫(熵管理)则负责清理它奔跑时留下的杂乱痕迹。 谁第一次喊出了这个名字 2026 年 2 月 5 日,HashiCorp 联合创始人在他的博客文章中首次使用了「harness engineering」这个术语。 Harness 到底在做什么 根据 OpenAI 官方报告的描述,Harness 由三个核心类别组成: 第一层:Context Engineering(上下文工程)。 不仅仅是给 Agent 一份文档,而是持续增强的知识库,加上动态上下文——比如可观测性数据、浏览器导航状态。 参考 [1] LangChain Terminal Bench 2.0 Results - blockchain.news. [2] Mitchell Hashimoto - My AI Adoption
大模型发展这两年,应用型 AI 的焦点一直在 “提示工程”(prompt engineering),但随着更强大的大语言模型(LLM)走向多轮、长时间的自主行动,一个更关键的概念开始走到台前:上下文工程 什么是上下文工程 上下文,是在一次 LLM 推断过程中被纳入采样的全部 token 集合,上下文工程的核心任务,是在模型固有约束下,优化这些 token 的效用,以更稳定地获得预期结果。 要驾驭 LLM,往往需要 “在上下文中思考”:把模型任意时刻能读取到的一切状态视为整体,并评估这些状态可能产生的行为。 2. 上下文工程 vs 提示工程 提示工程:编写和组织模型指令以获得最佳输出,通常聚焦系统提示如何写得清晰、有效。 “上下文工程” 的艺术就在于:在有限的上下文窗口中,选取最有价值的子集。 3. 为什么 “上下文工程“ 对强代理至关重要?
至于重要性,下面这张图很好地概括了上下文工程与提示词工程、RAG 等的关系。 在传统的提示工程中,开发者通常侧重于精心设计提示语,以期得到更好的答案。 如今,提供完整且结构化的上下文信息比任何巧妙的提示词更为重要。 上下文工程就是为此诞生的。 上下文工程是构建动态系统,以正确的格式提供合适的信息和工具,从而使得 LLM 能够合理地完成任务。 因此,上下文工程正在成为 AI 工程师可以发展的最重要技能。 什么是上下文工程? 上下文工程是指构建动态系统,以合适的格式提供准确的信息和工具,使 LLM 能够合理完成任务。 上下文工程是一个系统。 上下文工程与提示工程有何不同? 为什么要从提示工程到上下文工程转变?早期,开发者专注于巧妙地给出提示以引导模型给出更好的答案。 但随着应用变得更加复杂,现在越来越明显的是,提供完整且结构化的上下文比任何巧妙的措辞更为重要。 我们可以将提示工程视为上下文工程的一个子集。即使你拥有所有的上下文,如何在提示中组装它仍然至关重要。
没有正确的上下文,AI模型难以保证相关性,常常产生不准确或“幻觉”的响应。上下文工程旨在解决一个根本问题:在正确的时间以正确的格式提供正确的信息,使AI代理能够执行复杂的、特定于用例的任务。 Contextual AI平台由检索增强生成(RAG)的先驱创立,提供了一个全面的上下文工程平台,用于快速构建开箱即用、具有卓越准确性的AI代理。 随着代理和AI系统变得越来越复杂,上下文工程确保它们能够在正确的时间访问并推理正确的信息。 通过将某中心的混合搜索和向量数据库与Contextual AI的上下文工程平台相结合,开发者获得了一个功能丰富的统一体验,可以在准确的企业上下文中落地他们的代理,而无需增加复杂性。 这一联合解决方案使开发者能够:实现前所未有的准确性:通过使用Contextual AI的上下文工程平台和某中心的混合搜索,代理可以检索并推理最复杂的企业数据,包括财务报告、法律文件和工程规范。
然而,随着LLM能力的增强,提示工程已经演变为上下文工程:优化输入LLM的所有数据,以在复杂任务上实现最大性能。本文将深入探讨智能体上下文工程,即专门为智能体优化上下文。 具体的上下文工程技巧缩短/总结上下文工具使用在深入探讨上下文工程的具体细节之前,首先说明为什么智能体上下文工程很重要。 我们需要从LLM的上下文中移除这些噪音信息,并确保所有相关信息都存在于LLM的上下文中。具体的上下文工程技巧智能体上下文工程建立在传统上下文工程的基础之上。 然后我再把最后两位加起来得到1+2=3。答案是:30" </example><example>"120+70等于多少?" -> "为了回答用户的请求,我必须从后往前把数字加起来。我从0+0=0开始。 然后做2+7=9,最后做1+0=1。答案是:190" </example>123+150等于多少?"""这将有助于模型更好地理解示例,通常能进一步提高模型性能。
斯坦福大学最新提出的主动式上下文工程 Agentic Context Engineering(ACE)技术,正在挑战这一看似理所当然的做法,它让AI第一次拥有了类似人类的"经验积累"能力。
Alexa上下文语音识别的工程实现自动语音识别(ASR)是将语音信号转换为文本的技术。某中心的语音系统为每种语言维护统一的核心ASR模型,但其AI团队通过实时适配用户上下文来提升识别精度。 上下文感知的技术实现设备上下文利用 带屏幕的设备可显示查询应答列表,当处理后续指令时,ASR模型会优先识别列表中的条目。 规模化工程挑战 以确认型追问场景为例(如用户说"打电话给Meg"后需选择联系人),上下文感知使ASR错误率降低26%。 )的短文本数据表:独立存储加密的原始语句和上下文数据避免频繁加解密操作,仅在实际需要生成上下文向量时解密实时计算窗口优化利用系统响应时间窗口执行上下文向量计算麦克风重启指令(expect-speech) 系统设计支持离线实验新上下文信号,持续优化模型效果。技术团队强调:将实验室模型转化为海量用户服务需要严谨的系统设计,某中心工程团队通过科学与工程的紧密协作,实现了上下文机器学习在亿级规模下的稳定运行。
不过我觉得,“上下文工程”的基础更扎实一些。 1. 什么是上下文工程? img 可以这样理解: Prompting(提示词):是你直接让模型去做某件事。 2. 实际运作方式 这不是一个完美的逐步方法,但下面是一个在实践中效果不错的大致流程。 2.1. 先弄清楚你真正想要什么 在问模型任何问题之前,先明确你期待的结果。不要这样: “写一个食谱。” 上下文工程版本: [角色] 你是一名中年软件工程师,给同行写博客。 [受众] 有经验但对 LLM 持谨慎态度的开发者。 [语气示例] “是啊,Copilot 会写测试。 其实你可能已经在做上下文工程了,如果你曾经: 给提示词加过示例 改写提示词以调整语气 描述过目标受众 删除过多余文字以节省空间 ——那你就在做上下文工程。 译者注:所以我觉得所谓的上下文工程,如果只是本文来看的话,和提示词工程有什么区别呢?和我之前高赞原创的似乎没什么区别? 那么你的看法是什么呢?评论区留下你的见解。 敲黑板!
Shell 工具不是上下文工程的灵丹妙药 代理最重要的工具之一是用于构建自身上下文的搜索工具。 最近,LlamaIndex 和 LangChain 的帖子引发了一场讨论:对于上下文工程来说,shell 工具和文件系统是否足够? 不幸的是,这场讨论很快偏离了主题,变成了文件系统与数据库的比较。 例如,Claude Code [1] 和 Cursor [2] 允许代理根据任务的实际需要,在不同的搜索工具之间选择,甚至将它们组合起来进行链式查询。 上下文工程中有哪些搜索接口? 总结 文件系统与数据库的争论分散了工程师们应该关注的问题:代理需要什么样的搜索接口来构建自己的上下文? 答案很可能是,不只一种。 2. Cursor: 文档. 语义与代理搜索 (2026)。 3. Harrison Chase (LangChain). 我们如何构建 Agent Builder 的记忆系统 (2026)。 4.
真正拉开差距的,是上下文工程(Context Engineering)和提示词工程(Prompt Engineering)。 一、上下文工程:Agent 开发最被低估的工程问题 什么是上下文窗口管理 LLM 没有持久记忆,它只能看到被塞进上下文窗口里的内容。你塞什么,它就基于什么推理。 上下文工程要解决的核心问题是:在有限的 token 预算里,把最有价值的信息放进去,把噪声排出去。 写在最后 上下文工程和提示词工程这两件事,本质上都是在做同一件事:为模型的每次推理构建一个信息质量尽可能高的输入。这件事没有银弹,但有工程原则可循——分层、模块化、按需加载、明确优先级。 下一步值得探索的方向:Agent 的上下文工程在多 Agent 协作场景下会变得更复杂——多个 Agent 之间怎么共享上下文、传递状态、避免信息重复注入?这是下一阶段值得深挖的问题。
实现要求:提供RPC上下文,客户端可以透传数据给服务端。 实现如下: /** * rpc上下文 * * @author wqx * */ public class RpcContext { private static ThreadLocal private Object[] args; //参数 private Map<String,Object> context; RpcBuilder中在发送请求前,需要从当前上下文中获取数据 RpcRequest rpcRequest = (RpcRequest)req; //关联客户端传来的上下文数据 } 测试: 业务接口增加测试方法: public interface UserService { /** * 上下文测试,透明传输数据 */ public
这一转变标志着提示工程(Prompt Engineering)正在自然演进为上下文工程(Context Engineering)。本文我将从技术视角剖析上下文工程的核心逻辑,希望能帮助到各位。 一、什么是上下文工程? 简单来说,上下文工程是将正确的信息以正确的格式在正确的时间传递给LLM的艺术和科学。 二、为什么上下文工程至关重要? ps:关于上下文工程的工作原理,如果你不清楚,我之前有写过一个很详细的技术文档,建议粉丝朋友自行查阅:《图解Agent上下文工程,小白都能看懂》三、高效上下文工程的三大核心组件 1. 2. 工具设计:像代码库一样追求内聚与鲁棒性 工具定义了Agent与环境交互的契约。优秀工具应具备:自包含和功能内聚性,减少重叠;对错误的鲁棒性;意图清晰、参数无歧义。
还记得去年各大公司给提示工程师开出30万美元年薪的疯狂时期吗?现在这些招聘信息基本销声匿迹了。从技术角度看,提示工程确实有些"投机取巧"的意味——本质上就是让人们相信自己在做"工程"工作的华丽包装。 人们开始把传统软件工程的严谨方法和大语言模型的能力结合起来。这篇文章会深入探讨如何构建真正可扩展、生产环境稳定的智能体工作流。 上下文工程才是核心 虽然我从一开始就对提示工程持保留态度,但不得不承认这个领域的确积累了不少有价值的经验。没有万能的提示技巧,但针对特定数据集和场景,某些提示方法确实能带来明显的性能提升。 关键在于,单纯的提示远远不够——它只是"上下文工程"的一个小组成部分。 软件开发最初采用有向图结构,类似流程图的形式来表示顺序或分支逻辑。 许多研究表明,LLM在超过32k上下文窗口后可靠性显著下降,即便它们能处理百万级token。上下文越长,产生幻觉的概率就越高。
这揭示了一个重要趋势:AI代理的失败主要源于上下文失败而非模型缺陷,因此构建有效AI系统的关键是工程化上下文管理。 那么对于上下文工程和传统提示词工程的对比如下表: 接着我们再看下对于复杂问题上下文工程完整的处理流程如下图: 从上面的逻辑图,我们也可以看到上下文工程的核心组件包括了: 七个上下文维度 - 按照文章中提到的分类 ,我的第一感觉就是上下文工程就是一种通用性的Agent,具备了复杂任务感知理解和拆分,任务规划和执行,长上下文记忆和存储,多轮反思和迭代,高度工程化和自主性等关键特点。 2. 回答的内容要体现完整的逻辑性,而且通俗易懂,容易理解,如果需要例子也需要知识库里面存在的例子或案例。 3. 整个回答在2000到3000字之间。 具体链接如下: 2.AI编程中的需求工程结构化 这个也是我最近做的一个关键实践,就是AI编程中的需求结构化。
上下文工程是在智能体运行轨迹的每个步骤中,为其上下文窗口填充恰到好处信息的艺术与科学。在本文中,我们通过回顾各类热门智能体及相关论文,拆解了上下文工程的几种常见策略——写入、选择、压缩和隔离。 和RAM一样,LLM的上下文窗口容量有限,无法容纳所有来源的上下文信息。而正如操作系统会精心筛选适合存入CPU内存的内容,“上下文工程”也扮演着类似的角色。 【上下文工程是】“……一种精妙的艺术与科学,旨在为下一步操作的上下文窗口填充恰好所需的信息。” LLM应用中常见的上下文类型 在构建LLM应用时,我们需要管理哪些类型的上下文呢? 鉴于此,Cognition公司强调了上下文工程的重要性: “上下文工程”……实际上是构建AI智能体的工程师的首要工作。 2. 选择上下文(Select Context) 选择上下文指将外部信息拉入上下文窗口,以辅助智能体执行任务。 便签本选择 从便签本中选择上下文的机制取决于便签本的实现方式。
它关注的是如何为AI系统提供完整的工作环境,包括背景知识、历史记录、工具调用、数据检索等各个方面,让AI在这个精心构建的上下文环境中更好地完成复杂任务。 什么是上下文工程? 笔者最近为一个个人使用的多智能体深度研究应用做了一些上下文工程工作。在这个应用中,Search Planner(搜索规划师)智能体负责根据用户查询生成搜索计划。 创建2个子任务,这些子任务一起提供对主题的全面覆盖。重点关注不同的方面、观点或信息来源。 在这个系统提示中,有很多部分都需要仔细考虑,为规划智能体提供精确的上下文,使其能够有效地执行任务。 这不仅仅是设计一个简单的提示或指令,而是需要反复试验,并提供重要的上下文,以便模型能够最佳地执行任务。 指令层面的上下文工程 指令是提供给系统的高层指示,精确告诉系统要完成什么任务。 创建2个子任务,这些子任务一起提供对主题的全面覆盖。重点关注不同的方面、观点或信息来源。
MCP提示词工程:上下文注入的艺术与科学摘要作为一名深耕AI技术领域多年的技术博主摘星,我深刻认识到提示词工程(Prompt Engineering)在现代AI系统中的核心地位,特别是在Model Context 通过系统性的理论分析和丰富的实践案例,我将为读者构建一个完整的MCP提示词工程知识体系,帮助开发者掌握这一关键技术,在AI应用开发中实现更高效、更精准的上下文管理和提示词优化,最终提升整体系统的智能化水平和用户体验质量 =2)} 请基于以上上下文信息执行任务。 延迟0-9非关键维护任务无限制表1 MCP提示词优先级分级标准2. 从MCP协议的底层机制分析到动态提示词生成的高级算法实现,从上下文长度优化的数学模型到A/B测试的统计学方法,每一个技术环节都体现了现代AI工程的精密性和科学性。
@TOC开篇引言随着自然语言处理(NLP)技术的发展,模型对上下文的理解能力变得越来越重要。传统的Transformer模型由于其自注意力机制的复杂度限制,通常只能处理几千个Token的上下文。 本文将探讨如何在工程上实现百万Token的上下文窗口,并分析其中的实际瓶颈。 稀疏注意力机制原理传统Transformer模型的自注意力机制的时间复杂度为O(n^2),这在处理百万Token时是不可接受的。 总结实现百万Token上下文窗口的工程挑战主要集中在高效的数据结构和算法、稀疏注意力机制、分块处理和并行计算以及内存优化和显存管理等方面。 总结本文深入探讨了百万 Token 上下文窗口的工程实现与实际瓶颈的相关技术,从原理到实践,从基础到进阶,希望能够帮助读者全面掌握这一技术。