用Context Engineering修复Agent生产故障

Context Engineering vs. Prompt Engineering

虽然这两个术语有时会被混淆，但 prompt engineering 和 context engineering 在 AI 栈的不同层级上运作：

Prompt engineering 专注于如何格式化文本、编写指令，以及在 LLM 系统 prompt 设计中选择特定的词汇，以指导模型的即时推理。

Context engineering 是一门软件工程学科。它将 LLM context window 视为一个动态数据缓冲区。工程师不再手动调整 prompt，而是设计自动化系统在每次模型调用期间以编程方式组装和过滤数据。Context engineering 还涉及在多轮对话中压缩和清除历史交互、检索到的知识和工具 schema。

从 playground demo 转移到生产环境时，AI agents 性能下降的原因不总是基础模型的智能水平。关键在于它接收的数据。随着工作流演变为多步骤系统，单纯的 prompt 调整已经不够用。

LLM 的 context engineering 将焦点从编写巧妙的 prompt 转向控制每次调用时到达模型的数据。因为每一个历史对话、数据库检索和工具 schema 都在争夺空间，工程师需要主动管理进入模型的整个 context 生命周期。

Context window 中的内容组成

在实际应用中，context 是一个快速变化的数据混合体，从基础指令到大型数据库响应的所有内容都会被转换成 token。

由于 token 有严格的限制，不同的 context 部分会积极竞争模型的注意力。如果没有 context window 管理，就会出现 context rot（context 腐烂），使 agent 需要的高价值指令被低价值的执行数据埋没。

为了防止这种稀释，你必须分解构成 context window 的四个主要来源。

系统 prompt 和指令

LLM 系统 prompt 设计定义了 agent 的角色、结构约束、错误处理规则和执行边界。虽然它通常被视为静态的，但复杂的 agent 系统经常需要动态系统 prompt，根据工作流的当前状态追加或交换指令。由于这些指令必须在对话的每一轮中持续存在，一个臃肿的系统 prompt 对你的 token 预算构成了永久的开销。一个详细的系统 prompt 可能在每次调用中都会轻易消耗 1,000–2,000 个 token。

对话状态和内存

一旦 agent 开始迭代，agent 内存管理就成为 context window 空间的主要消耗者。这个部分存放用户消息、助手响应和中间执行思想的运行日志。如果你在每个新回合中盲目地将整个历史追加回循环中，性能会迅速下降。随着时间推移，早期的交互变得无关或甚至直接与当前任务相矛盾，导致模型失去执行的连贯性。

当 agent 需要外部数据来回答特定问题时，你可能会依赖检索增强生成（RAG）从向量存储或数据库中获取相关数据。但将原始 JSON 负载或大型文档片段直接转储到 context window 中是触发 AI 幻觉的快速方式。最佳实践是将这些检索视为干净的、即时添加，去除元数据和结构标记，只提取即时步骤所需的精确文本块。

工具定义和结构化输出

如果你的 agent 使用工具，你必须为它们的定义分配空间。每个 API 端点描述、参数约束和预期的 JSON 输出 schema 都必须在 LLM context window 中，这样模型才知道如何格式化它的调用。如果你给 agent 访问全局工具目录的权限，这些结构定义本身就可能在处理实际用户查询之前消耗掉它的整个 token 预算。

生产 agent 中的 context 管理策略

如果不加以管理，这四个来源可以独立扩展：系统 prompt 随着需求的演变而增长，内存随着每次对话而积累，RAG 结果的大小因查询而异，工具定义随着每个新功能而扩展。管理它们意味着要做出深思熟虑的决策，决定每个组件获得多少空间，以及当它们无法全部适应时哪些需要被删除。

在生产中，未管理的 context window 会导致遗漏指令、检索效果差和成本增加。随着执行循环迭代，context 变得越来越重、越来越昂贵、越来越混乱，直到模型丢弃关键指令、出现幻觉或选择了错误的工具。

为了防止这种崩溃，实施结构化策略来控制模型在每个步骤看到的内容。可以把它想象成一个连续的过滤管道，删除无关数据并仅保留当前操作所需的信息。

以下是工程师们用来控制进入 context window 的内容的四个核心模式。

在生产环境中控制 context window，而不是在脑子里

将写入、选择、压缩和隔离策略作为可检查的节点进行连接

控制 context 大小的最简单方法是规范地写入系统 prompt。好的 LLM 系统 prompt 设计不是指用防御性文本填充指令或恳求模型"仔细注意"。而是使用简洁、结构化的格式，如 markdown 标题和清晰的 JSON schemas。系统 prompt 中的每句话都应该有其价值。移除任何对核心任务不必要的约束。否则，你就是在为每个推理步骤增加不必要的成本。

你不需要一次性将整个历史记录或数据库提供给模型。选择策略侧重于在数据进入 context window 之前过滤它。对于对话日志，这意味着不再简单地转储聊天历史，而是使用滑动窗口缓冲区，仅保留最近的轮次。对于外部数据，这意味着使用 RAG 或有针对性的检索，根据用户的直接意图获取高度具体的数据块。当你仅公开与当前任务相关的工具，而不是默认给予对所有工具的访问权限时，同样的原则也适用于工具定义。

当你拥有过长而无法原样传递的高价值信息时，是时候进行压缩以提高信息密度。压缩的实现有两个选项：

• 运行一个总结工作流步骤，将长的对话历史线程浓缩为紧凑的状态更新。

• 使用专门的 token 修剪模型来删除冗余词和填充数据，而不会丧失含义。

通过将关键字段作为 JSON 而不是完整段落传递，从非结构化文本中提取结构化事实，这样模型就能接收可以直接处理的数据。

通过首先压缩数据，你确保 agent 保留它所需的核心 context，而不会耗尽自己的 LLM context window。

如果你的 agent 试图在一个巨大的 context window 中完成所有事情，随着工作流变得更加复杂，它会陷入困境。隔离将一个单体 agent 分解为一个由更小的、专门化步骤组成的网络。每个都在自己的隔离 context window 内运作，仅包含其狭隘任务所需的具体工具、指令和数据片段。通过在这些隔离块之间仅传递最终输出，你保持 token 使用量低，并防止一个步骤的故障影响工作流的其余部分。折中之处在于编排，你需要决定每个步骤接收什么以及将什么传递下去。

在 n8n 中实现 context engineering

在代码优先的框架或自定义编排脚本中，context 通常以编程方式管理。当 agent 在生产中进入无限循环或出现幻觉时，调试意味着追踪日志以重建模型实际接收的内容。

n8n 通过将完整的 context 生命周期公开为可配置、可检查的节点来改变这一点。你不需要依赖严格的抽象，而是获得了对内存后端、context window 阈值、检索时序和工具调用范围的直接、精细的控制。

你可以使用特定的工作流组件来实现上述每个 context 策略。IF/Switch 节点处理动态 context 选择，根据意图或用户类型将查询路由到不同的检索路径。Code 节点或 Basic LLM Chain 允许你压缩数据、总结历史或提取结构化事实，然后再将其放入 context window。

子工作流适合隔离，其中每个子 agent 在自己的 context 中操作，仅拥有它需要的工具和数据。内存子节点负责历史管理，控制多少轮次持续存在以及它们存储在哪里。关于什么进入 context window 的每个决策都是画布上的一个节点，而不是埋在代码中的一行。

因为 n8n 是围绕可视化工作流编排构建的，你可以在执行的每个步骤检查、调试和修改 context 流。如果 agent 失败，你不必猜测出了什么问题。你可以打开执行历史并查看 agent 日志，查看在该推理步骤中发送给 LLM 的确切 JSON 负载，看到输入数据、模型返回的内容，并直接调整工作流逻辑。

这种提供商无关的架构也意味着你的 context engineering 模式不会被锁定在单个模型供应商。无论你使用 OpenAI、Anthropic 还是自托管模型，相同的内存子节点、检索流和工具隔离模式都能无缝工作。随着 AI 生态的发展，你可以交换模型、更新内存配置或添加新工具，而无需重建整个编排层。

使用 MCP 和工具节点进行即时检索

通过仅按需检索数据来保持系统 prompt 的精简。使用 MCP Client Tool 节点，你的 agent 可以查询外部 MCP 服务器。为了保持 context window 专注于模型需要的内容，你可以仅选择特定 MCP 服务器公开的工具的子集。

跨子 agent 保持 context 隔离

通过对你的架构进行分区来避免加载不必要的工具。在 n8n 中，你可以通过连接专门的 AI Agent tool 子节点来隔离 context。数据分析子 agent 仅加载数据库工具 schema，而写作子 agent 仅加载样式指令。它们将干净、最小的输出传递给主工作流，保持单个 context window 小而可靠。

直接控制你的 agent 生命周期

Agent 的成功不取决于找到完美的 prompt。而是取决于你控制数据流、执行严格的 token 预算和在工作流扩展时保持 context window 专注的能力。通过将 context window 视为动态环境而不是静态 prompt 字符串，你可以构建在扩展时保持可预测和成本效益的多步骤工作流。

准备好控制你的 AI agent 工作流了吗？使用 n8n Cloud 开始构建 context-aware agent，或探索 AI agent 工作流模板以查看 context engineering 模式的实际应用。

n8n 的用户来自各种背景、经验水平和兴趣。我们一直在寻求在博客文章中突出不同用户及其项目的机会。如果你正在使用 n8n，并想激励社区，请与我们联系 💌