New context engineering challenges in late 2026

📝 摘要 #

文章指出，Agent 架构正在收敛为「LLM + 循环 + 工具调用 + 沙箱」这一统一形态，并沉淀出一批标准化的上下文工程实践：长对话摘要、工具结果卸载、Skills 渐进披露、Tool Search、Subagents 上下文隔离、以 Bash 为主工具。这种收敛让部分工程师产生「难题已被解决」的错觉。作者认为，随着 proactive、always-on、goal-oriented agent 的兴起，上下文工程正迎来新一轮阶跃式挑战，并列出六个目前尚无通用解的问题。

核心概念： Agent 架构虽已趋同，但「常驻后台、目标驱动」的新形态把上下文工程从「管理单次对话窗口」推进到「管理长期、异步、多主体的注意力与状态」。

关键技术栈 / 关键要点：

1. Proactive 而不打扰 — 后台 agent 通过事件流或心跳唤醒，需要在主动推送价值与通知过载之间做校准。
2. Memory — 记忆系统由简单数据结构 + 智能层构成，最难的是「记什么」：全忘与过度细粒度都会失败。
3. Async — 长任务与长生命周期 subagent 成为常态，需要解决完成通知，以及主 agent 处于运行中、已结束或等待人工审批时的上下文衔接。
4. Goal Tracking — agent 从「做任务」转向「追目标」，要能拆解目标、跑实验、取反馈，并跨长时间保持一致性。
5. Alignment — 用户很难设计出 agent 无法钻空子的目标；盲目优化会触发 specification gaming（如「消除所有 bug」→ 删除代码库）。
6. Browser Use — 通用 agent 的主要工具正从 Bash 变为浏览器，DOM 与截图都是大对象，上下文管理远比终端复杂。

关键结论 / 实践建议： 这些问题目前没有通用解，是当下最值得投入的上下文工程研究方向；构建常驻 agent 时应优先设计记忆取舍、异步通知与目标对齐机制，而非只复用编码 agent 的既有模式。

It feels like everyone is converging on the same agent architecture: an LLM, running in a loop, calling tools, running in a sandbox. Claude Code - perhaps the first high profile manifestation of this - came out over a year and a half ago. Deep Agents, our agent harness, launched over a year ago. This pattern has been building for a while.

There’s nothing bad with that convergence per se, but it has led to a sentiment among some AI engineers that I’ve talked to recently that “all the hard problems are solved” or “there’s no new AI engineering problems to solve”.

When people express this sentiment, I think they are largely talking about the context engineering practices we do to make agents work. And to some extent they are right - there are a lot of standard-ish context engineering solutions we’ve all arrived at:

• Summarizing long threads when it gets to be too much for the context window
• Offloading large tool call results
• Skills for progressive disclosure
• Tool search to deal with a lot of tools
• Subagents for context isolation
• Bash as a primary tool

The good news (for context engineering aficionados like myself) is that I think we’re seeing a step function change in agent capabilities, or at least how they are being used. Specifically, over the past few months every agent builder I’ve chatted with has been thinking about proactive, always on, goal-oriented agents. The core of this agent shares a lot of similarities with coding agents, but there are a set of new challenges as well. I highlight a few below. We (at LangChain, and in the industry) don’t necessarily have solutions (or at least, general solutions) for these, so thinking about these has been the most fun I’ve had in a while!

How to be proactive without being annoying: These proactive agents run in the background and either listen to event feeds or are woken up with heartbeats. On one hand, they need to be able to push things to the user - that creates a sense of helping. On the other hand, if you push too many notifications to the user, you risk overwhelming them. Calibrating this to be a delightful experience (not too much, not too little) is still a hard context engineering challenge!

Memory: memory for agents has been something we’ve talked with builders about for a while. Memory systems end up having two parts: the underlying data structure and an intelligence layer (agent) around the data. The data structures are often pretty simple (files, a single string). The hardest part of the intelligence layer is figuring out what to remember. Similar to proactiveness, it’s easy to mess up on either extreme (remembering nothing at all, or remembering way too granular of details). Since this intelligence layer that decides what to remember is often a (simple) agent itself, the context engineering around what to remember and when is still an open problem.

Async: These agents are getting longer and longer running, and interacting with other systems (tools, other agents) that themselves are longer and longer running. However, you almost always want to make sure the main agent interacting with the user is responsive to new messages. These combine to lead to an architecture where more work is getting done in asynchronous tools and subagents. This presents a set of new context engineering challenges: how do you notify the main agent when that work is done? How do you handle situations where the main agent is still running, vs when it has finished? What if it's paused waiting for human approval?

Goal Tracking: Agents are moving from doing tasks to working towards goals. Agents like Hone are a great example of this. How do you design agents that can break down goals into smaller steps, run experiments, get feedback, and continue to iterate towards a larger goal. It’s challenging to get agents to try out new experiments in pursuit of a goal (and not just repeat things). It’s challenging to get agents to think about broad goals and not just small tasks. It’s challenging to keep them consistent over long time horizons.

Alignment: Related to the above. Goal design is hard by itself. It will be very hard for users to design goals that agents can not cheat. If agents blindly try to optimize a goal - they may accomplish it, but they may cheat in ways that we cannot anticipate. For example: the classic example of “get rid of all bugs in codebase” → deletes codebase entirely (no code = no bugs). How do you design a harness to keep agents not only focused on goals, but not overly optimize for those goals.

Browser Use: For coding agents, the most important tool was a bash tool that could run and execute code. For a lot of these more general purpose agents, the browser is becoming that tool. A browser is a lot more complicated to drive than a terminal! Do you interact with images or with the DOM? Both are large objects - how do you manage context around that? Those are just some of the questions that pop up.

A few months ago I would have maybe agreed that there weren’t that many open questions in context engineering. But with these always on, proactive agents we are seeing a whole new set of challenges arise! What a time to be alive.