Agent 应用落地思考——Context 相关

上下文其实涉及到的就是每次给大模型看什么，怎么去管理上下文以及最后给用户执行器看什么。

它是模型在单次推理时接收到的全部信息总和，不仅包含 Prompt，还包含了背景设定、历史记录、检索内容等所有文本。

典型的组装块包括：

• System Prompt：全局人设、基础约束。
• History：近期的多轮对话记录。
• RAG / Memory：从外部数据库检索出来并插入的参考文本。
• Tool Result：外部工具执行后返回的数据（比如接口调用的 JSON）。
• State：Agent 当前所处的业务节点或状态机信息。

为什么要用上下文？

因为 LLM 本质上没有任何记忆。

它是一个无状态的纯函数，权重在训练完成后就固定了，不会因为你跟它聊了两句就实时更新神经网络。从这个角度看，单纯 LLM 并不具备自己进化的能力。

为了让它“显得”有记忆，你必须在每一次 API 调用时，把之前的聊天记录像打包行李一样，全部塞进 Context 里重新发给它。

Context Window（上下文窗口）

上下文的容量是有限的。

Context Window（上下文窗口）是模型单次能处理的最大 Token 数量上限（比如 128K、1M）。

如果组装后的 Context 超过这个阈值，通常会发生两件事之一：

• API 层面直接报错，拒绝响应。
• 模型丢失了最早放入的信息，遗忘产生幻觉。

为什么聊天越久效果越差？

随着对话轮数增加，Context 的信噪比会断崖式下降。

模型的注意力会被大量无效信息稀释，上下文中堆积了太多无效的中间步骤、寒暄和纠错过程，模型被这些“噪音”淹没，找不到真正的核心指令。

另外，现有的注意力机制对文本开头（规则）和结尾（最新提问）最敏感，而对夹在中间的大量历史内容容易忽略。

聊得越久，中间的废话越多，Agent 就越容易违背人设。

History（历史对话）

至于对话历史保存多少轮，建议根据实际业务场景需求来确定，没有一个标准。

如果一定要保存大量历史，就需要做压缩，也就是总结（Summary）。

虽然总结会丢失部分信息，但是保留核心事实和结论即可。

Tool Result

调用工具后返回的结果一定要进行清洗。

例如 RAG 检索出的知识，不能直接保留全部原文，而是在必要的节点进行筛选、总结之后再放入 Context。

State

至于 LangGraph 中的 State，最终也会加入 Context 中，但是在结构上它与 Context 还是独立的。

Memory

对于结果的清洗、对话的总结以及关键特征的提取，最后都会沉淀为 Agent 的记忆（Memory）。

但 Memory 往往以键值对形式保存，只有触发记忆检索，在必要的时候才会提取并加入 Context，而不是每轮对话都全部加载。

Context 管理建议

对于一个完整的 Context：

• System Prompt 置顶，不轻易变动。
• State 根据节点功能按需注入和增加。
• RAG、Memory 和 Tool Result 按需接入。
• History 使用滑动窗口，并及时进行 Summary。

在多 Agent 架构中，Context 需要进行严格隔离，通过共享 State 与总线消息进行传递，以免底层的幻觉互相污染。