原创 栾小凡 2025-10-13 17:58 上海
幻觉不是大模型的bug，是创造力的来源。Anthropic、langchain、Manus都在押注Context Engineering。
Context Engineering（上下文工程），让算法工程师精准找到大模型准确性与创造力的平衡点。
从OpenAI的最新发布会不难看出，基础模型的进步已经日渐放缓。
那么，怎么给大模型落地续命？
Anthropic、langchain、Manus在内，一众明星玩家都给出共同答案：提示词已死，Context Engineering（上下文工程）当立。
相比呆板的提示词，Context Engineering的输入更精简、更有逻辑、更动态，大模型的输出也因此变得更加可控且高质量。
那么，我们为什么需要Context Engineering，它的影响如何，我们如何设计Context Engineering，又该如何为它搭建合适的infra基础设施？本文将一一解答。
01
幻觉与创造力，是AI的一体两面
在正式聊Context Engineering之前，我想先分享一个观点，那就是幻觉与大模型创造力，本质上是同一事物的一体两面。
它们与人类的创作过程类似：都是基于扎实的事实、数据基础，产生规律总结，然后对规律进行延伸、组合，完成有根据的认知跳跃。
对人类来说，诗人写诗要懂语言韵律，科学家提假设需基于现有理论。对AI来说，它要在庞大的知识网络中寻找规律与连接点，才能实现类比推理、创意联想，产出好故事、好策划或新编程逻辑。
这种能力利用得当，就是优质内容产出；一旦失控，就是我们闻之色变的幻觉。
两者之间产生差别的根源，对人类来说，来自于阅读量与天分；对AI来说，则来自于模型能力以及模型的上下文输入质量。
而这，也是我们关注Context Engineering，也就是模型上下文工程的根本原因——找到模型的准确性与创造性的平衡点。
02
低质量输入带来的影响
低质量的上下文会带来一连串的输出问题，这种低质量包括但不限于：
（1）上下文污染（Context Poisoning）
当错误信息或幻觉内容进入上下文并被反复引用时，就会发生上下文污染。DeepMind在Gemini 2.5的技术报告中详细描述了这种现象：在Pokemon游戏实验中，AI智能体偶尔会产生关于游戏状态的错误判断，并将这些错误信息写入上下文。一旦目标部分被这些错误信息污染，智能体就会发展出完全荒谬的行动策略，执着地追求根本无法实现的目标。
（2）上下文分散（Context Distraction）
当前，许多头部模型已能支持100万token的上下文窗口——大约相当于75,000行代码或750,000字的文档内容。这给到了很多人一个错觉：我们给到大模型的输入越多越全面，大模型给我们的反馈就越好。
但现实是我们的输入上下文越长，大模型对核心内容的权重分配越混乱。而且，基于“Lost in the middle”现象，大模型会给上下文的开头和结尾更高的权重，忽略中间部分内容。
此外，当上下文变得过于冗长时，模型可能会过度依赖上下文内容而忽视其训练过程中获得的核心知识。研究发现，即使Gemini 2.5 Pro支持超过100万token的上下文，但在智能体任务中，一旦上下文超过10万token，智能体就更倾向于机械地重复历史动作，而不是基于训练知识综合出新的解决方案。Databricks的研究进一步显示，较小的模型如Llama 3.1 405b在32k token附近就开始出现明显的性能下降。
(3)上下文混乱（Context Confusion）
当上下文中包含过多无关信息时，会导致模型输出质量的显著下降。Berkeley的Function-Calling排行榜研究表明，所有模型在面对多个工具选项时性能都会下降，甚至在完全不需要工具的场景中也会错误地尝试调用工具。GeoEngine基准测试提供了一个典型案例：当给量化后的Llama 3.1 8b提供46个工具时，它完全失败；但减少到19个工具时，它就能成功完成任务。
(4)上下文冲突（Context Clash）
当上下文内部包含相互矛盾的信息时，会严重影响模型的推理能力。微软和Salesforce的联合研究发现，当将基准测试的prompt分散到多轮对话中时，模型表现平均下降39%。OpenAI o3的分数更是从98.1直接跌落到64.1。研究团队总结："当大语言模型在对话早期阶段做出错误假设时，它们往往会迷失方向，很难重新回到正确的轨道上。
针对以上困境，Context Engineering作为一门显学逐渐发展起来：它的主张是，不过分限制模型的"幻觉"，而是通过精心设计的上下文环境，引导模型在准确性与创造性之间找到最佳平衡点。
那么，一个优质的Context Engineering应该如何设计？
03
Context Engineering的三层架构如何运作
从工程实践角度分析，成功的Context Engineering应该有三层核心架构：
Instructions层（指令层）
这是系统的"导航系统"，包括精确的Prompts、典型的few-shot示例等。其主要功能是明确指导模型执行任务，清晰表达用户意图并提供具体操作示范。
Knowledge层（知识层）
这是系统的"数据库"，涵盖事实信息、长期记忆存储、代码库内容、当前系统状态和工作草稿等。它为模型推理过程提供必要的基础材料和背景信息。
Tools层（工具层）
这是系统的"执行引擎"，包含工具功能描述、调用结果反馈等。其主要作用是扩展模型的行动能力边界，使其能够与外部系统进行有效交互。
这三个层次构成了一个完整而动态的上下文生态系统：Instructions层确定行动方向，Knowledge层提供决策素材，Tools层扩展执行能力并提供实时反馈。
04
Context Engineering的业内实践
基于三层架构，目前行业内关于Context Engineering的探索，主要有以下解决方案：
上下文隔离（Context Isolation）
将复杂任务拆解为多个独立Agent，每个子任务使用独立上下文避免相互干扰。这种方法特别适用于多步骤的复杂任务，通过多智能体并行协作不仅提升效率，还能显著降低错误传播的风险。
上下文修剪（Context Pruning）
定期清理无关内容，保留核心指令与目标，删除冗余历史与文档。这需要建立明确的信息重要性评估机制，确保上下文始终聚焦于当前最相关的信息。
上下文摘要（Context Summarization）
将累积的长篇信息压缩为简短而精准的总结，既保留了关键信息，又减少了重复与噪音。优秀的摘要策略能够显著降低"上下文分散"的风险。
上下文卸载（Context Offloading）
将部分信息存储在LLM外部，比如使用专门的笔记系统或草稿工具。这种方法能够有效减轻主上下文的负担，同时保持信息的可访问性。
RAG增强（检索增强生成）
有选择地引入外部相关信息，避免"垃圾进，垃圾出"的问题。关键在于建立有效的信息过滤和质量评估机制，确保引入的信息真正有助于任务完成。
精准工具配置（Optimized Tool Loadout）
仅加载当前任务真正需要的工具。研究表明，工具数量超过30个时性能会显著下降，因此精准的工具选择和配置至关重要。
05
Data Infra
Context Engineering的基础设施
Context Engineering的理论再精妙，也需要强大的基础设施支撑。当前企业的Context Engineering在数据基础设施层面临着三重挑战：
数据量级的指数增长
从TB级跃升至PB级，过去的简单操作变成了系统工程。给表添加一个字段不再是一行SQL的小事，而需要涉及存储重构、计算调度、系统协调的复杂工程。
数据消费模式的根本性转变
AI Agent直接生成和消费数据，基础设施必须对机器和模型友好。
多模态数据的复杂性管理
从1KB的文本消息到100MB的视频片段，从简单的数值记录到复杂的嵌入向量。更复杂的是，这些非结构化数据往往还携带着丰富的元数据：标签、特征、语义向量等结构化信息。如何统一管理和高效检索这些异构数据，成为Context Engineering实施的关键瓶颈。
06
Milvus + 向量数据湖
专为AI时代打造的数据架构
面对这些挑战，Zilliz提供了针对Context Engineering的工程化解决方案：
毫秒级向量检索
Milvus专门为向量数据而生，无论你的embedding来自文本、图片、音频还是视频，都能统一存储和管理。关键指标：毫秒级检索延迟，轻松支持过亿条向量数据。当你的AI应用需要从海量上下文中快速找到最相关的信息时，这种性能表现直接决定了用户体验的好坏。
面向海量多模态数据的数据湖方案
向量数据湖作为多模态数据湖方案，专门解决大规模非结构化数据的离线处理难题。配合Ray、Daft等经过生产环境验证的分布式计算框架，能够高效完成上下文压缩、去重、聚类等复杂操作。处理完成的优化数据无缝对接Milvus，整个数据流pipeline一气呵成，避免了传统方案中繁琐的数据格式转换和中间存储开销。
真正的云原生弹性扩展
采用存算分离架构，存储和计算资源可以独立扩缩容。当你的业务从每天处理几GB数据增长到几TB甚至PB级时，系统能够自动适应负载变化。更重要的是，你可以根据实际场景需求在实时serving和离线training之间灵活调配资源，既保证了服务质量，又避免了资源浪费。
为下一代AI应用而设计
这套架构的设计哲学立足当下的同时，还可以为未来3-5年的AI应用发展趋势做准备。随着Context Engineering变得更加复杂——需要处理更丰富的模态组合、更复杂的数据关系建模、更智能的模型推理能力——这个架构都能从容应对技术演进。从简单的语义检索到复杂的多步推理，从单模态数据到多模态融合，技术升级路径清晰且平滑。
文末彩蛋
我们的向量数据湖方案将于近期发布与大家见面
另外，12月19日北京AICon，Context Engineering主题，我们将带来更多精彩内容与大家分享
也欢迎扫描文末二维码进群，我们将针对Context Engineering做持续的经验分享与输出。
作者介绍
栾小凡
Zilliz 合伙人和研发 VP
LF Al & Data 基金会技术咨询委员会成员
推荐阅读
RAG-Anything × Milvus：读PDF要集成20个工具的RAG时代结束了！
Milvus 2.6 上新解读：Data-in, Data-out，向量搜索告别复杂预处理
Word2Vec、 BERT、BGE-M3、LLM2Vec，embedding模型选型指南
全面测评LangChain vs LangGraph：谁是agent落地最优解
企业级向量数据库选型，Milvus 和Zilliz Cloud哪个更合适？
