上下文工程崛起：Manus天才少年Peak Ji揭示AI Agent核心突破

一个任务50次工具调用，上下文无限膨胀，性能急剧下降——这就是AI Agent面临的核心挑战。一位中国90后天才提出了革命性解决方案。

在ChatGPT引爆全球AI热潮后，一个全新的领域——上下文工程正在悄然崛起。当各大科技公司还在比拼模型参数规模时，一位来自中国的年轻技术天才已经找到了让AI真正智能化的关键所在。

他就是季逸超，更为人熟知的名字是Peak Ji，Manus的联合创始人兼首席科学家。近日在与LangChain的联合研讨会中，他揭示了构建高效AI智能体的核心技术——上下文工程，并分享了从数百万次真实交互中总结的宝贵经验。

Peak Ji的技术天赋在少年时期就已显现。不到18岁，他就因成功升级iPhone OS 4.0系统而被誉为"中国iPhone OS 4.0第一人"。

早在高中时期，他就独立开发了猛犸浏览器，并因此获得了真格基金和红杉资本的天使投资。

凭借出色的技术成就，季逸超在19岁时就登上了《福布斯》杂志的封面，并多次入选"30岁以下精英榜"。

他后来创立了Peak Labs实验室，并成为Manus的联合创始人兼首席科学家。作为《麻省理工科技评论》评选的2025年35岁以下创新者之一，他正带领团队在AI Agent领域开辟新的天地。

随着AI Agents执行日益复杂的长期任务，其上下文窗口会因大量的工具调用而急剧膨胀，导致性能显著下降。

LangChain的创始工程师Lance Martin在最近的联合研讨会中解释道："典型的任务可能需要大约50次工具调用，生产环境中的代理可能会进行长达数百轮的对话。"

这就形成了一个核心矛盾：Agents的强大功能依赖于利用大量上下文信息，但模型的性能却会因为上下文过长而受损。

Anthropic在一份关于"上下文腐烂"（context rot）的报告中确认了这一现象——随着上下文长度的增加，模型性能会显著下降。

面对这一挑战，业界逐渐形成了一套系统的解决方案。Lance Martin总结了上下文工程的五大核心策略：

上下文卸载

将信息从核心的对话历史中移出，存放到外部系统（如文件系统），只在上下文中保留一个轻量级的引用。

比如，将工具消息的输出转储到文件系统中，然后只向智能体返回必要的最简信息。

上下文缩减

通过总结或压缩来减少信息量，例如修剪旧的工具调用记录。

Manus将缩减操作细分为两种：压缩和总结。压缩是一种可逆的缩减，而总结则是不可逆的精炼。

上下文检索

在需要时，按需从外部系统将信息取回。实现方式包括基于索引的语义搜索，或更简单的基于文件系统的搜索工具。

上下文隔离

通过将任务分解给多个子代理（sub-agents），每个子代理拥有自己独立的、更小的上下文窗口，从而实现关注点分离和上下文管理。

上下文缓存

对上下文信息进行缓存，以提高效率（这一点在Manus的实践中被特别提及）。

在Manus的官方技术博客中，Peak Ji分享了团队从四次重构和数百万次真实交互中总结的宝贵经验。

围绕KV-Cache进行设计

"如果我必须选择仅一个指标，我认为KV-cache命中率是生产阶段AI Agent最重要的单一指标。它直接影响延迟和成本。"

Peak Ji解释道，在Manus中，平均输入与输出token比率约为100:1，这使得KV缓存优化变得至关重要。以Claude Sonnet为例，缓存的输入token成本为0.30美元/MTok，而未缓存的成本为3美元/MTok——相差10倍。

掩码，而非移除

随着Agent能力增强，其行动空间会自然变得更加复杂。Manus使用上下文感知的状态机来管理工具可用性，它不是移除工具，而是在解码过程中屏蔽token logits，防止基于当前上下文选择某些行动。

将文件系统作为上下文

"现代前沿大语言模型现在提供128K个token或更多的上下文窗口。但在真实世界的Agent场景中，这通常不够，有时甚至是一种负担。"

Manus将文件系统视为终极上下文：容量无限、天然持久，并且代理可直接操作。模型学会按需读写文件——把文件系统不仅当作存储，更当作结构化、外化的记忆。

通过"背诵"操控注意力

在Manus中，一个典型任务平均需要约50次工具调用。这是一个很长的循环——Agent很容易在冗长上下文或复杂任务中偏离主题或遗忘早期目标。

通过不断重写待办清单，Manus把目标"背诵"到上下文的末尾。这会将全局计划推入模型的近期注意力范围，避免了"迷失在半道"的问题，并减少了目标错位。

在创办Manus之前，Peak拥有超过十年的自然语言处理经验，他的上一个创业项目就是从零开始训练自己的语言模型。

这段经历让他痛苦地认识到，过早地构建专用模型会带来巨大风险：

• • 扼杀创新速度：产品的迭代速度完全被模型的迭代速度所限制。一个训练加评估的周期可能需要一到两周，这对于需要快速验证产品市场契合度的初创公司是致命的。
• • 优化目标错位：在产品方向尚未完全明朗时，团队可能会花费大量时间去提升一些对产品价值可能毫无意义的基准测试分数。

"初创公司应该尽可能长时间地依赖通用模型和上下文工程。"

然而，随着产品成熟和开源基础模型的崛起，另一个陷阱也随之出现：用自有数据微调一个强大的基础模型，使其在特定用例上表现出色。

Peak指出这同样是危险的，因为AI和Agents的早期阶段是极其脆弱的，底层技术可能一夜之间发生颠覆。

MCP的发布就是一个典型例子——它彻底改变了Manus的设计，使其从一个紧凑、静态的行动空间，转变为一个几乎无限可扩展的系统。

上下文精简是上下文工程的核心技术之一，但Manus在实践中将其细分为两种截然不同但相辅相成的方法：压缩（Compaction）和总结（Summarization），并建立了一套严谨的工作流程来协同使用它们。

压缩：可逆的信息外化

压缩的核心思想是一种可逆的信息缩减。它并非真正地"减少"信息，而是将信息的一部分外化到上下文窗口之外的某个地方（如文件系统或外部状态），同时在上下文中保留足以重建完整信息的线索。

具体例子：假设一个工具的功能是向文件中写入内容，它可能包含两个字段：path（路径）和content（内容）。一旦这个工具执行成功，我们就可以确定该文件已经存在于环境中。因此，在紧凑格式中，可以安全地丢弃可能非常长的content字段，只保留path。如果Agent后续需要再次读取该文件，它可以通过path轻松地检索到全部内容。

可逆性至关重要：Agents的决策是链式的，基于之前的行动和观察。我们永远无法预知过去的哪个动作会在十步之后突然变得至关重要。可逆的压缩确保了没有任何信息被真正丢失，只是被暂时移出了即时上下文。

总结：不可逆的谨慎精炼

当仅靠压缩已无法将上下文大小控制在阈值以下时，就需要动用更传统的总结方法。总结是不可逆的，意味着信息会有损失，因此必须非常谨慎地使用。

在执行总结之前，一个最佳实践是先将上下文中的关键部分卸载到文件中。在更激进的情况下，甚至可以将整个待总结的上下文作为一个文本或日志文件转储到file system中。

基于阈值的工作流程

为了让压缩和总结能够和谐共存，Manus设计了一套基于多层上下文长度阈值的自动化流程：

• • 确定阈值：模型性能开始显著下降的实际阈值通常在128K到200K token之间。
• • 触发压缩：当上下文长度接近"预腐烂阈值"时，首先触发压缩。
• • 必要时总结：只有在多轮压缩后，上下文长度仍然接近性能"腐烂"的临界点时才会触发总结。

Peak Ji在研讨会尾声分享了一个深刻洞见：优秀的上下文工程不仅是技术组合，更是一种 "less is more" 的哲学。

"回顾Manus发布过去的六、七个月，我们最大的性能提升并非来自添加更花哨的上下文管理层或更精巧的检索技巧，恰恰相反，它们都源于简化架构、移除不必要的技巧和更多地信任模型。"

他总结道："上下文工程的目标是让模型的工作更简单而不是更复杂。如果要从今天分享中带走一句话，那就是——建造更少，理解更多。"

关注我并回复“上下文工程”，获取LangChain与Manus关于上下文工程的完整原始PPT资料