微信扫码
添加专属顾问
我要投稿
从Prompt咒语到Context剧本,揭秘如何让AI成为你的高效工作伙伴,处理复杂任务游刃有余。 核心内容: 1. 从Prompt到Context的必然演进:多轮对话、工具调用与信息整合的挑战 2. Context Engineering三大核心问题:记忆限制、信息噪音与成本优化 3. 实战解决方案:如何为AI编写高效"情景剧本"提升协作效率
在ChatGPT出现之后的过去几年里,我们见证了“提示词工程”(Prompt Engineering)的兴起。我们像学习一门新的语言一样,钻研如何通过精巧的“咒语”或“指令”,从大语言模型(LLM)那里获得最靠谱和惊艳的回答。这感觉就像是发现了魔法,只要念对咒语,AI 就能文思泉涌、代码飞流。
但当我们将 AI 从一个聪明的“问答盒子”变成一个真正的“工作伙伴”——一个能处理复杂任务、使用工具、与我们进行多轮深度协作的智能体(Agentic AI)时,我们发现,单靠一句句的“魔法指令”已经不够了。
我们需要的不再是孤立的问答,而是一场连贯的、有记忆的、智能的互动。我们需要的不再是仅仅给 AI 一句指令,而是为它编写一整部“情景剧本”,于是“上下文工程”(Context Engineering)就闪亮登场了。
想象一下,你正在让一个 AI 助手帮你完成一份市场分析报告。这个任务涉及:
在这个过程中,产生的信息量是巨大的。而 AI 面临三大挑战,正是 Context Engineering 诞生的土壤。
每个大模型都有一个“上下文窗口”(Context Window),所有输入给它的信息,包括历史对话、文档、工具返回结果,都必须塞进这个窗口里,模型才能“看到”。
问题在于,这个窗口的大小是有限的。对于一个需要分析整个代码库的编程助手,或者一个与用户聊了数十轮的客服AI,对话历史很容易就“撑爆”了这个窗口。即使没撑爆,把海量信息全部塞进去,也意味着高昂的 API 调用成本。这就像和一个记忆力不好但收费高昂的顾问开会,你不得不一遍遍重复所有背景信息。
Agentic AI 在工作时会产生大量的“中间过程”,比如调用工具后返回的复杂原始数据(如 JSON 文件)、冗长的搜索结果等。如果把这些充满“噪音”的原始信息不加处理地直接扔给模型,不仅会迅速消耗宝贵的上下文空间,还会干扰模型的“注意力”,影响它对核心任务的判断。
即使不考虑大模型的上下文长度限制,模型调用成本也是不容回避的现实问题。对于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中,且不论效果如何,其成本之高也让人望而却步。
回顾我们人类自身,我们的大脑并不像一个无尽的硬盘,能够不分轻重地存储和读取一切经历与信息。相反,我们的大脑运行着一个极为高效的“信息管理系统”,能够动态地编码、筛选和存取信息。这一系统不仅帮助我们记忆,还决定了我们如何感知世界并专注于任务。
工作记忆: 由大脑中的海马体驱动,工作记忆处理我们当前正在思考和操作的信息。它是一种短期的、清晰且细节丰富的信息缓存,类似于一张“临时工作台”,专注于当前任务的具体细节。
长期记忆: 长期记忆存储着我们过去的重要知识、经历和技能。这些记忆并不是零散的,而通常是以“要点”和“摘要”的形式保留下来的。只有对我们重要或经常被重复的信息,才会从工作记忆迁移到长期记忆中。
注意力机制: 这是令人类大脑高效运转的关键所在。我们的注意力机制像是一盏“聚光灯”,选择性地聚焦于当前最重要的事物,同时过滤掉无关的背景信息。在一个充满无序信息的世界中,它帮助我们避免信息超载,并维持对关键任务的专注。
外部信息的调用: 当我们需要的信息不在脑海中时,我们会利用工具去查书、上网搜索,或者通过与他人交流来填补知识空白。
为了说明注意力机制的重要性,心理学家西蒙斯(Daniel Simons)和查布里斯(Christopher Chabris)曾设计了一项著名的实验——“隐形大猩猩实验”。在实验中,参与者被要求观看一段视频,视频中有两组篮球队员分别穿着白色和黑色的衣服,彼此传球。参与者的任务是数清白衣队员一共传了多少次球。
令人惊讶的是,尽管实验过程中一只穿着黑色大猩猩衣服的人从画面中间经过,多达一半的参与者完全没有注意到“大猩猩”的存在。这一现象被称为“无意识盲视”(inattentional blindness),深刻揭示了人类注意力机制的局限性:当我们全神贯注于某件任务时,与目标无关的信息,即使明显到荒谬程度,也可能被忽略。
大猩猩实验从认知科学的角度帮助我们理解注意力机制的核心意义——它不仅是管理信息的重要工具,更是一种保护机制,帮助我们从海量信息中过滤噪音,集中精力完成目标任务。如果没有这种选择性,我们会被无关的细节淹没,变得无所适从。然而,这种机制也表明,我们的大脑对其他信息的感知能力是有限的,专注的代价是对背景信息的遗漏。
一个优秀的人工智能系统,也需要具备类似人类大脑的信息管理能力,而不是被动地存储或处理信息。AI 的“记忆”和“注意力机制”应包括:
动态记忆管理: AI 应能够根据当前任务选择性地存储和检索信息,而非机械地扫描所有数据。
注意力模型: 类似于人类注意力机制,AI 应能够快速聚焦关键信息,过滤掉噪音,提升推理效率和准确性。
外部信息调用: AI 应当依赖丰富的外部资源,动态获取缺失或精确的信息,而不是试图将所有信息封装在内部。
这就是现代人工智能中Context Engineering的核心目标——帮助AI设计并构建一个高效的“思维架构”,像人类一样管理信息流,利用注意力机制处理复杂问题,并在广阔的信息海洋中保持清晰、专注和高效的执行力。
ConsoleX AI是一个为创造者量身定制的Agentic AI Studio,用户可以在统一的聊天界面中,利用大模型调用工具完成研究、创作、绘图、发布和分析等各种代理任务,因此不可避免的需要涉及到多轮对话以及连续的工具调用。我们面临的挑战很具体:如何在控制成本和保证性能(如首个token的响应速度)的前提下,让 AI 在长对话和复杂任务中保持高水准的表现?在 ConsoleX AI 的实践中,我们构建了一套工作记忆机制,这正是 Context Engineering 的一次企业级落地实践。
我们的答案是构建一个分层的、动态的、智能的上下文管理系统。
我们参考人脑的记忆模式,将 AI 的记忆分为不同层级,确保最有价值的信息始终处于“C位”。
通过这个分层系统,AI 在构建每一次回复的上下文时,都能像拼图一样,智能地从不同层级中拾取最相关的信息碎片,组成一个高效且信息量密集的“情景剧本”。
不过仅有分层压缩是不够的。温记忆和冷记忆在压缩过程中不可避免地会丢失大量细节信息,这可能导致 AI 在处理特定问题时缺乏必要的背景知识。为了解决这个问题,我们设计了一套基于记忆仓库 (Memory Vault) 的智能唤回机制:
这种方法确保了 AI 既能保持对话的连贯性,又能在关键时刻"回忆起"过去的重要细节,大大提高了回答的准确性和深度。
为了让记忆系统高效运转,我们还引入了两个关键机制:
我们还大量使用了缓存技术。对于那些被频繁访问的记忆或信息,会通过Redis缓存起来,把它们放在“手边”。当 AI 再次需要时,便可高速获取,极大地缩短了响应时间,提升了用户体验。
对于重复的内容,如AI的回复摘要、工具调用结果的压缩等,在ConsoleX的实践中,我们也会尽量利用缓存,避免重复压缩,这不仅可以节省压缩所需的大模型使用成本,而且由于现在国内外主流的大模型厂商都已经支持Prompt Cache机制,重复利用Redis缓存中压缩好的内容,可以提高在大模型调用过程中Cached token的命中比率,节省大模型调用的成本50%~85%。
构建这样一个复杂的记忆系统,不能凭感觉。我们很早就意识到了评估 (Evaluation) 对于构建LLM系统的重要性,并基于我们自己的评估产品EvalsOne建立了一套系统的评估方法论,具体包括:
通过反复的迭代和调整优化,我们实现了开启“动态工作记忆”模式的情况中,在几乎不损耗响应性能和回复准确率的前提下,在十轮以上的连续对话中,平均节省Tokens成本50%以上。
上下文工程(Context Engineering)是一个新兴的概念,标志着我们与 AI 协作模式从生成式 AI(Generative AI)迈向代理式 AI(Agentic AI)的深刻转变。尽管对这一概念的落地和实践观点各异,但也无需将其过度复杂化,关键在于立足具体应用场景进行设计,并付诸实践。抛砖引玉,希望希望能为大家提供一些启发和思路。
从 Prompt Engineer 到 Context Engineer,我们扮演的角色正在从一个“指令下达者”,转变为一个“情景剧本的导演”。我们不再是仅仅告诉 AI “做什么”,而是为它精心设计一个信息充足、条理清晰的“世界”,让它在这个世界中更自由、更智能地思考和创造。这,无疑是通往更强大、更通用的 Agentic AI 的必由之路。
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费场景POC验证,效果验证后签署服务协议。零风险落地应用大模型,已交付160+中大型企业
2025-05-08
2025-05-08
2025-05-08
2025-05-07
2025-05-19
2025-06-12
2025-05-07
2025-04-16
2025-06-27
2025-04-21
2025-07-08
2025-07-04
2025-06-23
2025-06-14
2025-06-04
2025-06-02
2025-05-17
2025-05-16