以 manus 为例，拆解以 multi-agent 为基础的通用任务智能体的工作流程：

一. 意图识别

1. 获取用户输入内容，进行必要的意图识别和关键词提取，比如用户输入的是“想去日本旅游，需要一个旅行计划”，拆解之后得到的关键词是： japan-trip，任务类型为：travel

2. 如果用户输入的需求比较简单，不能识别用户的意图，此步骤可以引导用户继续对话，补充更多的信息，或者上传文档 / 图片等资料

二. 任务初始化

1. 用识别出来的任务关键词创建任务文件夹，启动 docker 容器，为后续的任务执行做环境隔离

2. 任务执行过程中的内容产物，写入到任务文件夹，任务结束之后清理 docker 容器

三. 步骤规划

1. 使用意图识别的结果 + 补充背景信息，请求一个推理模型，对任务进行步骤拆分

2. 将任务拆分的步骤信息，写入到任务文件夹的 todo.md

四. 任务执行

1. 遍历任务文件夹中的 todo.md，[ ] 表示待执行的任务，[x] 表示已执行的任务

2. 取出待执行的任务，带上任务上下文信息，做一次 function call，这里带上的 function tools 是系统内置的可以执行不同任务的 agent，比如 search agent / code agent / data-analysis agent

3. 根据 function call 的结果，调度指定的 agent 执行任务，把执行过程中产生的内容，写入到容器中的任务文件夹

4. 任务执行完，由主线程，更新 todo.md，继续下一个任务

五. 归纳整理

1. todo.md 里面的任务全部执行完之后，主线程针对用户的初始需求，做一次整理输出

2. 把任务的内容产物，给到用户浏览或下载（文档 / 代码 / 图片 / 链接等）

3. 收集用户对任务的满意度

----

整个方案理下来，核心在于执行任务的 agent 设计，以及主线程的调度流程，以 search agent 为例，在处理“日本旅行计划”这个任务中，主要的执行步骤：

1. 拿到 japan-trip 等关键词信息，调用谷歌第三方 API，获取 10-20 条搜索结果

2. 模拟浏览器点开第一个网页，浏览网页内容，获取网页文本内容 + 浏览器截图拿到网页视觉信息

3. 调用支持多模态输入的模型，输入当前任务要求，从当前浏览的网页中提取有效信息（是否有符合要求的结果，如果不满足要求，返回下一个该点击的 button 元素）

4. 模拟浏览器点击 + 网页滚动行为，拿到更多的网页内容 + 视觉信息，重复几次，直到收集到的内容满足任务要求为止

5. 把收集到的内容保存到任务文件夹

这个 search agent 的核心在于模拟用户浏览网页行为，需要用到无头浏览器和多模态模型。

code agent 和 data-analysis agent 相对而言比较简单：

1. 根据任务需求，创建本地文件，写入代码（python 代码做数据分析，html 代码做视觉呈现）

2. 通过系统调用执行代码，把执行结果保存到任务文件夹

3. 通过 code-preview 服务，预览 html 文件的内容

---

此类 multi-agent 产品，还有一些改进的空间：

1. todo.md 的多个任务，是线性依赖关系，可以使用 DAG（有向无环图）实现更加复杂的任务依赖

2. 需要引入自动化测试 agent，对任务结果进行判断和矫正，如果对某个步骤评分过低，需要回溯到之前的某个任务节点重新执行

3. 允许全自动 + 用户介入的混合模式，在某个步骤执行完，先寻求用户反馈，如果几秒内没收到反馈，则自动继续运行

---

整体评价：manus 在工程层面做了很多工作，整体交互比其他产品好很多。技术层面，依然是没什么壁垒，对模型有比较深的依赖：

1. 也许有个小模型，做任务执行前的意图识别

2. 任务规划和推理，用 deepseek-r1

3. 图片识别 + 代码生成，用 claude-3.7-sonnet

token 消耗会很高，能不能广泛用起来，取决于谁来负担这个成本。

最终的任务准确性和用户满意度，还需要更多的案例来说明。

从我的视角上，Manus就是monica这家公司在抓机会能力上的最好体现，但这么解读monica太浅薄了，因为他们工程实践和agent workflow的积累是实实在在的，我参与到的就有23年9-10月首次在国内推出agent，这里面的todolist.md都是当时学习了各家agent方案之后的最佳实践，再到24年3月做gpts平台，24年初开始一直就在做浏览器的技术积累，积累大量对浏览器context利用的理解，23年11月开始做搜索，对于agent联网获取信息的能力也是有积累的。我没参与的部分，24年7月份通过roast获取社交流量的增长经验，24年11月coding产品中对于各模型coding能力的理解。确实每件事都是相对薄的一层，但这些积木在这个窗口形成的组合创新足够强也是事实。但也就是他们可能既有认知又有足够的工程能力在这个小窗口实现空袭。我觉得最恰当的例子可能是拼多多是一个如果没有黄峥team，有可能不会诞生的产品，因为阿里的怠惰，因为微信流量的窗口，因为团队的累积和努力。

我有朋友去 Manus上班了。
他告诉我，其实 Manus agent已经内测了。
真的非常强大吊打deepseek。
现在分享给你们：
KFC-CRAZY-THURSDAY-VWO50

昨天manus刷屏了，我没有“蹭”到这波流量，为什么？简单说几个原因和观点：
1.没有用到有效内测码，对于没有亲自用过的产品，没有判断依据。
2.从宣发看：产品定位存在矛盾（中国团队打造但全英文界面且需海外登录方式）
3.从某些号的实测过程和结果看：像是现有技术的组合与整合（Computer Use、虚拟机、Agent等）
当然，技术集成好的产品也是一种创新，类似之前小米系产品直接点，就是调用多模型的能力+多工具融合+RPA能力封装出一个很强大一次性处理很多任务的大号Agent。

讲人话，假设之前设计出的大多数Agent是一个一个研发团队的产品经理，大概率处理是负责产品经理的活。
那么manus 这个Agent就是整个研发团队，从产品，设计，后台开发，架构，前端实现干的活都能干。
再比如，之前的Agent是招聘HR或者其他板块HR，那么manus 扮演整个HR部门加面试官。
完成任务时间很长，算力成本必然很高，产品定价是关键，比如一个月1500使用100次，我应该是不会买。

不如我自己设计多个Agent的ROI结论：
manus谈不上颠覆，也比肩不了deepseekdeepseek全民皆可用，不用理解提示词，普通用户也可以回复满意结果。成本低，目前基本免费。

1.manus不可能免费。
2.manus对于懂业务场景的人是一大神器，懂业务，有业务场景，能变现，考虑无非是  ROI问题。

3.manus团队的研发能力，本质是对工程技术能力和对各模型能力深度了解体现，当然manus团队真的善用API调用各种有效数据源，从测试结果和过程看，这么复杂庞大工作流集合在浏览器上跑很稳定。

4.deepseek是的技术创新在于对科学理论实践落地为应用。这点manus不是在一个层面比较，前者是我们一直不擅长的，路径高度真的不一样。

5.大厂都有能力做这样工具，而且大概率内部已经做过。

6.作者没有亲自测试过，以上是个人观点，希望被打脸。

Mutable AI - 一款更全面的 GitHub Copilot 替代品
Mutable AI 一款更全面的 GitHub Copilot 替代品

链接：
https://mutable.ai/

#Ai工具推荐

豆包为什么老和元宝对着干呢？

你会和小爱同学说“请”字吗？
你会和 DeepSeek 说谢谢吗？
酒店机器人送餐，你会帮他关仓门吗？

机器人不是要取代人类么？我觉得我大部分工作都可以被机器人取代…今天连着盖章三百多个把手心给盖起泡了…这破工作谁爱干谁干。

这会填报信息也给我整暴躁了，只能一个一个单元格复制粘贴。什么笨蛋玩意儿啊！

貌似东莞从过去的莞式服务重镇默默变成了“陪伴”服务机器人重镇，一种中式梦核赛博朋克。