- 综合排序
- 最热优先
- 最新优先
- 来自专栏MixLab科技+设计实验室
上下文工程Context Engineering
最近，又多了个新的概念，上下文工程，这是从提示工程发展而来的，因为随着LLM上下文的增长以及Agent能力的提升，写好一句prompt已经远远不够了，我们需要为AI Agent处理动态的上下文信息，处理得越好 毕竟底层LLM都是大家就能接入的，而上下文工程，那就非常考验架构和工程能力了。 以下是上下文工程必须要了解的知识点，欢迎查看： # Prompt 工程的局限 Prompt Engineering 是一门设计和优化提示（prompts）的技术，旨在有效利用大型语言模型（LLMs）来执行各种应用和研究任务 - 它被 Cognition 公司称为“构建 AI 代理工程师的首要任务”。Anthropic 也强调，代理在数百轮对话中需要精细的上下文管理策略。 2. 知识（Knowledge）：包括事实、记忆等信息。 3. 工具（Tools）：可供 LLM 使用的工具定义，以及来自工具调用的反馈。
77710编辑于 2026-03-24 从提示词工程到上下文工程
Anthropic公司上个月29日发布了一篇长文，关于智能体上下文工程，针对这篇文章去阅读学习了下，顺带做个总结。 如下图所示提示词工程和上下文工程的对比，提示词是引导大模型去如何思考得到我们想要的信息，而上下文工程将智能体中的大模型输出的信息进行整合提炼或持久化管理，这二者不是相互替代的关系，而是相辅相成的关系。 02 — 上下文工程对智能体的重要性 文中提到了上下文会“腐烂”的观点。 2、智能体工具调用：高效token和高效智能体行为 工具允许智能体与其环境进行操作，并在工作时引入新的、额外的上下文。 2、结构化笔记（Structured note-taking） 结构化记笔记，或智能体记忆，是智能体定期将笔记写入持久化到上下文窗口外内存的技术。这些笔记会在以后的时间点被拉回上下文窗口。
50210编辑于 2026-06-22- 来自专栏机器学习与统计学
上下文工程比提示词工程更重要，6种上下文管理策略
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
1.3K10编辑于 2025-07-27 图解AI： 什么是上下文工程？
上下文工程干的就是把这一段“前置检索+加工+整合”做成系统性、可配置、可观测的流水线。 业务信息源杂且不断变动，靠手动写 Prompt 很快就失控； 2. 上下文长度有限，堆砌太多历史对话反而稀释重点； 3. 用户意图会跨多轮对话变化，静态 Prompt 跟不上节奏。 于是工程师开始把注意力从“怎么写得高级”转向“如何把当下必要的信息精准注入模型窗口”。这就是上下文工程的兴起。 一套成熟的上下文工程系统通常包含四个可观测的模块。 1. 工程师用统一的消息总线把这些“原始素材”先聚后滤，最终生成一个最小必要的信息包。 2. 工具编排（Tool Orchestration） 大模型需要“调用”而非“背诵”。 面向2025之后的系统架构，上下文工程极可能成为一条独立赛道。
60010编辑于 2026-06-22- 来自专栏MixLab科技+设计实验室
从上下文工程到驾驭工程
缰绳 （架构约束）引导它走正确的路，马车（上下文工程）提供舒适的承载空间，车上的镜子（反馈循环）随时照出它的状态，而车夫（熵管理）则负责清理它奔跑时留下的杂乱痕迹。 谁第一次喊出了这个名字 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
15.6K96编辑于 2026-03-25 上下文工程的精髓在于删除？
Philipp Schmid是Hugging Face的机器学习工程师。 有损摘要：上下文超过12.8万token时，让AI总结早期对话。但有个小技巧：保留最近3轮的完整对话，让模型保持"手感"。 2. 具体做法： 简单任务（比如"搜索文档中的某个词"）：给代理单独的上下文，只告诉它要干什么 复杂任务（比如调试，需要看历史错误）：才共享完整上下文 3. 先把工程做好。 设置预警线：别等到真正卡死才优化，提前监控token使用量。 用简单指标验证效果：代码能跑吗？文件创建成功了吗？别搞复杂的评分系统。 删除的艺术 Manus团队最大的收获是学会了删除。 博文：https://www.philschmid.de/context-engineering-part-2
15510编辑于 2026-06-23- 来自专栏周末程序猿
谈谈上下文工程（Context Engineering）
大模型发展这两年，应用型 AI 的焦点一直在 “提示工程”（prompt engineering），但随着更强大的大语言模型（LLM）走向多轮、长时间的自主行动，一个更关键的概念开始走到台前：上下文工程 什么是上下文工程 上下文，是在一次 LLM 推断过程中被纳入采样的全部 token 集合，上下文工程的核心任务，是在模型固有约束下，优化这些 token 的效用，以更稳定地获得预期结果。 要驾驭 LLM，往往需要 “在上下文中思考”：把模型任意时刻能读取到的一切状态视为整体，并评估这些状态可能产生的行为。 2. 上下文工程 vs 提示工程 提示工程：编写和组织模型指令以获得最佳输出，通常聚焦系统提示如何写得清晰、有效。 “上下文工程” 的艺术就在于：在有限的上下文窗口中，选取最有价值的子集。 3. 为什么 “上下文工程“ 对强代理至关重要？
1.6K12编辑于 2025-11-13 上下文工程的崛起：提示工程已是过去式
这正是上下文工程的核心。 大多数情况下，当一个智能体表现不可靠时，其根本原因并非模型本身的能力不足，而在于我们未能向其传递完成任务所需的上下文、指令和工具。 因此，上下文工程正迅速成为 AI 工程师所能掌握的最关键技能。 在前面文章里也多次提过上下文工程的内容，但缺少系统化理论化的定义。 近日，Langchain创始人也撰文《The rise of "context engineering"》探讨了这一问题，借此机会让我们更深入了解“上下文工程”。 什么是上下文工程？ 上下文工程与提示词工程的区别 为何行业焦点正从“提示词工程”转向“上下文工程”？早期，开发者更专注于通过巧妙的措辞来“诱导”模型给出更好的答案。 但随着应用复杂度的提升，一个共识逐渐形成：向 AI 提供完整、结构化的上下文，其重要性远超任何“魔法般”的措辞。 我们可以认为，提示词工程是上下文工程的一个子集。
24110编辑于 2026-06-23- 来自专栏机器之心
提示词工程、RAG之后，LangChain：上下文工程开始火了！
至于重要性，下面这张图很好地概括了上下文工程与提示词工程、RAG 等的关系。 在传统的提示工程中，开发者通常侧重于精心设计提示语，以期得到更好的答案。 如今，提供完整且结构化的上下文信息比任何巧妙的提示词更为重要。 上下文工程就是为此诞生的。 上下文工程是构建动态系统，以正确的格式提供合适的信息和工具，从而使得 LLM 能够合理地完成任务。 因此，上下文工程正在成为 AI 工程师可以发展的最重要技能。 什么是上下文工程？ 上下文工程是指构建动态系统，以合适的格式提供准确的信息和工具，使 LLM 能够合理完成任务。 上下文工程是一个系统。 上下文工程与提示工程有何不同？ 为什么要从提示工程到上下文工程转变？早期，开发者专注于巧妙地给出提示以引导模型给出更好的答案。 但随着应用变得更加复杂，现在越来越明显的是，提供完整且结构化的上下文比任何巧妙的措辞更为重要。 我们可以将提示工程视为上下文工程的一个子集。即使你拥有所有的上下文，如何在提示中组装它仍然至关重要。
93710编辑于 2025-06-26 RAG 工程里的上下文剪枝：如何减少 68% 的上下文
在助手服务中，检索到的chunk占了单次查询成本的2/3，这个开销甚至超过了生成回答、对话历史和systemprompt的成本总和。 不用分数截断上下文的话，还有一种做法是位置截断。只保留前5个chunk，或是把保留范围从前15个缩减到前10个。 2分：Tangential。同领域或术语接近，但无具体贡献。1分：Unrelated。基本无关。在这套评分标准中，4分的设置很重要。 Agent在执行单次任务时，要调用多个工具，每次工具调用的结果都会持续累加到上下文中。如果检索返回的内容更短、更干净，就能为后续的工具输出、推理步骤和中间状态留出更多的上下文空间。 如果你的系统基本符合这些条件，那么在Reranker和Generator之间加入一层轻量剪枝，就具有非常实在的工程价值。
22011编辑于 2026-07-15上下文AI与搜索平台集成以扩展精准上下文工程
没有正确的上下文，AI模型难以保证相关性，常常产生不准确或“幻觉”的响应。上下文工程旨在解决一个根本问题：在正确的时间以正确的格式提供正确的信息，使AI代理能够执行复杂的、特定于用例的任务。 Contextual AI平台由检索增强生成（RAG）的先驱创立，提供了一个全面的上下文工程平台，用于快速构建开箱即用、具有卓越准确性的AI代理。 随着代理和AI系统变得越来越复杂，上下文工程确保它们能够在正确的时间访问并推理正确的信息。 通过将某中心的混合搜索和向量数据库与Contextual AI的上下文工程平台相结合，开发者获得了一个功能丰富的统一体验，可以在准确的企业上下文中落地他们的代理，而无需增加复杂性。 这一联合解决方案使开发者能够：实现前所未有的准确性：通过使用Contextual AI的上下文工程平台和某中心的混合搜索，代理可以检索并推理最复杂的企业数据，包括财务报告、法律文件和工程规范。
32610编辑于 2025-12-20上下文工程是什么？从提示词工程到上下文，一文讲透 AI 不跑偏
这问题不在提示词没写清楚，而在上下文没管好。这篇把AI回答质量的底层逻辑讲透：提示词、提示词工程、上下文、上下文工程，一层层拆开，再聊聊怎么让AI自己记笔记、把上下文变短。 看这张图就明白了——第1轮发"系统提示词+问题1"，第2轮就得发"系统提示词+全部历史+问题2"，历史越长，每次打包的东西越多：重发历史的代价有三：按token计费，累积成本接近二次方增长；对话越长，每轮越慢越贵 四、上下文工程：管理的不是一句话，是AI眼前的一切上下文工程管的是"AI看到什么"——系统性地设计每一次请求进入上下文窗口的全部信息，这是提示词工程之后的下一个战场。 2）压缩（Compaction）：把上下文变短对话接近上下文窗口上限时，把历史交给模型总结成摘要，用"摘要+最近内容"重启上下文，接着干活。ClaudeCode里一条/compact命令就能触发。 你有哪些上下文工程的小技巧？
26310编辑于 2026-08-16如何高效执行智能体上下文工程
然而，随着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等于多少？"""这将有助于模型更好地理解示例，通常能进一步提高模型性能。
40210编辑于 2025-12-17Agentic上下文工程真能杀死LLM微调？
斯坦福大学最新提出的主动式上下文工程 Agentic Context Engineering（ACE）技术，正在挑战这一看似理所当然的做法，它让AI第一次拥有了类似人类的"经验积累"能力。
28210编辑于 2026-02-02Claude 新模型的上下文工程：从堆规则到设计上下文
当我们给Agent发消息时，当前这一次输入的Prompt，只占模型实际读到的上下文中的很小一部分。 上下文工程和写Prompt有一个结构性差异，那就是Prompt面向单次任务，而上下文会被大量请求反复使用。要复用就意味着上下文不能写得太具体，不然在下一个任务中它会变成噪音甚至干扰。 上下文工程的六个变化从规则堆叠到模型判断早期使用ClaudeCode时，我们需要告诉模型大量“不要做什么”：不要随便删文件，不要生成多余文档，不要加太多注释。 分层设计上下文把上面的变化落到具体实现上，每一层的职责要重新划分：SystemPrompt在整个上下文体系中，SystemPrompt和具体产品的关系是最紧密的。 对于ClaudeCode或任何Agent系统来说，好的上下文工程很少来自持续添加的内容。更多时候，我们要做的是删除那些不必要的信息，让真正重要的部分更容易被模型找到。
26210编辑于 2026-07-31Alexa上下文语音识别的工程实现解析
Alexa上下文语音识别的工程实现自动语音识别（ASR）是将语音信号转换为文本的技术。某中心的语音系统为每种语言维护统一的核心ASR模型，但其AI团队通过实时适配用户上下文来提升识别精度。 上下文感知的技术实现设备上下文利用 带屏幕的设备可显示查询应答列表，当处理后续指令时，ASR模型会优先识别列表中的条目。 规模化工程挑战 以确认型追问场景为例（如用户说"打电话给Meg"后需选择联系人），上下文感知使ASR错误率降低26%。 ）的短文本数据表：独立存储加密的原始语句和上下文数据避免频繁加解密操作，仅在实际需要生成上下文向量时解密实时计算窗口优化利用系统响应时间窗口执行上下文向量计算麦克风重启指令（expect-speech） 系统设计支持离线实验新上下文信号，持续优化模型效果。技术团队强调：将实验室模型转化为海量用户服务需要严谨的系统设计，某中心工程团队通过科学与工程的紧密协作，实现了上下文机器学习在亿级规模下的稳定运行。
38511编辑于 2025-08-28- 来自专栏AgenticAI
别再靠运气写 Prompt，上下文工程实战手册！
不过我觉得，“上下文工程”的基础更扎实一些。 1. 什么是上下文工程？ img 可以这样理解： Prompting（提示词）：是你直接让模型去做某件事。 2. 实际运作方式 这不是一个完美的逐步方法，但下面是一个在实践中效果不错的大致流程。 2.1. 先弄清楚你真正想要什么 在问模型任何问题之前，先明确你期待的结果。不要这样： “写一个食谱。” 上下文工程版本： [角色] 你是一名中年软件工程师，给同行写博客。 [受众] 有经验但对 LLM 持谨慎态度的开发者。 [语气示例] “是啊，Copilot 会写测试。 其实你可能已经在做上下文工程了，如果你曾经： 给提示词加过示例 改写提示词以调整语气 描述过目标受众 删除过多余文字以节省空间 ——那你就在做上下文工程。 译者注：所以我觉得所谓的上下文工程，如果只是本文来看的话，和提示词工程有什么区别呢？和我之前高赞原创的似乎没什么区别？ 那么你的看法是什么呢？评论区留下你的见解。 敲黑板！
1.7K10编辑于 2025-08-11 - 来自专栏大前端修炼手册
上下文工程与提示词工程：拆解 OpenClaw 是如何「喂养」大模型的
真正拉开差距的，是上下文工程（Context Engineering）和提示词工程（Prompt Engineering）。 一、上下文工程：Agent 开发最被低估的工程问题 什么是上下文窗口管理 LLM 没有持久记忆，它只能看到被塞进上下文窗口里的内容。你塞什么，它就基于什么推理。 上下文工程要解决的核心问题是：在有限的 token 预算里，把最有价值的信息放进去，把噪声排出去。 写在最后 上下文工程和提示词工程这两件事，本质上都是在做同一件事：为模型的每次推理构建一个信息质量尽可能高的输入。这件事没有银弹，但有工程原则可循——分层、模块化、按需加载、明确优先级。 下一步值得探索的方向：Agent 的上下文工程在多 Agent 协作场景下会变得更复杂——多个 Agent 之间怎么共享上下文、传递状态、避免信息重复注入？这是下一阶段值得深挖的问题。
1.5K10编辑于 2026-04-02 - 来自专栏Elastic Stack专栏
Shell 工具不是上下文工程的灵丹妙药
Shell 工具不是上下文工程的灵丹妙药 代理最重要的工具之一是用于构建自身上下文的搜索工具。 最近，LlamaIndex 和 LangChain 的帖子引发了一场讨论：对于上下文工程来说，shell 工具和文件系统是否足够？ 不幸的是，这场讨论很快偏离了主题，变成了文件系统与数据库的比较。 例如，Claude Code [1] 和 Cursor [2] 允许代理根据任务的实际需要，在不同的搜索工具之间选择，甚至将它们组合起来进行链式查询。 上下文工程中有哪些搜索接口？ 总结 文件系统与数据库的争论分散了工程师们应该关注的问题：代理需要什么样的搜索接口来构建自己的上下文？ 答案很可能是，不只一种。 2. Cursor: 文档. 语义与代理搜索 (2026)。 3. Harrison Chase (LangChain). 我们如何构建 Agent Builder 的记忆系统 (2026)。 4.
25110编辑于 2026-04-01 - 来自专栏FunTester
Cline 上下文工程核心思想与实践指南
Cline 是一个上下文工程工具，旨在通过自动化的方式帮助用户整理指令、工具、环境、文件预览和历史记录，并动态管理这些状态。 它的核心目标是：始终只保留“最重要”的上下文，确保每一步都聚焦于关键内容，从而提升任务的效率和成功率。 Cline 的上下文工程哲学可以概括为主动整理、压缩和交接上下文。 • /smol 或 /compact：在调试或探索阶段，任务上下文可能会迅速膨胀，导致信息过载。此时可以使用 /smol 或 /compact 命令对上下文进行压缩。 当日志信息过多导致上下文膨胀时，使用 /smol 命令智能压缩上下文，提取关键信息，避免信息过载。在定位问题根因后，使用 /newtask 开启新任务环境，专注于修复工作。 总结 Cline 是一款专注于上下文工程的工具，旨在通过自动化整理指令、工具、环境和历史记录，帮助用户聚焦关键内容，提升任务效率。其核心理念是主动整理、压缩和交接上下文，确保信息传递的完整性和准确性。
35110编辑于 2026-06-17
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号