不是删掉，而是挪走：用“加减乘除”读 LangChain Deep Agents 的上下文工程
LangChain 官方博客拆解 Deep Agents 的上下文工程：大结果落盘、旧对话摘要、子 Agent 隔离、技能按需加载，核心思路是把信息挪走而不是删掉。
上下文工程，就是给模型的注意力做账。
为什么要做账？
因为一个 Agent 跑得越久，它的上下文就越乱。
工具返回的大段结果、用户贴进来的长文档、走过的弯路、试错的日志，一层一层往窗口里堆。
堆到后来，真正要紧的那几句话，被埋在了最底下。
业内给这个现象起了个名字，叫“context rot”，上下文腐烂。
怎么办？
最直觉的办法是：删。
旧的删掉，长的删掉，看起来没用的删掉。
但是，删掉的东西，万一后面又要用呢？
LangChain 在 10 月 14 日发过一篇博客，作者是 Jess Weng，讲的就是它的开源 Agent 框架 Deep Agents 怎么对付上下文腐烂。这篇文章到这周还在开发者圈子里流传。
它的答案，可以用一句话概括：
不是删掉，而是挪走。
把东西挪出“活跃窗口”，但不丢掉，需要的时候再拿回来。
具体怎么挪？我用“加减乘除”四个字，把它的五招拆开来看。
一、先问一个问题：什么叫上下文？
要理解上下文工程，必须首先理解什么叫上下文。
什么叫上下文？
就是模型在回答这一句话之前，能“看见”的全部东西。
系统提示词、对话历史、工具结果、加载进来的文档，统统算。
那么，看见得越多，答得越好吗？
不一定。
假设你请了一位助理，每天早上把过去所有的会议记录、邮件、草稿，一股脑儿堆在他桌上，然后问他：今天最要紧的事是什么？
东西越多，他越难找到答案。
模型也一样。窗口有上限，注意力也有上限。
所以，上下文的质量，可以写成一个很简单的式子：
上下文质量 = 和当前任务相关的信息 ÷ 窗口里的全部信息
分子要够，分母要小。
Deep Agents 的五招，本质上都是在调这个分数。
二、减法：大块头先请出去
第一招，叫 offload，卸载。
据 LangChain 官方博客，Deep Agents 用 create_deep_agent 创建的 Agent，内置了压缩机制。
当一次工具调用返回的结果，大约超过 20,000 token，这个结果不会整段塞进上下文，而是写进一个文件：
/large_tool_results/{tool_call_id}
模型在窗口里看到的，只有这个结果的开头和结尾预览，外加文件路径。
用户发来的超大消息也一样。体量在大约 50,000 token 这一级的消息，会被放进 /conversation_history/ 目录。
这是不是很像仓库管理？
货架上只摆样品和标签，整箱的货放在后面库房。要用的时候，按标签去取。
第二招，叫摘要。
据官方博客，默认情况下，当上下文用量达到模型窗口的 85%，Deep Agents 会另外发起一次模型调用，把较早的消息压缩成摘要。最近的消息原样保留。
关键在于，摘要是可以“恢复”的。
原始内容会写回 /conversation_history/{session_id}.md，并没有丢。摘要也会一轮一轮叠加下去。
这两招加在一起，就是减法。
减的是窗口里的分母，不是减掉信息本身。
三、除法：吵闹的活，拆出去干
第三招，叫子 Agent（subagents）。
有些任务天生就很“吵”。
比如做一次市场调研，要搜很多网页，读很多资料，中间大量内容最后都用不上。
如果这些过程全都留在主 Agent 的窗口里，分母会迅速膨胀。
怎么办？
拆出去。
Deep Agents 的做法是，让子 Agent 在自己独立的窗口里干这件嘈杂的活，干完只把最终结果交回来。
官方博客举的例子，是一个叫 market-researcher 的子 Agent，最后只回 3 条 bullet。
这就是除法。
把一个大问题，除成几个小问题，各自在各自的房间里吵，主会场只听结论。
做过管理的人都明白这个道理：一个老板如果什么细节都要亲自过目，他的脑子很快就会被塞满；他真正需要的，是每个部门交上来的那一页纸。
四、加法：用到的时候再加进来
第四招，叫 Skills，技能按需加载。
据官方博客，Agent 启动时，只扫描各个 SKILL.md 文件的开头部分。
全文不读。
等到模型判断某个技能和当前任务相关，才用 read_file 把全文读进来。
这种做法有个专业名字，叫 progressive disclosure，渐进式披露。
为什么叫加法？
因为它不是一开始就把所有东西装满，而是先装目录，用到哪一章，再加哪一章。
分子在需要的时候变大，分母在不需要的时候保持很小。
五、乘法：记忆，跨会话复用
第五招，叫长期记忆。
据官方博客，Deep Agents 的长期记忆，就是 markdown 文件。
启动时加载，每一轮都注入系统提示词。Agent 学到了用户的偏好，可以回头去更新这个文件。
配置方式也很直白，比如：
memory=["/memories/AGENTS.md"]
为什么叫乘法？
因为前面四招，解决的是“这一次会话”里的问题。
而记忆解决的是“每一次会话”的问题。
一条偏好写进文件，以后每次开工都能用上。用的次数越多，这一次记录的价值就被乘得越大。
这里还有一个容易被忽视的细节。
官方博客提到，换模型、换厂商，可以共用同一个记忆文件。
这件事的意义，可能比技术本身更大。
六、记忆放在谁手里，是一个商业问题
为什么这么说？
因为记忆是 Agent 用得越久、越值钱的东西。
如果你的 Agent 记住的所有偏好、所有习惯，都锁在某一家厂商的系统里，你想换模型的时候，就要付出一笔看不见的成本：重新教一遍。
这就是转换成本。
转换成本越高，用户越走不掉。很多生意，赚的就是这部分钱。
Deep Agents 把记忆放在你自己可控的明文文件里，等于把这笔转换成本，交还给了用户。
你可以打开看，可以手动改，可以拿到另一个模型那里继续用。
我不评价这是商业策略还是工程洁癖。
但对于正在搭 Agent 的团队来说，这是一个值得认真对待的设计选择。
七、给搭 Agent 的团队三个自查问题
讲了这么多，怎么落地？
我建议你问自己三个问题。
第一，你的 Agent 是在删上下文，还是在挪上下文？
如果被压缩、被截断的内容再也找不回来，那么 Agent 每一次“忘记”，都可能在后面变成一次返工。
第二，你的主窗口里，有没有本该拆出去的“吵闹活”？
搜索、批量读取、反复试错，这些过程的价值在结果，不在过程。过程留在主窗口里，就是分母。
第三，你的记忆，放在谁手里？
想一想再回答。
如果明天要换一家模型厂商，你的 Agent 积累下来的东西，能不能带走？
如果想动手试试，据 FounderHeist 等报道，安装命令是 uv add deepagents；官方的上下文工程文档在 LangChain 文档站。
结语
回到开头那个式子。
上下文质量 = 和当前任务相关的信息 ÷ 窗口里的全部信息
减法，让分母变小；除法，把分母分给别人；加法，在需要的时候补足分子；乘法，让分子在每一次会话里反复生效。
窗口是有限的，注意力是有限的。
上下文工程的本质，不是让模型记住更多，而是让它在每一刻，只看见该看见的。
来源：LangChain 官方博客（2026-10-14）；Deep Agents 官方文档；FounderHeist。约 2 万 token 落盘、5 万 token 消息处理、85% 触发摘要等阈值据官方博客，可能随版本调整，以文档为准；安装命令据 FounderHeist 转述；“加减乘除”框架为作者概括。