上下文管理不是 token 技术细节，而是 AI Agent 的系统设计问题

真正的问题不是“窗口够不够大”，而是“任务状态住在哪里”

很多人一提上下文管理，第一反应还是 token：窗口够不够大、压缩策略好不好、要不要摘要、会不会丢信息。这种理解在聊天场景里没问题，但一旦进入 Agent 场景，尤其是长任务场景，就开始不够用了。

因为长任务真正需要连续的，不是聊天文本本身，而是这些东西：

• 任务现在处于哪个阶段；
• 哪些约束已经确认、哪些仍是猜测；
• 前一步做了什么，结果有没有验证；
• 下一步应该做什么，以及为什么；
• 哪些失败教训需要被记住，避免下轮重犯。

这些内容如果都塞在上下文窗口里，系统会越来越脆弱。因为窗口再大，也只是一段会话容器；而任务状态需要的是可持续、可回读、可交接、可重组的外部结构。

为什么大家很容易把它误解成 token 技术问题？

因为最直观的痛感就是窗口满了：对话越来越长，模型开始忘事，开始瞎总结，开始提前收尾。于是很多人自然会把解决方案理解成“摘要做得更好一点”“压缩得更聪明一点”。

但这只是表层现象。更底层的问题是：模型并不天然适合当任务状态数据库。它擅长在给定上下文里继续推理，却不擅长长期稳定地当系统记忆。

Anthropic 的 context reset 路线之所以重要，就是因为它等于明确承认：与其让模型在越来越脏的上下文里“继续想”，不如重开一轮，用结构化交接明确任务状态。

上下文管理其实分三层：窗口层、工件层、知识层

第一层：窗口层

这是大家最熟悉的一层：当前会话里模型能看到什么。包括原始消息、压缩摘要、近期文件、工具输出等。这一层解决的是短期工作记忆。

第二层：工件层

真正的长期任务连续性，往往活在工件里：task list、handoff note、feature list、progress file、测试结果、设计文档、review 结论。这一层解决的是可交接、可重启、可验证的问题。

第三层：知识层

再往上一层，是更慢、更稳定的知识沉淀：概念页、wiki、经验库、系统约束、历史判断、可复用 SOP。Karpathy 的 idea file / AI 知识库讨论之所以重要，就是因为它把这一层抬出来了。Agent 不只是临时记住事情，而是在一个可持续生长的知识环境里工作。

为什么知识库会成为上下文管理的关键外部结构？

Karpathy 那条思路的真正价值，不是又发明了一个记笔记法，而是提供了一种新的上下文外化方式：让知识库从“静态参考资料”变成“Agent 可读、可写、可组织、可扩展的工作空间”。

这意味着什么？意味着很多原本必须反复塞进上下文窗口的东西，可以逐渐迁移到知识库层：

• 项目背景和长期目标
• 概念定义与领域词汇
• 常见决策边界
• 过去踩过的坑
• 稳定可复用的方法论

一旦这些内容从聊天历史中解耦出来，系统就不再依赖“模型这次有没有刚好想起来”。它会变成一个更像工程系统的结构：窗口负责当前推理，工件负责当前任务，知识库负责长期稳定背景。

最后的判断：未来最好的上下文管理，不会是“更聪明的摘要器”，而是“更完整的外部记忆系统”

我对这件事的最终判断是：上下文管理以后会越来越少被单独看成 prompt / token 技巧，越来越多被纳入系统设计。窗口还会继续变大，压缩还会继续变聪明，但真正决定长期任务表现的，会是外部结构是否完整。

也就是说，未来的优秀 Agent 系统，往往会同时具备三种能力：

1. 能在当前窗口里高质量推理；
2. 能把状态持续外化到工件中；
3. 能把高价值经验沉淀进知识层，而不是每次重新开始。

参考线索