manus 发文介绍了其 wide research 功能。该功能采用“一任务一子代理”的并行架构，替代了传统的单模型顺序处理方式。这种架构能够消除长列表研究中出现的“编造阈值”，确保第50个项目与第1个项目获得同等深度的分析。
系统会将一个请求拆分成多个独立的子任务，并为每个子任务启动一个完整的 Manus 实例，包括独立的虚拟机、全套工具和空的上下文窗口。所有子代理并行执行，仅通过主控制器汇总结果，彼此之间不进行通信，以避免上下文污染。
该架构随任务量的增加而线性扩展，处理50个项目与5个项目的耗时接近，同时 hallucination 率显著下降。它适用于批量文档处理、多资产创意生成、大规模数据分析等场景。该功能现已向所有订阅者开放。
以下内容来自 Manus 官方博客：《Wide Research：超越上下文窗口》
AI 驱动研究的承诺一直很有吸引力:将信息收集和综合的繁琐工作委托给智能系统,从而释放人类认知能力用于更高阶的分析和决策。然而,任何在非平凡用例上推动这些系统的人都遇到了一个令人沮丧的现实:在多主题研究任务中,到第八或第九个项目时,AI 就开始编造内容。
不仅仅是简化。不仅仅是更简洁地总结。而是编造。
这不是提示工程问题。也不是模型能力问题。这是一个架构约束,自 AI 研究工具诞生以来就悄悄限制了其实用性。而这正是 Wide Research 旨在克服的约束。
上下文窗口:一个根本性瓶颈
每个大型语言模型都在上下文窗口内运行,这是一个有限的内存缓冲区,限制了模型在任何给定时刻可以主动处理的信息量。现代模型已经令人印象深刻地推动了这一边界:从 4K tokens 到 32K、128K,甚至最新版本的 1M tokens。
然而问题依然存在。
当你要求 AI 研究多个实体——比如五十家公司、三十篇研究论文或二十个竞争产品——上下文窗口会迅速填满。不仅仅是每个实体的原始信息,还包括:
•原始任务规范和要求
•一致输出格式的结构模板
•每个项目的中间推理和分析
•交叉引用和比较笔记
•所有先前项目的累积上下文
当模型到达第八或第九个项目时,上下文窗口已经承受巨大压力。模型面临一个不可能的选择:明确失败,或开始走捷径。
它总是选择后者。
编造阈值
实践中会发生以下情况:
项目 1-5: 模型进行真实研究。它检索信息,交叉引用来源,并产生详细、准确的分析。
项目 6-8: 质量开始微妙地下降。描述变得稍微更通用。模型开始更多地依赖先前的模式而不是新鲜的研究。
项目 9+: 模型进入编造模式。无法在管理溢出的上下文的同时维持彻底研究的认知负荷,它开始基于统计模式而非实际调查生成听起来合理的内容。
这些编造内容很复杂。它们听起来很权威。它们完美地遵循既定格式。它们通常在语法上无懈可击,在风格上与早期合法条目保持一致。
它们也经常是错误的。
竞争对手分析可能会将功能归因于不提供这些功能的公司。文献综述可能会引用带有编造发现的论文。产品比较可能会捏造定价层级或规格。
阴险的部分是,这些编造内容很难在没有人工验证的情况下检测到——这违背了自动化研究的全部目的。
为什么更大的上下文窗口无法解决这个问题
直观的反应是简单地扩大上下文窗口。如果 32K tokens 不够,就使用 128K。如果还不够,就推到 1M 或更高。
这种方法误解了问题。
首先,上下文衰减不是二元的。 模型不会在其整个上下文窗口中保持完美的回忆。研究表明,检索准确性会随着与当前位置的距离而下降——即”迷失在中间”现象。上下文开头和结尾的信息比中间的信息更可靠地被回忆起来。
其次,处理成本不成比例地增长。 处理 400K token 上下文的成本不仅仅是 200K 成本的两倍——它在时间和计算资源方面呈指数级增长。这使得大规模上下文处理在许多用例中在经济上不切实际。
第三,问题在于认知负荷。 即使有无限的上下文,要求单个模型在数十个独立研究任务中保持一致的质量也会产生认知瓶颈。模型必须在项目之间不断切换上下文,维护比较框架,并确保风格一致性——同时执行核心研究任务。
第四,上下文长度压力。 模型的”耐心”在某种程度上由其训练数据中样本的长度分布决定。然而,当前语言模型的后训练数据混合仍然主要由为聊天机器人式交互设计的相对较短的轨迹主导。因此,当助手消息内容的长度超过某个阈值时,模型自然会经历一种上下文长度压力,促使它加速总结或诉诸于不完整的表达形式,如要点列表。
上下文窗口是一个约束,是的。但它是更深层架构限制的症状:单处理器、顺序范式。
架构转变:并行处理
Wide Research 代表了对 AI 系统应如何处理大规模研究任务的根本性重新思考。我们不是要求一个处理器顺序处理 n 个项目,而是部署 n 个并行子代理同时处理 n 个项目。
Wide Research 架构
当你启动 Wide Research 任务时,系统按如下方式运行:
1. 智能分解
主控制器分析你的请求并将其分解为独立的、可并行化的子任务。这涉及理解任务结构、识别依赖关系并创建连贯的子规范。
2. 子代理委托
对于每个子任务,系统启动一个专用的子代理。至关重要的是,这些不是轻量级进程——它们是功能齐全的 Manus 实例,每个都具有:
•完整的虚拟机环境
•访问完整的工具库(搜索、浏览、代码执行、文件处理)
•独立的互联网连接
Manus
全球首款通用型AI Agent，可以将你的想法转化为行动。
134 查看详情
•全新的、空的上下文窗口
3. 并行执行
所有子代理同时执行。每个子代理专注于其分配的项目,执行与单项目任务相同深度的研究和分析。
4. 集中协调
主控制器维护监督,在子代理完成工作时收集结果。重要的是,子代理之间不相互通信,所有协调都通过主控制器流动。这可以防止上下文污染并保持独立性。
5. 综合与整合
一旦所有子代理都报告完成,主控制器将结果综合成一个单一的、连贯的、全面的报告。这个综合步骤利用了主控制器的全部上下文容量,因为它没有被原始研究工作所负担。
为什么这改变了一切
规模化的一致质量
每个项目都得到相同的处理。第 50 个项目的研究与第 1 个项目一样彻底。没有退化曲线,没有编造阈值,也没有质量悬崖。
真正的水平可扩展性
需要分析 10 个项目?系统部署 10 个子代理。需要分析 500 个?它部署 500 个。架构随任务大小线性扩展,而不是像基于上下文的方法那样呈指数级扩展。
显著加速
因为子代理并行操作,分析 50 个项目所需的实际时间与分析 5 个项目大致相同。瓶颈从顺序处理时间转移到综合时间——这是整体任务中小得多的组成部分。
降低幻觉率
每个子代理都在其认知舒适区内运行。有了全新的上下文和单一的、集中的任务,就没有编造的压力。子代理可以进行真实研究、验证事实并保持准确性。
独立性和可靠性
因为子代理不共享上下文,一个子代理工作中的错误或幻觉不会传播到其他子代理。每个分析都是独立的,降低了系统性风险。
超越研究:通用并行处理引擎
虽然我们称之为”Wide Research”,但这种架构的应用远远超出了传统的研究任务。
批量文档处理
处理数千个 PDF,每个都需要 OCR、提取和分析。每个文档都有一个专用的子代理,具有完整的处理能力套件。
多资产创意生成
生成数百个独特的图像、视频或音频资产。每个资产都由专用的子代理创建,可以在没有上下文约束的情况下充分探索创意空间。
大规模数据分析
同时分析多个数据集,每个都需要不同的处理管道和分析方法。
复杂工作流分解
将复杂的多步骤流程分解为可并行化的组件,同时执行它们并综合结果。
模式是通用的:任何可以分解为独立子任务的任务都可以从这种并行执行模型中受益。
代理通信和协调
Wide Research 的有效性取决于如何在不创建新瓶颈的情况下协调子代理。
中心辐射式通信
子代理仅与主控制器通信,从不相互通信。这种中心辐射式拓扑可以防止:
•上下文污染: 一个子代理的假设或错误影响另一个子代理的工作。
•协调开销: 点对点协调中通信复杂性的几何增长。
•同步问题: 分布式系统中的竞态条件和一致性问题。
无状态子代理
每个子代理都是无状态和短暂的。它接收任务规范,执行它,返回结果,然后终止。这种设计确保:
•清晰分离: 子任务之间没有隐藏的依赖关系。
•容错性: 失败的子代理可以重新启动而不影响其他子代理。
•资源效率: 子代理按需创建,完成后立即释放。
动态扩展
系统不会预先分配固定的子代理池。它根据以下因素动态扩展:
•任务复杂性: 更复杂的子任务可能会分配额外的资源。
•系统负载: 子代理被调度以优化整体吞吐量。
•成本约束: 系统可以在指定的资源预算内运行。
对专业工作的实际影响
对于依赖 AI 进行研究和分析的专业人士来说,Wide Research 从根本上改变了可能性。
市场情报
以一致的深度分析数十或数百个竞争对手、市场细分或客户群体。不再需要手动验证后面的条目。不再怀疑 AI 是否编造了该功能比较。
学术研究
审查数百篇论文,从大量文献中综合发现。每篇论文都得到彻底的分析,而不是随着数量增长而退化的肤浅浏览。
尽职调查
并行调查多家公司、产品或机会。关键决策值得一致的分析——而不是在前几个项目后就退化的研究。
内容创作
生成大量独特的高质量内容。每件作品都得到充分的创意关注,而不是受约束上下文产生的递减回报。
超越单处理器范式
Wide Research 不仅仅是一个功能——它代表了从单处理器范式向编排的并行架构的根本转变。AI 系统的未来不在于更大的上下文窗口,而在于智能任务分解和并行执行。
我们正在从”AI 助手”时代转向”AI 劳动力”时代。
何时使用 Wide Research: 涉及多个需要一致分析的类似项目的任何任务——竞争研究、文献综述、批量处理、多资产生成。
何时不使用: 每个步骤都严重依赖于先前结果的深度顺序任务,或单处理器处理更具成本效益的小任务(少于 10 个项目)。
以上就是Manus 基于“通用并行处理引擎”解决了上下文空间瓶颈的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/316749.html
微信扫一扫 
支付宝扫一扫 
