文章指出Agent 原型能跑但上线翻车常见原因并非模型能力不足而是上下文处理不当。通过合理的上下文工程可以在合适的时机将准确的信息和工具传递给模型。文章详细介绍了模型上下文、工具上下文和生命周期上下文的管理方法以及如何通过写出去、选进来、压缩和隔离等手段优化上下文窗口从而提升大模型的性能和可靠性。有时候Agent 原型能跑但是上线却翻车常见原因不是模型不够聪明而是它看见的上下文不对。例如工具描述含糊或者三轮前的错误结论还躺在历史里污染后面的推理。上下文工程就是来解决在合适的时机把准确的信息和工具塞给模型。环境基线Python 3.13、langchain1.3.2。模型从common.models.get_model拿。具体钩子写法回扣第 9–10 篇记忆回扣第 8、12 篇——本篇讲怎么组合、怎么取舍。一、概述Agent 循环其实就两步在转调模型 →可选执行工具 → 再调模型直到模型不再要工具。每一步模型都只看见你这次喂进去的那一包东西。失败通常有两种情况模型能力不够任务本身超出模型上限换更强模型或拆任务。正确上下文没到位指令过时、历史太脏、工具太多、权限没过滤、长期偏好没注入。线上更多是第二种。所以上下文工程不是写漂亮的 prompt而是控制系统里所有进入模型调用的输入以及步骤之间持久化了什么。上下文有三类类型你控制什么临时 / 持久模型上下文Model系统提示、消息、工具列表、用哪个模型、响应格式多为临时单次调用可见工具上下文Tool工具能读到什么、写出什么state / store / context持久写进 state/store生命周期上下文Life-cycle模型与工具之间摘要、防护、日志、跳转持久改 state或拦截临时修改和持久修改的区别临时修改持久修改修改的是什么本次模型调用即将看到的输入数据包消息列表、系统提示、工具列表Statecheckpointer 存下来的会话状态或 Store长期记忆从哪里生效从wrap_model_call或ModelRequest.override()里改只影响当前这一次模型调用从before_model、工具、Command(update...)里改写入 State 后后续所有轮次都会看到会不会进 checkpointer❌ 不会✅ 会典型场景本轮临时多塞一条上下文临时换一个模型跑一次删掉一条敏感消息把长历史压缩成摘要保存用户偏好搞混这两类最常见的症状是你以为「裁掉了历史」trace 里下一轮又回来了因为你只做了临时 override。上下文的3个数据源数据源别名范围例子Runtime Context静态配置单次 / 单会话运行user_id、角色、API Key、DB 连接State短期记忆当前 threadmessages、上传文件元数据、authenticatedStore长期记忆跨 thread用户偏好、沉淀事实读的时候记住口诀身份与密钥走 context本轮对话走 state跨会话事实走 store。 写的时候也一样别把 API Key 写进 messages。二、四种手段上下文窗口是最贵的资源。管理窗口常见手段就四种可以组合着用手段干什么本系列对应写出去Write大块中间产物别堆在 messages落到文件 / store窗口只留引用或摘要第 12 篇 storeDeepAgents 文件系统选进来Select从 state/store/context 挑相关片段注入而不是全量倾倒dynamic_prompt、消息注入、工具过滤压缩Compress历史太长就摘要、裁剪、清旧 ToolMessage第 8–9 篇 Summarization / ContextEditing / trim隔离Isolate不同权限看不同工具脏任务丢给子 Agent主窗口保持干净第 10 篇筛工具第 16 篇多 Agent怎么选用会反复用、又很大 → 写出去需要时再选进来。只跟当前问题相关 → 选进来其余别进窗口。已经进窗口且过时 → 压缩。会互相污染或权限不同 → 隔离。三、模型上下文模型上下文是每次调用模型前传给模型的那组完整输入参数。它由五个模块组成每个模块都可以在运行时动态调整数据来源仍然是 state / store / context模块控制内容提示system prompt、动态指令消息消息历史全量/摘要/裁剪后工具工具列表按权限过滤后模型具体用哪个模型主/备/按任务切换格式响应格式结构化输出、JSON Mode这五块在每次模型调用前组装成一个“输入包”模型拿到的就是这个包的完整内容。1 系统提示一般静态的system_prompt够用就不要用动态。当需要按轮次、角色、偏好切换时用dynamic_promptfrom langchain.agents.middleware import ModelRequest, dynamic_prompt dynamic_prompt def state_aware_prompt(request: ModelRequest) - str: 消息变长时要求更短admin 放开写操作说明。 base 你是客服助手。涉及订单必须调工具核实。 n len(request.messages) if n 10: base /n对话已较长回答尽量简短。 role getattr(request.runtime.context, user_role, user) if role admin: base /n当前为管理员可指导写操作仍需确认危险动作。 elif role viewer: base /n只读账号只引导查询不要建议删除或改库。 return base上面的代码从 store 读取偏好然后根据偏好再拼一句特有的提示前面一篇文章也有完整写法。原则是提示里写纪律和约束别把整份用户档案防进去。2 消息可以临时注入也可以持久改历史。临时注入需要模型这轮多看见一段资料但不想写进会话历史时用wrap_model_calloverride(messages...)from collections.abc import Callable from langchain.agents.middleware import ModelRequest, ModelResponse, wrap_model_call wrap_model_call def inject_file_context( request: ModelRequest, handler: Callable[[ModelRequest], ModelResponse], ) - ModelResponse: 把本会话上传文件的摘要临时拼进请求不改 state[messages]。 files request.state.get(uploaded_files, []) if not files: return handler(request) lines [f- {f[name]} ({f[type]}): {f[summary]} for f in files] tip 本会话可引用的文件/n /n.join(lines) # 追加在末尾模型对尾部指令通常更敏感 messages [*request.messages, {role: user, content: tip}] return handler(request.override(messagesmessages))为什么是临时的关键就是最后一步handler(request.override(messages...))request.messages原本是从state[messages]checkpointer 持久化的历史里取出来的。request.override(messages...)创建了一个全新的请求副本把messages替换成了“原始消息 临时追加的文件摘要”。这个副本只传给了这一次handler()调用没有被写回state。所以本轮模型能看到追加的文件摘要但state[messages]里并没有多出这条消息。下一轮调用模型时从state[messages]读到的还是原来的历史追加的摘要已经消失了。若要永久改历史删轮次、插入摘要走before_model/SummarizationMiddleware/ExtendedModelResponseCommand前面第 8、10 篇讲过def before_model(self, state: AgentState) - dict: files state.get(uploaded_files, []) if not files: return {} # 直接在 state[messages] 里追加一条消息 tip f本会话可引用的文件{len(files)} 个 return {messages: [*state[messages], HumanMessage(contenttip)]}before_model返回的{messages: ...}会经过 reducer 合并进statecheckpointer 会把它持久化。后续所有轮次都能看到这条追加的消息。选临时还是持久只影响当轮推理选临时希望之后每轮都看见选持久。3 工具定义清楚工具暴露要少。工具的 name / description / 参数说明就是给模型看的说明书。上下文工程另外管两件事别一次塞太多工具选项多了选错率上升。按权限/阶段过滤用request.override(tools...)示例wrap_model_call def filter_tools( request: ModelRequest, handler: Callable[[ModelRequest], ModelResponse] ) - ModelResponse: 根据用户角色和认证状态动态过滤可用工具列表。 # 1. 从 context 里取当前用户角色由调用方在 invoke 时传入 role getattr(request.runtime.context, user_role, user) # 2. 复制一份当前工具列表不能直接改 request.tools它是只读的 tools list(request.tools) # 3. 按角色过滤非管理员看不到 delete_order if role ! admin: tools [t for t in tools if getattr(t, name, ) ! delete_order] # 4. 按认证状态过滤未认证用户只能看到 public_ 开头的工具 if not request.state.get(authenticated, False): tools [t for t in tools if str(getattr(t, name, )).startswith(public_)] # 5. 用过滤后的工具列表覆盖本次请求继续执行 return handler(request.override(toolstools))工具特别多时第 9 篇的LLMToolSelectorMiddleware可再先筛一轮。4 模型与响应格式短对话用便宜模型、超长对话切大窗口VIP 用更强模型——都是request.override(model...)第 10 篇已经讲过。结构化落库用response_format第 7 篇也可以按轮次切换简单/详细 schema同样override(response_format...)。这五块的共同点从三个数据源读信号用 middleware 改当次 ModelRequest。可以翻前面的文章复习一下。四、工具上下文在上下文工程里工具扮演双重角色执行动作查订单、发邮件、改数据等这是“干活”的一面搬运信息从外部系统读数据喂给模型或把模型产生的结论写回记忆这是“信息管道”的一面很多教程只讲第一面但生产环境里第二面同样重要甚至更关键。因为工具是模型和外部世界之间的唯一桥梁。模型需要通过工具来看见它本身看不到的东西数据库、API、用户偏好等也需要通过工具来记住它本身记不住的东西跨会话的长期记忆。1 读操作工具在读数据时有三个数据来源可以用。它们各自的生命周期和用途不同来源写法生命周期典型用途runtime.context调用invoke()时传入单次请求用户身份、API Key安全凭证不进消息历史runtime.state由 checkpointer 持久化跨轮次但限于当前会话thread本轮是否登录、临时标记runtime.store跨会话持久化InMemory/Postgres永久除非主动删除用户长期偏好、历史摘要三个来源可以同时用示例from dataclasses import dataclass from langchain.tools import ToolRuntime, tool dataclass class Context: user_id: str api_key: str tool def fetch_my_orders(status: str, runtime: ToolRuntime[Context]) - str: 按状态查当前用户订单。status: pending|shipped|delivered。 # 1. 从 context 取身份凭证不进 messages模型看不到安全 uid runtime.context.user_id key runtime.context.api_key # 2. 从 state 取会话状态当前 thread 内持久 if not runtime.state.get(authenticated, True): return 未登录无法查询。 # 3. 从 store 取跨会话偏好可选不同用户不同风格 prefs None if runtime.store: item runtime.store.get((preferences,), uid) prefs item.value if item else None # 4. 真正干活调外部 API rows call_order_api(uid, status, key) # 伪代码 # 5. 返回摘要不是全文 # 关键原则工具返回值会进入 messages变成后续模型的上下文。 # 如果返回几万字的全文模型上下文会被撑爆。 # 所以这里只返回摘要 必要时提供 id让模型按需再查详情。 return summarize_orders(rows, style(prefs or {}).get(style, short))上面代码里context和state分工明确context存外部传入的身份凭证state存 Agent 自己维护的会话状态如登录标记。但是需要注意不建议一个工具干那么多事一般一个工具专注于一件事最好。2 写操作写有两种不同的目标取决于你想写进哪一层写进 State当前会话内持久跨轮次但不跨 thread写进 Store跨会话持久真正的长期记忆from langgraph.types import Command tool def mark_authenticated(ok: bool, runtime: ToolRuntime) - Command: 更新本会话登录标记写入 state持久到 checkpointer。 # Command(update...) 会把数据写进当前会话的 State # 后续轮次都能读到 runtime.state.get(authenticated) return Command(update{authenticated: ok})什么是写State什么时候写Store简单判断标准关闭浏览器再打开这条信息还应该保留吗应该保留 → 写 Store不需要保留 → 写 State注意工具返回的字符串会被封装成ToolMessage追加到messages里变成后续模型调用的上下文的一部分。所以工具返回值也会成为模型上下文所以返回要短、要结构化、错误要可修正。爬一整个网页塞进 ToolMessage是上下文工程里最常见的自杀式写法应写出去再选进来。五、生命周期除了前面讲的提示词和工具模型调用与工具调用之间中间件也能做修改或者跳转压缩SummarizationMiddleware、ContextEditingMiddleware第 8–9 篇讲过可以去复习下持久改 messages。防护PII、输入过滤、jump_toend第 11 篇讲过该拦的别进模型。跳转配额用尽跳end强制先走工具跳tools第 10 篇讲过。新手最容易踩的坑是用override(messages...)做了临时裁剪以为自己“管住了历史”结果下一轮完整历史又回来了。所以务必把这两者区分清楚临时 trimoverride(messages...)摘要压缩SummarizationMiddleware改的是谁本次模型调用收到的请求副本requeststate[messages]checkpointer 持久存储下一轮还在吗❌ 不在了完整历史会重新从 state 读出来✅ 已经压缩成摘要旧消息已被替换适用场景单次调用降噪比如本轮不需要看太老的历史长会话持续治理比如对话超过 50 轮后自动压缩长期运行的生产会话不要只靠临时 trim因为治标不治本state[messages]里的历史还在持续膨胀。推荐组合摘要压缩处理人话轮次用户和模型的对话历史把旧轮次压缩成摘要控制消息总量ClearToolUses或类似机制处理巨型工具输出比如爬虫返回的几万字 HTML把它们从历史中清理或压缩不让它们持续占用上下文窗口两者配合才能在长会话里既保留关键语义又不让上下文撑爆。六、预算表、腐化与策略对比1 一份可套用的窗口预算假设模型上下文 128KAgent 场景别用满。可先按下面切按 token 粗估可按产品改比例区块建议占比内容系统提示 动态约束5%10%角色、工具纪律、合规、偏好摘要工具 schema10%20%本轮可见工具能少则少长期记忆选段5%10%store 检索 top‑k不是全库近期对话 / 摘要40%50%keep 最近 N 条 更早摘要当轮工具结果15%25%只留当前任务相关大结果外置安全余量10%防突发放量、结构化输出开销三条硬规则工具结果单次超过余量可以写出去在messages 里留指针。长期记忆进 prompt 不超过 top‑35 条。系统提示增长要有人审动态拼接最容易把窗口吃干。2 上下文腐化与中间遗忘窗口不是越大越好。把更多历史塞进上下文不一定让模型更聪明反而可能引入三种常见问题。问题一上下文腐化Context Poisoning现象早期某轮模型说错了比如把订单号 ORD-123 误说成 ORD-456这个错误结论还留在历史消息里。后面轮次模型看到这条历史把它当事实引用继续往外扩散错误。口头纠正告诉他前面错了有一定作用但是效果不明显。例如在当前轮说“你之前说错了”那条错误的历史消息仍然原样留在state[messages]里。模型在后续轮次读历史时既能看到“错误结论”也能看到“你纠正了”但它有可能忽略纠正、继续采信错误结论尤其是错误结论在消息列表中更靠近头部高注意力区域时。正确做法是把错误消息删掉或替换掉# 在中间件里定位并删除包含错误结论的消息 def before_model(self, state: AgentState) - dict[str, Any]: messages state[messages] filtered [ m for m in messages if not (m.type ai and ORD-456 in m.content) ] # 追加一条修正后的正确消息 corrected AIMessage(content我重新核实了你的订单号是 ORD-123) return {messages: [*filtered, corrected]}问题二中间遗忘Lost in the Middle这是 LLM 的已知注意力缺陷。当上下文很长时比如超过 1 万 Token模型对开头和结尾的内容记忆更清晰对中间部分的关注度显著下降。如果你的关键约束比如“禁止编造订单号”埋在超长 prompt 的正中间模型很可能在生成时漏掉它。正确做法重要纪律放系统提示始终在模型视野的“头部”当前指令放消息末尾离模型生成最近“尾部”注意力最高中间部分只放“参考资料”且尽量短不依赖模型精确记住每一处细节# 消息排序策略 messages [ system_prompt, # 头部长期规则、安全边界 *chat_history, # 中间参考资料尽量压缩 current_instruction, # 尾部当前任务指令模型注意力最集中 ]问题三工具噪声工具调用失败了返回一大段错误堆栈工具搜索没结果返回“未找到任何匹配项”重试了 5 次每次都是同样的失败日志。这些失败结果全部堆在消息历史里占窗口、分散注意力、干扰模型判断。正确做法工具返回要短错误返回一句话说清楚“什么错了 怎么修”不要堆栈清理失败的工具结果用ClearToolUsesMiddleware清理掉已执行的工具调用记录只保留最终有用的那几条限制重试次数同一个工具连续失败 3 次以上不再让它继续尝试七、完整示例带预算意识的客服 Agent把动态提示、工具过滤、摘要、长期偏好选进拼在一起。重点看middleware组合而不是再造一套业务。第 13 篇上下文工程组合——注入偏好、过滤工具、压缩历史。 from collections.abc import Callable from dataclasses import dataclass from langchain.agents import create_agent from langchain.agents.middleware import ( ModelRequest, ModelResponse, SummarizationMiddleware, dynamic_prompt, wrap_model_call, ) from langchain.tools import ToolRuntime, tool from langgraph.checkpoint.memory import InMemorySaver from langgraph.store.memory import InMemoryStore from common.models import get_model # 1. 定义上下文调用方传入的身份信息 # context 与 state 分离context 存身份凭证不经过模型state 存会话状态 dataclass class Context: user_id: str user_role: str # user | admin # 2. 准备长期记忆存储InMemory 仅用于演示 # 生产环境换成 PostgresStore store InMemoryStore() # 预置一条用户偏好用户 u_1001 喜欢简短回复名叫张三 store.put( (preferences,), # namespace按用户隔离 u_1001, # key用户 ID {communication_style: short, name: 张三}, # value偏好数据 ) # 3. 定义工具 # 注意工具的 name/description 就是给模型的说明书写得越清楚模型用越准 tool def public_get_order(order_id: str, runtime: ToolRuntime[Context]) - str: 查询订单状态。order_id 形如 SO-12345。 # runtime.context.user_id 由调用方传入不经过模型防串号 return f{order_id}: 运输中用户 {runtime.context.user_id} tool def delete_order(order_id: str) - str: 删除订单仅管理员。 return fdeleted {order_id} # 4. 中间件1动态提示词长期偏好注入 # dynamic_prompt 在每次模型调用前执行返回值拼进 system prompt # 适用场景需要每轮都生效但不需要用户感知的信息偏好、约束 dynamic_prompt def budgeted_prompt(request: ModelRequest) - str: 系统提示保持短 - 基础角色纪律固定 - 从 store 读用户偏好只取需要的字段不整份倾倒 - 历史较长时加一句提示动态感知 base 你是电商客服。查单用 public_get_order。回答简洁。 # 从 store 读取该用户的长期偏好 uid request.runtime.context.user_id item request.runtime.store.get((preferences,), uid) if request.runtime.store else None if item: style item.value.get(communication_style, balanced) name item.value.get(name) if name: base f/n用户称呼{name}。 # 只取名字不暴露其他隐私字段 base f/n偏好风格{style}。 # 只取风格不整份 JSON 倒进去 # 动态感知消息超过 8 条时追加一句让模型注意控制篇幅 if len(request.messages) 8: base /n历史已较长避免重复寒暄。 return base # 5. 中间件2按角色过滤工具临时覆盖 # wrap_model_call 包住每次模型调用通过 override(tools...) 临时修改本轮可见工具 # 适用场景权限隔离、A/B 测试、阶段式工具暴露 wrap_model_call def select_tools( request: ModelRequest, handler: Callable[[ModelRequest], ModelResponse], ) - ModelResponse: 隔离非 admin 看不到 delete_order。 好处 1. 减少工具 schema 占用模型少看一个工具定义 2. 降低误调用概率模型根本不知道有这工具 tools list(request.tools) if getattr(request.runtime.context, user_role, user) ! admin: tools [t for t in tools if getattr(t, name, ) ! delete_order] # override 只影响本轮请求不改 state下一轮重新执行本钩子 return handler(request.override(toolstools)) # 6. 组装 Agent # middleware 列表顺序很重要 # SummarizationMiddleware持久改 state→ budgeted_prompt读 store 拼提示→ select_tools临时改请求 agent create_agent( modelget_model(deepseek, temperature0), # 工具完整列表实际可见由 select_tools 中间件过滤 tools[public_get_order, delete_order], # 长期记忆后端 storestore, # 短期记忆会话状态后端 checkpointerInMemorySaver(), # 上下文结构定义 context_schemaContext, # 中间件按顺序叠加 middleware[ # 1. 压缩持久摘要给长会话腾窗口 # trigger(tokens, 3000)消息超过 3000 token 时触发压缩 # keep(messages, 12)压缩后保留最近 12 条原始消息其余变摘要 SummarizationMiddleware( modelget_model(deepseek, temperature0), trigger(tokens, 3000), keep(messages, 12), ), # 2. 动态提示从 store 读偏好拼进 system prompt每轮执行 budgeted_prompt, # 3. 工具过滤按角色屏蔽 delete_order每轮执行 select_tools, ], ) # 7. 运行验收 if __name__ __main__: ctx Context(user_idu_1001, user_roleuser) result agent.invoke( {messages: [{role: user, content: SO-12345 到哪了}]}, config{configurable: {thread_id: ce-1}}, # 会话 ID用于隔离不同会话 contextctx, # 当前用户身份注入到 runtime.context ) print(result[messages][-1].content) # 8. 验收清单查 LangSmith / 本地 trace # 1. 非 admin 的模型请求里有没有 delete_order schema # → 用 trace 看 request.tools应该只有 public_get_order # # 2. 系统提示是否只有短偏好而不是整份 JSON 档案 # → 看 system prompt 里是 偏好风格short 还是 {communication_style: short, ...} # # 3. 对话变长后是否出现摘要消息而不是无限上涨的 raw history # → 看 state.messages 里是否出现了一条 SummarizationMiddleware 插入的摘要消息自己验收时看 LangSmith / 本地 trace非 admin 的模型请求里有没有delete_orderschema。系统提示是否只有短偏好而不是整份 JSON 档案。对话变长后是否出现摘要消息而不是无限上涨的 raw history。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取