1个月前（2025年10月15日），LangChain的工程师Lance Martin和Manus的联合创始人Peak（季逸超）有一个关于上下文工程的网络研讨，录屏在这里；潘锦有一篇非常好的笔记，在这里。
这里将基于Youtube的视频录屏和潘锦的笔记，融合学习记录一下。
前言
当大模型厂商竞相宣扬 100万 甚至 200万 Token 的超长上下文窗口时，身处生产一线的工程师们却发现了一个残酷的现实：“能放得下”并不等于“能处理好”。
在构建复杂 AI Agent（智能体）的过程中，上下文不仅是信息的容器，更是成本、延迟与智能水平的制约瓶颈。Lance和Pete的对话揭示了当前 AI 顶层玩家的共同认知：Context Engineering（上下文工程）正取代 Prompt Engineering（提示词工程），成为决定智能体生死的关键技术。
一、 隐形的天花板：上下文腐烂（Context Rot）
在理想的宣传中，我们将所有文档、历史记录扔给模型，它就能完美工作。但在现实的 Manus 实战数据中，一个典型的 Agent 任务大约包含 50 次工具调用。如果不加干预，这些累积的中间变量、错误重试和冗长的搜索结果，会在几十轮对话内迅速填满上下文窗口。
这就引出了“上下文腐烂”的现象。
虽然模型支持 200k 甚至更长的窗口，但当 Token 数量超过一定阈值（实测往往在 128k-200k 之间），模型性能会出现非线性的断崖式下跌：
- 注意力稀释：模型开始忽略中间的关键指令（Lost in the Middle）。
- 指令遵循下降：开始产生幻觉或重复输出。
- 延迟与成本飙升：KV Cache 的未命中导致推理成本指数级增长。
因此，上下文工程不再是“锦上添花”的优化，而是“雪中送炭”的必需品。它本质上是在解决一个计算机科学的经典问题：如何在有限的带宽（Context Window）内，处理无限的信息流（World Knowledge & History）。
二、 上下文工程的五大支柱：构建 Agent 的“操作系统”
如果把大模型比作 CPU，那么上下文窗口就是 RAM（内存）。LangChain 和 Manus 的实践表明，高效的 Agent 架构需要一套类似操作系统内存管理机制的方案。这套方案由五个维度构成：
1. 上下文卸载 (Offloading)：虚拟内存机制
这是最核心的策略。不要把所有工具的输出（如 ls 的文件列表、爬虫抓取的 HTML）直接塞进对话历史。
- 做法：将重型数据写入文件系统，只在上下文中保留“文件路径”或“引用句柄”。
- 隐喻：这就像操作系统的 Swap（交换空间）。CPU（模型）不需要时刻持有所有数据，它只需要知道数据在哪，用到时再去读取。
- 案例：Manus 和 Open Deep Research 都大量使用文件系统来暂存搜索结果，避免 Token 爆炸。
2. 上下文缩减 (Reduction)：压缩与摘要的辩证
这是极易混淆的两个概念，Pete 在对话中做了精彩的区分：
- 压缩 (Compaction/Compact)：无损或近无损的可逆操作。例如，保留最近 5 次工具调用的完整参数，但将更早的调用折叠为简短的描述，或者剔除 HTML 中的 CSS/JS 标签。关键在于：原始数据仍在外部存储中，随时可恢复。
- 摘要 (Summarization)：有损的不可逆操作。将一段长对话概括为结论。这极其危险，因为你永远不知道被丢弃的细节在未来是否重要。
- 最佳实践：优先压缩，慎用摘要。Manus 的策略是“日志优先”，在摘要前必须将完整上下文 Dump 到日志文件中作为备份。
3. 上下文检索 (Retrieval)：grep 胜过向量库
在 RAG（检索增强生成）时代，大家习惯了一上来就用向量数据库做语义搜索。但在 Agent 的工作流中，Lance 和 Pete 提出了反直觉的观点：回归基础工具。
- 对于代码库、文件系统或精确数据，简单的
grep、glob甚至按行读取，往往比语义搜索更精准、更可控。 - 原因：Agent 往往需要精确操作（如“修改第 50 行代码”），模糊的向量检索容易导致定位漂移。
4. 上下文隔离 (Isolation)：进程与线程的调度
当任务复杂时，引入子智能体 (Sub-agents)。这里涉及两种架构模式，酷似并发编程模型：
- 通信模式 (Communication / Message Passing)：主智能体给子智能体一个指令，子智能体在一个全新的、空白的上下文中执行，只返回最终结果。
- 优点：上下文干净，Token 消耗少，易于调试。
- 场景：翻译、独立代码模块编写。
- 共享内存模式 (Shared Memory)：子智能体继承主智能体的全部历史上下文。
- 优点：能理解复杂背景，连贯性强。
- 缺点：成本高，同步困难（“同步即噩梦”）。
- 结论：默认使用通信模式。只有在子任务高度依赖全局历史细节时，才使用共享内存模式。
5. 上下文缓存 (Caching)：利用局部性原理
这直接关乎金钱。对于长上下文 Agent，输入 Token 的费用远高于输出。利用 Anthropic 等厂商提供的 Prompt Caching（KV Cache），可以将静态的系统提示词、庞大的背景文档缓存起来，大幅降低首字节时间（TTFT）和推理成本。
三、 深度洞察：反直觉的工程哲学
在对话中，隐藏着比具体技术更重要的“工程哲学”。这些观点往往与市面上的主流教程背道而驰，却是在血淋淋的生产环境中总结出的真理。
1. 数据库视角的降维打击
构建 Context 系统，实际上是在设计一个数据库。
- Schema 设计：Agent 之间的通信不能靠自然语言（Chat），必须靠结构化数据（Schema）。Manus 强制要求工具输出符合 Schema，这类似于数据库的表结构约束，保证了数据的一致性。
- CRUD 操作：对记忆的管理，本质上是对 Context 的增删改查。Manus 甚至引入了“用户确认”机制来更新长期记忆（Knowledge），这就像是数据库事务的 Commit 操作。
2. “做减法”的艺术：避免过度工程
Pete 提到，Manus 性能提升最大的几次迭代，都是在删代码。
- 工具数量陷阱：不要给 Agent 挂载 100 个工具。30 个是上限。超过这个数，模型的选择能力会崩塌。
- 解决方案：分层行为空间。提供 10-20 个原子工具（读写文件、搜索），剩下的通过沙盒环境（Shell/Python）去动态执行，而不是把每个 API 都封装成独立工具。
- 格式极简主义：不要迷信 Markdown 或 JSON。对于大文件处理，Line-based（基于行）的纯文本格式往往是 LLM 最容易理解、最不容易出错的格式。
3. 模型选择的经济账
在开源模型大行其道的今天，两家头部公司却给出了冷静的建议：初创公司应尽可能依赖旗舰闭源模型（如 Claude 3.5 Sonnet / GPT-4o）。
- 隐性成本：开源模型虽然没有 Token 费，但为了达到生产级效果，你需要维护复杂的分布式 KV Cache 基础设施。对于长上下文应用，这笔基建成本往往高于直接调用优化良好的商业 API。
- 未来兼容性：不要过早微调（Fine-tuning）。现在的微调往往是对当前模型缺陷的“过拟合”。一旦基础模型能力升级（例如明日发布的 GPT-5），所有的微调资产可能瞬间归零。
四、 趋势展望：从 Chat 到 Actor
结合 LangChain 和 Manus 的实践，我们可以清晰地看到 AI Agent 的演进方向：
- 界面范式的转移：从“对话框”转向“画布与伪代码”。Agent 的思考过程越来越像代码执行（Scripting），每一次工具调用都是在编写并运行一个脚本。
- 状态管理的标准化：未来会出现专门的“上下文数据库”产品，自动处理 Offloading、Reduction 和 Retrieval，开发者只需关注业务逻辑，无需手动管理 Token。
- Guardrails（护栏）的内嵌化：随着 Agent 获得联网沙盒权限，安全性变得致命。未来的上下文工程将包含强制性的输出清洗和权限隔离，防止 Agent 在沙盒中“越狱”。
结语
上下文工程（Context Engineering）不是简单的“缩短提示词”，它是一门关于信息熵管理的科学。
正如早期的程序员需要精打细算地管理 64KB 内存一样，现在的 AI 工程师需要精细地管理 200k Token 窗口。Manus 和 LangChain 的经验告诉我们：成功的 Agent 不是靠堆砌最先进的模型，而是靠构建最健壮的上下文流水线。
在这个领域，克制（做减法）、结构化（Schema）与分层设计（操作系统和数据库思维），才是通往 AGI 的真实路径。