LangChain 指出 2026 年上下文工程面临新挑战

Harrison's In the Loop

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

感觉大家正在向同一种 Agent 架构收敛：一个 LLM，在循环中运行，调用工具，并在沙箱中执行。Claude Code——或许是这种模式首个高调的体现——发布已经一年半多了。我们的 Agent 框架 Deep Agents 也上线了一年多。这种模式已经酝酿了一段时间。

这种收敛本身并无不妥，但它导致我最近交流的一些 AI 工程师产生了一种观点：“所有难题都已解决”或“没有新的 AI 工程问题需要解决了”。

当人们表达这种观点时，我认为他们主要是在谈论我们为了让 Agent 正常工作而进行的 上下文工程 实践。在某种程度上，他们是正确的——我们已经达成了一些相对标准化的上下文工程解决方案：

• 当内容超出上下文窗口限制时，总结长对话线程‍
• 卸载大型工具调用结果‍
• 利用 Skills 实现渐进式披露‍
• 使用 工具搜索 来应对大量工具‍
• 使用 Subagents 进行上下文隔离
• 将 Bash 作为主要工具

好消息是（对于像我这样的上下文工程爱好者来说），我认为我们正在见证 Agent 能力的一次阶跃式变化，或者至少是其使用方式的转变。具体来说，在过去几个月里，我与之交流过的每一位 Agent 开发者都在思考 主动、常驻运行、目标导向的 Agent。这类 Agent 的核心与编码 Agent 有很多相似之处，但也面临着一系列新的挑战。我在下文重点介绍其中几点。我们（在 LangChain 以及整个行业中）并不一定拥有这些问题的解决方案（或者至少没有通用的解决方案），因此思考这些问题是我近期最有趣的经历！

如何做到主动而不令人厌烦：这些主动型 Agent 在后台运行，要么 监听事件流，要么通过心跳机制被唤醒。一方面，它们需要能够向用户推送信息——这能营造出一种助手的氛围。另一方面，如果向用户推送过多的通知，就有让用户不堪重负的风险。将这种体验校准得恰到好处（不多不少，令人愉悦）仍然是一个艰难的上下文工程挑战！

记忆：Agent 的记忆是我们与开发者们长期讨论的话题。记忆系统最终包含两个部分：底层数据结构以及围绕数据的一个智能层（Agent）。数据结构通常相当简单（例如 文件、单个字符串）。智能层最难的部分在于确定要记住什么。与主动性类似，容易走向两个极端（要么什么都不记，要么记住了过于细枝末节的细节）。由于决定记住什么的这个智能层本身往往也是一个（简单的）Agent，因此关于“记住什么”以及“何时记住”的上下文工程仍然是一个未解决的问题。

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

目标追踪（Goal Tracking）：智能体正从执行任务转向致力于实现目标。像 Hone 这样的智能体就是很好的例子。如何设计能够分解目标为更小步骤、运行实验、获取反馈并持续迭代以实现更大目标的智能体？让智能体在追求目标的过程中尝试新实验（而不是仅仅重复旧做法）具有挑战性。让智能体思考宏观目标而非仅关注微小任务也具有挑战性。在长时间跨度内保持其一致性同样充满挑战。

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

浏览器使用（Browser Use）：对于编程智能体而言，最重要的工具是能够运行和执行代码的 bash 工具。而对于许多通用型智能体来说，浏览器正在成为这一关键工具。操控一个浏览器远比操作终端复杂得多！你是通过图像还是 DOM 进行交互？这两者都是大型对象——如何管理围绕它们的上下文？这仅仅是涌现出的部分问题。

几个月前，我或许会同意上下文工程领域并没有那么多未解之谜。但随着这些始终在线、主动式智能体的出现，我们正目睹一系列全新挑战的产生！真是令人振奋的时代。