文章核心观点 - 上下文工程的优化是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]

产品功能更新 - OpenAI推出群聊功能，允许用户在同一对话中邀请最多20位成员进行人际协作，并可将ChatGPT拉入协作 [2] - 功能首次向日本、新西兰、韩国等地区用户开放 [2] - 群聊数据与用户的个人ChatGPT记忆完全隔离，确保私密对话不被泄露 [3] - 用户可通过“@”明确召唤ChatGPT，AI也具备场景感知能力，能主动判断何时该介入对话 [4][5] - 群聊支持多模态能力，包括联网搜索最新信息、生成图片、以及对成员上传的文档进行摘要、分析、翻译和提取关键信息 [6] 技术能力与交互逻辑 - 新的群聊功能赋予ChatGPT场景感知能力，使其能在不被@的情况下判断出“可以提供帮助”的时刻并主动发言，例如在讨论电影时推荐影片 [4][5][6] - AI基于群聊上下文对每个成员进行建模，理解其对话风格和需求 [7] - AI在群聊中的角色被比喻为一个“极有眼力见的实习生”，但其判断并非完美，有时仍会在不该说话时插嘴 [6][7] 商业化战略意图 - 推出群聊功能是OpenAI商业化逻辑的调整，旨在从只卖API转向让用户在平台沉淀关系和数据，以产生网络效应并提高用户迁移代价 [9] - 此举将ChatGPT从个人助理转变为可协作的平台，使用户因项目、客户关系而依赖平台，而不仅仅是模型性能 [9] - 群聊功能也是在测试ChatGPT的社交能力，使其理解多人对话中的复杂上下文和不同意图，为进入人类日常协作奠定基础 [10] 未来发展方向 - 群聊功能可能是在为多Agent协作进行技术验证和用户教育，未来可想象多个AI角色（如产品经理、工程师）在群内自动分工配合完成项目 [11] - 远期展望包括AI在群内扮演上帝或DM，与用户玩狼人杀、剧本杀等互动游戏 [10] - 该功能被视为定义AI时代人与机器协作范式的重要一步，标志着AI从辅助工具转变为直接参与人类会议协作的成员 [12][13]