在AI智能体开发领域，一个普遍存在的认知误区是：系统越复杂、功能越丰富、提供给模型的信息越多，其性能就越强大。然而，Hugging Face机器学习工程师Philipp Schmid近期分享的Manus AI案例，却彻底颠覆了这一传统观念。Manus团队在构建AI代理系统时，经历了五次彻底的重构，最终发现了一个反直觉的真理：删除代码往往比添加功能更能提升系统效能。这一发现不仅关乎技术优化，更触及了AI工程哲学的核心——在信息爆炸的时代，如何为模型提供“恰到好处”的上下文，而非“越多越好”的冗余数据。
Schmid将这一洞见提炼为一个简洁而有力的原则：为AI智能体寻找“刚好够用”的信息，避免用无关数据污染其认知空间。这背后涉及一个关键但常被忽视的技术现象：“上下文腐败”（Context Rot）。即便现代大模型宣称能处理百万级token的上下文窗口，实际应用中，当输入token数量达到约25万时，模型性能就会出现显著衰减。这类似于计算机内存过载导致的系统卡顿——模型在过长的上下文中难以有效聚焦，检索相关信息的成本急剧上升，最终输出质量下降。大多数开发者盲目追求扩大上下文容量，却忽略了优化信息质量与密度，结果往往事与愿违。
Manus团队通过实践探索出三条核心的上下文管理策略，这些策略共同指向一个方向：做减法。
首先，**实施主动的上下文压缩与清理**。这包括两种具体方法：一是“可逆压缩”，即删除那些已存储在其他位置（如文件、数据库）的冗余信息。例如，当AI生成并保存了500行代码后，聊天记录中便无需保留完整代码，仅需引用文件路径即可，需要时再动态读取。这大幅降低了上下文负载。二是“有损摘要”，当上下文长度超过12.8万token时，引导模型对早期对话进行总结，但保留最近三轮完整对话以维持模型的连贯“手感”。这种平衡确保了历史信息的凝练与当前任务的精准执行。
其次，**打破“共享大脑”的迷思，实现上下文隔离**。在多智能体系统中，让所有代理共享同一套上下文是常见错误，这会导致信息污染与相互干扰。Manus借鉴了Go语言的并发哲学——“通过通信共享内存，而非通过共享内存进行通信”。具体实践中，他们将任务分层处理：对于简单任务（如关键词搜索），为代理分配独立的、任务专属的上下文；仅当处理复杂任务（如需要历史错误记录的调试）时，才有限度地共享必要上下文。这种设计显著提升了各代理的专注度与执行效率。
第三，**精简工具集，推行极简主义**。为AI提供过多工具选项反而会增加其混淆与误用概率。Manus构建了一个三层工具架构：底层保留约20个基础工具（如文件读写、命令执行、搜索等），确保核心功能覆盖；中层避免定义独立工具，直接通过命令行调用实现功能；顶层则将复杂操作封装为代码库，供一次性调用。这种结构化精简使AI更易理解与使用可用工具，减少了决策负担。
此外，Manus倡导**将AI视为工具而非拟人化实体**。许多开发者热衷于为代理赋予人格化角色（如“经理AI”、“设计师AI”），并设计复杂交互剧情。Schmid指出，这属于过度拟人化，可能引入不必要的复杂性。更高效的范式是将子代理视为可调用的函数：主AI通过类似`call_planner(goal=”…”)`的指令触发子系统，后者返回结构化结果，如同调用标准化API。这提升了系统的模块化、可预测性与调试便利性。
实际应用效果验证了这些原则的价值。有开发者在采纳Manus方法后，虽经三次重构才实现稳定，但最终将token使用成本降低了40%，同时系统响应速度与可靠性显著提升。这一数据有力证明了“减法”带来的工程与经济收益。基于此，我们可提炼出几条实用建议：避免使用基于语义相似性的动态工具加载机制，因其易混淆模型；在模型迭代飞快的当下，优先完善工程架构而非匆忙训练自有模型；设立token使用量预警线，实施前瞻性监控；采用简单、直接的验证指标（如“代码能否运行”、“文件是否成功创建”），规避复杂评分体系带来的额外开销。
Manus团队的最大收获在于掌握了“删除的艺术”。他们删减了冗余的工具定义、不必要的管理层级、以及花哨的路由逻辑，系统反而变得更加稳定、高效且成本可控。正如LangChain的Lance Martin所言：“2025年最卓越的AI系统，或许并非那些能处理百万token的巨兽，而是仅用5万token就能精准解决问题的精悍引擎。”这一观点揭示了一个深刻趋势：AI工程的未来竞争力，将 increasingly 取决于“减什么”与“怎么减”的智慧——这不仅是技术选择，更是构建可持续、可扩展AI系统的核心壁垒所在。
参考博文：https://www.philschmid.de/context-engineering-part-2
关注“鲸栖”小程序，掌握最新AI资讯
本文来自网络搜集，不代表鲸林向海立场，如有侵权，联系删除。转载请注明出处：http://www.itsolotime.com/archives/5552
