我要投稿

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

发布日期：2025-09-19 18:59:24 浏览次数： 1999

作者：BubbleBrain

微信搜一搜，关注“BubbleBrain”

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

因为这真的很重要，尤其是对于 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 工程中苦涩的教训。