为什么上下文工程比提示工程更重要？AI Agent构建的核心！

什么是上下文工程？与提示工程有何不同？

最近，AI 圈子内关于“提示工程”是否应该更名为“上下文工程”的讨论非常火热。Shopify CEO Tobi Lutke 认为 “上下文工程” 更能准确描述该岗位所需的核心技能：为 LLM 提供完成任务所需的所有上下文。

Andrej Karpathy 也指出，“提示”容易让人联想到日常聊天机器人中的简单任务描述。而工业级的 LLM 应用中，上下文工程则是一门艺术和科学，它需要精心填充上下文窗口，使其包含恰到好处的信息，包括：

• 任务描述和解释
• 少量样本
• RAG（检索增强生成）
• 相关的多模态数据
• 工具、状态和历史
• 压缩信息

信息不足或形式不对，LLM 无法获得最佳性能所需的正确上下文。信息过多或不相关，成本上升，性能反而下降。所以，上下文工程师需要对 LLM 的“心理”有一种引导性的直觉，提供恰到好处的信息。这种直觉需要通过不断的使用和优化提示词和上下文内容，对模型的边界有足够的了解才能形成。

简单来说，提示工程更侧重于如何编写有效的提示词，而上下文工程则关注如何为LLM提供更全面、更有效的上下文信息，包括提示词、示例、知识库等。

, ,

为什么上下文工程在AI Agent构建中至关重要？

Cognition 和 Anthropic 都强调了在 AI Agent 构建中上下文管理的重要性。Cognition 认为上下文工程是构建 AI Agent 工程师的“首要任务”。Anthropic 指出，Agent 经常需要进行长达数百轮对话的交互，这要求采用精细的上下文管理策略。

重要性体现在以下几个方面：

• 避免不一致性： 不充分的上下文共享可能导致子 Agent 工作不一致或基于冲突的假设。
• 提升性能： 过长的上下文可能限制 LLM 回忆事实或遵循指令的能力，导致性能下降。不相关的信息过多也可能降低性能。
• 降低成本和延迟： 调用反馈可能使上下文窗口膨胀，导致成本和延迟增加。例如，在语音 AI Agent 中，延迟是关键指标。
• 提高指令遵循准确性： 即使是顶级模型，在多轮对话中指令遵循性能也会显著下降。优化上下文长度和准确性对于多轮 Agent 项目至关重要。例如GPT-4o 在多轮测试中准确率仅50%。

举个例子： 想象你正在和一个 AI 助手讨论一个复杂的项目。如果你只给它一个简单的任务描述（提示工程），它可能无法理解项目的全貌和背景信息。但是，如果你提供详细的项目文档、相关的历史记录和一些示例（上下文工程），AI 助手就能更好地理解你的需求，并给出更准确、更有用的回答。

, Agent,

如何优化上下文工程？三大策略：压缩、持久化、隔离

Lance Martin 将上下文工程定义为一个伞状学科，涵盖了指令上下文（提示、记忆、少样本示例）、知识上下文（检索、记忆，例如 RAG）以及操作上下文（通过工具从环境中流动的上下文）。他提出了三种常见的策略：压缩、持久化和隔离。

策略一：压缩上下文

• 核心目标： 在 Agent 每一轮对话中只保留最有价值的 Token。
• 主要方法： 上下文摘要。
• 案例：
  • Claude Code 会在上下文窗口使用量超过 95% 时，自动执行”压缩”操作。
  • Anthropic 的多 Agent 深度研究在完成工作阶段也会生成摘要。
  • Cognition 在 Devin 中使用了专门的微调模型进行上下文压缩。

上下文摘要其实非常困难，需要模型能够识别并提取关键信息。

策略二：持久化上下文

• 核心目标： 构建用于随时间存储、保存和检索上下文的系统。
• 主要措施： 考虑上下文存放方式、上下文保存策略和上下文的检索。
  • 上下文存放方式：
    • 文件： 简单直接，如 Claude Code 使用 CLAUDE.md 格式，Cursor 和 Windsurf 使用规则文件。
    • 嵌入式文档： Letta、Mem0 和 LangGraph/Mem 存储嵌入式文档。
    • 知识图谱： Zep 和 Neo4J 使用知识图谱对事实或关系进行持续/时序索引。
  • 上下文保存策略：
    • 用户手动创建/更新： 如 Claude Code 委托用户创建/更新记忆（例如 #快捷方式）。
    • Agent 自主创建/更新： Reflexion 论文提出了在每个 Agent 轮次后进行反思并复用这些自生成提示的概念。生成式 Agent 通过综合过往反馈集合来创建记忆摘要。
  • 上下文的检索：
    • 全部载入： Claude Code 会在每次会话开始时读取所有 CLAUDE.md 文件到上下文中。
    • 选择性检索： 基于嵌入向量的搜索或图检索技术。生成式 Agent 曾根据相似性、时效性和重要性对记忆进行评分。

需要注意的是，糟糕的上下文检索会让用户感觉AI跑题了，开始说在另一个聊天窗口聊过的主题。 例如，GPT-4o 根据你的记忆将位置信息注入到图像中，而这并非用户本意。

策略三：隔离上下文

• 核心目标： 在不同 Agent 或环境间划分上下文的方法。
• 主要措施： 考虑上下文模式 (Context Schema)、多 Agent和环境隔离的上下文管理。
  • 上下文模式 (Context Schema)：
    • 使用结构化运行时状态（如 Pydantic 模型）来更好地控制 LLM 在每轮 Agent 对话中看到的内容，避免消息列表膨胀。可将 Token 量大的部分隔离，按需选择性获取。
  • 多 Agent：
    • 将上下文分散到子 Agent 中。OpenAI Swarm 库的开发动机就是”关注点分离”，即一组 Agent 可以处理子任务，每个 Agent 都有自己的指令和上下文窗口。
    • Anthropic 的多 Agent 研究表明，采用隔离上下文的多 Agent 比单 Agent 性能高出 90.2%，这主要归功于 token 使用效率的提高。
    • Cognition 团队不推荐采用多Agent架构。
  • 环境隔离的上下文管理：
    • HuggingFace 采用 CodeAgent 架构，该 Agent 输出可执行工具的代码。代码在沙箱环境中运行，并将从代码执行中筛选出的工具反馈传回给 LLM。
    • 沙盒环境会存储执行过程中生成的对象（如图片），使其与 LLM 的上下文窗口隔离，但 Agent 仍能通过变量后续引用这些对象。

总而言之，压缩上下文是为了减少Token消耗，持久化上下文是为了长期记忆，隔离上下文是为了防止信息混淆。

, , ,

上下文工程的实践经验与教训

• 工具先行： 始终优先关注数据。构建 Agent 时务必建立 Token 追踪机制。这为任何上下文工程工作奠定了基础。
• 思考 Agent 状态： Anthropic 提出要”像你的 Agent 一样思考”。实现方式之一是梳理 Agent 在运行时需要收集和使用的信息。明确定义的状态模式能有效控制 Agent 运行过程中暴露给 LLM 的内容。
• 在工具边界处压缩： 如有需要，工具边界是天然适合添加压缩的位置。例如，可通过简单提示的小型 LLM 对 Token 密集的工具调用输出进行摘要。
• 从简单的记忆功能开始： 记忆是实现 Agent 个性化的有效手段，但正确实现可能颇具挑战。通常采用基于文件的简易记忆系统，追踪一组特定的 Agent 偏好参数，这些参数会随时间推移不断保存和优化。每次 Agent 运行时，都会将这些偏好参数加载至上下文环境中。
• 针对可并行化任务考虑多 Agent 方案： Agent 间通信技术尚处早期阶段，协调多 Agent 团队仍存在困难。但这并不意味着应该放弃多 Agent 构想。正如 Anthropic 多 Agent 研究员的案例所示，当任务能够轻松实现并行化且子 Agent 间无需严格协调时，就应当考虑采用多 Agent 架构。

记住，上下文工程是一个平衡的艺术，需要在性能、成本和准确性之间取得平衡。

, Agent开发,

我的感悟

我认为：

人工智能之战，不在于模型大小，而在于语境深浅。提示词如同一把钥匙，能开启智慧之门，而上下文则如同一幅地图，指引着前进的方向。只顾雕琢辞藻，而忽略了语境的构建，终将迷失在信息的汪洋大海之中。犹如无根之木，无源之水，虽一时繁盛，终难长久。唯有深入理解任务的来龙去脉，方能使人工智能真正理解人的意图，做出符合需求的决策。

, , ,