Coze手搓Manus？Manus原理及搭建讲解来了！
最深的蓝约 8 分钟今年国内AI圈最大的两个事情，一个是DeepSeek的发布，另一个就是Manus的首发。
还记得今年三月份的时候，有一天晚上，突然被一条爆火的视频刷屏朋友圈，所有人都在讨论一条新发布的视频 - Manus。
第一眼看到这个视频，效果确实还是比较震撼的，很多人的第一反应是
这就是我想要的智能体！
当时看着视频眼馋，但是由于没有邀请码，属于是看得见摸不着，着实给Manus蒙上了一层神秘的面纱！
现在经过半年多的演进，各种智能体平台白花齐放，Manus也开源了OpenManus项目，它的神秘面纱也终于被解开！
今天，咱们也来聊聊Manus的技术原理，然后看看用Coze能不能实现一个轻量版的Manus！
Agent
在说Manus之前，咱们得先来说一下今年最火的一个词Agent，那么到底啥是Agent，它跟大模型有啥区别？
简单来说，能够自己规划任务，自主调用工具，具备记忆的系统，称之为Agent。
Agent本质上它是一个系统
Multi Agent System
那么MAS，就是由多个Agent组成的一套协作系统。
其中每个Agent各司其职，分工协作完成复杂的任务。
其中通过规划Agent来理解用户的意图，并拆解任务清单，分发给子Agent执行具体的任务。
同时还可以主动与环境交互，实现多轮问答能力。
Manus本质上就是一个MAS系统
Manus的基本原理
我去Manus的官网，让他给我做一款贪吃蛇的小游戏，他不仅给我开发好了具体的程序，还提供了预览地址，看起来效果还可以！
他这里具体的基本功能是：
读写文件的能力 操作浏览器的能力（搜索网页和模拟点击、键盘事件等） 代码编写的能力 执行系统命令的能力 代码部署和预览能力
所有这操作，都在一台云主机上完成，并且实时回传了运行进展。
1. 整体框架
那么他到底是怎么实现的呢？根据OpenManus披露的一些实现和网上搜集的资料，我们大致可以描绘出他的整体架构。
大家看到这个图不要慌，其实拆解来看，其实也并不复杂，咱们现在就来拆解一下。
2. Planning模块
规划模块的职责是：
识别用户意图，并把任务拆解成若干个可以原子化执行的子任务，并写入Todo.md中
举个例子：
# 用户问题
帮我做一个贪吃蛇的小游戏
# Todo.md
# 贪吃蛇游戏开发进度
## 第一阶段：设计游戏架构和界面
- [ ] 创建项目目录结构
- [ ] 设计游戏界面布局
...
## 第二阶段：实现游戏核心逻辑
- [ ] 实现蛇的移动逻辑
- [ ] 实现食物生成和碰撞检测
...
## 第三阶段：测试和优化游戏
- [ ] 本地测试游戏功能
- [ ] 优化游戏性能
...
## 第四阶段：部署游戏并交付给用户
- [ ] 部署到公网
- [ ] 向用户交付最终产品
这一步其实最关键，后续的所有执行动作，都会围绕着这个清单进行执行，不会偏离主要目标。
OpenManus关于规划模块的提示词：
# planner_module
- 系统配备规划器模块，用于整体任务规划
- 任务规划将以事件流中的事件形式提供
- 任务计划使用编号的伪代码表示执行步骤
- 每次计划更新都包含当前步骤编号、状态和反思
- 表示执行步骤的伪代码将在整体任务目标发生变化时更新
- 必须完成所有计划步骤，并在完成时达到最终步骤编号
# todo rules
- 根据 Planner 模块中的任务规划，创建 todo.md 文件作为清单
- 任务规划优先于 todo.md，而 todo.md 包含更多详细信息
- 完成每项任务后，立即使用文本替换工具更新 todo.md 中的标记
- 当任务规划发生重大变化时，重建 todo.md
- 必须使用 todo.md 记录和更新信息收集任务的进度
- 所有计划步骤完成后，验证 todo.md 的完成情况并删除跳过的任务
3. Agent Loop
拿到了规划的清单之后，就会进入到一个事件循环当中，不断的执行清单上面的任务，直到所有任务完成。
Think模块会根据当前的执行情况，决定下一步的行动任务，如果任务偏离主目标太多的话，也可以推翻当前任务重新调整任务清单。Excute模块会按照当前任务调用各种Agent完成具体的任务，每个Agent都配置了各自的技能（比如各种工具）。Observe模块会评估当前任务的执行情况，更新任务执行的具体情况。
当清单中已经没有待办的任务时，就会跳出循环。
4. ComputerUse
云端主机负责执行具体的任务，提供任务的执行环境，并负责实时上报日志。
云主机上面为了达到ComputerUse的效果，会开放很多的能力，包括但不限于：
操作浏览器的能力 执行系统命令的能力，当然这里为了云主机的安全，会限制一些命令的执行。 写代码的能力与代码执行环境 文件读写能力 数据读写能力
同时还可以接入各种各样的MCP能力，比如查询天气，规划路线等。
5. Report
任务执行完成后，Report模块会分析执行的过程数据，并生成最终总结数据。
6. 其他
当然了，还会有很多其他的辅助模块，比如消息管理模块、云主机管理模块、日志模块等，这里咱们就不展开了。
Coze搭建思路
解释完了原理，咱们就来实际操作一下
咱们这里为了方便后续使用Coze搭建，整体的架构跟原版可能不完全一样，但不影响大家理解他的原理！
大体来说，分为两部分逻辑Client端和Service端
Service端： Manus使用的是Ubuntu的虚拟机，咱们简单起见，使用Linux的云服务器。
Client端： 咱们使用Coze进行搭建，实现规划、思考、执行、观察、汇总等几个模块。
Service端跟Client端通过异步通信协议实现连通。
异步通信协议
其实Manus本体应该是用Socket来完成通信的，咱们这里方便起见，使用异步轮询的方式。
非技术的同学可能不太理解异步通信是个啥，这里举一个例子：
# 同步通信
# 这里由于老板(Service)拿烟（处理任务）的时间很短
# 所以你(Client)是立等可取
# 基本上马上就能拿到结果
你(Client)去隔壁商店买包中华烟(Task)
老板(Service)随手从架子上拿了一包烟
你拿了烟就回家了。
# 异步通信
# 这里由于老板进货（执行任务）时间很长。
# 所以马上让你回家等消息（Response）
# 后面你每天都去问问情况（轮询）
# 直到拿到烟（任务完成）
1. 你(Client)去隔壁商店买包中华烟(Task)
老板(Service)说，我现在去进货，你先回去（Response）。
2. 你第二天去问老板货到了没(Request)，老板说没有(Response)。
3. 你第三天去问老板货到了没(Request)，老板说没有(Response)。
4. 你第N天去问老板货到了没(Request)，老板说有了(Response)。
你拿烟回家(Task Complete)
那么其实大模型执行任务的时间有可能是非常长的，所以需要使用异步通信的方式。具体来说，Client端跟Service端分别需要实现两个接口：
Excute接口：发布任务，并从服务端拿到session_id
Log接口：使用session_id轮询查看服务端的执行日志，直到任务结束。服务端需要实时把Agent的执行日志记录进log文件中。
具体Coze的实现如下：
日志模块的设计
Agent的执行日志，一般来说都是流式的JSON文件格式，例如：
{
"type": "tool_use",
"name": "TodoWrite",
"input": {
"todos": [
{
"content": "获取成都的经纬度坐标",
"status": "in_progress",
"activeForm": "正在获取成都的经纬度坐标"
},
{
"content": "获取上海五角场的经纬度坐标",
"status": "pending",
"activeForm": "正在获取上海五角场的经纬度坐标"
}
]
}
}
同时还需要加上日志头和日志尾，方便判断状态和记录信息。
完整的日志文件大概长这样：
Client端接收到日志后通过代码模块进行解析即可实时展示给用户看。
规划模块设计
这里最重要的是需要设计一下todoList的数据结构。
根据OpenManus的提示词，可以设计出类似右边的数据结构。
Coze实现的话，就是一个大模型模块就搞定了。
执行模块设计
这里需要实现的是一套大模型自主调用智能体的流程，因为用的是coze工作流，咱们使用系统提示词手动实现FunctionCalling调用远程工具。
大致的流程如下：
智能体之间的通信协议设计如下：
通过这个能力，咱们的系统就具备了自主判断和调用工具的能力。
Coze实现如下：
观察模块设计
观察模块咱们也是通过一个大模型节点就可以搞定。
提示词如下：
# 角色
执行效果评估助手
# 任务
1. 根据当前的上下文中的任务状态字段，判断是否存在执行失败和待执行的任务。
2. 不要解释，也不要额外输出其他内容。
3. 保持上下文格式和内容的完整性
4. 上下文中不包括历史记录数据
5. 上下文需要时一个合法的JSON
if (存在执行失败的任务) {
- 面向最终目标，更新任务列表和当前任务。
- 之前已经执行成功的任务保持不变
} elseif (存在待执行的任务) {
- 更新当前任务为下一个待执行的任务。
} else {
- 原样输出上下文
}
# 上下文
{{context}}
# 历史记录
{{histroy}}
# 输出要求
status的值：
所有任务都执行完毕=complete
存在执行失败的任务=retry
存在待执行的任务=next
服务端设计
服务端的话，可以使用Cursor或者ClaudeCode实现一个简单的Service服务器。
核心实现/Excute和/Log这两个接口即可。
其中/Excute接口需要能够调用服务器上的智能体，接收智能体的流日志并写入日志文件。
智能体可以使用任意大模型，如果需要大模型写代码的话最好选择代码模型（Claude系列、Kimi K2等），然后配套各种MCP工具即可。
具体的MCP工具的使用可以直接查看相关文档，这里就不再赘述，后续单开一期讲讲MCP。
具体选择哪些MCP主要看你想要实现的功能。
整体效果
总结
虽然Manus的基本原理看起来比较简单，但真实生产场景，还是要复杂很多，咱们只是通过简单的例子来尝试理解Manus背后的运作机制，其实除了Manus，其他产品例如Curosr和ClaudeCode等，也是类似的MAS系统，通过多智能体协作和任务拆解，一步步引导AI完成复杂的任务。
今天的内容就分享到这里了，感兴趣的话记得点个关注~