上下文工程实战：本质是预算管理

2026 年，上下文窗口越来越大：1M token 的模型已经不稀奇，10M 的也在路上了。于是很多人得出一个结论："窗口这么大，全塞进去不就行了？"然后账单来了：一次任务烧掉几十万 token，输出质量还没比"精选 5 个文件"好。

这篇讲上下文工程的实战。核心观点：上下文工程的本质是预算管理——你的预算有三本账：token 的钱、模型的注意力、你的时间。管好这三本账，Agent 的效果翻倍；管不好，窗口再大也是浪费。

第一本账：token 的钱

先算清楚。假设主力模型 $2/$10 per 1M tokens（2026 年下半年的标准价，见本批 art9/art11），一个中等任务：输入 100K tokens（含历史对话+检索的代码），输出 10K。单次成本 = 0.1×$2 + 0.01×$10 = $0.3。看起来不多？一天跑 100 个任务，一个月就是 $900。对独立开发者，这不是小钱。

省钱的三个杠杆，按 ROI 排序：

• 缓存一切可缓存的。系统 prompt、AGENTS.md、项目结构说明——这些每次任务都一样的东西，走 prompt caching（$0.10-$0.20 per 1M，见 art11），成本直接打 1 折。这是 2026 年最确定的省钱手段，不用就是亏。
• 检索代替堆砌。别把整个 src/ 塞进去。用代码索引/RAG，先检索出最相关的 5-10 个文件。实测：精准检索的输入量通常是"全塞"的 1/10，效果反而更好——因为噪音少了。
• 历史对话定期压缩。长任务里，历史对话是 token 黑洞。每 10-20 轮，让 Agent 自己总结一次（"把目前的进展、关键决策、待办压缩成 500 字"），然后用总结替换原文。Claude Code 的 compaction、Codex 的自动压缩都是这个思路，手动做也行。

第二本账：模型的注意力

这本账比钱更重要。模型的注意力是有限的，上下文越长，有效注意力越稀释——"大海捞针"测试早就证明了：信息在长上下文里的位置，显著影响模型能不能用到它。1M 窗口不等于 1M 有效窗口。

管理注意力的四条军规：

• 重要的放两头。开头和结尾是注意力高地。系统指令放开头，当前任务放结尾，中间放参考材料。这是 transformer 架构的特性，不是玄学。
• 结构化 beats 自然语言。给模型看代码结构，用"文件树+接口签名"而不是"把 10 个文件全文粘进来"。给需求，用"编号列表"而不是"一段散文"。结构化信息的信噪比更高，模型处理得更快更准。
• 一次只给"当前步"需要的信息。Agent 做第 5 步时，第 1 步的详细日志已经没用了，留个摘要就行。这叫"上下文衰减"——信息随时间贬值，要主动清理。好的 Agent 框架会自动做（compaction），手动工作流里，你要定期跟 Agent 说"忘了前面的细节，只记住结论"。
• 用"引用"代替"复制"。"参考 src/auth/login.ts 的错误处理模式"比把 login.ts 全文粘进来好。现代 Agent 工具都支持文件引用（@、#），让模型按需去读，而不是你替它决定读什么。

第三本账：你的时间

最容易被忽视的一本账。你花 30 分钟精心准备上下文，省了 Agent 5 分钟的试错——这买卖划算吗？取决于你的时薪和任务的重复度。

决策框架：一次性任务，上下文准备不超过 10 分钟——随手给几个关键文件，剩下的让 Agent 自己探索（它有工具）。重复性任务，值得投入 2 小时建"上下文资产"——AGENTS.md、few-shot 示例库、常用检索模板。这些资产每次任务都在帮你省时间，ROI 越用越高。

一个反模式："上下文完美主义"。有些人花一小时调 prompt 和上下文，就为了让 Agent 一次成功。但 Agent 试错一次才 30 秒、$0.3——你的 1 小时值多少个 $0.3？接受"70 分的上下文+2 轮反馈"，比追求"100 分的上下文+0 轮反馈"划算得多。记住 guide7 的结论：反馈循环是 2026 年的核心技能，别把功夫全花在第一帧。

实战模板：一个任务的上下文清单

每次开新任务，按这个清单准备上下文，5 分钟搞定：

• □ AGENTS.md（项目级，让 Agent 自己读，不用你粘）
• □ 任务描述：3 句话——干什么、验收标准是什么、有什么约束
• □ 关键文件引用：3-5 个，用 @ 或 # 引用，不粘全文
• □ 反例/正例：1 个"别这么干"的例子，胜过 10 句"要小心"
• □ 输出格式：要 diff 还是完整文件？要解释还是只给代码？说清楚，省得 Agent 猜

三本账的量化案例：一个任务的真实成本

理论讲多了，来算一笔真实的账。假设你要用 Agent 重构一个 5000 行的模块：

方案 A：全塞进去。输入：整个模块 5000 行 ≈ 60K tokens，加上历史对话 20K，共 80K。按 $2/$10 计：输入 $0.16，输出 8K tokens $0.08，单次 $0.24。看起来便宜？但"全塞"的噪音大，Agent 平均要 3 轮才做对（第一轮理解错文件关系，第二轮修，第三轮才过测试）。总成本 $0.72，耗时 25 分钟（含你 review 的时间）。

方案 B：检索+缓存。输入：AGENTS.md（缓存命中，$0.10）+ 检索出的 6 个关键文件 12K tokens + 任务描述 1K。输入成本：缓存部分按 $0.10，新增 13K 按 $2 ≈ $0.027。输出 6K（更精准的输入→更短的输出）$0.06。单次 $0.087，一轮做对（因为给的全是要点）。总成本 $0.087，耗时 8 分钟。

差了 8 倍的成本，3 倍的时间。而方案 B 多花的时间，只是你前期 10 分钟写 AGENTS.md 和调检索——这 10 分钟是"资产"，下次任务接着用。算清楚这笔账，你就再也不会"全塞"了。

工具对照：主流 Agent 工具的上下文管理功能

2026 年下半年，主流工具的上下文管理能力分三档：

• 第一档（自动管理）：Claude Code。自动 compaction（历史压缩）、/config 里可调的上下文策略、AGENTS.md 原生支持。你要做的最少，适合"不想操心"的人。代价是"黑盒"——它怎么压缩的，你看不到，偶尔会丢关键信息。
• 第二档（半自动）：Codex CLI、Cursor。提供@引用、文件级缓存、手动压缩命令，但"什么时候压缩、压缩什么"要你自己决策。灵活度最高，适合愿意动手的进阶用户。Cursor 的 Rules + @ 组合，是目前"手动上下文管理"的天花板。
• 第三档（裸奔）：裸 API 调用。直接调 API 的，你的上下文管理全靠自己写代码：检索、分块、压缩、缓存，每一行都自己来。最累，但也最可控——做 AI 产品的，大概率在这档，因为"上下文策略"本身就是产品竞争力。

选型建议：个人用第一档或第二档，别在第三档浪费时间（除非你在做产品）；做 AI 产品必须第三档，因为"把上下文管好"就是你的护城河。

上下文资产的目录结构：一个可复制的模板

最后给一个"上下文资产"的目录结构，直接抄：

• AGENTS.md（项目根目录）：宪法，100 行，见本批 art14。
• .agent/examples/：few-shot 示例库。每个高频任务一个文件：输入（任务描述）+ 输出（好的结果）。Agent 跑新任务前，先读同类示例。
• .agent/patterns.md：代码模式文档。"这个项目里错误处理怎么写""API 返回格式是什么"，把"惯例"写下来，别让 Agent 每次都猜。
• .agent/review-checklist.md：review 清单（本批 guide9），Agent 提交前自查用。
• .agent/context-budget.md：记录每个任务类型的"上下文预算"——"重构任务：输入不超过 30K tokens""修 bug：先给报错+相关文件，不超过 10K"。预算超了，说明任务拆得不够细，回去拆。

这套资产建起来要 2-3 小时，但它是"一次投入、永久分红"。三个月后，你会发现你的 Agent 任务成功率、平均 token 成本、你的准备时间，三个指标同时变好——这就是"上下文工程"的复利。

3 个反模式：别这么管上下文

最后，三个最常见的"管错了"的反模式，对照自查：

反模式一："囤积症"——什么都舍不得删。历史对话 200 轮了还留着，"万一后面用得上呢"。真相：200 轮之前的信息，后面用上的概率 <1%，但每一轮都在烧钱、稀释注意力。治法：定一条铁律——"超过 20 轮的历史，必须压缩成摘要"。别心疼，压缩丢的那点信息，远没有省下的钱重要。

反模式二："巨婴式投喂"——替 Agent 做所有决定。有些人把 30 个文件全找好、排好序、写好摘要，再喂给 Agent。这 2 小时的"准备"，Agent 自己检索 5 分钟也能做到 80 分。你的时间比 token 贵得多——准备上下文的上限是 10 分钟（一次性任务），超了就是你在替 Agent 打工。

反模式三："玄学调参"——凭感觉调检索数量。"召回 10 个文件效果不好，试试 20 个？"——别猜，测。固定 5 个代表性任务，检索数量分别设 5/10/20，记录成功率和 token 成本，画条曲线。多数人的最优点在 5-10 之间，超过 10 收益递减。用数据代替感觉，这是"工程"二字的含义。

工具推荐：从哪个开始

如果你不知道从哪下手，按这个顺序试：个人用户先用 Claude Code 的自动压缩（零配置），觉得"黑盒"不放心，换 Codex CLI 或 Cursor 的手动 @ 引用；做 AI 产品，直接上 LangChain 的检索+压缩组件，别自己写。记住原则：先用自动的，遇到天花板再换手动的——大多数人的上下文问题，自动工具已经能解决 80%。

一句话总结：上下文工程不是"怎么塞更多"，是"怎么花更少、办更多"。三本账——token 的钱、模型的注意力、你的时间——每一本都要精打细算。窗口越来越大是好事，但它奖励的不是"塞得多的人"，是"管得好的人"。2026 年下半场，vibe coding 的竞争已经从"谁的模型强"变成了"谁的上下文管理好"。而后者，不花钱，只花心思——这是独立开发者最公平的战场。