WEBVTT

00:00:00.000 --> 00:00:04.000
我給Octop記憶定義的就是給Agent一個能帶走的記憶。

00:00:04.000 --> 00:00:08.000
我們多專家多Agent的並行,如何來重溝我們的記憶。

00:00:08.000 --> 00:00:10.000
Hello,大家好,大家晚上好。

00:00:10.000 --> 00:00:15.000
歡迎大家來到今天的直播間,我是今天的主持人佼佼。

00:00:15.000 --> 00:00:19.000
歡迎大家再次來到雲上AI工坊的直播間。

00:00:19.000 --> 00:00:24.000
今天這期的主角是Octop,一個剛剛開源的自演的AI助手。

00:00:24.000 --> 00:00:29.000
今天我們也會針對他多專家多用戶多Agent的並行這樣子的一個特徵。

00:00:29.000 --> 00:00:29.800
这样子的一个特征

00:00:29.800 --> 00:00:32.200
去采取一些实战的案例分析

00:00:32.200 --> 00:00:34.320
比如说我不知道直播间的各位

00:00:34.320 --> 00:00:36.260
有没有一些做行业分析

00:00:36.260 --> 00:00:37.180
竞品分析

00:00:37.180 --> 00:00:39.380
这样子的一个日常的工作需求

00:00:39.380 --> 00:00:40.780
那么我们也会

00:00:40.780 --> 00:00:43.200
针对这样子的一个实战的场景

00:00:43.200 --> 00:00:45.600
来打造这个Octop重塑竞品分析

00:00:45.600 --> 00:00:47.820
工作流这样子的一个实战案例

00:00:47.820 --> 00:00:50.340
同时也会涉及到一些多agent博弈

00:00:50.340 --> 00:00:51.740
比如说大家不知道

00:00:51.740 --> 00:00:53.040
喜不喜欢吃豆腐脑

00:00:53.040 --> 00:00:54.700
我们本场直播也会给大家

00:00:54.700 --> 00:00:56.580
在线围观一下这个豆腐脑

00:00:56.580 --> 00:00:58.660
AI它是如何进行填衔

00:00:58.660 --> 00:00:59.620
辩论的

00:00:59.620 --> 00:01:01.560
同时大家上一场直播中

00:01:01.560 --> 00:01:02.680
其实也有关注到

00:01:02.680 --> 00:01:03.680
我们这个Octop

00:01:03.680 --> 00:01:04.860
它的一个记忆机制

00:01:04.860 --> 00:01:05.620
是怎么样的

00:01:05.620 --> 00:01:07.140
什么东西是该记忆的

00:01:07.140 --> 00:01:08.300
什么是该召回的

00:01:08.300 --> 00:01:09.420
那么本场直播

00:01:09.420 --> 00:01:10.240
大家不用着急

00:01:10.240 --> 00:01:11.840
我们也会给大家详细的

00:01:11.840 --> 00:01:13.760
去拆解Octop的记忆机制

00:01:13.760 --> 00:01:15.260
话不多说

00:01:15.260 --> 00:01:16.500
我们也简要的介绍一下

00:01:16.500 --> 00:01:17.680
今天的两位嘉宾

00:01:17.680 --> 00:01:20.080
首先是Octop的研发工程师

00:01:20.080 --> 00:01:20.500
英宁

00:01:20.500 --> 00:01:21.860
另外一位杨直

00:01:21.860 --> 00:01:23.860
也是我们的Octop的研发工程师

00:01:23.860 --> 00:01:25.060
我们先来讲

00:01:25.060 --> 00:01:28.280
本期的一个Octop基础的

00:01:28.280 --> 00:01:30.280
模块介绍就是记忆

00:01:30.280 --> 00:01:33.280
我上一期应该就是给大家演示了

00:01:33.280 --> 00:01:35.280
我们Octop的记忆面板

00:01:35.280 --> 00:01:40.040
然后这期我们会给大家详细带来一下Octop的记忆

00:01:40.040 --> 00:01:41.120
它是怎么记的

00:01:41.120 --> 00:01:43.320
它又为什么好

00:01:43.320 --> 00:01:44.280
话不多说

00:01:44.280 --> 00:01:45.280
让我们开始

00:01:45.280 --> 00:01:47.240
首先可以看到标题

00:01:47.240 --> 00:01:52.240
我给Octop记忆定义的就是给Agent一个能带走的记忆

00:01:52.240 --> 00:01:53.680
如果想到能带走

00:01:53.680 --> 00:01:55.520
我想问一下杨直跟佼佼

00:01:55.520 --> 00:01:56.920
首先想到的是什么

00:01:56.920 --> 00:01:59.860
它一定可以从不管是Open Cloud还是Harmor

00:01:59.860 --> 00:02:01.360
都可以迁积到我们的Octob

00:02:01.360 --> 00:02:01.920
对

00:02:01.920 --> 00:02:03.660
是的 我也是这样想的

00:02:04.520 --> 00:02:06.620
是的 那其实就是这样

00:02:06.620 --> 00:02:08.720
不知道现在在看直播的朋友

00:02:08.720 --> 00:02:10.780
有没有我们以前的老用户

00:02:10.780 --> 00:02:12.520
给大家说一下我们的Octob

00:02:12.520 --> 00:02:16.320
其实是有个前身就是叫LiCloud ACE

00:02:16.320 --> 00:02:19.120
如果一直关注咱们腾讯服务器直播间的朋友

00:02:19.120 --> 00:02:21.920
应该听说过这个产品或名词

00:02:21.920 --> 00:02:24.620
现在我们推出了全新升级版Octob

00:02:24.620 --> 00:02:26.780
同时我们也在GitHub开源了

00:02:26.780 --> 00:02:30.920
感兴趣的粉丝朋友们也可以去搜索Octop

00:02:30.920 --> 00:02:33.280
看看我们的代码

00:02:33.280 --> 00:02:35.020
给我们提交PR或issue

00:02:35.020 --> 00:02:37.080
也请多多fork我们仓库

00:02:37.080 --> 00:02:38.000
以及给我们start

00:02:38.000 --> 00:02:38.320
是的

00:02:38.320 --> 00:02:40.400
欢迎提论区的大佬们

00:02:40.400 --> 00:02:44.060
多多的为我们的项目去提出建设性的意见

00:02:44.060 --> 00:02:46.440
首先那继续给大家讲解记忆

00:02:46.440 --> 00:02:48.000
那我们现在记忆

00:02:48.000 --> 00:02:50.940
其实现在是一个七层的记忆结构

00:02:50.940 --> 00:02:52.860
和两条相反的流水线

00:02:52.860 --> 00:02:55.440
那两条方向相反流水线是什么

00:02:55.440 --> 00:02:56.940
就是沉淀和召回

00:02:56.940 --> 00:02:59.940
其实这两个名词有点灰色难懂

00:02:59.940 --> 00:03:01.040
但是没有关系

00:03:01.040 --> 00:03:02.100
后面听我讲

00:03:02.100 --> 00:03:03.600
大家就能懂了

00:03:03.600 --> 00:03:05.260
首先给大家介绍一下

00:03:05.260 --> 00:03:06.720
Octop Memory是什么

00:03:06.720 --> 00:03:11.620
它其实是一个面向Agent的可插拔长期记忆系统

00:03:11.620 --> 00:03:14.520
也就是它其实不只适用于我们Octop

00:03:14.520 --> 00:03:16.980
因为在我们推出Ace的Memory的时候

00:03:16.980 --> 00:03:18.820
其实很多粉丝朋友就问

00:03:18.820 --> 00:03:21.860
说那如果你们一直在说你们Memory好

00:03:21.860 --> 00:03:24.000
那能不能做个独立的插件

00:03:24.000 --> 00:03:26.500
像外面的那些memory插件一样

00:03:26.500 --> 00:03:28.840
他们就是想接在OpenCloud使用

00:03:28.840 --> 00:03:30.180
接在Hermes使用

00:03:30.180 --> 00:03:32.120
当时给大家的回复是

00:03:32.120 --> 00:03:33.320
我们未来会推出

00:03:33.320 --> 00:03:35.820
那现在随着我们全新升级的Octop推出

00:03:35.820 --> 00:03:37.200
对我们Octop Memory

00:03:37.200 --> 00:03:39.600
也迎来一个可插拔的长期记忆系统

00:03:39.600 --> 00:03:41.560
现在我们Octop Memory也支持

00:03:41.560 --> 00:03:44.000
就是在Hermes上使用

00:03:44.000 --> 00:03:45.780
在OpenCloud上使用

00:03:45.780 --> 00:03:47.860
以及刚刚我们说可以带走的记忆

00:03:47.860 --> 00:03:49.400
也就是说你的记忆

00:03:49.400 --> 00:03:51.880
其实是跟着我们Octop memory走

00:03:51.880 --> 00:03:53.760
并不是说是依赖agent本身

00:03:53.760 --> 00:03:55.380
如果你在Octop上

00:03:55.380 --> 00:03:56.760
你就是用了一段时间

00:03:56.760 --> 00:03:58.200
你想我带着这份记忆

00:03:58.200 --> 00:03:59.060
我去试一下

00:03:59.060 --> 00:04:01.200
那OpenCloud是怎么样的

00:04:01.200 --> 00:04:02.740
Hermus是怎么样的

00:04:02.740 --> 00:04:04.840
是不是你们Octop真的说着

00:04:04.840 --> 00:04:05.940
比OpenCloudHermus好

00:04:05.940 --> 00:04:06.800
那是真的好吗

00:04:06.800 --> 00:04:07.880
那没关系

00:04:07.880 --> 00:04:09.540
你就可以带着我们的记忆

00:04:09.540 --> 00:04:10.860
去实地感受一下

00:04:10.860 --> 00:04:13.900
对我们现在是可以支持这个功能的

00:04:13.900 --> 00:04:15.480
那是不是可以理解为

00:04:15.480 --> 00:04:17.020
只要拥有这个插件

00:04:17.020 --> 00:04:18.360
其实我们的记忆

00:04:18.360 --> 00:04:19.900
就可以灵活的

00:04:19.900 --> 00:04:21.080
OpenCloud Hermes之间

00:04:21.080 --> 00:04:22.500
去迁移使用

00:04:22.500 --> 00:04:22.800
是的

00:04:22.800 --> 00:04:24.040
就是这样的

00:04:24.040 --> 00:04:25.840
那这个功能也太方便了

00:04:25.840 --> 00:04:27.620
那真的是一个挺大的优势

00:04:27.620 --> 00:04:28.820
是的

00:04:28.820 --> 00:04:30.660
因为之前我们每个组件

00:04:30.660 --> 00:04:32.460
都是聚合在一起的

00:04:32.460 --> 00:04:33.880
是在我们前身ACE版本

00:04:33.880 --> 00:04:35.180
如果了解的粉丝朋友

00:04:35.180 --> 00:04:35.860
应该也知道

00:04:35.860 --> 00:04:37.060
但我们现在

00:04:37.060 --> 00:04:39.220
随着我们全新的功能升级

00:04:39.220 --> 00:04:41.060
我们架构也迎来了一个升级

00:04:41.060 --> 00:04:42.880
在后面我们也会

00:04:42.880 --> 00:04:44.280
陆续开源我们每个组件

00:04:44.280 --> 00:04:45.400
如果感兴趣的朋友

00:04:45.400 --> 00:04:47.540
可以先给我们仓库

00:04:47.540 --> 00:04:48.280
点个Star

00:04:48.280 --> 00:04:50.220
后续我们看愿其他组件

00:04:50.220 --> 00:04:52.540
我们也会通知各位观众朋友

00:04:52.540 --> 00:04:53.160
对

00:04:53.160 --> 00:04:53.780
是的

00:04:53.780 --> 00:04:56.100
大家把这个star给点起来

00:04:56.100 --> 00:04:57.740
我刚刚其实也介绍了

00:04:57.740 --> 00:04:59.380
我们Octop在最上层

00:04:59.380 --> 00:05:00.920
然后我们也有browser

00:05:00.920 --> 00:05:02.020
也有givet

00:05:02.020 --> 00:05:03.520
包括我们的运行时

00:05:03.520 --> 00:05:06.220
那今天我们其实要给大家带来的是

00:05:06.220 --> 00:05:06.920
Octop Memory

00:05:06.920 --> 00:05:08.880
在介绍Octop Memory之前

00:05:08.880 --> 00:05:11.780
那其实今天还没有遇到那个经典问题

00:05:11.780 --> 00:05:13.760
我包括在之前来到直播间

00:05:13.760 --> 00:05:15.500
大概五六七八次

00:05:15.500 --> 00:05:16.960
不管是在建议的时候

00:05:16.960 --> 00:05:18.180
或者是Octop的时候

00:05:18.180 --> 00:05:20.860
粉丝朋友总会在评论区问

00:05:20.860 --> 00:05:23.680
那你们跟谁谁有什么不一样

00:05:23.680 --> 00:05:27.160
那之前其实都是很口语化的给大家解答

00:05:27.160 --> 00:05:30.900
但是今天我作为一个经验丰富的老主播

00:05:30.900 --> 00:05:32.540
我就是预设到了这个问题

00:05:32.540 --> 00:05:34.900
那我就是加了一页HTML

00:05:34.900 --> 00:05:36.320
跟大家好好讲讲

00:05:36.320 --> 00:05:39.980
我们on top到底跟别人有什么不一样

00:05:39.980 --> 00:05:42.360
其实可以从四维看见

00:05:42.360 --> 00:05:43.840
其实就有四个维度

00:05:43.840 --> 00:05:45.340
一个是多用户

00:05:45.340 --> 00:05:46.440
一个是个人

00:05:46.440 --> 00:05:48.080
以及一个是编码场景

00:05:48.080 --> 00:05:51.020
一个是通用办公和生活场景

00:05:51.020 --> 00:05:52.980
那这时候其实我想问一下

00:05:52.980 --> 00:05:53.900
焦焦和杨直

00:05:53.900 --> 00:05:56.920
其实正好是一个运营同学

00:05:56.920 --> 00:05:58.340
一个研发同学

00:05:58.340 --> 00:06:00.000
那你们在工作中

00:06:00.000 --> 00:06:01.980
其实用哪个agent用的比较多

00:06:01.980 --> 00:06:03.440
其实我在日常工作中

00:06:03.440 --> 00:06:04.800
这几个都有使用

00:06:04.800 --> 00:06:07.060
首先就是我们云上的这个lighthouse

00:06:07.060 --> 00:06:09.860
是我自己一直持续有氧的

00:06:09.860 --> 00:06:12.240
我们的一个桌面的agentworkbody

00:06:12.240 --> 00:06:13.420
其实也有在使用的

00:06:13.420 --> 00:06:16.680
我觉得他们可能在不同的场景

00:06:16.680 --> 00:06:17.940
和不同的任务

00:06:17.940 --> 00:06:18.720
它各有优利

00:06:18.720 --> 00:06:20.520
这几个都有使用

00:06:20.520 --> 00:06:21.560
那我平时觉得

00:06:21.560 --> 00:06:22.820
Workbody去做一些

00:06:22.820 --> 00:06:24.480
文档编辑是很方便的

00:06:24.480 --> 00:06:24.720
对

00:06:24.720 --> 00:06:25.800
但对于一个研发工程师

00:06:25.800 --> 00:06:26.400
可能来说

00:06:26.400 --> 00:06:27.220
像Codex

00:06:27.220 --> 00:06:29.100
像Cloudcode这种编码

00:06:29.100 --> 00:06:30.120
包括我们的腾讯

00:06:30.120 --> 00:06:30.820
推出的Codebody

00:06:30.820 --> 00:06:32.020
也是非常好的一个编码工具

00:06:32.020 --> 00:06:32.940
这些都在使用

00:06:32.940 --> 00:06:34.200
粉丝朋友也有说

00:06:34.200 --> 00:06:35.300
有用这个Workbody

00:06:35.300 --> 00:06:36.740
有用Hermes都在用

00:06:36.740 --> 00:06:36.960
对

00:06:36.960 --> 00:06:38.320
我也看到一个问题

00:06:38.320 --> 00:06:40.100
是说这个记忆写入时

00:06:40.100 --> 00:06:41.660
有没有去重合

00:06:41.660 --> 00:06:43.000
冲突的消解机制

00:06:43.000 --> 00:06:44.040
如何处理

00:06:44.040 --> 00:06:45.740
同一事实的不同表述

00:06:45.740 --> 00:06:46.980
这个问题挺好的

00:06:46.980 --> 00:06:47.640
对

00:06:47.640 --> 00:06:50.300
看来这个Nome粉丝朋友

00:06:50.300 --> 00:06:53.320
其实是有关注记忆组件的

00:06:53.320 --> 00:06:57.280
那其实我们去虫和冲突消解机制是有的

00:06:57.280 --> 00:07:00.600
其实先给大家看一下后续的PPT

00:07:00.600 --> 00:07:02.960
那我们其实有七层结构

00:07:02.960 --> 00:07:04.840
第一层是memory.md

00:07:04.840 --> 00:07:07.360
如果养过虾的朋友可能就知道它是什么

00:07:07.360 --> 00:07:09.040
对于Open Cloud和Hermas

00:07:09.040 --> 00:07:11.480
它都会全量进入一个上下文

00:07:11.480 --> 00:07:13.300
做一个比较全的记忆

00:07:13.300 --> 00:07:16.100
当然我们也会同步这个操作场景

00:07:16.100 --> 00:07:17.460
对于我们自己的记忆

00:07:17.460 --> 00:07:19.660
首先我们就有一个ROEvent

00:07:19.660 --> 00:07:21.660
就是一个最底层的事实

00:07:21.660 --> 00:07:23.260
也就是对话数据源

00:07:23.260 --> 00:07:25.460
然后我们会有一个Candidate

00:07:25.460 --> 00:07:27.560
如果我们会有一套记忆的上升规则

00:07:27.560 --> 00:07:29.160
就是关于长期记忆

00:07:29.160 --> 00:07:29.760
有事实记忆

00:07:29.760 --> 00:07:30.860
有情景记忆

00:07:30.860 --> 00:07:32.960
以及用户的一些信息

00:07:32.960 --> 00:07:35.460
那如果你触发到了我们的规则

00:07:35.460 --> 00:07:36.860
那就会进入Candidate

00:07:36.860 --> 00:07:38.560
那在Candidate层

00:07:38.560 --> 00:07:40.260
那这个记忆会做什么

00:07:40.260 --> 00:07:42.560
其实就是一个沉淀

00:07:42.560 --> 00:07:44.960
那首先他会去判断你的

00:07:44.960 --> 00:07:48.760
这条记忆是闲聊噪声还是真的是实

00:07:48.760 --> 00:07:52.300
如果是重要性低和自信度低的话

00:07:52.300 --> 00:07:54.400
他就会选择一个丢弃

00:07:54.400 --> 00:07:57.820
其实我们这个记忆其实最重要的就是

00:07:57.820 --> 00:07:59.200
他必须正确

00:07:59.200 --> 00:08:01.260
就是他永远都会有一个reference

00:08:01.260 --> 00:08:03.700
可以指挥刚刚我们所谓的Rone Event

00:08:03.700 --> 00:08:05.360
一个Elling的原始事件

00:08:05.360 --> 00:08:06.820
因为这样我们

00:08:06.820 --> 00:08:09.100
我当时在考虑做这个记忆的时候

00:08:09.100 --> 00:08:12.160
其实想打造成一个可追溯的记忆

00:08:12.160 --> 00:08:14.920
并不是说像OpenCloud或者Hermas一样

00:08:14.920 --> 00:08:16.460
如果大模型觉得该写

00:08:16.460 --> 00:08:18.600
他就去写这个memory.md

00:08:18.600 --> 00:08:20.020
后面可能记错了

00:08:20.020 --> 00:08:22.960
或者说是记的事实有误的时候

00:08:22.960 --> 00:08:23.780
其实想追溯

00:08:23.780 --> 00:08:24.780
你其实并不知道

00:08:24.780 --> 00:08:26.960
他是什么时候把这个错误信息写了进去

00:08:26.960 --> 00:08:29.820
所以我在设计这个记系统的时候

00:08:29.820 --> 00:08:32.100
就有非常严苛的reference地址

00:08:32.100 --> 00:08:35.280
如果过了这两道检查关卡

00:08:35.280 --> 00:08:37.320
其实就会到一个我们的entity

00:08:37.320 --> 00:08:41.960
那这里可能就会有朋友问的去重合冲突

00:08:41.960 --> 00:08:43.980
那其实在entity这里

00:08:43.980 --> 00:08:46.860
可以给大家先在我们这里看一眼

00:08:46.860 --> 00:08:48.480
那其实我们会有个记忆数

00:08:48.480 --> 00:08:51.860
那其实每个entity下面

00:08:51.860 --> 00:08:54.500
每个主体下面都会有记忆

00:08:54.868 --> 00:09:04.868
如果有一條新的記憶進來,它會看是屬於這個user自己的,或者是哪個人物的,或者是某個事實的。

00:09:04.868 --> 00:09:07.448
当然你有了这些事实和人物之后

00:09:07.448 --> 00:09:09.748
你觉得这条记忆不好或者不重要

00:09:09.748 --> 00:09:13.028
或者你不想让它参与以后的记忆交回

00:09:13.028 --> 00:09:14.608
你可以把它弃用掉

00:09:14.608 --> 00:09:15.428
对

00:09:15.428 --> 00:09:16.688
一

00:09:16.688 --> 00:09:20.068
这个冲突消解会是在这个entity的时候

00:09:20.068 --> 00:09:22.108
它会读取你之前的记忆

00:09:22.108 --> 00:09:24.688
然后进行一个entity的重构

00:09:24.688 --> 00:09:26.208
你看这里也有

00:09:26.208 --> 00:09:27.488
如果和事实矛盾

00:09:27.488 --> 00:09:29.208
它会进冲突对冽

00:09:29.208 --> 00:09:31.308
如果冲突对冽在哪

00:09:31.308 --> 00:09:33.088
其实是在我们的记忆沉淀这里

00:09:33.088 --> 00:09:34.548
那我现在没有冲突的

00:09:34.548 --> 00:09:35.568
如果有冲突的

00:09:35.568 --> 00:09:37.708
它会希望你去check

00:09:37.708 --> 00:09:38.408
对看

00:09:38.408 --> 00:09:39.908
如果存在矛盾

00:09:39.908 --> 00:09:40.768
就尽

00:09:40.768 --> 00:09:42.048
如果你点采纳

00:09:42.048 --> 00:09:43.468
或你可以点轰略

00:09:43.468 --> 00:09:45.648
但是如果你七天没有的话

00:09:45.648 --> 00:09:47.648
它会判断是新的

00:09:47.648 --> 00:09:49.308
记忆自动采纳

00:09:49.308 --> 00:09:49.568
对

00:09:49.568 --> 00:09:51.388
我们先给大家回答一下

00:09:51.388 --> 00:09:52.508
几个高频的问题

00:09:52.508 --> 00:09:53.708
就是说我们的October

00:09:53.708 --> 00:09:54.788
和其他的产品

00:09:54.788 --> 00:09:56.468
它的定位有什么不同

00:09:56.468 --> 00:09:58.328
以及它的优势在哪里

00:09:58.328 --> 00:09:59.648
先给大家讲完

00:09:59.648 --> 00:10:00.148
我们待会儿

00:10:00.148 --> 00:10:01.468
我也会详细地讲解到

00:10:01.468 --> 00:10:01.888
记忆制

00:10:01.888 --> 00:10:03.008
大家有关于记忆的

00:10:03.008 --> 00:10:04.348
可以一起提问

00:10:04.348 --> 00:10:07.388
那其实从包括

00:10:07.388 --> 00:10:08.668
我其实刚刚也问了

00:10:08.668 --> 00:10:09.888
焦焦和杨真两个问题

00:10:09.888 --> 00:10:12.628
那其实研发可能就用Cloud Code

00:10:12.628 --> 00:10:13.308
用Codex

00:10:13.308 --> 00:10:15.268
包括我们公司的Codebody比较多

00:10:15.268 --> 00:10:17.448
办公可能就是我们Workbody

00:10:17.448 --> 00:10:20.868
现在其实也有些同事会用

00:10:20.868 --> 00:10:22.428
CC或者Codex

00:10:22.428 --> 00:10:24.428
就是做一个办公场景的Agent

00:10:24.428 --> 00:10:26.808
生活场景其实就是OpenCloud Hermes

00:10:26.808 --> 00:10:29.868
我们其实是处于这个项线位

00:10:29.868 --> 00:10:32.128
那其实首先比起个人

00:10:32.128 --> 00:10:33.948
我们Octop肯定是多用户的

00:10:33.948 --> 00:10:35.648
我们是支持多用户

00:10:35.648 --> 00:10:37.708
如果上一期直播

00:10:37.708 --> 00:10:40.488
Octop第一期直播没有看的观众朋友们

00:10:40.488 --> 00:10:42.448
可能是这里可以给大家介绍一下

00:10:42.448 --> 00:10:44.768
你在一台服务器部署了我们Octop

00:10:44.768 --> 00:10:46.688
你有一个主用户

00:10:46.688 --> 00:10:49.588
你也可以创建许多子用户去分给你

00:10:49.588 --> 00:10:50.628
不管是家人朋友

00:10:50.628 --> 00:10:52.768
你们可以一起共享这个Octop

00:10:52.768 --> 00:10:56.208
他们彼此之间的工作空间和记忆是隔离的

00:10:56.208 --> 00:10:58.588
只有一个龙虾就可以供一个小团队

00:10:58.588 --> 00:11:00.188
或者一家人去使用

00:11:00.188 --> 00:11:00.408
对

00:11:00.408 --> 00:11:02.568
不同的agent可以用不同的记忆

00:11:02.568 --> 00:11:03.008
对的

00:11:03.008 --> 00:11:04.968
刚刚说到不同的agent

00:11:04.968 --> 00:11:06.848
每个用户肯定记忆隔离

00:11:06.848 --> 00:11:09.288
其实上期直播也讲了多agent

00:11:09.288 --> 00:11:11.128
我们在一个用户的多agent下

00:11:11.128 --> 00:11:13.288
每个agent也是记忆隔离的

00:11:13.288 --> 00:11:15.588
这样就是防止我们记忆紊乱

00:11:15.588 --> 00:11:16.488
是的

00:11:16.488 --> 00:11:19.328
我们的粉丝朋友开头的问

00:11:19.328 --> 00:11:21.728
Octob是一个桌面应用程序吗

00:11:21.728 --> 00:11:23.688
这也是涉及到我们的定位问题

00:11:23.688 --> 00:11:29.448
Octob我们现在是一个开源的一个agent

00:11:29.448 --> 00:11:32.928
我们未来会推出轻量云应用镜像

00:11:32.928 --> 00:11:37.388
我们也支持PWA安装成应用程序

00:11:37.388 --> 00:11:39.508
PWA安装在桌面上

00:11:39.508 --> 00:11:41.828
如果后续有期待桌面客户端

00:11:41.828 --> 00:11:44.048
我们有精力也会投入

00:11:44.048 --> 00:11:46.608
最多可以支持用户

00:11:46.608 --> 00:11:49.588
最多就应该是看你服务系性能了

00:11:49.588 --> 00:11:51.328
如果你买个很多

00:11:51.328 --> 00:11:53.268
8核8G或者多核多G

00:11:53.268 --> 00:11:55.768
其实就可以承载很多个用户

00:11:55.768 --> 00:11:57.468
还有粉丝朋友问

00:11:57.468 --> 00:11:58.668
这个目的是用在

00:11:58.668 --> 00:12:00.528
OnCloud Hermes Workbody上面吗

00:12:00.528 --> 00:12:02.848
其实我们就是一个独立的agent

00:12:02.848 --> 00:12:04.048
对

00:12:04.048 --> 00:12:05.288
独立的agent

00:12:05.288 --> 00:12:06.908
就是跟OpenCloud

00:12:06.908 --> 00:12:07.868
Hermas Workbody

00:12:07.868 --> 00:12:09.208
我们同位agent

00:12:09.208 --> 00:12:11.168
可能有些相似或不同的功能

00:12:11.168 --> 00:12:12.788
其实刚刚就讲到

00:12:12.788 --> 00:12:13.848
首先我们是独用户

00:12:13.848 --> 00:12:15.068
我们其实是

00:12:15.068 --> 00:12:16.708
办公和生活场景

00:12:16.708 --> 00:12:18.748
都是比较通用的

00:12:18.748 --> 00:12:21.168
像我们Octop可以用来做PPT

00:12:21.168 --> 00:12:23.668
包括后面养殖会演示的竞品调研

00:12:23.668 --> 00:12:27.028
同时关注过我们直播间的朋友

00:12:27.028 --> 00:12:28.608
我们之前有个很火的直播

00:12:28.608 --> 00:12:30.308
就是我们的产品

00:12:30.308 --> 00:12:30.668
Anthel

00:12:30.668 --> 00:12:32.388
他在用ACE养娃

00:12:32.388 --> 00:12:36.108
对这个场景也同时迁移到了我们的Octop上

00:12:36.108 --> 00:12:38.128
大家也可以尝试一下用Octop养花

00:12:38.128 --> 00:12:39.948
对包括我自己啊

00:12:39.948 --> 00:12:43.008
我在用Octop做我的健康管理助手

00:12:43.008 --> 00:12:47.108
对其实办公和生活场景我们都能cover

00:12:47.108 --> 00:12:49.548
大家感兴趣的话可以都试一下

00:12:49.548 --> 00:12:52.248
可以直接作为记忆题给Workbody

00:12:52.248 --> 00:12:54.288
也就是我们的Hanath Memory

00:12:54.288 --> 00:12:55.728
也就是我们的Octop Memory

00:12:55.728 --> 00:12:59.208
我们现在还没有提供接入Workbody的记忆

00:12:59.208 --> 00:13:02.048
Workbody我理解他们应该有一个原生的记忆

00:13:02.048 --> 00:13:04.228
对我其实下面列了

00:13:04.228 --> 00:13:06.188
我们到底和别的记忆

00:13:06.188 --> 00:13:06.888
有什么不一样

00:13:06.888 --> 00:13:08.448
那Workbody它其实

00:13:08.448 --> 00:13:10.208
记忆是产品内封装的

00:13:10.208 --> 00:13:12.188
如果后续大家感兴趣

00:13:12.188 --> 00:13:13.848
可以说去看看

00:13:13.848 --> 00:13:15.048
怎么合作对接一下

00:13:15.048 --> 00:13:15.288
对

00:13:15.288 --> 00:13:17.468
我问了一个非常经典的

00:13:17.468 --> 00:13:18.428
为啥叫Octop

00:13:18.428 --> 00:13:20.128
其实上一期直播

00:13:20.128 --> 00:13:21.568
也有朋友问

00:13:21.568 --> 00:13:23.128
那给我们取这个名字

00:13:23.128 --> 00:13:24.508
其实是我们的一名主播

00:13:24.508 --> 00:13:25.648
他原来想一个名字

00:13:25.648 --> 00:13:26.548
叫Octopus

00:13:26.548 --> 00:13:28.128
就是Octopus

00:13:28.128 --> 00:13:29.008
就是章鱼

00:13:29.008 --> 00:13:30.568
因为我们多用户

00:13:30.568 --> 00:13:31.248
多专家

00:13:31.248 --> 00:13:33.808
还有多智能体非常多

00:13:33.808 --> 00:13:35.788
就像章鱼非常多的触手一样

00:13:35.788 --> 00:13:37.528
所以我们想了Octopus

00:13:37.528 --> 00:13:39.468
但是为了一是好发音

00:13:39.468 --> 00:13:43.768
二是我们比较想要Top这个后缀

00:13:43.768 --> 00:13:45.388
所以我们改名叫On Top

00:13:45.388 --> 00:13:48.988
那我看我们也是列举了

00:13:48.988 --> 00:13:51.308
不同的形态的Agent的区别

00:13:51.308 --> 00:13:53.968
您这一块可以给我们详细的介绍一下吗

00:13:53.968 --> 00:13:56.308
直播间的粉丝朋友们可以截图保存

00:13:56.308 --> 00:13:58.208
大家如果对这一块

00:13:58.208 --> 00:14:00.248
不仔细的可以截图保存一下

00:14:00.248 --> 00:14:04.708
其实我理解大家问的最多应该是Open Cloud Hermes

00:14:04.708 --> 00:14:06.888
跟我们到底有什么不一样

00:14:06.888 --> 00:14:10.528
其实Cloud Code和Codex就是一个编码agent

00:14:10.528 --> 00:14:13.548
大家用的最多的也是我们直播间出现最多的

00:14:13.548 --> 00:14:14.788
就是Open Cloud Hermes

00:14:14.788 --> 00:14:17.648
然后它跟我们一个最大区别是

00:14:17.648 --> 00:14:19.948
我们其实是一个多专家

00:14:19.948 --> 00:14:23.328
包括一个用户你可以创建非常多的专家

00:14:23.328 --> 00:14:26.388
也就是你可以就比如我和杨直

00:14:26.388 --> 00:14:28.008
我们俩是一个小团队

00:14:28.008 --> 00:14:29.368
我是Admin

00:14:29.368 --> 00:14:32.968
我可以创建我自己的生活助理和办公助理

00:14:32.968 --> 00:14:34.788
这两个助理都在Octop

00:14:34.788 --> 00:14:36.068
都使用一个Octop

00:14:36.068 --> 00:14:38.128
他们工作区和记忆是完全隔离的

00:14:38.128 --> 00:14:40.808
同时我还可以创建一个子用户给杨指

00:14:40.808 --> 00:14:43.808
杨指也可以创建属于他自己的多专家

00:14:43.808 --> 00:14:44.448
对

00:14:44.448 --> 00:14:47.128
每个专家对于IM渠道都是隔离的

00:14:47.128 --> 00:14:50.128
所以如果想要就可以生活场景

00:14:50.128 --> 00:14:51.708
就在微信上接入

00:14:51.708 --> 00:14:52.668
办公场景

00:14:52.668 --> 00:14:54.808
我们就连飞书或起飞或丁丁

00:14:54.808 --> 00:14:56.748
我们也都支持

00:14:56.748 --> 00:14:57.148
对

00:14:57.148 --> 00:14:59.448
其实这是一个最大的不同

00:14:59.448 --> 00:15:00.628
像OpenCloud和Hermes

00:15:00.628 --> 00:15:01.668
他们都是个人Agent

00:15:01.668 --> 00:15:04.228
包括他们也只支持单人用户

00:15:04.228 --> 00:15:05.808
我们是多用户

00:15:05.808 --> 00:15:07.428
然后一人部署全家

00:15:07.428 --> 00:15:08.728
关键问题是

00:15:08.728 --> 00:15:09.908
你这个产品支持多少个通道

00:15:09.908 --> 00:15:11.068
我们这也有介绍的

00:15:11.068 --> 00:15:11.828
是的

00:15:11.828 --> 00:15:13.108
我们其实支持

00:15:13.108 --> 00:15:14.768
飞书丁丁 启威 QQ

00:15:14.768 --> 00:15:15.828
很多通道

00:15:15.828 --> 00:15:18.488
像我可以在这个里面

00:15:18.488 --> 00:15:20.528
这就是我们实际的产品面板

00:15:20.528 --> 00:15:21.808
可以给大家看一下

00:15:21.808 --> 00:15:24.088
支持微信 QQ 启威 启威 元宝

00:15:24.088 --> 00:15:25.988
包括华为的小益

00:15:25.988 --> 00:15:26.828
也小易都可以

00:15:26.828 --> 00:15:29.428
对包括这个MQTT也可以看

00:15:29.428 --> 00:15:32.148
刚刚我举例一个用户有多个专家

00:15:32.148 --> 00:15:34.488
他们每个人其实都可以配那么多的通道

00:15:34.488 --> 00:15:35.948
每个专家可以配多通道

00:15:35.948 --> 00:15:36.828
对是的

00:15:36.828 --> 00:15:38.348
那还是很全面的

00:15:38.348 --> 00:15:39.988
是的欢迎大家使用

00:15:39.988 --> 00:15:42.688
有用户在问我们官网地址是什么

00:15:42.688 --> 00:15:47.188
我们官网地址是好给大家放大一下

00:15:47.188 --> 00:15:50.748
请搜Github

00:15:50.748 --> 00:15:54.688
在我们Tencent Cloud项目下的OCTO

00:15:54.688 --> 00:15:58.088
对也欢迎大家记得支持我们的产品

00:15:58.088 --> 00:15:58.728
GateStar

00:15:58.728 --> 00:16:00.568
对那我现在回答现在一下这个用户

00:16:00.568 --> 00:16:02.248
QQ是不是只是单鸟

00:16:02.248 --> 00:16:04.368
如果是群鸟是不是还得用QQBot

00:16:04.368 --> 00:16:06.328
那么非常感谢这位用户的提问

00:16:06.328 --> 00:16:07.968
这个QQ群鸟现在已经支持了

00:16:07.968 --> 00:16:10.408
但是我们未来会继续拓展我们的QQ群鸟

00:16:10.408 --> 00:16:12.088
包括我们的QQ的一个多Agent

00:16:12.088 --> 00:16:14.128
会接入到我们的包括QQ频道

00:16:14.128 --> 00:16:15.768
我们也可以用家庭群

00:16:15.768 --> 00:16:17.208
我们也会接入我们的Agent

00:16:17.208 --> 00:16:19.208
每个家庭用户都有机会在里面提问

00:16:19.208 --> 00:16:20.208
这是我们下一步的打算

00:16:20.208 --> 00:16:21.688
没错可以多个Agent

00:16:21.688 --> 00:16:22.328
当然可以了

00:16:22.328 --> 00:16:25.688
我们当然可以用多个Agent在一个聊天框里面去执行共同任务

00:16:25.688 --> 00:16:26.688
的话我们会展示的

00:16:27.488 --> 00:16:29.568
对其实关于我讲的记忆的话

00:16:29.568 --> 00:16:31.088
像OpenCloud和Hermes

00:16:31.088 --> 00:16:33.168
他们其实都是把他们的MD

00:16:33.168 --> 00:16:36.288
加入就是系统提示词

00:16:36.288 --> 00:16:37.568
然后被读到

00:16:37.568 --> 00:16:42.968
你要记的时候就是叫OpenCloud和HermesAgent本身去写Memory的MD

00:16:42.968 --> 00:16:47.408
那我们其实讲到稍微提了一点关于沉淀和召回

00:16:47.408 --> 00:16:48.528
包括我们的牵引能力

00:16:48.528 --> 00:16:50.088
后续我会细讲

00:16:50.288 --> 00:16:51.768
对其实还有很多功能

00:16:51.768 --> 00:16:54.568
包括ACP其实刚刚有提到

00:16:56.868 --> 00:17:04.868
那其实我们和不管是Cloud Code还是Codex,甚至Codebody OpenCode,我们并不是竞品,我们其实是可以调用它们的能力的。

00:17:04.868 --> 00:17:07.628
因为Octop有个邪教ACP

00:17:07.628 --> 00:17:11.308
可以通过ACP就是连接上Codec和Code

00:17:11.308 --> 00:17:12.708
你如果想编程

00:17:12.708 --> 00:17:16.108
你想用更成熟的CodeAgent

00:17:16.108 --> 00:17:17.948
你就可以把任务委派给他们

00:17:17.948 --> 00:17:20.428
也是在我们Octop里是可以实现的

00:17:20.428 --> 00:17:22.988
有粉丝朋友问能自己部署吗

00:17:22.988 --> 00:17:23.468
可以的

00:17:23.468 --> 00:17:26.408
请关注我们的Octop Geekhub仓库

00:17:26.408 --> 00:17:28.048
然后在我们的ReadMe里

00:17:28.048 --> 00:17:30.348
有详细的字部署教程

00:17:30.348 --> 00:17:32.908
如果是想用镜上一键部署的话

00:17:32.908 --> 00:17:35.268
我们未来也会提供镜像

00:17:35.268 --> 00:17:37.708
可以在腾讯控制台直接购买

00:17:37.708 --> 00:17:40.068
也是使用腾讯轻量服务器

00:17:40.068 --> 00:17:42.708
对我们后续会提供轻量服务器的镜像

00:17:42.708 --> 00:17:43.108
很快

00:17:43.108 --> 00:17:44.248
本周或者下周

00:17:44.248 --> 00:17:46.608
我们现在有一点最后的工作

00:17:46.608 --> 00:17:47.548
我们即将会出

00:17:47.548 --> 00:17:49.848
对欢迎大家即使关注我们轻量

00:17:49.848 --> 00:17:52.228
我们会适时推出我们的Octop镜像

00:17:52.228 --> 00:17:53.488
也就是以前我们的ACE镜像

00:17:53.488 --> 00:17:55.508
用户也可以升级到Octop镜像

00:17:55.508 --> 00:17:56.828
对了我们的ACE是不是要升级了

00:17:56.828 --> 00:17:59.448
是的我们也会提供轻易工具

00:17:59.448 --> 00:18:01.408
既然说到这了

00:18:01.408 --> 00:18:03.708
那就给大家演示一下

00:18:03.708 --> 00:18:05.868
如果有我们的老用户的话

00:18:05.868 --> 00:18:10.028
可以更新到我们最新的0.1.31版本

00:18:10.028 --> 00:18:12.248
认准我们0.1.31版本

00:18:12.248 --> 00:18:13.908
在高级设置里

00:18:13.908 --> 00:18:15.848
可以看到一个导出到Octop

00:18:15.848 --> 00:18:18.988
然后这里就可以导出到Octop

00:18:18.988 --> 00:18:20.788
可以打包一个备份

00:18:20.788 --> 00:18:22.928
可以看到这个备份

00:18:22.928 --> 00:18:25.528
其实已经就是TAR包下下来了

00:18:25.528 --> 00:18:27.868
然后再打开我们的Octop

00:18:27.868 --> 00:18:29.588
然后再应用设置

00:18:29.588 --> 00:18:30.828
有个备份与恢复

00:18:30.828 --> 00:18:33.108
首先就上传我们刚刚

00:18:33.108 --> 00:18:35.968
你看这就是19.32刚刚那个备份

00:18:35.968 --> 00:18:37.708
我们把它上传了

00:18:37.708 --> 00:18:40.228
然后我们就点恢复

00:18:40.228 --> 00:18:42.968
请大家记住我们的用户名就是

00:18:42.968 --> 00:18:47.308
密码就是之前在LiteCloud设置的那个密码

00:18:47.308 --> 00:18:48.448
我们继续来学习

00:18:48.448 --> 00:18:51.768
其实刚刚给大家也讲了

00:18:51.768 --> 00:18:54.568
我们跟OpenCloud跟Hermas

00:18:54.568 --> 00:18:56.968
包括跟Cloudcode和Codex

00:18:56.968 --> 00:18:59.368
在产品上和记忆上有什么不同

00:18:59.368 --> 00:19:02.588
那Octop memory到底是怎么样的呢

00:19:02.588 --> 00:19:03.868
那就给大家

00:19:03.868 --> 00:19:06.808
其实我在PT里给大家做个比喻

00:19:06.808 --> 00:19:08.108
如果把我们的记忆

00:19:08.108 --> 00:19:09.668
比做成一家暴数

00:19:09.668 --> 00:19:11.048
那我们常驻的

00:19:11.048 --> 00:19:14.808
除了常驻的memory.md文件之外

00:19:14.808 --> 00:19:17.308
那其实我们刚刚其实介绍

00:19:17.308 --> 00:19:18.708
有个roll event

00:19:18.708 --> 00:19:20.028
它就是一个录音笔

00:19:20.028 --> 00:19:23.028
就是你跟Octop说了什么

00:19:23.028 --> 00:19:23.928
它都会记住

00:19:23.928 --> 00:19:26.208
然后它永远是一个证据员

00:19:26.208 --> 00:19:28.108
我们刚刚说到

00:19:28.108 --> 00:19:29.568
在记忆招回的时候

00:19:29.568 --> 00:19:31.148
不管招回的是哪条记忆

00:19:31.148 --> 00:19:32.728
最后都能refer

00:19:32.728 --> 00:19:36.168
就能溯源到你跟Octop的对话

00:19:36.168 --> 00:19:40.488
就是保证我们记忆永远是正确的一个机制

00:19:40.488 --> 00:19:42.168
所以它是一个录音笔

00:19:42.168 --> 00:19:44.168
下一层就是一个candidate

00:19:44.168 --> 00:19:45.368
就是记者初稿

00:19:45.368 --> 00:19:49.308
那就是大模型从原始对话中

00:19:49.308 --> 00:19:51.508
就是从用户跟Octop对话中

00:19:51.508 --> 00:19:53.588
抽取出的候选事实

00:19:53.588 --> 00:19:55.228
但是为什么是初稿呢

00:19:55.228 --> 00:19:56.608
因为它只是一个候选事实

00:19:56.608 --> 00:19:57.548
它还没有见报

00:19:57.548 --> 00:20:00.528
在Candidate这一层解决完冲突

00:20:00.528 --> 00:20:02.108
通过用户审核

00:20:02.108 --> 00:20:05.288
然后在重要性和置信度上面

00:20:05.288 --> 00:20:07.388
有所筛选之后

00:20:07.388 --> 00:20:10.368
然后它才会晋升成一个Atom Card

00:20:10.368 --> 00:20:12.068
就是一个正式简报

00:20:12.068 --> 00:20:14.008
当然这也是我们在

00:20:14.008 --> 00:20:16.628
就是我们的Octop面板中会看到的记忆

00:20:16.628 --> 00:20:18.948
它也是我们的召回主力层

00:20:18.948 --> 00:20:21.388
当然后面我们会讲到召回

00:20:21.388 --> 00:20:24.828
除此之外我们还有一个日记层

00:20:24.828 --> 00:20:28.488
那这个其实是除了上面的事实之外的东西

00:20:28.488 --> 00:20:30.808
就是一些装事实过滤掉的东西

00:20:30.808 --> 00:20:33.548
比如是生活事件和情绪

00:20:33.548 --> 00:20:36.088
它是和事实管线病情跑的

00:20:36.088 --> 00:20:36.808
并不污染

00:20:36.808 --> 00:20:39.528
了解我们AC和Octop的话

00:20:39.528 --> 00:20:41.948
知道我们会有一个主动关心机制

00:20:41.948 --> 00:20:45.768
那其实这个机制就是探查到用户的心情

00:20:45.768 --> 00:20:48.048
在用户开心的时候会鼓励他

00:20:48.048 --> 00:20:50.468
以及在用户低落的时候会安慰他

00:20:50.468 --> 00:20:54.048
然后在Octop里其实就是靠着我们这个日记层

00:20:54.048 --> 00:20:56.028
其实我们还有人物词条

00:20:56.028 --> 00:20:58.568
所有的正式建报的原子卡片

00:20:58.568 --> 00:21:00.868
都会在一个人物词条下

00:21:00.868 --> 00:21:04.668
它会把原子卡片归类到人物词条

00:21:04.668 --> 00:21:06.228
包括用户人物事实

00:21:06.228 --> 00:21:09.528
在这样就会每条原子卡片之间

00:21:09.528 --> 00:21:10.748
就会产生联系

00:21:10.748 --> 00:21:12.668
最后是神器流水

00:21:12.668 --> 00:21:15.908
因为听课的观众朋友们

00:21:15.908 --> 00:21:17.648
可能就会有问题

00:21:17.648 --> 00:21:20.428
那所有记忆的生成都靠大模型

00:21:20.428 --> 00:21:22.468
那它是怎么做的

00:21:22.468 --> 00:21:24.148
那其实就是神器流水

00:21:24.148 --> 00:21:26.028
它可以记住大模型

00:21:26.028 --> 00:21:27.828
从哪一条事实中

00:21:27.828 --> 00:21:30.428
那个对话中提取到了哪些候选

00:21:30.428 --> 00:21:32.148
候选怎么进生存原子卡片

00:21:32.148 --> 00:21:34.628
都会在我们的面板中一一显示

00:21:34.628 --> 00:21:36.508
包括删除 包括冲突

00:21:36.508 --> 00:21:36.908
对

00:21:36.908 --> 00:21:38.708
那其实我有一个小白的问题

00:21:38.708 --> 00:21:39.908
想问一下英明

00:21:39.908 --> 00:21:41.828
不知道直播间有没有类似的问题

00:21:41.828 --> 00:21:44.468
关于我们记忆它的一个沉淀和召回

00:21:44.468 --> 00:21:45.508
它具体指的是什么

00:21:45.508 --> 00:21:46.708
是这个概念怎么理解

00:21:46.708 --> 00:21:47.828
记忆的沉淀

00:21:47.828 --> 00:21:49.228
像焦焦其实有在

00:21:49.228 --> 00:21:50.828
一样OpenCloud和Hermes

00:21:50.828 --> 00:21:52.268
那比如说

00:21:52.468 --> 00:21:56.108
那你最近一个问你的Hermas的问题是什么

00:21:56.108 --> 00:21:58.968
焦焦你可以告诉我们你在什么一个场景下用了它

00:21:58.968 --> 00:22:04.688
就比如说最近一次让他帮我撰写一下我们这个直播的整个的策划

00:22:04.688 --> 00:22:08.088
对那关于你和他在这个对话中

00:22:08.088 --> 00:22:10.268
那记忆的沉淀他会记住

00:22:10.268 --> 00:22:15.828
我的主人焦焦那今天其实是叫我帮忙撰写这个直播的计划

00:22:15.828 --> 00:22:18.728
那他会根据你给他提示词沉淀一下

00:22:18.728 --> 00:22:22.068
焦焦在今天那他参与了主题什么什么的直播

00:22:22.068 --> 00:22:23.788
他就会根据你的对话

00:22:23.788 --> 00:22:25.768
然后记住一些有用的事实

00:22:25.768 --> 00:22:27.648
或者你今天做的事情

00:22:27.648 --> 00:22:29.048
这就是记得沉淀

00:22:29.048 --> 00:22:29.868
对

00:22:29.868 --> 00:22:32.168
那什么是召回呢

00:22:32.168 --> 00:22:33.288
那比如说

00:22:33.288 --> 00:22:35.008
那下次直播的时候

00:22:35.008 --> 00:22:38.408
如果你再跟你的龙虾对话

00:22:38.408 --> 00:22:41.008
其实如果就是人与人之间对话

00:22:41.008 --> 00:22:41.588
比如说

00:22:41.588 --> 00:22:42.928
比如说我昨天跟杨子说

00:22:42.928 --> 00:22:44.428
那我可能昨天跟杨子说

00:22:44.428 --> 00:22:45.348
我最近有点烧火

00:22:45.348 --> 00:22:47.048
那可能我今天说

00:22:47.048 --> 00:22:48.968
OK我要去吃炸鸡

00:22:48.968 --> 00:22:50.548
那杨子就会响起

00:22:50.548 --> 00:22:52.948
那我说我昨天有点上火

00:22:52.948 --> 00:22:55.568
他就会可能想起这个相关性

00:22:55.568 --> 00:22:57.728
那其实agent也会这样

00:22:57.728 --> 00:22:59.188
如果你下次跟他说

00:22:59.188 --> 00:23:01.368
你又要撰写一个直播的

00:23:01.368 --> 00:23:03.608
PPT或者直播的大纲了

00:23:03.608 --> 00:23:05.648
他应该像人一样想起

00:23:05.648 --> 00:23:07.708
你之前跟他说过的相似的对话

00:23:07.708 --> 00:23:10.468
然后来帮助你更好的去优化你的工作

00:23:10.468 --> 00:23:12.408
工作这就是记忆的召回

00:23:12.408 --> 00:23:13.808
了解了

00:23:13.808 --> 00:23:14.708
好的学到了

00:23:14.708 --> 00:23:16.648
那其实刚刚讲那么多

00:23:16.648 --> 00:23:19.008
那就来实力演练一下

00:23:19.008 --> 00:23:24.468
那假如这个用户在一台安装了OctopMemory的agent上说

00:23:24.468 --> 00:23:26.488
跟这个agent说

00:23:26.488 --> 00:23:29.028
那这个项目暂时先别上PG了

00:23:29.028 --> 00:23:30.188
PG就是一个数据库

00:23:30.188 --> 00:23:32.888
说本地SecureLights已经够用了

00:23:32.888 --> 00:23:34.628
说他下周要去上海出差

00:23:34.628 --> 00:23:35.348
有点焦虑

00:23:35.348 --> 00:23:38.288
那其实这句话包含了很多信息

00:23:38.288 --> 00:23:40.808
首先L0层就是我们刚刚的事实

00:23:40.808 --> 00:23:41.588
就是录音笔

00:23:41.588 --> 00:23:44.508
他会把这句话记下来

00:23:44.508 --> 00:23:45.708
在录音笔之外

00:23:45.708 --> 00:23:47.288
到了我们的候选事实

00:23:47.288 --> 00:23:49.348
那一有日记

00:23:49.348 --> 00:23:51.248
下周去上海出差有点焦虑

00:23:51.248 --> 00:23:54.528
因为这只是一个一时的心情

00:23:54.528 --> 00:23:57.668
他可能在工作中不太会被需要

00:23:57.668 --> 00:24:00.488
那这个项目不用PG

00:24:00.488 --> 00:24:01.308
用CircleLite

00:24:01.308 --> 00:24:03.548
这可能就是一个工具强相关的事实

00:24:03.548 --> 00:24:05.368
那心情就进日记

00:24:05.368 --> 00:24:07.308
事实就进我们的候选卡片

00:24:07.308 --> 00:24:10.008
那就说到了刚刚的五层

00:24:10.008 --> 00:24:13.608
那看看他的自信度和重要性够吗

00:24:13.608 --> 00:24:15.768
有没有可以录音证据

00:24:15.768 --> 00:24:17.388
用0的原始试试程

00:24:17.388 --> 00:24:19.388
到底能不能被指导

00:24:19.388 --> 00:24:20.628
如果被指导

00:24:20.628 --> 00:24:22.368
那我们就要进生成

00:24:22.368 --> 00:24:24.208
就是正式的原子卡片了

00:24:24.208 --> 00:24:26.408
那我们这个原子卡片里

00:24:26.408 --> 00:24:27.608
有没有一个实体

00:24:27.608 --> 00:24:29.028
可以让它归类

00:24:29.028 --> 00:24:29.748
如果有的话

00:24:29.748 --> 00:24:30.988
那就装进这个实体

00:24:30.988 --> 00:24:33.808
没有就重新去生成一个实体

00:24:33.808 --> 00:24:34.988
我再看看

00:24:34.988 --> 00:24:37.228
跟数据库里的事实

00:24:37.228 --> 00:24:37.908
有没有冲突

00:24:37.908 --> 00:24:39.748
可能我们数据库里面

00:24:39.748 --> 00:24:41.308
三个月前有一条事实是

00:24:41.308 --> 00:24:44.468
那我们就要用PG做足裤

00:24:44.468 --> 00:24:46.588
然后当我们现在说了一句话

00:24:46.588 --> 00:24:48.068
是别上PG了

00:24:48.068 --> 00:24:49.748
他就检测到有冲突

00:24:49.748 --> 00:24:51.468
那他其实就会触发

00:24:51.468 --> 00:24:54.048
刚刚我们演示的那个有冲突

00:24:54.048 --> 00:24:54.848
那就等待用

00:24:56.968 --> 00:25:00.068
這就是我們整體的一個沉澱路線了。

00:25:00.068 --> 00:25:03.868
那下面其實講解就是G的最後一部分,就是召回。

00:25:03.868 --> 00:25:08.368
那召回那又是一個實力演練,一個舉例。

00:25:08.368 --> 00:25:10.408
如果一个用户就是问

00:25:10.408 --> 00:25:13.768
那个项目的当时的数据库是怎么定的来着

00:25:13.768 --> 00:25:16.608
那首先会去查一个缓存

00:25:16.608 --> 00:25:20.088
看这个缓存里有没有相关的关键字

00:25:20.088 --> 00:25:20.608
如果没有

00:25:20.608 --> 00:25:24.488
那就直接去进行一个用BM25

00:25:24.488 --> 00:25:27.288
就是我们的一个招回的一个算法

00:25:27.288 --> 00:25:28.648
然后去搜索

00:25:28.648 --> 00:25:31.608
那有没有相应的原子卡片

00:25:31.608 --> 00:25:32.608
那搜到了

00:25:32.608 --> 00:25:34.768
就是我们刚刚说的

00:25:34.768 --> 00:25:38.168
那Octob这个暂时先不用PG了

00:25:38.168 --> 00:25:39.928
先用本地的Syculate

00:25:39.928 --> 00:25:41.828
它就是搜到之后

00:25:41.828 --> 00:25:44.308
它就可以回答用户的这个问题了

00:25:44.308 --> 00:25:48.928
就是它的一个运行的内在机制的原理是吗

00:25:48.928 --> 00:25:50.908
一步一步是如何运作的

00:25:50.908 --> 00:25:51.628
对的

00:25:51.628 --> 00:25:54.028
其实还有很多细节

00:25:54.028 --> 00:25:55.508
但是我们未来实在不

00:25:55.508 --> 00:25:56.688
在很近的未来

00:25:56.688 --> 00:25:58.228
马上就会把我们的记忆开远

00:25:58.228 --> 00:26:01.848
感兴趣的朋友也可以先关注我们的Octop

00:26:01.848 --> 00:26:04.308
后续我们的Octop Memory

00:26:04.308 --> 00:26:07.208
也会随之在Tencent Cloud下面开远的

00:26:07.208 --> 00:26:09.528
如果说以后再云服务器

00:26:09.528 --> 00:26:11.228
部署了是不是只有国外的服务器

00:26:11.228 --> 00:26:13.408
可以去调用GPT的模型呢

00:26:13.408 --> 00:26:14.588
是的

00:26:14.588 --> 00:26:17.008
调用GPT的模型

00:26:17.008 --> 00:26:18.528
其实是取决于GPT

00:26:18.528 --> 00:26:20.828
它本身可以在哪个地位调用

00:26:20.828 --> 00:26:23.008
那如果在中国

00:26:23.008 --> 00:26:25.468
或者在哪里

00:26:25.468 --> 00:26:26.608
不能访问GPT

00:26:26.608 --> 00:26:27.768
你就是调用不了

00:26:27.768 --> 00:26:30.548
你只能在能调用GPT地域的服务器

00:26:30.548 --> 00:26:32.568
然后去调用到GPT

00:26:32.568 --> 00:26:32.888
对

00:26:32.888 --> 00:26:36.428
问目前Optop采用默认Q-Lite

00:26:36.428 --> 00:26:41.168
而不用PG是出于怎样的考虑呢

00:26:41.168 --> 00:26:43.188
这各位粉丝朋友问得很好

00:26:43.188 --> 00:26:45.068
其实我们现在也支持PG了

00:26:45.068 --> 00:26:46.908
但是默认是Ciclite

00:26:46.908 --> 00:26:50.728
一是可以支持用户一键安装完就可以使用

00:26:50.728 --> 00:26:53.108
默认就是在本地创建一个Ciclite

00:26:53.108 --> 00:26:54.328
这个服务就可以用了

00:26:54.328 --> 00:26:58.288
然后也不是说需要用户去建一个PG配置

00:26:58.288 --> 00:26:59.768
那如果有高端用户

00:26:59.768 --> 00:27:01.108
如果想做分布式

00:27:01.108 --> 00:27:01.708
想用PG

00:27:01.708 --> 00:27:03.988
我们其实也是完全可以支持PG

00:27:03.988 --> 00:27:05.848
对这个能力我们现在已经支持了

00:27:05.848 --> 00:27:10.848
对,那其实今天记忆讲的其实就是这么多了

00:27:10.848 --> 00:27:15.848
那如果大家还有后续问题可以一是在我们的GitHub主页上给我们提问

00:27:15.848 --> 00:27:18.848
二是进入我们的用户群,然后提问

00:27:18.848 --> 00:27:23.848
这个直播的下半场其实要有请我们杨纸给大家做一些实力的介绍

00:27:23.848 --> 00:27:25.848
好的,大家好,我叫杨纸

00:27:25.848 --> 00:27:29.848
那我来和大家分享一下我们的多专家多Agent的病情,如何来重复我们的进行

00:27:29.848 --> 00:27:35.728
我想问问您有没有在比如说CodeBody或者是WorkBody里面使用过多Agent多专家

00:27:35.728 --> 00:27:37.348
想教教我们是不是有经常去使用

00:27:37.348 --> 00:27:38.728
那我先说确实

00:27:38.728 --> 00:27:42.268
比如让WorkBody帮我做某一个PT的时候

00:27:42.268 --> 00:27:48.808
他其实自己先是会调用一下很多Agent去分别做一些小步骤的事情

00:27:48.808 --> 00:27:49.728
最后再汇总

00:27:49.728 --> 00:27:51.808
然后多专家我其实也有体验到

00:27:51.808 --> 00:27:56.728
因为熟悉WorkBody的朋友应该知道可以在一个项目里增加很多专家

00:27:56.728 --> 00:27:58.648
你就可以去调用这些专家的努力

00:27:58.648 --> 00:28:00.108
对那么我们的

00:28:00.108 --> 00:28:02.188
也是具备这么大的能力

00:28:02.188 --> 00:28:02.988
包括像您如果在

00:28:02.988 --> 00:28:03.708
QQ通道里面

00:28:03.708 --> 00:28:05.008
我们可以支持家庭去聊

00:28:05.008 --> 00:28:05.708
包括微信通道

00:28:05.708 --> 00:28:06.388
如果以后开通了

00:28:06.388 --> 00:28:07.308
我们会相信支持

00:28:07.308 --> 00:28:08.188
然后还有一些用户

00:28:08.188 --> 00:28:08.748
还在提问

00:28:08.748 --> 00:28:10.308
有没有agent team的想法

00:28:10.308 --> 00:28:11.988
对我们现在正在调研agent team

00:28:11.988 --> 00:28:13.188
也是在不久之后

00:28:13.188 --> 00:28:14.088
也会推出agent team

00:28:14.088 --> 00:28:14.988
那么我就回到了正题

00:28:14.988 --> 00:28:16.548
我们讲一讲我们的多次能题

00:28:16.548 --> 00:28:18.488
我们的就刚和大家多聊了

00:28:18.488 --> 00:28:19.848
觉得专家其实

00:28:19.848 --> 00:28:20.748
确实用的挺多的

00:28:20.748 --> 00:28:22.108
不管是Ethan Giorg之前

00:28:22.108 --> 00:28:23.248
直播的育儿专家

00:28:23.248 --> 00:28:25.048
包括现在我们大家

00:28:25.048 --> 00:28:25.788
在用workbody

00:28:25.788 --> 00:28:26.908
去做一些竞品类的

00:28:26.908 --> 00:28:28.308
一个调研专家

00:28:28.308 --> 00:28:30.748
那么我们今天就会给大家来实战演练一下

00:28:30.748 --> 00:28:33.908
我想想你你可能是不还是会经常遇见老板会给你

00:28:33.908 --> 00:28:35.468
下发一个很艰巨的任务

00:28:35.468 --> 00:28:36.428
叫你去完成呢

00:28:36.428 --> 00:28:37.148
是的

00:28:37.148 --> 00:28:41.788
对其实像我们同事之间也会有经常像

00:28:41.788 --> 00:28:46.948
包括我们在研究这种比较新的产品也会需要调研很多东西

00:28:46.948 --> 00:28:47.268
对的

00:28:47.268 --> 00:28:48.868
像有一个传统像OpenCloud

00:28:48.868 --> 00:28:51.588
他只支持就是说你在一个亲户里面

00:28:51.588 --> 00:28:54.668
可能只是单个agent在那里给你调研究

00:28:54.668 --> 00:28:55.348
其实它非常慢

00:28:55.348 --> 00:28:56.308
现在我们在ACE

00:28:56.308 --> 00:28:58.028
假如我的一个老板下午要求我

00:28:58.028 --> 00:29:00.388
去调研一下想必大家都在喝茶饮

00:29:00.388 --> 00:29:01.628
比如说洗茶耐血

00:29:01.628 --> 00:29:02.668
比如说帮忙茶几

00:29:02.668 --> 00:29:04.488
老板会比较关心里面的产品

00:29:04.488 --> 00:29:06.828
竞品如何调研价格产品营销

00:29:06.828 --> 00:29:09.068
往往你期间的OpenCloud可能是单A进程

00:29:09.068 --> 00:29:10.368
它的调研会非常慢

00:29:10.368 --> 00:29:12.348
那么我们的Octop显然是领先于它的

00:29:12.348 --> 00:29:14.668
我们的很多进程可以帮助大家很快的调研跟它报告

00:29:14.668 --> 00:29:15.748
我现在给大家展示一下

00:29:15.748 --> 00:29:17.708
比如说老板要求我完成这个

00:29:17.708 --> 00:29:19.088
传统的做法就是三个牌子

00:29:19.088 --> 00:29:20.168
挨一个的时候整理一个晚上

00:29:20.168 --> 00:29:22.068
然后每个A进程之间还不太交互的通

00:29:22.068 --> 00:29:24.148
我们在我们的Octop里面

00:29:24.148 --> 00:29:26.188
首先我们有非常多的类似的一个专家

00:29:26.188 --> 00:29:27.428
也有一些专家市场

00:29:27.428 --> 00:29:29.148
我们是对接的Token Hub的专家市场

00:29:29.148 --> 00:29:31.308
有电商的金融的内容的

00:29:31.308 --> 00:29:32.348
如果大家有喜欢的

00:29:32.348 --> 00:29:33.548
就从这点击一下

00:29:33.548 --> 00:29:34.388
来从市场创建

00:29:34.388 --> 00:29:36.708
这就可以创建我们的网闻小说创作家

00:29:36.708 --> 00:29:39.508
那这个配置专家的过程还是很方便的

00:29:39.508 --> 00:29:40.268
对对对的

00:29:40.268 --> 00:29:41.428
如果大家默认

00:29:41.428 --> 00:29:44.188
为了防止大家经常从专家市场下比较慢

00:29:44.188 --> 00:29:45.148
所以我们还有类似专家

00:29:45.148 --> 00:29:47.308
业的专家下载后会类似到这里面

00:29:47.308 --> 00:29:49.228
比如说我之前装了竞品分析专家

00:29:49.228 --> 00:29:52.068
那我们今天就用剂米分加来实战演练一下

00:29:52.068 --> 00:29:53.128
那么就讲解题

00:29:53.128 --> 00:29:57.828
我看有粉丝朋友问Octop记忆模块代码是独立解藕的

00:29:57.828 --> 00:30:00.428
还是与其他意见组件存在编译期以外

00:30:00.428 --> 00:30:02.228
是完全独立解藕的

00:30:02.228 --> 00:30:04.728
刚刚其实这个记忆模块也可以跟

00:30:04.728 --> 00:30:07.328
现在是支持跟Otom Cloud 跟Hermas都一起用

00:30:07.328 --> 00:30:09.928
我们后续会推出完整的教程

00:30:09.928 --> 00:30:10.328
对

00:30:10.328 --> 00:30:12.728
那我们去玩一个很好玩的一个东西

00:30:12.728 --> 00:30:13.928
英宁 你吃豆河佬吗

00:30:13.928 --> 00:30:15.028
我吃

00:30:15.028 --> 00:30:18.928
那那个像佼佼们到底豆河佬喜欢吃甜的

00:30:18.928 --> 00:30:19.728
还是喜欢吃咸的

00:30:19.728 --> 00:30:21.128
或者是川芸人喜欢吃辣的

00:30:21.128 --> 00:30:23.988
我肯定是坚定的吃咸的

00:30:23.988 --> 00:30:25.088
豆腐脑的这一派

00:30:25.088 --> 00:30:26.008
我肯定占咸

00:30:26.008 --> 00:30:27.188
大家有吃甜的吗

00:30:27.188 --> 00:30:28.708
大家豆腐脑有吃甜的吗

00:30:28.708 --> 00:30:31.008
我其实是吃甜的

00:30:31.008 --> 00:30:31.588
不好意思

00:30:31.588 --> 00:30:33.408
我们三个人吃三种口味

00:30:33.408 --> 00:30:35.348
我们三个人刚好吃三种口味

00:30:35.348 --> 00:30:36.188
对

00:30:36.188 --> 00:30:39.048
那我们来让我们的美食专家来评判一下

00:30:39.048 --> 00:30:41.028
我们这有一个营养规划专家

00:30:41.028 --> 00:30:42.328
豆腐脑也是要有营养的

00:30:42.328 --> 00:30:43.008
我们来问问他

00:30:43.008 --> 00:30:44.228
是的

00:30:44.228 --> 00:30:45.788
我们现在是在等

00:30:45.788 --> 00:30:48.188
竞品分析专家在给我们做调研

00:30:48.188 --> 00:30:50.268
在等待他做调研的过程中

00:30:50.268 --> 00:30:52.568
我们来做一个多agent的博弈

00:30:52.568 --> 00:30:53.728
这样子的一个演示

00:30:53.728 --> 00:30:56.228
给大家更加实战地去看一下

00:30:56.228 --> 00:30:57.748
Oxop他的多agent之间

00:30:57.748 --> 00:30:58.748
如何去思考

00:30:58.748 --> 00:30:59.508
如何去博弈

00:30:59.508 --> 00:31:02.088
那么我们也是以这个豆腐脑为例

00:31:02.088 --> 00:31:03.448
我们来看一下这个agent

00:31:03.448 --> 00:31:04.568
如何做裁决

00:31:04.568 --> 00:31:05.328
已经结束了

00:31:05.328 --> 00:31:05.808
我们可以看到

00:31:05.808 --> 00:31:07.608
刚才他其实是调用了三个工具的

00:31:07.608 --> 00:31:09.868
确实是分发了给不同的agent

00:31:09.868 --> 00:31:11.468
然后下发了他的任务

00:31:11.468 --> 00:31:12.608
你是一个辣打的专家

00:31:12.608 --> 00:31:13.248
或者你穿越人

00:31:13.248 --> 00:31:14.908
好 完整交换就来了

00:31:14.908 --> 00:31:15.468
第一轮呢

00:31:15.468 --> 00:31:16.808
我们的甜党先说了

00:31:16.808 --> 00:31:17.388
就是甜味

00:31:17.388 --> 00:31:19.068
像英宁肯定是非常喜欢吃甜的

00:31:19.068 --> 00:31:21.028
它可能存在比较幸福的记忆

00:31:21.028 --> 00:31:21.628
我就比较清楚

00:31:21.628 --> 00:31:23.528
咸党可能说的是没有咸味

00:31:23.528 --> 00:31:25.388
像一个焦焦比较喜欢吃咸的

00:31:25.388 --> 00:31:26.628
比较沉稳的

00:31:26.628 --> 00:31:28.408
像我当然就喜欢吃辣

00:31:28.408 --> 00:31:30.968
小川水人必须吃火锅都必须吃辣

00:31:30.968 --> 00:31:32.928
他们就开始第二轮的相互攻击了

00:31:32.928 --> 00:31:35.048
那么甜党就开始调侃了一个咸党

00:31:35.048 --> 00:31:35.788
说它单调

00:31:35.788 --> 00:31:37.288
辣的确实伤胃味

00:31:37.288 --> 00:31:38.668
现在是比较优雅的

00:31:38.668 --> 00:31:39.968
攻势还比较强硬

00:31:39.968 --> 00:31:42.048
那么咸党又直接了一个甜党的比较幼稚

00:31:42.048 --> 00:31:43.228
它有一个非常频繁的一个金句

00:31:43.228 --> 00:31:45.228
就叫做辣味上头舌头直接化工

00:31:45.228 --> 00:31:46.428
这和做机会有小区别

00:31:46.428 --> 00:31:48.828
说明参与人其实不太想救美食的

00:31:48.828 --> 00:31:50.828
这种口感可能还是比较喜欢辣味

00:31:50.828 --> 00:31:51.828
就盖过了全味

00:31:51.828 --> 00:31:54.428
辣就开始反进来嘲讽我们的田党说

00:31:54.428 --> 00:31:55.828
田党农院活化在童话世界

00:31:55.828 --> 00:31:56.828
因为田田的甜妹

00:31:56.828 --> 00:31:57.828
田党农院是配角

00:31:57.828 --> 00:31:59.628
也是比较精彩的一个博弈

00:31:59.628 --> 00:32:01.228
我们看主义镜党的台办

00:32:01.228 --> 00:32:02.428
他可能读取了我的记忆

00:32:02.428 --> 00:32:03.828
他觉得可能是辣的显身

00:32:03.828 --> 00:32:06.028
首先是辣味他可能带来了记忆点

00:32:06.028 --> 00:32:07.628
甜和咸都太日常了

00:32:07.628 --> 00:32:08.828
但是说句公道话

00:32:08.828 --> 00:32:11.028
我觉得其实豆腐老师甜的也挺好吃的

00:32:11.028 --> 00:32:11.708
包括吃咸的

00:32:11.708 --> 00:32:13.148
开始端水

00:32:13.148 --> 00:32:16.328
那我们Octop那是没有杨之会端水是吧

00:32:16.328 --> 00:32:18.508
他还真的评出辣当品生

00:32:18.508 --> 00:32:20.028
我看专幕也说了

00:32:20.028 --> 00:32:21.028
要吃就要吃两碗

00:32:21.028 --> 00:32:22.348
要先吃甜的再吃咸的

00:32:22.348 --> 00:32:23.108
说明我们的用户

00:32:23.108 --> 00:32:25.028
不一定非得吃某一个口味的

00:32:25.028 --> 00:32:28.228
其实我们也可以再看一下我们这个博弈的过程

00:32:28.228 --> 00:32:30.588
杨之也可以帮我们再讲解

00:32:30.588 --> 00:32:34.228
那这个过程其实我们是主动调用了几个agent

00:32:34.228 --> 00:32:35.688
是如何进行博弈

00:32:35.688 --> 00:32:38.088
哪一个agent来进行裁决的呢

00:32:38.088 --> 00:32:39.728
那在这里我们有一个主Agent

00:32:39.728 --> 00:32:41.208
因为子Agent和主Agent

00:32:41.208 --> 00:32:42.368
大概有这么一个概念

00:32:42.648 --> 00:32:44.368
子Agent它是一个现存的概念

00:32:44.528 --> 00:32:45.968
它用完之后它就消失了

00:32:45.968 --> 00:32:47.808
它会和其他的Agent去对话

00:32:48.128 --> 00:32:49.888
所以它必须要把他收到的任务的答案

00:32:49.888 --> 00:32:51.288
交还给主Agent

00:32:51.688 --> 00:32:53.848
所以到这我们是一个主从事的结构

00:32:53.848 --> 00:32:54.868
所以必须要让主Agent

00:33:09.868 --> 00:33:11.868
他们分别完成后互相看不见

00:33:11.868 --> 00:33:14.668
在后面的户对环节开始通过主要进展图

00:33:14.668 --> 00:33:17.468
传递给大家每个党派的一个反驳的意见

00:33:17.468 --> 00:33:19.148
最后主要进行裁判

00:33:19.148 --> 00:33:20.388
该觉得哪个比较好

00:33:20.388 --> 00:33:24.908
那这里是不是其实平时我们在做调研任务

00:33:24.908 --> 00:33:28.788
或者我们比如有个家长想帮小朋友

00:33:28.788 --> 00:33:32.668
看看怎么去收集一些作文素材

00:33:32.668 --> 00:33:36.268
是不是其实也可以是给我们Octop分发一个任务

00:33:36.268 --> 00:33:40.228
让一个子agent去收集关于历史的素材

00:33:40.228 --> 00:33:43.108
另一个子agent去收集关于感动故事

00:33:43.108 --> 00:33:45.948
另一个子agent去收集关局名言名言

00:33:45.948 --> 00:33:47.108
是不是也是一样的道理

00:33:47.108 --> 00:33:47.988
我觉得这个场景非常好

00:33:47.988 --> 00:33:50.348
因为像我们可能观看的观众里面

00:33:50.348 --> 00:33:52.588
有一些家长朋友们也比较关心这个问题

00:33:52.588 --> 00:33:54.388
那么我要来回答一下大家的这个问题

00:33:54.388 --> 00:33:55.988
像比如说在Talk里面

00:33:55.988 --> 00:33:58.028
比如说我们的有很多的子agent

00:33:58.028 --> 00:33:59.628
在我们的有一些学术的子agent

00:33:59.628 --> 00:34:00.988
比如说像英琳刚刚说的

00:34:00.988 --> 00:34:01.868
我们有地理专家

00:34:01.868 --> 00:34:03.708
父母觉得如果地理孩子定义成绩不好

00:34:03.708 --> 00:34:05.708
那么可以叫他做一份地理的PDF报告

00:34:05.708 --> 00:34:08.808
交付款给答应出来给我们的一个小朋友

00:34:08.808 --> 00:34:09.768
就跟他们去阅读

00:34:09.768 --> 00:34:11.548
我们等于TOP之前是非常支持的

00:34:11.548 --> 00:34:14.628
包括我看我们刚刚的调研报告也是很顺利的出来了

00:34:14.628 --> 00:34:17.848
你看包括我们在这里是很交付了一个PDF文件

00:34:17.848 --> 00:34:19.928
MD文件到时候可以转化为PDF

00:34:19.928 --> 00:34:24.448
像用户朋友们就可以在这里去下载到本地之后就可以使用

00:34:24.448 --> 00:34:27.228
我相信家长朋友们可能还是比较喜欢给孩子分发中研

00:34:27.228 --> 00:34:28.268
也应该比较喜欢这个功能

00:34:28.268 --> 00:34:29.368
那话不多说了

00:34:29.368 --> 00:34:31.728
我们就看看这个调研报告它竟然都做出来了

00:34:31.728 --> 00:34:34.428
那我们先看报告之前

00:34:34.428 --> 00:34:38.508
其实我想问那杨主持人你最喜欢的奶茶是什么牌子

00:34:38.508 --> 00:34:40.268
我其实比较喜欢爆炎茶几

00:34:40.268 --> 00:34:40.988
那焦焦

00:34:40.988 --> 00:34:43.828
我其实想喜欢喜茶多一点

00:34:43.828 --> 00:34:46.568
好吧那没有人是点门

00:34:46.568 --> 00:34:48.648
我就是一点点大头

00:34:48.648 --> 00:34:49.888
虽然一点点不在这

00:34:49.888 --> 00:34:50.968
一点点很老

00:34:50.968 --> 00:34:52.688
但我就是坚定的点门人

00:34:52.688 --> 00:34:57.568
好那我们继续看这个新品牌茶饮三巨头的调研报告吧

00:34:57.568 --> 00:34:58.528
然后我放大一下

00:34:58.528 --> 00:35:00.888
供大家可以很好的查看

00:35:00.888 --> 00:35:02.708
好应该是大概调研报告

00:35:02.708 --> 00:35:03.828
因为我们这有一些折地功能

00:35:03.828 --> 00:35:06.188
大家如果想这样看就非常方便

00:35:06.188 --> 00:35:07.068
也可以这样看

00:35:07.068 --> 00:35:08.108
也支持斜着看

00:35:08.108 --> 00:35:09.388
我们都非常支持的

00:35:09.628 --> 00:35:11.468
比如说像现在右半边

00:35:11.468 --> 00:35:12.388
右半边看了

00:35:12.388 --> 00:35:13.388
或者是下面看

00:35:13.388 --> 00:35:14.028
我们都非常支持

00:35:14.028 --> 00:35:15.308
那么显然就为了放中间

00:35:15.308 --> 00:35:16.388
让大家看得比较清楚

00:35:16.388 --> 00:35:18.228
这是不是就是三折叠

00:35:18.228 --> 00:35:19.828
怎么这么多有边

00:35:19.828 --> 00:35:20.588
对的对的

00:35:20.588 --> 00:35:21.148
放大一点

00:35:21.148 --> 00:35:22.828
让大家都比较都很好的看清楚

00:35:22.828 --> 00:35:24.228
像我们的一个G2报告

00:35:24.228 --> 00:35:26.108
已经茶饮你的老板给你派火了

00:35:26.108 --> 00:35:26.988
你就很快的出来

00:35:26.988 --> 00:35:28.548
首先它生成了行业的总染

00:35:28.548 --> 00:35:30.068
比如说茶饮现在可能进入一个

00:35:30.068 --> 00:35:30.708
纯粮博弈

00:35:30.708 --> 00:35:32.028
可能现在进入比较激烈了

00:35:32.028 --> 00:35:32.828
那它也调研了

00:35:32.828 --> 00:35:33.688
像密血冰城

00:35:33.688 --> 00:35:34.808
它也不止调研这三个

00:35:34.808 --> 00:35:35.988
像密血冰城比较便宜的

00:35:35.988 --> 00:35:36.768
也有人喜欢的

00:35:36.768 --> 00:35:37.328
薄牙绝权

00:35:37.328 --> 00:35:38.568
帮忙查记忆的一个产品

00:35:38.568 --> 00:35:40.868
如果稍微贵点的

00:35:40.868 --> 00:35:42.908
可能大家可以去喝喜茶和赖雪

00:35:42.908 --> 00:35:43.748
但是对我来说

00:35:43.748 --> 00:35:45.108
可能帮忙查记忆到价格适中的

00:35:45.108 --> 00:35:46.328
包括它也非常

00:35:46.328 --> 00:35:46.948
你可以看到Octob

00:35:46.948 --> 00:35:49.188
它是比较了三个的一个创立时间

00:35:49.188 --> 00:35:50.728
包括它一个高端定位

00:35:50.728 --> 00:35:51.788
喜茶的是高端定位

00:35:51.788 --> 00:35:53.628
赖雪的茶号称星巴克

00:35:53.628 --> 00:35:56.068
我想问一下杨直

00:35:56.068 --> 00:35:57.888
我们的Octob在搜索到

00:35:57.888 --> 00:35:58.868
这些信息的时候

00:35:58.868 --> 00:36:01.948
是它主动去有搜索到

00:36:01.948 --> 00:36:03.388
准确的一些信息源吗

00:36:03.388 --> 00:36:04.908
就这些最新的数据

00:36:04.908 --> 00:36:05.548
当然的

00:36:05.548 --> 00:36:07.028
那Octop它的整个呢

00:36:07.028 --> 00:36:09.288
它是抓取的是我们最新的一个数据

00:36:09.288 --> 00:36:10.428
如果这个数据没有了

00:36:10.428 --> 00:36:12.828
它会去查另外的也很多的一个数据

00:36:12.828 --> 00:36:15.748
包括一些非常非常实时的一些网站

00:36:15.748 --> 00:36:16.828
都可以很好的查询到

00:36:16.828 --> 00:36:18.908
那评论区的大家可以放心

00:36:18.908 --> 00:36:21.428
我们Octop做出来的调研分析呢

00:36:21.428 --> 00:36:22.968
数据是绝对准确的

00:36:22.968 --> 00:36:24.548
大家可以放心使用

00:36:24.548 --> 00:36:26.208
对包括我们Octop

00:36:26.208 --> 00:36:28.528
其实也有一个自建的搜索引擎

00:36:28.528 --> 00:36:30.548
所以大家可能在用

00:36:30.548 --> 00:36:32.148
OpenCloud和Hermes的时候

00:36:32.148 --> 00:36:33.588
其实有偶尔感受到

00:36:33.588 --> 00:36:36.508
如果不自己去配那种付费搜索引擎

00:36:36.508 --> 00:36:38.668
或者配那种专门的search key

00:36:38.668 --> 00:36:41.148
它的搜索功能或许有些许缺陷

00:36:41.148 --> 00:36:44.468
但是我们Octop其实内置了一个专业的搜索引擎

00:36:44.468 --> 00:36:47.108
所以大家可以放心用我们Octop做调研

00:36:47.108 --> 00:36:48.428
还有我想给大家说的

00:36:48.428 --> 00:36:49.788
可能有些用户没有拒绝的

00:36:49.788 --> 00:36:51.628
AI只能把你生成

00:36:51.628 --> 00:36:52.228
你不能改

00:36:52.228 --> 00:36:54.988
我和Top现在我们是可以直接在里面修改

00:36:54.988 --> 00:36:57.388
他给你说了交付的是管理层

00:36:57.388 --> 00:36:58.828
你显然老板不希望看到这个

00:36:58.828 --> 00:36:59.788
因为你不能呼噜

00:36:59.788 --> 00:37:00.748
然后你可以把它删掉

00:37:00.748 --> 00:37:01.528
然后保存下来

00:37:01.528 --> 00:37:02.808
你就可以把这个发给你老板

00:37:02.808 --> 00:37:03.968
也是为了我们也很多

00:37:03.968 --> 00:37:05.248
提供了像类似于

00:37:05.248 --> 00:37:06.208
WorkerBody的一个能力了

00:37:06.208 --> 00:37:06.768
然后我们以为来

00:37:06.768 --> 00:37:08.388
还会逐步的去完善优化

00:37:08.388 --> 00:37:10.668
这个编辑能力还挺好用的

00:37:10.668 --> 00:37:11.148
这样的话

00:37:11.148 --> 00:37:14.928
就可以实时的和AI进行交互和修改

00:37:14.928 --> 00:37:15.248
是的

00:37:15.248 --> 00:37:17.808
那我们要不继续给大家展示一下

00:37:17.808 --> 00:37:19.488
我们Octob做出来的调研报告

00:37:19.488 --> 00:37:21.108
剩下还包含哪一些部分

00:37:21.108 --> 00:37:22.268
刚刚我们有看到

00:37:22.268 --> 00:37:24.608
它其实有很全面的这个行业总览

00:37:24.608 --> 00:37:27.188
以及三巨头的核心的对比维度

00:37:27.188 --> 00:37:28.348
我们可以

00:37:28.348 --> 00:37:29.628
你老板如果没有关心

00:37:29.628 --> 00:37:31.828
还有价格一些策略深度对比

00:37:31.828 --> 00:37:33.508
包括我们的一个产品矩正

00:37:33.508 --> 00:37:35.448
像喜茶它主打的可能是一个水果茶

00:37:35.448 --> 00:37:36.808
水果茶比较好喝

00:37:36.808 --> 00:37:38.408
我上班学的茶可能就是一个

00:37:38.408 --> 00:37:40.728
现烤烘焙的一个鲜果茶

00:37:40.728 --> 00:37:41.388
纯茶

00:37:41.388 --> 00:37:43.128
像花王茶间可能就是一个鲜奶茶的

00:37:43.128 --> 00:37:44.908
因为完全挺好喝的

00:37:44.908 --> 00:37:47.028
看来Octop真的调研的很全面

00:37:47.028 --> 00:37:49.228
还有营销策略的深度对比

00:37:49.228 --> 00:37:51.728
对甚至杨植宁给他的prompt

00:37:51.728 --> 00:37:52.588
比较直接紧的去做

00:37:52.588 --> 00:37:53.648
因为我们为什么要这么做

00:37:53.648 --> 00:37:54.848
一方面是加快我们的数

00:37:54.848 --> 00:37:56.368
另外一方面如果调研喜茶的时候

00:37:56.368 --> 00:37:57.268
像英年

00:37:57.268 --> 00:37:59.268
如果我们还去调研一下耐学的查

00:37:59.268 --> 00:38:01.368
说实话它的回复质量可能是比较低的

00:38:01.368 --> 00:38:03.268
所以说我们为什么要引入多一个来

00:38:03.268 --> 00:38:05.268
更好地形成一个调研报纳

00:38:05.268 --> 00:38:07.268
所以分别一个agent调研写查

00:38:07.268 --> 00:38:08.768
一个agent调研报纳查机

00:38:08.768 --> 00:38:10.668
还有一个agent在调研

00:38:10.668 --> 00:38:13.268
耐学的最后再医

00:38:13.268 --> 00:38:15.268
对你把整个的一个调研追过来

00:38:15.268 --> 00:38:18.268
agent做完调研之后是由主agent来做

00:38:18.268 --> 00:38:21.268
最后的一个整合和报告的撰写吗

00:38:21.268 --> 00:38:23.268
对的交交问的很对

00:38:23.268 --> 00:38:25.268
我们简单回复一下

00:38:25.268 --> 00:38:28.268
我们现在应该来说要支持有两种概念

00:38:28.268 --> 00:38:29.268
一种是我们的贼警的

00:38:29.268 --> 00:38:31.268
它是一个如果是变成朋友们比较熟悉

00:38:31.268 --> 00:38:32.868
它是一个现成的概念

00:38:32.868 --> 00:38:34.268
它用了一次之后就会消失

00:38:34.268 --> 00:38:36.268
所以它一定要成为主意警的它的一个答案

00:38:36.268 --> 00:38:39.268
未来朋友们比较放心的我们是回复答案能不能长久保存

00:38:39.268 --> 00:38:41.268
它有一个思路我们未来会推出agent的team

00:38:41.268 --> 00:38:43.268
又和我们的每个专家我们的Octop

00:38:43.268 --> 00:38:46.268
像刚刚也有些影视专家等等那些专家

00:38:46.268 --> 00:38:47.268
它里面的一个东西都会存在里面

00:38:47.268 --> 00:38:49.268
所以那个是一个进程的概念

00:38:49.268 --> 00:38:50.268
未来大家可以多多关注我们的Octop

00:38:50.268 --> 00:38:52.268
我们未来会及时的推出agent的team

00:38:52.268 --> 00:38:53.408
帮助大家更好的

00:38:53.408 --> 00:38:54.248
适应这种

00:38:54.248 --> 00:38:55.908
不论是那种工作

00:38:55.908 --> 00:38:57.168
还是我们刚刚一年说的

00:38:57.168 --> 00:38:58.468
这种宝爸宝妈们

00:38:58.468 --> 00:38:59.308
要给孩子做作业

00:38:59.308 --> 00:39:00.608
当然我们的agent team

00:39:00.608 --> 00:39:01.508
都会保存一些记忆

00:39:01.508 --> 00:39:02.868
欢迎大家继续关注

00:39:02.868 --> 00:39:04.448
那我们这个

00:39:04.448 --> 00:39:05.988
让他做竞品调研

00:39:05.988 --> 00:39:06.888
我们就只需要

00:39:06.888 --> 00:39:09.828
给他布置一个复杂的任务

00:39:09.828 --> 00:39:12.168
他自己就会去衡量和思考

00:39:12.168 --> 00:39:14.388
应该把什么任务分配给谁

00:39:14.388 --> 00:39:16.168
需要去有多少个agent

00:39:16.168 --> 00:39:17.608
支持这个任务吗

00:39:17.608 --> 00:39:20.028
好 我们可以简单

00:39:20.028 --> 00:39:21.488
回顾一下我们的用户

00:39:21.488 --> 00:39:25.328
是不是有个竞品调研专家他是有这些能力的

00:39:25.328 --> 00:39:27.328
对的我们是有一个竞品调研专家

00:39:27.328 --> 00:39:29.828
像我们的专家里面他都会有这个能力

00:39:29.828 --> 00:39:32.628
像我们的有很多专家是像我们的Z-Gent里面

00:39:32.628 --> 00:39:34.828
因为我们的我们的决策也是说了

00:39:34.828 --> 00:39:37.448
我们未来是可以不需要用户在这里面去安装

00:39:37.448 --> 00:39:39.828
也许他可以自动路由到一个你所需要的A-Gent

00:39:39.828 --> 00:39:42.028
因为我们也和那些客户在哪

00:39:42.028 --> 00:39:44.828
可能用的时候就说你只需要需要

00:39:44.828 --> 00:39:45.948
他自动可以帮你创造的未来

00:39:45.948 --> 00:39:47.848
我们就会不仅你是从这去下载

00:39:47.848 --> 00:39:49.828
还是你在用户窗口就可以直接和他对话

00:39:49.828 --> 00:39:50.908
未来都会支持这种能力

00:39:50.908 --> 00:39:52.788
我们目前已经内置了

00:39:52.788 --> 00:39:54.388
精品分析的这个专家

00:39:54.388 --> 00:39:57.088
因此我们用户只需要调用这个专家

00:39:57.088 --> 00:39:59.408
然后去给他输入非常简单的

00:39:59.408 --> 00:40:00.448
调研的指令

00:40:00.448 --> 00:40:02.028
然后他就会自动去帮我们

00:40:02.028 --> 00:40:03.368
去分配贼agent

00:40:03.368 --> 00:40:04.808
还有怎么分配任务

00:40:04.808 --> 00:40:06.668
就会自动帮我们一键输出报告了

00:40:06.668 --> 00:40:07.588
是的

00:40:07.588 --> 00:40:10.008
并且未来还就算不让大家去安装

00:40:10.008 --> 00:40:11.168
因为大家还要找

00:40:11.168 --> 00:40:12.248
让我们未来我们的

00:40:12.248 --> 00:40:13.088
只要是一个agent

00:40:13.088 --> 00:40:14.788
他自己可以去激活了一些贼agent的

00:40:14.788 --> 00:40:15.808
也可以激活了一些专家

00:40:15.808 --> 00:40:16.888
我看到我们粉丝朋友

00:40:16.888 --> 00:40:18.888
如果生成结构化文档

00:40:18.888 --> 00:40:22.928
前一张的输出是后一张的输入适合多Agent吗

00:40:23.279 --> 00:40:37.279
那其實這裡有非常多一種情況。其實是如果端木你是想,比如你想生成一篇文档,那比如先生成了第一段,再生成了第二段,第一段是第二段的輸入。

00:40:37.279 --> 00:40:38.039
输入

00:40:38.299 --> 00:40:41.639
那其实第二段的生成必须要第一段已经生成了

00:40:41.639 --> 00:40:45.219
其实多agents是适合这种并行的任务的

00:40:45.479 --> 00:40:49.559
那个像我们的多agent他现在的一个agent的输入大概是一个文本

00:40:49.559 --> 00:40:51.879
但是他可以生成像一个pdf文件

00:40:51.879 --> 00:40:53.919
或者像端木说的一个结构化的文档

00:40:53.919 --> 00:40:56.739
那么他端木的问题应该是在生成这个节目化文档之后

00:40:56.739 --> 00:40:59.559
这一个输入是否可以被后一个比如说agent

00:40:59.799 --> 00:41:00.579
然后给接收

00:41:00.579 --> 00:41:02.119
那么我们现在的回复就是

00:41:02.119 --> 00:41:04.159
如果是紫agent之间它是一个现成的关系

00:41:04.159 --> 00:41:06.079
它是不能够吸收这种结构化文本

00:41:06.079 --> 00:41:08.079
它只能接受文本的一个输入

00:41:08.079 --> 00:41:09.079
但是我们的主A进程

00:41:09.079 --> 00:41:10.759
可以把它的一个子A进程

00:41:10.759 --> 00:41:11.519
做出来的PDF

00:41:11.519 --> 00:41:12.919
Markdown文件要保存下来

00:41:12.919 --> 00:41:14.919
让主A进程读后交给子A进程

00:41:14.919 --> 00:41:16.559
这是我们的Octop的一个特色了

00:41:16.559 --> 00:41:18.999
我们也是支持这种多结构化文本

00:41:18.999 --> 00:41:19.719
从一个输入后

00:41:19.719 --> 00:41:21.239
下一个输出也肯定是支持的

00:41:21.239 --> 00:41:23.559
还有一位粉丝朋友问

00:41:23.559 --> 00:41:26.359
这一老用户迁移到Octop后

00:41:26.359 --> 00:41:30.639
原有记忆是否需要重新做GIMA转换

00:41:30.639 --> 00:41:31.439
是这样的

00:41:31.439 --> 00:41:33.439
在原有来靠ACE的记忆

00:41:33.439 --> 00:41:34.639
其实大家知道

00:41:34.639 --> 00:41:38.099
就是只有memory文件夹下的所有md文档

00:41:38.099 --> 00:41:40.639
以及memory.md是记忆的所有真相语言

00:41:40.639 --> 00:41:43.639
你做迁移可以一起迁移过来

00:41:43.639 --> 00:41:44.879
我们现在记忆一遍

00:41:44.879 --> 00:41:47.259
那memory.md是可以全量读得到的

00:41:47.259 --> 00:41:50.359
那关于其他的一些结构化文档

00:41:50.359 --> 00:41:54.399
我们也会推出一个支持的记忆格式转换

00:41:54.399 --> 00:41:55.599
我看粉丝朋友问

00:41:55.599 --> 00:41:57.639
好像不能多用户多智能力

00:41:57.639 --> 00:41:58.759
以共同协作

00:41:58.759 --> 00:41:59.119
对的

00:41:59.119 --> 00:42:01.139
因为我们现在的一个思路是

00:42:01.139 --> 00:42:02.939
每个用户和每个用户之间是隔离的

00:42:02.939 --> 00:42:06.099
所以用户和用户之间是不能够进行一个协作的

00:42:06.099 --> 00:42:07.059
但是如果你有需求

00:42:07.059 --> 00:42:09.379
我觉得是不是未来一向英雄我们是不是可以

00:42:09.379 --> 00:42:12.059
对看这位粉丝朋友的具体需求

00:42:12.059 --> 00:42:16.299
我理解单用户你的多智能体是可以共同协作的

00:42:16.299 --> 00:42:17.599
我们继续讲解

00:42:17.599 --> 00:42:22.299
看大家对刚刚的竞品分析的演示有没有什么问题

00:42:22.299 --> 00:42:26.659
我刚刚看到我们的October也是用一条简单的指令

00:42:26.659 --> 00:42:30.379
立刻产出了一份比较完善角度

00:42:30.379 --> 00:42:32.699
也比较齐全的竞品分析调研报告了

00:42:32.699 --> 00:42:33.339
对

00:42:33.339 --> 00:42:34.299
是的

00:42:34.299 --> 00:42:36.459
看一下大家有什么问题没有

00:42:36.459 --> 00:42:37.679
大家提问

00:42:37.679 --> 00:42:40.559
那大家有没有什么想了解的场景

00:42:40.559 --> 00:42:43.139
也可以现在在评论区打出来

00:42:43.139 --> 00:42:46.779
或者是加入用户群里和我们一起探讨一下

00:42:46.779 --> 00:42:47.739
收费不以后

00:42:47.739 --> 00:42:48.899
我看有用户提问了

00:42:48.899 --> 00:42:49.759
我们不收费

00:42:49.759 --> 00:42:51.119
我们代码现在都开源的

00:42:51.119 --> 00:42:54.919
我们未来也会在轻量云服务器的控制台上上镜像

00:42:54.919 --> 00:42:57.639
对我们没有收费

00:42:57.639 --> 00:42:58.819
对买一台服务器

00:42:58.819 --> 00:43:01.579
包括你现在自己也可以去安装

00:43:01.579 --> 00:43:03.859
安装方式可以去GitHub

00:43:03.859 --> 00:43:05.059
看我们的ReadMe

00:43:05.059 --> 00:43:06.619
未来我们也会在

00:43:06.619 --> 00:43:07.919
腾讯社区里

00:43:07.919 --> 00:43:09.219
推出更方便的

00:43:09.219 --> 00:43:10.859
安装方式教学

00:43:10.859 --> 00:43:11.159
对

00:43:11.159 --> 00:43:12.559
好像我们的Optop了吗

00:43:12.559 --> 00:43:13.319
还算不算便宜的

00:43:13.319 --> 00:43:14.059
我们会想欢迎大家

00:43:14.059 --> 00:43:15.199
来我们的Lighthouse里面来买

00:43:15.199 --> 00:43:16.799
因为你买了一个后

00:43:16.799 --> 00:43:18.019
那你可以是全家

00:43:18.019 --> 00:43:18.599
全家都用

00:43:18.599 --> 00:43:18.959
是的

00:43:18.959 --> 00:43:20.439
有一个问题

00:43:20.439 --> 00:43:21.819
假如说未来我们在

00:43:21.819 --> 00:43:23.639
服务器上上了镜像之后

00:43:23.639 --> 00:43:25.819
我们的多用户功能

00:43:25.819 --> 00:43:26.819
也就是相当于

00:43:26.819 --> 00:43:28.079
只要管理员

00:43:28.079 --> 00:43:29.079
买了一台服务器

00:43:29.079 --> 00:43:30.539
有一台Optop之后

00:43:30.539 --> 00:43:32.259
我所设置的多用户

00:43:32.259 --> 00:43:33.799
他们就不用再买了对吗

00:43:33.799 --> 00:43:34.559
对的

00:43:34.559 --> 00:43:36.099
一台服气的Octob

00:43:36.099 --> 00:43:38.179
就能够多用户使用

00:43:38.179 --> 00:43:39.559
我看到粉丝朋友问

00:43:39.559 --> 00:43:40.199
上了镜像

00:43:40.199 --> 00:43:41.679
到时候可以把Hermes镜像

00:43:41.679 --> 00:43:42.779
换成Octob吗

00:43:42.779 --> 00:43:44.019
可以

00:43:44.019 --> 00:43:45.099
其实换镜像

00:43:45.099 --> 00:43:47.379
就是一个实力重装

00:43:47.379 --> 00:43:49.179
是关于服气的操作

00:43:49.179 --> 00:43:51.419
其实都可以随时做的

00:43:51.419 --> 00:43:53.939
我看还有黄医生问

00:43:53.939 --> 00:43:54.759
ACE转移

00:43:54.759 --> 00:43:56.219
包括记忆聊天记录

00:43:56.219 --> 00:43:58.559
Skill这些无损切换到Octob

00:43:58.559 --> 00:43:59.999
E和Skill

00:43:59.999 --> 00:44:01.519
包括你通道配置

00:44:01.519 --> 00:44:03.219
那些配置现在都是无损切换

00:44:03.219 --> 00:44:04.959
但是聊天介络

00:44:04.959 --> 00:44:07.059
现在的迁移工具还不支持

00:44:07.059 --> 00:44:09.259
对如果有强烈需求的话

00:44:09.259 --> 00:44:11.819
可以在用户群里讨论

00:44:11.819 --> 00:44:13.899
未来可能看看升级迁移工具

00:44:13.899 --> 00:44:15.279
或以其他方式支持

00:44:15.279 --> 00:44:17.019
什么时候上了清亮云

00:44:17.019 --> 00:44:18.099
很快了

00:44:18.099 --> 00:44:20.739
我们进上工作还差最后的适配

00:44:20.739 --> 00:44:23.439
最迟其实近两周就能上

00:44:23.439 --> 00:44:25.179
对欢迎到周公开

00:44:25.179 --> 00:44:25.679
是的

00:44:25.679 --> 00:44:28.239
那我们两位研发工程师

00:44:28.239 --> 00:44:30.619
关于October未来的一个产品规划

00:44:30.619 --> 00:44:33.159
以及一些会上的功能能力

00:44:33.159 --> 00:44:34.759
也可以简单的给大家剧透一下

00:44:34.759 --> 00:44:35.819
大家可以期待一下

00:44:35.819 --> 00:44:39.439
同时大家如果有什么想要上的功能

00:44:39.439 --> 00:44:40.599
或者说上线的功能

00:44:40.599 --> 00:44:42.539
也可以在评论区里面交流一下

00:44:42.539 --> 00:44:45.379
那么也有请两位简单介绍一下

00:44:45.379 --> 00:44:49.679
那由我先来简单的说说我们的一个初步打算

00:44:49.679 --> 00:44:51.659
我们下一段的目标主要是

00:44:51.659 --> 00:44:52.979
正在服务于大家的一个

00:44:52.979 --> 00:44:55.219
从我们ACE前一到我们的TOP里面

00:44:55.219 --> 00:44:56.919
我们在支持这种工序的升级

00:44:56.919 --> 00:44:59.979
这之外我们还在积极地调远Agent Team的一个使用方式

00:44:59.979 --> 00:45:02.799
以及未来的Octobre在我们的一个QQ群鸟里面

00:45:02.799 --> 00:45:05.639
它怎么样服务好我们的整个一个家庭用户场景

00:45:05.639 --> 00:45:09.579
怎么去把一个Agent服务多个用户的这种能力给发挥出来

00:45:09.579 --> 00:45:10.799
包括我们也来积极地探索

00:45:10.799 --> 00:45:12.619
像使用这种杀香的机制

00:45:12.619 --> 00:45:15.539
像每位用户也可以一个家庭有一个Agent

00:45:15.539 --> 00:45:17.999
像我确实也听到过像用户提问

00:45:17.999 --> 00:45:20.079
比如说他希望他看到的东西

00:45:20.079 --> 00:45:23.039
他的孩子和他的老婆都能够使用

00:45:23.039 --> 00:45:24.459
包括特别是在QQ里面

00:45:24.459 --> 00:45:25.619
未来我们的也会支持

00:45:25.619 --> 00:45:26.899
像我们的群鸟

00:45:26.899 --> 00:45:27.459
Agent的切能

00:45:27.459 --> 00:45:29.099
我们会做一个类似于杀箱的机制

00:45:29.099 --> 00:45:30.539
来支持这种东西

00:45:30.539 --> 00:45:31.339
因为据我所知

00:45:31.339 --> 00:45:34.059
现在还是没有一个Agent能够做的很好

00:45:34.059 --> 00:45:34.819
包括Hammus也好

00:45:34.819 --> 00:45:35.619
跟Clau也好

00:45:35.619 --> 00:45:36.299
未来的Octobre

00:45:36.299 --> 00:45:37.099
会把这个作为一个

00:45:37.099 --> 00:45:39.179
我们的相对的一个竞争优势去完善长

00:45:39.179 --> 00:45:40.259
是的 期待

00:45:40.259 --> 00:45:41.859
希望能够加上类似于

00:45:41.859 --> 00:45:44.019
OakBody项目的模式

00:45:44.019 --> 00:45:44.739
应酶

00:45:44.739 --> 00:45:46.259
我觉得其实我们也可以尝试

00:45:46.259 --> 00:45:47.539
去往这方面去做一做

00:45:47.539 --> 00:45:49.819
可以回去探讨一下

00:45:49.819 --> 00:45:51.059
对 也欢迎黄众

00:45:51.059 --> 00:45:52.739
现在就在我们的GitHub里面

00:45:52.739 --> 00:45:53.579
机器给我们提issue

00:45:53.579 --> 00:45:54.339
我们看到你的issue

00:45:54.339 --> 00:45:55.499
也会把它作为一个

00:45:55.499 --> 00:45:57.219
我们可以未来的发展方向

00:45:57.219 --> 00:45:59.339
也欢迎您来给我们做做共同

00:45:59.339 --> 00:45:59.819
做pr

00:45:59.819 --> 00:46:00.659
因为我们这是开云的

00:46:00.659 --> 00:46:02.539
也可以服务一下您的一个用户场景

00:46:02.779 --> 00:46:04.139
单个用户的记忆数据

00:46:04.139 --> 00:46:04.779
达到百万级

00:46:04.779 --> 00:46:06.419
Octop怎么保证解锁能力

00:46:06.419 --> 00:46:08.659
对这个我可以回答一下

00:46:08.659 --> 00:46:09.779
刚刚其实讲到了

00:46:09.779 --> 00:46:11.739
Octop现在的记忆层级

00:46:11.739 --> 00:46:14.339
那其实首先我们会去

00:46:14.339 --> 00:46:16.299
检索所谓的原子卡片

00:46:16.299 --> 00:46:19.259
那其实如果对话数量达到百万级

00:46:19.259 --> 00:46:20.059
我们理解

00:46:20.059 --> 00:46:21.699
其实近身的原子卡片数量

00:46:21.699 --> 00:46:22.659
并没有这么多

00:46:22.659 --> 00:46:25.459
对那一我们是先召回原子卡片

00:46:25.459 --> 00:46:27.059
然后分层检索

00:46:27.059 --> 00:46:29.279
我理解其实我们就是先召回原子卡片

00:46:29.279 --> 00:46:33.299
然后再从候选者最后再召回到原始事件

00:46:33.299 --> 00:46:36.119
其实这是一个分层的检索forback

00:46:36.119 --> 00:46:40.719
后续我们也其实会推出记忆接上向量的模式

00:46:40.719 --> 00:46:42.119
如果是ACE老用户的话

00:46:42.119 --> 00:46:45.259
可以知道现在ACE其实默认有一个向量模型机制

00:46:45.259 --> 00:46:48.859
但是在Octop因为我们要做组件拆分

00:46:48.859 --> 00:46:51.759
我们其实默认是FTS加BM25

00:46:51.759 --> 00:46:56.239
但后续如果有更重的记忆需求

00:46:56.239 --> 00:47:00.119
我们其实也在计划推出Octop Memory

00:47:00.119 --> 00:47:01.659
配置项料模型

00:47:01.659 --> 00:47:03.399
以及自己的项料数据库

00:47:03.399 --> 00:47:05.179
可以欢迎后续期待一下

00:47:05.179 --> 00:47:07.399
微信渠道可以多往上下

00:47:07.399 --> 00:47:09.319
尽量做到QQ渠道的程度

00:47:09.319 --> 00:47:10.759
关于这个问题我来回复一下

00:47:10.759 --> 00:47:12.039
因为是我在GDF的

00:47:12.039 --> 00:47:14.179
像微信渠道我们在积极的和微信里面

00:47:14.179 --> 00:47:14.979
进行一个沟通

00:47:14.979 --> 00:47:17.679
因为目前是它里面包括一些多艺景特能

00:47:17.679 --> 00:47:20.479
包括它一些主动推送的一些限度

00:47:20.479 --> 00:47:22.579
导致它没有办法像QQ通道做的这么全

00:47:22.579 --> 00:47:24.239
那么等待微信通道里边

00:47:24.239 --> 00:47:25.279
我相信他们也会很快更新

00:47:25.279 --> 00:47:28.639
然后我们也会适时的去更新连带我们的微信通道

00:47:28.639 --> 00:47:30.119
以及帮靠达更好的支持活动

00:47:30.119 --> 00:47:30.439
对

00:47:30.439 --> 00:47:34.079
我看那种说希望能提供SSO集成方案

00:47:34.079 --> 00:47:39.039
支持企业部署成内部知识记忆中枢

00:47:39.039 --> 00:47:39.719
好的

00:47:39.719 --> 00:47:42.879
下来我们去探讨一下争取

00:47:42.879 --> 00:47:44.919
不管是参观我们代码也好

00:47:44.919 --> 00:47:47.919
还是给我们STAR或者提提提提提提提提

00:47:47.919 --> 00:47:49.779
也欢迎加入我们的用户群

00:47:49.779 --> 00:47:51.959
跟我们的研发和产品同学

00:47:51.959 --> 00:47:53.139
做积极的交流

00:47:53.139 --> 00:47:54.699
有意见或者有建议

00:47:54.699 --> 00:47:56.319
都可以在里面跟我们提出来

00:47:56.319 --> 00:47:57.559
是的那么本场之外

00:47:57.559 --> 00:47:59.879
其实我们围绕Octop的技艺机制

00:47:59.879 --> 00:48:03.099
以及竞品分析这个专家的能力

00:48:03.099 --> 00:48:05.159
如何帮助我们去做日常调研

00:48:05.159 --> 00:48:06.259
分析的工作

00:48:06.259 --> 00:48:07.419
帮助我们提校

00:48:07.419 --> 00:48:10.259
都进行了一个详细的讲

00:48:10.259 --> 00:48:12.239
如果说云服务器一键

00:48:12.239 --> 00:48:13.659
不需要建议多大的配置

00:48:13.659 --> 00:48:15.299
这个因为我们现在

00:48:15.299 --> 00:48:16.999
Octop支持多用户

00:48:16.999 --> 00:48:19.079
其实多大配置取决于

00:48:19.079 --> 00:48:22.479
这个用户箱就是这个机器或者Octop

00:48:22.479 --> 00:48:23.739
支持多少个用户

00:48:23.739 --> 00:48:27.539
我们后续也会出一个专门的配置推荐

00:48:27.539 --> 00:48:29.859
来帮助大家选购服务器

00:48:29.859 --> 00:48:32.559
全全老师这边说是100个员工左右的规模

00:48:32.559 --> 00:48:33.079
好的

00:48:33.079 --> 00:48:34.879
那我们推荐我们另外一款产品

00:48:34.879 --> 00:48:35.539
Club Pro的

00:48:35.539 --> 00:48:38.219
全全老师不知道有没有关注过Club Pro

00:48:38.219 --> 00:48:39.459
可以去关注一下

00:48:39.459 --> 00:48:42.759
当然如果非常想用我们Octop

00:48:42.759 --> 00:48:45.159
我们后续也会给一个推荐

00:48:45.159 --> 00:48:47.119
Emma问可以部署到本地吗

00:48:47.119 --> 00:48:47.899
可以的可以的

00:48:47.899 --> 00:48:50.379
Emma可以直接访问我们的DHub仓库

00:48:50.379 --> 00:48:54.019
Vidmin有完整的部署的一个介绍

00:48:54.019 --> 00:48:56.139
我们今天的直播就到这里结束了

00:48:56.139 --> 00:48:56.699
好的

00:48:56.699 --> 00:48:57.179
拜拜