返回首页

对比阅读

对比阅读:Long-Task Agents 'Lose Their Memory'—The Real Problem Is Unmanaged Context 与 Agent 跑长任务容易'老年痴呆',根因不在模型 — 是上下文没人管

AEN
AgentSourcegraphLangChain·

Long-Task Agents 'Lose Their Memory'—The Real Problem Is Unmanaged Context

We have observed a counterintuitive fact: as the context window—the short-term working memory of an AI system—expanded from 32K to 128K, the failure rate of Agents on long-running tasks did not decline. The problem is not that the model has become less capable. Nobody is managing the “garbage collection” of its working memory. Tool results, retrieved passages, and stale plans pile up until critical evidence is pushed out. A technical article on Juejin proposes an engineering solution called a “context ledger.”

What this is

When an Agent handles a long-running task, a single session may involve dozens of tool calls, web scrapes, and large volumes of code. Over the past year, every major model company has raced to expand context windows—from 8K and 32K to 128K. But a context window is not an infinitely expandable chat history. It is closer to a hybrid of runtime memory, an evidence repository, and a task log. Without lifecycle management, any window—no matter how large—will eventually be clogged with low-value tool output, duplicate retrieval results, and debugging information.

The article’s solution is to give the Agent a “context ledger.” Every piece of information entering the window is recorded with five attributes: where it came from, its current utility, when it expires, what risks it carries, and whether the original text, a summary, or only a citation should be retained. Before each inference, the model does not simply append the latest N messages. Instead, it selects only what it needs from the ledger. For example, the user’s original objective is marked non-evictable; failed tool results receive a risk label and are excluded by default; and large documents are represented by pointers, with their contents reread only when necessary.

Industry view

This is not a single voice. In its 2026 practice guide, Sourcegraph elevated “context engineering”—the design of what a model can see during each inference—to a standalone topic. LangChain, meanwhile, breaks the strategy into four operations: writing, selecting, compressing, and isolating. These two companies represent two major strands of the Agent framework market—one focused on developer IDEs and the other on general-purpose applications—and both identified context governance as the top engineering problem in 2026.

Some teams remain cautious. One objection is that a ledger merely moves complexity from the model layer to the engineering layer; it does not fundamentally change the fact that long-task Agents tend to drift off course. Another concern is that building such a framework in-house creates a significant engineering burden for small and midsize teams, potentially slowing product delivery. Both criticisms are worth keeping in mind. An elegant technical solution does not mean that an off-the-shelf product is available today.

Impact on regular people

  • For enterprise IT: When evaluating or purchasing Agent products, ask vendors a specific question: How do you handle context bloat during long-running tasks? Do you have an automatic disposal mechanism?
  • For individual professionals: At this stage, there is no need to worry that “AI employees” will replace you. But it is worth recognizing that the Agents capable of reliably completing long-running tasks are the ones that can truly enter the workplace. Systems that manage only ten rounds of conversation offer more hype than practical utility.
  • For the consumer market: Consumer AI assistants for chat and writing will not adopt heavy-duty ledger systems in the short term. For “AI employee” products costing several thousand yuan per year, however, context governance will directly determine whether the product remains useful for an entire year.
来源: juejin.cn
BZH
AgentSourcegraphLangChain·

Agent 跑长任务容易'老年痴呆',根因不在模型 — 是上下文没人管

我们注意到一个反直觉的事实:上下文窗口(context window,即 AI 的短期工作记忆)从 32K 扩到 128K,Agent(能自主调用工具、查资料的"AI 助理")长任务翻车率反而没降。问题不是模型变笨,而是没人给它的"工作记忆"做垃圾分类——工具结果、检索片段、旧计划堆在一起,关键证据被挤出去。掘金这篇技术文章提出一套"上下文账本"的工程解法。

这是什么

Agent 跑长任务时,一次会话可能涉及几十次工具调用、网页抓取和大量代码片段。过去一年,所有大模型公司都在竞相把上下文窗口做大——从 8K、32K 到 128K。但窗口不是无限增长的聊天记录,更像运行时内存、证据仓库和任务日志的混合体;只要没有生命周期管理,再大也会被低价值工具输出、重复检索片段和调试信息塞满。

文章的解法是给 Agent 配一本"上下文账本":每条进入窗口的信息登记五件事——从哪里来、现在有什么用、什么时候过期、有什么风险、该原文保留、摘要保留还是只留引用。每次调用前,模型不是简单追加最近 N 条消息,而是从账本里按需挑选。比如用户原始目标设为不可驱逐,失败的工具结果打上风险标签后默认剔除,大段文档只放指针、要用时再读。

行业怎么看

这不是一家之言。Sourcegraph 在 2026 年的实践指南里把"上下文工程"(context engineering,即设计模型每次推理能看到什么)单列为新主题;LangChain 则把策略拆成"写入、选择、压缩、隔离"四步。这两家公司代表 Agent 框架的两条主线——一个偏开发者 IDE,一个偏通用应用——都在 2026 年把上下文治理当作头号工程问题。

不过也有团队保持谨慎。一种反对意见认为,账本机制本质是把复杂度从模型层挪到了工程层,并没有改变"长任务 Agent 容易跑偏"这件事;另一种声音指出,对中小团队来说,自建框架的工程门槛不低,可能反而拖慢产品落地。这两种质疑值得普通读者留意——技术方案漂亮,不等于今天就能买到现成产品。

对普通人的影响

  • 对企业 IT:采购 Agent 类产品时,可以问供应商一个具体问题——你们怎么处理长任务下的上下文膨胀?有没有自动丢弃机制?
  • 对个人职场:现阶段不必担心"AI 员工"取代你,但值得关心的是,能把长任务跑稳的 Agent 才是真正能进办公室的那种;只能聊 10 轮的,噱头大于实用。
  • 对消费市场:消费级 AI 助手(聊天、写作类)短期内不会用账本这类重方案;但几千块一年的"AI 员工"产品,上下文治理能力会直接决定它能不能用满一年。
来源: juejin.cn