编程Agent的上下文窗口固定在约100万token，能力再强也得精打细算。过去一年，Agent从聊天机器人进化到自主工具调用，但窗口大小没怎么涨。2026年的关键转变，是把重心从“把信息塞进模型”转向“把信息输出给用户”——因为人的注意力才是最稀缺的盒子。
上下文窗口：一个固定大小的盒子
100万token听起来很大，但代码库动辄几百万行。一个中型项目500万行代码，按每行30个token算，就是1.5亿token，是窗口的150倍。所以别想着把整个代码库塞进去。你需要做的是精挑细选，只带相关文件、相关函数、相关报错。这就是零开销原则：不为不需要的内容付费。每多塞一个无关文件，模型就多一分“注意力”被稀释。
Agent的演进：从聊天到自主调用工具
回顾一下路径：最初是聊天机器人，你问一句它答一句；后来学会调用工具，比如搜索或计算；再后来变成自主Agent，能连续多次调用工具，直到完成目标。编码Agent的核心工具是什么？不是炫酷的语义搜索，而是最原始的查找替换。这类工具能改代码，但还远远不够聪明。比如替换一个变量名，如果同名变量在不同作用域，它可能改错地方。工具本身的改进空间，比模型能力提升更值得关注。
定制化模型：为什么需要？其实还是上下文
很多团队想微调模型，觉得这样模型就“懂”了公司内部知识。但模型权重发布后是冻结的，微调并不能真正改变模型的知识，只能改变它的行为倾向。定制化的核心原因有三个：模型需要访问完成工作所需的信息、获取公司内部机构知识、以及具备获取这些知识的工具。而这些本质上都是文本层面的上下文学习——你把文档、规范、工具说明放进上下文里，模型才能“知道”。所以定制化不是魔法，它依然受制于那个固定大小的盒子。
KV缓存与上下文驱逐的代价
上下文窗口有一个隐藏的物理机制：KV缓存。它让前缀一致时计算成本更低。如果你频繁调整上下文的前缀，比如用类似LRU的缓存策略去驱逐旧内容，那每次驱逐都会让前缀失效，计算成本暴涨。Cursor早期在规则管理上就吃过这个亏：每个文件都附加一套规则，结果规则一改，整个缓存作废，响应慢到怀疑人生。所以上下文管理不能简单粗暴，得考虑前缀稳定性。
MCP与Skill：两种扩展方式的取舍
MCP服务器作为插件抽象，扩展性有限。每个工具的名称、描述、schema都要占上下文。假设一个工具schema平均200个token，挂50个工具就是1万token，占了窗口的1%。看似不多，但加上工具返回结果，很快就把窗口填满。工具搜索机制能缓解，但不能根治——搜索本身也要消耗上下文，而且可能搜不到最合适的。Skill则是一种惰性系统Prompt，用文件夹加markdown文件组织。它的描述始终占用上下文，但正文按需加载。如果你已经有一个CLI工具，与其为它写一个MCP服务器，不如创建一个解释这个CLI的Skill，让Agent在需要时读取使用说明。这样更省空间，也更灵活。
2026年的核心转变：把信息从模型输出给用户
过去我们一直在研究怎么往模型里塞更多信息：更大的窗口、更好的检索、更聪明的压缩。但2026年，方向变了。模型处理能力越来越强，真正稀缺的是人的注意力。Agent不能光顾着自己干活，得学会把最重要的结论、最需要人类决策的点，用清晰的方式输出。你的屏幕就是一个盒子，你的大脑也是。谁能在这个盒子里放最值得看的东西，谁就能赢得效率。
FAQ
Q: 100万token上下文窗口够用吗？
A: 对于单个任务，比如修改一个模块、修复一个bug，通常够用。但如果你想塞下整个代码库，那远远不够。关键不是窗口多大，而是怎么把最相关的代码挑出来放进去。
Q: MCP服务器和Skill有什么区别？
A: MCP把工具抽象成插件，但每个工具的schema都占上下文；Skill是惰性加载的Prompt，描述常驻，正文按需读取。如果你已经有现成CLI，用Skill解释它往往比写MCP服务器更轻量。
Q: 为什么上下文驱逐策略会昂贵？
A: 因为KV缓存机制对前缀敏感。前缀一变，之前的缓存可能就没用了，需要重新计算。类似LRU的驱逐策略会导致频繁的前缀变化，让计算成本成倍上升。所以上下文管理要尽量保持前缀稳定。
来源：InfoQ
