上下文工程与退化

Context Engineering And Context Rot · context-engineering-and-context-rot--raviv-khan

解决什么问题

AI 产品答错时不知道该怪模型还是怪输入；长对话越聊越笨不知原因；不知道如何在有限的 context window 里安排信息让 AI 发挥最好。

核心内容

先查上下文再怪模型：AI 产品给出错误答案时，第一反应不该是换更大的模型或做昂贵的微调，而是问"agent 到底有没有拿到对的信息？"
RAG 祛魅：RAG 就是"开口之前先把资料查一遍"。无论 Perplexity、Claude Code、Cursor 还是任何标着 RAG 的产品，本质都是某种"拉取文档并把它们放进对话开头"的机制。
Context engineering 的定义：在有限 context window 内为 AI 安排好完成任务所需的一切。上下文有两条进入路径：(1) 每次会话手动选择的（拖入文件夹/研究转写/技术文档、启用分析工具的 MCP、指定指令集）；(2) 每次自动进入的（AGENTS.md、MCP、tool 定义）。
Context 是稀缺资源：tool 定义、RAG 结果、memory、目标、对话历史竞争同一个窗口。对话式产品里每轮回复都会变成下一轮的输入，窗口持续膨胀。作者建议像盯汽车油表一样盯 token 用量（Cursor 聊天框下的饼图），用日常使用建立"200K/1M token 到底是多大、多快用完"的体感。
Context rot：塞进的 token 越多，模型表现越差——而且远在到达窗口上限之前就开始退化。退化程度取决于任务与模型：创意脑暴不敏感；金融、编码、数据分析等精确任务明显。感知它的最好方式是拿真正在乎的任务观察输出质量随 token 增长的变化。
四类工程对策（对应生产系统的常见方案）：
1. Progressive disclosure：框架/工具/指令用到时才拉入而非预载（Claude Skills 是典型例子；手动拖文件也是一种）。
2. Subagent：另开线程做子任务，只把"结论"传回主线程，保持主窗口干净。
3. 压缩工具面：把多个 MCP 工具合并成单个工具，或让 agent 现场选择组合工具。
4. 接近上限时修剪/总结上下文——让 LLM 总结后开新线程就是手动版。

适用边界

没有完美公式：放什么进窗口取决于任务、模型和目标，只能靠反复试验加日常使用建立直觉。
context rot 是模糊现象，不同模型训练差异大，具体阈值需自测。

关键引述 · 原话

Andrej Karpathy（原文转引的推文）: "context engineering is the delicate art and science of filling the context window"

Tal Raviv & Aman Khan: "In short, model performance degrades the more tokens you stuff into the context window."

— Tal Raviv & Aman Khan

关联卡片

Agent 记忆即前缀文本 Agent 三人群聊模型多 Agent 上下文分区面向AI上下文PRD文件系统

- 同源卡：`agent-memory-is-a-prepended-text-file--raviv-khan`、`agent-as-three-way-group-chat--raviv-khan`。 - 呼应 `multi-agent-context-partitioning--claire-vo`（subagent 隔离上下文）、`prd-file-system-for-ai-context--lazar-jovanovic`（用文件系统供给上下文）。

出处：Tal Raviv & Aman Khan (AI 产品人，Build AI Product Sense 工作坊创办者) · 02-newsletters/how-to-build-ai-product-sense.md
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast（2019–2026）。本站为个人学习用途的二次创作，与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2