拆解Manus:真正有用的深度报告的生成

标签: manus 深度 报告 | 发表时间:2026-01-01 00:00 | 作者:
出处:https://colobu.com/

真正的深度研究报告不是让 AI "写"出来的,而是"研究"出来的。这两个字差别大了。

最近几个月,几个产品让我眼前一亮:Gemini Deep Research、Manus Wide Research,还有 OpenAI 的 Deep Research。它们都在做同一件事——让 AI 具备真正的"研究能力"。

这事儿得从"上下文窗口陷阱"说起。

一、上下文窗口陷阱

01-一、上下文窗口陷阱

传统 AI 助手有个致命问题。

让它分析 5 个产品?没问题,每个都能给出详尽分析。

分析 10 个?开始有点吃力,后面的描述明显变短。

分析 30 个?基本崩了,只能给些通用摘要,错误率飙升。

这不是模型变笨了,是上下文窗口被撑爆了。AI 必须把前面所有项目都记在内存里,越往后,早期信息被压缩得越厉害,最后就剩个轮廓。

研究显示,大多数 AI 系统的"幻觉阈值"大概在 8-10 个项目左右。超过这个数,质量断崖式下跌。

这就是为什么那些所谓的"深度研究" agent,给你列 50 篇论文,结果后面 30 篇都是胡编乱造。

二、两条路线

02-二、两条路线

业界现在有两条路线解决这个问题。

路线一:把模型做强

代表是 Google 的 Gemini Deep Research。2025 年搞了两次大升级——4 月上了 Gemini 2.5 Pro,12 月又升级到 Gemini 3 Pro。核心思路就是用更大的上下文窗口、更强的推理能力,硬抗复杂任务。

它适合那种需要深度推理、跨多个来源综合分析的任务。比如研究一个技术趋势的演进,需要把几十篇论文、新闻、博客揉在一起,找出脉络。

路线二:把架构做巧

代表是 Manus 的 Wide Research。它不跟你比谁的上下文窗口大,而是直接换个架构——不用一个 Agent 干所有事,而是搞几百个 Agent 并行干活。

每个 Agent 只负责一个项目,有自己独立的上下文窗口。主 Agent 负责拆解任务、分配工作、最后汇总结果。

这就像写研究报告。原来是一个人憋大招,现在是一个导师带几十个研究生,每人负责一篇文献,最后导师综合。

所以Manus把它的研究项目叫做宽度搜索 (wide research)。

三、实战对比:风电行业投资研究

03-三、实战对比:风电行业投资研究

拿"风电行业股票的投资研究"这个任务来说,两种方案差异明显。

Gemini Deep Research:深度推理派

丢给 Gemini 一个复杂问题,它会:

① 先理解任务,规划研究策略
可以看到,Gemini一开始先制定研究方案,把搜索计划拆解成 7 个方向,针对每个方向,进行深度的分析。
而且它在开始的允许你修改研究方案,提供 human-in-the-loop 的机制,允引入人工干预的过程。

② 多轮搜索,找权威来源——行业报告、公司财报、政策文件、学术论文
这其实是谷歌的优势,它是搜索引擎起家,有着无与伦比的搜索数据优势,而且时效性也非常的高,所以它更有资源去做这个事情,其实百度也非常的合适做这个。所以它搜索的质量也是非常高的,搜索出来的网页的权重都挺高,权威性好。

边搜索边分析,不断调整方向
从上图可以看出,它也是边搜索边思考,对搜索方向进行适当的调整,围绕着计划进行有目的的搜索。

④ 综合所有信息,写出有逻辑的报告
最终,整合所有的报告,输出一份完整的报告结果。

整个过程可能要跑十几分钟。 但它给出的不是简单的信息拼凑,而是有洞察的分析

优点是推理能力强,能发现隐含的关联。比如它会注意到某个政策变化对上游设备商和下游运营商的不同影响,这是普通搜索做不到的。

缺点是,如果任务涉及大量独立对象(比如分析 50 家风电公司),还是会遇到上下文瓶颈。

Manus Wide Research:并行执行派

同样的任务,如果是"分析 50 家风电上市公司",Manus 的做法完全不同。

第一步,任务拆解。

主 Agent 会把"分析 50 家公司"这个大任务,拆成 50 个独立的小任务。每个小任务包含:公司名称、需要收集的信息字段(财务数据、业务布局、风险因素等)、评估标准。

第二步,并行启动。

50 个子 Agent 同时启动,每个只研究一家公司。关键在于——它们不是轮流干活,而是真正并行。就像 50 个研究员同时开工,互不干扰。

第三步,独立执行。

每个子 Agent 在自己的沙箱环境里跑完整的调研流程:搜索公司信息、读财报、查新闻、整理数据。因为每个 Agent 有独立的上下文窗口,第 50 个公司和第 1 个公司获得的分析深度完全一致。

第四步,结果汇总。

主 Agent 收集所有子任务的结果,整理成结构化输出——表格、报告、或者数据库。

这个方案的巧妙之处在于 规避了上下文窗口问题

传统方式是一个 Agent 处理所有任务,越往后上下文越拥挤,质量必然下降。而 Manus 的方式是每个 Agent 都从零开始,大家都是"满血"状态,不存在谁挤占谁的问题。

官方有个案例——研究 250 位 AI 研究员。

第 1 位到第 250 位,每位的详细程度都一样:完整的背景、研究方向、代表作、核心论文。这换成传统 AI 根本做不到——早就因为上下文爆炸而开始胡编乱造了。

技术实现细节

剥开产品外壳,Manus 的架构其实挺讲究的。核心思想来自一篇叫《CodeAct》的论文:让 AI 像程序员一样工作——写代码、运行代码、看结果、改代码、再运行。

ReAct 模式

每个 Agent 的执行逻辑是一个循环:观察(Observation)→ 思考(Thought)→ 行动(Action)→ 观察...不断迭代,直到任务完成。

这不是简单的"调用工具",而是边思考边行动。搜索结果不相关?换关键词。代码执行报错?检查原因、修改命令、重试。

     
1
2
3
     
┌─────────────────────────────────────────────┐
│ 观察 → 思考 → 行动 → 观察 → 思考 → 行动... │
└─────────────────────────────────────────────┘

沙箱隔离

每个 Agent 跑在独立的虚拟机环境里。这不是多线程,而是真正的隔离——独立的文件系统、独立的网络、独立的进程空间。

Manus 用了沙箱技术,这样就算某个 Agent 被诱导执行了危险命令,也影响不到其他 Agent 和宿主系统。

任务分解:DAG 结构

主 Agent 把复杂任务拆成有向无环图(DAG)。清楚知道哪些步骤可以并行,哪些必须等前置条件。

比如"研究 50 家风电公司"的执行图:

     
1
2
3
4
5
6
7
8
9
10
     
[主 Agent:任务分解]
┌─────────┬─────────┼─────────┬─────────┐
↓ ↓ ↓ ↓ ↓
[Agent 1] [Agent 2] [Agent 3] ... [Agent 50]
研究公司1 研究公司2 研究公司3 研究公司50
↓ ↓ ↓ ↓ ↓
└─────────┴─────────┴─────────┴─────────┘
[主 Agent:结果汇总]

工具集

Manus 提供了 29 种工具,分成几类:

类别 工具示例 用途
命令执行 Shell、Python 执行任意代码和系统命令
文件操作 读写 txt/md/pdf/xlsx 处理各种格式的文档
网络能力 搜索、浏览器、端口部署 获取信息、部署服务
系统能力 进程管理、软件安装 配置运行环境

这些工具让 Agent 能真正"动手做事",而不是只会生成文本。比如研究一家公司,它可以:搜索公司官网、爬取财报数据、用 Python 分析财务指标、把结果写入表格。

动态质量检测

Manus 不是按预设流程走到黑。每次执行完一个步骤,都会判断:结果可信吗?需要调整方向吗?

     
1
2
3
4
     
def quality_check(result):
if result.confidence < 0.7:
trigger_self_correction()
return generate_validation_report()

代码执行报错?调整命令重试。搜索结果太少?换搜索引擎或关键词。这种自我纠错能力,让它在遇到问题时不会死磕,而是会寻找替代方案。

状态管理

每个任务维护一个 todo.md 文件,实时更新进度:

     
1
2
3
4
5
6
7
8
9
10
11
     
# TODO
![cover](cover.png)
![cover](cover.png)
- [x] 收集公司列表
- [x] 研究前 10 家公司
- [ ] 研究中 30 家公司
- [ ] 研究后 10 家公司
- [ ] 汇总分析报告

这样做的好处是:任务中断后可以恢复;用户随时能看到进展;中间结果有地方存储,不会丢失。

当然这些分析都是我们基于Manus的产品、宣传资料和外部人员的分析做的推测,我们实际并不知道Manus内部的方案。仅供分析和学习。

四、真正的"研究"是什么?

看这些产品,我发现一个有趣的共通点:它们都在模仿人类研究员的工作方式。

人类研究员怎么做深度报告?

  • 首先规划:这个问题要从哪些角度分析?需要哪些数据?
  • 然后执行:找数据、读文献、做访谈、整理信息。
  • 最后综合:把零散的信息组织成有逻辑的故事。

关键在于,这不是一次性能完成的。 需要反复迭代——查了资料发现方向不对,得换方向;分析到一半发现缺数据,得补数据。

传统的 LLM chat 模式,本质上是一次性生成。给你个 prompt,你吐出结果。这是"写作",不是"研究"。

真正的深度研究 agent,应该具备:

① 规划能力:能理解任务,制定研究策略,知道先查什么后查什么。

② 工具能力:会用搜索引擎、读数据库、解析文档,不只是从训练数据里抠信息。

③ 迭代能力:能根据中间结果调整方向,不是按预定流程走到黑。

④ 验证能力:能交叉验证信息来源,不是捡到什么信什么。

⑤ 综合能力:能把碎片信息拼成完整故事,不是简单的信息罗列。

Gemini Deep Research 和 Manus Wide Research,本质上都是在往这个方向努力。只是侧重点不同——前者重"深",后者重"广"。

五、一些思考

05-五、一些思考

深度研究报告的生成,本质上是在解决 AI 的两个核心问题: 知识获取复杂推理

传统的做法是把知识"压缩"进模型参数里,但这有天花板——模型总有训练截止日期,总有不知道的东西。

新的方向是给 AI 装上"工具",让它能动态获取信息、多步推理、自我纠错。这更像人类的智能——我们不是什么都知道,但知道怎么去查、怎么去思考。

Deep Research 这类产品,标志着 AI 从"聊天机器人"向"研究助手"的转变。它们不只是在陪你闲聊,而是能真正帮你干活。

当然,问题还很多。幻觉、偏见、安全风险,一个都没解决。但方向是对的。

Insight: 我们的深度研究工具

06-Insight: 我们的深度研究工具

06-Insight: 我们的深度研究工具

基于上面对这些产品的分析,结合对智能体 20 余中架构模式的研究,针对深度研究报告这个场景,我们研发了Insight平台,展示了要实现高质量的深度研究报告所设计的技术和套路,并提供了独有的一些方法。

接下来我介绍这个产品的重要的结束。在这之前,我先给大家展示一下效果。

Insight平台地址: https://insight.rpcx.io
一个网友的报告: https://insight.rpcx.io/reports/e25061cd-b936-470d-b5ed-3998b2d7452e

高质量的资料源

就像研究员一样,要想生成高质量的报告,必须要有高质量的数据源作为基础。

如上面提到过的,这方面搜索引擎具有优势,他们拥有全面性,时效性高的搜索资料。

一些专业的网站也有行业方面的专业资料,比如金融领域相关的,IT技术相关的、白酒方面相关的
电商方面相关的,旅游行业相关的、出行方面相关的、法律行业相关的,科普方面相关的,他们能够提供垂类专业的资料,如果要生成这方面的报告,找这些行业相关的网站信息是最好的。当然如果这些资料是公开的,可以通过搜索因为+专业的搜索词进行搜索获取,所以搜索引擎的重要性在AI的深度调研报告生成中占很重要的地位。

但是搜索引擎并不轻易把它的能力无偿的暴露出来,比如谷歌,它提供付费的搜索API,价格不低。Bing已经把它的搜索API下掉了。还有一些第三方的服务,或许是通过爬虫的方式进行搜索,比如Travily、Brave、SerpAPI等,也提供收费的服务。总的来说,好东西都是有价格的。这些搜索引擎增加了反爬虫的机制,我几个月前还能绕过这些限制,现在也不行了,他们都很聪明,不会轻易让你免费使用的。

从 Manus网站的输出来看,我怀疑它们买了某个或者某几个服务器服务商的服务,可以针对用户的请求,得到搜索引擎的列表 (SERP), 这是猜测,前端并看不出来,因为它们并不可能去做个搜索引擎。专业的人做专业的事。它们拿到搜索结果列表后,通过它们的AI浏览器,也就是虚拟机的浏览器去浏览网络,获取网页的内容。它们叫 cloud browser,应该是基于browserbase开发的。沙盒技术和Browser我放在下一个拆解文章中在再专门介绍,这一篇还是专门关注调研报告的实现。

识别用户的意图

专业的用户会提供详细的、简洁的、对 AI 友好的提示词,但是大部分用户并不能很好的表达自己的意图,比如:

请帮我分析Apple的市场行情

这里的Apple指的是苹果电脑公司还是水果苹果呢?非常有歧义。还有的提示词含糊不清。在Insight的实现在,我们首先实现的就是对用户的提示词进行澄清。理论上对于非常模糊的提示词,比如Apple这里例子,我们需要进一步询问用户,反问用户的意图,但是Insight还没进一步的实现这个功能,而是自动进行澄清,它是怎么实现的呢?

生成报告大纲

接下来专门有个agent( StructurePlannerNode)负责生成报告的节点,主要确定报告的主要大纲和方向。

区分报告的种类进行规划搜索任务

接下来针对报告的大纲, Planner Agent针对金融投资领域、技术开发领域、商业分析领域、政策相关领域、通用领域等各种领域制定搜索计划,为每个章节搜索足够的信息备用。

执行搜索

Search Agent 会根据搜索计划,逐步实现相关内容的搜索。

它会根据项目提供的工具,进行搜索。目前提供了travily、github、谷歌学术、知乎、微信公众号等网站的搜索,我其实还是期望能直接搜索google的搜索结果和一些顶级的专业网站的搜索内容。

搜索的结果内容如果太长,还会对它们进行summary,以便压缩上下文。

此节点还会针对每个章节进行内容的总结。

现在万事俱备了,所有的大纲和材料都准备好了,可以进行报告的编写了。有请 ContentWriter Agent。

内容的编写

ContentWriter 负责报告的编写,它根据大纲和材料进行内容的创作。

说起创作来,针对内容创作的场景,我们为了提高创作产品的质量,经常采用Reflection模式,针对生成的内容进行打分,要不要进行优化。

所以这个Agent生成后,会调用Reflector Agent进行打分,以便决定要不要调用Revisor节点进行订正。你看报告生成的日志也能观察到这一点。

除非生成的报告片段达到了“优”的级别,否则就会尝试补充和订正,直到达到了 5 轮的反复订正才算通过。

所以你会看到Insight生成的报告的质量还是很高的,不像一个玩具或者示例deep research产品的报告那么简略或者偏离主题。

Reportor Agent

最后这个Agent把各个章节合在一起,生成一个完整的markdown的报告。

会生成合理的章节,并进行编号。

另外还有的Podcast Agent,可以生成播客的脚本。如果用户请求中要求生成播客,那么此Agent就会自动生成。

工作流程

完整的工作流 (graph)如下:

工程开发

07-工程开发
本产品开发过程中很多资源花费了工程产品化方面,尤其是前端的生成和优化。

实现框架

08-实现框架

本产品使用 https://github.com/smallnest/langgraphgo 实现。 Go 语言实现。

使用 CC 辅助代码生成。

使用 GLM 4.7 作为后端模型。

本产品演示网站: https://insight.rpcx.io

对后端代码感兴趣的可以加我微信 smallnest 。我拉你进《智能体研究社》,讨论智能体的开发和vibe coding。

未来计划

09-未来计划

报告中缺乏图表,可以加强数据的采集和图表的展示。

报告中缺乏图片的润色,网上搜索的图片经常文不对题,不过我已经有方案了。


参考资料:

相关 [manus 深度 报告] 推荐:

拆解Manus:真正有用的深度报告的生成

- - 鸟窝
真正的深度研究报告不是让 AI "写"出来的,而是"研究"出来的. 最近几个月,几个产品让我眼前一亮:Gemini Deep Research、Manus Wide Research,还有 OpenAI 的 Deep Research. 它们都在做同一件事——让 AI 具备真正的"研究能力". 这事儿得从"上下文窗口陷阱"说起.

纽约时报记者深度体验 Google 眼镜之报告

- - 谷奥——探寻谷歌的奥秘
纽约时报的记者David Pogue今天发表长篇博文,全面的介绍了自己使用Google眼镜的体验( 视频我们前几天发过). 他称这是一个全新的科技玩意系列,也许iPhone可以称得上是最近出现的这样一个新科技玩意,iPad可能也能算一个,那么Google眼镜显然也是了. David拿到的这个显然还是原型机,其名字被称为Google Glass,而非Glasses(眼镜要用复数嘛初中老师千叮咛万嘱咐的形象又回荡在我的脑海里),是因为它没有任何镜片,但它让你看上去就戴着是一个只有一边带镜片的眼镜──在右侧眉毛那里有一个明显的“镜框”,它是一个很小的透明的小块儿──其实就是个屏幕.

深度搜索

- - 译言最新精选
译者: HorseHour 原文地址: streamhacker.com. 当我们准备发布 Weotta时,我们已经为如何描述它犯了难. 我们使用了机器学习和自然语言处理吗. 我们最终觉得“深度搜索”是对我们工作最贴切的描述,它是一个超越了基本文本搜索的复杂搜索系统的简洁描述. 无需赘言,不管怎么看,我们都不是这个领域唯一的一家公司;谷歌和很多其他公司都在对深度搜索的各个方面进行研究.

Cookie深度解析

- - CSDN博客互联网推荐文章
       最近在公司做了Web端单点登录(SSO)功能,基于Cookie实现,做完之后感觉有必要总结一下,本文着重讲解Cookie,下文会说明单点登录的实现方案.        众所周知,Web协议(也就是HTTP)是一个无状态的协议. 一个Web应用由很多个Web页面组成,每个页面都有唯一的URL来定义.

Kafka深度解析

- - zzm
原创文章,转载请务必将下面这段话置于文章开头处. 本文转发自Jason’s Blog,原文链接. http://www.jasongj.com/2015/01/02/Kafka深度解析. Kafka是一种分布式的,基于发布/订阅的消息系统. 以时间复杂度为O(1)的方式提供消息持久化能力,即使对TB级以上数据也能保证常数时间的访问性能.

Google+统计报告

- pestwave - 36氪
Google+推出有一段时间了,用户性别比例如何呢. find people on plus对947996名Google+用户进行了统计,按照性别、地理位置、职位进行了分类,甚至还对来自Facebook和Google的员工进行了统计. 男:698,703 (73.70%). 女:234,504 (24.74%).

impala测试报告

- - 开源软件 - ITeye博客
10.200.187.86 cslave1 4核 3G. 10.200.187.87 cslave2 2核 4G. 10.200.187.88 cslave3 2核 4G. 10.200.187.89 cslave4 2核 6G. 1.在内存够用并且是简单sql条件下,impala相比hive执行效率高很多,简单的sql在百万级别数据中运行,耗时几秒甚至不用一秒.

HBase性能深度分析

- Rubby - 《程序员》杂志官网
HBase作为BigTable的一个开源实现,随着其应用的普及,用户对它的性能数据愈发关注. 本文将为您揭开HBase性能测试的一角,邀您一起参与到对云计算模块性能调优的深度思考中. 对于BigTable类型的分布式数据库应用来说,用户往往会对其性能状况有极大的兴趣,这其中又对实时数据插入性能更为关注.

[转][转]ZeroMQ 深度探索

- - heiyeluren的blog(黑夜路人的开源世界)
最初认识 ZeroMQ 是被它的名号所吸引,最近在一个高性能中间件的项目中用到了 ZeroMQ,对这个号称“史上最快的消息队列”有了更深层次的了解. 如果我们仅仅把 ZeroMQ 看作是一个消息队列,那就完全搞错了,ZeroMQ 是一套智能传输层协议,它不仅为开发者提供了强大的开发包,还包含了一套很棒的通信协议的实现,更值得一提是,它对分布式系统开发有着相当独到的见解,绝对值得我们好好学习.

HashMap深度解析(一)

- - CSDN博客编程语言推荐文章
       HashMap可以说是Java中最常用的集合类框架之一,是Java语言中非常典型的数据结构,我们总会在不经意间用到它,很大程度上方便了我们日常开发. 在很多Java的笔试题中也会被问到,最常见的,“HashMap和HashTable有什么区别. ”,这也不是三言两语能说清楚的,这种笔试题就是考察你来笔试之前有没有复习功课,随便来个快餐式的复习就能给出简单的答案.