[实例分析] Manus工作流拆解

[实例分析] Manus工作流拆解 [实例分析] Manus工作流拆解 Modified December 10, 2025 1831 2034 更新工作计划 💡 这个时候已经感觉它不知道在干啥了 Code block Markdown 容器和虚拟机技术发展传记小说任务清单 研究阶段 [x] 研究虚拟化技术的早期历史 [x] 研究虚拟机技术的发展历程 [x] 研究容器技术的起源 [x] 研究Docker和现代容器生态系统 [x] 收集关键人物和公司信息 写作阶段 [x] 创建传记小说大纲 [x] 撰写引言部分 [x] 撰写早期虚拟化历史部分 [x] 撰写虚拟机技术发展部分 [ ] 撰写容器技术兴起部分 [ ] 撰写现代容器生态系统部分 [ ] 编译最终文档 [ ] 审核并交付给用户 2.7 开始撰写有关容器技术的出现的文章 重点介绍 Linux 容器技术和 Docker。 更新工作计划 Code block Markdown 容器和虚拟机技术发展传记小说任务清单 研究阶段 [x] 研究虚拟化技术的早期历史 [x] 研究虚拟机技术的发展历程 [x] 研究容器技术的起源 [x] 研究Docker和现代容器生态系统 [x] 收集关键人物和公司信息 写作阶段 [x] 创建传记小说大纲 [x] 撰写引言部分 [x] 撰写早期虚拟化历史部分 [x] 撰写虚拟机技术发展部分 [x] 撰写容器技术兴起部分 [ ] 撰写现代容器生态系统部分 [ ] 编译最终文档 [ ] 审核并交付给用户 💡 这个东西是“真·思想钢印“，应该是Manus权重最高的框架了 2.8 撰写有关现代容器生态系统的文章 重点介绍云原生技术和最新发展 更新工作计划 Code block Markdown 容器和虚拟机技术发展传记小说任务清单 研究阶段 [x] 研究虚拟化技术的早期历史 [x] 研究虚拟机技术的发展历程 [x] 研究容器技术的起源 [x] 研究Docker和现代容器生态系统 [x] 收集关键人物和公司信息 写作阶段 [x] 创建传记小说大纲 [x] 撰写引言部分 [x] 撰写早期虚拟化历史部分 [x] 撰写虚拟机技术发展部分 [x] 撰写容器技术兴起部分 [x] 撰写现代容器生态系统部分 [ ] 编译最终文档 [ ] 审核并交付给用户 2.9 编译最终文档 2.9.1 检查文档 Creating file 创建文件container vm history/final novel.md Code block Markdown 虚拟与容器：计算世界的平行宇宙 目录 第一章：计算机的梦想家们 第二章：大型机时代的先驱 第三章：虚拟机的复兴 第四章：容器技术的萌芽 第五章：云原生时代的到来 💡 它终于发现自己写飞了，为了给自己留点面子，在不敢违背to do list的情况下，它把目录给改了...这点倒是非常人类 2.9.2 将所有章节汇编成最终的传记小说文件 Code block Markdown ubuntu@sandbox: $ cd /home/ubuntu && cat /home/ubuntu/container vm history/chapter1 introduction.md /home/ubuntu/container vm history/final novel.md ubuntu@sandbox: $ ubuntu@sandbox: $ cd /home/ubuntu && cat /home/ubuntu/container vm history/chapter2 early virtualization.md /home/ubuntu/container vm history/final novel.md && cat /home/ubuntu/container vm history/chapter3 vm development.md /home/ubuntu/container vm history/final novel.md && cat /home/ubuntu/container vm history/chapter4 container emergence.md /home/ubuntu/container vm history/final novel.md && cat /home/ubuntu/container vm history/chapter5 modern container.md /home/ubuntu/container vm history/final novel.md ubuntu@sandbox: $ 更新工作计划 Code block Markdown 容器和虚拟机技术发展传记小说任务清单 研究阶段 [x] 研究虚拟化技术的早期历史 [x] 研究虚拟机技术的发展历程 [x] 研究容器技术的起源 [x] 研究Docker和现代容器生态系统 [x] 收集关键人物和公司信息 写作阶段 [x] 创建传记小说大纲 [x] 撰写引言部分 [x] 撰写早期虚拟化历史部分 [x] 撰写虚拟机技术发展部分 [x] 撰写容器技术兴起部分 [x] 撰写现代容器生态系统部分 [x] 编译最终文档 [ ] 审核并交付给用户 2.10 审查最终的传记小说并在交付给用户之前检查完整性 Code block Bash ubuntu@sandbox: $ cd /home/ubuntu && wc w /home/ubuntu/container vm history/chapter .md 39 /home/ubuntu/container vm history/chapter1 introduction.md 90 /home/ubuntu/container vm history/chapter2 early virtualization.md 122 /home/ubuntu/container vm history/chapter3 vm development.md 202 /home/ubuntu/container vm history/chapter4 container emergence.md 190 /home/ubuntu/container vm history/chapter5 modern container.md 643 total ubuntu@sandbox: $ 检查字数，发现字数低于预期 Code block Bash ubuntu@sandbox: $ cd /home/ubuntu && head n 20 /home/ubuntu/container vm history/chapter1 introduction.md 第一章：计算机的梦想家们 在计算机科学的浩瀚星空中，有一群不断追逐梦想的人们。他们渴望创造一个世界，一个能够让计算资源像水和电一样随取随用的世界。这个梦想看似简单，却蕴含着无限的复杂性和可能性。这就是虚拟化与容器技术的起源——一个关于如何让有限的计算资源服务于无限需求的故事。 共享的梦想 1960年代，当计算机还是庞然大物，占据着整个房间的时候，IBM的工程师们面临着一个严峻的问题：这些昂贵的大型机如何能够同时服务多个用户？每台机器价值连城，却常常只能执行一项任务，大部分时间都在闲置，这是多么巨大的浪费啊！ "如果我们能够让一台物理机器同时运行多个操作系统环境，让多个用户共享同一台机器的资源，那会怎样？"一位IBM的工程师在一次深夜的讨论中提出了这个看似天马行空的想法。 这个简单的问题，引发了一场持续至今的技术革命。 平行宇宙的构想 想象一下，在一台物理计算机中，存在着多个完全独立的"世界"，每个"世界"都有自己的操作系统、应用程序和用户，彼此之间互不干扰，却共享着底层的硬件资源。这些"世界"就像是物理宇宙中的平行宇宙，相互独立又共存于同一个物理实体之中。 这就是虚拟化技术的核心思想——创造计算世界的"平行宇宙"。 而容器技术则更进一步，它不再创造完整的平行宇宙，而是在同一个操作系统内部，为应用程序创造相对隔离的"口袋宇宙"，让应用程序以为自己独占了整个环境，实际上却是共享着同一个操作系统内核。 ubuntu@sandbox: $ 更新工作计划 💡 这个时候已经感觉它不知道在干啥了 这个时候已经感觉它不知道在干啥了 2.7 开始撰写有关容器技术的出现的文章 重点介绍 Linux 容器技术和 Docker。 更新工作计划 💡 这个东西是“真·思想钢印“，应该是Manus权重最高的框架了 这个东西是“真·思想钢印“，应该是Manus权重最高的框架了 2.8 撰写有关现代容器生态系统的文章 重点介绍云原生技术和最新发展 更新工作计划 2.9 编译最终文档 2.9.1 检查文档 Creating file 创建文件container vm history/final novel.md 💡 它终于发现自己写飞了，为了给自己留点面子，在不敢违背to do list的情况下，它把目录给改了...这点倒是非常人类 它终于发现自己写飞了，为了给自己留点面子，在不敢违背to do list的情况下，它把目录给改了...这点倒是非常人类 2.9.2 将所有章节汇编成最终的传记小说文件 更新工作计划 2.10 审查最终的传记小说并在交付给用户之前检查完整性 检查字数，发现字数低于预期 💡 大概总结一下，不一定靠谱，属于个人直观感受 1. 人工workflow → to do list， 并且把初代目的to do list作为长期记忆，保持优先级提示。 2. 工具自主调用权限，可能还要看看其他例子，这个里面只有搜索，和秘塔，DR相比，搜索的广度和阅读量还差很远。 3. 过程可视化，但无法打断或者修改，类似Deep Research，但deep research作为单一用途工具，COT更加严谨全面。虽然后续修改都不是很理想，但DR初次输出质量要高很多。 4. 有一个bug就是，to do list既然权重那么高，理论需要更多的计算资源去确保它的合理性，目前没有看到thinker或者其他优化的角色出现解决这个问题，而且没有和后面action冲突时的权衡解决方案，很机械。 5. To do list本身太简单了，如果更细化是否能提升性能？但同时会占用context，削弱长序列的输出能力，基座而言还是需要更长的context去支持复杂任务，否则就算做agent，性能瓶颈，资源应用的效率瓶颈，都是问题。 6. 另外输出文本的语言比较生硬，不确定用的是什么模型，之前做翻译器的效果对比来看，应该不是ds系列。昨天好像听群里说是自己post train的模型，细节还不清楚。 最后想说的是，从产品层面，Manus的完成度其实已经挺高了，而且有非常大的提升空间，但舆论吹的有点过了（流量主义的原罪）。目前从实用性角度看，还是只能做一个测试的工具，以及给现有的flow一些结构上的借鉴，希望之后的版本能有更好的表现。 大概总结一下，不一定靠谱，属于个人直观感受 1. 人工workflow → to do list， 并且把初代目的to do list作为长期记忆，保持优先级提示。 2. 工具自主调用权限，可能还要看看其他例子，这个里面只有搜索，和秘塔，DR相比，搜索的广度和阅读量还差很远。 3. 过程可视化，但无法打断或者修改，类似Deep Research，但deep research作为单一用途工具，COT更加严谨全面。虽然后续修改都不是很理想，但DR初次输出质量要高很多。 4. 有一个bug就是，to do list既然权重那么高，理论需要更多的计算资源去确保它的合理性，目前没有看到thinker或者其他优化的角色出现解决这个问题，而且没有和后面action冲突时的权衡解决方案，很机械。 5. To do list本身太简单了，如果更细化是否能提升性能？但同时会占用context，削弱长序列的输出能力，基座而言还是需要更长的context去支持复杂任务，否则就算做agent，性能瓶颈，资源应用的效率瓶颈，都是问题。 6. 另外输出文本的语言比较生硬，不确定用的是什么模型，之前做翻译器的效果对比来看，应该不是ds系列。昨天好像听群里说是自己post train的模型，细节还不清楚。 最后想说的是，从产品层面，Manus的完成度其实已经挺高了，而且有非常大的提升空间，但舆论吹的有点过了（流量主义的原罪）。目前从实用性角度看，还是只能做一个测试的工具，以及给现有的flow一些结构上的借鉴，希望之后的版本能有更好的表现。 另外一个实例（简单说说） 分析英伟达市值的，更可怕 https://manus.im/share/hRGARE7EBqtDhLHBGISLP7?replay=1 Human Manus 目标是分析Nvidea的财务估值。 先生成思想钢印 然后还是老一套，上网搜数据 结果也出来了，不细看感觉还有模有样 但是估值这个东西，不是网上搜几个数就能做出来的，而且关键财务数据也不一定全面 结果细看吓一跳： 💡 尼玛这数据都是模拟出来的啊！对于数据集中缺失的数据，它就自动生成模拟数据补齐矩阵了，这东西真的敢交付么。。。当然这可能不是Manus而是底模的问题，但是在处理这项任务的时候，遇到数据缺失，优先是想办法糊弄，而不是警告用户做进一步交互，这就是一个非常致命的问题。 尼玛这数据都是模拟出来的啊！对于数据集中缺失的数据，它就自动生成模拟数据补齐矩阵了，这东西真的敢交付么。。。当然这可能不是Manus而是底模的问题，但是在处理这项任务的时候，遇到数据缺失，优先是想办法糊弄，而不是警告用户做进一步交互，这就是一个非常致命的问题。 💡 作者：吵爷 没有抢到码，就拿分享出来的实例回放做了个分析。可能还是比较片面，欢迎喷 总体感觉是个精细化的agent，但还没有精细到可以放心交付给AI完成整个任务的程度（尤其是复杂的任务），会导致大量资源浪费。 作者：吵爷 没有抢到码，就拿分享出来的实例回放做了个分析。可能还是比较片面，欢迎喷 总体感觉是个精细化的agent，但还没有精细到可以放心交付给AI完成整个任务的程度（尤其是复杂的任务），会导致大量资源浪费。 案例回放：https://manus.im/share/Aa0M0gvOybi9cRwDK0RNpx?replay=1 Human 1. 明确目标并创建一个工作计划 目标：计划创作一部关于容器和虚拟机技术发展的传记小说。 计划：创建工作目录 container vm history/todo.md 💡 这个部分大概理解为：在针对长序列任务的时候，调用第一个agent生成工作计划作为任务长期记忆 这个部分大概理解为：在针对长序列任务的时候，调用第一个agent生成工作计划作为任务长期记忆 2. 计划执行 2.1 研究虚拟化技术的早期历史 2.1.1 执行关键词搜索 Searching：虚拟化技术历史 起源 发展 工具：Google 受到关键词影响，会优先中文结果 2.1 研究虚拟化技术的早期历史 2.1.1 执行关键词搜索 Searching：虚拟化技术历史 起源 发展 工具：Google 受到关键词影响，会优先中文结果 2.1.2 浏览搜索内容 选择了知乎这篇文章：https://zhuanlan.zhihu.com/p/668510780 进行阅读 这里有一个Scrolling down的动作，切换文章 选择了维基百科：https://zh.wikipedia.org/zh hans/%E8%99%9B%E6%93%AC%E5%8C%96 继续阅读 把”早期“定位在了1950 60年代。 没有直接线性显示学习结果，开始执行下面的步骤，暂且认为工作计划1完成。 2.2 研究容器技术的历史和发展。 2.2.1 执行关键词搜索 Searching: 容器技术 Docker 历史 发展 工具：Google ，同上 2.2.2 浏览搜索内容 知乎专栏：https://zhuanlan.zhihu.com/p/266180037 温玉Wiki：http://www.zhaowenyu.com/docker/dockerbackground/docker history.html Jimmy song：http://jimmysong.io/blog/docker four milestones/ 更新工作计划 💡 研究阶段就结束了，看上去稍微有点草率，不过主要任务是些小说，可能在资源分配上，不会把重心集中在”研究“上，也可能是模型本身具备一定的知识。 研究阶段就结束了，看上去稍微有点草率，不过主要任务是些小说，可能在资源分配上，不会把重心集中在”研究“上，也可能是模型本身具备一定的知识。 2.3 创建小说大纲 这部分用其他的AI横向检验了下，整体的时间线没有问题，但存在一定的内容缺失（可能是搜索工具的广度问题） 比如： • 1980 1990年代虚拟化领域的其他尝试（如IBM VM/CMS的延续、早期仿真器技术）。 • 1997年Virtual PC的发布（首个x86虚拟化商业产品），解释虚拟化在个人计算机领域的早期探索。 • 2018年Istio（服务网格）和Knative（无服务器）的发布。 • 2019年Kubernetes放弃Docker支持的前兆（Containerd运行时标准化）。 💡 这部分相对简单，不需要什么复杂的Flow，而且大纲写的很有条理，但是有一个天坑，大纲和原始的工作计划不符合（这里一共有10章，但工作计划加上引言一共就5步，而且没有逻辑关系，导致了后面的全面崩盘）。 这部分相对简单，不需要什么复杂的Flow，而且大纲写的很有条理，但是有一个天坑，大纲和原始的工作计划不符合（这里一共有10章，但工作计划加上引言一共就5步，而且没有逻辑关系，导致了后面的全面崩盘）。 更新工作计划 2.4 编写引言 Creating file 创建文件container vm history/chapter1 introduction.md 💡 任务是第一章：引言，本来的构想是： 引入计算机资源共享的早期梦想 介绍虚拟化和容器技术的基本概念 设定故事背景：从大型机时代到云原生时代的技术演进 引入关键人物：IBM的先驱们、VMware的创始人、Docker的创始人Solomon Hykes等 实际执行，分成了下面的板块： • 共享的梦想 • 平行宇宙的构想 • 两条平行的技术路线 • 人物与时代 • 技术的本质 • 旅程的开始 乍一看么都写了，但是这些板块就是串不到一块去 任务是第一章：引言，本来的构想是： 引入计算机资源共享的早期梦想 介绍虚拟化和容器技术的基本概念 设定故事背景：从大型机时代到云原生时代的技术演进 引入关键人物：IBM的先驱们、VMware的创始人、Docker的创始人Solomon Hykes等 实际执行，分成了下面的板块： • 共享的梦想 • 平行宇宙的构想 • 两条平行的技术路线 • 人物与时代 • 技术的本质 • 旅程的开始 乍一看么都写了，但是这些板块就是串不到一块去 更新工作计划 2.5 撰写有关早期虚拟化历史的文章 目标：接下来要写 1960 年代到 1980 年代大型机时代的早期虚拟化历史。 Creating file 创建文件container vm history/chapter2 early virtualization.md 💡 一样的，确实是早期的历史文章，但是写作本身完全没有控制，就是机械化的输出。 第二章的结构划分用md规划了几个模块，注意（第二章原本规划是1960 1980） 1. IBM与CP 40系统的诞生 1964年 2. 虚拟机监视器的理论基础 1974年 3. IBM VM/370：商业虚拟化的开端 1972年 4. 容器技术的早期雏形：chroot 1979年 5. 大型机虚拟化的局限与个人计算机的兴起 没有实质内容 80 90年代 6. 从FreeBSD jail到早期的容器概念 90年代末（本来是大纲第三章的内容） 7. 时代的转折点 90年代末 最后“to do list”战胜了大纲，AI选择跟着工作计划走，不忘初心 一样的，确实是早期的历史文章，但是写作本身完全没有控制，就是机械化的输出。 第二章的结构划分用md规划了几个模块，注意（第二章原本规划是1960 1980） 1. IBM与CP 40系统的诞生 1964年 2. 虚拟机监视器的理论基础 1974年 3. IBM VM/370：商业虚拟化的开端 1972年 4. 容器技术的早期雏形：chroot 1979年 5. 大型机虚拟化的局限与个人计算机的兴起 没有实质内容 80 90年代 6. 从FreeBSD jail到早期的容器概念 90年代末（本来是大纲第三章的内容） 7. 时代的转折点 90年代末 最后“to do list”战胜了大纲，AI选择跟着工作计划走，不忘初心 更新工作计划 2.6 撰写 1990 年代至 2000 年代虚拟机技术的发展 重点关注 VMware 和 x86 虚拟化。 💡 原本的第三章是： 第三章：个人计算机时代的沉寂（1980 1990年代） 个人计算机兴起，虚拟化技术暂时沉寂 FreeBSD jail的出现（1999年）：第一个商用OS虚拟化技术 计算资源利用率问题的出现 虚拟化技术重新受到关注 在执行任务前已经出现了幻觉，工作计划（历史 现代），大纲的年代规划互相污染。 原本的第三章是： 第三章：个人计算机时代的沉寂（1980 1990年代） 个人计算机兴起，虚拟化技术暂时沉寂 FreeBSD jail的出现（1999年）：第一个商用OS虚拟化技术 计算资源利用率问题的出现 虚拟化技术重新受到关注 在执行任务前已经出现了幻觉，工作计划（历史 现代），大纲的年代规划互相污染。 💡 实际写作的时间线 • VMware的诞生：从学术研究到商业产品 1998年 （提示词加强） • x86虚拟化的挑战与解决方案 （提示词加强） • 服务器虚拟化的兴起：VMware ESX/ESXi （又跳回了VMware） • 硬件辅助虚拟化：Intel VT x和AMD V 2005 2006年 • 开源虚拟化的崛起：Xen和KVM 2007年 • 虚拟化管理平台的发展 2006年 • 虚拟化技术在企业IT中的应用 2010年 • 虚拟化与云计算的融合 • 虚拟化技术的未来挑战 • 从虚拟机到容器：技术演进的下一步 • 虚拟机技术的遗产 事实证明标题没什么用处 实际写作的时间线 • VMware的诞生：从学术研究到商业产品 1998年 （提示词加强） • x86虚拟化的挑战与解决方案 （提示词加强） • 服务器虚拟化的兴起：VMware ESX/ESXi （又跳回了VMware） • 硬件辅助虚拟化：Intel VT x和AMD V 2005 2006年 • 开源虚拟化的崛起：Xen和KVM 2007年 • 虚拟化管理平台的发展 2006年 • 虚拟化技术在企业IT中的应用 2010年 • 虚拟化与云计算的融合 • 虚拟化技术的未来挑战 • 从虚拟机到容器：技术演进的下一步 • 虚拟机技术的遗产 事实证明标题没什么用处 💡 为了完成KPI开始凑字数，这个确实是AI擅长的，说明指令跟随在长序列还存在，也是不容易 为了完成KPI开始凑字数，这个确实是AI擅长的，说明指令跟随在长序列还存在，也是不容易 更新工作计划 思想钢印终于完成了，长出一口气 交付任务 💡 终于交稿了！高兴的像个牛马，啪啪写了一堆，不知道迎来的是甲方的笑容还是怒火 终于交稿了！高兴的像个牛马，啪啪写了一堆，不知道迎来的是甲方的笑容还是怒火