- 综合排序
- 最热优先
- 最新优先
- 来自专栏MixLab科技+设计实验室
上下文工程Context Engineering
最近，又多了个新的概念，上下文工程，这是从提示工程发展而来的，因为随着LLM上下文的增长以及Agent能力的提升，写好一句prompt已经远远不够了，我们需要为AI Agent处理动态的上下文信息，处理得越好 毕竟底层LLM都是大家就能接入的，而上下文工程，那就非常考验架构和工程能力了。 以下是上下文工程必须要了解的知识点，欢迎查看： # Prompt 工程的局限 Prompt Engineering 是一门设计和优化提示（prompts）的技术，旨在有效利用大型语言模型（LLMs）来执行各种应用和研究任务 - 它被 Cognition 公司称为“构建 AI 代理工程师的首要任务”。Anthropic 也强调，代理在数百轮对话中需要精细的上下文管理策略。 3. 工具（Tools）：可供 LLM 使用的工具定义，以及来自工具调用的反馈。LLM 并非直接调用工具，而是输出它想要调用的工具和参数，然后由应用程序实际执行调用并将结果放回上下文窗口。 4.
77710编辑于 2026-03-24 从提示词工程到上下文工程
Anthropic公司上个月29日发布了一篇长文，关于智能体上下文工程，针对这篇文章去阅读学习了下，顺带做个总结。 如下图所示提示词工程和上下文工程的对比，提示词是引导大模型去如何思考得到我们想要的信息，而上下文工程将智能体中的大模型输出的信息进行整合提炼或持久化管理，这二者不是相互替代的关系，而是相辅相成的关系。 02 — 上下文工程对智能体的重要性 文中提到了上下文会“腐烂”的观点。 3、示例（few-shot）：典型优于边缘 用 3 个覆盖 80% 主流场景的示例，比 20 条“罕见 corner case”更能让模型举一反三。 3、子智能体架构（Sub-agent architectures） 子智能体架构提供了绕过上下文限制的另一种方法。
50210编辑于 2026-06-22- 来自专栏机器学习与统计学
上下文工程比提示词工程更重要，6种上下文管理策略
slide=id.p#slide=id.p 1、从提示词工程到上下文工程 2、“上下文工程” 体现了当下所面临的各类挑战 上下文污染（Context Poisoning） 示例：Gemini在玩《宝可梦 3、Andrej Karpathy：上下文工程是一门精细的艺术与科学 +1 for "context engineering" over "prompt engineering". 而在每一个工业级的 LLM 应用中，上下文工程是填充上下文窗口以提供恰到好处的信息的艺术和科学，以便为下一步提供正确的背景信息。 借助文件系统（例如 todo.md）进行计划制定与进度追踪（参考：Manus[3]).。 通过文件系统读写包含大量 token 的上下文（参考：Manus[4]）。 3、检索上下文 结合多种检索方法与重排序技术（参考: Varun’s take[13] from Windsurf).
1.3K10编辑于 2025-07-27 图解AI： 什么是上下文工程？
上下文工程干的就是把这一段“前置检索+加工+整合”做成系统性、可配置、可观测的流水线。 上下文长度有限，堆砌太多历史对话反而稀释重点； 3. 用户意图会跨多轮对话变化，静态 Prompt 跟不上节奏。 于是工程师开始把注意力从“怎么写得高级”转向“如何把当下必要的信息精准注入模型窗口”。 这就是上下文工程的兴起。 一套成熟的上下文工程系统通常包含四个可观测的模块。 1. 动态信息流 信息不再是一次性塞进 Prompt，而是按场景、按角色按需组装。 上下文工程把可被调用的接口包装成 JSON Schema，附带枚举、必填字段、示例返回值，让模型一次看懂。同时把工具反馈的结果再次切分、提炼，避免把整屏 SQL LOG 扔回去给用户。 3. 面向2025之后的系统架构，上下文工程极可能成为一条独立赛道。
60010编辑于 2026-06-22- 来自专栏MixLab科技+设计实验室
从上下文工程到驾驭工程
缰绳 （架构约束）引导它走正确的路，马车（上下文工程）提供舒适的承载空间，车上的镜子（反馈循环）随时照出它的状态，而车夫（熵管理）则负责清理它奔跑时留下的杂乱痕迹。 Harness 到底在做什么 根据 OpenAI 官方报告的描述，Harness 由三个核心类别组成： 第一层：Context Engineering（上下文工程）。 不仅仅是给 Agent 一份文档，而是持续增强的知识库，加上动态上下文——比如可观测性数据、浏览器导航状态。 Hashline 格式：文件内容会以类似 42:a3f| let x = compute(); 的形式呈现。这里的 42:a3f 就是哈希锚点，它由行号和内容哈希组成。 LangChain Terminal Bench 2.0 Results - blockchain.news. [2] Mitchell Hashimoto - My AI Adoption Journey. [3]
15.6K96编辑于 2026-03-25 上下文工程的精髓在于删除？
Philipp Schmid是Hugging Face的机器学习工程师。 上下文会腐败，就像食物会变质 先说个基本事实：AI模型的上下文窗口会"腐败"。 什么意思？就算你的模型号称能处理100万个token，实际上塞到25万个左右，性能就开始下滑了。 有损摘要：上下文超过12.8万token时，让AI总结早期对话。但有个小技巧：保留最近3轮的完整对话，让模型保持"手感"。 2. 具体做法： 简单任务（比如"搜索文档中的某个词"）：给代理单独的上下文，只告诉它要干什么 复杂任务（比如调试，需要看历史错误）：才共享完整上下文 3. 先把工程做好。 设置预警线：别等到真正卡死才优化，提前监控token使用量。 用简单指标验证效果：代码能跑吗？文件创建成功了吗？别搞复杂的评分系统。 删除的艺术 Manus团队最大的收获是学会了删除。
15510编辑于 2026-06-23- 来自专栏周末程序猿
谈谈上下文工程（Context Engineering）
大模型发展这两年，应用型 AI 的焦点一直在 “提示工程”（prompt engineering），但随着更强大的大语言模型（LLM）走向多轮、长时间的自主行动，一个更关键的概念开始走到台前：上下文工程 什么是上下文工程 上下文，是在一次 LLM 推断过程中被纳入采样的全部 token 集合，上下文工程的核心任务，是在模型固有约束下，优化这些 token 的效用，以更稳定地获得预期结果。 上下文工程 vs 提示工程 提示工程：编写和组织模型指令以获得最佳输出，通常聚焦系统提示如何写得清晰、有效。 “上下文工程” 的艺术就在于：在有限的上下文窗口中，选取最有价值的子集。 3. 为什么 “上下文工程“ 对强代理至关重要？ 这些问题需要用更好的处理方法：把上下文视为稀缺资源，并以工程化方式加以管理，是构建强大代理的基础。 4. 什么是有效上下文？
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的成本总和。 3分：Supporting。和问题相关，且对回答问题有帮助，但没有它答案大概率也能成立。2分：Tangential。同领域或术语接近，但无具体贡献。1分：Unrelated。基本无关。 设定阈值为3分，则会更保守一些，将Supporting也一并留下。这与直接使用Rerank的浮点数分数的逻辑完全不同。 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自己记笔记、把上下文变短。 Anthropic的经验是"典型优于边缘"——给3个覆盖80%主流场景的示例，比堆20条罕见cornercase更管用。示例是让AI学模式，不是让它背题。 四、上下文工程：管理的不是一句话，是AI眼前的一切上下文工程管的是"AI看到什么"——系统性地设计每一次请求进入上下文窗口的全部信息，这是提示词工程之后的下一个战场。 提示词工程和上下文工程的分工，可以这样看：维度提示词工程上下文工程管什么怎么问AI看到什么层次单次请求内的措辞整体信息环境（历史/工具/资料）状态无状态，一次一问有状态，动态组装擅长单轮任务多轮、多步自主任务失败模式措辞歧义 你有哪些上下文工程的小技巧？
26310编辑于 2026-08-16如何高效执行智能体上下文工程
然而，随着LLM能力的增强，提示工程已经演变为上下文工程：优化输入LLM的所有数据，以在复杂任务上实现最大性能。本文将深入探讨智能体上下文工程，即专门为智能体优化上下文。 具体的上下文工程技巧缩短/总结上下文工具使用在深入探讨上下文工程的具体细节之前，首先说明为什么智能体上下文工程很重要。 为什么智能体需要上下文工程现在我们知道了为什么需要智能体，但为什么智能体需要上下文工程呢？主要原因是，当LLM的上下文包含更多相关信息且噪音（不相关信息）更少时，其性能总是更好。 我们需要从LLM的上下文中移除这些噪音信息，并确保所有相关信息都存在于LLM的上下文中。具体的上下文工程技巧智能体上下文工程建立在传统上下文工程的基础之上。 然后我再把最后两位加起来得到1+2=3。答案是：30" </example><example>"120+70等于多少？" -> "为了回答用户的请求，我必须从后往前把数字加起来。我从0+0=0开始。
40210编辑于 2025-12-17- 来自专栏架构师成长之路
Go进阶(3)：上下文context
wg.Done() } func main() { wg.Add(2) // 需要开启几个goroutine就给等待组的计数器赋值为多少，这里为2 for i := 1; i < 3; Goroutine 由于没有接收到这个信号所以会继续工作； 使用 Context 同步信号：但是当我们正确地使用 context.Context 时，就可以在下层及时停掉无用的工作以减少额外资源的消耗： 3、 3) context.cancelCtx.cancel方法实现： context.cancelCtx 实现的几个接口方法也没有太多值得分析的地方，该结构体最重要的方法是 context.cancelCtx.cancel 3、valueCtx 类型：传值方法 在调用 context.WithValue 方法时，我们会涉及到 valueCtx 类型，其主要特性是涉及上下文信息传递。 而在实际的工程应用中，你会发现各大框架，例如：gin、grpc 等。他都是有自己再实现一套上下文信息的传输的二次封装，本意也是为了更好的管理和观察上下文信息。
1.4K20编辑于 2023-02-27 Agentic上下文工程真能杀死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（提示词）：是你直接让模型去做某件事。 3. 两个真实示例 img 3.1 菠萝蜜食谱 目标：一个有趣、快速的素食菠萝蜜食谱。 Prompt 版本： “给我一个菠萝蜜食谱。” 结果：安全、无聊、毫无个性。 上下文工程版本： [角色] 你是一名中年软件工程师，给同行写博客。 [受众] 有经验但对 LLM 持谨慎态度的开发者。 [语气示例] “是啊，Copilot 会写测试。 其实你可能已经在做上下文工程了，如果你曾经： 给提示词加过示例 改写提示词以调整语气 描述过目标受众 删除过多余文字以节省空间 ——那你就在做上下文工程。 译者注：所以我觉得所谓的上下文工程，如果只是本文来看的话，和提示词工程有什么区别呢？和我之前高赞原创的似乎没什么区别？ 那么你的看法是什么呢？评论区留下你的见解。 敲黑板！
1.7K10编辑于 2025-08-11 - 来自专栏大前端修炼手册
上下文工程与提示词工程：拆解 OpenClaw 是如何「喂养」大模型的
真正拉开差距的，是上下文工程（Context Engineering）和提示词工程（Prompt Engineering）。 一、上下文工程：Agent 开发最被低估的工程问题 什么是上下文窗口管理 LLM 没有持久记忆，它只能看到被塞进上下文窗口里的内容。你塞什么，它就基于什么推理。 上下文工程要解决的核心问题是：在有限的 token 预算里，把最有价值的信息放进去，把噪声排出去。 3. 四个容易踩的坑 坑一：上下文污染 工具调用的输出往往很长，全量放入上下文会污染后续推理。处理原则：工具输出超过 2000 token 时主动截断或摘要，只保留核心内容。 写在最后 上下文工程和提示词工程这两件事，本质上都是在做同一件事：为模型的每次推理构建一个信息质量尽可能高的输入。这件事没有银弹，但有工程原则可循——分层、模块化、按需加载、明确优先级。
1.5K10编辑于 2026-04-02 - 来自专栏Elastic Stack专栏
Shell 工具不是上下文工程的灵丹妙药
Shell 工具不是上下文工程的灵丹妙药 代理最重要的工具之一是用于构建自身上下文的搜索工具。 最近，LlamaIndex 和 LangChain 的帖子引发了一场讨论：对于上下文工程来说，shell 工具和文件系统是否足够？ 不幸的是，这场讨论很快偏离了主题，变成了文件系统与数据库的比较。 上下文工程中有哪些搜索接口？ 上下文可以存在于不同的位置，例如网络、本地文件系统或数据库。 总结 文件系统与数据库的争论分散了工程师们应该关注的问题：代理需要什么样的搜索接口来构建自己的上下文？ 答案很可能是，不只一种。 3. Harrison Chase (LangChain). 我们如何构建 Agent Builder 的记忆系统 (2026)。 4.
25110编辑于 2026-04-01
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号