第二章：从 LLM 看上下文管理

如果只从表面看，大语言模型这几年的进步似乎很容易解释：模型越来越大，数据越来越多，算力越来越强，所以模型越来越聪明。

这当然是事实。

LLM 的 scaling law 告诉我们，当参数规模、数据规模、计算规模不断上升，模型能力会呈现某种可预测的提升。更神奇的是，在某些能力上，这种提升并不是简单线性的，而像是在某个临界点突然“冒出来”。

一个小模型可能只能做简单补全。规模大一点，开始能回答问题。再大一点，开始会翻译、总结、推理、写代码。到了更强的模型，它甚至能拆解任务、使用工具、检查错误、迭代方案。

这就是所谓的智能涌现。

但如果我们只看 scaling law，就会错过另一条同样重要的线索：模型外部使用方式的进化。

从 prompt 到 agent

早期我们和模型互动，主要靠 prompt。于是出现了 prompt engineering。

人们研究怎么写提示词，怎么让模型扮演专家，怎么提供背景，怎么约束格式，怎么给出示例，怎么要求模型一步一步分析。

那时的上下文管理是手工的。人类把目标、背景、角色、限制、样例都塞进 prompt，希望模型在一个更好的语境里回答。

后来，人们发现光靠 prompt 不够。模型需要外部知识，于是有了 RAG。我们把相关文档、数据库、知识库检索出来，放进模型上下文。模型不再凭空回答，而是基于资料回答。

再后来，模型需要工具。它要查文件、跑代码、访问网页、调用接口、操作软件、创建计划、修改项目。于是 function calling、tool use、agent workflow 出现了。模型开始不只是“说”，而是能在环境里“做”。

再往后，MCP、skills、memory、project context、workflow 这些机制逐渐成熟。模型不只是拥有一个临时 prompt，而是拥有一整套上下文组织系统。

它知道当前项目是什么，知道用户目标是什么，知道哪些工具可用，知道什么时候该查文档，知道什么时候该运行测试，知道什么时候该复盘自己的输出。

这一路走来，表面上看是工具越来越多，框架越来越复杂，产品越来越强。可底层其实都在解决同一个问题：

如何把正确的信息、正确的目标、正确的约束、正确的工具、正确的反馈，在正确的时刻放进模型的工作上下文里。

聊天机器人往往只有一段对话。它能回答，但很难承担长期任务。

真正能工作的 agent，需要项目上下文、任务上下文、工具上下文、历史上下文、评价上下文。它需要知道自己在哪里，要做什么，什么算完成，哪些东西不能碰，如何验证结果。

这时我们就会发现一个很神奇的事实：

上下文管理的水平，会让同一个智能系统的实质效果发生质变。

不是小修小补，而是质变。

一个没有上下文管理的强模型，像一个刚被叫醒的聪明人：聪明，但不知道情况。

一个拥有良好上下文的模型，像一个入职很久、熟悉业务、有工具、有流程、有检查标准的人：它不只是聪明，它能交付。

Claude Code、Codex 这类工具之所以让人感觉“AI 开始能工作了”，并不只是因为底层模型更强了，也因为它们终于被放进了一个更完整的工作上下文里。

它们能看项目，能读文件，能理解任务，能运行命令，能根据错误反馈修改方案，能在一次次上下文更新中靠近目标。

模型没有凭空变成另一个物种。它只是获得了更好的上下文，于是能力边界被重新打开了。

这件事越想越像人生。