大模型开发手记（十一）：LangChain 上下文 精讲（下）：Agent 上下文控制与工程化

目录前言一、瞬时与持久二、Model Context模型上下文瞬时上下文三、Tool Context工具上下文持久上下文的核心节点四、Life-cycle Context生命周期上下文持久上下文的全局管控五、核心协同三大工程化上下文与基础上下文的流转逻辑六、Agent 上下文工程化的最佳实践前言本文是“上下文精讲”系列的第二篇。在上一篇中我们厘清了上下文的分类与三种管理方式。本篇将基于LangChain官方文档深入探讨如何在实际开发中精准控制上下文让你的Agent更加可靠。在实际的Agent开发中我们常遇到这样的问题为什么模型有时会“忘记”之前的对话为什么工具调用总是不准确问题的根源往往不在于模型本身而在于我们没有给模型提供正确的上下文。LangChain官方文档中将上下文工程归纳为三个可控制的层面模型上下文Model Context、工具上下文Tool Context和生命周期上下文Life-cycle Context。掌握这三个层面的控制技术是构建可靠Agent的关键。所有的上下文工程化操作最终都是为了解决一个核心问题让 Agent 在真实场景中能拿到「正确的信息」做出「正确的决策」—— 这也是 LangChain 官方强调的上下文工程化是 AI 工程师的核心工作。一、瞬时与持久在讲上下文工程化控制之前必须先明确一个核心划分瞬时上下文 (Transient) 和持久上下文 (Persistent)瞬时上下文仅作用于单次模型调用修改后不会同步到 Agent 的 State/Store 中相当于 “临时修改”核心载体是Model Context模型上下文持久上下文作用于整个 Agent 生命周期 / 跨会话修改后会永久保存到 State/Store 中所有后续的模型调用、工具执行都能读取核心载体是Tool Context工具上下文和Life-cycle Context生命周期上下文。而这两种上下文的所有数据最终都来自上一篇讲的静态运行时上下文context、State、Store三者的关系可以简单理解为基础上下文是数据来源瞬时 / 持久是数据的使用方式三大工程化上下文是具体的落地载体。工程化上下文瞬时 / 持久核心作用数据来源基础上下文Model Context瞬时控制单次模型调用的输入提示词、工具、模型等静态运行时上下文、State、StoreTool Context持久工具对基础上下文的读 / 写操作静态运行时上下文、State、StoreLife-cycle Context持久模型 / 工具调用之间的全局上下文管控State、Store二、Model Context模型上下文瞬时上下文Model Context 是单次模型调用的所有输入的集合也是我们最常定制的部分。它的核心作用是为当前这一次 LLM 调用动态组装「系统提示词、message、工具、模型、输出格式」且所有修改都是临时的——仅对本次调用有效不会改变 State/Store 中的原始数据。LangChain 将 Model Context 拆解为五大核心模块「系统提示词、message、工具、模型、输出格式」且每个模块都能从「静态运行时上下文、State、Store」中读取数据做动态定制。Model Context 我们主要通过wrap_model_call和dynamic_prompt中间件实现这两个中间件内部对上下文的修改只是临时的仅限于当前模型调用下面举两个代码实例fromlangchain.agentsimportcreate_agentfromlangchain.agents.middlewareimportdynamic_prompt,ModelRequestdynamic_promptdefstate_aware_prompt(request:ModelRequest)-str:# 从State读取对话消息数量request.messages是State[messages]的快捷方式message_countlen(request.messages)base你是一个乐于助人的AI助手。# 对话超过10轮要求简洁回复ifmessage_count10:base\n本次对话较长请尽量简洁回答问题。returnbase# 创建Agent并挂载中间件agentcreate_agent(modelgpt-4.1,tools[],# 按需添加工具middleware[state_aware_prompt])fromlangchain.agentsimportcreate_agentfromlangchain.agents.middlewareimportwrap_model_call,ModelRequest,ModelResponsefromtypingimportCallablewrap_model_calldefinject_file_context(request:ModelRequest,handler:Callable)-ModelResponse:# 从State读取用户本次会话上传的文件信息uploaded_filesrequest.state.get(uploaded_files,[])ifuploaded_files:# 组装文件上下文file_info[f-{f[name]}({f[type]}):{f[summary]}forfinuploaded_files]file_contextf本次会话你可访问的文件\n{chr(10).join(file_info)}\n回答问题时请参考这些文件。# 注入到对话消息中messages[*request.messages,{role:user,content:file_context}]requestrequest.override(messagesmessages)returnhandler(request)agentcreate_agent(modelgpt-4.1,tools[],middleware[inject_file_context])三、Tool Context工具上下文持久上下文的核心节点Tool Context 的所有操作都会持久化到 State/Store 中后续的模型调用、工具执行都能读取到修改后的数据。Tool Context 的操作分为两类Reads读 和Writes写所有操作的对象都是上一篇讲的静态运行时上下文、State、Store。fromlangchain.toolsimporttool,ToolRuntimefromlangchain.agentsimportcreate_agentfromlanggraph.typesimportCommandtooldefauthenticate_user(password:str,runtime:ToolRuntime)-Command:用户认证成功后更新State中的认证状态# 模拟认证逻辑ifpassword123456:# 向State写入authenticatedTrueCommand实现状态更新returnCommand(update{authenticated:True})else:returnCommand(update{authenticated:False})agentcreate_agent(modelgpt-4.1,tools[authenticate_user])# 认证后State中会持久化authenticated字段后续工具可读取agent.invoke({messages:[{role:user,content:认证123456}]})四、Life-cycle Context生命周期上下文持久上下文的全局管控Agent 的运行是一个模型调用→工具执行→模型调用的循环而 Life-cycle Context 就是介于这些步骤之间的全局上下文管控核心作用是在模型和工具调用的间隙对上下文做全局的、持久的修改Life-cycle Context也是通过生命周期中间件实现与 wrap_model_call和dynamic_prompt等局部周期中间件不同生命周期中间件的修改会持久化到 State/Store中对所有后续步骤有效。中间件类型装饰器 / 函数Hook 层级修改的对象数据作用域瞬时 / 持久所属 Context模型调用级中间件dynamic_prompt模型调用前本次模型调用的提示词瞬时Model Context模型调用级中间件wrap_model_call模型调用前后本次模型调用的所有输入输出瞬时Model Context生命周期级中间件SummarizationMiddleware模型调用后 / 工具执行后State 中的 messages替换旧消息为总结持久Life-cycle Context自定义生命周期中间件自定义 middlewareHook before_agent/after_toolAgent 全局步骤State/Store任意字段持久Life-cycle Contextfromlangchain.agentsimportcreate_agentfromlangchain.agents.middlewareimportSummarizationMiddleware 检测对话历史的 token 数是否超过 4000 若超过用gpt-4.1-mini总结旧消息保留最新 20 条 将总结结果替换原始旧消息持久化写入 State 后续模型调用仅能看到总结结果 最新 20 条消息。 agentcreate_agent(modelgpt-4.1,tools[],middleware[SummarizationMiddleware(modelgpt-4.1-mini,# 用于总结的轻量模型trigger{tokens:4000},# 触发总结的token阈值keep{messages:20}# 保留最新的20条消息不总结)])五、核心协同三大工程化上下文与基础上下文的流转逻辑看到这里你可能会疑惑静态运行时上下文、State、Store和Model Context、Tool Context、Life-cycle Context到底是如何协同工作的这里用一张逻辑流转图讲清核心关系也是 Agent 上下文工程化的核心逻辑【静态运行时上下文/State/Store】→ 数据来源 ↓ 读 【Model Context】→ 瞬时组装提示词/工具/模型等→ 单次LLM调用 ↓ 指令 【Tool Context】→ 读基础上下文→ 执行工具 → 写基础上下文持久化 ↓ 循环 【Life-cycle Context】→ 中间件Hook → 全局修改基础上下文持久化→ 回到Model Context简单总结三大工程化上下文的角色Model Context消费者—— 仅从基础上下文中读取数据做瞬时组装不修改Tool Context生产者 消费者—— 既读取基础上下文的数据又向其写入数据是上下文流转的核心节点Life-cycle Context管理者—— 不直接参与模型 / 工具调用而是在间隙中全局管控基础上下文实现跨步骤的持久化修改。六、Agent 上下文工程化的最佳实践结合 LangChain 官方文档和实际项目经验总结 几条落地性极强的最佳实践让 Agent 的上下文管理更稳定、更易维护先静态后动态初期开发时先用静态提示词、静态工具集、静态模型实现 Agent 的核心功能确认功能可用后再逐步添加动态逻辑如动态提示词、动态工具筛选。避免一开始就做复杂的动态上下文导致问题难以排查。增量测试单变量修改添加上下文工程化的功能时每次仅修改一个变量比如先加动态提示词测试通过后再加动态工具并做好测试。多变量同时修改会导致无法定位问题尤其是在复杂的 Agent 中。明确瞬时 / 持久避免数据混乱修改上下文时必须明确是瞬时修改仅本次模型调用还是持久修改写入 State/Store单次调用的临时需求如注入本次文件信息→ 用 Model Context会话 / 跨会话的持久需求如认证状态、用户偏好→ 用 Tool Context/Life-cycle Context。优先使用内置中间件减少自定义LangChain 提供了大量内置中间件如SummarizationMiddleware、LLMToolSelectorMiddleware这些中间件经过官方优化稳定性远高于自定义中间件。除非有个性化需求否则优先使用内置中间件。监控上下文大小避免 Token 过载LLM 的上下文窗口是有限的必须监控 Model Context 的总 Token 数尤其是对话历史和工具描述及时做总结、裁剪。可以结合SummarizationMiddleware和自定义中间件实现 Token 的自动管控。