在ChatGPT出现之后的过去几年里，我们见证了“提示词工程”（Prompt Engineering）的兴起。我们像学习一门新的语言一样，钻研如何通过精巧的“咒语”或“指令”，从大语言模型（LLM）那里获得最靠谱和惊艳的回答。这感觉就像是发现了魔法，只要念对咒语，AI 就能文思泉涌、代码飞流。
但当我们将 AI 从一个聪明的“问答盒子”变成一个真正的“工作伙伴”——一个能处理复杂任务、使用工具、与我们进行多轮深度协作的智能体（Agentic AI）时，我们发现，单靠一句句的“魔法指令”已经不够了。
我们需要的不再是孤立的问答，而是一场连贯的、有记忆的、智能的互动。我们需要的不再是仅仅给 AI 一句指令，而是为它编写一整部“情景剧本”，于是“上下文工程”（Context Engineering）就闪亮登场了。
一、为什么需要从 Prompt 走向 Context？
想象一下，你正在让一个 AI 助手帮你完成一份市场分析报告。这个任务涉及：
• 多轮对话：你需要不断与它讨论、修正方向、补充细节。 • 工具调用：AI 需要上网搜索最新的行业动态、查询公司内部的销售数据。 • 信息整合：它要能理解并整合来自外部网络、内部数据库和你们对话中的所有信息。
在这个过程中，产生的信息量是巨大的。而 AI 面临三大挑战，正是 Context Engineering 诞生的土壤。
1. 大模型的“记忆”是有限的
每个大模型都有一个“上下文窗口”（Context Window），所有输入给它的信息，包括历史对话、文档、工具返回结果，都必须塞进这个窗口里，模型才能“看到”。
问题在于，这个窗口的大小是有限的。对于一个需要分析整个代码库的编程助手，或者一个与用户聊了数十轮的客服AI，对话历史很容易就“撑爆”了这个窗口。即使没撑爆，把海量信息全部塞进去，也意味着高昂的 API 调用成本。这就像和一个记忆力不好但收费高昂的顾问开会，你不得不一遍遍重复所有背景信息。
2. 原始信息的“噪音”太大
Agentic AI 在工作时会产生大量的“中间过程”，比如调用工具后返回的复杂原始数据（如 JSON 文件）、冗长的搜索结果等。如果把这些充满“噪音”的原始信息不加处理地直接扔给模型，不仅会迅速消耗宝贵的上下文空间，还会干扰模型的“注意力”，影响它对核心任务的判断。
3. 成本之殇
即使不考虑大模型的上下文长度限制，模型调用成本也是不容回避的现实问题。对于Agentic的任务来说，底座大模型的推理能力对于任务执行的成败至关重要，至少要Premium级别的模型才可以胜任，例如Anthropic的Claude Sonnet/Opus 4系列，OpenAI的GPT-4o/4.1或o3/o4-mini，Gemini 2.5 Pro或者DeepSeek的R1/V3等模型，而这些模型的调用成本，通常是flash/mini等轻量级模型的几倍甚至十几倍。对于一次十几轮交互的Agentic任务，动辄消耗几十万甚至上百万Tokens，如果在每轮对话中都一股脑地将对话历史塞进Context Window中，且不论效果如何，其成本之高也让人望而却步。
二、从人类到AI：构建高效的信息“大脑”
回顾我们人类自身，我们的大脑并不像一个无尽的硬盘，能够不分轻重地存储和读取一切经历与信息。相反，我们的大脑运行着一个极为高效的“信息管理系统”，能够动态地编码、筛选和存取信息。这一系统不仅帮助我们记忆，还决定了我们如何感知世界并专注于任务。
工作记忆： 由大脑中的海马体驱动，工作记忆处理我们当前正在思考和操作的信息。它是一种短期的、清晰且细节丰富的信息缓存，类似于一张“临时工作台”，专注于当前任务的具体细节。
长期记忆： 长期记忆存储着我们过去的重要知识、经历和技能。这些记忆并不是零散的，而通常是以“要点”和“摘要”的形式保留下来的。只有对我们重要或经常被重复的信息，才会从工作记忆迁移到长期记忆中。
注意力机制： 这是令人类大脑高效运转的关键所在。我们的注意力机制像是一盏“聚光灯”，选择性地聚焦于当前最重要的事物，同时过滤掉无关的背景信息。在一个充满无序信息的世界中，它帮助我们避免信息超载，并维持对关键任务的专注。
外部信息的调用： 当我们需要的信息不在脑海中时，我们会利用工具去查书、上网搜索，或者通过与他人交流来填补知识空白。
大猩猩实验：注意力机制的启示
为了说明注意力机制的重要性，心理学家西蒙斯（Daniel Simons）和查布里斯（Christopher Chabris）曾设计了一项著名的实验——“隐形大猩猩实验”。在实验中，参与者被要求观看一段视频，视频中有两组篮球队员分别穿着白色和黑色的衣服，彼此传球。参与者的任务是数清白衣队员一共传了多少次球。
令人惊讶的是，尽管实验过程中一只穿着黑色大猩猩衣服的人从画面中间经过，多达一半的参与者完全没有注意到“大猩猩”的存在。这一现象被称为“无意识盲视”（inattentional blindness），深刻揭示了人类注意力机制的局限性：当我们全神贯注于某件任务时，与目标无关的信息，即使明显到荒谬程度，也可能被忽略。
大猩猩实验从认知科学的角度帮助我们理解注意力机制的核心意义——它不仅是管理信息的重要工具，更是一种保护机制，帮助我们从海量信息中过滤噪音，集中精力完成目标任务。如果没有这种选择性，我们会被无关的细节淹没，变得无所适从。然而，这种机制也表明，我们的大脑对其他信息的感知能力是有限的，专注的代价是对背景信息的遗漏。
一个优秀的人工智能系统，也需要具备类似人类大脑的信息管理能力，而不是被动地存储或处理信息。AI 的“记忆”和“注意力机制”应包括：
动态记忆管理： AI 应能够根据当前任务选择性地存储和检索信息，而非机械地扫描所有数据。
注意力模型： 类似于人类注意力机制，AI 应能够快速聚焦关键信息，过滤掉噪音，提升推理效率和准确性。
外部信息调用： AI 应当依赖丰富的外部资源，动态获取缺失或精确的信息，而不是试图将所有信息封装在内部。
这就是现代人工智能中Context Engineering的核心目标——帮助AI设计并构建一个高效的“思维架构”，像人类一样管理信息流，利用注意力机制处理复杂问题，并在广阔的信息海洋中保持清晰、专注和高效的执行力。
二、ConsoleX AI 的实践：为 AI 构建一个高效“大脑”
ConsoleX AI是一个为创造者量身定制的Agentic AI Studio，用户可以在统一的聊天界面中，利用大模型调用工具完成研究、创作、绘图、发布和分析等各种代理任务，因此不可避免的需要涉及到多轮对话以及连续的工具调用。我们面临的挑战很具体：如何在控制成本和保证性能（如首个token的响应速度）的前提下，让 AI 在长对话和复杂任务中保持高水准的表现？在 ConsoleX AI 的实践中，我们构建了一套工作记忆机制，这正是 Context Engineering 的一次企业级落地实践。
我们的答案是构建一个分层的、动态的、智能的上下文管理系统。
1. 记忆分层：信息的重要性各不相同
我们参考人脑的记忆模式，将 AI 的记忆分为不同层级，确保最有价值的信息始终处于“C位”。
• 🔥 热记忆（Hot Memory）：这是 AI 的“工作台”，存放着最近几轮的完整对话。它保证了对话的即时连贯性，让 AI 能记住“我们刚才在聊什么”。 • 🌡️ 温记忆（Warm Memory）】：对于稍早一些的对话，我们不会全部丢弃，而是由 AI 自动进行“智能压缩”，提炼出关键信息和摘要。这就像我们对昨天会议的“会议纪要”，细节少了，但核心决策和要点都在。 • ❄️ 冷记忆（Cold Memory）：对于非常久远的历史对话，系统会生成一个高度浓缩的“背景摘要”。这确保了 AI 即使在跨越数天的对话中，也能记起最核心的长期背景，保持“人设”不崩。 • ⚙️ 系统记忆（System Memory）：这是 AI 的“性格”和“本能”，包含了它的角色设定、核心指令和能力边界。这部分是永久不变的。
通过这个分层系统，AI 在构建每一次回复的上下文时，都能像拼图一样，智能地从不同层级中拾取最相关的信息碎片，组成一个高效且信息量密集的“情景剧本”。
2. 智能唤回机制：弥补压缩损失的关键
不过仅有分层压缩是不够的。温记忆和冷记忆在压缩过程中不可避免地会丢失大量细节信息，这可能导致 AI 在处理特定问题时缺乏必要的背景知识。为了解决这个问题，我们设计了一套基于记忆仓库 (Memory Vault) 的智能唤回机制：
• 语义检索引擎：我们使用向量数据库存储本组对话历史的每个片段，并通过语义向量的方式为它们建立索引。当用户提出新问题时，系统会自动分析问题的语义，并从对话历史碎片库中检索出最相关的历史片段。由于ConsoleX AI的架构托管在微软Azure云上，我们使用CosmosDB来存储对话历史的每个片段，开发者也可以使用如 Pinecone、Milvus 等向量数据库或PostgreSQL等支持向量存储的数据库用来存储对话历史片段。 • 智能检索引擎和相关性打分：当用户提出新问题时，系统会自动分析问题的语义，通过智能检索引擎从记忆仓库中检索出最相关的对话片段，并对检索结果进行相关性评分，只有得分超过一定阈值的内容才会被重新注入到当前上下文中，确保唤回的信息是高度相关的。 • 动态上下文构建：在每次 AI 生成回答前，系统会动态组装最终的上下文，这个过程包括： • 从热记忆中获取最近几轮完整对话 • 添加温记忆和冷记忆的摘要 • 根据当前问题从对话历史库中唤回相关的对话片段 • 结合系统记忆，形成一个完整的"情景剧本"
这种方法确保了 AI 既能保持对话的连贯性，又能在关键时刻"回忆起"过去的重要细节，大大提高了回答的准确性和深度。
3. 智能压缩与异步处理：高效的“后台管家”
为了让记忆系统高效运转，我们还引入了两个关键机制：
• 智能内容压缩：当 AI 的回复或工具返回的结果太长时（比如一大段代码或一个复杂的数据库查询结果），我们不会粗暴地截断它。而是会启动一个“压缩模型”（通常是一个更小、更快的 LLM），用自然语言总结出其中的核心含义。这既保留了关键信息，又大大节省了空间。 • 异步框架：所有的记忆整理、压缩、存储工作，都在“后台”悄无声息地进行。用户在前台与 AI 对话时，完全感受不到这些复杂的处理过程，保证了交互的流畅性。这就像一个勤劳的管家，在你休息时就已经把房间整理得井井有条。
4. 缓存的力量：更快更节省
我们还大量使用了缓存技术。对于那些被频繁访问的记忆或信息，会通过Redis缓存起来，把它们放在“手边”。当 AI 再次需要时，便可高速获取，极大地缩短了响应时间，提升了用户体验。
对于重复的内容，如AI的回复摘要、工具调用结果的压缩等，在ConsoleX的实践中，我们也会尽量利用缓存，避免重复压缩，这不仅可以节省压缩所需的大模型使用成本，而且由于现在国内外主流的大模型厂商都已经支持Prompt Cache机制，重复利用Redis缓存中压缩好的内容，可以提高在大模型调用过程中Cached token的命中比率，节省大模型调用的成本50%～85%。
5. 评估与迭代：科学地让“大脑”更聪明
构建这样一个复杂的记忆系统，不能凭感觉。我们很早就意识到了评估 (Evaluation) 对于构建LLM系统的重要性，并基于我们自己的评估产品EvalsOne建立了一套系统的评估方法论，具体包括：
• 建立评估基准：我们会先有一个“朴素”的版本（比如每次都传递完整的历史），作为比较的基准。 • 设计评估指标：我们关注的核心指标包括：成本节省了多少、任务成功率是否提升、用户满意度如何、检索唤回的精度如何、响应时间是否达标等。 • 反复迭代：通过对比实验和数据分析，我们不断调整记忆分层的比例、压缩算法的策略，持续优化整个系统的表现。
通过反复的迭代和调整优化，我们实现了开启“动态工作记忆”模式的情况中，在几乎不损耗响应性能和回复准确率的前提下，在十轮以上的连续对话中，平均节省Tokens成本50%以上。
三、终章：从工程师到“剧本导演”
上下文工程（Context Engineering）是一个新兴的概念，标志着我们与 AI 协作模式从生成式 AI（Generative AI）迈向代理式 AI（Agentic AI）的深刻转变。尽管对这一概念的落地和实践观点各异，但也无需将其过度复杂化，关键在于立足具体应用场景进行设计，并付诸实践。抛砖引玉，希望希望能为大家提供一些启发和思路。
1. Context Engineering不是要替代 Prompt Engineering，而是后者的自然演进。 Prompt Engineering 教会我们如何与 AI“清晰地对话”，而 Context Engineering 则在此基础上，教会我们如何与 AI“构建一个有深度、有记忆的世界”。那些关于清晰、简洁、角色扮演的提示原则，在构建高质量的上下文中依然至关重要。 2. 这是一个循序渐进的工程实践，而非一蹴而就的魔法。 并非所有应用都需要一开始就构建如此复杂的系统。应该从实际需求出发，当简单的上下文管理无法满足业务场景时，再逐步引入分层、压缩等机制。ConsoleX AI在具体的Context engineering实践过程中，也是先从最基本的记忆分层开始，再到记忆碎片的唤回，未来还将引入跨对话Session的长期记忆。 3. 评估，评估再评估！ Context Engineering 的效果好坏，必须通过数据来度量。建立科学的评估体系，并反复迭代，是确保方向正确、持续进步的唯一途径。
从 Prompt Engineer 到 Context Engineer，我们扮演的角色正在从一个“指令下达者”，转变为一个“情景剧本的导演”。我们不再是仅仅告诉 AI “做什么”，而是为它精心设计一个信息充足、条理清晰的“世界”，让它在这个世界中更自由、更智能地思考和创造。这，无疑是通往更强大、更通用的 Agentic AI 的必由之路。
