回想ChatBot时代，模型能看到的输入基本就三样：官方预设的系统提示词、用户输入框里敲的提示词、加上一些多轮对话的历史记忆。但进入龙虾时代之后，随便在token看板上盯一个任务的agent调用链路，或者对照公开的token用量分析，你会发现——打字输入的那些提示词，真的只是冰山一角。工具在反复调用、skills在频繁装载、本地文件在不断被读取……历史上下文就这样几何级地膨胀开来。我们手敲的那几个字，在整个Token账单里，其实就是个零头。

最开始用龙虾时，我也是从Opus一路到底，觉得这样才算物尽其用。但token越来越不够用之后，就开始持续琢磨怎么省。越深入研究越发现：真正的省token不是削减投入、不是压低预算，而是在保证效率和产能的前提下，用结构化的方式替代蛮力输入。说白了就是学会工程化地用AI——关键动作就一个：在合适的时间，把合适的上下文，装进合适的模型。这不仅省token，更重要的是让AI的每一分注意力都用在刀刃上。

看完这个分布图，问题就清晰了：上下文怎么管，是一门需要持续精进的学问。现在上下文最大的模型也就1M左右，任其自然的话，模型会越用越笨。所有多出来的历史上下文，只能靠龙虾工具自己的压缩能力来硬撑。但压缩一定是有损的，过程中可能丢掉了之前定好的约束，或者反复追问已经确认过的事。这就是常说的Context Rot（上下文腐烂）。

上下文token越多，模型的召回准确率就越低。根子在Transformer架构本身：n个token之间是n?的两两关联，上下文越长，注意力就被摊得越薄。那些无效信息，反而冲淡了我们真正希望大模型读取到的内容。

所以，把上下文管好，既能省token，同时也能让AI变聪明、产出更好的效果。接下来从四个维度拆解：最小上下文、清晰理想态、Harness架构分层、动态选型。

---

别让AI“读全文”，要让它“按需取”

那么，什么才是“好的上下文”？很简单：找到那个最小的、信号最强的token集合。不是喂得越多越好，是喂得越准越好。

可以参考大多数龙虾针对代码仓库的索引方案——不把整个代码库一股脑塞进上下文，只维护一套轻量索引（文件路径、查询语句、链接），用到的时候用grep/glob/read现场搜索读取。这套打法叫JIT（Just-in-Time，即时检索）。

JIT解决的是“进来时少装”。但长轮次的会话还有另一个问题：会话本身会膨胀。这就需要一个“上下文卸载”的思路：把AI上下文当存储系统来管理，缓存该缓存、落盘该落盘、分层存储。

想象一下，你的龙虾就像一台电脑。电脑有多层存储：CPU缓存最快但最小，内存次之，硬盘最慢但容量无限。AI的上下文系统也一样。

对标这个层级，卸载的策略就清晰了：

具体操作可以这样拆解：

提到缓存，这里还有经常被忽略的省token技巧：Prompt Caching（提示缓存命中）。固定的系统指令和工具定义放前缀，重复部分只按零头计费。启用缓存最多可以降低90%的输入成本。试过用DeepSeek模型执行任务时，账单的性价比经常会让人眼前一亮。

---

越约束，越自由：花五分钟说清楚，省五十分钟拉扯

很多token，是在“猜来猜去”里烧掉的。扔一句“帮我写个登录页”，AI只能猜你想要什么；写出来不对，你改，它再猜。五六轮过去，token花了不少，事情还没成。

写提示词就像调收音机，要找对频率高度。太低了：硬编码一堆if-else；太高了：说一句“请专业地完成任务”刚刚好——给清目标和约束，别把每一步都规定死。

出发前花五分钟回答以下三个问题，能省掉后面五十分钟的反复试探。注意是“策展”不是“堆砌”——不要塞一长串边缘情况试图覆盖所有规则，而是挑几个多样化、有代表性的样板。

这三个问题的背后是一个递进的金字塔：给示例（One-Shot）最准确，给规则（Spec/约束）次之，光提需求最差。

一个真实的例子胜过千字描述。但这是“策展”不是“堆砌”，不要试图列长串边缘情况来覆盖所有规则，而是精心挑选几个多样化、有代表性的样板。

把这些约束和示例固化下来，就是给AI装上护栏。护栏是信任的基础。没有护栏，你只敢让AI做简单的事；有了护栏，才敢把复杂的活交给它。如果工具集臃肿、功能重叠、规则模糊，连人类工程师都说不清该用哪个工具、该遵循哪条规则，AI更不可能猜对。

约束越精确 → AI越不用猜 → 一次到位 → 返工越少 → Token越省。输出质量也会更高。

省Token和把AI用好，其实就是同一件事。

---

活太大，就别让一个脑子硬扛

有些任务本身复杂，单个会话很快被细节塞满。这时需要从架构层面重新思考：不是一个虾硬扛，而是多个虾的分工和协作。

第一部分：主动压缩 · 会话的三段生命周期

一个会话不是越长越好。随着轮次增加，虾的表现会经历三个阶段：

· FRESH（清醒）：前20轮，虾的状态最好。输入输出精准、理解深度到位、响应快速。这个时候就放心用，不用省。

· DRIFT（漂移）：20~60轮，上下文开始有点乱。虾开始重复犯同一种错、忘了早期的约定、输出变啰嗦。这个时候该动手压缩了——把历史摘要一下，新窗口继续。

· ROT（腐烂）：超过60轮，虾已经换了个样子。风格突变、答非所问、逻辑混乱。这时候没救了，必须重开。

关键就是别硬撑。一旦进入DRIFT，就主动摘要一下，用摘要启动新会话。做一次上下文压缩，保留摘要加最近的几个文件，成本降了，效果也没掉。

第二部分：子智能体架构 · 轻主虾 + 重子虾

但即使你很会压缩，有些任务就是特别复杂。比如一个月级的长期项目，需要全程精细化决策。光靠“按阶段压缩”不够，因为你经常要在执行中途改需求、改方案。这时该换架构：不是一个虾从头到尾，而是一个主虾加多个子虾。

核心思想很简单：主虾只做决策和调度，子虾做具体执行。主虾的工作是理解全局、拆分任务、整合结论。子虾各自拿一个明确的、最小粒度的原子任务，用干净的上下文窗口，完成后只交回结果，不回灌过程。

举个例子：写一个复杂的系统设计文档。旧方法是一个Opus从需求分析→架构设计→代码框架→文档输出，一个会话全搞定。问题是上下文越堆越厚，最后虾被前面的细节压得喘不过气，新的需求改动反而容易被忽视。

新方法是：主虾接到“写系统设计文档”的任务，拆成5个子任务给子虾：①理解需求，②梳理关键决策点，③设计核心架构，④给出代码参考，⑤生成文档框架。每个子虾拿一个子任务，干完把结论交回来，主虾汇总最后输出。

这样做有三个好处：

①主虾永不疲劳：强模型只在决策点出场，上下文从不积压。即使项目跑数千行代码，主虾脑子一直清醒。

②子虾是原子单位：每个子虾的任务完全独立、不需要跨轮积累上下文。用便宜点的模型就够了，一次搞定。

③需求变更无痛：中途改需求，主虾重新拆分即可。不用推翻整个进度，只调整涉及的子虾。

关键是任务的拆分粒度。不是拆成5个大阶段，而是拆到最低细粒度的原子任务，每个都完全独立、不需要跨轮上下文。比如：“给代码补充单测”“校验JSON结构”“从文档提取决策点”。这样子虾用Sonnet甚至更便宜的模型就够了，成本降到原来的20~30%。

---

回到开头：别全程开着最强模型

按阶段切换模型是最直接的方案。简单任务用快模型，关键任务才用最强的：

这招上手快，但手动切换麻烦。如果任务本身高度复杂、需要全程精细化决策，仅靠“按阶段切换”还不够。

这里还有一个更优雅的方案：大脑+手脚架构。用一个强的模型当主Agent（大脑），它的唯一职责是理解全局、拆分任务、调度执行、汇总决策。然后让性价比高的模型作为Sub-Agent（手脚），接收大脑下达的“细粒度原子任务”，逐个完成，只反馈结果，不回灌过程。

关键是任务拆分粒度。大脑不是把一个大任务砍成五六个中等任务，而是拆到最低细粒度的原子任务。每个都是完全独立、不需要上下文积累、可以用中等模型一把搞定的单元。比如：“给这段代码加注释”“检查这个JSON字段有没有缺”“从这个文本里提取核心信息”。

这样做有三个妙处：

①大脑永不疲劳：强模型只在决策点出场，上下文从不积压。即使项目跑数千行代码，脑子一直清醒。

②手脚可以并行：五个原子任务可以同时派给五个便宜模型实例，并行完成，大脑只需在最后合并结果。

③成本剧降：大脑调用次数少（只在关键时刻），手脚用便宜模型。整体成本可能只有“全程Opus”的20~30%。

这恰似软件工程的“高内聚、低耦合”。把模型当团队编制，大脑和手脚职责明确，信息流清晰，反而削平了单一模型的上下文焦虑。

认清账单、最小上下文、清晰理想态、Harness架构分层、动态选型——省token和怎么把AI用好，本质都是一句话：在合适的时间，把合适的上下文，装载进合适的模型。