题记与说明
- 精读日期：2026-10-29
- 精读方式：主题研究。先用网络检索筛选互补来源，再逐一精读（学术论文读摘要+HTML 正文提取，工程博客读全文）
- 主题判断：确认是"研究主题"——"上下文工程"是 2025 年中兴起、横跨学术综述与工程实践的新领域，无单篇原文，按主题研究流程处理
- 选题动机：主题要求覆盖三条主线——压缩策略、记忆分层、检索时机，并产出个人 agent 项目的落地清单
- 与既有笔记的关系：2026-10-27-agent-memory-memgpt-letta-zep-langmem-对比精读.md已覆盖记忆系统产品的横向对比，2026-10-28-Anthropic-Building-Effective-Agents-工作流vsAgent取舍精读.md已覆盖工作流/agent 取舍——本笔记不重复这两块，聚焦上下文本身的管理（这恰好是那两篇的上游：记忆系统是上下文工程的子问题）
0. 精读来源清单（检索筛选结果）
| # | 来源 | 类型 | 精读深度 | 价值定位 |
|---|---|---|---|---|
| 1 | A Survey of Context Engineering for Large Language Models（arXiv:2507.13334）（Mei et al., 2025-07，覆盖 1400+ 篇论文） | 学术综述 | 精读（摘要页 + HTML v2 正文提取） | 学术主干：领域正式定义、三段式分类法、核心科学问题（理解-生成不对称性） |
| 2 | Anthropic《Effective context engineering for AI agents》（2025-09 末，Engineering 栏目） | 工程博客 | 全文精读 | 实践主干：context rot、注意力预算、正确高度、just-in-time 检索、压缩/笔记/子代理三件套 |
| 3 | LangChain《Context Engineering》（Lance Martin，2025-07-02） | 工程博客 | 全文精读 | 操作框架：write / select / compress / isolate 四策略 + 各家 agent 的实例对照 |
| 4 | Context Engineering 2.0: The Context of Context Engineering（arXiv:2510.26493）（Hua et al., 2025-10-30） | 学术论文 | 精读摘要页（正文细节未能从摘要页获得，见 §6 局限） | 历史纵深：把上下文工程追溯到 1990 年代初，给出人机→人-智能体交互的历史分期 |
| 5 | Karpathy / Tobi Lütke 术语源头推文（2025-06，原文推文汇辑 Gist；经搜索验证，未直接打开 X 原帖） | 术语定义 | 引述级（转引自 LangChain 博客及搜索结果） | 术语的标准定义和出处，所有来源都引用它 |
检索中还见过但未精读（仅出现在搜索摘要，本笔记不引用其细节）：Claude 平台 cookbook（compaction/memory 工具页）、OpenReview 上的 ACON（长任务上下文压缩，168 引用）、FeishuLuo《Evolving LLM Agent Memory Survey》、多篇 Medium/VentureBeat 转述。另：综述 HTML 正文在 §4.3.4 后被截断，其支撑"不对称性"论断的实验章节未能读到（见 §6）。
1. 核心问题
整个领域要回答一个单一问题，Karpathy 的定义说得最清楚（逐字）：
"In every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window with just the right information for the next step."
（在每个工业级 LLM 应用里，上下文工程是一门精妙的艺术与科学：在下一步之前，往上下文窗口里填入恰好合适的信息。）
为什么"填什么进窗口"会成为一门独立学科？三个来源给出了递进的理由：
- 模型权重不再是主要瓶颈，上下文才是。 综述摘要开宗明义：上下文工程是"the art of generating, acquiring, processing, and managing context"，它涵盖"对推理时喂给 LLM 的信息载荷做系统化优化"——因为决定 LLM 表现的常常不是模型权重而是这个载荷。
- 更多上下文 ≠ 更好表现。 Anthropic 提出了关键反直觉现象——context rot（上下文腐烂）：随着窗口内 token 数量增加，模型准确回忆信息的能力反而下降。原因在注意力机制的结构：所有 token 两两配对争夺注意力，窗口越大、注意力被摊得越薄。Anthropic 的结论是：上下文工程的核心目标变成——"找到适配手头任务的最小高信号 token 集合"（"finding the smallest set of high-signal tokens that lead to the desired outcome"）。
- LLM 天生无状态，长任务会累积垃圾。 综述把 LLM 无状态性上升到理论位置（作者甚至关联到 Gödel 不完备性定理的类比）；LangChain 则引用 Drew Breunig 总结的四种长任务上下文失败模式：Context Poisoning（幻觉进入上下文后自我强化）、Context Distraction（上下文淹没训练分布，模型开始复读）、Context Confusion（冗余上下文干扰输出）、Context Clash（上下文内部自相矛盾）。Cognition 的说法被 LangChain 引用："context engineering is effectively the #1 job of engineers building AI agents"（上下文工程实际上就是构建 AI agent 的工程师的头号工作）。
三条主线（压缩策略 / 记忆分层 / 检索时机）都是这个核心问题的子问题：窗口装不下 → 要压缩；窗口外信息要跨回合存活 → 要分层记忆；窗口内信息要"在正确的下一步"出现 → 要设计检索时机。
2. 主要主张
2.1 术语主张：prompt engineering 是上下文工程的子集
- 源头（2025-06）：Tobi Lütke 先发推提出"context engineering"优于"prompt engineering"，Karpathy 回复 "+1" 使其流行。Karpathy 补充说在一问一答式聊天里两者看起来一样，但在真实 agent 应用里差别巨大；且"this, alone, is a full job"——这本身就是一项完整的工作。
- Port.io 的隐喻：prompt engineering 像立方体的一个面（2D），context engineering 展现立方体的深度（3D）。其定义（逐字）："Prompt engineering is how you instruct an AI agent what to do, where context engineering is how you provide the data an agent needs to do what you tell it to do."（prompt engineering 告诉 agent 做什么；context engineering 提供它做事所需的数据。）
- LangChain 的 OS 类比（转引 Karpathy）：LLM 是 CPU，上下文窗口是 RAM——上下文工程就是这门新型操作系统的内存管理。
- 综述的历史观（来源 4）：这不是新发明，而是二十年以上实践的正式化——从 1990 年代初围绕早期计算机的人机交互框架，到今天智能体驱动的人-智能体交互范式，未来面向人类级/超人类智能。摘要以马克思开篇："the human essence is the ensemble of social relations"——机器理解人类情境的问题由来已久。
2.2 学术主张：综述的三段式分类法 + 理解-生成不对称性
综述（1400+ 篇论文）把上下文工程拆成三大基础组件：
A. 上下文检索与生成（Context Retrieval & Generation）——决定"往窗口里放什么"：
- 提示工程（CLEAR 框架：conciseness, logic, explicitness, adaptability, reflectiveness）、few-shot、CoT 及其推理结构变体；
- 外部知识检索：RAG 基础（Self-RAG、RAPTOR、HippoRAG）、知识图谱集成（KAPING、Think-on-Graph）、agentic/模块化检索；
- 动态上下文组装：组装函数 𝒜（模板化、优先级选择）、自动提示优化（APE、LM-BFF "up to 30% absolute improvement"、Promptbreeder）。
B. 上下文处理（Context Processing）——决定"放进来的信息怎么被高效消化"：
- 长上下文架构：线性注意力（最高 4000× 加速）、LongNet、位置外推（YaRN、LongRoPE 达 2048K token）、KV cache 优化（GQA、FlashAttention-2、Ring Attention）；
- 自精炼：Self-Refine（GPT-4 约 20% 绝对提升）、Reflexion、Agent-R（MCTS 回溯）、长 CoT 推理模型（o1、DeepSeek-R1）；
- 多模态（核心挑战是 modality bias：模型偏向文本，产生看似合理但无多模态依据的回答）；
- 结构化上下文：GraphToken（图推理任务最多 +73 个百分点）、StructLM。
C. 上下文管理（Context Management）——决定"窗口的物理与逻辑约束"：
- 基本约束：O(n²) 注意力复杂度、lost-in-the-middle（中间位置信息检索差，长 CoT 中性能退化最多达 73%）、无状态性、context overflow 与 collapse；
- 记忆分层（本次主题主线之一）：MemGPT（OS 式分页内存）、MemoryBank（艾宾浩斯遗忘曲线）、ReadAgent；
- 上下文压缩（主线之二）：ICAE（4× 压缩）、ACRE 双层 KV cache、Infinite-LLM、PREMISE（87.5% token 减少）。
核心科学问题（摘要明确立论）："a fundamental asymmetry exists between model capabilities"——当前经上下文工程增强的模型在理解复杂上下文方面表现卓越，但在生成同等复杂的长篇输出方面 "exhibit pronounced limitations"（表现出明显局限）；作者称 "Addressing this gap is a defining priority for future research"（弥合这一差距是未来研究的决定性优先事项）。
系统实现层四支柱：RAG（已演化为模块化、agentic——检索代理是"智能调查员"、graph-enhanced 三种架构）、Memory Systems（短期/长期记忆架构，挑战是"记忆饱和导致检索低效"）、Tool-Integrated Reasoning（从单工具到 LangChain/AutoGen 式编排）、Multi-Agent Systems（集中式协调高效但扩展性差；分散式减少溢出但增加响应时间）。
2.3 工程主张：LangChain 四策略（write / select / compress / isolate）
这是最便于个人项目套用的操作框架：
| 策略 | 定义（原文缩略） | 具体手段 | 代表实践 |
|---|---|---|---|
| Write（把信息存到窗口之外） | "saving outside the window" | Scratchpad（任务内笔记：写文件的工具调用或 runtime state 字段）；Memories（跨会话记忆，源自 Reflexion 的反思式记忆与 Generative Agents 的定期综合） | Anthropic 多 agent 研究系统的 LeadResearcher 在开工前先把计划写入 memory——"since if the context window exceeds 200,000 tokens it will be truncated"（因为窗口超过 200K token 就会被截断） |
| Select（把相关信息拉进窗口） | "pulling into the window" | Scratchpad 选择（state 实现让开发者精细控制每步暴露什么）；Memories 三分法：episodic（few-shot 示例）/ procedural（指令）/ semantic（事实），索引用 embeddings 或知识图谱（Zep）；Tools 选择：工具太多会混淆，对工具描述做 RAG——有论文显示工具选择准确率提升 3 倍；Knowledge 选择：RAG | Windsurf 的 Varun 有一句关键提醒（逐字）："Indexing code ≠ context retrieval"（索引代码不等于上下文检索），需要结合 grep/文件搜索与重排序 |
| Compress（只保留完成任务所需 token） | "retaining only required tokens" | Summarization（Claude Code 超 95% 窗口触发 auto-compact 总结全程轨迹；可在 token 密集工具调用后即时处理，或在 agent-agent 边界做知识交接总结——Cognition 用微调模型干这事）；Trimming（硬编码启发式删旧消息，或训练式剪枝如 Provence） | Claude Code auto-compact；Cognition 反对多 agent、押注高质量单 agent + 压缩 |
| Isolate（拆分上下文） | "splitting it up" | Multi-agent（每个 sub-agent 有自己的工具、指令和窗口，OpenAI Swarm 的动机是关注点分离）；Environments/Sandbox（HuggingFace CodeAgent 在 E2B 沙箱执行代码只回传返回值，token 密集对象作变量存在环境里）；State（带 schema 的 state object，只暴露 messages 字段给 LLM） | HF 深度研究员的沙箱隔离；Anthropic 多 agent 研究员并行跑自己的窗口 |
LangChain 还给了一个重要的反例警示：Simon Willison 举过 ChatGPT 记忆误选的案例——位置记忆被意外注入图片请求，让用户感觉窗口 "no longer belongs to them"（不再属于自己）。Select 策略做不好比不做更糟。
2.4 工程主张：Anthropic 三件套 + 检索时机判断
Anthropic 全文的骨架：context rot → 注意力预算 → 因此每个环节都要省着花预算：
- 系统提示要写到"正确高度"（right altitude）：太硬编码（精确步骤、print 语句）→ 脆弱、僵化；太抽象 → 建议无用。存在一个 Goldilocks zone——"At the right altitude, you have provided the model with the exact information it needs to succeed"（在正确高度上，你提供的恰好是模型成功所需的信息）。这是给"记忆分层"的procedural 层的写作原则。
- 工具按 token 效率设计："minimal viable set of tools"（最小可用工具集）；Anthropic 举过 GitHub 工具瘦身案例：把同时接受 PR 号和 diff URL 的三工具合并成一个代理式工具，全量工具测试下token 用量减少 98%。
- 检索时机：just-in-time 优先于预检索（主线之三，Anthropic 的核心立场）：
- 先天假设是"像给人类文档一样预检索"（embedding 索引 + 相似度），但对 agent 来说 Naive RAG 在文档超过 20 份左右就会因相似度噪音失败；
- 更好的做法是 agentic search：给模型 glob/grep 等原始工具，让它按需检索——模型可以用 grep 精确定位、读文件树导航，查询质量随任务上下文更新而提高；
- Claude Code 的混合方案：CLAUDE.md（身份/事实/工作流）开局即入窗口（always-on），其余代码细节 just-in-time 检索（on-demand）。Anthropic 提醒要按用例校准：小且稳定的语料预索引合理；大量异构内容用 agentic search。
- 长任务三件套（主线一、二的交汇处）：
- Compaction（压缩）：接近窗口上限时把对话总结后重新开窗。关键取舍在保什么删什么：保留架构决策、未解决的 bug、任务细节；丢弃冗余工具调用与结果。"tool result clearing"（工具结果清理）是其轻量变体——最近的工具调用之后清掉过期的工具输出。
- Structured note-taking（结构化笔记 / agentic memory）：让模型把信息持久化到窗口外的 NOTES.md / memory tool 中，需要时读回。Anthropic 的量化案例：在 40 轮以上的 Pokémon 游戏挑战中，不加笔记成绩 42%，加笔记后 92.5%。
- Sub-agent architectures（子代理隔离）：独立的编码 agent 清出主上下文、研究 agent 并行探索后只回传 1000-2000 token 的精简摘要；副产品是跨窗口并行检索。代价：丢失主上下文细节（sub-agent 拿不到父任务的完整上下文，包括用户改过的需求）、token 成本高（多 agent 研究系统比聊天多至 15×）。
- 方法论主张："context engineering is highly empirical"（上下文工程高度依赖实证）——必须拿真实任务反复迭代，而不是套模板。LangChain 给出配套工程闭环：可观测性先行（trace + token 用量）→ 评估（每次上下文改动跑 eval）→ "识别机会 → 实现 → 测试 → 重复"。
2.5 各家立场的真实分歧（综述性阅读才能看到的）
- 多 agent vs 单 agent + 压缩：Anthropic/LangChain 展示 sub-agent 隔离收益（研究系统 90.2% 超单 agent）；Cognition 则公开反对，认为上下文共享断裂会引入冲突，押注微调压缩模型 + 单 agent。两家的选择都成立，取决于任务是否可并行。
- 预检索 vs just-in-time：传统 RAG 供应商押注 embedding 索引；Anthropic 用 Claude Code 实证 agentic search 在编码场景更优；LangChain 居中——RAG 仍是 Knowledge 选择的主力，但要加重排序，且"索引 ≠ 检索"。
- 记忆写入的主动性：Generative Agents 式的自动综合（ChatGPT 全自动记忆）有 Willison 式误选风险；Anthropic 主张显式、结构化的笔记工具（模型自己决定何时写）。个人项目建议选后者：可审计、可编辑。
3. 方法
- 主题研究方法：先广度检索（5 组关键词：综述/Anthropic 工程文/Karpathy 定义/记忆综述/压缩综述），按"学术主干 + 实践主干 + 术语源头 + 历史纵深"四象限筛选出 5 个互补来源，逐一精读后交叉验证。
- 各来源自身的方法：
- 综述（2507.13334）：系统性文献综述法，覆盖 1400+ 篇论文，按"基础组件（检索生成/处理/管理）× 系统实现（RAG/记忆/工具/多 agent）"双维组织，配统一数学记号（上下文定义为 token 子序列、上下文工程为映射的有序组合）；
- Anthropic：一线产品经验归纳（Claude Code、多 agent 研究系统、内部 agent 团队访谈），配内部挑战赛数据（Pokémon 笔记实验、GitHub 工具瘦身）；
- LangChain：框架归纳法（四策略）+ 横向案例对照（Claude Code / ChatGPT / Cursor / Windsurf / Cognition / HF / OpenAI Swarm），落点在其自家产品闭环（LangSmith/LangGraph）；
- CE 2.0（2510.26493）：概念史与分期法，从 HCI 文献史论证上下文工程的连续性。
4. 数据与证据
综述（1400+ 篇）的关键数字（来源 1）：
| 项 | 数字 | 含义 |
|---|---|---|
| 综述覆盖论文 | 1400+ | 领域规模的量度 |
| Zero-shot CoT（MultiArith） | 17.7% → 78.7% | 检索与生成层：推理结构的收益 |
| Tree-of-Thoughts（Game of 24） | 4% → 74% | 同上 |
| Graph-of-Thoughts vs ToT | 质量 +62%、成本 −31% | 结构化推理优于树状 |
| lost-in-the-middle | 性能退化最多 73% | 上下文管理的物理约束证据 |
| Mistral-7B 窗口 4K→128K | 计算量 +122× | 窗口扩张的真实代价 |
| Llama 3.1 8B @128K | 每请求最高 16GB | 同上，落到显存 |
| StreamingLLM | 22.2× 加速、400 万 token | 处理层压缩方案 |
| H2O | 吞吐至 29× | KV cache 逐出策略 |
| ICAE | 4× 压缩 | 表示级压缩 |
| PREMISE | token 减少 87.5% | 压缩上限的参考 |
| GraphToken | 图推理最多 +73 个百分点 | 结构化上下文收益 |
| 多 agent vs 单 agent（Pass@1） | 相对提升 29.9–47.1% | 隔离策略收益 |
工程侧量化证据（来源 2、3）：
- Pokémon 长任务笔记实验：无笔记 42% → 有 NOTES.md 92.5%（Anthropic，40+ 轮挑战）；
- GitHub 工具合并瘦身：token 用量 −98%（全量工具测试下）；
- 多 agent 研究系统：90.2% 优于单 agent（Anthropic 2025-06 报告，被 LangChain 转引），代价 15× token；
- Claude Code auto-compact 触发线：窗口用量超 95%；
- Naive RAG 失效点：文档规模 20 份左右（Anthropic 的经验值，非系统实测）；
- 工具描述 RAG：工具选择准确率 3×（LangChain 引论文）。
证据充分性评估：综述数字多为转引各原始论文，且大多来自 QA/推理/代码基准，没有针对"压缩/记忆/检索策略选型"的统一基准——它告诉你每类技术单独能到多少，不告诉你组合起来的最优解。工程侧数字（42%→92.5%、15×）来自产品内部任务，外部效度有限，但两类证据相互独立、方向一致（"窗口信息质量比数量重要"），可信度较高。
5. 结论
- 领域定位成立：上下文工程已从推文热词正式化为学科——有正式定义（Karpathy）、有 1400 篇论文的学术综述（2507.13334）、有可操作框架（四策略）、有历史分期（CE 2.0）。
- 第一性原理是注意力预算：context rot + lost-in-the-middle + O(n²) 的物理约束意味着——目标不是"塞更多上下文"，而是"每一步让最小的高信号 token 集合出现在窗口里"。
- 三条主线有收敛的工程答案：
- 压缩策略：分级响应——先用轻量的工具结果清理；到阈值（如 95%）再 compaction 总结，保决策/未决问题、弃冗余工具输出；表示级压缩（ICAE/KV cache 层）属基础设施层，个人项目暂不必碰；
- 记忆分层：三层结构——窗口内（工作记忆）→ scratchpad（任务内笔记）→ 跨会话记忆（episodic/procedural/semantic 三分，embedding 或 KG 索引）；写作上遵守"正确高度"原则；
- 检索时机：默认 just-in-time（agentic search），小且稳定的语料才预索引；"always-on 身份与记忆 + on-demand 细节"的混合模式是当前最佳实践；索引 ≠ 检索，要有重排序。
- 没有银弹，只有实证闭环：Anthropic 与 LangChain 罕见地在这一条上完全一致——上下文策略必须由可观测性 + 评估驱动，按自己的任务迭代。
- 悬而未决的学术前沿：理解-生成不对称性——模型能"读懂"复杂上下文，但"写出"同等复杂的长输出能力受限；这是未来研究的决定性优先事项（综述原话）。
6. 局限
- 综述正文抓取不完整：HTML 版在 §4.3.4 后截断，支撑"不对称性"论断的实验章节未能读到，该论断只引到摘要级证据；"Context Engineering 2.0"只精读到摘要页，搜索结果提到的"六个组件框架"未能在摘要页获得验证，本笔记不作转述。
- 综述的方法学局限：1400 篇的分类是"并存罗列"而非"比较评估"——没有统一基准，无法回答"我该选哪个"；其转引数字来自各论文自己的基准设定，横向可比性弱。
- 工程证据的外部效度：42%→92.5%、90.2%、15× 等数字全部出自 Anthropic 自家任务与报告，无第三方复现；Naive RAG "20 份文档失效"是经验值。
- 时效风险：领域以月为单位演化（LangChain 2026-01 已有《Context Management for Deep Agents》续篇讨论可插拔压缩策略），本笔记数字与工具名可能在数月内过时；Karpathy 推文未直接打开 X 验证原文，引述经两个独立二手来源交叉确认。
- 立场偏差：LangChain 的"落地建议"一节自然导向其自家产品（LangSmith/LangGraph/LangMem），是内容营销与技术的混合体，工具选型部分需打折。
7. 对我的启发（个人 agent 项目落地清单）
结合既有笔记（记忆产品对比、工作流/agent 取舍），给个人 agent 项目的可执行清单，按"压缩 / 记忆 / 检索 / 隔离 + 底座"组织。每条标注来源依据：
7.0 底座（先做，其他都靠它）
- [ ] 可观测性先行：记录每步的 token 用量与完整 trace——不知道钱花在哪，就不知道哪里值得做上下文工程（LangChain："先建立可观测性，据此判断在哪里投入最有价值"）。
- [ ] 先有评估再改上下文：准备 10-20 个真实任务作为 eval 集；每次调整上下文策略前后各跑一遍对比。Anthropic："context engineering is highly empirical"。
- [ ] 系统提示写到"正确高度"：写行为准则与目标，不写逐步操作；把"何时用某工具"写成条件判断而非流程图。（Anthropic Goldilocks zone）
7.1 压缩策略（compaction）
- [ ] 设阈值触发：窗口用量 ~90-95% 时触发总结压缩（对标 Claude Code 的 95% 线），而不是塞满了再被动截断。
- [ ] 压缩时保三类信息：架构/关键决策、未解决的问题、任务约束与用户偏好；弃冗余工具输出。（Anthropic compaction 一节）
- [ ] 轻量手段优先：先把旧工具结果清理掉（tool result clearing），再考虑整段总结——破坏性小一级。
- [ ] 在 agent- agent / 阶段边界做交接总结：把上游结论压缩成结构化交接文档传给下游（Cognition 的做法，即使用单 agent 也适用）。
- [ ] 暂不碰 KV-cache 级压缩：ICAE/H2O/StreamingLLM 属推理基础设施，个人项目收益远小于复杂度（综述数字仅供参考）。
7.2 记忆分层（memory layering）
- [ ] 三层最小结构：① 窗口内工作记忆（本轮对话）② 任务内 scratchpad（一个 NOTES.md 或 state 字段，任务结束即弃）③ 跨会话长期记忆（文件或向量库）。①②用文件实现即可，不必引入记忆中间件（既有笔记 2026-10-27 的结论：Letta/Zep/LangMem 适合规模化场景，个人项目文件起步）。
- [ ] 长期记忆按三分法组织：procedural（规则/工作流，如 CLAUDE.md）、episodic（过往任务案例，可作 few-shot）、semantic（事实）。分开存、分开选——避免 Willison 式误选。
- [ ] 写入显式化：给模型一个结构化的记忆写入工具（带 schema），模型自己决定何时写；不选全自动后台综合（不可审计）。
- [ ] 记忆写入遵守"正确高度"：存"该做什么"，不存"怎么做的每一步"。
- [ ] 定期审计记忆库：过期/错误记忆是 context poisoning 的长期形态。
7.3 检索时机（retrieval timing）
- [ ] 默认 just-in-time：给模型 grep/文件树/读取工具让它自己找，优于预先把语料 embedding 后整块注入（Anthropic：agentic search 在异构内容上更优；Naive RAG 约 20 份文档即退化）。
- [ ] 混合模式：身份、硬约束、常用工作流 always-on 进系统提示；细节知识 on-demand。（Claude Code：CLAUDE.md 开局 + glob/grep 随时检索）
- [ ] 小而稳的语料才预索引：文档 <20 且内容稳定时，embedding 检索合理；否则投资 agentic search。
- [ ] 索引 ≠ 检索：有索引也要配重排序和 grep 兜底（Windsurf："Indexing code ≠ context retrieval"）。
- [ ] 工具集本身也要被检索：工具超过 ~20 个时对工具描述做语义检索，而非全部注入（LangChain 引 3× 准确率数据）。
7.4 隔离（isolate）
- [ ] 子代理只用于可并行的探索型任务（研究/大范围搜索），不用于编码等强上下文依赖任务（既有笔记 2026-10-28 的取舍原则与此一致）；预期 token 成本 ~15×。
- [ ] sub-agent 回传控制在 1000-2000 token 的结构化摘要，并在开工前把计划写入 memory 防截断（Anthropic 研究系统的做法）。
- [ ] token 密集对象放沙箱：代码执行、图片/音频处理在 sandbox 里跑，只回传文本结果（HF CodeAgent 模式）。
- [ ] state 只暴露 messages：带 schema 的 state object，把不必要字段隔离在 LLM 视野外（LangGraph 模式；纯代码实现同理）。
7.5 一句话总纲
"找到适配任务的最小高信号 token 集合"是唯一目标；压缩、记忆分层、检索时机、隔离都是它的手段；可观测性 + 评估是判断手段是否有效的唯一裁判。
附：本次学到的可复用原则
- "上下文是注意力预算"是比"上下文是内存"更准确的模型——OS 类比（RAM/分页）适合讲机制，预算类比适合做决策（每个 token 都在花别人的注意力）。
- 压缩是分级手术：清理（无害）→ 总结（有损）→ 隔离（转移）→ 表示压缩（基础设施），破坏性递增，从轻到重使用。
- 检索时机比检索技术更重要：同一个 RAG 组件，"什么时候让信息进窗口"的决定（always-on vs on-demand）对结果的影响大于"用什么索引"。
- 记忆系统选型先于记忆产品选型：先定三分法（procedural/episodic/semantic）与三层结构（窗口/scratchpad/长期），再决定用文件还是中间件——产品对比笔记的价值只有在框架清晰后才兑现。