摘要：10年NLP（自然语言处理）经验的AI创业公司联创坦言：“对于创业公司，过早微调（Fine-tuning）模型是一个陷阱。”

Manus联创的“血泪”教训：为什么上下文工程，而非模型微调，才是护城河？

10年NLP（自然语言处理）经验的AI创业公司联创坦言：“对于创业公司，过早微调（Fine-tuning）模型是一个陷阱。”

这不是危言耸听。

Manus联合创始人兼首席科学家Peak最近与LangChain创始人交流中，分享了“血泪教训”：上一个产品，迭代速度被长达1-2周的模型训练周期活活拖死。

这次把赌注压在“上下文工程”（Context Engineering）上，团队短短几个月内，将产品重构了整整5次。

为什么如此笃定？

1. “微调”陷阱：被模型拖垮的“上一个”公司

创立Manus前，Peak已经在NLP领域摸爬滚打了10年。上一个创业项目和现在许多AI团队一样，选择“训练自有模型”的重度路线。

结果是灾难性的。

“产品创新速度完全被模型迭代速度给限制了。”Peak回忆道。

产品还没找到PMF（市场契合点）的阶段，他们却在花费大量时间“提升那些可能根本不重要的基准测试”。

一个单一的“训练-评估”周期，就需要1到2周。

当团队在焦急地等待模型时，市场窗口早已关闭。

但最大的“陷阱”还不是时间，而是“僵化”。

“微调模型时，通常会固定一个‘行动空间’（Action Space）。”

就像花重金打造一把精妙绝伦的“屠龙宝刀”。但如果第二天，巨头发布了（比如多模态MCP），市场不再需要“屠龙”，而是需要“飞天”，这把刀就成了一堆废铁。

“Manus设计曾被MCP的发布彻底改变。”Peak坦言，如果当时死磕微调，唯一的下场就是被市场活活抛弃。

2. 划清界限：AI应用层的真正边界

经历“痛苦”领悟后，Peak为Manus找到了清晰无比的战略边界。

“必须坚定地划清界限（Be firm about where you draw the line）。”

AI应用层创业的界限就是“上下文工程”。

这是目前应用和模型之间最清晰、最实用的边界。创业公司应该“尽可能久地”依赖通用大模型，而不是试图在模型层与巨头竞争。

巨头的护城河是“模型”，而应用层的护城河，就是“使用”模型的能力——即“上下文工程”。

那么，这个听起来高深的“上下文工程”到底是什么？

3. “上下文悖论”：Agent的阿喀琉斯之踵

2022年大家谈论“提示词工程”（Prompt Engineering），解决单次交互。

而2024年面临的是“上下文工程”（Context Engineering），解决Agent（智能体）的长序列、多轮工具调用。

LangChain创始人Lance指出“上下文悖论”：Agent要完成复杂任务，必须大量调用工具（典型任务约50次）来获取上下文。

但上下文越长，Agent性能就越差，成本也呈指数级上升。

更糟糕的是，即使100万Token上下文窗口，模型在处理到200K（约20万）时，性能就开始“腐烂”（Context Rot），出现重复、缓慢和质量下降。

“上下文腐烂”阈值大约128K到200K之间。

Agent又慢又笨，不是模型不行，是“上下文工程”没做好。

4. 破局：上下文工程的4大支柱

如何解决这个悖论？上下文工程常见方法

这些策略并非孤立存在，而是相互关联、协同工作，共同构成了现代 AI Agents 架构的基石

总结

LangChain Lance总结了业内顶尖团队（包括Manus）都在使用的4大工程支柱：

Manus心得

详情：

1️⃣ 上下文卸载 (Offloading)

做法：不把所有信息都塞进上下文。

比如，一个万字的网络搜索结果，只在上下文中返回一个文件路径（file.txt），Agent需要时自己去读。

场景：处理大文件、大输出。

2️⃣ 上下文检索 (Retrieving)

做法：把信息（如记忆）存储在外部（如向量数据库），需要时通过RAG或简单grep命令检索回来。

场景：长时记忆、知识库。

3️⃣ 上下文隔离 (Isolation)

做法：使用多智能体（Multi-Agent）架构，每个子Agent只处理自己的小上下文窗口，互不干扰。

场景：复杂任务拆解。

4️⃣ 上下文缩减 (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说。

这种“上下文工程”能力，也让manus在选择模型时有了更反直觉的洞察。

Peak甚至认为，对于Agent应用，使用开源模型可能“更贵”。

关键在于成本，Agent输入（上下文）远大于输出，KV缓存至关重要。而头部API厂商（如Anthropic）在分布式KV缓存上做了坚实的基建，使得在超长上下文中，API成本甚至低于自托管的开源模型。

7. 结语：构建更少，理解更多

回顾Manus历程，Peak给出最深刻的领悟：

“我们最大的飞跃，不是来自添加了更花哨的上下文管理技巧，而是来自‘简化’和‘移除不必要的层’。”

“最终哲学：构建更少，理解更多（Build less and understand more）。”

这位10年NLP老兵最后总结道：

“上下文工程的真正目标，不是让系统更复杂，而是让模型的工作，变得更简单。”

参考：

LangChain联合Manus季逸超最新分享！也许当前最好的「上下文工程」讲解

Context Engineering for AI Agents with LangChain and Manus

推文 ：https://x.com/PMbackttfuture/status/1983023370561335770

youtube 视频

https://www.youtube.com/watch?v=6_BcCthVvb8#

来源：鹤啸九天blog