Agent 项目里最容易被忽略的不是模型，而是上下文治理

如果只看表面，Agent 项目最吸引人的部分通常是模型。

比如用了哪个模型，推理能力怎么样，能不能自己规划，多轮执行是不是顺滑。这些当然重要，但我现在做这类项目越多，越觉得最后最容易把系统拉开差距的，往往不是模型本身，而是上下文治理。

这个词第一次听上去有点虚，但它其实非常具体。

说白了，就是模型每一步到底看到了什么信息，这些信息是不是干净、够用、不过量，而且不会把它带偏。

为什么我后来开始更重视这个问题

因为我发现很多 Agent 不稳定，不是因为模型完全不会，而是因为它每一步拿到的信息质量太差。

常见情况包括：

• 历史消息太长，重点被淹了。
• 工具返回结果太杂，模型读不动。
• 旧状态没清掉，影响当前判断。
• 同一个事实在上下文里出现了多个版本。

这些问题单看都不算大，但它们会叠加。最后系统就会出现一种特别典型的状态：偶尔聪明，大多数时候不稳，而且很难定位问题在哪。

我现在理解的上下文，不是一个大输入框

以前我会把上下文理解成“给模型的所有信息”。

后来我慢慢改成另一种想法：上下文应该是一份按步骤组织的工作材料，而不是一个越堆越大的杂物间。

比如在一个多步任务里，模型当前只需要知道：

• 这一步的目标是什么。
• 它已经拿到了哪些关键事实。
• 下一步允许它做哪些动作。

如果把历史聊天、全部工具结果、各种系统提示一股脑都塞进去，模型并不会因此更聪明，只会更容易抓错重点。

我比较认同的四个治理动作

1. 按阶段切上下文

不是所有信息都应该在所有步骤里出现。

任务拆解阶段需要的是用户意图和任务背景，工具选择阶段需要的是可用动作和参数约束，结果整合阶段需要的是证据和结论。它们应该是不同形态的上下文。

如果不分阶段，模型就容易在一个时刻同时面对太多层次的信息。

2. 给工具结果做翻译

这一点特别重要。

工具输出通常是给系统看的，不是给模型看的。字段名、结构、冗余信息、错误码，这些对模型来说全是负担。

所以我现在不太愿意直接把原始返回塞回去，而是会先做一层整理，把它翻译成模型更容易消费的内容。比如哪些字段是真正关键的，哪些结果只说明“未命中”，哪些异常该被解释成人话。

这一步做得好不好，直接影响后面推理的稳定性。

3. 让旧状态及时失效

很多人会讨论怎么记住更多，但我现在更关心怎么把旧的东西清掉。

因为 Agent 很容易被“刚刚做过什么”影响，而这种影响有时候是错的。一个任务已经切换阶段了，系统却还带着上一阶段的假设继续推；用户已经补充新信息了，模型还在沿用旧理解。

如果没有状态清理，系统就会越来越像一边走路一边往包里塞石头。

4. 给关键事实定来源

这个动作看起来像数据问题，其实也是上下文问题。

如果模型当前依赖一个结论，它最好知道这个结论来自哪。是用户刚刚亲口说的，还是数据库查到的，还是知识库里的一段文档，可信度完全不一样。

没有来源标记的上下文，最后很容易变成“信息很多，但不知道该信谁”。

我为什么觉得这比换模型更值得做

因为上下文治理改好了，很多收益是跨模型存在的。

你换一个模型，能力上限可能变高；但如果上下文还是乱的，它照样会在很多地方犯低级错误。反过来，如果上下文组织得更清楚，哪怕模型不是最强的，整体体验也往往会稳很多。

这有点像后端系统里的接口设计。不是说底层服务不重要，而是上层把输入输出关系整理清楚之后，整个系统才能稳定协作。

如果让我用一句话总结

我现在会说，Agent 项目后期拼的不是谁接了更厉害的模型，而是谁能持续给模型提供“刚刚好够用”的上下文。

多了是噪音，少了会断链，乱了就跑偏。

所以我现在越来越觉得，上下文治理不是优化项，它本身就是 Agent 工程化的核心组成部分。