LangChain 谈 2026 年底智能体上下文工程的新挑战

LangChain：Blog·2026-11-03 00:51· 2 小时前AI 评分48

2026 年末上下文工程面临的新挑战

AI 导读

LangChain 指出，随着主动式、常驻、目标导向的智能体兴起，上下文工程出现一批新难题。文章列举了主动推送与打扰的平衡、记忆取舍、异步子任务通知、目标跟踪、目标对齐（如"清除所有 bug"导致删库）以及浏览器工具上下文管理等问题，并称业界尚无通用解法。

正文 · 原文

似乎所有人都在向同一种智能体架构靠拢：一个 LLM 在循环中运行、调用工具、在沙箱中执行。Claude Code——或许这是该架构首个高调亮相的实例——发布于一年半多以前。我们的智能体框架 Deep Agents 也已在一年多前推出。这种模式已经酝酿了一段时间。

这种趋同本身并无问题，但它导致我最近交流过的一些 AI 工程师产生了一种情绪，认为“所有难题都已解决”或“已经没有新的 AI 工程问题需要解决了”。

当人们表达这种情绪时，我认为他们主要指的是我们为了让智能体工作而实践的上下文工程。在某种程度上他们是对的——我们已经形成了一大批大致标准的上下文工程解决方案：

• 对过长的对话线程进行摘要，当它超出上下文窗口容量时‍
• 将大型工具调用结果卸载‍
• 用于渐进式披露的技能（Skills）‍
• 用于应对大量工具的工具搜索‍
• 用于上下文隔离的子智能体
• 将 Bash 作为主要工具

好消息是（对我这样的上下文工程爱好者而言），我认为我们正在看到智能体能力出现阶跃式变化，或者至少是其使用方式的变化。具体来说，在过去几个月里，我交流过的每一位智能体构建者都在思考主动式、常驻、目标导向的智能体。这类智能体的核心与编码智能体有许多相似之处，但也带来了一系列新挑战。我在下面重点列出几个。我们（在 LangChain 以及整个行业）未必有解决方案（或者至少没有通用解决方案），因此思考这些问题是我一段时间以来最有趣的事！

如何做到主动而不惹人烦：这些主动式智能体在后台运行，要么监听事件流，要么通过心跳被唤醒。一方面，它们需要能够向用户推送内容——这会营造出一种有帮助的感觉。另一方面，如果你向用户推送太多通知，就有可能让他们不堪重负。将其校准为一种令人愉悦的体验（不多不少）仍然是一个艰难的上下文工程挑战！

记忆：智能体的记忆是我们与构建者讨论了一段时间的话题。记忆系统最终包含两部分：底层数据结构和围绕数据的智能层（智能体）。数据结构通常相当简单（文件、单个字符串）。智能层最难的部分是弄清楚该记住什么。与主动性类似，两个极端都很容易出错（什么都不记，或者记住过于细碎的细节）。由于决定记住什么的这个智能层本身通常就是一个（简单的）智能体，围绕记住什么以及何时记住的上下文工程仍然是一个未解决的问题。

异步：这些智能体运行时间越来越长，并且会与同样运行时间越来越长的其他系统（工具、其他智能体）交互。然而，你几乎总是希望与用户交互的主智能体能够对新消息保持响应。这些因素共同促成了一种架构：更多工作正在异步工具和子智能体中完成。这带来了一系列新的上下文工程挑战：当这些工作完成时，你如何通知主智能体？你如何处理主智能体仍在运行与已经结束的不同情况？如果它暂停等待人类批准呢？

目标跟踪：智能体正在从执行任务转向朝着目标努力。像Hone这样的智能体就是一个很好的例子。你如何设计智能体，使其能够将目标分解为更小的步骤、运行实验、获取反馈，并继续迭代以朝着更大的目标前进。让智能体在追求目标时尝试新的实验（而不只是重复）很有挑战性。让智能体思考宽泛的目标而不只是小任务很有挑战性。让它们在长时间跨度内保持一致也很有挑战性。

对齐：与上述内容相关。目标设计本身就很困难。用户很难设计出智能体无法作弊的目标。如果智能体盲目地试图优化某个目标，它们可能实现该目标，但也可能以我们无法预料的方式作弊。例如：经典例子是“清除代码库中的所有 bug” → 完全删除代码库（没有代码 = 没有 bug）。你如何设计一个框架，使智能体不仅专注于目标，而且不会过度优化这些目标。

浏览器使用：对于编码智能体来说，最重要的工具是能够运行和执行代码的 bash 工具。对于许多这类更通用的智能体来说，浏览器正在成为这样的工具。浏览器比终端更难驱动！你是与图像交互还是与 DOM 交互？两者都是大型对象——你如何管理围绕它们的上下文？这些只是出现的一些问题。

几个月前，我可能还会同意上下文工程中并没有那么多开放问题。但有了这些始终在线、主动运行的智能体，我们正看到一系列全新的挑战出现！生逢其时。

来源：LangChain：Blog · langchain.com