从 Manus 和 Cursor 的分享中，我最大的领悟：关键在于防止 Context 过度工程化

从 Manus 和 Cursor 分享中获得的启示：别让 Context 过度复杂化！Founder Park已认证机构号

说到底，优化上下文工程，依然是许多创业公司在新的一年里拼搏的关键所在。这可不是个小事，大家都在努力追赶，确保自己的产品在市场上能脱颖而出。

如何优化上下文工程，提升Agent表现

在实际开发过程中，上下文信息的质量对 Agent 的表现影响相当大。

其实，Manus 的首席科学家季逸超在之前的访谈里提到过一个非常重要的观点：

初创公司应该尽可能长时间依赖通用模型和上下文工程，而不是急于构建专用模型或进行微调。上下文工程实际上是应用层和模型层之间最直观、最实用的界限。

如果能做好上下文工程，开发者就可以在不改动模型底层权重的情况下灵活运用模型，还能快速适应产品变化的需求。

最近，Cursor 也分享了一篇关于《动态上下文发现》的文章，讲述了他们如何进行上下文管理。

结合 Manus 和 Cursor 这两家在 Agent 领域的领先团队的思路，我们整理了一些关键要点，帮助大家更好地掌握上下文工程。

想要了解更多，Cursor 的原文可以在这里找到：动态上下文发现

此外，之前 Founder Park 也分享过一篇关于如何构建 AI Agent 的上下文工程的文章，大家可以去看看。

⬆️如果你关注 Founder Park，就能获得最新、最实用的创业分享哦！

---

在「AI 产品市集」社群里，已经有超过 19000 人加入，大家不会错过每一款有价值的 AI 应用。

欢迎各位从业者、开发人员和创业者通过飞书扫码加群！

加入后，你将有机会获得：

• 最新、最值得关注的 AI 新品资讯；
• 不定期赠送热门新品的邀请码和会员码；
• 精准的 AI 产品曝光渠道。

---

01

上下文缩减，简单有效的策略

在构建 Agent 的过程中，会发现一个有趣的现象：上下文信息总是不断增长，并且这种增长方式相当特殊。

每次 Agent 调用工具时，都会返回一个观测结果，而这些结果就会被添加到聊天记录中。随着时间的推移，消息列表越来越长，导致 Agent 在运行时信息量暴增。

根据 Manus 的说法，通常一个任务大约需要调用 50 次工具，而 Anthropic 也提到过，生产环境中的 Agent 可能会进行数百轮的对话。

上下文长度的不断增加，会导致推理性能大幅下降，这种现象被称为“上下文腐烂”。表现出来的就是推理变慢、质量下降，甚至开始重复无意义的内容。

那么，如何解决这个问题呢？业内普遍认可的一个方法是“上下文卸载”，简单来说就是不要把所有的信息都强行塞进 Agent 的短期记忆里，而是将其卸载出去。这些信息放在上下文窗口之外，但在需要时能够精准地检索回来。

目前，将信息转移到文件系统中，已经成为生产级 Agent 中一种主流且有效的做法。

Cursor 的理念：万物皆可文件化

Cursor 将“卸载”这个思路发挥到了极致，利用文件作为基础单元，把冗长的工具结果、终端会话和聊天记录全部转化为文件。

Cursor 表示：

我们不确定未来 LLM 工具的最佳接口是什么，但文件是一个简单而强大的基础单元，比发明全新抽象要安全得多。

基于这个思路，Cursor 提出了“动态上下文发现”的模式，核心是让模型在需要时自己去寻找信息，而不是急于塞给它。

Cursor 还将这种模式应用到多个实际场景中：

• 将冗长的工具结果转化为文件

在调用工具时，特别是 Shell 命令或第三方模型上下文协议，常常返回庞大的 JSON 响应，这很容易撑爆上下文。传统的编程 Agent 通常采取的做法是直接截断过长的命令结果，但这可能会丢失关键信息。

Cursor 的做法是直接将这些输出写入一个文件，然后在上下文中告诉 Agent：“结果在 output.log 里，你自己去查看。”这样，Agent 可以先用 tail 命令查看文件末尾，如果需要更多细节，再读取整个文件。

• 在总结阶段引用聊天记录

当模型的上下文窗口被填满时，Cursor 会触发一个总结步骤，给 Agent 腾出新的上下文窗口，里面包含之前工作的摘要。

不过，在这个过程中，Agent 的知识可能会“退化”，因为总结本质上是对上下文的一种有损压缩。Cursor 将完整的聊天历史记录视为一个文件，在触发总结时，Agent 会得到一份摘要，以及一个指向“历史记录文件”的引用。如果 Agent 发现摘要中缺少某些必要的细节，它可以通过搜索这份历史记录文件来找回这些信息。

• 将所有集成终端的会话视为文件

在 Cursor 中，不再需要手动复制粘贴冗长的终端报错信息，系统会自动将集成终端的所有会话输出同步到本地文件系统。当问到“为什么我的命令失败了？”时，Agent 能直接定位问题，甚至可以使用 grep 命令在长篇的服务器日志中搜索相关的错误行。这种方式模仿了 CLI Agent 的体验，拥有先前 Shell 输出作为上下文，但不同的是，这是一种动态发现，而不是静态注入。

Manus ：一套结构化的可逆、缩减系统

理解上下文缩减的妙招

相较于 Cursor 那种直接粗暴的方式，Manus 则是把上下文缩减设计成了一套有序的流程，分阶段来执行，听起来是不是挺聪明的？

首先，Manus 的系统会时刻监控上下文的长度，设定一个比模型硬件极限低得多的「腐烂前阈值」。

季逸超提到，你的模型有个上下文限制，比如说 100 万个 Token，这个在现在可算是很常见了。但实际上，大多数模型在远低于这个值时就开始出现性能下滑，通常在 20 万个 Token 左右，你就会察觉到「上下文腐烂」的现象，比如重复内容、推理变慢、质量下降等等。

因此，通过大量评估，找到「腐烂前」的阈值是至关重要的，通常是在 12.8 万到 20 万个 Token 之间，作为触发上下文缩减的标准。

一旦信号被触发，系统就会进入第一阶段的操作：

第一步：紧凑化

这是一种不损失信息且可逆的缩减方式。关键是将任何能从外部状态（比如文件系统）重建的信息剥离掉。

比如，Agent 调用了一个写入文件的工具，这个操作的历史记录可能包含路径和内容两个字段。一旦执行成功，那些冗长的内容字段就可以安全地从上下文中去掉，只留下路径。

信息并没有消失，它只是被「外部化」了。如果 Agent 在接下来的步骤中需要再次读取该文件，凭借保留的路径就能轻松找回。

Manus 认为，这种可逆性非常重要，因为你根本不知道哪些过去的操作会在未来变得关键。

通常紧凑化只会针对最早的 50% 历史记录，保留最新的、完整的工具调用作为模型学习的例子。

但紧凑化的效果有限。当经过多轮操作后，上下文削减的效果微乎其微时，系统会进入第二阶段：

第二步：摘要化

这是一种有损但有保障的压缩方式，可以理解为最后的手段，执行时得格外小心。

它的「保障」在于：在生成摘要之前，系统会主动将完整上下文转储到一个文本或日志文件中，等于给历史创建了一个完整的快照存档。如果模型足够聪明，它甚至能用 grep 或 glob 自己去日志里找数据。

季逸超指出，紧凑化是可逆的，而摘要化则不是。虽然它们都减少了上下文长度，但方式却大相径庭。

在进行摘要化时，总是使用完整版本的数据，而不是紧凑版。

摘要化依旧会保留最近几次完整的工具调用记录，这样模型能清楚地知道自己在哪停下，能够顺利继续工作，保持风格和语气的一致性。

经过这两个步骤，通过「紧凑化」剥离可重建的信息，以及在「摘要化」前将完整上下文转储到日志，实现上下文的缩减。

02

为工具构建灵活的操作空间

随着 Agent 能力的提升，配备的工具也越来越多。

如果把所有工具的详细描述都放进上下文，会出现两个问题：

• 一是上下文混淆，工具太多了，模型可能会搞不清楚，甚至调用错误的工具，或者根本想象出不存在的工具。

• 二是 Token 浪费，很多工具大部分时候根本不会用到。如果还用了多个 MCP 服务器，那情况就更糟了。

那么如何解决工具过载的问题呢？一个核心思路就是：动态发现，让 Agent 自己去找需要调用的工具。

Cursor：把工具说明书全部归档

Cursor 的策略相对简单粗暴。它把所有 MCP 工具和 Agent 技能的详细定义都放到文件夹里，Agent 需要时可以自己查阅。

在 Cursor 的框架中，分成了索引层和发现层。

索引层，Agent 的系统提示词里只包含一小部分静态信息，比如 MCP 工具或 Agent 技能的名称列表。

这些工具和技能的详细描述、参数定义、使用方法都被存放在一个本地文件夹中。当模型需要时，Agent 就像个聪明的程序员一样，进入发现层，用 grep 或语义搜索，主动去文件夹里查找需要的工具详细信息，然后拉取到上下文中来处理。

Cursor 进行了一次 A/B 测试，结果发现，调用 MCP 工具的任务中，这种策略让Token 的总消耗降低了 46.9%。

另外，Cursor 还表示，这种全文件化的方式，意外解锁了一个新能力：向 Agent 传达工具的状态。

比如，以前如果某个 MCP 服务器需要重新认证，Agent 可能会「忘记」这些工具的存在。但现在，Agent 可以主动提醒用户去重新认证。

Manus：创建了一套分层的操作空间

Manus 认为，传统的方法对工具描述进行动态的 RAG，并不可行。因为动态加载工具定义会导致 KV 缓存失效，历史的旧调用记录可能会成为障碍。

季逸超提到，目前一个普遍的方法是对工具描述进行动态的 RAG，比如根据当前任务或状态按需加载工具。

但这样会引发两个问题：首先，由于工具定义在上下文的开头，每次变动都会重置 KV 缓存；其次，模型过去对那些被移除的工具的调用记录仍然保留在上下文中，这可能误导模型调用无效的工具或参数。

为了应对这个问题，Manus 设计了一种分层的操作空间。将 Agent 的能力分成三个层次：函数调用、沙盒工具、软件包和 API。

• 第一层：原子函数调用

核心层只包含极其少量固定的原子函数，比如：读写文件、执行 shell 命令、在文件和互联网中搜索。由于这一层是固定的，所以对 KV 缓存友好，功能边界清晰，不会产生混淆。

• 第二层：沙盒工具

优雅的多层结构与智能协作

在卸载层方面，Manus 将大多数工具，比如格式转换器、语音识别工具，还有 MCP 调用本身，都放进了一个定制的 Linux 虚拟机沙箱里，像是预装的软件包。这样，Agent 似乎并没有直接接触到这些工具的详细定义，而是像个真正的开发者，通过第一层的 shell 命令来灵活使用它们。例如，它可以用 ls /bin 来查看有哪些工具可以用，或者用 mcp_cli –help 来了解 MCP 命令行工具的用法。

• 第三层：软件包与 API

在代码层面，Manus 允许 Agent 编写并执行 Python 脚本，特别是当任务需要大量内存计算或要与复杂的第三方服务交互时。比如，如果要分析一整年的股票数据，Agent 不会把所有的原始数据加载到上下文中，而是通过编写脚本来完成计算，最后只把摘要结果返回。

季逸超提到，在这一层，Manus 可以利用 Python 脚本来调用已经授权的 API 或自定义软件包。比如，Manus 可能会用到一个 3D 设计库来进行建模，或者调用金融 API 获取市场数据。实际上，我们已经为用户购买了所有这些 API，并且费用都包含在订阅里。

所以说，Manus 本身就预装了很多 API 密钥，用户可以通过这些密钥来访问 API。这种方式对于那些需要大量内存计算但又不想把所有数据都推送到模型上下文的任务来说，简直是太完美了。

这种设计思路与 CodeAct 的论文有相似之处。

代码是可以组合的，可以在一步内完成很多事情。不过，它同样不是模式安全的，所以在代码上进行约束解码非常困难。因此，我们认为应该为这些功能寻找合适的使用场景。对我们来说，任何能够在一个编译器或解释器运行的任务，我们都用代码来完成；否则，就使用沙箱工具或函数调用。

Manus 的这种分层设计真是优雅又高效。从模型的角度来看，不管是使用第二层还是第三层的复杂工具，最终都会通过第一层的那些原子函数来执行。这种接口设计不仅简洁，而且缓存也很稳定。

03

多 Agent 协作的挑战与解决方案

那么，多个 Agent 之间如何协作呢？这是个不小的挑战。

Cognition 之前在博客里提到过，千万不要滥用多 Agent 的设置，因为一旦 Agent 的数量增加，信息的同步就会变得相当棘手。

如何利用多 Agent 来实现“上下文隔离”，让每个子 Agent 都有自己独立的上下文窗口，从而实现关注点的分离，这就是一个核心问题。

Manus 的解决思路是借鉴 Go 语言的理念：不要通过共享内存来交流，而是通过交流来共享内存。

把这句话中的“内存”换成“上下文”，就形成了两种截然不同的 Agent 协作模式。

两种 Agent 协作模式

• 任务委托模式：通过通信实现隔离

这是经典的主-子 Agent（Master-Sub-agent）模式。主 Agent 会将一个任务封装成简短清晰的指令，然后发送给子 Agent。子 Agent 的上下文是完全独立的，从零开始，只包含这条指令。

简单来说，就是主 Agent 发任务，子 Agent 给结果，中间过程不打扰。

这种模式适合那些“过程不重要，结果最重要”的任务。比如，主 Agent 需要在一个大型代码库中查找特定的代码片段。它只需委托子 Agent：“在 A 项目中找到所有调用了 some_function 的地方”，然后等待返回结果即可。主 Agent 不关心子 Agent 是如何完成搜索的。

在内部，Manus 称这种模式为“Agent 即工具”。从主 Agent 的视角来看，它只是在调用 advanced_search 函数，而实际上是另一个拥有独立工作流的子 Agent 在执行。

• 信息同步模式：通过共享上下文实现协作

但是，对于更复杂的场景，单纯的任务委托是不够的。

Manus 提出的思路是，通过共享上下文来实现协作。子 Agent 在创建时，可以看到主 Agent完整的先前上下文，包括所有历史工具调用和观察。然而，这个子 Agent 也有自己的独立系统提示词和新的行动空间。

这种模式更适合那些高度依赖历史信息、需要综合分析的任务。比如，在进行一项深度研究时，最终的研究报告需要整合大量的中间搜索结果和笔记。

如果采用第一种模式，主 Agent 需要将所有中间产物写入文件，然后让子 Agent 一一读取，这样会导致延迟和额外的 Token 消耗。在这个情况下，直接让子 Agent 继承完整的上下文反而更高效。

不过，Manus 也指出，共享上下文的模式成本相当昂贵。因为每个子 Agent 启动时都需要填充一个非常大的输入，并且由于系统提示词不同，无法复用主 Agent 的 KV 缓存，因此必须支付全价。

所以，根据任务的特性，灵活选择这两种模式是非常重要的。

多 Agent 通信，发信息不难，难的是收结果

多 Agent 之间的一个难点是“接收”，如何从多个同时工作的子 Agent 获取结构一致、内容准确的输出？

Manus 设计了一套内部代号为“Agent 化的 MapReduce”的系统。简单来说，

• 共享沙箱

每个 Manus 会话都在完整的虚拟机沙箱中运行。当主 Agent 创建子 Agent 时，它们共享同一个沙箱。这意味着，它们共享同一个文件系统，信息传递可以简单到只需传递不同的文件路径，这样就解决了输入信息同步的问题。

• 输出模式（Schema）

这非常关键。在创建子 Agent 之前，主 Agent必须先定义一个输出的 Schema。这个模式相当于一份强制执行的 API 合同，规定了子 Agent 最终必须返回什么样的数据结构。

• 约束解码

聊聊这两家公司的设计哲学

好了，咱们再回到最初的话题，聊聊这两家公司的上下文工程设计思路。

Cursor 的理念是「动态上下文发现」，他们主张越简单越好。其实啊，Cursor 发现如果一开始提供给模型的细节少一点，效果反而会更好，这样可以让 Agent 更轻松地找到相关的上下文信息。

而 Manus 则有不同的看法，他们认为「少构建，多理解」才是关键。他们尽量避免上下文的过度设计，目标是让模型的工作变得简单，而不是复杂。

季逸超曾说过，自从 Manus 发布以来的六七个月里，我们看到的最大进步，其实不是通过增加花哨的上下文管理或复杂的检索技巧，而是通过简化，去掉不必要的复杂性，并对模型多一些信任。

每当我们简化架构，系统就会变得更快、更稳定、更智能。上下文工程的目的就是让模型的工作变得更轻松，而不是增加负担。

所以，两家公司的共同目标其实都是从「怎么把更多信息塞进上下文」转变为「如何为 Agent 创建一个信息丰富且易于探索的外部环境」。

引用宝玉老师的一句话，未来随着基模能力的不断提升，把主动权交给模型是必然的趋势。

更多阅读

泛娱乐 AI 赛道观察：从「猜你喜欢」到参与共创，角色才是 AI 时代最核心的资产

两次拿到陆奇投资，张浩然这次想用 Agencize AI 干掉所有工作流 Agent

AI 陪伴赛道复盘：2026 年了，为什么还没有一款千万级 DAU 的产品跑出来？

想成为下一个 Manus，先把这些出海合规问题处理好

发布于 2026-01-10 01:00，北京


说到2026年，大家可能会问，为什么还没有哪个产品能达到千万级的日活跃用户呢？其实，这里面有很多因素在作祟。比如说，如果你想成为下一个成功的科技巨头，像Manus那样，首先得把出海的合规问题搞定。要知道，合规性不仅仅是个法律问题，它关系到你能否在国际市场上立足。总之，面对这些挑战，处理好这些问题，才能真正开启你的出海之路。
标题：轻松分享你的喜好和请求！

“`html

喜欢


收藏


申请转载


“`