200k Tokens 的上下文真的够用吗？

推荐语

200K Tokens的上下文窗口真的不够用吗？Amp团队用实践告诉你：恰到好处的短线程才是高效编程的关键。

核心内容：
1. 200K Tokens窗口的合理性分析
2. 长上下文带来的"Agent醉酒"现象解析
3. 自下而上的模块化开发实践建议

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

放眼看去，现在各大闭源开源的Code模型还是以200K的居多。

200k Tokens真的够用吗？

Amp 团队最近写了一个文章，说200k Tokens才是正道，不仅是够用，而且相当长的时间它就应该是主流。

以Opus 4.5为例子，已发布几周了，它是Amp团队的主力模型，也被公认为目前最强的编程模型。下放！Opus 4.5 在Claude Code 20刀订阅中可用

但它的上下文窗口只有200ktokens。

有人诟病说不如Gemini 3 Pro的好，都2025年了，纯是挤牙膏。

但是Amp团队觉得200ktokens就刚刚好，这不仅仅是它们团队中某个人的偏好，而是整个团队都在践行的一种工作哲学，全员短线程。

为什么要抛弃百万级 Context？

Amp团队也是从它们无数爬坑的实践中得的理论，Amp团队最近给 Amp 上线了一个新功能，在命令面板中添加发送至支持的指令。

这个任务不是直接在一个巨大的窗口上下文中完成，而是由一组相互连接的微小工作线程组成的。

最大的一个工作线程用了151k输出 tokens，只有四条用户消息。

平均下来的工作线程长度在80k tokens左右。

即便把这13个相关联的工作线程全部加起来，其实也勉强能塞进一个100 万 token 的窗口里。

那么问题来了，为什么不直接把所有东西丢进一个超大工作线程里，省去开新对话的麻烦呢？

Amp 团队的观点是：因为Agent会喝醉

Amp团队在他们的 Context 管理指南里写过这样一句话，如果你喂给 Agent 太多 tokens，它们会醉。

原因很简单，上下文过载的模型行为像醉汉！

模型开始胡言乱语，逻辑混乱，甚至和开发者抬杠，如果继续喂数据，它们吐出来的代码更是一塌糊涂。

Agent的本质是模型、系统提示词、工具以及对话历史的集合。

对话越长，历史包袱越重，充斥着大量与当前任务无关的噪音。

想要Agent表现最佳，必须只提供完成当前任务所需的上下文，多一点都是累赘。

长对话是陷阱

除了效果差，长对话还是成本黑洞。

每一次请求，所有历史 token都要重新发送给模型提供商。成本呈指数级上升，尤其是象Cursor这种现在已经全面按Token收费的厂商。

而且时间越长回答就越慢！

长工作线程往往更长的思考停顿，而且累计起来的结果就是错过缓存窗口，Token爆炸。

那应该怎么做呢？

把线程拆碎，就是把任务拆碎

他们应该最正确的是方式是，任务拆解。

其实传统开发，就是这种模块化开发，把大任务拆成一个个小任务。

AI Code也应如此。

让每一个线程都有一个明确的目标，才能让原本复杂的开发流程变得清晰、可控，而且速度极快。

自下而上的构建流

观察Amp团队的编码方式，这是一种典型的自下而上的构建过程。

首先，开一个工作线程构建基础实现。

如果特别复杂，会先开一个工作线程专门调研代码库，收集上下文。

有了基础后，开启全新的线程来进行调整或重构。

一个改动就是一个线程。使用工具读取上一个工作线程的上下文。

代码写完了，评审环节也是新工作线程。

让 AI 阅读新代码，检查是否符合现有的设计模式，确保没有引入坏味道。

验证阶段，再开几个新线程，写一次性脚本、跑测试、分析性能日志、强制触发错误状态。

在Amp中，开发者通过引用 ID 或 URL 来在线程间传递上下文，这比使用多个 markdown 文件来记录规格和历史要轻量得多。

整个过程非常流畅。

新建线程，输入引用指令关联上一个相关线程。

如果需要主线程的背景，一键切换回去。

这就是高效团队的工作流。

每一个线程都是一个离散的原子任务，无数个原子任务聚合成了一个完整的功能。

方向盘依然在人手中，车速更快，路费更省，逻辑更清晰。

所以，200k tokens 够吗？

就目前来说，只要掌握了模块化子任务，简直是绰绰有余！