在生产环境中为AI代理构建上下文的架构方法（静态、动态与会话层）

我们在生产环境中观察到代理表现不佳的最常见原因，既不是模型问题，也不是提示词问题，而是上下文架构从未经过设计，只是随时间不断累积。所有内容最终都塞进了系统提示词中，因为这是最方便的存放位置，而代理开始以难以诊断的方式出现故障，因为失败是结构性的，而非逻辑性的。对我们最有帮助的框架是将上下文视为三个需要分别管理的独立层，因为每一层都有不同的更新频率、不同的故障模式和不同的恢复路径。静态层涵盖描述业务运作的所有内容：术语、决策边界、产品规则、升级路径。这类内容很少变更，但一旦变更就必须准确，因为过时的静态上下文会产生自信的错误答案，这些错误比明显错误更难发现。我们将静态层放在系统提示词之外，存放在一个结构化的知识库中，代理从中检索，而不是直接嵌入其中，这样更容易在不修改代理逻辑本身的情况下进行更新。动态层是代理在运行时需要的实时数据：订单状态、客户历史、库存、账户详情。这实际上是生产环境中大多数上下文缺口所在，因为那些在测试中表现出色的代理，往往在测试环境中拥有干净、完整的动态数据，而生产环境无法可靠提供。解决方法不是改进提示词，而是让动态数据检索明确显示它找到了什么以及未找到什么，这样代理就不会通过推理默默填补缺口。会话层涵盖本次特定对话或工作流运行中发生的一切，我们在此最常见错误是存储原始对话历史并向前传递，这会使上下文窗口膨胀，将信号淹没在噪音中。改为存储结构化的决策记录，即记录决定了什么、依据是什么、以及运行中的哪个时间点，这样可以保持会话上下文精简，并在后续出现问题时使代理的推理可审计。在构建任何代理之前，值得问的架构问题是：在您的特定上下文中，三层中哪一层最可能引发故障，以及发生故障时是否有恢复路径，因为我们见过的大多数代理可靠性问题都可以追溯到三层中的某一层缺失、过时，或者以某种方式与另一层合并，导致无法独立更新或调试。