上下文工程是构建 Agent 的一切

这不是我第一次在我的文章里提到上下文工程了，我相信也绝对不会是最后一次。

因为这真的很重要，尤其是对于 Agent 大行其道的今天。知道上下文工程在 Agent 中的运转和作用，绝逼比你去抄别人的 Prompt 来的有用的多。

正好刷到 Latent Space 的一期播客，谈到了上下文工程在 Agent 中的作用，邀请的对象是Lance Martin，也是Langchain 的早期成员。

我整理了这期访谈的重点内容，但是如果有条件的小伙伴，我还是推荐去反复观看这期访谈 5,6,7,8 遍。

到底什么是上下文工程

所谓的上下文工程，这个概念其实最早来自Karpathy。他指出上下文工程是：

为 LLM 提供下一步所需的恰到好处的上下文。

那上下文工程和我们日常所说的 Prompt 又有什么不同呢？

区别在于：Prompt 更多是指人类与模型聊天，ChatGPT，所输入的信息。但在 Agent 的使用场景中，Agent 往往处理的信息远不止人类输入的这么点点。

举个例子来说，如果大家用过 Claude Code，或者 Cursor，这类Coding Agent 就会发现，很多时候哪怕即使是处理你简单的一个请求，都会调用很多工具，从而产生巨大的 Token 消耗，也就给模型带来了巨大的上下文负担。

所以，现在整个 AI 圈会一直在探讨的一个问题就是，如何给模型塞入合适的上下文。

因为整个上下文实际上是动态的，它除了包括 System Prompt 和用户输入的 Prompt 之外，还需要处理超过数十次工具调用的结果。

实际生产环境中，一次任务调用工具的次数可以达到几十次，甚至上百次。

「所以不难理解为什么 Claude Code 这么贵了。。。」

Lance 指出，在 Agent 开发的早期，经常会因为粗暴的整合上下文，而导致Token 消耗巨大，比如他在构建 Open Deep Research 这个项目早期的时候，每次运行消耗 50 万 Token，成本达到 1 至 2 美元。

同时，也会导致 Agent 性能表现急剧下滑。

那如何处理这种情况呢？

上下文卸载

Lance Martin 提到了 Manus 给出了一个概念，叫上下文卸载。

其实就是将工具调用的全部原始内容存到一个外部系统，按需求检索。千万别非常粗暴的直接塞回上下文消息历史里。

上下文卸载的核心在于保留最简的摘要元数据，确保模型能够理解被卸载的内容。

Lance 拿他做的 Open Deep Research 这个项目来举例。在深度研究场景，可能会卸载完整页面，但真正的困难在于如何生成能准确反映文章内容的高效摘要或简介。

因为这些文章的摘要或者简介往往是决定模型是否需要去读取相关信息的关键因素。

Lance 在Open Deep Research 中是通过精心设计提示词来生成摘要，确保摘要具有高召回率，能够捕获文章中所有的关键点。

同样，Lance 也谈到了上下文卸载在多智能体系统中的运用。

业界比如 Cognition 其实是比较反对多 Agent 系统的。一个主要的原因就是多 Agent 的实现难度比较高，特别是如何向子智能体传递充分的上下文，还有就是在多 Agent 系统中，每个子 Agent 通常会做出互相冲突的决策，如何很好的处理这些决策也是一个问题。

Lance 认为在编码场景使用多 Agent 系统需要非常谨慎，因为每个子 Agent 在创建系统组件时，非常容易在决策上产生冲突。但是在深度研究的场景，使用多 Agent 系统反而就还好。因为在深度研究场景中，每个子 Agent 通过读取操作进行上下文收集，等所有的子智能体工作完成以后，可以基于所有共享的上下文进行整合。

他认为有关多Agent 系统和单 Agent 的争论，也可以称为 AI 工程中苦涩的教训。

检索和记忆

检索和记忆在整个 Agent 系统中，我认为是一直被忽略的模块。

Lance 谈到了现在主流的检索方式。第一种就是还是基于 RAG 的方案。

Windsurf 采用了经典的代码分块技术，通过精心设计的语义辩解划分代码块，并将这些分块进行嵌入以实现基于语义相似度的向量搜索与检索。此外，系统还整合了 grep 和知识图谱，通过重排序机制融合多种检索结果，构建出复杂多阶段的 RAG 流程。

相反，Claude Code 采取了截然不同的方案。它采取了 grep 等基础工具调用来遍历文件，完全无需建立检索体系。

Lance 自己特意做了一个实验，来比较这几种方法的效果。

发现 Claude Code 采用的方法确实非常有效。

对于记忆，Lance 认为可以分为记忆写入和记忆读取。

他还是拿 Claude Code举了个例子。在记忆读取上，它会在每次启动时，会载入claude.md 文档；在记忆写入方面，用户需明确指定保存的内容，由 Claude Code 写入 claude.md。

另一个极端是 ChatGPT。它的记忆系统在后台自主决定何时写入和调取记忆。虽然看上去非常丝滑，但是也容易出现失控。

由此可见，如何确定记忆写入的时机与方式仍然值得探讨。不过记忆读取机制与检索功能的结合已经非常成熟。

大规模的记忆检索本质上就是检索。

苦涩教训

Lance 提到了自己在做 Open Deep Research 的时候，有一个非常深刻的教训是，他一开始才用了一种高度结构化的工作流程，刻意规避工具调用功能。

这源自于它 2004 年的经验。

但是现在的 LLM 早已和当年不能比了。这种方案反而会成为瓶颈，阻碍了他对 MCP 这种新兴技术的运用，也无法充分利用工具调用功能改进。

还有一个教训出现在它让子 Agent 独立撰写报告时，出现了内容割裂。也就是之前提到过的多 Agent 之间出现了通信问题，所以它取消了子 Agent 独立写作的环节，实施单次生成报告机制。

所以，其实所谓苦涩的教训，指的就是，随着模型能力不断飞升，我们在构建 AI 产品时，也要不断去重新考量当前方案的可行性。

最后说点

这期播客的质量还是非常高的，

里面谈论了很多构建 Agent 的关键点，包括记忆、检索、上下文工程、以及一些踩过的坑。

如果你也在构建 Agent 的话，真的推荐反复观看。

目前业界的主要观点不仅仅是认可 Claude Code 的写代码能力，同时也把 Claude Code 作为一个非常优秀的 agent 架构设计来看待，非常值得学习。还有就是 RAG 作为传统的检索方式，随着模型能力的越来越强，逐渐在很多场景会被渐渐抛弃，会采用效率更高，质量更好的检索方式。

防杠声明：我一直觉得 Anthropic 这个公司，狗屎是真的狗屎，但是产品也好、模型也罢，做的东西质量是真的没话说，还有很多要学习的地方。

{{userData.name}}已认证

上下文工程是构建 Agent 的一切

NebulaGraph + LLM 处理风控知识图谱的探索和实践

Ambient Agent: 让 AI 主动工作的新范式