点击知识块看内容，点击连线看依据。没有关系的块也保留。
你的 agent 做不好一件事,最可能的原因不是模型不够聪明,而是它动手那一刻手里的上下文是错的。这话有硬数字撑着:同一组模型权重,只换外层 harness,SWE-bench Verified 的分数能差 11–15 个百分点——远大于论文里被当作有意义进展的 2–4 个百分点;而在 Anthropic 多 agent 研究系统的 BrowseComp 评测里,token 使用量这一个变量就解释了 80% 的性能方差,工具调用次数与模型选择合起来才解释另外约 15%。所以在你决定换更大的模型、更长的窗口之前,先把「窗口里到底躺着哪些 token」这件事当成一等工程问题来做。
这篇文章要做的,是把这个问题拆到可诊断、可量测的粒度:证据放在哪会失效、长度怎么连续吃掉能力、减法该怎么做、什么时候该即时拉取、什么时候该开子窗口、什么时候必须落盘,以及——最后一节——什么时候上面这些建议全都不成立。
最反直觉的一个数字来自 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 对时多数模型显著困难。任务里没有任何推理,失败纯粹来自位置。
于是有三条推论,每条都和流行做法相反:
对应的处置便宜到没有理由不做:rerank 之后按分数做首尾折叠——最高分的两三条放上下文最开头和最末尾,低分的塞中间,直接吃 U 形曲线的两端;同时把 k 压下去而不是加上去。
上一节讲的是同等总量下位置造成的差异;这一节讲总量本身。二者同源但必须分开量。
上下文腐烂(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,同一个模型,同一道题。
再往里看,三个细节值得单独记住:
还有一个容易被误读成「模型偷懒」的指纹:欠生成。让模型复述一段长序列,它输出的词数系统性地少于要求。Chroma 在 25 / 50 / 75 / 100 / 250 / 500 / 750 / 1,000 / 2,500 / 5,000 / 7,500 / 10,000 词各档上测出这个现象,且唯一词位置越靠前准确率越高。你在生产里看到的「输出比要求的短」「指令被漏执行」,很可能不是提示词没写清楚,是上下文太长。
顺带纠正一个日常错觉:「会话进行到一半开始变笨,把同一个问题拿到新会话问一次就对」——这不是玄学,这是腐烂的教科书症状。
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,不能两个一起换。 11–15 个百分点的 harness 噪声足以淹没任何模型差异。
上面三节把病摆清楚了,现在说方向。上下文工程的目标函数只有一句话:找到那组能最大化目标结果概率的、最小的高信号 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。你的平台上这三项是多少,应该是个能报出来的数,而不是个未知数。
即时检索(just-in-time)的做法是:上下文里只保存轻量标识符——文件路径、查询语句、URL、记录 ID——而不保存数据本身;真正需要时再用工具在运行时把内容拉进窗口。它的对立面是预加载:推理开始前就把所有可能用到的资料塞进 prompt。
底层理由是一个成本不对称:LLM 的上下文是稀缺的,而磁盘和数据库是廉价、充裕的。把状态放在便宜的一侧,只在需要时付昂贵的搬运费。
收益的量级不是几个百分点:把所有 MCP 工具定义前置加载需要约 150,000 token,改成文件系统 + 按需读取后降到约 2,000 token,省掉 98.7%。中间结果同理:一场 2 小时销售会议的转录如果必须在两次工具调用之间穿过模型上下文,会额外消耗约 50,000 token;让代码在沙箱里直接把结果从 A 传给 B,这笔钱就省掉了。
但取舍是真的,别只看省下的部分:
还有一个顺序建议,和很多团队的直觉相反:收集上下文的四条路里,agentic search(用 grep / glob / tail 在文件系统里现找)应该排在语义检索前面。语义检索通常比 agentic search 快,但准确率更低、更难维护;正确顺序是先做 agentic search,只有在需要更快结果时才加语义检索。「上来先建向量库」经常是在给自己造一个又慢又准确率更低的中间层。
这三件事经常被混为一谈,但它们处在完全不同的位置。
压缩(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 条」下一轮就是谎言,而模型会把过期数字当事实拿去推理。
诊断的骨架用 agent 循环的三格分区:收集上下文 → 行动 → 验证。任何 agent 失败都落在其中一格——它没拿到该拿的信息、拿到了却做错了动作、或者做完了却不知道自己错了。三格的修法完全不同,混在一起调是大多数 agent 调不好的原因。而且三格不等权:多数团队把精力全花在格二(工具、prompt),失败却常在格一和格三。诊断时先问「它当时看到了什么」,再问「它怎么知道自己对了」。
具体量这七项:
排查顺序建议是 2 → 4 → 3 → 1 → 5 → 6 → 7:先确认是不是位置问题(最便宜的修复),再确认检索是不是负贡献(最狠的结论),然后才谈预算和结构。
这篇文章的建议有明确的适用边界,越过就别照搬。
单轮、无工具、无历史的任务不适用。 分类、改写、抽取这类任务里上下文几乎不变,你做的仍然是 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。绝大多数团队今天卡的是后面这个系数。