Context Engineering vs Prompt Engineering
Anthropic 和 Cognition 相继发布了关于 Multi-Agents 的文章，至少从标题看是持完全不同的观点，Cognition 认为不应该构建 Multi-Agents，而 Anthropic 则分享了团队构建 Multi-Agents 研究系统的实践经验。
仔细阅读两篇文章后，才发现它们并非对立，而是基于不同的视角，讲述了原有 Prompt Engineering 的局限性，尤其是 Cognition 重点强调引入了 Context Engineering 的概念。
Don’t Build Multi-Agents
https://cognition.ai/blog/dont-build-multi-agents
How we built our multi-agent research system
https://www.anthropic.com/engineering/built-multi-agent-research-system
在 Context Engineering 的概念正式进入讨论，也激起了 AI 领域激烈的讨论，大家纷纷表示 Context Engineering 确实是一个更贴切更符合最新发展的概念，其中以 Langchain 团队和 Philipp Schmid 的观点分享更为详尽系统。
The New Skill in AI is Not Prompting, It's Context Engineering
https://www.philschmid.de/context-engineering
Context Engineering
今天咱们就一起基于上面的几篇干货优质文章，重新理解 Context Engineering 到底是什么？包含什么？为什么重要？策略、原则和应用场景又分别是什么？
Context Engineering（上下文工程）是什么？
简单来说，Context Engineering 是构建强大 AI 智能体（Agent）的关键技术，它的核心在于为 AI 模型提供恰到好处的“上下文”，让它能更好地理解任务、做出明智决策，最终完成复杂的工作。相比传统的“提示工程”（Prompt Engineering），上下文工程更全面、更动态，像是给 AI 配备了一套完整的“工作环境”，而不仅仅是一个单一的指令。
为什么上下文工程这么重要？
想象一下，你让一个超级聪明的助手帮你安排明天的一个会议。如果只给它一句模糊的指令，比如“明天安排个会议”，它可能会一脸懵：跟谁？什么时候？关于什么？但如果你提供了更多背景信息，比如你的日程表、对方是谁、你们之前的邮件往来，甚至还能调用发邀请的工具，这个助手就能给你一个精准又贴心的回答，比如：“嘿，Jim，明天我全天都排满了，星期四上午可以吗？我已经发了个邀请给你，确认下时间吧！” 这就是上下文工程的魔法——它让 AI 从一个“听话的机器人”变成一个“懂你的伙伴”。
文章中反复提到，AI 智能体的失败往往不是模型不够聪明，而是上下文不够好。换句话说，垃圾输入（Garbage In）等于垃圾输出（Garbage Out）。上下文工程就是要确保 AI 在“对的时间”拿到“对的信息”和“对的工具”，以最适合的格式呈现，从而完成任务。
上下文工程包含什么？
上下文工程不只是写一个完美的提示词，它是一个动态的系统，包含以下几个关键部分：
-
指令/系统提示：告诉 AI 它该扮演什么角色，比如“像专业助手一样回答”或“严格遵守 JSON 格式输出”。还可能包括示例、规则等。
-
用户提示：你当下给 AI 的具体任务或问题，比如“帮我写一封邮件”。
-
短期记忆（对话历史）：当前对话的来龙去脉，包含你和 AI 的交互记录。
-
长期记忆：跨对话的知识积累，比如用户偏好、过去的项目总结或特定事实。
-
外部信息（RAG）：通过检索外部文档、数据库或 API 获取的最新信息。
-
可用工具：AI 可以调用的功能，比如查日程、发邮件或搜索网页。
-
输出格式：定义 AI 回答的结构，比如必须返回 JSON 或简洁的文本。
这些部分共同构成了 AI 的“工作内存”，就像电脑的 RAM，容量有限但至关重要。上下文工程的艺术就在于如何高效地管理这些信息，确保 AI 在需要时能拿到最相关的“原料”。
上下文工程的四大策略
为了让上下文更高效，文章总结了四种常见策略，适用于构建更可靠的 AI 智能体：
-
写入上下文（Write Context）
就像人类做笔记一样，AI 可以在“便签本”（Scratchpad）上记录任务过程中的关键信息，比如计划、临时想法等。这些信息可以保存在会话中（短期记忆）或跨会话存储（长期记忆）。比如，ChatGPT 会自动生成用户偏好的记忆，供未来使用。
-
选择上下文（Select Context）
不是所有信息都得一股脑儿塞给 AI。选择上下文就像从资料库里挑出最相关的材料。比如，AI 可以根据任务需要，从长期记忆中提取特定的事实或示例，或者通过 RAG 检索外部知识。代码智能体（Code Agent）就常用这种方式，从庞大的代码库中精准提取相关文件。
-
压缩上下文（Compress Context）
AI 的上下文窗口（工作内存）有限，信息太多会导致溢出或性能下降。压缩上下文就像整理笔记，只保留最关键的内容。比如，Claude Code 会在上下文快满时自动总结对话历史，或者对冗长的工具调用结果进行精简。这种方式既省 token 又提高效率。
-
隔离上下文（Isolate Context）
有时，任务太复杂，一个 AI 搞不定，可以拆分成多个子智能体，每个子智能体专注于一个小任务，拥有自己的上下文窗口。比如，OpenAI 的 Swarm 框架让子智能体各司其职，减少主智能体的负担。但这也带来挑战：子智能体之间需要协调一致，否则可能出现冲突（比如一个智能体画了个 Mario 风格的背景，另一个却做了 Flappy Bird 的鸟，风格不搭）。
上下文工程的原则
文章特别提到，构建可靠的 AI 智能体需要遵循一些核心原则，尤其是避免多智能体架构中的常见陷阱：
-
共享完整上下文
每个智能体都应该看到任务的完整背景，包括其他智能体的决策和动作记录。如果子智能体只知道自己的小任务，可能会误解大目标，导致结果不一致。比如，构建 Flappy Bird 游戏时，如果子智能体不知道整体风格要求，可能会产出完全不搭的素材。
-
动作包含隐性决策
智能体的每次动作都暗含决策，这些决策可能与其他智能体冲突。因此，理想的架构是让所有智能体共享一个连续的上下文，或者用一个专门的模型来压缩和提炼关键信息，确保一致性。
基于这些原则，文章建议优先使用单线程线性智能体，因为它能保持上下文的连续性，减少错误。对于超长任务，可以引入一个专门的“压缩模型”来总结历史记录，但这需要额外投入，比如微调一个小型模型。
上下文工程的实际应用
上下文工程已经在许多 AI 产品中大放异彩。比如：
Claude Code：通过限制子智能体的任务（只回答问题，不写代码）来简化上下文管理，同时用自动压缩来避免窗口溢出。
ChatGPT：利用长期记忆存储用户偏好，通过嵌入式检索（Embedding）选择相关记忆，但有时也会误选无关信息（比如不小心把你的位置塞进图片生成）。
代码智能体：像 Windsurf 这样的工具，通过语义检索和知识图谱，从海量代码库中挑出最相关的文件，优化上下文。
为什么多智能体架构要谨慎？
虽然多智能体听起来很酷（多个 AI 协作解决问题！），但文章警告说，2025 年的技术还不够成熟。子智能体之间的上下文共享和协调是个大难题，容易导致“各干各的”，结果不一致。相比之下，单线程智能体虽然简单，但更可靠，能避免上下文断裂带来的混乱。
总结：上下文工程是 AI 智能体的未来
上下文工程是让 AI 从“能干”到“干得漂亮”的关键。它不再是简单地写个提示词，而是要像搭积木一样，动态地为 AI 构建一个清晰、高效的工作环境。通过写入、选择、压缩和隔离上下文，工程师可以让 AI 更聪明、更可靠地完成任务。就像 React 改变了网页开发，上下文工程正在重新定义 AI 智能体的构建方式。
如果你想打造一个真正“神奇”的 AI 助手，记住：代码不重要，模型不关键，上下文才是王道！