Manus联创的"血泪"教训：为什么上下文工程,而非模型微调,才是护城河?
一位拥有10年NLP(自然语言处理)经验的AI创业公司联创坦言:"对于创业公司,过早微调(Fine-tuning)模型是一个陷阱。"
这不是危言耸听。
Manus的联合创始人兼首席科学家Peak,在最近与LangChain创始人的对谈中,分享了他的"血泪教训":他的上一个产品,迭代速度被长达 1-2周 的模型训练周期活活拖死。
这一次,他选择把所有赌注压在"上下文工程"(Context Engineering)上,并为此,他的团队在短短几个月内,将产品重构了整整 5次。
为什么他如此笃定?
1. "微调"的陷阱:被模型拖垮的"上一个"公司
在创立Manus之前,Peak已经在NLP领域摸爬滚打了10年。他的上一个创业项目,和现在许多AI团队一样,选择了"训练自有模型"的重度路线。
结果是灾难性的。
"我们的产品创新速度,完全被模型的迭代速度给限制了。"Peak回忆道。
在产品还没找到PMF(市场契合点)的阶段,他们却在花费大量时间"提升那些可能根本不重要的基准测试"。一个单一的"训练-评估"周期,就需要1到2周。
当团队在焦急地等待模型时,市场窗口早已关闭。
但最大的"陷阱"还不是时间,而是"僵化"。
"当你微调一个模型时,"Peak解释道,"你通常会固定一个'行动空间'(Action Space)。"
这就像你花重金打造了一把精妙绝伦的"屠龙宝刀"。但如果第二天,巨头发布了(比如多模态MCP),市场不再需要"屠龙",而是需要"飞天",你这把刀就成了一堆废铁。
"Manus的设计就曾被MCP的发布彻底改变。"Peak坦言,如果他们当时死磕微调,唯一的下场就是被市场活活抛弃。
2. 划清界限:AI应用层的真正边界
经历了上一次的"痛苦"领悟,Peak这次为Manus找到了一个清晰无比的战略边界。
"你必须坚定地划清你的界限(Be firm about where you draw the line)。"
对于AI应用层创业,这条界限就是"上下文工程"。
Peak认为,这是目前应用和模型之间最清晰、最实用的边界。创业公司应该"尽可能久地"依赖通用大模型,而不是试图在模型层与巨头竞争。
巨头的护城河是"模型",而应用层的护城河,就是你"使用"模型的能力——即"上下文工程"。
那么,这个听起来高深的"上下文工程"到底是什么?
3. "上下文悖论":Agent的阿喀琉斯之踵
2022年,我们谈论的是"提示词工程"(Prompt Engineering),它解决的是单次交互。 而2024年,我们面临的是"上下文工程"(Context Engineering),它要解决的是Agent(智能体)的长序列、多轮工具调用。
LangChain的创始人Lance指出了一个"上下文悖论":
Agent要完成复杂任务,必须大量调用工具(典型任务约50次)来获取上下文。
但上下文越长,Agent的性能就越差,成本也呈指数级上升。
更糟糕的是,Peak发现,即使是100万Token的上下文窗口,模型在处理到200K(约20万)时,性能就开始"腐烂"(Context Rot),出现重复、缓慢和质量下降。
"上下文腐烂"的阈值,大约就在 128K到200K 之间。
你的Agent又慢又笨,不是模型不行,是你的"上下文工程"没做好。
4. 破局:上下文工程的4大支柱
如何解决这个悖论?LangChain的Lance总结了业内顶尖团队(包括Manus)都在使用的4大工程支柱:
上下文卸载 (Offloading)
做法: 不把所有信息都塞进上下文。比如,一个万字的网络搜索结果,只在上下文中返回一个文件路径(file.txt),Agent需要时自己去读。
场景: 处理大文件、大输出。
上下文检索 (Retrieving)
做法: 把信息(如记忆)存储在外部(如向量数据库),在需要时通过RAG或简单的grep命令检索回来。
场景: 长时记忆、知识库。
上下文隔离 (Isolation)
做法: 使用多智能体(Multi-Agent)架构,每个子Agent只处理自己的小上下文窗口,互不干扰。
场景: 复杂任务拆解。
上下文缩减 (Reducing)
做法: 这是最核心也最精妙的一步,即在上下文"腐烂"之前,主动对其进行"瘦身"。
而Manus团队,正是在"上下文缩减"上,做到了极致。
5. Manus实战:"压缩"与"摘要"的精妙艺术
Peak的团队将"缩减"分为了两种截然不同的操作:
1. 压缩 (Compaction):可逆的"瘦身"
定义: 删除那些可以从外部(如文件系统)重建的信息。
例子: 一个工具调用,完整信息是{path: "file.txt", content: "..."}。在"压缩"后,只保留{path: "file.txt"}。
优势: 信息"零"丢失,只是被"外置"了。
2. 摘要 (Summarization):不可逆的"遗忘"
定义: 对历史信息进行总结,彻底丢弃原文。
优势: 大幅度释放上下文空间。
Manus的策略堪称精妙:
设置"腐烂"闹钟: 首先,团队会设置一个"腐烂阈值",比如128K。
先"压缩",后"摘要": 当上下文达到128K时,系统首先触发"压缩"。只在"压缩"的收益也变小时,才万不得已触发"摘要"。
"压缩"的艺术: 执行"压缩"时,只压缩最老的50%历史,并保留最新的50%工具调用的完整信息。这能确保模型有足够的新鲜"样例"来模仿,防止其行为错乱。
"摘要"的技巧: 执行"摘要"时,会使用原始的、未经压缩的数据来总结,以保证信息保真度。并且,同样会保留最后几个工具调用的全量信息,防止模型"忘记自己刚刚在干什么"。
6. 在流沙上构建:5次重构与"更贵"的开源
这套复杂的"上下文工程"架构,就是Manus的护城河。它让Manus有能力在"流沙"(不断迭代的大模型)之上构建稳固的应用。
"从3月到现在,我们已经重构了5次。"Peak说。
这种"上下文工程"能力,也让他们在选择模型时有了更反直觉的洞察。
Peak甚至认为,对于Agent应用,使用开源模型可能"更贵"。
"这很有趣,关键在于成本。"他解释道,"Agent的输入(上下文)远大于输出,KV缓存至关重要。"而头部API厂商(如Anthropic)在分布式KV缓存上做了坚实的基建,使得在超长上下文中,API的成本甚至低于自托管的开源模型。
7. 结语:构建更少,理解更多
回顾Manus的历程,Peak给出了他最深刻的领悟:
"我们最大的飞跃,不是来自添加了更花哨的上下文管理技巧,而是来自'简化'和'移除不必要的层'。"
"我们最终的哲学是:构建更少,理解更多(Build less and understand more)。"
这位10年NLP老兵最后总结道:
"上下文工程的真正目标,不是让你的系统更复杂,而是让模型的工作,变得更简单。"
from Langchain
Context Engineering for AI Agents with LangChain and Manus