最近看到很多的文章都在写“RAG已死，上下文为王”，YB上也非常多的相关的内容。这让我这个刚接触AI应用的初学者感到非常疑惑。在阅读https://github.com/davidkimai/Context-Engineering 后，我对大模型应用有了不一样的理解。
先说结论：RAG与Context-Engineering只是概念上的混淆。只是RAG并不能准确描述大模型应用技术，采用上下文工程这个更精确、更高价值的概念来代替。
那么什么是上下文工程？下面一张图就能说明上下文工程。在https://github.com/davidkimai/Context-Engineering中，将上下文工程以生物学隐喻的方式进行展开，图也是基于相关文章进行整理绘制的。
"Context engineering is the delicate art and science of filling the context window with just the right information for the next step." — Andrej Karpathy
"上下文工程是一门精妙的艺术和科学，为下一步填充恰当的信息到上下文窗口中。"
上下文是在推理时提供给 LLM 的完整信息负载，包括模型为合理完成给定任务所需的所有结构化信息组件。废话不多说，先上图：
原子：提示词的基本单位
完成一个任务所需要的最基本的prompt,由于提供信息过少，模型难保持一致性。
分子：将提示词与示例结合
通过小样本学习的方式做到更高精度和一致性，同时借助外部示例数据库还能实现动态分子（不同任务检索示例数据库提供最相关的示例）。
细胞：添加记忆和状态
默认情况下大模型不具备记忆功能，大模型会忘记先前交互中的信息导致用户体验不连贯
直接将所有历史消息则会导致上下文窗口被填满，因此合理的记忆管理策略十分重要。
器官
上下文器官协调多个LLM细胞来解决任何单个上下文都无法解决的问题。由指挥者、共享记忆、以及专业细胞通过相应的合适所需应用的控制流模式结合组成。
各司其职的器官共同组成一个完整的认知系统。
目前构建器官可能会面临的挑战：
- 错误可能通过系统传递
- 编排增加了复杂性和延迟
- 关键信息可能在细胞之间丢失
- 复杂的交互难以追踪，调试困难
- 多次调用LLM增加总token成本
- 系统设计复杂性高，需要仔细规划和测试
器官构建的最佳实践方式：
- 从最小化器官开始，根据需要增加复杂性
- 在隔离状态下测量每个细胞的性能
- 需要定义细胞之间的清晰输入输出格式
- 跟踪所有细胞之间的通信
- 设计细胞处理意外输入
- 添加专门的细胞来检查输出
- 先构建基本功能再添加
- 识别并并行化独立任务
本文参考：https://github.com/davidkimai/Context-Engineering
