文章核心观点 - 上下文工程的优化是AI Agent创业公司当前竞争的重点，其核心思路正从“如何把更多信息塞进上下文”转变为“如何为Agent创建一个信息丰富、易于探索的外部环境”[2][65] - 通过借鉴Cursor和Manus两家头部公司的实践，做好上下文工程的关键在于：实施有效的上下文缩减策略、构建灵活的工具行动空间、以及设计高效的多Agent协作模式[6][65] 上下文缩减策略 - 问题根源：上下文腐烂 Agent每调用一次工具，结果就会被追加到聊天记录中，导致上下文无限制增长[9] 典型任务可能需要调用50次工具，生产环境中的Agent对话轮次可能长达数百轮[10] 这会导致推理性能断崖式下跌，表现为推理变慢、质量下降和无意义重复，即“上下文腐烂”[10] - 主流解决方案：上下文卸载 业内共识是将信息转移到上下文窗口之外，需要时再精确检索回来，即“上下文卸载”[10] 将信息转移到文件系统是目前生产级Agent中主流且最有效的做法[11] - Cursor的“动态上下文发现”模式 其核心是让模型在需要时自己去找信息，而非急于将信息塞给模型[13] 具体做法包括： - 将冗长的工具结果（如巨大的JSON响应或Shell命令输出）直接写入文件，在上下文中仅告知Agent结果的文件位置[14] - 当上下文窗口被填满时，触发“总结”步骤，为Agent提供一份摘要和一个指向完整历史记录文件的引用，Agent可按需搜索该文件获取细节[15] - 将集成终端的所有会话输出同步到本地文件系统，使Agent能直接定位和搜索相关问题[18] - Manus的结构化可逆缩减系统 该系统设定明确的触发机制并分阶段执行[19] - 监控与触发：系统持续监控上下文长度，并设定一个远低于模型硬件极限的“腐烂前阈值”作为触发条件，该阈值通常在12.8万到20万个Token之间[20][21] - 第一阶段：紧凑化 这是一种无损、可逆的缩减，剥离能从外部状态（如文件系统）重建的信息[22] 例如，将文件写入操作中的冗长content字段剥离，仅保留path字段[22] 信息被“外部化”而非丢失，Agent后续可通过path检索[23] 通常只对最早的50%历史记录进行紧凑化，以保留最新的完整工具调用作为学习范例[24] - 第二阶段：摘要化 当紧凑化收益微乎其微时启动，这是一种有损但带保险的压缩[25] 保险措施在于：在生成摘要前，将完整的上下文转储到一个文本或日志文件中创建快照存档[26] 摘要化会使用完整版本的数据，并保留最后几次完整的工具调用记录，以保持工作连贯性[28][29] 工具行动空间管理 - 问题根源：工具过载 将所有工具的冗长描述都放入上下文会导致“上下文混淆”和直接的Token浪费[31][36] - 核心思路：动态发现 让Agent自己去找要调用哪些工具[31] - Cursor的策略：工具说明书文件化 将所有MCP工具和Agent Skills的详细定义同步到文件夹中，Agent在需要时自行查阅[32] 其框架分为索引层和发现层：系统提示词中仅包含工具名称列表，详细描述则存放在本地文件夹供Agent主动搜索[34] 该策略在一次A/B测试中，对于调用了MCP工具的任务，将Token总消耗降低了46.9%[35] 这种方式还能向Agent传达工具状态，例如在MCP服务器需要重新认证时，Agent可以主动告知用户[37][38] - Manus的策略：分层行动空间 将Agent能力划分为三个层次[41] - 第一层：原子函数调用 核心层，只包含极少数固定的、正交的原子函数，如读写文件、执行shell命令、搜索等，此层固定，对KV缓存友好且功能边界清晰[42] - 第二层：沙盒工具 卸载层，将绝大多数工具（如格式转换器、语音识别工具、MCP调用本身）作为预装软件放在定制的Linux虚拟机沙箱中[43] Agent不在上下文中“看到”这些工具定义，而是通过第一层的shell命令动态交互，例如用ls /bin查看可用工具[43] - 第三层：软件包与API 代码层，对于需要大量内存计算或与复杂第三方服务交互的任务，允许Agent编写并执行Python脚本，仅返回摘要结果[44] 例如，Manus预装了大量API密钥，Agent可用其访问金融API获取市场数据[44] - 设计优势 从模型角度看，无论使用第二层还是第三层的复杂工具，最终都通过第一层的几个原子函数执行，这种接口设计对模型极度简洁且缓存稳定[47] 多Agent协作模式 - 核心问题：上下文隔离与信息同步 如何利用多Agent实现“上下文隔离”，让每个子Agent有独立的上下文窗口以实现关注点分离，同时解决它们之间的信息同步难题[49][50] - 两种协作模式 - 任务委托模式（通过通信实现隔离） 经典的主-子Agent设置，主Agent将任务封装成简短指令发送给子Agent，子Agent上下文完全独立[53] 适用于“过程不重要，只关心结果”的任务，如委托子Agent在代码库中搜索特定代码片段[54] Manus内部称此模式为“Agent即工具”[54] - 信息同步模式（通过共享上下文实现协作） 子Agent创建时能看到主Agent完整的先前上下文，但拥有独立的系统提示词和行动空间[55] 更适用于高度依赖历史信息、需要综合分析的任务，如深度研究报告[55] 但此模式成本昂贵，因为每个子Agent启动时都需要Prefill大量输入且无法复用主Agent的KV缓存[55] - 通信难点与解决方案：结构化输出 多Agent通信的难点在于如何从多个并行子Agent处获得结构一致、内容准确的输出[57] Manus设计了一套“Agent化的MapReduce”系统，其关键包括： - 共享沙箱：主Agent与子Agent共享同一个虚拟机沙箱和文件系统，信息传递可通过文件路径完成[58] - 输出模式：主Agent在创建子Agent前必须先定义一个输出的Schema，作为强制执行的API合同[59] - 约束解码：使用约束解码技术，强制子Agent通过专用工具submit_result提交的结果必须严格符合主Agent定义的Schema[60] - 核心思路 无论是做摘要还是Agent间通信，都反复使用模式和结构化输出作为一种“契约”，以保证信息以结构化、完整的方式传递[61] 设计哲学总结 - Cursor的设计哲学 强调“少即是多”，认为最初提供给模型的细节越少，效果反而越好，这能让Agent更轻松地自行抓取相关上下文[62] - Manus的设计哲学 强调“少构建，多理解”，避免上下文的过度工程化[63] 其经验表明，最大的飞跃来自简化架构、移除不必要的技巧以及对模型多一点的信任，每次简化都使系统更快、更稳定、更智能[63][64] 上下文工程的目标是让模型的工作变得更简单，而不是更难[64]