【开云发布】-决定 AI Agent 成败的关键:上下文工程(Context Engineering)深度解析
2026 15:27:50.01 15:27:50.14 15:27:50

于 AI 开发范畴,有一个年夜大都开发者不肯面临的“残暴本相”:你的AI Agent(智能体)体现糟糕糕,往往不是由于你选错了模子(Model),而是由于你没有构建好准确的上下文(Context)。

当所有人都于痴迷在 GPT-四、Claude 或者 Gemini 哪一个模子更强时,真实的决胜局发生于一个被年夜大都人轻忽的范畴:信息流的架构设计。这就是上下文工程(Context Engineering),它正悄然成为 AI 开发中最要害的焦点能力。

给一个LLM(年夜语言模子)配备最强的年夜脑但提供糟糕糕的上下文,就像是招聘了一个被关于密屋里的天才——没有窗户,没有互联网,只能经由过程门缝递进来的纸条获守信息。不管他多智慧,于这类前提下也只能“瞽者摸象”。

甚么是上下文工程?

上下文工程不单单是写出更好的 Prompt(提醒词),它是对于 AI 体系网络、构造、存储、检索及利用信息以举行决议计划的体系性设计。它是缭绕并驱动 AI 的整个信息架构。

操作体系类比

正如Andrej Karpathy出色的比方,LLM 就像是一种新型的操作体系:

LLM= CPU(处置惩罚单位)Context Window(上下文窗口)= RAM(事情内存)External Knowledge(外部常识)= Hard Drive(持久存储/硬盘)Tools & APIs= Peripherals(外设/东西)

上下文工程的焦点本能机能,就是决议将哪些数据于甚么时刻加载到 AI 的“事情内存”(RAM)中。

从Prompt Engineering到 Context Engineering 的演进

Prompt Engineering 曾经合用在简朴使命(如翻译、择要),但于繁杂的真实场景中,它碰到了瓶颈:

缺少多轮对于话的影象能力没法处置惩罚及时外部数据难以应答长流程的事情流

底子的区分于在:Prompt Engineering 问的是“我该怎么说?(what should I say?)”;而 Context Engineering 问的是“体系应该知道甚么?何时知道?信息怎样随时间流动?”

上下文工程的四年夜支柱 (The Four Pillars)

构建强盛的 Agent 需要于如下四个维度举行邃密化工程设计:

1. 写入上下文(Memory Management)

挑战:AI 每一次对于话都处在“掉忆”状况,而使命需要联贯性。

解决方案:构建自力在上下文窗口的外部影象体系。

要害技能:

Scratchpads(底稿本):于使命履行时期的姑且条记。Memory Stores(影象库):持久长期化存储。State Tracking(状况追踪):于多步事情流中维护进度。

业界实例:Anthropic 的研究 Agent 利用了一个“Memory”组件,LeadResearcher(首席研究员)会于将使命拆解为子使命前生存规划。这避免了上下文窗口被沉没,并确保要害规划信息患上以长期化。

最好实践:实行分层影象(Hierarchical Memory):

事情影象(Working memory):近来几轮对于话,当即上下文。会话影象(Session memory):当前完备的对于话汗青。持久影象(Long-term memory):用户偏好、汗青数据。2. 选择上下文(Retrieval Strategy)

挑战:你拥有海量数据,但模子的上下文窗口(纵然是 200K token)是有限的。

解决方案:智能检索体系,只抓取当下最相干的信息。

选择的要害因子:

语义相干性:与当前使命的相似度。时效性:信息是新鲜的还有是过时的?频率:该信息被利用的频率。依靠性:当前步调是否依靠在先前的信息?

进阶模式 —— GraphRAG: 传统的 RAG 将文档视为扁平的切片(Chunks),而 GraphRAG 将常识构造为图谱,明确建模实体与瓜葛。这使患上模子可以或许超过毗连的信息举行更繁杂的推理。

3. 压缩上下文(Abstraction)

挑战:上下文随对于话呈指数级增加。

解决方案:于保留语义的条件下举行智能压缩。

常见压缩计谋对于比:

计谋

长处

错误谬误

示例

A) 天然语言择要

易实现,人类可读

丢掉布局及细节瓜葛

"用户已往10条动静扣问了价格及安全问题。"

B) 布局化提取

保留瓜葛,撑持查询

需要设计 Schema

JSON 格局存储​​{"topic": "pricing", "sentiment": "cautious"}​​

C) 向量嵌入

高扩大性,搜刮高效

人类不成读

将对于话转为 1536 维向量

数据左证:Google 的研究注解,上下文压缩技能可以于削减 50% 内存占用的同时维持相应质量,甚至于某些“年夜海捞针”测试中经由过程避免“迷掉于中间(lost in the middle)”问题来提高正确性。

4. 断绝上下文(Separation of Concerns)

挑战:当所有信息混于一个上下文中时,信息会越界,致使杂乱。

解决方案:利用多个专用 Agent 举行战略性断绝。

实现模式:

A) 子智能体(Sub-Agents):每一个 Agent 拥有自力的上下文窗口。Planner(计划者):存眷宏不雅计谋。Executor(履行者):存眷细节实现。Reviewer(审查者):存眷质量节制。B) 沙盒化(Sandboxing):将年夜型输出(如代码、数据)存储于外部,仅于主上下文中保留援用。例如:​​Code saved to analysis.py​​。C) 基在东西的断绝:让搜刮东西治理查询汗青,数据东西维护自身状况。四种必需防止的掉败模式

理解掉败的缘故原由与构建准确的体系一样主要。

上下文投毒(Context Poisoning)征象:过错或者幻觉信息进入上下文并像病毒同样扩散。预防:入库前验证要害事实;引入置信度评分;于要害决议计划引入“人机回环(Human-in-the-loop)”。上下文混合(Context Confusion)征象:模子被无关信息滋扰。例如扣问“苹果手机”,但检索出的果园信息致使模子最先会商农业。预防:实行相干性评分;利用重排序(Re-ranking)算法;明确的分开符。上下文漂移(Context Drift)征象:初期的过错测验考试依然留于上下文中,滋扰了终极成果。预防:上下文剪枝(Context Pruning)。断根中间推理步调,只保留终极结论。研究显示此技能可晋升 54% 的基准机能。上下文腐臭(Context Rot)征象:跟着上下文窗口变年夜,模子的回召能力降落(近似在于嘈杂房间里回忆3小时前听到的德律风号码)。预防:将上下文视为稀缺资源;实行自顺应上下文窗口;不要无脑堆砌信息。机能倍增器:KV Cache 优化

这是年夜大都开发者纰漏的细节:上下文的布局直接影响成本及速率,差异可达 10 倍以上。

甚么是 KV Cache?

LLM 于处置惩罚文本时管帐算 Token 的 Key 及 Value 张量。这些计较很是昂贵。KV Caching 存储这些计较成果,防止对于反复文本举行从头计较。

成本与速率影响

以 Anthropic Claude 的订价为例:

Cached input tokens:美金0.30/ millionUncached input tokens:美金3.00/ million这是 10 倍的成本差异!要害优化法则连结前缀 Prompt 不变(Keep Prefix Prompts Stable)BAD:​​[Timestamp: 2025-01-06] System Prompt...​​(时间戳于最前,致使后续所有缓存掉效)GOOD:​​System Prompt... [Timestamp: 2025-01-06]​​(将变化部门放于末了)仅追加之下文(Append-Only Context):永远不要编纂或者从头排序已往的内容,只于末尾追加。一致的序列化:对于象转文本时,连结键值挨次及格局的一致性。实战:构建你的第一个上下文工程化 Agent

如下是一个构建客户撑持 Agent 的架构示例。

1. 架构组件代码示例

# 1. 短时间影象 (Session Context)# 存储当前对于话流session_context = { "conversation_history": [], "current_intent": "product_inquiry", "user_sentiment": "neutral"}# 2. 持久影象 (User Profile)# 跨会话长期化user_profile = { "previous_issues": ["billing_question", "product_setup"], "preferences": {"co妹妹unication_style": "detailed"}, "purchase_history": ["Premium Plan", "API Access"]}# 3. 检索体系 (Knowledge Base)# 向量数据库 + 语义搜刮 + 缓存相应2. 上下文组装计谋(Token 预算示例)

对于在每个 Query,咱们需要一个钱打二十四个结:

System prompt: 500 tokens (固定,使用 KV Cache)Current query + context: 2,000 tokens (焦点)Retrieved knowledge: 3,000 tokens (相干度最高的信息)Conversation history: 1,500 tokens (近来几轮)Total: 7,000 tokens

这类设计远低在 200K 的上限,但为了速率及正确性举行了极致优化。

下一个前沿:跨体系上下文同享

跟着企业部署多个专用 Agent,孤岛问题日趋凸显。

场景:发卖 Agent 知道客户对于价格敏感,但撑持 Agent 不知道,致使办事体验割裂。解决方案:上下文适配器(Adapters):各自自力,经由过程转换器交互。尺度上下文和谈(Standard Context Protocols):如 Anthropic 提出的 **MCP(Model Context Protocol)**,提供尺度化的 API 实现即插即用。结语

上下文工程的结局不是为了拥有更繁杂的技巧,而是构建隐形的基础举措措施。就像咱们阅读网页时不会去思索 TCP/IP 和谈同样,将来的开发者可能不需要手动治理上下文,体系将主动、智能地处置惩罚这一切。

但于将来 3-5 年内,上下文工程将是区别“玩具级 Demo”与“出产级 AI 体系”的焦点分水岭。

本文转载自​​​​Halo咯咯​​​ 作者:基咯咯

©著作权归作者所有,如需转载,请注明来由,不然将究查法令责任-本文由开云·Kaiyun(中国)官方网站-科技股份有限公司-www.kaiyun.com(kaiyun.com)技术部原创提供,更多官方资讯请认准本站(dysp777.com)。


万物互联 开云智造