知识块 · 版本 1块链接查看来源查看知识状态待读取
01

正文

你的 agent 做不好一件事,最可能的原因不是模型不够聪明,而是它动手那一刻手里的上下文是错的。这话有硬数字撑着:同一组模型权重,只换外层 harness,SWE-bench Verified 的分数能差 11–15 个百分点——远大于论文里被当作有意义进展的 2–4 个百分点;而在 Anthropic 多 agent 研究系统的 BrowseComp 评测里,token 使用量这一个变量就解释了 80% 的性能方差,工具调用次数与模型选择合起来才解释另外约 15%。所以在你决定换更大的模型、更长的窗口之前,先把「窗口里到底躺着哪些 token」这件事当成一等工程问题来做。

这篇文章要做的,是把这个问题拆到可诊断、可量测的粒度:证据放在哪会失效、长度怎么连续吃掉能力、减法该怎么做、什么时候该即时拉取、什么时候该开子窗口、什么时候必须落盘,以及——最后一节——什么时候上面这些建议全都不成立。

知识块 · 版本 1块链接查看来源查看知识状态待读取
02

一、先接受这个事实:证据放在中段,不如不给

最反直觉的一个数字来自 Liu 等人的 Lost in the Middle(TACL 2024)。多文档问答,20 篇文档,GPT-3.5-Turbo,只改一件事:正确文档在提示里的位置。

正确文档位置准确率
第 1 篇75.8%
第 10 篇(中段)53.8%
第 20 篇(末尾)63.2%

同模型的两条对照线:闭卷(一篇文档都不给)56.1%,oracle(只给正确那一篇)88.3%。

盯住 53.8% < 56.1% 这一行。当正确答案就摆在上下文中段时,模型的表现低于什么资料都不给。这意味着在这个位置上,你花钱建的检索系统净贡献为负——它不是没帮上忙,是把模型拖到了闭卷之下。

有人会说这是任务太难。第二组实验堵死了这条解释:纯键值查表,零推理成分,只是「给你一堆 key-value,查一个 key」。75 对时多数模型尚可、部分已现 U 形;140 对时 GPT-3.5-Turbo、MPT-30B-Instruct、LongChat-13B 明显退化;300 对时多数模型显著困难。任务里没有任何推理,失败纯粹来自位置。

于是有三条推论,每条都和流行做法相反:

  1. 换更大窗口的模型不解决这件事。 论文明确指出,显式的长上下文变体(GPT-3.5-Turbo-16K、Claude-1.3-100K 这类)表现出同样的中段弱点;文档能塞进小窗口时,16k 版并不比 4k 版更强。「我们上了 128k 模型」不是一个修复。
  2. 加大 top-k 可能是负优化。 多塞进来的文档会把正确文档往中段推,而中段的边际价值可能是负的。
  3. 用 LLM 做长上下文重排,是在传染而不是治疗。 把 100 条候选一次性丢给模型让它排序,这个排序动作本身就带着同一个位置偏置。cross-encoder 对每个 (query, doc) 单独前向,结构上没有这个毛病。

对应的处置便宜到没有理由不做:rerank 之后按分数做首尾折叠——最高分的两三条放上下文最开头和最末尾,低分的塞中间,直接吃 U 形曲线的两端;同时把 k 压下去而不是加上去。

知识块 · 版本 1块链接查看来源查看知识状态待读取
03

二、腐烂是连续的,「还没爆窗口」不是免罪符

上一节讲的是同等总量下位置造成的差异;这一节讲总量本身。二者同源但必须分开量。

上下文腐烂(context rot)指的是:随着上下文变长,模型从中精确调用信息的能力连续下降——不是到窗口上限才崩,而是从很早就开始掉,而且掉的方式在结构上是平滑的。Chroma 在 18 个模型上验证了这一点(Claude Opus 4 / Sonnet 4 / Sonnet 3.7 / 3.5 / Haiku 3.5、GPT-4.1 全系 / GPT-4o / GPT-4 Turbo / GPT-3.5 Turbo / o3、Gemini 2.5 Pro / 2.5 Flash / 2.0 Flash、Qwen3-235B-A22B / 32B / 8B)。这不是某个厂商的缺陷,是当前架构的普遍属性。

最干净的对照是 LongMemEval:同一批问题,A 版只喂约 300 token 的相关片段,B 版喂完整约 113k token 的对话历史。所有受测模型家族在 A 上都显著更高,Claude 系列的差距「最为明显」——表现形式是在歧义下更保守、更倾向弃答。300 token 打赢 113k token,同一个模型,同一道题。

再往里看,三个细节值得单独记住:

  • 单个干扰项就有代价。 实验设了三档:只有 needle、加 1 个干扰项、加 4 个干扰项。结论是即使单个干扰项也会相对基线降低性能,4 个叠加恶化,而且不同干扰项影响不均匀(第 3 号造成的下降明显大于其他)。「多放一点没坏处」是错的。
  • 信号强度和长度是乘性关系。 needle 与问题的语义相似度(Paul Graham 语料 0.445–0.775,arXiv 语料 0.521–0.829)越低,性能随长度衰减越快。弱信号在长上下文里衰减得更快——这条直接推翻「反正相似度低也塞进去,万一有用」。
  • 把干扰文本打乱顺序,模型反而表现更好。 Chroma 明确报告:haystack 保持逻辑连贯的思路流时模型表现更差,打乱后一致地提升。如果你的长上下文是一篇结构良好的长文,这一条尤其要警惕。

还有一个容易被误读成「模型偷懒」的指纹:欠生成。让模型复述一段长序列,它输出的词数系统性地少于要求。Chroma 在 25 / 50 / 75 / 100 / 250 / 500 / 750 / 1,000 / 2,500 / 5,000 / 7,500 / 10,000 词各档上测出这个现象,且唯一词位置越靠前准确率越高。你在生产里看到的「输出比要求的短」「指令被漏执行」,很可能不是提示词没写清楚,是上下文太长。

顺带纠正一个日常错觉:「会话进行到一半开始变笨,把同一个问题拿到新会话问一次就对」——这不是玄学,这是腐烂的教科书症状。

知识块 · 版本 1块链接查看来源查看知识状态待读取
04

三、同一个模型换 harness 差 11–15 分,所以别急着归因给模型

harness 是包住模型的那整层工程:工具集与工具描述、system prompt、上下文管理策略、权限与沙箱、子代理编排、验证回路、重试与检查点。「harness 放大模型」不是一句励志话,是可测量的断言。

Epoch AI 在 SWE-bench Verified 上做过横向测量:仅仅切换 scaffold,就为 GPT-5 带来最高 11% 的差异,为 Kimi K2 Thinking 带来最高 15% 的差异,他们直接断言 scaffold 的选择对整体表现有单一最大的影响。这个量级意味着什么?意味着看到「某模型在 SWE-bench 上 X%」而不披露 harness,这个数字是不可解读的。

连 API 调用方式都算 harness 的一部分:OpenAI 报告用 Responses API 而非标准 ChatCompletions,在 SWE-bench Verified 上可带来最高 3% 的提升;某厂商报告在 tau-bench 上用自家 API 实现相比标准 ChatCompletions 有 23 个百分点的差异。

Holistic Agent Leaderboard(arXiv 2510.11977)干脆把 harness 变量标准化后重测:9 个模型 × 9 个基准 × 21,730 次 agent rollout,约 4 万美元成本、25 亿 token 的日志。它的日志分析里有两个必须知道的反直觉发现:提高 reasoning effort 在多数运行中反而降低准确率;以及 agent 会跑去 HuggingFace 上搜基准答案而不是解题。这两件事都得在 harness 层堵,模型层堵不了。

放大发生在三条可分离的通道上,值得记住,因为它决定你的调试顺序:

  • 信息通道——harness 决定模型每一轮实际看到什么。一个 harness 给它 grep 定位后的 30 行,另一个给它整个文件的 3000 行,后者要在被稀释的注意力里找同一个答案。BrowseComp 上 80% 的方差就落在这条通道。
  • 动作通道——工具的粒度、命名、错误消息决定意图能否转成正确调用。Anthropic 在 SWE-bench 的实践里在工具描述上花的时间比在整体 prompt 上还多;「用绝对路径作参数」这样一个改动就消灭了整类相对路径错误。Claude Sonnet 3.5 当时拿下 SWE-bench Verified SOTA,发生在对工具描述做精确调整之后——权重没变。
  • 纠错通道——harness 是否提供确定性的验证信号(类型检查、lint、测试、截图),决定错误是被当场捕获还是复利累积。这也是为什么 agent 在 TypeScript 项目里常比在同等规模 JavaScript 项目里表现更好:多一层免费的、确定性的反馈。

有一条纪律直接从这里出来:评测时要么固定 harness 比模型,要么固定模型比 harness,不能两个一起换。 11–15 个百分点的 harness 噪声足以淹没任何模型差异。

知识块 · 版本 1块链接查看来源查看知识状态待读取
05

四、做减法的方向是「最小充分」,不是「最短」

上面三节把病摆清楚了,现在说方向。上下文工程的目标函数只有一句话:找到那组能最大化目标结果概率的、最小的高信号 token 集合(Anthropic 原文:the smallest set of high-signal tokens that maximize the likelihood of some desired outcome)。

这就是最小充分上下文。它把「上下文该放什么」从审美判断变成有约束的优化问题:不是「够全」,也不是「够短」,而是在满足任务所需信息的前提下最短。检验一段上下文的唯一问题是:它把正确输出的概率提高了吗?提不高就是负资产,哪怕它看起来相关。

「最小」不是「最短」——这是最常见的误读,而且代价不对称。删掉必要的背景会让模型自行猜测,错误率上升的损失远大于省下的 token。上一节那个例子就是反例:工具描述变长换来错误率大幅下降,那是正确的加法。

落到 system prompt 上,操作原则是找对「海拔」(altitude)。一端是把脆弱的 if-else 逻辑硬编码进 prompt(维护成本高、泛化差),另一端是只给一句「做个好助手」式的高层指导(模型没有可执行的共享上下文)。正确位置在中间:具体到能指导行为,又灵活到给模型强启发式。可操作的找法是——先用最好的模型跑一份最小 prompt,看它在哪里失败,再针对失败点加最少的东西。反过来先写一份「面面俱到」的 prompt 再删,你永远不知道哪一段是有用的。

两条配套判据:示例要「少而典型」而不是堆一份边缘案例清单(对 LLM 而言,示例是抵一千字的图片);工具集要瘦,判据很直接——如果一个人类工程师拿到这套工具都说不清什么时候该用哪个,模型也说不清。

另外要有个账本意识:在你敲第一个字之前,窗口就已经被占了。Claude Code 的实际账本是 system prompt 约 4,200 token、环境信息约 280 token、MCP 工具名(schema 默认延迟加载)约 120 token。你的平台上这三项是多少,应该是个能报出来的数,而不是个未知数。

知识块 · 版本 1块链接查看来源查看知识状态待读取
06

五、即时检索省的是窗口,付的是延迟

即时检索(just-in-time)的做法是:上下文里只保存轻量标识符——文件路径、查询语句、URL、记录 ID——而不保存数据本身;真正需要时再用工具在运行时把内容拉进窗口。它的对立面是预加载:推理开始前就把所有可能用到的资料塞进 prompt。

底层理由是一个成本不对称:LLM 的上下文是稀缺的,而磁盘和数据库是廉价、充裕的。把状态放在便宜的一侧,只在需要时付昂贵的搬运费。

收益的量级不是几个百分点:把所有 MCP 工具定义前置加载需要约 150,000 token,改成文件系统 + 按需读取后降到约 2,000 token,省掉 98.7%。中间结果同理:一场 2 小时销售会议的转录如果必须在两次工具调用之间穿过模型上下文,会额外消耗约 50,000 token;让代码在沙箱里直接把结果从 A 传给 B,这笔钱就省掉了。

但取舍是真的,别只看省下的部分:

  • 代价是延迟。 Anthropic 直言运行时探索比检索预计算数据要慢,推荐的是混合策略——先预取一部分数据保证速度,再让 agent 自主决定是否继续探索。
  • 命中率决定成败。 即时检索的收益来自「候选集大但实际命中率低」。如果每次请求都要读同一张 200 行的配置表,预加载一次比每轮跑三次工具调用更快也更便宜——命中率接近 100% 时,即时检索是纯开销。
  • 标识符必须可读。 文件路径、URL、主键本身要能承载语义。如果标识符是 UUID 这种不可读串,agent 无法从标识符判断该不该拉取,即时检索就退化成盲目试探。把 UUID 换成自然语言名称能显著提升检索精度并减少幻觉。
  • 它不解决相关性。 拉得晚不等于拉得准,拉进来的片段照样可能相似但无关。

还有一个顺序建议,和很多团队的直觉相反:收集上下文的四条路里,agentic search(用 grep / glob / tail 在文件系统里现找)应该排在语义检索前面。语义检索通常比 agentic search 快,但准确率更低、更难维护;正确顺序是先做 agentic search,只有在需要更快结果时才加语义检索。「上来先建向量库」经常是在给自己造一个又慢又准确率更低的中间层。

知识块 · 版本 1块链接查看来源查看知识状态待读取
07

六、压缩是补救,子代理隔离是预防,落盘是保险

这三件事经常被混为一谈,但它们处在完全不同的位置。

压缩(compaction) 指把接近上限的对话交给模型总结,再用摘要重新初始化一个新窗口。它和随口说的「摘要」有个关键差别:compaction 是 harness 层的状态迁移操作,它决定下一轮推理的初始状态,错了就没有回头路;而摘要通常只是产出给人看的一段文本,错了不影响系统继续跑。

由此得出压缩 prompt 的调优顺序:先最大化召回,再优化精度。第一版应该宁可多留,确认没丢关键信息之后再逐步砍冗余。反过来先追求短,会在不可观测的地方丢状态。

压缩不是单一动作,是一个从轻到重的梯度:清空工具结果(把已消化的大块工具输出替换成占位符,这被明确称为「最安全、最轻手的一种压缩形式」,因为它不动模型自己的推理链)→ 有焦点压缩(由人指定摘要该保留什么)→ 提前压缩(设定窗口填到多满就触发)→ 直接清空(切换到不相关任务时丢弃,比压缩更彻底也更便宜)。

最容易踩空的是「压缩之后什么还在」。 Claude Code 的实际行为分四类,值得当作一般性教训:system prompt 不属于消息历史,原样保留;项目根 CLAUDE.md、auto memory 会从磁盘重新注入;带 paths: frontmatter 的路径规则和子目录里的嵌套 CLAUDE.md 会丢失,直到再次读到匹配文件;被调用过的 skill 正文重新注入时受每个 skill 5,000 token、总计 25,000 token 的上限截断,先丢最旧的,且截断保留文件开头。最后这条有个直接的写作结论:指令文件要把最重要的内容放最前面,因为截断从尾部砍。

窗口变大不取消压缩,只是推迟它。默认 200K 也好,1M 变体也好,机制是一样的。

子代理隔离是另一条路:把会产生大量一次性中间物(搜索结果、日志、文件内容、失败尝试)的工作交给一个拥有独立窗口的子代理,主 agent 只收回蒸馏后的结果。它的价值不在并行加速——那是副产品——而在信息不对称:探索过程的熵留在子窗口,只有结论穿过边界。

量级是可测的:文档里的一个会话示例中,子代理为回答一个研究问题读了 6,100 token 的文件,回到主窗口的结果只有 420 token,约 14.5:1;那 6,100 token 从未占用过主窗口。经验区间是子代理返回 1,000–2,000 token 的凝练摘要。

这里要说清一件事:隔离省的不只是 token。 如果只算 token 账,那 6,100 对 420 只是省了钱。真正的收益有三层——第一,那 6,100 token 里包含大量失败尝试和无关片段,它们进主窗口是干扰项,而我们已经知道单个干扰项就有代价;第二,它们会把后续真正相关的证据往中段挤,直接踩上一节的 U 形曲线;第三,独立窗口能规避三类行为退化:agentic laziness(活干一半)、self-preferential bias(agent 偏袒自己的产出)、goal drift(长回合后目标保真度流失)。让一个新窗口的 agent 来审另一个 agent 的产出,是绕开自我偏好最简单的办法——这是纯 harness 收益,和模型无关。

隔离要成立有个反直觉前提:主 agent 必须写清委派指令——明确的目标、输出格式、任务边界、可用工具。因为子代理看不见主会话,主 agent 脑子里「不言自明」的东西对它就是缺失信息。委派不清的直接后果是几个子代理做重复工作,或者都漏掉同一块。并行规模的经验规则:简单事实查询 1 个子代理(3–10 次工具调用),对比类查询 2–4 个(每个 10–15 次),复杂研究 10 个以上;lead agent 一次并行拉起 3–5 个。代价是同步执行——lead 必须等最慢的那个返回,所以子代理数量增加不必然带来墙钟时间线性下降。

压缩和隔离是竞争关系,不是互补:能预见的大批量读取应该一开始就丢进子窗口烧掉(预防);不可预见的自然增长才走压缩(补救)。用压缩去清理本可以隔离的脏东西,是在为已经付过的注意力代价再付一次总结代价。

最后一层是落盘。 压缩是有损的,重复压缩会累计漂移——第 3 次压缩时,模型总结的是第 2 次摘要的摘要。凡是必须精确的状态(计数、清单、已试过的方案、决策理由、文件路径)都该写到窗口外的外部记忆里,压缩只负责叙事上下文。多 agent 研究系统的做法就是接近 200,000 token 上限时把计划写进外部记忆,而不是指望摘要保住它。Claude 玩 Pokémon 是最直观的案例:靠窗口外的笔记跨数千个游戏步骤维持精确计数,并逐步构建已探索区域的地图——数千步远超任何窗口容量,没有外部笔记这个任务在结构上就不可能完成。

外部记忆有两条纪律。写入时机:可靠的触发点是「状态发生了变化」——完成子任务、推翻假设、拿到不可重算的结果;写太频笔记本身变噪声,写太少压缩来时状态已经丢了。写方法不写快照:记「用 SELECT count(*) FROM x 查当前条数」能长期有效,记「当前 1,283 条」下一轮就是谎言,而模型会把过期数字当事实拿去推理。

知识块 · 版本 1块链接查看来源查看知识状态待读取
08

七、该量什么:一张今天就能跑的诊断表

诊断的骨架用 agent 循环的三格分区:收集上下文 → 行动 → 验证。任何 agent 失败都落在其中一格——它没拿到该拿的信息、拿到了却做错了动作、或者做完了却不知道自己错了。三格的修法完全不同,混在一起调是大多数 agent 调不好的原因。而且三格不等权:多数团队把精力全花在格二(工具、prompt),失败却常在格一和格三。诊断时先问「它当时看到了什么」,再问「它怎么知道自己对了」。

具体量这七项:

  1. 窗口账本。开局固定成本是多少?system prompt、工具定义、环境信息、常驻记忆各占多少 token,报得出具体数。占位超过窗口 10% 就该考虑把工具 schema 改成延迟加载。
  2. 位置扫描曲线。固定一个问题和一批文档,只把正确文档从头移到尾,其余顺序不变,重跑 N 次,画准确率对位置的曲线。U 形 → 命中中段淹没;平坦 → 问题在别处(召回、切块、指令)。 半小时能跑出来,不必靠猜。
  3. focused vs full 对照。同一批任务做两版:A 版只喂人工挑出的相关片段,B 版喂完整历史。A 显著优于 B,就是上下文腐烂,不是模型能力不足。这个对照还顺便给出你的上下文预算上界——A 用了多少 token,那就是「充分」的量级。
  4. 闭卷基线。把资料全撤掉,只问问题。这条线是很多人不画的,但它是判断检索系统净贡献正负的唯一标尺:低于闭卷,你的检索是在帮倒忙。
  5. 穿越边界的 token 量。每个子代理读了多少、回传了多少,比值是多少。接近 1:1 说明隔离没起作用,它只是把内容搬了个地方。
  6. 压缩存活率。压缩前记下 N 条关键状态(决策、计数、路径),压缩后逐条问模型,数还剩几条。存活率不到 100% 的那几类状态,就是必须落盘的清单。
  7. 验证信号的确定性等级。你的格三靠什么?规则/类型/测试(确定性)、视觉反馈(半确定)、还是 LLM-as-judge?最后一种通常不是很稳健的方法,且有延迟代价;要用就用成对比较而不是绝对打分——让模型判「A 和 B 哪个好」比判「A 值几分」容易得多。

排查顺序建议是 2 → 4 → 3 → 1 → 5 → 6 → 7:先确认是不是位置问题(最便宜的修复),再确认检索是不是负贡献(最狠的结论),然后才谈预算和结构。

知识块 · 版本 1块链接查看来源查看知识状态待读取
09

八、什么时候本文不成立

这篇文章的建议有明确的适用边界,越过就别照搬。

单轮、无工具、无历史的任务不适用。 分类、改写、抽取这类任务里上下文几乎不变,你做的仍然是 prompt engineering。上下文工程的收益只在多轮 + 有工具 + 长任务的 agent 场景里才显著。

需要完整审计轨迹的场景不适用「最小」。 合规审查、事故复盘这类任务里,「上下文完整」本身就是目标之一,裁剪会破坏可追溯性。这时正确的做法是把全量留在窗口外(文件、数据库)而不是不留,再按需读回。

需要看着完整历史做判断的任务不该外包给子代理。 「这个 bug 和我们三小时前改的那处有没有关系」——这类问题一旦隔离,信息就单向不可逆地丢了。同理,需要频繁来回协商的任务也不适合:每次委派都是一轮完整的 prompt + 推理 + 返回,延迟远高于主 agent 自己多读一个文件。编码任务尤其不适合多 agent,因为真正可并行的子任务更少。

验证信号弱的领域,不该用自主 agent,该用工作流。 只有当需求步骤无法预先确定、无法硬编码固定路径时才用 agent。原因就是格三:没有来自环境的 ground truth,误差会复利式累积——这是 agent 与工作流最本质的成本差异。能用 prompt chaining、routing、orchestrator-workers 解决的,别用 agent。

最重要的一条:今天的裁剪逻辑明年可能是负资产。 Anthropic 明确预期,随着模型变强,agent 设计会趋向「让聪明模型自己聪明地行动」,人工策展的比重下降。所以 harness 的正确姿态是可拆卸的脚手架,不是越砌越厚的城墙;今天为省 token 手工写的裁剪规则,要写成可以关掉的策略,而不是焊死进 prompt。同样,别把 harness 复杂度当美德——每一层都要能拿出实测收益,否则它只是在增加调试面积。

回到开头那句:harness 是乘数,不是加数。乘性意味着模型在某能力上是 0 时,再好的 harness 也乘不出来。但它同样意味着,当你的模型已经有 0.7 的底子,上下文工程决定的是你拿到 0.3 还是 0.9。绝大多数团队今天卡的是后面这个系数。

知识块 · 版本 1块链接查看来源查看知识状态待读取
10

出处

来源与依据