被 Meta 以 3 亿美元收购的 Manus，与 LangChain 联合公开了智能体开发的核心原则

Meta 斥资 3 亿美元收购 Manus 的消息霸占了各大头条，但真正值得关注的，是 Manus 在与 LangChain 的联合演讲中透露的内容。这场分享毫无保留地拆解了构建”真正能用”的 AI 智能体背后的核心原则 - 并且清晰地划出了一条线：创业公司常犯的错误在一边，真正有效的策略在另一边。

上下文腐化的悖论

智能体需要工具。工具越多，能力越强。但问题来了：智能体调用的工具越多，上下文就越膨胀 - 性能也随之直线下降。

Manus 把这种现象称为上下文腐化（Context Rot）。这是智能体开发中最核心的悖论：让你的智能体变强的东西，同时也在让它变蠢。

解决方案是上下文工程（Context Engineering） - 只给模型展示下一步所需的信息，多余的一概不要。

Manus 总结了六种具体技术：

• 卸载（Offload） - 把占用大量 token 的数据转移到文件系统，不要塞在上下文里
• 裁剪（Reduce） - 激进地清除过时信息
• 压缩（Compact） - 可逆地压缩可恢复的数据（比如删掉文件内容但保留路径）
• 摘要（Summarize） - 不可逆地压缩信息，但始终通过结构化 schema 来做
• 检索（Retrieve） - 按需通过搜索提供信息
• 隔离（Isolate） - 使用拥有独立上下文的子代理

核心洞察：上下文管理不是锦上添花的优化，而是一个决定你的智能体能否规模化的架构级决策。做不好这一点，智能体终将在自身的上下文重量下崩塌。

在找到 PMF 之前，别急着微调

Manus 指出的一个最常见的创业错误：在找到产品市场契合度（PMF）之前就去训练专用模型。

逻辑很简单。通用大模型加上强大的上下文工程，能带来快得多的迭代周期。过早微调等于把自己锁死在一套尚未经过用户验证的假设上。

更尖锐的一点：模型改进的速度，决定了产品创新速度的天花板。微调会拖慢这个循环，上下文工程则能让它保持高速。

等产品验证成功之后再考虑微调。在此之前，它就是最昂贵的过早优化。

多智能体模式：两种截然不同的路径

Manus 归纳了两种基本的多智能体模式，分别适用于不同类型的任务：

通信模式（Communicating Pattern） - 子代理从零开始。主代理发送一个聚焦的请求，子代理独立处理后返回结果。最适合低上下文、可并行的任务，比如代码搜索或数据检索。

共享记忆模式（Shared Memory Pattern） - 子代理共享完整的对话历史，但各自使用不同的提示词和工具集。最适合复杂的、环环相扣的任务，比如深度研究 - 每一步都建立在之前的发现之上。

选择哪种模式不取决于能力，而取决于上下文需求。如果子任务是自包含的，用通信模式；如果它需要完整的全局信息，用共享记忆模式。选错了，要么在无用的上下文上浪费 token，要么让智能体因信息匮乏而无法完成任务。

三层动作空间：防止工具过载

工具太多会让模型犯迷糊。Manus 的应对方案是一套分层架构，限制模型在任意时刻能”看到”的工具数量：

原子层（Atomic Layer） - 10 到 20 个核心能力：读、写、Shell、浏览器。这些始终可用，模型直接调用。

沙箱工具（Sandbox Utilities） - 预装的 CLI 工具，比如格式转换器、Linter、代码格式化工具。模型通过 Shell 来调用它们，而不是把它们作为独立的工具暴露出来。

包与 API（Packages and APIs） - 带预认证 API 密钥的 Python 脚本。负责处理外部服务交互，同时避免把完整的 API 接口暴露给模型。

这种分层让模型的决策空间保持在可控范围内。它不再需要从 200 个工具中做选择，而是从 15 个核心动作中选取，其余通过 Shell 调用。结果是工具选择更可靠，幻觉调用和错误调用大幅减少。

重新思考评估指标

GAIA 之类的公开基准测试并不能反映真实用户的偏好。Manus 的立场很明确：黄金标准是用户对已完成会话的评分，1 到 5 分制。

三条评估原则浮出水面：

1. 执行测试优先于问答测试 - 智能体能不能在沙箱中真正完成任务？这比它能不能”回答关于任务的问题”重要得多。
2. 主观质量必须靠人工审查 - 视觉美感、语气和整体连贯性无法自动打分，必须有人亲眼看过输出结果。
3. 基准分数必要但不充分 - 它们证明了基线能力，但证明不了产品好不好用。

核心教训

过度工程是最大的敌人。

最大的性能提升不来自增加复杂度 - 而来自消除复杂度。别给模型增加负担，要给它减负。

这或许正是 Meta 愿意花 3 亿美元买下 Manus 的原因。不是因为花哨的功能，而是因为一套以本质为核心的设计哲学：剥离不必要的东西，毫不留情地管理上下文，构建出让模型能专注于任务、而非淹没在自身状态中的系统。

在生产环境中真正跑得通的智能体，不是能力最多的那个，而是每一项能力都能发挥作用的那个。