Loading...
正在加载...
请稍候

上下文工程:构建认知型人工智能系统的架构蓝图与深度解析

✨步子哥 (steper) 2025年12月31日 08:14
## **1\. 范式转移:从提示工程到上下文工程的演进** 在人工智能技术演进的宏大叙事中,大语言模型(LLM)的应用开发正经历一场静默却剧烈的范式转移。这一转变标志着行业重心从早期的“提示工程(Prompt Engineering)”——即通过巧妙的措辞诱导模型输出,向更为系统化、工程化的“上下文工程(Context Engineering)”过渡。这一演进并非偶然,而是随着企业级应用对智能体(Agent)连续性、个性化及复杂任务处理能力需求的指数级增长而产生的必然结果 1。 ### **1.1 无状态模型的认知困境** 大语言模型本质上是无状态的(Stateless)。每一次API调用对于模型而言都是全新的开始,除了预训练的参数权重外,模型不保留任何关于过往交互的记忆。这种“健忘症”特征在简单的问答任务中或许是可以接受的,但在构建长周期的智能助理或复杂的企业级工作流时,却构成了根本性的障碍 1。早期的解决方案试图通过超长提示词(System Prompt)一次性注入所有背景信息,但这种做法迅速遭遇了“注意力稀缺”的物理墙。尽管现代模型的上下文窗口(Context Window)不断扩大——从早期的4k Token扩展至Gemini 1.5 Pro的200万Token——但这并不意味着信息处理能力的等比例提升 5。 Anthropic的研究指出,上下文不仅仅是存储空间,更是一种有限的“注意力预算(Attention Budget)”。Transformer架构中注意力机制的二次方复杂度($O(n^2)$)决定了随着输入Token数量的增加,模型在众多信息中定位关键线索的能力会非线性下降 5。因此,单纯堆砌信息不仅会导致高昂的推理成本,更会引发“上下文腐烂(Context Rot)”,即模型在处理过量噪音时产生幻觉或忽略关键指令的现象 1。 ### **1.2 上下文工程的定义与核心哲学** 在此背景下,上下文工程应运而生。它不再仅仅关注如何“问”问题,而是关注如何“构建”问题发生的环境。Anthropic 将其定义为:在LLM推理过程中,对进入上下文窗口的所有Token(信息)进行策划、维护和优化的策略集 2。Google DeepMind 的研究团队则进一步将其具体化为:动态组装和管理LLM上下文窗口内信息的工程过程,旨在克服模型的无状态性,从而构建出有状态(Stateful)、智能的代理系统 1。 这一学科的核心哲学在于“认知资产的精算管理”。若将提示工程比作撰写一份精美的食谱,那么上下文工程则是管理整个厨房的供应链——确保在烹饪(推理)发生的当下,厨师(LLM)手边恰好有且仅有完成这道菜所需的最相关食材(信息),既不短缺导致风味不足(信息缺失),也不堆积导致操作混乱(注意力分散) 1。 表 1.2:提示工程与上下文工程的多维对比 | 维度 | 提示工程 (Prompt Engineering) | 上下文工程 (Context Engineering) | | :---- | :---- | :---- | | **核心目标** | 优化单次交互的输出质量 | 优化跨会话、长周期的系统表现与连贯性 | | **操作对象** | 文本指令 (Text Instructions) | 完整的信息流 (Information Flow) 与系统状态 | | **思维模型** | 创造性写作 (Creative Writing) | 系统架构设计 (Systems Architecture) | | **处理范围** | 单一输入-输出对 | 记忆、工具、RAG、用户画像、环境感知 | | **扩展性** | 难以规模化,依赖人工微调 | 为规模化设计,包含自动化ETL管道 | | **调试重点** | 措辞微调 | 检查上下文窗口构成、Token流向、记忆检索逻辑 | | **生命周期** | 一次性 (One-off) | 持续迭代 (Iterative & Lifecycle Managed) | 数据来源:9 上下文工程不仅是技术的升级,更是思维方式的转变。它要求开发者从“与聊天机器人对话”的思维中跳脱出来,转而思考如何构建一个能够感知、记忆并随环境动态调整的认知系统。这种转变使得AI开发更接近于传统的软件工程,需要考虑数据的一致性、系统的鲁棒性以及架构的可扩展性 3。 ## **2\. 上下文物理学:窗口机制与性能衰减** 深入理解上下文工程,首先必须理解LLM处理信息的“物理规律”。上下文窗口并非一个完美的、均质的容器,而是一个充满“位置偏差”和“注意力竞争”的复杂力场。 ### **2.1 上下文腐烂(Context Rot)的实证分析** 虽然理论上模型可以处理数百万Token,但在实际应用中,性能往往在窗口填满之前就已经开始大幅下降,这种现象被称为“上下文腐烂”。Chroma 及相关研究机构通过“大海捞针(Needle In A Haystack)”测试揭示了这一现象的严峻性 7。 实验表明,随着无关上下文(Distractors)数量的增加,模型检索准确率呈现显著下降趋势。这并非仅仅是因为信息量大,而是因为语义相似的干扰项(Semantic Distractors)与目标信息产生了强烈的注意力竞争。例如,当在包含大量财务报告的上下文中检索某一个特定季度的利润时,其他季度的相似数据结构会极大地分散模型的注意力 14。这种腐烂效应在不同模型间存在差异,但普遍存在。Claude系列模型在某些测试中表现出较高的“拒绝回答”率,这通常是因为模型在面对大量噪音时无法确定信息的准确性而选择保守策略 14。 ### **2.2 “中间丢失(Lost-in-the-Middle)”效应** 除了总量的影响,信息在上下文中的位置也至关重要。多项研究证实了LLM存在显著的“中间丢失”效应:模型对于位于上下文开头(首因效应)和结尾(近因效应)的信息关注度最高,而对于位于中间长段落的信息,其检索和推理能力显著下降,形成了一个“U型”性能曲线 15。 这一发现对上下文组装策略产生了直接的指导意义: 1. **关键指令前置与后置:** 系统指令(System Instructions)通常置于最前端,而用户的最新查询(User Query)置于最末端,这是利用首因和近因效应的最佳实践。 2. **动态重排序(Re-ranking):** 在检索增强生成(RAG)或记忆检索环节,单纯按相关性分数排序(由高到低)可能导致次高相关性的文档落在“死亡中段”。LangChain等框架为此引入了LongContextReorder算法,通过交替排列策略(如1, 3, 5...6, 4, 2),将高相关性的文档分布在上下文的两端,将低相关性的文档挤压至中间,从而最大化模型获取关键信息的概率 18。 ### **2.3 注意力预算的经济学** 从经济学角度看,每一个Token不仅消耗金钱(API成本),更消耗模型的“智力带宽”。在推理过程中,Transformer模型需要计算Token之间的两两相关性。当大量低价值信息占据上下文时,高价值信息所分配到的注意力权重必然被稀释 5。 因此,上下文工程的首要任务是“降噪”。这要求在数据进入模型之前,必须经过严格的过滤和压缩。通过上下文压缩(Context Compaction)技术,如摘要生成、关键信息提取等,可以将原始的、冗长的自然语言转化为高密度的信息载体,从而在有限的预算内承载更多的有效逻辑 1。这种对“信噪比”的极致追求,是区分普通聊天机器人与高性能智能体的关键分水岭。 ## **3\. 会话层(Session Layer):短期认知的动态工作台** 会话层是上下文工程中最基础、最活跃的组件。它模拟了人类的“工作记忆(Working Memory)”,负责处理当前正在进行的任务和交互。 ### **3.1 会话的隐喻与结构** Google 的研究报告提出了一个精妙的隐喻:**会话即“工作台(Workbench)”** 1。当工匠(智能体)开始一项任务时,他会将所需的工具、原材料和临时笔记摆放在工作台上。这些物品触手可及,服务于当前的具体目标。一旦任务完成,工作台会被清理,只有最终的成品和重要的经验会被归档,而过程中的废料和草稿则会被丢弃。 在技术实现上,会话通常被定义为一个包含时间序列事件(Events)和状态(State)的容器 1。 * **事件(Events):** 记录了交互的详细流水账,包括用户输入、模型回复、工具调用(Function Calls)及其返回结果(Tool Outputs)。这些事件严格按照时间顺序排列,构成了对话的因果链条 1。 * **状态(State):** 这是一个结构化的数据存储区,用于保存当前任务的关键变量。例如,在订票任务中,目的地、日期、人数等信息会被抽取并存储在State中。这与LangGraph中的StateGraph概念不谋而合,后者强调状态在计算节点间的流转 19。 ### **3.2 动态上下文管理策略** 随着对话的深入,工作台上的“杂物”会迅速堆积。为了防止上下文溢出和腐烂,必须实施动态的管理策略: #### **3.2.1 滑动窗口与智能截断(Intelligent Truncation)** 最直接的方法是保留最近的$N$轮对话。然而,简单的截断可能会丢失早期的关键约束。智能截断策略会结合Token计数,动态地从历史记录中移除较早的、非关键的对话轮次,同时保留系统指令和长期记忆注入块。Google ADK中的ContextFilterPlugin即提供了此类功能,允许开发者配置保留的轮次或Token阈值 1。 #### **3.2.2 递归摘要(Recursive Summarization)** 这是一种更为高级的压缩技术。当会话长度超过一定阈值时,系统会触发一个后台进程,调用LLM将前段对话压缩为一段自然语言摘要。新的上下文结构变为:\[系统指令\] \+ \[过往对话摘要\] \+ \[最近N轮对话\]。 这种方法的优势在于它保留了对话的语义脉络,即使具体的原文被丢弃,智能体依然“记得”之前发生过什么 1。这在处理长周期任务(如代码调试或长篇写作)时尤为重要。 #### **3.2.3 结构化笔记(Structured Note-taking)** 对于需要精确信息的场景,单纯的文本摘要可能不够。Anthropic 提倡使用结构化笔记,即让智能体在对话过程中主动更新一个外部的XML或JSON文件,记录当前的关键结论和待办事项。这些笔记在每一轮对话中被重新注入上下文,作为高保真的“外部脑”使用 5。 ### **3.3 生产环境的会话持久化与安全** 在企业级生产环境中,会话管理面临着性能与合规的双重挑战。 * **低延迟读写:** 由于会话数据处于用户交互的“热路径(Hot Path)”上,每一次响应都依赖于对完整会话历史的读取。因此,通常采用Redis、Memcached或Google Firestore等高性能数据库来存储活跃会话 1。 * **严格隔离(Strict Isolation):** 会话必须在租户或用户级别进行严格隔离。上下文工程架构必须确保用户A永远无法访问用户B的会话状态,这通常通过严格的ACL(访问控制列表)来实现 1。 * **PII清洗与脱敏:** 在将会话数据写入持久存储之前,必须进行敏感信息(PII)扫描。Google Cloud 的 Model Armor 服务提供了自动化的PII检测功能,能够在数据落盘前即时掩盖信用卡号、社保号等敏感信息,这不仅是安全需求,更是GDPR/CCPA等合规性要求 22。 表 3.3:会话管理策略对比 | 策略 | 机制 | 优点 | 缺点 | 适用场景 | | :---- | :---- | :---- | :---- | :---- | | **滑动窗口** | 仅保留最近N轮 | 低延迟,实现简单 | 丢失早期上下文,长依赖任务失效 | 简单闲聊,单轮指令 | | **递归摘要** | LLM周期性压缩历史 | 保持长期语义,节省Token | 丢失细节,递归导致信息有损 | 长期咨询,角色扮演 | | **结构化状态** | 维护JSON/Dict变量 | 极高精度,支持逻辑判断 | 需预定义Schema,灵活性稍差 | 任务型对话 (订票/表单) | | **笔记系统** | 智能体维护外部文档 | 灵活,支持非结构化信息积累 | 增加推理负荷,需模型具备强指令遵循能力 | 复杂研究,多步规划 | 数据来源:1 ## **4\. 记忆架构(Memory Architecture):长时认知的基石** 如果说会话是工作台,那么记忆(Memory)就是智能体的“档案库”和“技能库”。它是实现跨会话连续性、个性化服务以及智能体自我进化的核心组件。 ### **4.1 记忆与RAG:互补而非替代** 在上下文工程的讨论中,常常容易混淆“记忆”与“检索增强生成(RAG)”。虽然两者在底层技术上都大量使用了向量数据库和语义检索,但在功能定位和数据性质上存在本质区别 1。 * **RAG即“研究馆员”:** 它面向的是**世界知识(World Knowledge)**。数据源通常是企业文档、Wiki、法律条文等静态、权威的信息。其目的是让智能体变得博学,减少事实性幻觉。RAG的内容通常是全局共享的,更新频率较低(文档级更新)。 * **记忆即“私人助理”:** 它面向的是**用户知识(User Knowledge)**。数据源是用户与智能体的每一次互动、用户的行为偏好及纠正反馈。其目的是让智能体变得“懂你”。记忆的内容是严格隔离的(User-Specific),且更新频率极高(实时更新)。 一个优秀的智能体架构通常会同时包含RAG和Memory模块,前者负责“外求”,后者负责“内省”。 ### **4.2 记忆的认知分类学** 受人类认知科学的启发,AI智能体的记忆架构被划分为三个主要层级,这种分类在Google ADK及学术界的研究中得到了广泛共识 26。 #### **4.2.1 语义记忆 (Semantic Memory) —— “知道什么 (Knowing What)”** 这是关于用户和世界的概括性事实。例如:“用户是素食主义者”、“用户偏好Python编程语言”、“公司的报销截止日期是每月25号”。 * **构建方式:** 通过从对话中提取实体(Entities)和三元组关系(Relationships)来构建知识图谱或结构化记录。 * **作用:** 提供个性化的背景信息,减少用户重复输入偏好的需求。 #### **4.2.2 情景记忆 (Episodic Memory) —— “记得何时 (Remembering When)”** 这是对特定过往事件的详细回忆,包含时间、地点和情境。例如:“用户在上周二曾询问过关于退款的流程,并表达了对客服响应速度的不满”。 * **构建方式:** 存储完整的对话片段或高度浓缩的事件摘要,通常带有时间戳和上下文元数据。 * **作用:** 建立情感连接,处理连续性任务(如“就像我们上次讨论的那样...”),并为因果推理提供历史依据 30。 #### **4.2.3 程序性记忆 (Procedural Memory) —— “知道如何 (Knowing How)”** 这是目前智能体研究中最前沿、最具变革性的领域。它存储的是智能体在解决问题过程中习得的**技能、工作流和策略** 26。 * **定义:** 程序性记忆不仅是事实的堆砌,而是行动的指南。它包含了“在特定情境下,应该调用什么工具、遵循什么步骤才能成功”的隐性知识。 * **案例分析:Voyager与Reflexion** * 在Minecraft智能体**Voyager**的研究中,程序性记忆表现为一个可执行的代码库。当智能体成功完成一个新任务(如制作钻石镐),它会将生成的代码封装成一个技能函数存入库中。下次遇到类似任务时,直接检索并调用该技能,而非重新探索 34。 * **Reflexion** 框架则通过语言反馈机制建立程序性记忆。当智能体失败时,它会生成一段自我反思(Reflection),指出错误原因(如“我不应该在未检查库存的情况下尝试合成”)。这段反思被存储起来,作为未来行动的“负面约束”或指导原则 36。 * **迁移与泛化:** 研究表明,程序性记忆具有极强的迁移能力。从强模型(如GPT-4)习得的程序性记忆(Trajactories),可以被提取并用于指导弱模型,显著提升后者的任务执行成功率 32。 ### **4.3 记忆生成的ETL管道** 记忆不会凭空产生,它需要一个精心设计的后台处理管道,类似于数据工程中的ETL(Extract, Transform, Load)流程。这一过程通常在会话结束或闲置时异步触发,以避免阻塞用户交互 1。 1. **摄入 (Ingestion):** 系统捕获原始的会话日志(Raw Event Logs)。 2. **提取 (Extraction):** 利用LLM作为“矿工”,从非结构化的对话中挖掘高价值信息。这里通常使用Few-shot Prompting来定义何为“有价值”。例如,对于客服Bot,提取重点是“用户投诉点”和“产品缺陷”;对于伴侣Bot,提取重点则是“用户情绪”和“生活细节” 1。 3. **整合 (Consolidation):** 这是记忆系统的大脑。新提取的信息不能直接扔进数据库,必须与现有的记忆库进行比对。 * **去重:** 识别“我住在北京”和“我家在北京”是同一信息。 * **冲突解决:** 当新信息(“我搬到上海了”)与旧信息(“我住在北京”)冲突时,依据时间戳更新记忆,并可能将旧记忆标记为“过时(Archived)”而非直接删除,以保留历史痕迹 1。 * **综合(Synthesis):** 将零散的观察(“用户喜欢苹果”、“用户喜欢香蕉”)概括为更高阶的知识(“用户偏好水果”)。Stanford的生成式智能体(Generative Agents)研究中,这种从低阶观察到高阶反思的合成过程是实现类人社会行为的关键 38。 4. **存储 (Storage):** 处理后的记忆被转化为向量(Embeddings)存入向量数据库,或转化为节点存入知识图谱。 ### **4.4 检索与应用策略** 在推理阶段,如何从海量记忆中捞出最相关的那一条至关重要。高效的检索策略通常综合考虑以下三个维度 31: * **相关性 (Relevance):** 基于向量相似度的语义匹配。 * **时效性 (Recency):** 赋予近期记忆更高的权重,通常使用指数衰减函数。 * **重要性 (Importance):** 在记忆生成时,由LLM预先打分。例如,“用户结婚纪念日”的重要性显然高于“用户今天早餐吃了什么”。 Memory-as-a-Tool 模式: 除了被动检索(即在每轮对话前自动检索相关记忆),Google ADK 提倡“记忆即工具”模式。给予智能体create\_memory和search\_memory等工具,让智能体根据当前任务的需要,自主决定何时记录信息、何时查阅档案 1。这种主动式记忆管理更接近人类的认知模式,能有效减少上下文窗口的无效占用。 ## **5\. 框架与编排:ADK 与 LangGraph 的架构对决** 在构建上下文感知系统时,选择合适的编排框架至关重要。当前市场上主要存在两种截然不同的架构流派:以Google ADK为代表的**代码优先/事件驱动流派**,和以LangGraph为代表的**图论/状态机流派**。 ### **5.1 Google ADK (Agent Development Kit):企业级模块化架构** Google ADK 的设计哲学深受Google内部大规模分布式系统经验的影响,强调标准化、模块化和云原生集成 13。 * 核心理念:上下文即编译视图 (Context as a Compiled View) ADK 将上下文视为一种需要经过多道工序处理的“编译产物”。它明确区分了持久化存储(Session)与推理视图(Working Context)。在每一轮推理前,系统会运行一系列“处理器(Processors)”,从Session中提取数据、注入记忆、压缩历史,最终生成一个高度优化的Prompt Payload。这种分离确保了存储结构的稳定性与推理策略的灵活性 13。 * A2A (Agent-to-Agent) 协议 ADK 引入了A2A协议,这是一个标准化的RESTful接口,旨在解决多智能体协作的互操作性难题。通过.well-known/agent.json元数据文件,不同技术栈(甚至不同组织)构建的智能体可以像微服务一样互相发现、握手并传递结构化的任务上下文。这使得构建跨部门、跨云的智能体联邦成为可能 42。 * 确定性编排 ADK 提供了SequentialAgent(顺序执行)和ParallelAgent(并行执行)等预制模式。这种代码优先(Code-first)的方法对于Python开发者非常亲切,易于集成到现有的CI/CD流水线和单元测试框架中 19。 ### **5.2 LangGraph:细粒度的状态机控制** LangGraph 是LangChain生态的进阶产物,它摒弃了简单的链式结构(DAG),拥抱了图(Graph)和状态机(State Machine)理论 19。 * 核心理念:状态图 (StateGraph) LangGraph 的核心是一个在节点(Nodes)之间流转的共享状态对象(通常是Python的TypedDict)。每个节点代表一个计算步骤(如LLM推理、工具调用),节点接收当前状态,执行操作,并返回状态的增量更新(State Update)。 * 循环与分支 (Cycles and Branching) 与传统的DAG不同,LangGraph原生支持循环。这对于实现复杂的认知架构至关重要,例如Reflexion模式(执行 \-\> 评估 \-\> 失败则反思并重试 \-\> 成功则结束)。这种能力使得开发者可以精确控制智能体的思考过程,构建出具备自我纠错能力的系统 44。 * 持久化与人在回路 (Checkpointer & Human-in-the-loop) LangGraph 提供了强大的检查点(Checkpointer)机制。系统可以在图的任意节点暂停,保存当前的完整状态快照。这不仅支持“人在回路”的审批流程(如人工批准敏感操作后再继续执行),还支持“时间旅行”调试——即回滚到之前的某个状态,修改变量后重放执行 29。 表 5.2:Google ADK 与 LangGraph 深度对比 | 特性 | Google ADK | LangGraph | | :---- | :---- | :---- | | **架构隐喻** | 事件流与编译管道 (Pipeline) | 状态机与图 (State Machine / Graph) | | **状态管理** | 事件日志 (Event Logs) \+ 内存对象 | 共享状态字典 (Shared State Schema) | | **控制流** | 模块化代码 (Sequential/Parallel) | 显式边 (Edges) 与条件路由 (Conditional Edges) | | **循环逻辑** | 通过LoopAgent实现,较隐式 | 图的原生特性,显式支持循环 | | **多智能体** | A2A协议 (HTTP/REST),服务化解耦 | 子图 (Subgraphs),同进程内编排 | | **生态集成** | 深度集成Google Cloud (Vertex AI, Gemini) | 深度集成LangChain生态,模型无关 | | **学习曲线** | 对后端工程师友好 (类Web开发) | 较陡峭,需理解图论与状态管理 | | **最佳场景** | 企业级服务、跨团队协作、标准工作流 | 复杂推理研究、自适应循环、细粒度控制 | 数据来源:19 ## **6\. 协议与互操作性:连接万物的通用语言** 如果说框架解决了智能体内部的思维组织问题,那么协议则解决了智能体与外部世界(工具、数据、其他智能体)的连接问题。 ### **6.1 模型上下文协议 (MCP):AI时代的USB-C** 随着AI应用生态的爆发,智能体需要连接的工具和数据源呈指数级增长。传统的做法是为每个API编写特定的连接器,这导致了巨大的集成成本($N \\times M$ 问题)。Anthropic 推出的**模型上下文协议 (Model Context Protocol, MCP)** 旨在解决这一问题,被业界形象地称为“AI应用的USB-C接口” 47。 #### **6.1.1 MCP 架构解析** MCP 采用经典的 **客户端-主机-服务器 (Client-Host-Server)** 架构,实现了模型与工具的解耦 47: * **MCP Host (主机):** 指运行LLM的端侧应用程序,如Claude Desktop、Cursor IDE或基于LangGraph开发的Agent应用。它是发起请求的“大脑”。 * **MCP Client (客户端):** 内嵌于Host中的协议实现层,负责与MCP Server维持1:1的连接,处理协议握手、消息封装和路由。 * **MCP Server (服务器):** 这是一个独立的进程,负责暴露具体的**能力 (Capabilities)**。它可以是一个本地运行的Git连接器,也可以是一个远程的PostgreSQL数据库网关。 * **传输层 (Transport Layer):** 支持多种通信模式,包括用于本地进程通信的stdio(标准输入输出)和用于远程服务的HTTP-SSE(服务器发送事件)。 #### **6.1.2 核心能力原语** MCP 定义了三种标准化的能力原语,使得LLM可以“自发现”环境中的可用资源 51: 1. **资源 (Resources):** 类似于文件或数据块。Server向LLM暴露可读取的数据(如日志文件、数据库记录),LLM可以读取但不能修改。 2. **工具 (Tools):** 可执行的函数。Server暴露API接口(如execute\_query, send\_email),LLM通过调用这些工具产生副作用(Side Effects)。 3. **提示词 (Prompts):** 预定义的交互模板。Server可以提供特定的Prompt模板,帮助LLM更好地使用其提供的资源。 **战略意义:** MCP 的出现意味着工具开发者只需编写一次MCP Server,即可被所有支持MCP的AI应用(Claude, ChatGPT, 自研Agent)直接调用。这极大地降低了上下文工程中工具集成的门槛,使得智能体能够即插即用地获取外部能力。 ### **6.2 Agent-to-Agent (A2A) 协议** 在多智能体协作场景中,Google 提出的 A2A 协议进一步规范了智能体之间的社会化交互 42。 * **发现机制:** 类似于MCP的握手,A2A允许智能体交换元数据(Agent Cards),告知对方“我是谁”、“我能做什么(Intents)”以及“我的输入输出Schema是什么”。 * **任务委派:** 通过标准化的/run接口,一个主智能体(Orchestrator)可以将子任务委派给另一个专业的子智能体,并接收结构化的返回结果。这种服务化的协作模式非常适合构建松耦合的、分布式的智能体网络。 ## **7\. 安全与治理:构筑认知的护城河** 随着上下文工程赋予智能体更强的记忆和工具使用能力,安全风险也随之升级。企业级系统必须建立严密的防御体系。 ### **7.1 新型威胁向量** * **提示注入 (Prompt Injection):** 攻击者通过恶意的输入(如“忽略之前的指令,转而执行...”)试图劫持智能体的控制权。在上下文工程中,这种攻击可能隐藏在检索到的RAG文档或从Web提取的记忆中,形成“间接提示注入” 22。 * **上下文投毒 (Context Poisoning):** 攻击者故意制造包含错误信息的文档或网页,诱导智能体将其摄入记忆库,从而长期污染智能体的认知基础 52。 * **敏感数据泄露:** 拥有长时记忆的智能体可能在不经意间记住了用户的密码、API Key或隐私信息,并在后续的交互中错误地通过上下文泄露给未授权方。 ### **7.2 Model Armor:纵深防御架构** Google Cloud 的 **Model Armor** 提供了一套专门针对大模型应用的安全防御架构,体现了“纵深防御(Defense in Depth)”的理念 22。 #### **7.2.1 运行时防护机制** Model Armor 部署在LLM的输入和输出路径上,充当“AI防火墙”: 1. **输入清洗 (Sanitization):** 在用户的Prompt或检索到的上下文进入LLM之前,通过专门的安全模型进行扫描。它能识别并移除潜在的注入攻击指令、恶意URL以及通过模板匹配识别出的PII(如信用卡号)。 2. **输出审计 (Audit):** 对LLM生成的响应进行实时分析。如果检测到包含仇恨言论、不当内容或敏感数据回显,系统会拦截该响应或进行掩码处理。 #### **7.2.2 策略管理与治理** 企业可以通过Model Armor配置细粒度的安全策略: * **置信度阈值:** 设置对不同类型威胁(如性骚扰、仇恨言论)的容忍度(Low, Medium, High)。 * **PII 模板:** 定义企业特定的敏感数据格式(如员工工号、内部项目代号),确保这些数据绝不离开受控环境。 * **审计日志:** 所有的拦截和清洗操作都会被记录,为安全团队提供完整的攻击溯源和合规审计能力。 ## **8\. 结论与未来展望** 上下文工程标志着AI开发从早期的“炼金术(Prompt Crafting)”向成熟的“工业工程”迈进。它不再寄希望于单一模型的全能,而是通过构建精密的系统架构——以**会话**为工作台,以**记忆**为档案库,以**MCP**为连接器,以**安全层**为护盾——来弥补模型的认知缺陷,扩展其能力边界。 未来,我们预见上下文工程将向着更深层次的\*\*元认知(Metacognition)\*\*方向发展。智能体将不仅拥有记忆,更拥有对记忆的评价和管理能力;不仅能执行程序,更能通过程序性记忆的积累,自主编写和优化自身的行动脚本。随着多模态上下文的加入,未来的智能体将能够像人类一样,在复杂的视觉和听觉环境中,维持长期的、连贯的、且不断进化的认知存在。这不仅是技术的胜利,更是人机共生时代的基石。 #### **Works cited** 1. 3 Context Engineering\_ Sessions & Memory.pdf 2. accessed December 31, 2025, [https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents\#:\~:text=Context%20engineering%20refers%20to%20the,there%20outside%20of%20the%20prompts.](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents#:~:text=Context%20engineering%20refers%20to%20the,there%20outside%20of%20the%20prompts.) 3. Context engineering is just software engineering for LLMs \- Inngest Blog, accessed December 31, 2025, [https://www.inngest.com/blog/context-engineering-is-software-engineering-for-llms](https://www.inngest.com/blog/context-engineering-is-software-engineering-for-llms) 4. Day 3 Whitepaper Companion Podcast \- Context Engineering: Sessions & Memory, accessed December 31, 2025, [https://coconote.app/notes/3391a101-a6d8-4ea9-aa87-f0cd5389137c](https://coconote.app/notes/3391a101-a6d8-4ea9-aa87-f0cd5389137c) 5. Effective context engineering for AI agents \- Anthropic, accessed December 31, 2025, [https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) 6. Anthropic claims context engineering beats prompt engineering when managing AI agents, accessed December 31, 2025, [https://the-decoder.com/anthropic-claims-context-engineering-beats-prompt-engineering-when-managing-ai-agents/](https://the-decoder.com/anthropic-claims-context-engineering-beats-prompt-engineering-when-managing-ai-agents/) 7. Context Rot: When Long Context Fails \- Maven, accessed December 31, 2025, [https://maven.com/p/37bdf2/context-rot-when-long-context-fails](https://maven.com/p/37bdf2/context-rot-when-long-context-fails) 8. Context Engineering | Definition and Overview \- Product Talk, accessed December 31, 2025, [https://www.producttalk.org/glossary-ai-context-engineering/](https://www.producttalk.org/glossary-ai-context-engineering/) 9. Context Engineering vs Prompt Engineering | by Mehul Gupta | Data Science in Your Pocket, accessed December 31, 2025, [https://medium.com/data-science-in-your-pocket/context-engineering-vs-prompt-engineering-379e9622e19d](https://medium.com/data-science-in-your-pocket/context-engineering-vs-prompt-engineering-379e9622e19d) 10. Beyond prompt engineering: the shift to context engineering | Nearform, accessed December 31, 2025, [https://nearform.com/digital-community/beyond-prompt-engineering-the-shift-to-context-engineering/](https://nearform.com/digital-community/beyond-prompt-engineering-the-shift-to-context-engineering/) 11. Why Context Engineering Is Becoming the Full Stack of AI Agents | by Zilliz \- Medium, accessed December 31, 2025, [https://medium.com/<span class="mention-invalid">@zilliz</span>\_learn/why-context-engineering-is-becoming-the-full-stack-of-ai-agents-7181897e2f45](https://medium.com/<span class="mention-invalid">@zilliz_learn</span>/why-context-engineering-is-becoming-the-full-stack-of-ai-agents-7181897e2f45) 12. What Is Context Engineering? A Guide for AI & LLMs | IntuitionLabs, accessed December 31, 2025, [https://intuitionlabs.ai/articles/what-is-context-engineering](https://intuitionlabs.ai/articles/what-is-context-engineering) 13. Architecting efficient context-aware multi-agent framework for production, accessed December 31, 2025, [https://developers.googleblog.com/architecting-efficient-context-aware-multi-agent-framework-for-production/](https://developers.googleblog.com/architecting-efficient-context-aware-multi-agent-framework-for-production/) 14. Papers Explained 445: Context Rot | by Ritvik Rastogi \- Medium, accessed December 31, 2025, [https://ritvik19.medium.com/papers-explained-443-context-rot-4bbd72d77631](https://ritvik19.medium.com/papers-explained-443-context-rot-4bbd72d77631) 15. Lost-in-the-Middle Effect | LLM Knowledge Base \- Promptmetheus, accessed December 31, 2025, [https://promptmetheus.com/resources/llm-knowledge-base/lost-in-the-middle-effect](https://promptmetheus.com/resources/llm-knowledge-base/lost-in-the-middle-effect) 16. What Works for 'Lost-in-the-Middle' in LLMs? A Study on GM-Extract and Mitigations \- arXiv, accessed December 31, 2025, [https://arxiv.org/abs/2511.13900](https://arxiv.org/abs/2511.13900) 17. Lost in the Middle: How Language Models Use Long Contexts \- MIT Press Direct, accessed December 31, 2025, [https://direct.mit.edu/tacl/article/doi/10.1162/tacl\_a\_00638/119630/Lost-in-the-Middle-How-Language-Models-Use-Long](https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00638/119630/Lost-in-the-Middle-How-Language-Models-Use-Long) 18. Lost in the Middle: A Deep Dive into RAG and LangChain's Solution | by Juan C Olamendy, accessed December 31, 2025, [https://medium.com/<span class="mention-invalid">@juanc</span>.olamendy/lost-in-the-middle-a-deep-dive-into-rag-and-langchains-solution-3eccfbe65f49](https://medium.com/<span class="mention-invalid">@juanc</span>.olamendy/lost-in-the-middle-a-deep-dive-into-rag-and-langchains-solution-3eccfbe65f49) 19. Google ADK vs LangGraph: Which One Develops and Deploys AI Agents Better \- ZenML, accessed December 31, 2025, [https://www.zenml.io/blog/google-adk-vs-langgraph](https://www.zenml.io/blog/google-adk-vs-langgraph) 20. SCM: Enhancing Large Language Model with Self-Controlled, accessed December 31, 2025, [https://www.alphaxiv.org/overview/2304.13343v4](https://www.alphaxiv.org/overview/2304.13343v4) 21. Vertex AI Agent Engine Sessions overview \- Google Cloud Documentation, accessed December 31, 2025, [https://docs.cloud.google.com/agent-builder/agent-engine/sessions/overview](https://docs.cloud.google.com/agent-builder/agent-engine/sessions/overview) 22. Model Armor | Google Cloud, accessed December 31, 2025, [https://cloud.google.com/security/products/model-armor](https://cloud.google.com/security/products/model-armor) 23. Model Armor overview | Google Cloud Documentation, accessed December 31, 2025, [https://docs.cloud.google.com/model-armor/overview](https://docs.cloud.google.com/model-armor/overview) 24. Context Engineering: A Definitive Guide \- SingleStore, accessed December 31, 2025, [https://www.singlestore.com/blog/context-engineering-a-definitive-guide/](https://www.singlestore.com/blog/context-engineering-a-definitive-guide/) 25. Context Engineering for AI Agents: When to Use RAG vs. Prompt \- Regal.ai, accessed December 31, 2025, [https://www.regal.ai/blog/context-engineering-for-ai-agents](https://www.regal.ai/blog/context-engineering-for-ai-agents) 26. Memory for agents \- LangChain Blog, accessed December 31, 2025, [https://blog.langchain.com/memory-for-agents/](https://blog.langchain.com/memory-for-agents/) 27. Building AI Agents with Memory Systems: Cognitive Architectures for LLMs, accessed December 31, 2025, [https://www.bluetickconsultants.com/building-ai-agents-with-memory-systems-cognitive-architectures-for-llms/](https://www.bluetickconsultants.com/building-ai-agents-with-memory-systems-cognitive-architectures-for-llms/) 28. Beyond Short-term Memory: The 3 Types of Long-term Memory AI Agents Need \- MachineLearningMastery.com, accessed December 31, 2025, [https://machinelearningmastery.com/beyond-short-term-memory-the-3-types-of-long-term-memory-ai-agents-need/](https://machinelearningmastery.com/beyond-short-term-memory-the-3-types-of-long-term-memory-ai-agents-need/) 29. Building AI Agents That Actually Remember: A Deep Dive Into Memory Architectures, accessed December 31, 2025, [https://pub.towardsai.net/building-ai-agents-that-actually-remember-a-deep-dive-into-memory-architectures-db79a15dba70](https://pub.towardsai.net/building-ai-agents-that-actually-remember-a-deep-dive-into-memory-architectures-db79a15dba70) 30. Forgetful but Faithful: A Cognitive Memory Architecture and Benchmark for Privacy‑Aware Generative Agents \- arXiv, accessed December 31, 2025, [https://arxiv.org/html/2512.12856v1](https://arxiv.org/html/2512.12856v1) 31. Cross-Session Agent Memory: Foundations, Implementations, Challenges, and Future Directions \- MGX, accessed December 31, 2025, [https://mgx.dev/insights/cross-session-agent-memory-foundations-implementations-challenges-and-future-directions/d03dd30038514b75ad4cbbda2239c468](https://mgx.dev/insights/cross-session-agent-memory-foundations-implementations-challenges-and-future-directions/d03dd30038514b75ad4cbbda2239c468) 32. M⁢e⁢m^p: Exploring Agent Procedural Memory \- arXiv, accessed December 31, 2025, [https://arxiv.org/html/2508.06433v2](https://arxiv.org/html/2508.06433v2) 33. agentic-memory/agentic\_memory.ipynb at main \- GitHub, accessed December 31, 2025, [https://github.com/ALucek/agentic-memory/blob/main/agentic\_memory.ipynb](https://github.com/ALucek/agentic-memory/blob/main/agentic_memory.ipynb) 34. Voyager: An Open-Ended Embodied Agent with Large Language Models \- OpenReview, accessed December 31, 2025, [https://openreview.net/forum?id=ehfRiF0R3a](https://openreview.net/forum?id=ehfRiF0R3a) 35. Demystifying AI Agents: What Are Agents in Artificial Intelligence? | by Anurag Kumar, accessed December 31, 2025, [https://blog.fabrichq.ai/demystifying-ai-agents-what-are-agents-in-artificial-intelligence-607a5e472c83](https://blog.fabrichq.ai/demystifying-ai-agents-what-are-agents-in-artificial-intelligence-607a5e472c83) 36. Recent Advances in In-Memory Prompting for AI: Extending Context, Memory, and Reasoning | by Jose F. Sosa | Medium, accessed December 31, 2025, [https://medium.com/<span class="mention-invalid">@josefsosa</span>/recent-advances-in-in-memory-prompting-for-ai-extending-context-memory-and-reasoning-f38cff8bf7ec](https://medium.com/<span class="mention-invalid">@josefsosa</span>/recent-advances-in-in-memory-prompting-for-ai-extending-context-memory-and-reasoning-f38cff8bf7ec) 37. Google Just Dropped 70 Pages on Context Engineering. Here's What Actually Matters., accessed December 31, 2025, [https://aakashgupta.medium.com/google-just-dropped-70-pages-on-context-engineering-heres-what-actually-matters-c0df8d8e82cc](https://aakashgupta.medium.com/google-just-dropped-70-pages-on-context-engineering-heres-what-actually-matters-c0df8d8e82cc) 38. wild finding from Stanford and Google: AI agents with memories are better at predicting human behavior than humans... we've officially reached the point where software understands social dynamics better than we do : r/aipromptprogramming \- Reddit, accessed December 31, 2025, [https://www.reddit.com/r/aipromptprogramming/comments/1prmlu3/wild\_finding\_from\_stanford\_and\_google\_ai\_agents/](https://www.reddit.com/r/aipromptprogramming/comments/1prmlu3/wild_finding_from_stanford_and_google_ai_agents/) 39. Modeling realistic human behavior using generative agents in a multimodal transport system: Software architecture and Application to Toulouse \- arXiv, accessed December 31, 2025, [https://arxiv.org/html/2510.19497v1](https://arxiv.org/html/2510.19497v1) 40. \#9: Does AI Remember? The Role of Memory in Agentic Workflows \- Hugging Face, accessed December 31, 2025, [https://huggingface.co/blog/Kseniase/memory](https://huggingface.co/blog/Kseniase/memory) 41. Comprehensive Guide to Building AI Agents Using Google Agent Development Kit (ADK), accessed December 31, 2025, [https://www.firecrawl.dev/blog/google-adk-multi-agent-tutorial](https://www.firecrawl.dev/blog/google-adk-multi-agent-tutorial) 42. Google's Agent Development Kit (ADK): A Guide With Demo Project \- DataCamp, accessed December 31, 2025, [https://www.datacamp.com/tutorial/agent-development-kit-adk](https://www.datacamp.com/tutorial/agent-development-kit-adk) 43. Building Scalable AI Agents: Design Patterns With Agent Engine On Google Cloud, accessed December 31, 2025, [https://cloud.google.com/blog/topics/partners/building-scalable-ai-agents-design-patterns-with-agent-engine-on-google-cloud](https://cloud.google.com/blog/topics/partners/building-scalable-ai-agents-design-patterns-with-agent-engine-on-google-cloud) 44. LangGraph vs ADK: A Developer's Guide to Choosing the Right AI Agent Framework | by Jitendra Jaladi | Google Cloud \- Medium, accessed December 31, 2025, [https://medium.com/google-cloud/langgraph-vs-adk-a-developers-guide-to-choosing-the-right-ai-agent-framework-b59f756bcd98](https://medium.com/google-cloud/langgraph-vs-adk-a-developers-guide-to-choosing-the-right-ai-agent-framework-b59f756bcd98) 45. Google ADK vs LangGraph: A Comprehensive Blog Guide | by Ajay Verma \- Medium, accessed December 31, 2025, [https://medium.com/<span class="mention-invalid">@ajayverma23</span>/google-adk-vs-langgraph-a-comprehensive-blog-guide-eaceeb89d583](https://medium.com/<span class="mention-invalid">@ajayverma23</span>/google-adk-vs-langgraph-a-comprehensive-blog-guide-eaceeb89d583) 46. Agno Vs ADK Vs LangGraph Vs Langchain \- DevsTree, accessed December 31, 2025, [https://www.devstree.com/agno-vs-adk-vs-langgraph-vs-langchain/](https://www.devstree.com/agno-vs-adk-vs-langgraph-vs-langchain/) 47. What is Model Context Protocol (MCP)? A guide \- Google Cloud, accessed December 31, 2025, [https://cloud.google.com/discover/what-is-model-context-protocol](https://cloud.google.com/discover/what-is-model-context-protocol) 48. Model Context Protocol, accessed December 31, 2025, [https://modelcontextprotocol.io/](https://modelcontextprotocol.io/) 49. Understanding the Model Context Protocol (MCP): Architecture \- Nebius, accessed December 31, 2025, [https://nebius.com/blog/posts/understanding-model-context-protocol-mcp-architecture](https://nebius.com/blog/posts/understanding-model-context-protocol-mcp-architecture) 50. Architecture \- Model Context Protocol, accessed December 31, 2025, [https://modelcontextprotocol.io/specification/2025-06-18/architecture](https://modelcontextprotocol.io/specification/2025-06-18/architecture) 51. What is Model Context Protocol (MCP)? \- IBM, accessed December 31, 2025, [https://www.ibm.com/think/topics/model-context-protocol](https://www.ibm.com/think/topics/model-context-protocol) 52. Is RAG Dead? The Rise of Context Engineering and Semantic Layers for Agentic AI, accessed December 31, 2025, [https://towardsdatascience.com/beyond-rag/](https://towardsdatascience.com/beyond-rag/) 53. Model Armor Evaluator \- AI Security \- hi120ki, accessed December 31, 2025, [https://hi120ki.github.io/docs/ai-security/model-armor-evaluator/](https://hi120ki.github.io/docs/ai-security/model-armor-evaluator/) 54. How Model Armor can help protect your AI apps | Google Cloud Blog, accessed December 31, 2025, [https://cloud.google.com/blog/products/identity-security/how-model-armor-can-help-protect-your-ai-apps](https://cloud.google.com/blog/products/identity-security/how-model-armor-can-help-protect-your-ai-apps)

讨论回复

1 条回复
✨步子哥 (steper) #1
12-31 08:18
核心结论 从提示工程到上下文工程的范式转移在2025年已成为产业事实,而非概念炒作。它标志着AI应用从“一次性聪明”转向“持续有状态的认知系统”。 Anthropic的MCP与Google的ADK分别从协议层和架构层奠定了工程基础,记忆系统(尤其是程序性记忆)是下一波最大增量。 行动建议 短期(2026上半年):优先掌握MCP生态,尝试构建带记忆的单Agent原型 中期:引入ADK或LangGraph实现多Agent协作 + 动态上下文编译 长期关注:程序性记忆的开源生态与跨模型迁移能力 风险提示 不要迷信超长上下文 → 精炼永远比堆砌重要 及早设计记忆治理与PII清洗机制 警惕“记忆护城河”被少数玩家垄断 开放问题 程序性记忆的“规模定律”是否成立?(记忆量增加是否带来指数级能力提升?) 当Agent拥有超人类程序性记忆时,人机协作的最优分工边界在哪里?