关于 Context Engineering 的 100 个问题

写在前面

这是一套「100 个问题」主题文档：用问题把一个主题拆开，再一个问题一个问题地读透。

上下文工程讨论的不是「怎么写一句更好的提示词」，而是模型每次推理前，如何从文档、工具、记忆和历史里，装配出能最大化任务成功率的那一小撮 token。它同时是一门成本课：窗口里的每一枚 token 都在分走注意力，也在进入账单。

这份文档按 6 个阶段展开：先理解窗口为什么会越塞越笨，再判断什么该进窗口、长会话怎么不烂尾、指令怎么写才不被无视、上下文怎么烧钱，最后回答质量该怎么验证。

快速回答

• 窗口不是仓库，是工作台：装得对，比装得多重要。
• 先保证正确和完整，再谈精简；错信息比缺信息更糟。
• 能封顶就不要改写，能清场就不要硬压，缓存最怕前缀变化。
• 关键约束写进项目根文件，别只留在对话里等摘要。
• 技巧没有通用真值，只有「在你的评测集上涨没涨分」。

本文整理自 Context Engineering 主题文档与公开资料，并结合站内编辑做了结构化整理与补全。

本册为整理版：部分原始资料存在 OCR 截断，正文以可执行的问题清单和简明回答为主。

1. 窗口越大为啥越笨

1. 为什么窗口塞得越多，模型反而越笨？#

这是 context rot：窗口里的 token 越多，模型准确取回信息的能力越差。18 个模型的受控实验结论一致，没有谁能随输入变长守住成绩。

原因在注意力预算。Transformer 让每对 token 建立关系，n 个 token 就是 n² 对关系，窗口越满，预算摊得越薄。退化是渐进的，不会突然断崖，但检索精度和长程推理会悄悄下滑。

2. 找东西的测试都满分了，为什么真实任务还是翻车？#

因为「大海捞针」考的是词汇匹配，不是语义理解。真实任务里问题和答案常常不共享关键词，还要从一堆相关但不回答问题的内容里分辨。

自测要拆成三题：找得到、换一种说法还找得到、加干扰项后还能找到。只测第一题，很容易高估模型。

3. 为什么摆在正中间的信息最容易被模型忘掉？#

注意力呈 U 型：开头有首因效应，结尾有近因效应，中间是洼地。多文档实验里，关键信息放在 20 到 30 篇文档中间时，成绩甚至低于一篇文档都不给的闭卷。

所以长文档放前面，问题放最后；超过 20 篇文档后继续加料，收益已经很小。

4. 为什么信息「怎么摆」比「在不在窗口里」更重要？#

信息在场但被埋没，和缺席的实际差别没有想象中大。同样的针、同样的长度，只改语义相似度、干扰项和文档结构，成绩就能拉开。

操作上做三件事：用标题或 XML 标签分段；指令、背景、工具说明各占一段；示例选代表性的，不要堆边角案例。

5. 为什么聊得越久越乱，而且多半救不回来？#

模型会在早期轮次抢着下结论，后续信息进来后仍围着旧结论打转。多轮实验里所有模型平均掉 39%，强模型也会明显下滑。

出现「推翻自己」「重复同一个失败动作」「无视新指令」里任意两个信号，就别再打补丁：把已确认结论写成文件，开新窗口重来。

6. 为什么打乱顺序的上下文反而比通顺的更好用？#

这是反直觉但可复现的结果：把干草堆句子随机打乱后，模型找针的成绩反而更好。通顺文本有自己的论述流，插进来的针像不速之客；打乱后全文本来就不连贯，针反而不突兀。

生产上别照搬乱序，但要拿走三个正向杠杆：压体积、提高针与问题的相似度、减少干扰项。

7. 上下文的四种死法（污染/干扰/冲突/过期）怎么分辨？#

污染是幻觉进了窗口还被反复引用；干扰是窗口太长，模型盯着历史忘了当前任务；困惑是多余内容把回答带偏；冲突是旧信息和新信息互相打架。

排查从最可确认的开始：先查污染，再查冲突，然后砍材料看是否缓解，最后才归因于单纯太长。

8. 为什么说注意力是预算，花一块就少一块？#

每新增一个 token，都会稀释全体 token 之间的注意力关系。输入翻倍，关系对数翻四倍，这就是上下文边际收益递减的数学形状。

管窗口只要两条规则：加一样先删一样；系统提示、工具定义这类常驻项设固定上限。

9. 怎么判断 agent 变笨是模型的锅还是上下文的锅？#

工程实践里，多数失败是上下文问题。先做三步排除：手工重排上下文看是否恢复；检查指令是否真的被加载；对照上下文故障的典型症状。

三步都干净还错，才轮到怀疑模型本身。否则换模型只是换一个更容易被同样上下文拖垮的模型。

10. 怎么让模型自己报出还剩多少窗口可用？#

新一代 Claude API 会自动注入预算和剩余量提醒，也就是 context awareness。模型因此能按真实余量安排工作，而不是靠感觉收尾。

要量化数据就读响应里的 usage 字段，别解析这些注入标签；如果框架会自动压缩，也要明确告诉模型，避免它提前收工。

11. 怎么亲手测出手头模型的实际可用窗口？#

至少设五档长度，从几千 token 一直到标称上限，只动长度、不动任务难度；针要语义化，不要用能直接词汇匹配的句子；同时测单针和多针。

而且必须测你真实使用的入口，接口层、订阅层都可能和宣传页不一样。

12. 为什么同一个模型换个宿主就判若两「模」？#

模型能力固定，但每次推理前装什么、怎么截断、挂哪些工具，由宿主决定。同样的底层模型，在 Cursor 和 Claude Code 里的表现可以差很多。

抱怨模型不行之前，先看宿主的装配清单：系统提示多大、工具几个、历史怎么截、项目规则有没有加载。

13. 宣称的 1M 窗口和能用的窗口差在哪几层？#

分四层：标称窗口、可容纳、可检索、可推理。买到的只是第一层，任务成败往往取决于后两层。

每一层都比上一层小。容量问题查文档，token 计数能提前算；可检索和可推理必须用自己的文档实测。

14. 提示词工程已死，是真凉了还是贩卖焦虑？#

没死，是被吸收了。提示词工程仍然是上下文工程的子集：单轮交互里写好指令的能力永远有用，只是多轮、多工具、长会话里光会写指令不够。

「已死论」更多是传播新概念时制造的冲突叙事，不必站队，按问题落在哪边补哪边。

15. 上下文工程凭什么叫工程，而不是换皮话术？#

看它有没有真实世界的失效模式要对抗。LLM 的失效方式和物理工程更像：有容差、有不确定性、有材料强度未知的问题。

什么时候算工程？当你能说出当前失效率、改动前后的对照数字，以及为什么有效。说不出来，就还在调咒语。

16. 一条推文怎么就让上下文工程火遍全网？#

路径很短：Tobi Lütke 先说他更喜欢「上下文工程」这个叫法，Karpathy 转发并列出任务描述、示例、RAG、工具、状态、历史、压缩，随后 HN 和 Simon Willison 把它定义成一个有粘性的术语。

术语只是容器，真正被传播的是那份七项清单，也正好是这份文档六章要拆的内容。

2. 什么东西才配进窗口

17. 为什么「最小的高信号 token 集合」是唯一通用原则？#

其他技巧都有适用边界：检索适合知识在窗外，记忆适合跨会话，压缩适合会话太长；只有「少而精」在任何场景都成立。

两个限定词缺一不可：高信号，每枚 token 都对推理有贡献；最小，有贡献还不够，还得值得占窗。200K 窗口装 190K 无关资料，不如装 20K 相关资料。

18. 为什么检索一下再答，胜过把资料全塞进去？#

全塞进去最容易养出懒惰：资料一股脑进窗，模型反而不好好找。即时检索只在窗口里留路径、查询、链接这类轻量标识符，用到再读。

落地是混合策略：稳定不变的静态知识预装，动态线索交给 agent 现查。

19. 为什么说 RAG 死不了，死的是懒惰的 RAG？#

死掉的是最浅的实现：随机切块、向量 top-5、塞进 prompt、祈祷。检索的内核——在对的时机给对的信息——没有死。

长上下文也没有终结它。企业知识散落、过期、有权限、有版本，长窗口只给了更多摆放空间，没回答该摆哪些。把切块、BM25、rerank、评测集四件事做齐。

20. 系统提示写到什么程度算「恰到好处」？#

刻度叫 right altitude：太低，硬编码流程一遇边缘情况就断；太高，模型拿不到具体信号只能猜。合适的位置是具体到能引导行为，抽象到留出启发式空间。

结构可以照四段排：Identity、Instructions、Examples、Context。先拿最小提示测基线，每发现一个失败案例补一条规则。

21. few-shot 示例怎么给才不白烧窗口？#

3 到 5 个起步，选相关、多样、能覆盖标准场景的典型示例，用 <example> 标签和指令隔开。示例是行为锚点，不是说明书。

示例属于稳定内容，放进缓存前缀后边际成本会大降；散在中间、每轮变化，就等于每轮全价重付。

22. 多篇文档喂进窗口，按什么顺序排？#

长文档放顶部，问题放最后。多文档复杂任务里，query 靠后最多能带来约 30% 的质量提升，但这是上限值，不是保底。

每篇文档用 <document> 包好并标来源；长文档任务先让它摘引原文，再基于引用回答。

23. 哪些东西该留窗口里，哪些该落到窗外文件？#

这轮推理要用的留窗，「以后可能有用」的落盘。文件是持久层，窗口是工作台，两边各干各的活。

研究写 research 文档、方案写 plan 文件，进度写 progress.md；会话结束前把关键决策写进项目文件，下一次从文件续命。

24. 记忆系统五花八门，到底按什么选？#

没有排行榜，只有场景题。时序知识图谱适合事实会变、要追溯时效；OS 分层适合长跑有状态 agent；SQL 画像便宜可审计；逐字存储加元数据过滤，则在很多负载上打平甚至更好。

2026 年一个明显转向是反抽取：不是所有记忆都值得每笔写入调一次模型。

25. 什么情况下装记忆系统纯属浪费钱？#

三个信号：任务根本不跨会话；要记的东西一页纸装得下；自带 CLAUDE.md 和 auto memory 还没用起来。

轻量方案往往就够了，比如让 agent 维护一个 NOTES.md，或在项目规则里加一句「压缩后先重读计划文件」。

26. CLAUDE.md 和 auto memory 为什么要分两条通道？#

分工是一条界线：CLAUDE.md 是你写给模型的，auto memory 是模型写给自己的。前者装你审核过的指令和规则，后者装它从纠正里学到的教训与偏好。

分开是为了可审计：你的规则不会被模型改坏，模型的猜测也不会冒充你的决定。

27. 工具定义怎么写才不把窗口撑爆？#

工具定义每轮全额占窗，而且不会随对话压缩自动消失。先把职责重叠的工具合并，把多步操作的中间输出挡在窗口外。

再给工具加响应格式、分页、范围选择、过滤和截断。单个工具响应不要无上限地灌进窗口。

28. MCP 工具一多就爆窗，怎么把它们请出主对话？#

三条路：给子代理独立工具白名单，脏活留在子代理窗口；把工具定义写成文件按需加载；先整合再外迁。

核心不是「少接几个 MCP」，而是别让几十个工具定义常驻主对话。很多团队真正缺的是整合，不是工具。

29. 检索回来一堆不沾边的，怎么治「对题不对答」？#

这类内容叫 distractor：主题相关但不回答问题，不是中性噪声，是主动干扰，输入越长危害越大。

按三步治：查切块有没有把答案切散；上混合检索，别丢 BM25；加 rerank，把 top-30 收到真正答题的 top-5。

30. 怎么给窗口设配额，让每样东西按预算进场？#

把窗口分四档：固定区放系统约束和当前目标；可精简区放检索背景和旧工具结果；可折叠区放早期历史；阶段性区放当前阶段才用的工具和示例。

每次装配前统一走一遍：加载约束、提取目标、检索证据、召回记忆、选工具、压缩历史、按相关性排序、按 token 预算截断。

31. 上下文给对了，普通模型真能打胜仗吗？#

给对上下文是普通模型能上场的前提，但不是它场场获胜的保证。上下文解决「知道」，解决不了「验证」。

中等模型配上完整订单、保修、工单和工具，确实能直接给出换货方案；但看起来漂亮、实际根本性错误的回复仍然存在，所以评测和验证层不能省。

32. 为什么说「RAG is dead」的人一开口就露馅？#

因为这句话通常默认企业知识是一份能整块塞进窗口的干净文档。真正做过生产的人知道，知识散落、过期、有权限、有版本、互相矛盾，解法是筛选不是扩容。

坏 RAG 比没有 RAG 更糟，因为它给人「有据可依」的错觉。该死的是最浅的实现，不是检索。

33. 一整座图书馆和两千个精准 token，哪个好用？#

窗口里真正参与当前推理的，叫 working set。无论 200K 还是 1M，工作集被陈旧内容填满的速度一样快；窗口上限只是把墙挪远，没改变「堆多了会钝」。

图书馆永远该在窗外，窗口里只放当前任务这一撮。判断标准还是那把尺子：拿掉这枚 token，本轮推理会不会受影响。

34. 为什么塞错上下文比不给上下文更可怕？#

因为错信息比缺信息更糟，缺信息又比噪声更糟。模型能从糟糕的上下文里写出流畅自信的文字，措辞的把握和事实的把握是两套机制。

更危险的是伪完成：回复通顺、切题、礼貌，却悄悄无视了你十轮前定下的约束。装配的最后一道工序，永远是评估「装错」的代价。

3. 长会话怎么不烂尾

35. 压缩到底什么时候触发，由谁说了算？#

Claude Code 默认顶到模型上下文上限才压缩，比如 Sonnet 5 的 1M 窗口约 967K 才动手；可以用 /autocompact 或环境变量提前到 100K 到 1M 之间。

API 侧是另一套：服务端压缩走 beta 参数，默认约 15 万 token 触发，最低可设 5 万。两套数字别混着记。

36. 压缩为什么天然有损，最先丢的偏偏是最要命的？#

摘要器保大放小。实验里，任务主干的事实 3/3 全在，附录表格的冷门数字 0/3 全丢；而「必须调实时 API、不许读缓存」这种规则，在摘要器眼里跟闲聊没区别。

纪律只有一条：你负担不起丢失的东西，别放在对话里等摘要。写进项目根文件，或在压缩指令里点名保留。

37. 为什么压缩次数越多，会话反而病得越重？#

每压一次，全文过一遍有损管道，上一轮摘要里的细节再丢一层，损失是乘法不是加法。压得越勤，窗口里低相关内容占比越高，模型站在劣化语料上继续写下一份摘要。

实测里，压缩配置的记忆探针只有 38%，比什么都不做的 92% 差一倍多。压缩救急不救命，连压两轮还乱就重开。

38. 「什么都不做胜过压缩」什么时候是真话？#

当你的缓存价格足够低、会话长度还在可控范围时，保留全量历史可能比任何改写都便宜，因为改写前缀会让缓存折扣全部失效。

但这不是普适定律：缓存价一高、会话一长，结论就会翻面。先查自己的缓存单价和轮数，再决定压不压。

39. 怎么让长会话永远别走到灾难式压缩那一步？#

别等顶到 95% 以上才压。窗口越满，摘要调用越局促，产出又短又残，还会出现「快到上限就乱来」的 context anxiety。

经验线是 40% 到 75% 之间动手，提前压、带焦点压，或者用 /autocompact 500k 把自动线挪低。

40. /compact、/clear、开新窗口，到底按哪个？#

要连续性用 /compact，要彻底重来用 /clear，任务换场用「交接文件 + 新窗口」。被错误假设污染的会话，直接 /clear 比抢救便宜。

红线是 /clear 永久删除历史，按下去之前确认值得留的都已经写进文件。

41. 怎么写一条定向压缩指令，只留我要的？#

在 /compact 后面直接说人话：保留什么、扔掉什么，点名到具体名词。比如「保留 401 报错的修复步骤和结论」，而不是「保留错误修复过程」。

指令别写太瘦，格式约定、关键约束、下一步都要点到；自动压缩猜的是泛用重要，你赌不起就自己点名。

42. 压缩后计划还在名字没了内容，怎么防？#

常见伤口是：计划文件名还在上下文里，内容没跟过来，模型也没想着去读。元数据在、正文丢，这是压缩最典型的事故形状。

防法三条：关键约束写进项目根 CLAUDE.md；压缩后第一句话让它重读计划文件；要全自动就上 SessionStart hook。

43. 会话交接文档怎么写才能无缝续命？#

五段，一段不许空：会话意图、已改文件、关键决策、活动目标、下一步。结构化模板像强制检查表，静默丢失的空间比自由叙事小得多。

合格标准只有一个：没参与过这场会话的人，包括下一个模型实例，拿着它能直接开工。

44. 压缩、清除、记忆三件套能一起开吗？#

能，分工像操作系统：清除管窗口内的旧工具结果，压缩管整个窗口，记忆管跨会话。三者治的是三种不同的增长。

注意把 memory 工具加进清除的排除名单，否则刚写进记忆的内容可能被清掉。触发线也要拉开，别挤在同一刻一起开火。

45. 工具输出刷屏，怎么封顶才不误伤缓存？#

关键是分清「封顶」和「总结」。封顶让前缀变短但逐字节不变，缓存照常命中；总结改写了前缀，缓存整体失效，省下的 token 又按全价重算。

所以缩上下文，别改写上下文。要清旧工具结果就一次清够，让缓存重建的成本值回票价。

46. 长会话变慢变贵，怎么自查是不是上下文烂了？#

先查账再判病。/context 看窗口里装了什么，/usage 看钱和限额去哪了，/cost 看本次会话累计花费。

如果数字正常，但行为开始重复、推翻自己、无视新指令，那就是上下文烂了，不是账单问题。按第 48 题选抢救还是重开。

47. 压缩报错卡死了，第一步自救做什么？#

别硬刚。先 Ctrl+C 退出进程，重新启动，/resume 恢复会话，再 /compact。这套三连的原理是丢掉客户端越滚越大的坏状态。

如果新版仍有问题，带上版本号开新 issue；根因通常是压缩请求本身已经装不下整个会话。

48. 怎么判断该抢救会话还是果断重开？#

三问：错误是瞬时的吗，退出重进能过就是抽风，抢救；拿到摘要但 /context 数字没掉吗，没掉就是伪成功，没救；要留的决策写成文件了吗，写了就重开零损失。

被错误假设污染、反复回到错误前提的会话，重开比抢救便宜。会话是消耗品，别心疼。

49. 外置记忆怎么落地，SQLite 文件还是向量库？#

多数人用不着向量库。先看内置记忆工具：模型自己调 view、create、replace、insert、delete、rename，读写一个你说了算的文件后端，可读、可 diff、可进版本库。

真有跨会话海量历史要检索，再上 SQLite 加向量召回；让窗口当内存、文件当磁盘，要哪页调哪页。

50. 多 agent 并发时，上下文怎么隔离才不互相污染？#

把活关进子代理的独立窗口：独立上下文、独立 system prompt、独立工具白名单，大文件读取留在子代理窗口，只把结论带回主窗口。

隔离窗口还不够，任务描述也要隔离。每个子代理必须拿全目标、输出格式、可用工具、任务边界，否则会重复劳动或跑错方向。

51. 一个压缩 bug 官方修了八个月，期间发生了什么？#

报错是死循环：提示「上下文满了，去压缩」，按下压缩又报「会话太长」。用户先自救——退出、重进、恢复、再压；官方多次说修了，又在后续版本复发，直到 v2.1.85 才真正处理压缩请求过大的情况。

教训是：报错第一现场在 issue 区，自救永远先于修复；「已修复」要锚定版本号，别只信 changelog。

52. 为什么压缩失败「假装成功」比崩溃更伤人？#

硬失败会弹错误，你知道坏了；伪成功不报错，返回一份「最小交接摘要」，看起来续上了，实际窗口一寸没瘦，会话照卡在上限。

防御只有一招：压缩后看 /context，数字掉下来才算压成；数字没动就按伪成功处理，立即写交接文件重开。

53. 一次压缩失误怎么让真实账目错了 12 倍？#

规则明明写在文件里：持仓必须调实时 API，不许读缓存。压缩后模型把规则忘在窗外，抄近路读了三天前的缓存，账面直接错 12 倍。

关键不是 12 倍，而是「文件在」不等于「规则在窗口里」。涉钱涉数据的硬约束要写进项目根文件，压缩后第一句话让它复述关键约束。

54. 压不住的会话，怎么养出一圈外挂工具？#

社区工具大概三类：压缩前先清创，剪掉重复读取和巨大工具输出；用量到 65% 就拦下 agent，逼它写结构化交接再换窗；把整个上下文搬进 SQLite 加向量库的代理层。

这些方案没有认证背书，但三个思路可以白拿：用量预警线、结构化交接文件、换窗续命。

4. 指令怎么写才不被无视

55. CLAUDE.md 写多少行合适，超了会怎样？#

单个文件控制在 200 行以内。超了不报错，但越长越吃上下文、遵循率越低；涨到 4 MiB 以上，Claude Code 会整个跳过。

拆成 @import 没用，导入文件照样全文进窗。超了就把局部规则搬进 .claude/rules/ 加 paths 头，或者直接删掉模型能从代码推导的内容。

56. 为什么写进 CLAUDE.md 的规则经常被无视？#

两个常见原因：CLAUDE.md 是作为用户消息注入的，不在系统提示里，严格遵循无从承诺；新旧规则互相冲突时，模型可能随便挑一条听。

先跑 /context 看 Memory files 里文件在不在，再把含糊规则改成可验证动作。必须定点执行的规则，用 hook 或 permissions，不要只靠文档。

57. CLAUDE.md、rules、AGENTS.md 到底谁说了算？#

没有一条自动生效的硬层级。它们都是上下文：项目根 CLAUDE.md 影响最大，带 paths 的 rules 只在相关文件上加载，AGENTS.md 是跨工具约定，是否读取取决于宿主配置。

冲突时，更具体的作用域和更明确的指令通常占上风，但冲突本身就会降低遵循率。最稳的做法是保留一个事实来源，硬约束交给 hook 或 permissions。

58. 长上下文里关键指令放哪才不被稀释？#

长文档放顶部，问题放最后。注意力在开头和结尾最高，中间最容易被略读；资料越多，挤在中间的指令越容易被稀释。

多文档用标签分区、标来源，回答前先摘引原文。铺料也要节制，超过二十篇后继续加，收益已经很小。

59. 系统提示里哪些话纯属浪费，哪些一字千金？#

浪费有两种极端：把几十行 if-else 硬塞进去，遇到没见过的边缘情况照样跑偏；只写「你是一个有帮助的助手」，模型拿不到任何决策依据。

值钱的是踩坑记录、设计理由，以及一切与默认行为不同的约定。模型能自己从代码推导出来的目录结构和依赖清单，都是废话。

60. 换新模型后旧提示词为什么要做减法？#

新模型指令遵循更强，很多旧时代的补丁会从「保险」变成「噪声」：prefill、威胁式大写、过细的步骤、重复自检，都会挤占注意力，甚至让模型在该提问时抢着动手。

做法是删而不是改写：去掉无效的狠话和自检，保留领域约束、验收标准和真正需要的示例。

61. prefill 被禁之后，格式控制改用什么？#

用 Structured Outputs 约束 schema，或者定义一个带枚举字段的工具，让「输出」变成一次工具调用。去前言可以直接在系统提示里说「不要开场白」。

续写被截断的回答，把原文放进用户消息，说明断点在哪；绕拒答则把请求写清楚，不要靠 prefill 演开场。

62. 缓存断点放哪，才能让每一轮都省钱？#

断点打在最后一个跨请求保持不变的块上。断点前的任何一块变了，前缀哈希就全变，下一轮全部重算。

最经典的反面教材是时间戳：系统提示开头放一个精确到秒的时间，每秒都在变，你永远在付全价。

63. 为什么改一个工具定义，整个缓存全失效？#

缓存按 tools → system → messages 分层判定，每一层的改动作废该层及其后所有层。工具定义排在最前面，改一个词就是三层全炸。

把工具定义当编译产物：会话进行中冻结不碰；要改就接受「改一次、炸一次、重灌一次」，最好挑间歇期。

64. 多轮对话的提示词怎么排布才吃满缓存红利？#

静态内容按 tools → system → messages 的顺序放最前面；时间戳、随机 ID、当日日期这类每请求必变的，放到消息流末尾。

历史保持只增不改，别回头编辑旧消息；中途补指令就追加 system 消息，别改顶层 system 字段。每轮收尾看 usage 里的缓存读写字段。

65. 给模型看的示例怎么挑才值回 token 价？#

三条：相关，贴着真实用例；多样，覆盖边界但别让模型学出假规律；结构化，用 <example> 包好，和指令区隔开。

不确定就请模型自己评：把候选发给它，按相关性和多样性打分或补缺口，粗筛完再人工定稿。

66. 多窗口工作流怎么搭，为什么优于硬撑单窗？#

把工作切进多个窗口：第一个窗口搭架子、写测试、建初始化脚本；后续窗口照清单干活；上下文清空后优先开新窗口，而不是硬压。

成熟版是三段式：research 产出研究文档，plan 产出实现计划，implement 照计划干活，人在两道闸口只审文档。

67. 为什么「把 prompt 拿给同事看」是最好的测试？#

因为你自己写自己读，大脑会自动补全没写出来的上下文。同事没有你的脑内缓存，他卡在哪，prompt 就缺哪。

递出去之前先自查三件事：输出格式和约束写具体了吗；有先后依赖的步骤编号了吗；要求额外动作时，交代动机了吗。

68. 为什么对模型说「不要做什么」基本没用？#

禁令只告诉模型别去哪，没说该去哪，模型只能在禁区边上猜。要格式稳定，就告诉它「要做什么」：不要用 markdown，不如说「用流畅的散文段落回答」。

还有一招是风格匹配：提示词自己写满列表，输出就更容易带列表；你希望输出什么样，就把提示词写成什么样。

69. 自认为调好的上下文，为什么实测不如裸奔？#

因为每一层「显然合理」的中间件叠起来，可能互相抵消。实测里，三层清理和摘要配置的记忆召回只有 58%，复测掉到 38%，成本还是什么都不做的两倍。

别靠手感，要上评测：同任务、同数据，把你的配置和全量历史各跑一遍，只对埋点打分，再看成本曲线。

70. 为什么一句话指令常常比一大段规矩更管用？#

规则越厚，单条分到的注意力越薄。一句话能说清的，就不要写一段；具体和简洁不是对立的，啰嗦才是天敌。

骨架是：角色、具体动作、交付形式、可验证标准、一句动机。复杂的多步流程该长还是长，但每一行都要在干活。

71. 「上下文就是大模型的记忆」这句话对吗？#

不准确。完整原版是 working memory，工作内存。上下文即时、有限、掉电即失，但记忆是外存，是每次请求时才编译进来的工作集。

Claude Code 的双通道和 Letta 的 memory blocks 都在说明：记忆和上下文是两层，不该混为一谈。

72. Tobi 为什么把「会不会装上下文」写进绩效？#

因为装载上下文是企业里最容易被跳过的一步：试两次没效果就退回老办法，没人追问是 prompt 的问题、上下文没给够，还是根本没试第二次。

把 AI 使用和上下文能力写进绩效与互评，等于把它从个人手艺变成组织要求。不过这是管理叙事，不是实测数据，引用时要分清。

5. 上下文是怎么烧钱的

73. 为什么缓存只改价钱，不改窗口占用？#

缓存像 CPU 的缓存行：加速取数，但不省内存。已缓存的前缀仍然占窗口，注意力照样被分掉，压缩也照常在上限附近触发。

所以两本账分开看：占多少看 /context，花多少看 /usage。折扣只在账单上，不在窗口里。

74. 为什么多轮对话每说一句话，都在重付全史账单？#

模型没有记忆，每次请求都要重发完整会话。你只发「继续」两个字，这一轮照样按全部历史计费。

到第 50 次工具调用，光历史就可能超过 15 万 token；50 轮对话相当于付了 1275 份单轮输入。缓存能压低单价，改不了这个复利形状。

75. 怎么估算我的任务每月要烧多少上下文钱？#

三个锚点：企业部署人均约 13 美元一个活跃日、150 到 250 美元一个月；按 Sonnet 3 美元每百万 token 算，15 万上下文单轮约 0.45 美元，3 万约 0.09 美元；填满一次 1M 窗口约 0.14 到 10 美元。

月账单约等于：日活跃轮数 × 每轮输入 token × 输入单价 × 缓存折扣。命中率健康时读价约一折，忽高忽低就留三到五折余量。

76. 多 agent 的上下文账单怎么算怎么控？#

聊天算 1 倍，单 agent 约 4 倍，多 agent 约 15 倍；agent teams 在 plan 模式下约 7 倍。每个 teammate 都带独立窗口，各烧各的 token。

控制杠杆：按任务复杂度分级 effort；给思考 token 封顶；团队保持小，干完立刻关，别让活着的 teammate 持续烧钱。

77. KV-cache 命中率上哪查，怎么提？#

Claude Code 的统计行会给出请求数、缓存输入占比、miss 次数和缓存热度；API 侧看 usage 里的 cache_read_input_tokens、cache_creation_input_tokens、input_tokens。

命中率就是读缓存 ÷ 三者之和。提高的办法不是压 token，而是让前缀稳定：工具定义冻结、时间戳后置、历史只增不改。

78. 什么时候该给缓存上一小时 TTL？#

默认五分钟够用就别升级。出现「间隔超过五分钟、一小时以内必有下一单」的节奏，1 小时 TTL 才开始回本。

价格上，五分钟档写缓存是输入价的 1.25 倍，1 小时档是 2 倍，读价都是 0.1 倍。混用两档时，长 TTL 必须排在短 TTL 前面。

79. 启动时怎么预热缓存，把首响拉快？#

发一个 max_tokens: 0 的请求，让 API 读完 prompt 并在断点处写好缓存，然后立刻返回，不生成任何输出 token。

断点要放在和正式请求共享的最后一块上，thinking 和 effort 配置要一致，用显式断点而不是自动缓存。预热本身可能产生一次写缓存计费。

80. 百万窗口什么时候用得起，什么时候是坑？#

一次性投喂大文档很值：填一次、问完就走，账单就是那一次填窗的钱。但首 token 等待会很明显，10 万 token 约 22 秒，80 万以上约 76 秒。

别把 1M 当常驻默认：每轮背着满窗历史跑，首响和账单都按轮复利；实际占用过半后，就只剩检索或压缩二选一。

81. 代码执行怎么把 15 万 token 的活干成 2 千？#

工具定义变成文件系统里的文件，agent 先列目录，只读当下要用的几个；数据在沙箱里脚本对脚本流转，中间结果根本不进模型。

省的是两处：工具说明书不再全量进窗，中间结果不再逐环过模。代价是沙箱需要安全隔离、资源限额和监控。

82. 为什么最便宜的跑法，反而是发最多 token 的？#

因为缓存。每轮发近 30 万 token、97% 命中缓存时，账单可以低到 0.0063 美元一轮；激进裁剪看起来发得少，却打碎了缓存折扣，反而更贵。

但这依赖低缓存价和特定 workload，不是普适定律。缓存价一高，结论会翻面。真正稳的省钱动作是封顶，不是改写。

83. 为什么总结历史比不总结还贵 50%？#

总结省下的 token，抵不过它杀掉的缓存折扣。全量历史每轮 0.11 美元，总结式 0.24 美元；记忆探针 92% 对 38%，又贵又忘。

机制是：缓存命中要求上一轮上下文原样重发，总结改写了前缀，等于把打过折的部分全部按原价重算。

84. 填满一个百万窗口，最贵最便宜差多少倍？#

2026 年 6 月口径下是 71 倍：最便宜约 0.14 美元，最贵约 10 美元。差距主要来自模型单价结构，不是能力档次。

这张表量的是「填一次」的价，不等于「跑一个月」的账。月账还要乘命中率和轮数。

85. 按一次压缩键，凭什么烧掉几千 token 和十几秒？#

因为压缩本身就是一次全量推理请求：读整段会话，生成摘要。15 万 token 的窗口，压缩调用要生成 3000 到 5000 个输出 token，再搭上 5 到 15 秒延迟。

输出按输出价计费，通常是输入价的数倍；压缩还会重写前缀，让缓存整段重建。任务间不需要连续性，直接 /clear 更省。

86. 多干一倍活为什么要贵七倍，还值不值？#

多 agent 的本质是买算力换成功率，token 用量本身能解释八成的效果方差。Claude Code 的 agent teams 在 plan 模式下约 7 倍 token。

值不值看两点：产出能不能独立验收；并行分支之间要不要共享决策。要共享的，单线程把上下文喂好更稳；能独立验收且真并行的，15 倍才花得有价值。

87. 模型一升级，为什么你的窗口悄悄缩水了？#

因为 tokenizer 换了。Opus 4.7 起，同一段文本最多比旧模型多算 35% 的 token，窗口尺寸没动，计数器动了。

升级当天要跑一次 /context，拿同一段历史在新旧模型上各数一遍，预算和速率配额按新数字重报。

88. 想省钱，先砍上下文还是先换模型？#

按顺序走：先查缓存命中率，命中率低先修排布和断点，这是免费的；命中率健康且缓存价低于约 0.55 美元每百万 token，先砍上下文；单价本身太高，再换模型；模型换不动，最后才上外置记忆或代码执行。

每改一个变量测一次，别同时动三处。

6. 上下文好坏怎么知道

89. 上下文质量为什么到现在没有公认评测标准？#

因为「好」在这门手艺里还没被定义出来。失败是静默的：压缩丢掉的是「下文才显出重要性」的细节，当场看不出来。

探针只能测「保留」，测不了「利用」；现有基准追不上生产里几十次有损压缩连成的链式退化。没有公认答案，就只能自己当自己的标准。

90. 怎么用「埋探针」测出 agent 什么时候开始忘事？#

五步：第 0 轮埋一条具体到可判对错的事实；用真实问题把对话推过压缩点；抛一个必须用该事实才能答对的问题；如果本轮压缩没触发，这轮作废；最后让不知道配置来源的 judge 盲评。

埋「300 毫秒」这种点，别埋「用户喜欢简洁」这种模糊偏好。实测里零次压缩全对，五六次之后十道只剩三道。

91. 压缩得好不好，看什么指标才不被骗？#

压缩比会骗人：三家压缩率都在 98% 到 99%，质量分却从 3.35 拉到 3.70，压得最狠的反而垫底。

看六个维度：准确度、上下文感知、足迹、完整度、连续性、指令遵循。最值得盯的是「足迹」——记不记得自己读过、改过哪些文件，这一维全场最弱。

92. 怎么给自己的 workload 搭一套上下文监控？#

三件套：每轮记录总上下文 token，注意要把未缓存、缓存读、缓存写加总，别只看 API 的 input_tokens；给压缩和清理记事件日志；把缓存命中和成本做成固定统计行。

有了这三样，才能回答「哪一轮开始变笨」和「钱花在哪」。

93. 二三十条真实轨迹，怎么起步做最小评测？#

20 到 50 条真实任务就够起步，早期改动的效应量很大，几条用例就看得清。流程是：攒轨迹、配可验证判分、存基线、一次只改一个变量、留一小块做留出测试。

参考答案别自己写，从真人处理记录里拆原子要点，这样 judge 才判得准。

94. 怎么快速给一份上下文装配打分？#

问四个问题：有没有错的版本（正确性）；任务要的前提是不是都在（完整性）；噪声占了几成（大小）；干到一半接得上吗（轨迹）。

排序比清单重要：正确性压倒一切，错信息比缺信息糟，缺信息比噪声糟。别为了省 token 先砍正确性。

95. 为什么 97% 的人都说重要，只有 4% 真做成了？#

因为差距不在认同，在基建。97% 说上下文重要，但只有 4% 走到「知识沉淀、越用越值钱」的成熟度；只有 42% 说自己能准确测量上生产的准备程度。

评测、监控、治理这一层，正是把 97% 变成 4% 的地方。谁先补完基建，谁先拿到红利。

96. 整体得分 97 分，为什么还是会静默遗忘？#

因为整体分测的是「这条回复像不像好回复」：文笔、切题、格式都在场，唯独被忘掉的那件事不在评分表上。实测里质量分 97% 到 99%，记忆探针只有 58%。

验收必须只对埋点打分，整体分只能当仪表盘。要问的是「第 0 轮埋的事实，第 11 轮还取得到吗」。

97. 为什么说可观测性是上下文工程最大的短板？#

因为厂商都在喊上下文重要，却很少有人给你一扇能看进窗口的窗。/context 只能看到静态占用，最要紧的动态消息区反而看不清。

更糟的是度量本身会失真：有 issue 里 /context 报出 1553.9% 这种不可能的读数。对策是把轨迹接进 OpenTelemetry，并让 agent 用结构化格式输出假设和证据。

98. 「不到 5% 的团队有评测」，这数字可信吗？#

数字本身不可信，但描述的现象大概率为真。它来自一位匿名从业者的自述，没有样本量，也没有可核查的调查方法。

引用时要按三步验：问出处、找互证、挂口径。行业报告里 42% 能测量上生产准备程度，恰好指向同一个方向。当证词可以，当统计不行。

99. 学了一堆技巧，怎么知道哪条对我的场景真有效？#

技巧没有通用真值，只有「在你的评测集上涨没涨分」。别凭体感改提示词，拿评测说话。

流程是：从历史故障和现有测试里造评测集，对不同装配方案跑 eval matrix，一次只动一个变量；涨了才留，不涨就删。

100. 上下文工程会像提示词工程一样过气吗？#

会过气一半。具体技巧有保质期：缓存断点怎么摆、阈值设多少、哪些指令要加粗，模型每升级一次就贬值一次。

但另外两半不过气：评测不过气，模型越强，「知道好坏」越稀缺；难题不过气，模型理解复杂上下文很强，生成同样复杂的长输出仍然拉胯。