AI Agent 上下文不是越长越好

上一讲：AI 看到回答前的内容｜生成式AI｜第五讲

上一篇我们已经把上下文掰开讲过一遍。

模型在输出答案之前，实际接触到的信息，往往远不止用户刚输入的那一句。

它还可能读到系统规则、历史对话、长期记忆、外部资料、工具返回、示例，以及中间推导。

到了 AI Agent 这里，事情就会再往前复杂一层。

在单轮问答中，用户提一个问题，模型给出一个回答。

Agent 不只是负责答复。

它会围绕目标先做规划，接着调用工具，查看结果，再判断下一步怎么走。

这让 Agent 更像一个可以持续运转的系统。

但这也带来一个很现实的难题：

它每执行一步，都会生成新的上下文。

上下文越滚越大，Agent 就越容易被前面的记录拖慢、带偏，甚至“越聊越乱”。

可以先把 Agent 当成一个循环。

它先接到一个目标。

然后决定采取一个动作。

这个动作可能是搜网页、读文件、调接口、跑代码、点页面，或者去问用户。

动作完成后，系统会给出一个观察结果。

模型再依据这个结果决定下一步。

这个循环可以概括成三件事：

Goal。

Action。

Observation。

目标、动作、观察。

只要任务还没有结束，这个循环就会一直转下去。

以代码排障为例。

它可能先查看报错日志。

再检索相关文件。

再打开某个函数。

再执行测试。

再根据失败信息改动代码。

再继续跑测试。

从表面看，它像是在“自动干活”。

从模型视角看，它其实是在不断接收新上下文，再接着生成下一步。

所以 Agent 的关键并不只是工具调用本身。

它必须能在不断扩张的上下文里守住目标。

Agent 每做一次动作，都会留下痕迹。

它做了什么。

工具返回了什么。

哪些地方成功了。

哪些地方失败了。

后面又尝试了什么。

这些痕迹很有价值。

没有这些记录，Agent 就不知道自己已经走到哪一步。

但记录一多，也会变成负担。

一个工具可能回传很长的日志。

一次搜索可能带回十几个网页片段。

一段对话里可能混着不少临时想法和废弃方案。

一个错误虽然已经修好，但旧报错还留在上下文里。

模型继续生成时，会把这些内容一起看到。

它未必总能准确分辨：

哪些仍然是当前最重要的信息。

哪些只是历史痕迹。

哪些已经过期。

哪些从一开始就不够可靠。

这就是 Agent 比单轮问答更依赖上下文工程的原因。

单轮问答通常只需要一个明确的问题。

Agent 需要持续维护一个清晰的工作现场。

现在很多模型都在强调长上下文。

几十万 token，甚至上百万 token。

长上下文当然有它的价值。

它让模型一次能看到更多材料。

长文档、代码库、历史记录、工具结果，都更容易塞进去。

但能塞进去，不代表都该塞进去。

桌子很大，并不意味着要把所有文件都铺在桌面上。

桌面越乱，越难快速找到关键材料。

模型也是一样。

上下文越长，里面的有效信号越容易被冲淡。

关键信息可能被埋到中间。

旧信息可能和新信息互相打架。

无关细节可能抢走注意力。

这类问题常被称为 Lost in the Middle。

也可以更直白地理解为：

信息一多，模型未必能稳定抓住中间那块最关键的内容。

还有一种现象，可以叫 Context Rot。

上下文不是一下子坏掉的。

它是慢慢变脏的。

先混入几条无关内容。

再留下几段过时结论。

再加上一些重复的工具结果。

最后模型虽然看到了很多东西，但工作现场已经不干净了。

Agent 往往还会搭配 RAG 一起用。

它先检索资料，再把资料放入上下文。

这对处理最新信息、私有文档、代码库和知识库都很重要。

但 RAG 也有同样的问题。

检索到了资料，不代表这些资料有用。

资料相关，不代表资料足够关键。

资料很多，不代表答案就更可靠。

如果 Agent 每一步都把大量检索结果塞进上下文，模型看到的内容就会越来越拥挤。

这时它可能被一段弱相关材料带偏。

也可能把多个