放眼看去，现在各大闭源开源的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 够吗？
就目前来说，只要掌握了模块化子任务，简直是绰绰有余！
