聊一下最近圈子热议的话题
#ai创造营#Shopify CEO 和Andrej Karpathy 都同意的观点：提示工程的名称是否应该改为上下文工程
主要包括：
- 各路大神的观点
- 为什么上下文工程如此重要
- 上下文工程的三大策略
- 其他实践经验与建议
这里发一下文章的总结
近期AI圈热议“提示工程”是否应更名为“上下文工程”，因为后者更准确地描述了为大模型（LLM）提供任务所需全部信息的工作。
Shopify CEO Tobi Lutke 和 Andrej Karpathy 等人认为，“上下文工程”更能体现工业级LLM应用中对上下文的精细管理和填充。
上下文工程不仅仅是写好提示词，还包括任务描述、样本、RAG（检索增强生成）、多模态数据、工具、状态、历史和信息压缩等。
上下文工程的重要性
Cognition 和 Anthropic 等公司在多Agent系统中强调上下文管理的重要性。
不充分的上下文会导致Agent工作不一致，过长或不相关的上下文会增加成本、降低性能。
多轮对话中，指令遵循性下降，优化上下文长度和准确性尤为关键。
上下文工程的三大策略
1. 压缩（Compression）
目标：每轮对话只保留最有价值的Token。
方法：上下文摘要（如Claude Code自动压缩、Cognition用微调模型压缩）。
难点：高质量摘要难以实现。
2. 持久化（Persistence）
目标：构建可长期存储、保存和检索上下文的系统。
存储方式：文件（如CLAUDE .md）、嵌入式文档、知识图谱等。
保存策略：用户手动或Agent自动生成/更新记忆（如Reflexion机制）。
检索方式：直接加载或基于嵌入向量/图检索，需防止检索出错导致“跑题”。
3. 隔离（Isolation）
目标：在不同Agent或环境间划分上下文。
方法：结构化上下文模式（如Pydantic模型）、多Agent分散上下文、环境隔离（如HuggingFace的沙盒环境）。
多Agent系统可提升性能，但也带来Token消耗和协调难题，适合可并行化任务。
实践经验与建议
工具先行，优先关注数据和Token追踪。
明确Agent状态，梳理运行时所需信息。
在工具边界处进行上下文压缩。
从简单记忆功能做起，逐步优化。
多Agent方案适用于可并行化任务，但需注意协调难题。
结论
