1 00:00:00,000 --> 00:00:04,000 我給Octop記憶定義的就是給Agent一個能帶走的記憶。 2 00:00:04,000 --> 00:00:08,000 我們多專家多Agent的並行,如何來重溝我們的記憶。 3 00:00:08,000 --> 00:00:10,000 Hello,大家好,大家晚上好。 4 00:00:10,000 --> 00:00:15,000 歡迎大家來到今天的直播間,我是今天的主持人佼佼。 5 00:00:15,000 --> 00:00:19,000 歡迎大家再次來到雲上AI工坊的直播間。 6 00:00:19,000 --> 00:00:24,000 今天這期的主角是Octop,一個剛剛開源的自演的AI助手。 7 00:00:24,000 --> 00:00:29,000 今天我們也會針對他多專家多用戶多Agent的並行這樣子的一個特徵。 8 00:00:29,000 --> 00:00:29,800 这样子的一个特征 9 00:00:29,800 --> 00:00:32,200 去采取一些实战的案例分析 10 00:00:32,200 --> 00:00:34,320 比如说我不知道直播间的各位 11 00:00:34,320 --> 00:00:36,260 有没有一些做行业分析 12 00:00:36,260 --> 00:00:37,180 竞品分析 13 00:00:37,180 --> 00:00:39,380 这样子的一个日常的工作需求 14 00:00:39,380 --> 00:00:40,780 那么我们也会 15 00:00:40,780 --> 00:00:43,200 针对这样子的一个实战的场景 16 00:00:43,200 --> 00:00:45,600 来打造这个Octop重塑竞品分析 17 00:00:45,600 --> 00:00:47,820 工作流这样子的一个实战案例 18 00:00:47,820 --> 00:00:50,340 同时也会涉及到一些多agent博弈 19 00:00:50,340 --> 00:00:51,740 比如说大家不知道 20 00:00:51,740 --> 00:00:53,040 喜不喜欢吃豆腐脑 21 00:00:53,040 --> 00:00:54,700 我们本场直播也会给大家 22 00:00:54,700 --> 00:00:56,580 在线围观一下这个豆腐脑 23 00:00:56,580 --> 00:00:58,660 AI它是如何进行填衔 24 00:00:58,660 --> 00:00:59,620 辩论的 25 00:00:59,620 --> 00:01:01,560 同时大家上一场直播中 26 00:01:01,560 --> 00:01:02,680 其实也有关注到 27 00:01:02,680 --> 00:01:03,680 我们这个Octop 28 00:01:03,680 --> 00:01:04,860 它的一个记忆机制 29 00:01:04,860 --> 00:01:05,620 是怎么样的 30 00:01:05,620 --> 00:01:07,140 什么东西是该记忆的 31 00:01:07,140 --> 00:01:08,300 什么是该召回的 32 00:01:08,300 --> 00:01:09,420 那么本场直播 33 00:01:09,420 --> 00:01:10,240 大家不用着急 34 00:01:10,240 --> 00:01:11,840 我们也会给大家详细的 35 00:01:11,840 --> 00:01:13,760 去拆解Octop的记忆机制 36 00:01:13,760 --> 00:01:15,260 话不多说 37 00:01:15,260 --> 00:01:16,500 我们也简要的介绍一下 38 00:01:16,500 --> 00:01:17,680 今天的两位嘉宾 39 00:01:17,680 --> 00:01:20,080 首先是Octop的研发工程师 40 00:01:20,080 --> 00:01:20,500 英宁 41 00:01:20,500 --> 00:01:21,860 另外一位杨直 42 00:01:21,860 --> 00:01:23,860 也是我们的Octop的研发工程师 43 00:01:23,860 --> 00:01:25,060 我们先来讲 44 00:01:25,060 --> 00:01:28,280 本期的一个Octop基础的 45 00:01:28,280 --> 00:01:30,280 模块介绍就是记忆 46 00:01:30,280 --> 00:01:33,280 我上一期应该就是给大家演示了 47 00:01:33,280 --> 00:01:35,280 我们Octop的记忆面板 48 00:01:35,280 --> 00:01:40,040 然后这期我们会给大家详细带来一下Octop的记忆 49 00:01:40,040 --> 00:01:41,120 它是怎么记的 50 00:01:41,120 --> 00:01:43,320 它又为什么好 51 00:01:43,320 --> 00:01:44,280 话不多说 52 00:01:44,280 --> 00:01:45,280 让我们开始 53 00:01:45,280 --> 00:01:47,240 首先可以看到标题 54 00:01:47,240 --> 00:01:52,240 我给Octop记忆定义的就是给Agent一个能带走的记忆 55 00:01:52,240 --> 00:01:53,680 如果想到能带走 56 00:01:53,680 --> 00:01:55,520 我想问一下杨直跟佼佼 57 00:01:55,520 --> 00:01:56,920 首先想到的是什么 58 00:01:56,920 --> 00:01:59,860 它一定可以从不管是Open Cloud还是Harmor 59 00:01:59,860 --> 00:02:01,360 都可以迁积到我们的Octob 60 00:02:01,360 --> 00:02:01,920 对 61 00:02:01,920 --> 00:02:03,660 是的 我也是这样想的 62 00:02:04,520 --> 00:02:06,620 是的 那其实就是这样 63 00:02:06,620 --> 00:02:08,720 不知道现在在看直播的朋友 64 00:02:08,720 --> 00:02:10,780 有没有我们以前的老用户 65 00:02:10,780 --> 00:02:12,520 给大家说一下我们的Octob 66 00:02:12,520 --> 00:02:16,320 其实是有个前身就是叫LiCloud ACE 67 00:02:16,320 --> 00:02:19,120 如果一直关注咱们腾讯服务器直播间的朋友 68 00:02:19,120 --> 00:02:21,920 应该听说过这个产品或名词 69 00:02:21,920 --> 00:02:24,620 现在我们推出了全新升级版Octob 70 00:02:24,620 --> 00:02:26,780 同时我们也在GitHub开源了 71 00:02:26,780 --> 00:02:30,920 感兴趣的粉丝朋友们也可以去搜索Octop 72 00:02:30,920 --> 00:02:33,280 看看我们的代码 73 00:02:33,280 --> 00:02:35,020 给我们提交PR或issue 74 00:02:35,020 --> 00:02:37,080 也请多多fork我们仓库 75 00:02:37,080 --> 00:02:38,000 以及给我们start 76 00:02:38,000 --> 00:02:38,320 是的 77 00:02:38,320 --> 00:02:40,400 欢迎提论区的大佬们 78 00:02:40,400 --> 00:02:44,060 多多的为我们的项目去提出建设性的意见 79 00:02:44,060 --> 00:02:46,440 首先那继续给大家讲解记忆 80 00:02:46,440 --> 00:02:48,000 那我们现在记忆 81 00:02:48,000 --> 00:02:50,940 其实现在是一个七层的记忆结构 82 00:02:50,940 --> 00:02:52,860 和两条相反的流水线 83 00:02:52,860 --> 00:02:55,440 那两条方向相反流水线是什么 84 00:02:55,440 --> 00:02:56,940 就是沉淀和召回 85 00:02:56,940 --> 00:02:59,940 其实这两个名词有点灰色难懂 86 00:02:59,940 --> 00:03:01,040 但是没有关系 87 00:03:01,040 --> 00:03:02,100 后面听我讲 88 00:03:02,100 --> 00:03:03,600 大家就能懂了 89 00:03:03,600 --> 00:03:05,260 首先给大家介绍一下 90 00:03:05,260 --> 00:03:06,720 Octop Memory是什么 91 00:03:06,720 --> 00:03:11,620 它其实是一个面向Agent的可插拔长期记忆系统 92 00:03:11,620 --> 00:03:14,520 也就是它其实不只适用于我们Octop 93 00:03:14,520 --> 00:03:16,980 因为在我们推出Ace的Memory的时候 94 00:03:16,980 --> 00:03:18,820 其实很多粉丝朋友就问 95 00:03:18,820 --> 00:03:21,860 说那如果你们一直在说你们Memory好 96 00:03:21,860 --> 00:03:24,000 那能不能做个独立的插件 97 00:03:24,000 --> 00:03:26,500 像外面的那些memory插件一样 98 00:03:26,500 --> 00:03:28,840 他们就是想接在OpenCloud使用 99 00:03:28,840 --> 00:03:30,180 接在Hermes使用 100 00:03:30,180 --> 00:03:32,120 当时给大家的回复是 101 00:03:32,120 --> 00:03:33,320 我们未来会推出 102 00:03:33,320 --> 00:03:35,820 那现在随着我们全新升级的Octop推出 103 00:03:35,820 --> 00:03:37,200 对我们Octop Memory 104 00:03:37,200 --> 00:03:39,600 也迎来一个可插拔的长期记忆系统 105 00:03:39,600 --> 00:03:41,560 现在我们Octop Memory也支持 106 00:03:41,560 --> 00:03:44,000 就是在Hermes上使用 107 00:03:44,000 --> 00:03:45,780 在OpenCloud上使用 108 00:03:45,780 --> 00:03:47,860 以及刚刚我们说可以带走的记忆 109 00:03:47,860 --> 00:03:49,400 也就是说你的记忆 110 00:03:49,400 --> 00:03:51,880 其实是跟着我们Octop memory走 111 00:03:51,880 --> 00:03:53,760 并不是说是依赖agent本身 112 00:03:53,760 --> 00:03:55,380 如果你在Octop上 113 00:03:55,380 --> 00:03:56,760 你就是用了一段时间 114 00:03:56,760 --> 00:03:58,200 你想我带着这份记忆 115 00:03:58,200 --> 00:03:59,060 我去试一下 116 00:03:59,060 --> 00:04:01,200 那OpenCloud是怎么样的 117 00:04:01,200 --> 00:04:02,740 Hermus是怎么样的 118 00:04:02,740 --> 00:04:04,840 是不是你们Octop真的说着 119 00:04:04,840 --> 00:04:05,940 比OpenCloudHermus好 120 00:04:05,940 --> 00:04:06,800 那是真的好吗 121 00:04:06,800 --> 00:04:07,880 那没关系 122 00:04:07,880 --> 00:04:09,540 你就可以带着我们的记忆 123 00:04:09,540 --> 00:04:10,860 去实地感受一下 124 00:04:10,860 --> 00:04:13,900 对我们现在是可以支持这个功能的 125 00:04:13,900 --> 00:04:15,480 那是不是可以理解为 126 00:04:15,480 --> 00:04:17,020 只要拥有这个插件 127 00:04:17,020 --> 00:04:18,360 其实我们的记忆 128 00:04:18,360 --> 00:04:19,900 就可以灵活的 129 00:04:19,900 --> 00:04:21,080 OpenCloud Hermes之间 130 00:04:21,080 --> 00:04:22,500 去迁移使用 131 00:04:22,500 --> 00:04:22,800 是的 132 00:04:22,800 --> 00:04:24,040 就是这样的 133 00:04:24,040 --> 00:04:25,840 那这个功能也太方便了 134 00:04:25,840 --> 00:04:27,620 那真的是一个挺大的优势 135 00:04:27,620 --> 00:04:28,820 是的 136 00:04:28,820 --> 00:04:30,660 因为之前我们每个组件 137 00:04:30,660 --> 00:04:32,460 都是聚合在一起的 138 00:04:32,460 --> 00:04:33,880 是在我们前身ACE版本 139 00:04:33,880 --> 00:04:35,180 如果了解的粉丝朋友 140 00:04:35,180 --> 00:04:35,860 应该也知道 141 00:04:35,860 --> 00:04:37,060 但我们现在 142 00:04:37,060 --> 00:04:39,220 随着我们全新的功能升级 143 00:04:39,220 --> 00:04:41,060 我们架构也迎来了一个升级 144 00:04:41,060 --> 00:04:42,880 在后面我们也会 145 00:04:42,880 --> 00:04:44,280 陆续开源我们每个组件 146 00:04:44,280 --> 00:04:45,400 如果感兴趣的朋友 147 00:04:45,400 --> 00:04:47,540 可以先给我们仓库 148 00:04:47,540 --> 00:04:48,280 点个Star 149 00:04:48,280 --> 00:04:50,220 后续我们看愿其他组件 150 00:04:50,220 --> 00:04:52,540 我们也会通知各位观众朋友 151 00:04:52,540 --> 00:04:53,160 对 152 00:04:53,160 --> 00:04:53,780 是的 153 00:04:53,780 --> 00:04:56,100 大家把这个star给点起来 154 00:04:56,100 --> 00:04:57,740 我刚刚其实也介绍了 155 00:04:57,740 --> 00:04:59,380 我们Octop在最上层 156 00:04:59,380 --> 00:05:00,920 然后我们也有browser 157 00:05:00,920 --> 00:05:02,020 也有givet 158 00:05:02,020 --> 00:05:03,520 包括我们的运行时 159 00:05:03,520 --> 00:05:06,220 那今天我们其实要给大家带来的是 160 00:05:06,220 --> 00:05:06,920 Octop Memory 161 00:05:06,920 --> 00:05:08,880 在介绍Octop Memory之前 162 00:05:08,880 --> 00:05:11,780 那其实今天还没有遇到那个经典问题 163 00:05:11,780 --> 00:05:13,760 我包括在之前来到直播间 164 00:05:13,760 --> 00:05:15,500 大概五六七八次 165 00:05:15,500 --> 00:05:16,960 不管是在建议的时候 166 00:05:16,960 --> 00:05:18,180 或者是Octop的时候 167 00:05:18,180 --> 00:05:20,860 粉丝朋友总会在评论区问 168 00:05:20,860 --> 00:05:23,680 那你们跟谁谁有什么不一样 169 00:05:23,680 --> 00:05:27,160 那之前其实都是很口语化的给大家解答 170 00:05:27,160 --> 00:05:30,900 但是今天我作为一个经验丰富的老主播 171 00:05:30,900 --> 00:05:32,540 我就是预设到了这个问题 172 00:05:32,540 --> 00:05:34,900 那我就是加了一页HTML 173 00:05:34,900 --> 00:05:36,320 跟大家好好讲讲 174 00:05:36,320 --> 00:05:39,980 我们on top到底跟别人有什么不一样 175 00:05:39,980 --> 00:05:42,360 其实可以从四维看见 176 00:05:42,360 --> 00:05:43,840 其实就有四个维度 177 00:05:43,840 --> 00:05:45,340 一个是多用户 178 00:05:45,340 --> 00:05:46,440 一个是个人 179 00:05:46,440 --> 00:05:48,080 以及一个是编码场景 180 00:05:48,080 --> 00:05:51,020 一个是通用办公和生活场景 181 00:05:51,020 --> 00:05:52,980 那这时候其实我想问一下 182 00:05:52,980 --> 00:05:53,900 焦焦和杨直 183 00:05:53,900 --> 00:05:56,920 其实正好是一个运营同学 184 00:05:56,920 --> 00:05:58,340 一个研发同学 185 00:05:58,340 --> 00:06:00,000 那你们在工作中 186 00:06:00,000 --> 00:06:01,980 其实用哪个agent用的比较多 187 00:06:01,980 --> 00:06:03,440 其实我在日常工作中 188 00:06:03,440 --> 00:06:04,800 这几个都有使用 189 00:06:04,800 --> 00:06:07,060 首先就是我们云上的这个lighthouse 190 00:06:07,060 --> 00:06:09,860 是我自己一直持续有氧的 191 00:06:09,860 --> 00:06:12,240 我们的一个桌面的agentworkbody 192 00:06:12,240 --> 00:06:13,420 其实也有在使用的 193 00:06:13,420 --> 00:06:16,680 我觉得他们可能在不同的场景 194 00:06:16,680 --> 00:06:17,940 和不同的任务 195 00:06:17,940 --> 00:06:18,720 它各有优利 196 00:06:18,720 --> 00:06:20,520 这几个都有使用 197 00:06:20,520 --> 00:06:21,560 那我平时觉得 198 00:06:21,560 --> 00:06:22,820 Workbody去做一些 199 00:06:22,820 --> 00:06:24,480 文档编辑是很方便的 200 00:06:24,480 --> 00:06:24,720 对 201 00:06:24,720 --> 00:06:25,800 但对于一个研发工程师 202 00:06:25,800 --> 00:06:26,400 可能来说 203 00:06:26,400 --> 00:06:27,220 像Codex 204 00:06:27,220 --> 00:06:29,100 像Cloudcode这种编码 205 00:06:29,100 --> 00:06:30,120 包括我们的腾讯 206 00:06:30,120 --> 00:06:30,820 推出的Codebody 207 00:06:30,820 --> 00:06:32,020 也是非常好的一个编码工具 208 00:06:32,020 --> 00:06:32,940 这些都在使用 209 00:06:32,940 --> 00:06:34,200 粉丝朋友也有说 210 00:06:34,200 --> 00:06:35,300 有用这个Workbody 211 00:06:35,300 --> 00:06:36,740 有用Hermes都在用 212 00:06:36,740 --> 00:06:36,960 对 213 00:06:36,960 --> 00:06:38,320 我也看到一个问题 214 00:06:38,320 --> 00:06:40,100 是说这个记忆写入时 215 00:06:40,100 --> 00:06:41,660 有没有去重合 216 00:06:41,660 --> 00:06:43,000 冲突的消解机制 217 00:06:43,000 --> 00:06:44,040 如何处理 218 00:06:44,040 --> 00:06:45,740 同一事实的不同表述 219 00:06:45,740 --> 00:06:46,980 这个问题挺好的 220 00:06:46,980 --> 00:06:47,640 对 221 00:06:47,640 --> 00:06:50,300 看来这个Nome粉丝朋友 222 00:06:50,300 --> 00:06:53,320 其实是有关注记忆组件的 223 00:06:53,320 --> 00:06:57,280 那其实我们去虫和冲突消解机制是有的 224 00:06:57,280 --> 00:07:00,600 其实先给大家看一下后续的PPT 225 00:07:00,600 --> 00:07:02,960 那我们其实有七层结构 226 00:07:02,960 --> 00:07:04,840 第一层是memory.md 227 00:07:04,840 --> 00:07:07,360 如果养过虾的朋友可能就知道它是什么 228 00:07:07,360 --> 00:07:09,040 对于Open Cloud和Hermas 229 00:07:09,040 --> 00:07:11,480 它都会全量进入一个上下文 230 00:07:11,480 --> 00:07:13,300 做一个比较全的记忆 231 00:07:13,300 --> 00:07:16,100 当然我们也会同步这个操作场景 232 00:07:16,100 --> 00:07:17,460 对于我们自己的记忆 233 00:07:17,460 --> 00:07:19,660 首先我们就有一个ROEvent 234 00:07:19,660 --> 00:07:21,660 就是一个最底层的事实 235 00:07:21,660 --> 00:07:23,260 也就是对话数据源 236 00:07:23,260 --> 00:07:25,460 然后我们会有一个Candidate 237 00:07:25,460 --> 00:07:27,560 如果我们会有一套记忆的上升规则 238 00:07:27,560 --> 00:07:29,160 就是关于长期记忆 239 00:07:29,160 --> 00:07:29,760 有事实记忆 240 00:07:29,760 --> 00:07:30,860 有情景记忆 241 00:07:30,860 --> 00:07:32,960 以及用户的一些信息 242 00:07:32,960 --> 00:07:35,460 那如果你触发到了我们的规则 243 00:07:35,460 --> 00:07:36,860 那就会进入Candidate 244 00:07:36,860 --> 00:07:38,560 那在Candidate层 245 00:07:38,560 --> 00:07:40,260 那这个记忆会做什么 246 00:07:40,260 --> 00:07:42,560 其实就是一个沉淀 247 00:07:42,560 --> 00:07:44,960 那首先他会去判断你的 248 00:07:44,960 --> 00:07:48,760 这条记忆是闲聊噪声还是真的是实 249 00:07:48,760 --> 00:07:52,300 如果是重要性低和自信度低的话 250 00:07:52,300 --> 00:07:54,400 他就会选择一个丢弃 251 00:07:54,400 --> 00:07:57,820 其实我们这个记忆其实最重要的就是 252 00:07:57,820 --> 00:07:59,200 他必须正确 253 00:07:59,200 --> 00:08:01,260 就是他永远都会有一个reference 254 00:08:01,260 --> 00:08:03,700 可以指挥刚刚我们所谓的Rone Event 255 00:08:03,700 --> 00:08:05,360 一个Elling的原始事件 256 00:08:05,360 --> 00:08:06,820 因为这样我们 257 00:08:06,820 --> 00:08:09,100 我当时在考虑做这个记忆的时候 258 00:08:09,100 --> 00:08:12,160 其实想打造成一个可追溯的记忆 259 00:08:12,160 --> 00:08:14,920 并不是说像OpenCloud或者Hermas一样 260 00:08:14,920 --> 00:08:16,460 如果大模型觉得该写 261 00:08:16,460 --> 00:08:18,600 他就去写这个memory.md 262 00:08:18,600 --> 00:08:20,020 后面可能记错了 263 00:08:20,020 --> 00:08:22,960 或者说是记的事实有误的时候 264 00:08:22,960 --> 00:08:23,780 其实想追溯 265 00:08:23,780 --> 00:08:24,780 你其实并不知道 266 00:08:24,780 --> 00:08:26,960 他是什么时候把这个错误信息写了进去 267 00:08:26,960 --> 00:08:29,820 所以我在设计这个记系统的时候 268 00:08:29,820 --> 00:08:32,100 就有非常严苛的reference地址 269 00:08:32,100 --> 00:08:35,280 如果过了这两道检查关卡 270 00:08:35,280 --> 00:08:37,320 其实就会到一个我们的entity 271 00:08:37,320 --> 00:08:41,960 那这里可能就会有朋友问的去重合冲突 272 00:08:41,960 --> 00:08:43,980 那其实在entity这里 273 00:08:43,980 --> 00:08:46,860 可以给大家先在我们这里看一眼 274 00:08:46,860 --> 00:08:48,480 那其实我们会有个记忆数 275 00:08:48,480 --> 00:08:51,860 那其实每个entity下面 276 00:08:51,860 --> 00:08:54,500 每个主体下面都会有记忆 277 00:08:54,868 --> 00:09:04,868 如果有一條新的記憶進來,它會看是屬於這個user自己的,或者是哪個人物的,或者是某個事實的。 278 00:09:04,868 --> 00:09:07,448 当然你有了这些事实和人物之后 279 00:09:07,448 --> 00:09:09,748 你觉得这条记忆不好或者不重要 280 00:09:09,748 --> 00:09:13,028 或者你不想让它参与以后的记忆交回 281 00:09:13,028 --> 00:09:14,608 你可以把它弃用掉 282 00:09:14,608 --> 00:09:15,428 对 283 00:09:15,428 --> 00:09:16,688 一 284 00:09:16,688 --> 00:09:20,068 这个冲突消解会是在这个entity的时候 285 00:09:20,068 --> 00:09:22,108 它会读取你之前的记忆 286 00:09:22,108 --> 00:09:24,688 然后进行一个entity的重构 287 00:09:24,688 --> 00:09:26,208 你看这里也有 288 00:09:26,208 --> 00:09:27,488 如果和事实矛盾 289 00:09:27,488 --> 00:09:29,208 它会进冲突对冽 290 00:09:29,208 --> 00:09:31,308 如果冲突对冽在哪 291 00:09:31,308 --> 00:09:33,088 其实是在我们的记忆沉淀这里 292 00:09:33,088 --> 00:09:34,548 那我现在没有冲突的 293 00:09:34,548 --> 00:09:35,568 如果有冲突的 294 00:09:35,568 --> 00:09:37,708 它会希望你去check 295 00:09:37,708 --> 00:09:38,408 对看 296 00:09:38,408 --> 00:09:39,908 如果存在矛盾 297 00:09:39,908 --> 00:09:40,768 就尽 298 00:09:40,768 --> 00:09:42,048 如果你点采纳 299 00:09:42,048 --> 00:09:43,468 或你可以点轰略 300 00:09:43,468 --> 00:09:45,648 但是如果你七天没有的话 301 00:09:45,648 --> 00:09:47,648 它会判断是新的 302 00:09:47,648 --> 00:09:49,308 记忆自动采纳 303 00:09:49,308 --> 00:09:49,568 对 304 00:09:49,568 --> 00:09:51,388 我们先给大家回答一下 305 00:09:51,388 --> 00:09:52,508 几个高频的问题 306 00:09:52,508 --> 00:09:53,708 就是说我们的October 307 00:09:53,708 --> 00:09:54,788 和其他的产品 308 00:09:54,788 --> 00:09:56,468 它的定位有什么不同 309 00:09:56,468 --> 00:09:58,328 以及它的优势在哪里 310 00:09:58,328 --> 00:09:59,648 先给大家讲完 311 00:09:59,648 --> 00:10:00,148 我们待会儿 312 00:10:00,148 --> 00:10:01,468 我也会详细地讲解到 313 00:10:01,468 --> 00:10:01,888 记忆制 314 00:10:01,888 --> 00:10:03,008 大家有关于记忆的 315 00:10:03,008 --> 00:10:04,348 可以一起提问 316 00:10:04,348 --> 00:10:07,388 那其实从包括 317 00:10:07,388 --> 00:10:08,668 我其实刚刚也问了 318 00:10:08,668 --> 00:10:09,888 焦焦和杨真两个问题 319 00:10:09,888 --> 00:10:12,628 那其实研发可能就用Cloud Code 320 00:10:12,628 --> 00:10:13,308 用Codex 321 00:10:13,308 --> 00:10:15,268 包括我们公司的Codebody比较多 322 00:10:15,268 --> 00:10:17,448 办公可能就是我们Workbody 323 00:10:17,448 --> 00:10:20,868 现在其实也有些同事会用 324 00:10:20,868 --> 00:10:22,428 CC或者Codex 325 00:10:22,428 --> 00:10:24,428 就是做一个办公场景的Agent 326 00:10:24,428 --> 00:10:26,808 生活场景其实就是OpenCloud Hermes 327 00:10:26,808 --> 00:10:29,868 我们其实是处于这个项线位 328 00:10:29,868 --> 00:10:32,128 那其实首先比起个人 329 00:10:32,128 --> 00:10:33,948 我们Octop肯定是多用户的 330 00:10:33,948 --> 00:10:35,648 我们是支持多用户 331 00:10:35,648 --> 00:10:37,708 如果上一期直播 332 00:10:37,708 --> 00:10:40,488 Octop第一期直播没有看的观众朋友们 333 00:10:40,488 --> 00:10:42,448 可能是这里可以给大家介绍一下 334 00:10:42,448 --> 00:10:44,768 你在一台服务器部署了我们Octop 335 00:10:44,768 --> 00:10:46,688 你有一个主用户 336 00:10:46,688 --> 00:10:49,588 你也可以创建许多子用户去分给你 337 00:10:49,588 --> 00:10:50,628 不管是家人朋友 338 00:10:50,628 --> 00:10:52,768 你们可以一起共享这个Octop 339 00:10:52,768 --> 00:10:56,208 他们彼此之间的工作空间和记忆是隔离的 340 00:10:56,208 --> 00:10:58,588 只有一个龙虾就可以供一个小团队 341 00:10:58,588 --> 00:11:00,188 或者一家人去使用 342 00:11:00,188 --> 00:11:00,408 对 343 00:11:00,408 --> 00:11:02,568 不同的agent可以用不同的记忆 344 00:11:02,568 --> 00:11:03,008 对的 345 00:11:03,008 --> 00:11:04,968 刚刚说到不同的agent 346 00:11:04,968 --> 00:11:06,848 每个用户肯定记忆隔离 347 00:11:06,848 --> 00:11:09,288 其实上期直播也讲了多agent 348 00:11:09,288 --> 00:11:11,128 我们在一个用户的多agent下 349 00:11:11,128 --> 00:11:13,288 每个agent也是记忆隔离的 350 00:11:13,288 --> 00:11:15,588 这样就是防止我们记忆紊乱 351 00:11:15,588 --> 00:11:16,488 是的 352 00:11:16,488 --> 00:11:19,328 我们的粉丝朋友开头的问 353 00:11:19,328 --> 00:11:21,728 Octob是一个桌面应用程序吗 354 00:11:21,728 --> 00:11:23,688 这也是涉及到我们的定位问题 355 00:11:23,688 --> 00:11:29,448 Octob我们现在是一个开源的一个agent 356 00:11:29,448 --> 00:11:32,928 我们未来会推出轻量云应用镜像 357 00:11:32,928 --> 00:11:37,388 我们也支持PWA安装成应用程序 358 00:11:37,388 --> 00:11:39,508 PWA安装在桌面上 359 00:11:39,508 --> 00:11:41,828 如果后续有期待桌面客户端 360 00:11:41,828 --> 00:11:44,048 我们有精力也会投入 361 00:11:44,048 --> 00:11:46,608 最多可以支持用户 362 00:11:46,608 --> 00:11:49,588 最多就应该是看你服务系性能了 363 00:11:49,588 --> 00:11:51,328 如果你买个很多 364 00:11:51,328 --> 00:11:53,268 8核8G或者多核多G 365 00:11:53,268 --> 00:11:55,768 其实就可以承载很多个用户 366 00:11:55,768 --> 00:11:57,468 还有粉丝朋友问 367 00:11:57,468 --> 00:11:58,668 这个目的是用在 368 00:11:58,668 --> 00:12:00,528 OnCloud Hermes Workbody上面吗 369 00:12:00,528 --> 00:12:02,848 其实我们就是一个独立的agent 370 00:12:02,848 --> 00:12:04,048 对 371 00:12:04,048 --> 00:12:05,288 独立的agent 372 00:12:05,288 --> 00:12:06,908 就是跟OpenCloud 373 00:12:06,908 --> 00:12:07,868 Hermas Workbody 374 00:12:07,868 --> 00:12:09,208 我们同位agent 375 00:12:09,208 --> 00:12:11,168 可能有些相似或不同的功能 376 00:12:11,168 --> 00:12:12,788 其实刚刚就讲到 377 00:12:12,788 --> 00:12:13,848 首先我们是独用户 378 00:12:13,848 --> 00:12:15,068 我们其实是 379 00:12:15,068 --> 00:12:16,708 办公和生活场景 380 00:12:16,708 --> 00:12:18,748 都是比较通用的 381 00:12:18,748 --> 00:12:21,168 像我们Octop可以用来做PPT 382 00:12:21,168 --> 00:12:23,668 包括后面养殖会演示的竞品调研 383 00:12:23,668 --> 00:12:27,028 同时关注过我们直播间的朋友 384 00:12:27,028 --> 00:12:28,608 我们之前有个很火的直播 385 00:12:28,608 --> 00:12:30,308 就是我们的产品 386 00:12:30,308 --> 00:12:30,668 Anthel 387 00:12:30,668 --> 00:12:32,388 他在用ACE养娃 388 00:12:32,388 --> 00:12:36,108 对这个场景也同时迁移到了我们的Octop上 389 00:12:36,108 --> 00:12:38,128 大家也可以尝试一下用Octop养花 390 00:12:38,128 --> 00:12:39,948 对包括我自己啊 391 00:12:39,948 --> 00:12:43,008 我在用Octop做我的健康管理助手 392 00:12:43,008 --> 00:12:47,108 对其实办公和生活场景我们都能cover 393 00:12:47,108 --> 00:12:49,548 大家感兴趣的话可以都试一下 394 00:12:49,548 --> 00:12:52,248 可以直接作为记忆题给Workbody 395 00:12:52,248 --> 00:12:54,288 也就是我们的Hanath Memory 396 00:12:54,288 --> 00:12:55,728 也就是我们的Octop Memory 397 00:12:55,728 --> 00:12:59,208 我们现在还没有提供接入Workbody的记忆 398 00:12:59,208 --> 00:13:02,048 Workbody我理解他们应该有一个原生的记忆 399 00:13:02,048 --> 00:13:04,228 对我其实下面列了 400 00:13:04,228 --> 00:13:06,188 我们到底和别的记忆 401 00:13:06,188 --> 00:13:06,888 有什么不一样 402 00:13:06,888 --> 00:13:08,448 那Workbody它其实 403 00:13:08,448 --> 00:13:10,208 记忆是产品内封装的 404 00:13:10,208 --> 00:13:12,188 如果后续大家感兴趣 405 00:13:12,188 --> 00:13:13,848 可以说去看看 406 00:13:13,848 --> 00:13:15,048 怎么合作对接一下 407 00:13:15,048 --> 00:13:15,288 对 408 00:13:15,288 --> 00:13:17,468 我问了一个非常经典的 409 00:13:17,468 --> 00:13:18,428 为啥叫Octop 410 00:13:18,428 --> 00:13:20,128 其实上一期直播 411 00:13:20,128 --> 00:13:21,568 也有朋友问 412 00:13:21,568 --> 00:13:23,128 那给我们取这个名字 413 00:13:23,128 --> 00:13:24,508 其实是我们的一名主播 414 00:13:24,508 --> 00:13:25,648 他原来想一个名字 415 00:13:25,648 --> 00:13:26,548 叫Octopus 416 00:13:26,548 --> 00:13:28,128 就是Octopus 417 00:13:28,128 --> 00:13:29,008 就是章鱼 418 00:13:29,008 --> 00:13:30,568 因为我们多用户 419 00:13:30,568 --> 00:13:31,248 多专家 420 00:13:31,248 --> 00:13:33,808 还有多智能体非常多 421 00:13:33,808 --> 00:13:35,788 就像章鱼非常多的触手一样 422 00:13:35,788 --> 00:13:37,528 所以我们想了Octopus 423 00:13:37,528 --> 00:13:39,468 但是为了一是好发音 424 00:13:39,468 --> 00:13:43,768 二是我们比较想要Top这个后缀 425 00:13:43,768 --> 00:13:45,388 所以我们改名叫On Top 426 00:13:45,388 --> 00:13:48,988 那我看我们也是列举了 427 00:13:48,988 --> 00:13:51,308 不同的形态的Agent的区别 428 00:13:51,308 --> 00:13:53,968 您这一块可以给我们详细的介绍一下吗 429 00:13:53,968 --> 00:13:56,308 直播间的粉丝朋友们可以截图保存 430 00:13:56,308 --> 00:13:58,208 大家如果对这一块 431 00:13:58,208 --> 00:14:00,248 不仔细的可以截图保存一下 432 00:14:00,248 --> 00:14:04,708 其实我理解大家问的最多应该是Open Cloud Hermes 433 00:14:04,708 --> 00:14:06,888 跟我们到底有什么不一样 434 00:14:06,888 --> 00:14:10,528 其实Cloud Code和Codex就是一个编码agent 435 00:14:10,528 --> 00:14:13,548 大家用的最多的也是我们直播间出现最多的 436 00:14:13,548 --> 00:14:14,788 就是Open Cloud Hermes 437 00:14:14,788 --> 00:14:17,648 然后它跟我们一个最大区别是 438 00:14:17,648 --> 00:14:19,948 我们其实是一个多专家 439 00:14:19,948 --> 00:14:23,328 包括一个用户你可以创建非常多的专家 440 00:14:23,328 --> 00:14:26,388 也就是你可以就比如我和杨直 441 00:14:26,388 --> 00:14:28,008 我们俩是一个小团队 442 00:14:28,008 --> 00:14:29,368 我是Admin 443 00:14:29,368 --> 00:14:32,968 我可以创建我自己的生活助理和办公助理 444 00:14:32,968 --> 00:14:34,788 这两个助理都在Octop 445 00:14:34,788 --> 00:14:36,068 都使用一个Octop 446 00:14:36,068 --> 00:14:38,128 他们工作区和记忆是完全隔离的 447 00:14:38,128 --> 00:14:40,808 同时我还可以创建一个子用户给杨指 448 00:14:40,808 --> 00:14:43,808 杨指也可以创建属于他自己的多专家 449 00:14:43,808 --> 00:14:44,448 对 450 00:14:44,448 --> 00:14:47,128 每个专家对于IM渠道都是隔离的 451 00:14:47,128 --> 00:14:50,128 所以如果想要就可以生活场景 452 00:14:50,128 --> 00:14:51,708 就在微信上接入 453 00:14:51,708 --> 00:14:52,668 办公场景 454 00:14:52,668 --> 00:14:54,808 我们就连飞书或起飞或丁丁 455 00:14:54,808 --> 00:14:56,748 我们也都支持 456 00:14:56,748 --> 00:14:57,148 对 457 00:14:57,148 --> 00:14:59,448 其实这是一个最大的不同 458 00:14:59,448 --> 00:15:00,628 像OpenCloud和Hermes 459 00:15:00,628 --> 00:15:01,668 他们都是个人Agent 460 00:15:01,668 --> 00:15:04,228 包括他们也只支持单人用户 461 00:15:04,228 --> 00:15:05,808 我们是多用户 462 00:15:05,808 --> 00:15:07,428 然后一人部署全家 463 00:15:07,428 --> 00:15:08,728 关键问题是 464 00:15:08,728 --> 00:15:09,908 你这个产品支持多少个通道 465 00:15:09,908 --> 00:15:11,068 我们这也有介绍的 466 00:15:11,068 --> 00:15:11,828 是的 467 00:15:11,828 --> 00:15:13,108 我们其实支持 468 00:15:13,108 --> 00:15:14,768 飞书丁丁 启威 QQ 469 00:15:14,768 --> 00:15:15,828 很多通道 470 00:15:15,828 --> 00:15:18,488 像我可以在这个里面 471 00:15:18,488 --> 00:15:20,528 这就是我们实际的产品面板 472 00:15:20,528 --> 00:15:21,808 可以给大家看一下 473 00:15:21,808 --> 00:15:24,088 支持微信 QQ 启威 启威 元宝 474 00:15:24,088 --> 00:15:25,988 包括华为的小益 475 00:15:25,988 --> 00:15:26,828 也小易都可以 476 00:15:26,828 --> 00:15:29,428 对包括这个MQTT也可以看 477 00:15:29,428 --> 00:15:32,148 刚刚我举例一个用户有多个专家 478 00:15:32,148 --> 00:15:34,488 他们每个人其实都可以配那么多的通道 479 00:15:34,488 --> 00:15:35,948 每个专家可以配多通道 480 00:15:35,948 --> 00:15:36,828 对是的 481 00:15:36,828 --> 00:15:38,348 那还是很全面的 482 00:15:38,348 --> 00:15:39,988 是的欢迎大家使用 483 00:15:39,988 --> 00:15:42,688 有用户在问我们官网地址是什么 484 00:15:42,688 --> 00:15:47,188 我们官网地址是好给大家放大一下 485 00:15:47,188 --> 00:15:50,748 请搜Github 486 00:15:50,748 --> 00:15:54,688 在我们Tencent Cloud项目下的OCTO 487 00:15:54,688 --> 00:15:58,088 对也欢迎大家记得支持我们的产品 488 00:15:58,088 --> 00:15:58,728 GateStar 489 00:15:58,728 --> 00:16:00,568 对那我现在回答现在一下这个用户 490 00:16:00,568 --> 00:16:02,248 QQ是不是只是单鸟 491 00:16:02,248 --> 00:16:04,368 如果是群鸟是不是还得用QQBot 492 00:16:04,368 --> 00:16:06,328 那么非常感谢这位用户的提问 493 00:16:06,328 --> 00:16:07,968 这个QQ群鸟现在已经支持了 494 00:16:07,968 --> 00:16:10,408 但是我们未来会继续拓展我们的QQ群鸟 495 00:16:10,408 --> 00:16:12,088 包括我们的QQ的一个多Agent 496 00:16:12,088 --> 00:16:14,128 会接入到我们的包括QQ频道 497 00:16:14,128 --> 00:16:15,768 我们也可以用家庭群 498 00:16:15,768 --> 00:16:17,208 我们也会接入我们的Agent 499 00:16:17,208 --> 00:16:19,208 每个家庭用户都有机会在里面提问 500 00:16:19,208 --> 00:16:20,208 这是我们下一步的打算 501 00:16:20,208 --> 00:16:21,688 没错可以多个Agent 502 00:16:21,688 --> 00:16:22,328 当然可以了 503 00:16:22,328 --> 00:16:25,688 我们当然可以用多个Agent在一个聊天框里面去执行共同任务 504 00:16:25,688 --> 00:16:26,688 的话我们会展示的 505 00:16:27,488 --> 00:16:29,568 对其实关于我讲的记忆的话 506 00:16:29,568 --> 00:16:31,088 像OpenCloud和Hermes 507 00:16:31,088 --> 00:16:33,168 他们其实都是把他们的MD 508 00:16:33,168 --> 00:16:36,288 加入就是系统提示词 509 00:16:36,288 --> 00:16:37,568 然后被读到 510 00:16:37,568 --> 00:16:42,968 你要记的时候就是叫OpenCloud和HermesAgent本身去写Memory的MD 511 00:16:42,968 --> 00:16:47,408 那我们其实讲到稍微提了一点关于沉淀和召回 512 00:16:47,408 --> 00:16:48,528 包括我们的牵引能力 513 00:16:48,528 --> 00:16:50,088 后续我会细讲 514 00:16:50,288 --> 00:16:51,768 对其实还有很多功能 515 00:16:51,768 --> 00:16:54,568 包括ACP其实刚刚有提到 516 00:16:56,868 --> 00:17:04,868 那其实我们和不管是Cloud Code还是Codex,甚至Codebody OpenCode,我们并不是竞品,我们其实是可以调用它们的能力的。 517 00:17:04,868 --> 00:17:07,628 因为Octop有个邪教ACP 518 00:17:07,628 --> 00:17:11,308 可以通过ACP就是连接上Codec和Code 519 00:17:11,308 --> 00:17:12,708 你如果想编程 520 00:17:12,708 --> 00:17:16,108 你想用更成熟的CodeAgent 521 00:17:16,108 --> 00:17:17,948 你就可以把任务委派给他们 522 00:17:17,948 --> 00:17:20,428 也是在我们Octop里是可以实现的 523 00:17:20,428 --> 00:17:22,988 有粉丝朋友问能自己部署吗 524 00:17:22,988 --> 00:17:23,468 可以的 525 00:17:23,468 --> 00:17:26,408 请关注我们的Octop Geekhub仓库 526 00:17:26,408 --> 00:17:28,048 然后在我们的ReadMe里 527 00:17:28,048 --> 00:17:30,348 有详细的字部署教程 528 00:17:30,348 --> 00:17:32,908 如果是想用镜上一键部署的话 529 00:17:32,908 --> 00:17:35,268 我们未来也会提供镜像 530 00:17:35,268 --> 00:17:37,708 可以在腾讯控制台直接购买 531 00:17:37,708 --> 00:17:40,068 也是使用腾讯轻量服务器 532 00:17:40,068 --> 00:17:42,708 对我们后续会提供轻量服务器的镜像 533 00:17:42,708 --> 00:17:43,108 很快 534 00:17:43,108 --> 00:17:44,248 本周或者下周 535 00:17:44,248 --> 00:17:46,608 我们现在有一点最后的工作 536 00:17:46,608 --> 00:17:47,548 我们即将会出 537 00:17:47,548 --> 00:17:49,848 对欢迎大家即使关注我们轻量 538 00:17:49,848 --> 00:17:52,228 我们会适时推出我们的Octop镜像 539 00:17:52,228 --> 00:17:53,488 也就是以前我们的ACE镜像 540 00:17:53,488 --> 00:17:55,508 用户也可以升级到Octop镜像 541 00:17:55,508 --> 00:17:56,828 对了我们的ACE是不是要升级了 542 00:17:56,828 --> 00:17:59,448 是的我们也会提供轻易工具 543 00:17:59,448 --> 00:18:01,408 既然说到这了 544 00:18:01,408 --> 00:18:03,708 那就给大家演示一下 545 00:18:03,708 --> 00:18:05,868 如果有我们的老用户的话 546 00:18:05,868 --> 00:18:10,028 可以更新到我们最新的0.1.31版本 547 00:18:10,028 --> 00:18:12,248 认准我们0.1.31版本 548 00:18:12,248 --> 00:18:13,908 在高级设置里 549 00:18:13,908 --> 00:18:15,848 可以看到一个导出到Octop 550 00:18:15,848 --> 00:18:18,988 然后这里就可以导出到Octop 551 00:18:18,988 --> 00:18:20,788 可以打包一个备份 552 00:18:20,788 --> 00:18:22,928 可以看到这个备份 553 00:18:22,928 --> 00:18:25,528 其实已经就是TAR包下下来了 554 00:18:25,528 --> 00:18:27,868 然后再打开我们的Octop 555 00:18:27,868 --> 00:18:29,588 然后再应用设置 556 00:18:29,588 --> 00:18:30,828 有个备份与恢复 557 00:18:30,828 --> 00:18:33,108 首先就上传我们刚刚 558 00:18:33,108 --> 00:18:35,968 你看这就是19.32刚刚那个备份 559 00:18:35,968 --> 00:18:37,708 我们把它上传了 560 00:18:37,708 --> 00:18:40,228 然后我们就点恢复 561 00:18:40,228 --> 00:18:42,968 请大家记住我们的用户名就是 562 00:18:42,968 --> 00:18:47,308 密码就是之前在LiteCloud设置的那个密码 563 00:18:47,308 --> 00:18:48,448 我们继续来学习 564 00:18:48,448 --> 00:18:51,768 其实刚刚给大家也讲了 565 00:18:51,768 --> 00:18:54,568 我们跟OpenCloud跟Hermas 566 00:18:54,568 --> 00:18:56,968 包括跟Cloudcode和Codex 567 00:18:56,968 --> 00:18:59,368 在产品上和记忆上有什么不同 568 00:18:59,368 --> 00:19:02,588 那Octop memory到底是怎么样的呢 569 00:19:02,588 --> 00:19:03,868 那就给大家 570 00:19:03,868 --> 00:19:06,808 其实我在PT里给大家做个比喻 571 00:19:06,808 --> 00:19:08,108 如果把我们的记忆 572 00:19:08,108 --> 00:19:09,668 比做成一家暴数 573 00:19:09,668 --> 00:19:11,048 那我们常驻的 574 00:19:11,048 --> 00:19:14,808 除了常驻的memory.md文件之外 575 00:19:14,808 --> 00:19:17,308 那其实我们刚刚其实介绍 576 00:19:17,308 --> 00:19:18,708 有个roll event 577 00:19:18,708 --> 00:19:20,028 它就是一个录音笔 578 00:19:20,028 --> 00:19:23,028 就是你跟Octop说了什么 579 00:19:23,028 --> 00:19:23,928 它都会记住 580 00:19:23,928 --> 00:19:26,208 然后它永远是一个证据员 581 00:19:26,208 --> 00:19:28,108 我们刚刚说到 582 00:19:28,108 --> 00:19:29,568 在记忆招回的时候 583 00:19:29,568 --> 00:19:31,148 不管招回的是哪条记忆 584 00:19:31,148 --> 00:19:32,728 最后都能refer 585 00:19:32,728 --> 00:19:36,168 就能溯源到你跟Octop的对话 586 00:19:36,168 --> 00:19:40,488 就是保证我们记忆永远是正确的一个机制 587 00:19:40,488 --> 00:19:42,168 所以它是一个录音笔 588 00:19:42,168 --> 00:19:44,168 下一层就是一个candidate 589 00:19:44,168 --> 00:19:45,368 就是记者初稿 590 00:19:45,368 --> 00:19:49,308 那就是大模型从原始对话中 591 00:19:49,308 --> 00:19:51,508 就是从用户跟Octop对话中 592 00:19:51,508 --> 00:19:53,588 抽取出的候选事实 593 00:19:53,588 --> 00:19:55,228 但是为什么是初稿呢 594 00:19:55,228 --> 00:19:56,608 因为它只是一个候选事实 595 00:19:56,608 --> 00:19:57,548 它还没有见报 596 00:19:57,548 --> 00:20:00,528 在Candidate这一层解决完冲突 597 00:20:00,528 --> 00:20:02,108 通过用户审核 598 00:20:02,108 --> 00:20:05,288 然后在重要性和置信度上面 599 00:20:05,288 --> 00:20:07,388 有所筛选之后 600 00:20:07,388 --> 00:20:10,368 然后它才会晋升成一个Atom Card 601 00:20:10,368 --> 00:20:12,068 就是一个正式简报 602 00:20:12,068 --> 00:20:14,008 当然这也是我们在 603 00:20:14,008 --> 00:20:16,628 就是我们的Octop面板中会看到的记忆 604 00:20:16,628 --> 00:20:18,948 它也是我们的召回主力层 605 00:20:18,948 --> 00:20:21,388 当然后面我们会讲到召回 606 00:20:21,388 --> 00:20:24,828 除此之外我们还有一个日记层 607 00:20:24,828 --> 00:20:28,488 那这个其实是除了上面的事实之外的东西 608 00:20:28,488 --> 00:20:30,808 就是一些装事实过滤掉的东西 609 00:20:30,808 --> 00:20:33,548 比如是生活事件和情绪 610 00:20:33,548 --> 00:20:36,088 它是和事实管线病情跑的 611 00:20:36,088 --> 00:20:36,808 并不污染 612 00:20:36,808 --> 00:20:39,528 了解我们AC和Octop的话 613 00:20:39,528 --> 00:20:41,948 知道我们会有一个主动关心机制 614 00:20:41,948 --> 00:20:45,768 那其实这个机制就是探查到用户的心情 615 00:20:45,768 --> 00:20:48,048 在用户开心的时候会鼓励他 616 00:20:48,048 --> 00:20:50,468 以及在用户低落的时候会安慰他 617 00:20:50,468 --> 00:20:54,048 然后在Octop里其实就是靠着我们这个日记层 618 00:20:54,048 --> 00:20:56,028 其实我们还有人物词条 619 00:20:56,028 --> 00:20:58,568 所有的正式建报的原子卡片 620 00:20:58,568 --> 00:21:00,868 都会在一个人物词条下 621 00:21:00,868 --> 00:21:04,668 它会把原子卡片归类到人物词条 622 00:21:04,668 --> 00:21:06,228 包括用户人物事实 623 00:21:06,228 --> 00:21:09,528 在这样就会每条原子卡片之间 624 00:21:09,528 --> 00:21:10,748 就会产生联系 625 00:21:10,748 --> 00:21:12,668 最后是神器流水 626 00:21:12,668 --> 00:21:15,908 因为听课的观众朋友们 627 00:21:15,908 --> 00:21:17,648 可能就会有问题 628 00:21:17,648 --> 00:21:20,428 那所有记忆的生成都靠大模型 629 00:21:20,428 --> 00:21:22,468 那它是怎么做的 630 00:21:22,468 --> 00:21:24,148 那其实就是神器流水 631 00:21:24,148 --> 00:21:26,028 它可以记住大模型 632 00:21:26,028 --> 00:21:27,828 从哪一条事实中 633 00:21:27,828 --> 00:21:30,428 那个对话中提取到了哪些候选 634 00:21:30,428 --> 00:21:32,148 候选怎么进生存原子卡片 635 00:21:32,148 --> 00:21:34,628 都会在我们的面板中一一显示 636 00:21:34,628 --> 00:21:36,508 包括删除 包括冲突 637 00:21:36,508 --> 00:21:36,908 对 638 00:21:36,908 --> 00:21:38,708 那其实我有一个小白的问题 639 00:21:38,708 --> 00:21:39,908 想问一下英明 640 00:21:39,908 --> 00:21:41,828 不知道直播间有没有类似的问题 641 00:21:41,828 --> 00:21:44,468 关于我们记忆它的一个沉淀和召回 642 00:21:44,468 --> 00:21:45,508 它具体指的是什么 643 00:21:45,508 --> 00:21:46,708 是这个概念怎么理解 644 00:21:46,708 --> 00:21:47,828 记忆的沉淀 645 00:21:47,828 --> 00:21:49,228 像焦焦其实有在 646 00:21:49,228 --> 00:21:50,828 一样OpenCloud和Hermes 647 00:21:50,828 --> 00:21:52,268 那比如说 648 00:21:52,468 --> 00:21:56,108 那你最近一个问你的Hermas的问题是什么 649 00:21:56,108 --> 00:21:58,968 焦焦你可以告诉我们你在什么一个场景下用了它 650 00:21:58,968 --> 00:22:04,688 就比如说最近一次让他帮我撰写一下我们这个直播的整个的策划 651 00:22:04,688 --> 00:22:08,088 对那关于你和他在这个对话中 652 00:22:08,088 --> 00:22:10,268 那记忆的沉淀他会记住 653 00:22:10,268 --> 00:22:15,828 我的主人焦焦那今天其实是叫我帮忙撰写这个直播的计划 654 00:22:15,828 --> 00:22:18,728 那他会根据你给他提示词沉淀一下 655 00:22:18,728 --> 00:22:22,068 焦焦在今天那他参与了主题什么什么的直播 656 00:22:22,068 --> 00:22:23,788 他就会根据你的对话 657 00:22:23,788 --> 00:22:25,768 然后记住一些有用的事实 658 00:22:25,768 --> 00:22:27,648 或者你今天做的事情 659 00:22:27,648 --> 00:22:29,048 这就是记得沉淀 660 00:22:29,048 --> 00:22:29,868 对 661 00:22:29,868 --> 00:22:32,168 那什么是召回呢 662 00:22:32,168 --> 00:22:33,288 那比如说 663 00:22:33,288 --> 00:22:35,008 那下次直播的时候 664 00:22:35,008 --> 00:22:38,408 如果你再跟你的龙虾对话 665 00:22:38,408 --> 00:22:41,008 其实如果就是人与人之间对话 666 00:22:41,008 --> 00:22:41,588 比如说 667 00:22:41,588 --> 00:22:42,928 比如说我昨天跟杨子说 668 00:22:42,928 --> 00:22:44,428 那我可能昨天跟杨子说 669 00:22:44,428 --> 00:22:45,348 我最近有点烧火 670 00:22:45,348 --> 00:22:47,048 那可能我今天说 671 00:22:47,048 --> 00:22:48,968 OK我要去吃炸鸡 672 00:22:48,968 --> 00:22:50,548 那杨子就会响起 673 00:22:50,548 --> 00:22:52,948 那我说我昨天有点上火 674 00:22:52,948 --> 00:22:55,568 他就会可能想起这个相关性 675 00:22:55,568 --> 00:22:57,728 那其实agent也会这样 676 00:22:57,728 --> 00:22:59,188 如果你下次跟他说 677 00:22:59,188 --> 00:23:01,368 你又要撰写一个直播的 678 00:23:01,368 --> 00:23:03,608 PPT或者直播的大纲了 679 00:23:03,608 --> 00:23:05,648 他应该像人一样想起 680 00:23:05,648 --> 00:23:07,708 你之前跟他说过的相似的对话 681 00:23:07,708 --> 00:23:10,468 然后来帮助你更好的去优化你的工作 682 00:23:10,468 --> 00:23:12,408 工作这就是记忆的召回 683 00:23:12,408 --> 00:23:13,808 了解了 684 00:23:13,808 --> 00:23:14,708 好的学到了 685 00:23:14,708 --> 00:23:16,648 那其实刚刚讲那么多 686 00:23:16,648 --> 00:23:19,008 那就来实力演练一下 687 00:23:19,008 --> 00:23:24,468 那假如这个用户在一台安装了OctopMemory的agent上说 688 00:23:24,468 --> 00:23:26,488 跟这个agent说 689 00:23:26,488 --> 00:23:29,028 那这个项目暂时先别上PG了 690 00:23:29,028 --> 00:23:30,188 PG就是一个数据库 691 00:23:30,188 --> 00:23:32,888 说本地SecureLights已经够用了 692 00:23:32,888 --> 00:23:34,628 说他下周要去上海出差 693 00:23:34,628 --> 00:23:35,348 有点焦虑 694 00:23:35,348 --> 00:23:38,288 那其实这句话包含了很多信息 695 00:23:38,288 --> 00:23:40,808 首先L0层就是我们刚刚的事实 696 00:23:40,808 --> 00:23:41,588 就是录音笔 697 00:23:41,588 --> 00:23:44,508 他会把这句话记下来 698 00:23:44,508 --> 00:23:45,708 在录音笔之外 699 00:23:45,708 --> 00:23:47,288 到了我们的候选事实 700 00:23:47,288 --> 00:23:49,348 那一有日记 701 00:23:49,348 --> 00:23:51,248 下周去上海出差有点焦虑 702 00:23:51,248 --> 00:23:54,528 因为这只是一个一时的心情 703 00:23:54,528 --> 00:23:57,668 他可能在工作中不太会被需要 704 00:23:57,668 --> 00:24:00,488 那这个项目不用PG 705 00:24:00,488 --> 00:24:01,308 用CircleLite 706 00:24:01,308 --> 00:24:03,548 这可能就是一个工具强相关的事实 707 00:24:03,548 --> 00:24:05,368 那心情就进日记 708 00:24:05,368 --> 00:24:07,308 事实就进我们的候选卡片 709 00:24:07,308 --> 00:24:10,008 那就说到了刚刚的五层 710 00:24:10,008 --> 00:24:13,608 那看看他的自信度和重要性够吗 711 00:24:13,608 --> 00:24:15,768 有没有可以录音证据 712 00:24:15,768 --> 00:24:17,388 用0的原始试试程 713 00:24:17,388 --> 00:24:19,388 到底能不能被指导 714 00:24:19,388 --> 00:24:20,628 如果被指导 715 00:24:20,628 --> 00:24:22,368 那我们就要进生成 716 00:24:22,368 --> 00:24:24,208 就是正式的原子卡片了 717 00:24:24,208 --> 00:24:26,408 那我们这个原子卡片里 718 00:24:26,408 --> 00:24:27,608 有没有一个实体 719 00:24:27,608 --> 00:24:29,028 可以让它归类 720 00:24:29,028 --> 00:24:29,748 如果有的话 721 00:24:29,748 --> 00:24:30,988 那就装进这个实体 722 00:24:30,988 --> 00:24:33,808 没有就重新去生成一个实体 723 00:24:33,808 --> 00:24:34,988 我再看看 724 00:24:34,988 --> 00:24:37,228 跟数据库里的事实 725 00:24:37,228 --> 00:24:37,908 有没有冲突 726 00:24:37,908 --> 00:24:39,748 可能我们数据库里面 727 00:24:39,748 --> 00:24:41,308 三个月前有一条事实是 728 00:24:41,308 --> 00:24:44,468 那我们就要用PG做足裤 729 00:24:44,468 --> 00:24:46,588 然后当我们现在说了一句话 730 00:24:46,588 --> 00:24:48,068 是别上PG了 731 00:24:48,068 --> 00:24:49,748 他就检测到有冲突 732 00:24:49,748 --> 00:24:51,468 那他其实就会触发 733 00:24:51,468 --> 00:24:54,048 刚刚我们演示的那个有冲突 734 00:24:54,048 --> 00:24:54,848 那就等待用 735 00:24:56,968 --> 00:25:00,068 這就是我們整體的一個沉澱路線了。 736 00:25:00,068 --> 00:25:03,868 那下面其實講解就是G的最後一部分,就是召回。 737 00:25:03,868 --> 00:25:08,368 那召回那又是一個實力演練,一個舉例。 738 00:25:08,368 --> 00:25:10,408 如果一个用户就是问 739 00:25:10,408 --> 00:25:13,768 那个项目的当时的数据库是怎么定的来着 740 00:25:13,768 --> 00:25:16,608 那首先会去查一个缓存 741 00:25:16,608 --> 00:25:20,088 看这个缓存里有没有相关的关键字 742 00:25:20,088 --> 00:25:20,608 如果没有 743 00:25:20,608 --> 00:25:24,488 那就直接去进行一个用BM25 744 00:25:24,488 --> 00:25:27,288 就是我们的一个招回的一个算法 745 00:25:27,288 --> 00:25:28,648 然后去搜索 746 00:25:28,648 --> 00:25:31,608 那有没有相应的原子卡片 747 00:25:31,608 --> 00:25:32,608 那搜到了 748 00:25:32,608 --> 00:25:34,768 就是我们刚刚说的 749 00:25:34,768 --> 00:25:38,168 那Octob这个暂时先不用PG了 750 00:25:38,168 --> 00:25:39,928 先用本地的Syculate 751 00:25:39,928 --> 00:25:41,828 它就是搜到之后 752 00:25:41,828 --> 00:25:44,308 它就可以回答用户的这个问题了 753 00:25:44,308 --> 00:25:48,928 就是它的一个运行的内在机制的原理是吗 754 00:25:48,928 --> 00:25:50,908 一步一步是如何运作的 755 00:25:50,908 --> 00:25:51,628 对的 756 00:25:51,628 --> 00:25:54,028 其实还有很多细节 757 00:25:54,028 --> 00:25:55,508 但是我们未来实在不 758 00:25:55,508 --> 00:25:56,688 在很近的未来 759 00:25:56,688 --> 00:25:58,228 马上就会把我们的记忆开远 760 00:25:58,228 --> 00:26:01,848 感兴趣的朋友也可以先关注我们的Octop 761 00:26:01,848 --> 00:26:04,308 后续我们的Octop Memory 762 00:26:04,308 --> 00:26:07,208 也会随之在Tencent Cloud下面开远的 763 00:26:07,208 --> 00:26:09,528 如果说以后再云服务器 764 00:26:09,528 --> 00:26:11,228 部署了是不是只有国外的服务器 765 00:26:11,228 --> 00:26:13,408 可以去调用GPT的模型呢 766 00:26:13,408 --> 00:26:14,588 是的 767 00:26:14,588 --> 00:26:17,008 调用GPT的模型 768 00:26:17,008 --> 00:26:18,528 其实是取决于GPT 769 00:26:18,528 --> 00:26:20,828 它本身可以在哪个地位调用 770 00:26:20,828 --> 00:26:23,008 那如果在中国 771 00:26:23,008 --> 00:26:25,468 或者在哪里 772 00:26:25,468 --> 00:26:26,608 不能访问GPT 773 00:26:26,608 --> 00:26:27,768 你就是调用不了 774 00:26:27,768 --> 00:26:30,548 你只能在能调用GPT地域的服务器 775 00:26:30,548 --> 00:26:32,568 然后去调用到GPT 776 00:26:32,568 --> 00:26:32,888 对 777 00:26:32,888 --> 00:26:36,428 问目前Optop采用默认Q-Lite 778 00:26:36,428 --> 00:26:41,168 而不用PG是出于怎样的考虑呢 779 00:26:41,168 --> 00:26:43,188 这各位粉丝朋友问得很好 780 00:26:43,188 --> 00:26:45,068 其实我们现在也支持PG了 781 00:26:45,068 --> 00:26:46,908 但是默认是Ciclite 782 00:26:46,908 --> 00:26:50,728 一是可以支持用户一键安装完就可以使用 783 00:26:50,728 --> 00:26:53,108 默认就是在本地创建一个Ciclite 784 00:26:53,108 --> 00:26:54,328 这个服务就可以用了 785 00:26:54,328 --> 00:26:58,288 然后也不是说需要用户去建一个PG配置 786 00:26:58,288 --> 00:26:59,768 那如果有高端用户 787 00:26:59,768 --> 00:27:01,108 如果想做分布式 788 00:27:01,108 --> 00:27:01,708 想用PG 789 00:27:01,708 --> 00:27:03,988 我们其实也是完全可以支持PG 790 00:27:03,988 --> 00:27:05,848 对这个能力我们现在已经支持了 791 00:27:05,848 --> 00:27:10,848 对,那其实今天记忆讲的其实就是这么多了 792 00:27:10,848 --> 00:27:15,848 那如果大家还有后续问题可以一是在我们的GitHub主页上给我们提问 793 00:27:15,848 --> 00:27:18,848 二是进入我们的用户群,然后提问 794 00:27:18,848 --> 00:27:23,848 这个直播的下半场其实要有请我们杨纸给大家做一些实力的介绍 795 00:27:23,848 --> 00:27:25,848 好的,大家好,我叫杨纸 796 00:27:25,848 --> 00:27:29,848 那我来和大家分享一下我们的多专家多Agent的病情,如何来重复我们的进行 797 00:27:29,848 --> 00:27:35,728 我想问问您有没有在比如说CodeBody或者是WorkBody里面使用过多Agent多专家 798 00:27:35,728 --> 00:27:37,348 想教教我们是不是有经常去使用 799 00:27:37,348 --> 00:27:38,728 那我先说确实 800 00:27:38,728 --> 00:27:42,268 比如让WorkBody帮我做某一个PT的时候 801 00:27:42,268 --> 00:27:48,808 他其实自己先是会调用一下很多Agent去分别做一些小步骤的事情 802 00:27:48,808 --> 00:27:49,728 最后再汇总 803 00:27:49,728 --> 00:27:51,808 然后多专家我其实也有体验到 804 00:27:51,808 --> 00:27:56,728 因为熟悉WorkBody的朋友应该知道可以在一个项目里增加很多专家 805 00:27:56,728 --> 00:27:58,648 你就可以去调用这些专家的努力 806 00:27:58,648 --> 00:28:00,108 对那么我们的 807 00:28:00,108 --> 00:28:02,188 也是具备这么大的能力 808 00:28:02,188 --> 00:28:02,988 包括像您如果在 809 00:28:02,988 --> 00:28:03,708 QQ通道里面 810 00:28:03,708 --> 00:28:05,008 我们可以支持家庭去聊 811 00:28:05,008 --> 00:28:05,708 包括微信通道 812 00:28:05,708 --> 00:28:06,388 如果以后开通了 813 00:28:06,388 --> 00:28:07,308 我们会相信支持 814 00:28:07,308 --> 00:28:08,188 然后还有一些用户 815 00:28:08,188 --> 00:28:08,748 还在提问 816 00:28:08,748 --> 00:28:10,308 有没有agent team的想法 817 00:28:10,308 --> 00:28:11,988 对我们现在正在调研agent team 818 00:28:11,988 --> 00:28:13,188 也是在不久之后 819 00:28:13,188 --> 00:28:14,088 也会推出agent team 820 00:28:14,088 --> 00:28:14,988 那么我就回到了正题 821 00:28:14,988 --> 00:28:16,548 我们讲一讲我们的多次能题 822 00:28:16,548 --> 00:28:18,488 我们的就刚和大家多聊了 823 00:28:18,488 --> 00:28:19,848 觉得专家其实 824 00:28:19,848 --> 00:28:20,748 确实用的挺多的 825 00:28:20,748 --> 00:28:22,108 不管是Ethan Giorg之前 826 00:28:22,108 --> 00:28:23,248 直播的育儿专家 827 00:28:23,248 --> 00:28:25,048 包括现在我们大家 828 00:28:25,048 --> 00:28:25,788 在用workbody 829 00:28:25,788 --> 00:28:26,908 去做一些竞品类的 830 00:28:26,908 --> 00:28:28,308 一个调研专家 831 00:28:28,308 --> 00:28:30,748 那么我们今天就会给大家来实战演练一下 832 00:28:30,748 --> 00:28:33,908 我想想你你可能是不还是会经常遇见老板会给你 833 00:28:33,908 --> 00:28:35,468 下发一个很艰巨的任务 834 00:28:35,468 --> 00:28:36,428 叫你去完成呢 835 00:28:36,428 --> 00:28:37,148 是的 836 00:28:37,148 --> 00:28:41,788 对其实像我们同事之间也会有经常像 837 00:28:41,788 --> 00:28:46,948 包括我们在研究这种比较新的产品也会需要调研很多东西 838 00:28:46,948 --> 00:28:47,268 对的 839 00:28:47,268 --> 00:28:48,868 像有一个传统像OpenCloud 840 00:28:48,868 --> 00:28:51,588 他只支持就是说你在一个亲户里面 841 00:28:51,588 --> 00:28:54,668 可能只是单个agent在那里给你调研究 842 00:28:54,668 --> 00:28:55,348 其实它非常慢 843 00:28:55,348 --> 00:28:56,308 现在我们在ACE 844 00:28:56,308 --> 00:28:58,028 假如我的一个老板下午要求我 845 00:28:58,028 --> 00:29:00,388 去调研一下想必大家都在喝茶饮 846 00:29:00,388 --> 00:29:01,628 比如说洗茶耐血 847 00:29:01,628 --> 00:29:02,668 比如说帮忙茶几 848 00:29:02,668 --> 00:29:04,488 老板会比较关心里面的产品 849 00:29:04,488 --> 00:29:06,828 竞品如何调研价格产品营销 850 00:29:06,828 --> 00:29:09,068 往往你期间的OpenCloud可能是单A进程 851 00:29:09,068 --> 00:29:10,368 它的调研会非常慢 852 00:29:10,368 --> 00:29:12,348 那么我们的Octop显然是领先于它的 853 00:29:12,348 --> 00:29:14,668 我们的很多进程可以帮助大家很快的调研跟它报告 854 00:29:14,668 --> 00:29:15,748 我现在给大家展示一下 855 00:29:15,748 --> 00:29:17,708 比如说老板要求我完成这个 856 00:29:17,708 --> 00:29:19,088 传统的做法就是三个牌子 857 00:29:19,088 --> 00:29:20,168 挨一个的时候整理一个晚上 858 00:29:20,168 --> 00:29:22,068 然后每个A进程之间还不太交互的通 859 00:29:22,068 --> 00:29:24,148 我们在我们的Octop里面 860 00:29:24,148 --> 00:29:26,188 首先我们有非常多的类似的一个专家 861 00:29:26,188 --> 00:29:27,428 也有一些专家市场 862 00:29:27,428 --> 00:29:29,148 我们是对接的Token Hub的专家市场 863 00:29:29,148 --> 00:29:31,308 有电商的金融的内容的 864 00:29:31,308 --> 00:29:32,348 如果大家有喜欢的 865 00:29:32,348 --> 00:29:33,548 就从这点击一下 866 00:29:33,548 --> 00:29:34,388 来从市场创建 867 00:29:34,388 --> 00:29:36,708 这就可以创建我们的网闻小说创作家 868 00:29:36,708 --> 00:29:39,508 那这个配置专家的过程还是很方便的 869 00:29:39,508 --> 00:29:40,268 对对对的 870 00:29:40,268 --> 00:29:41,428 如果大家默认 871 00:29:41,428 --> 00:29:44,188 为了防止大家经常从专家市场下比较慢 872 00:29:44,188 --> 00:29:45,148 所以我们还有类似专家 873 00:29:45,148 --> 00:29:47,308 业的专家下载后会类似到这里面 874 00:29:47,308 --> 00:29:49,228 比如说我之前装了竞品分析专家 875 00:29:49,228 --> 00:29:52,068 那我们今天就用剂米分加来实战演练一下 876 00:29:52,068 --> 00:29:53,128 那么就讲解题 877 00:29:53,128 --> 00:29:57,828 我看有粉丝朋友问Octop记忆模块代码是独立解藕的 878 00:29:57,828 --> 00:30:00,428 还是与其他意见组件存在编译期以外 879 00:30:00,428 --> 00:30:02,228 是完全独立解藕的 880 00:30:02,228 --> 00:30:04,728 刚刚其实这个记忆模块也可以跟 881 00:30:04,728 --> 00:30:07,328 现在是支持跟Otom Cloud 跟Hermas都一起用 882 00:30:07,328 --> 00:30:09,928 我们后续会推出完整的教程 883 00:30:09,928 --> 00:30:10,328 对 884 00:30:10,328 --> 00:30:12,728 那我们去玩一个很好玩的一个东西 885 00:30:12,728 --> 00:30:13,928 英宁 你吃豆河佬吗 886 00:30:13,928 --> 00:30:15,028 我吃 887 00:30:15,028 --> 00:30:18,928 那那个像佼佼们到底豆河佬喜欢吃甜的 888 00:30:18,928 --> 00:30:19,728 还是喜欢吃咸的 889 00:30:19,728 --> 00:30:21,128 或者是川芸人喜欢吃辣的 890 00:30:21,128 --> 00:30:23,988 我肯定是坚定的吃咸的 891 00:30:23,988 --> 00:30:25,088 豆腐脑的这一派 892 00:30:25,088 --> 00:30:26,008 我肯定占咸 893 00:30:26,008 --> 00:30:27,188 大家有吃甜的吗 894 00:30:27,188 --> 00:30:28,708 大家豆腐脑有吃甜的吗 895 00:30:28,708 --> 00:30:31,008 我其实是吃甜的 896 00:30:31,008 --> 00:30:31,588 不好意思 897 00:30:31,588 --> 00:30:33,408 我们三个人吃三种口味 898 00:30:33,408 --> 00:30:35,348 我们三个人刚好吃三种口味 899 00:30:35,348 --> 00:30:36,188 对 900 00:30:36,188 --> 00:30:39,048 那我们来让我们的美食专家来评判一下 901 00:30:39,048 --> 00:30:41,028 我们这有一个营养规划专家 902 00:30:41,028 --> 00:30:42,328 豆腐脑也是要有营养的 903 00:30:42,328 --> 00:30:43,008 我们来问问他 904 00:30:43,008 --> 00:30:44,228 是的 905 00:30:44,228 --> 00:30:45,788 我们现在是在等 906 00:30:45,788 --> 00:30:48,188 竞品分析专家在给我们做调研 907 00:30:48,188 --> 00:30:50,268 在等待他做调研的过程中 908 00:30:50,268 --> 00:30:52,568 我们来做一个多agent的博弈 909 00:30:52,568 --> 00:30:53,728 这样子的一个演示 910 00:30:53,728 --> 00:30:56,228 给大家更加实战地去看一下 911 00:30:56,228 --> 00:30:57,748 Oxop他的多agent之间 912 00:30:57,748 --> 00:30:58,748 如何去思考 913 00:30:58,748 --> 00:30:59,508 如何去博弈 914 00:30:59,508 --> 00:31:02,088 那么我们也是以这个豆腐脑为例 915 00:31:02,088 --> 00:31:03,448 我们来看一下这个agent 916 00:31:03,448 --> 00:31:04,568 如何做裁决 917 00:31:04,568 --> 00:31:05,328 已经结束了 918 00:31:05,328 --> 00:31:05,808 我们可以看到 919 00:31:05,808 --> 00:31:07,608 刚才他其实是调用了三个工具的 920 00:31:07,608 --> 00:31:09,868 确实是分发了给不同的agent 921 00:31:09,868 --> 00:31:11,468 然后下发了他的任务 922 00:31:11,468 --> 00:31:12,608 你是一个辣打的专家 923 00:31:12,608 --> 00:31:13,248 或者你穿越人 924 00:31:13,248 --> 00:31:14,908 好 完整交换就来了 925 00:31:14,908 --> 00:31:15,468 第一轮呢 926 00:31:15,468 --> 00:31:16,808 我们的甜党先说了 927 00:31:16,808 --> 00:31:17,388 就是甜味 928 00:31:17,388 --> 00:31:19,068 像英宁肯定是非常喜欢吃甜的 929 00:31:19,068 --> 00:31:21,028 它可能存在比较幸福的记忆 930 00:31:21,028 --> 00:31:21,628 我就比较清楚 931 00:31:21,628 --> 00:31:23,528 咸党可能说的是没有咸味 932 00:31:23,528 --> 00:31:25,388 像一个焦焦比较喜欢吃咸的 933 00:31:25,388 --> 00:31:26,628 比较沉稳的 934 00:31:26,628 --> 00:31:28,408 像我当然就喜欢吃辣 935 00:31:28,408 --> 00:31:30,968 小川水人必须吃火锅都必须吃辣 936 00:31:30,968 --> 00:31:32,928 他们就开始第二轮的相互攻击了 937 00:31:32,928 --> 00:31:35,048 那么甜党就开始调侃了一个咸党 938 00:31:35,048 --> 00:31:35,788 说它单调 939 00:31:35,788 --> 00:31:37,288 辣的确实伤胃味 940 00:31:37,288 --> 00:31:38,668 现在是比较优雅的 941 00:31:38,668 --> 00:31:39,968 攻势还比较强硬 942 00:31:39,968 --> 00:31:42,048 那么咸党又直接了一个甜党的比较幼稚 943 00:31:42,048 --> 00:31:43,228 它有一个非常频繁的一个金句 944 00:31:43,228 --> 00:31:45,228 就叫做辣味上头舌头直接化工 945 00:31:45,228 --> 00:31:46,428 这和做机会有小区别 946 00:31:46,428 --> 00:31:48,828 说明参与人其实不太想救美食的 947 00:31:48,828 --> 00:31:50,828 这种口感可能还是比较喜欢辣味 948 00:31:50,828 --> 00:31:51,828 就盖过了全味 949 00:31:51,828 --> 00:31:54,428 辣就开始反进来嘲讽我们的田党说 950 00:31:54,428 --> 00:31:55,828 田党农院活化在童话世界 951 00:31:55,828 --> 00:31:56,828 因为田田的甜妹 952 00:31:56,828 --> 00:31:57,828 田党农院是配角 953 00:31:57,828 --> 00:31:59,628 也是比较精彩的一个博弈 954 00:31:59,628 --> 00:32:01,228 我们看主义镜党的台办 955 00:32:01,228 --> 00:32:02,428 他可能读取了我的记忆 956 00:32:02,428 --> 00:32:03,828 他觉得可能是辣的显身 957 00:32:03,828 --> 00:32:06,028 首先是辣味他可能带来了记忆点 958 00:32:06,028 --> 00:32:07,628 甜和咸都太日常了 959 00:32:07,628 --> 00:32:08,828 但是说句公道话 960 00:32:08,828 --> 00:32:11,028 我觉得其实豆腐老师甜的也挺好吃的 961 00:32:11,028 --> 00:32:11,708 包括吃咸的 962 00:32:11,708 --> 00:32:13,148 开始端水 963 00:32:13,148 --> 00:32:16,328 那我们Octop那是没有杨之会端水是吧 964 00:32:16,328 --> 00:32:18,508 他还真的评出辣当品生 965 00:32:18,508 --> 00:32:20,028 我看专幕也说了 966 00:32:20,028 --> 00:32:21,028 要吃就要吃两碗 967 00:32:21,028 --> 00:32:22,348 要先吃甜的再吃咸的 968 00:32:22,348 --> 00:32:23,108 说明我们的用户 969 00:32:23,108 --> 00:32:25,028 不一定非得吃某一个口味的 970 00:32:25,028 --> 00:32:28,228 其实我们也可以再看一下我们这个博弈的过程 971 00:32:28,228 --> 00:32:30,588 杨之也可以帮我们再讲解 972 00:32:30,588 --> 00:32:34,228 那这个过程其实我们是主动调用了几个agent 973 00:32:34,228 --> 00:32:35,688 是如何进行博弈 974 00:32:35,688 --> 00:32:38,088 哪一个agent来进行裁决的呢 975 00:32:38,088 --> 00:32:39,728 那在这里我们有一个主Agent 976 00:32:39,728 --> 00:32:41,208 因为子Agent和主Agent 977 00:32:41,208 --> 00:32:42,368 大概有这么一个概念 978 00:32:42,648 --> 00:32:44,368 子Agent它是一个现存的概念 979 00:32:44,528 --> 00:32:45,968 它用完之后它就消失了 980 00:32:45,968 --> 00:32:47,808 它会和其他的Agent去对话 981 00:32:48,128 --> 00:32:49,888 所以它必须要把他收到的任务的答案 982 00:32:49,888 --> 00:32:51,288 交还给主Agent 983 00:32:51,688 --> 00:32:53,848 所以到这我们是一个主从事的结构 984 00:32:53,848 --> 00:32:54,868 所以必须要让主Agent 985 00:33:09,868 --> 00:33:11,868 他们分别完成后互相看不见 986 00:33:11,868 --> 00:33:14,668 在后面的户对环节开始通过主要进展图 987 00:33:14,668 --> 00:33:17,468 传递给大家每个党派的一个反驳的意见 988 00:33:17,468 --> 00:33:19,148 最后主要进行裁判 989 00:33:19,148 --> 00:33:20,388 该觉得哪个比较好 990 00:33:20,388 --> 00:33:24,908 那这里是不是其实平时我们在做调研任务 991 00:33:24,908 --> 00:33:28,788 或者我们比如有个家长想帮小朋友 992 00:33:28,788 --> 00:33:32,668 看看怎么去收集一些作文素材 993 00:33:32,668 --> 00:33:36,268 是不是其实也可以是给我们Octop分发一个任务 994 00:33:36,268 --> 00:33:40,228 让一个子agent去收集关于历史的素材 995 00:33:40,228 --> 00:33:43,108 另一个子agent去收集关于感动故事 996 00:33:43,108 --> 00:33:45,948 另一个子agent去收集关局名言名言 997 00:33:45,948 --> 00:33:47,108 是不是也是一样的道理 998 00:33:47,108 --> 00:33:47,988 我觉得这个场景非常好 999 00:33:47,988 --> 00:33:50,348 因为像我们可能观看的观众里面 1000 00:33:50,348 --> 00:33:52,588 有一些家长朋友们也比较关心这个问题 1001 00:33:52,588 --> 00:33:54,388 那么我要来回答一下大家的这个问题 1002 00:33:54,388 --> 00:33:55,988 像比如说在Talk里面 1003 00:33:55,988 --> 00:33:58,028 比如说我们的有很多的子agent 1004 00:33:58,028 --> 00:33:59,628 在我们的有一些学术的子agent 1005 00:33:59,628 --> 00:34:00,988 比如说像英琳刚刚说的 1006 00:34:00,988 --> 00:34:01,868 我们有地理专家 1007 00:34:01,868 --> 00:34:03,708 父母觉得如果地理孩子定义成绩不好 1008 00:34:03,708 --> 00:34:05,708 那么可以叫他做一份地理的PDF报告 1009 00:34:05,708 --> 00:34:08,808 交付款给答应出来给我们的一个小朋友 1010 00:34:08,808 --> 00:34:09,768 就跟他们去阅读 1011 00:34:09,768 --> 00:34:11,548 我们等于TOP之前是非常支持的 1012 00:34:11,548 --> 00:34:14,628 包括我看我们刚刚的调研报告也是很顺利的出来了 1013 00:34:14,628 --> 00:34:17,848 你看包括我们在这里是很交付了一个PDF文件 1014 00:34:17,848 --> 00:34:19,928 MD文件到时候可以转化为PDF 1015 00:34:19,928 --> 00:34:24,448 像用户朋友们就可以在这里去下载到本地之后就可以使用 1016 00:34:24,448 --> 00:34:27,228 我相信家长朋友们可能还是比较喜欢给孩子分发中研 1017 00:34:27,228 --> 00:34:28,268 也应该比较喜欢这个功能 1018 00:34:28,268 --> 00:34:29,368 那话不多说了 1019 00:34:29,368 --> 00:34:31,728 我们就看看这个调研报告它竟然都做出来了 1020 00:34:31,728 --> 00:34:34,428 那我们先看报告之前 1021 00:34:34,428 --> 00:34:38,508 其实我想问那杨主持人你最喜欢的奶茶是什么牌子 1022 00:34:38,508 --> 00:34:40,268 我其实比较喜欢爆炎茶几 1023 00:34:40,268 --> 00:34:40,988 那焦焦 1024 00:34:40,988 --> 00:34:43,828 我其实想喜欢喜茶多一点 1025 00:34:43,828 --> 00:34:46,568 好吧那没有人是点门 1026 00:34:46,568 --> 00:34:48,648 我就是一点点大头 1027 00:34:48,648 --> 00:34:49,888 虽然一点点不在这 1028 00:34:49,888 --> 00:34:50,968 一点点很老 1029 00:34:50,968 --> 00:34:52,688 但我就是坚定的点门人 1030 00:34:52,688 --> 00:34:57,568 好那我们继续看这个新品牌茶饮三巨头的调研报告吧 1031 00:34:57,568 --> 00:34:58,528 然后我放大一下 1032 00:34:58,528 --> 00:35:00,888 供大家可以很好的查看 1033 00:35:00,888 --> 00:35:02,708 好应该是大概调研报告 1034 00:35:02,708 --> 00:35:03,828 因为我们这有一些折地功能 1035 00:35:03,828 --> 00:35:06,188 大家如果想这样看就非常方便 1036 00:35:06,188 --> 00:35:07,068 也可以这样看 1037 00:35:07,068 --> 00:35:08,108 也支持斜着看 1038 00:35:08,108 --> 00:35:09,388 我们都非常支持的 1039 00:35:09,628 --> 00:35:11,468 比如说像现在右半边 1040 00:35:11,468 --> 00:35:12,388 右半边看了 1041 00:35:12,388 --> 00:35:13,388 或者是下面看 1042 00:35:13,388 --> 00:35:14,028 我们都非常支持 1043 00:35:14,028 --> 00:35:15,308 那么显然就为了放中间 1044 00:35:15,308 --> 00:35:16,388 让大家看得比较清楚 1045 00:35:16,388 --> 00:35:18,228 这是不是就是三折叠 1046 00:35:18,228 --> 00:35:19,828 怎么这么多有边 1047 00:35:19,828 --> 00:35:20,588 对的对的 1048 00:35:20,588 --> 00:35:21,148 放大一点 1049 00:35:21,148 --> 00:35:22,828 让大家都比较都很好的看清楚 1050 00:35:22,828 --> 00:35:24,228 像我们的一个G2报告 1051 00:35:24,228 --> 00:35:26,108 已经茶饮你的老板给你派火了 1052 00:35:26,108 --> 00:35:26,988 你就很快的出来 1053 00:35:26,988 --> 00:35:28,548 首先它生成了行业的总染 1054 00:35:28,548 --> 00:35:30,068 比如说茶饮现在可能进入一个 1055 00:35:30,068 --> 00:35:30,708 纯粮博弈 1056 00:35:30,708 --> 00:35:32,028 可能现在进入比较激烈了 1057 00:35:32,028 --> 00:35:32,828 那它也调研了 1058 00:35:32,828 --> 00:35:33,688 像密血冰城 1059 00:35:33,688 --> 00:35:34,808 它也不止调研这三个 1060 00:35:34,808 --> 00:35:35,988 像密血冰城比较便宜的 1061 00:35:35,988 --> 00:35:36,768 也有人喜欢的 1062 00:35:36,768 --> 00:35:37,328 薄牙绝权 1063 00:35:37,328 --> 00:35:38,568 帮忙查记忆的一个产品 1064 00:35:38,568 --> 00:35:40,868 如果稍微贵点的 1065 00:35:40,868 --> 00:35:42,908 可能大家可以去喝喜茶和赖雪 1066 00:35:42,908 --> 00:35:43,748 但是对我来说 1067 00:35:43,748 --> 00:35:45,108 可能帮忙查记忆到价格适中的 1068 00:35:45,108 --> 00:35:46,328 包括它也非常 1069 00:35:46,328 --> 00:35:46,948 你可以看到Octob 1070 00:35:46,948 --> 00:35:49,188 它是比较了三个的一个创立时间 1071 00:35:49,188 --> 00:35:50,728 包括它一个高端定位 1072 00:35:50,728 --> 00:35:51,788 喜茶的是高端定位 1073 00:35:51,788 --> 00:35:53,628 赖雪的茶号称星巴克 1074 00:35:53,628 --> 00:35:56,068 我想问一下杨直 1075 00:35:56,068 --> 00:35:57,888 我们的Octob在搜索到 1076 00:35:57,888 --> 00:35:58,868 这些信息的时候 1077 00:35:58,868 --> 00:36:01,948 是它主动去有搜索到 1078 00:36:01,948 --> 00:36:03,388 准确的一些信息源吗 1079 00:36:03,388 --> 00:36:04,908 就这些最新的数据 1080 00:36:04,908 --> 00:36:05,548 当然的 1081 00:36:05,548 --> 00:36:07,028 那Octop它的整个呢 1082 00:36:07,028 --> 00:36:09,288 它是抓取的是我们最新的一个数据 1083 00:36:09,288 --> 00:36:10,428 如果这个数据没有了 1084 00:36:10,428 --> 00:36:12,828 它会去查另外的也很多的一个数据 1085 00:36:12,828 --> 00:36:15,748 包括一些非常非常实时的一些网站 1086 00:36:15,748 --> 00:36:16,828 都可以很好的查询到 1087 00:36:16,828 --> 00:36:18,908 那评论区的大家可以放心 1088 00:36:18,908 --> 00:36:21,428 我们Octop做出来的调研分析呢 1089 00:36:21,428 --> 00:36:22,968 数据是绝对准确的 1090 00:36:22,968 --> 00:36:24,548 大家可以放心使用 1091 00:36:24,548 --> 00:36:26,208 对包括我们Octop 1092 00:36:26,208 --> 00:36:28,528 其实也有一个自建的搜索引擎 1093 00:36:28,528 --> 00:36:30,548 所以大家可能在用 1094 00:36:30,548 --> 00:36:32,148 OpenCloud和Hermes的时候 1095 00:36:32,148 --> 00:36:33,588 其实有偶尔感受到 1096 00:36:33,588 --> 00:36:36,508 如果不自己去配那种付费搜索引擎 1097 00:36:36,508 --> 00:36:38,668 或者配那种专门的search key 1098 00:36:38,668 --> 00:36:41,148 它的搜索功能或许有些许缺陷 1099 00:36:41,148 --> 00:36:44,468 但是我们Octop其实内置了一个专业的搜索引擎 1100 00:36:44,468 --> 00:36:47,108 所以大家可以放心用我们Octop做调研 1101 00:36:47,108 --> 00:36:48,428 还有我想给大家说的 1102 00:36:48,428 --> 00:36:49,788 可能有些用户没有拒绝的 1103 00:36:49,788 --> 00:36:51,628 AI只能把你生成 1104 00:36:51,628 --> 00:36:52,228 你不能改 1105 00:36:52,228 --> 00:36:54,988 我和Top现在我们是可以直接在里面修改 1106 00:36:54,988 --> 00:36:57,388 他给你说了交付的是管理层 1107 00:36:57,388 --> 00:36:58,828 你显然老板不希望看到这个 1108 00:36:58,828 --> 00:36:59,788 因为你不能呼噜 1109 00:36:59,788 --> 00:37:00,748 然后你可以把它删掉 1110 00:37:00,748 --> 00:37:01,528 然后保存下来 1111 00:37:01,528 --> 00:37:02,808 你就可以把这个发给你老板 1112 00:37:02,808 --> 00:37:03,968 也是为了我们也很多 1113 00:37:03,968 --> 00:37:05,248 提供了像类似于 1114 00:37:05,248 --> 00:37:06,208 WorkerBody的一个能力了 1115 00:37:06,208 --> 00:37:06,768 然后我们以为来 1116 00:37:06,768 --> 00:37:08,388 还会逐步的去完善优化 1117 00:37:08,388 --> 00:37:10,668 这个编辑能力还挺好用的 1118 00:37:10,668 --> 00:37:11,148 这样的话 1119 00:37:11,148 --> 00:37:14,928 就可以实时的和AI进行交互和修改 1120 00:37:14,928 --> 00:37:15,248 是的 1121 00:37:15,248 --> 00:37:17,808 那我们要不继续给大家展示一下 1122 00:37:17,808 --> 00:37:19,488 我们Octob做出来的调研报告 1123 00:37:19,488 --> 00:37:21,108 剩下还包含哪一些部分 1124 00:37:21,108 --> 00:37:22,268 刚刚我们有看到 1125 00:37:22,268 --> 00:37:24,608 它其实有很全面的这个行业总览 1126 00:37:24,608 --> 00:37:27,188 以及三巨头的核心的对比维度 1127 00:37:27,188 --> 00:37:28,348 我们可以 1128 00:37:28,348 --> 00:37:29,628 你老板如果没有关心 1129 00:37:29,628 --> 00:37:31,828 还有价格一些策略深度对比 1130 00:37:31,828 --> 00:37:33,508 包括我们的一个产品矩正 1131 00:37:33,508 --> 00:37:35,448 像喜茶它主打的可能是一个水果茶 1132 00:37:35,448 --> 00:37:36,808 水果茶比较好喝 1133 00:37:36,808 --> 00:37:38,408 我上班学的茶可能就是一个 1134 00:37:38,408 --> 00:37:40,728 现烤烘焙的一个鲜果茶 1135 00:37:40,728 --> 00:37:41,388 纯茶 1136 00:37:41,388 --> 00:37:43,128 像花王茶间可能就是一个鲜奶茶的 1137 00:37:43,128 --> 00:37:44,908 因为完全挺好喝的 1138 00:37:44,908 --> 00:37:47,028 看来Octop真的调研的很全面 1139 00:37:47,028 --> 00:37:49,228 还有营销策略的深度对比 1140 00:37:49,228 --> 00:37:51,728 对甚至杨植宁给他的prompt 1141 00:37:51,728 --> 00:37:52,588 比较直接紧的去做 1142 00:37:52,588 --> 00:37:53,648 因为我们为什么要这么做 1143 00:37:53,648 --> 00:37:54,848 一方面是加快我们的数 1144 00:37:54,848 --> 00:37:56,368 另外一方面如果调研喜茶的时候 1145 00:37:56,368 --> 00:37:57,268 像英年 1146 00:37:57,268 --> 00:37:59,268 如果我们还去调研一下耐学的查 1147 00:37:59,268 --> 00:38:01,368 说实话它的回复质量可能是比较低的 1148 00:38:01,368 --> 00:38:03,268 所以说我们为什么要引入多一个来 1149 00:38:03,268 --> 00:38:05,268 更好地形成一个调研报纳 1150 00:38:05,268 --> 00:38:07,268 所以分别一个agent调研写查 1151 00:38:07,268 --> 00:38:08,768 一个agent调研报纳查机 1152 00:38:08,768 --> 00:38:10,668 还有一个agent在调研 1153 00:38:10,668 --> 00:38:13,268 耐学的最后再医 1154 00:38:13,268 --> 00:38:15,268 对你把整个的一个调研追过来 1155 00:38:15,268 --> 00:38:18,268 agent做完调研之后是由主agent来做 1156 00:38:18,268 --> 00:38:21,268 最后的一个整合和报告的撰写吗 1157 00:38:21,268 --> 00:38:23,268 对的交交问的很对 1158 00:38:23,268 --> 00:38:25,268 我们简单回复一下 1159 00:38:25,268 --> 00:38:28,268 我们现在应该来说要支持有两种概念 1160 00:38:28,268 --> 00:38:29,268 一种是我们的贼警的 1161 00:38:29,268 --> 00:38:31,268 它是一个如果是变成朋友们比较熟悉 1162 00:38:31,268 --> 00:38:32,868 它是一个现成的概念 1163 00:38:32,868 --> 00:38:34,268 它用了一次之后就会消失 1164 00:38:34,268 --> 00:38:36,268 所以它一定要成为主意警的它的一个答案 1165 00:38:36,268 --> 00:38:39,268 未来朋友们比较放心的我们是回复答案能不能长久保存 1166 00:38:39,268 --> 00:38:41,268 它有一个思路我们未来会推出agent的team 1167 00:38:41,268 --> 00:38:43,268 又和我们的每个专家我们的Octop 1168 00:38:43,268 --> 00:38:46,268 像刚刚也有些影视专家等等那些专家 1169 00:38:46,268 --> 00:38:47,268 它里面的一个东西都会存在里面 1170 00:38:47,268 --> 00:38:49,268 所以那个是一个进程的概念 1171 00:38:49,268 --> 00:38:50,268 未来大家可以多多关注我们的Octop 1172 00:38:50,268 --> 00:38:52,268 我们未来会及时的推出agent的team 1173 00:38:52,268 --> 00:38:53,408 帮助大家更好的 1174 00:38:53,408 --> 00:38:54,248 适应这种 1175 00:38:54,248 --> 00:38:55,908 不论是那种工作 1176 00:38:55,908 --> 00:38:57,168 还是我们刚刚一年说的 1177 00:38:57,168 --> 00:38:58,468 这种宝爸宝妈们 1178 00:38:58,468 --> 00:38:59,308 要给孩子做作业 1179 00:38:59,308 --> 00:39:00,608 当然我们的agent team 1180 00:39:00,608 --> 00:39:01,508 都会保存一些记忆 1181 00:39:01,508 --> 00:39:02,868 欢迎大家继续关注 1182 00:39:02,868 --> 00:39:04,448 那我们这个 1183 00:39:04,448 --> 00:39:05,988 让他做竞品调研 1184 00:39:05,988 --> 00:39:06,888 我们就只需要 1185 00:39:06,888 --> 00:39:09,828 给他布置一个复杂的任务 1186 00:39:09,828 --> 00:39:12,168 他自己就会去衡量和思考 1187 00:39:12,168 --> 00:39:14,388 应该把什么任务分配给谁 1188 00:39:14,388 --> 00:39:16,168 需要去有多少个agent 1189 00:39:16,168 --> 00:39:17,608 支持这个任务吗 1190 00:39:17,608 --> 00:39:20,028 好 我们可以简单 1191 00:39:20,028 --> 00:39:21,488 回顾一下我们的用户 1192 00:39:21,488 --> 00:39:25,328 是不是有个竞品调研专家他是有这些能力的 1193 00:39:25,328 --> 00:39:27,328 对的我们是有一个竞品调研专家 1194 00:39:27,328 --> 00:39:29,828 像我们的专家里面他都会有这个能力 1195 00:39:29,828 --> 00:39:32,628 像我们的有很多专家是像我们的Z-Gent里面 1196 00:39:32,628 --> 00:39:34,828 因为我们的我们的决策也是说了 1197 00:39:34,828 --> 00:39:37,448 我们未来是可以不需要用户在这里面去安装 1198 00:39:37,448 --> 00:39:39,828 也许他可以自动路由到一个你所需要的A-Gent 1199 00:39:39,828 --> 00:39:42,028 因为我们也和那些客户在哪 1200 00:39:42,028 --> 00:39:44,828 可能用的时候就说你只需要需要 1201 00:39:44,828 --> 00:39:45,948 他自动可以帮你创造的未来 1202 00:39:45,948 --> 00:39:47,848 我们就会不仅你是从这去下载 1203 00:39:47,848 --> 00:39:49,828 还是你在用户窗口就可以直接和他对话 1204 00:39:49,828 --> 00:39:50,908 未来都会支持这种能力 1205 00:39:50,908 --> 00:39:52,788 我们目前已经内置了 1206 00:39:52,788 --> 00:39:54,388 精品分析的这个专家 1207 00:39:54,388 --> 00:39:57,088 因此我们用户只需要调用这个专家 1208 00:39:57,088 --> 00:39:59,408 然后去给他输入非常简单的 1209 00:39:59,408 --> 00:40:00,448 调研的指令 1210 00:40:00,448 --> 00:40:02,028 然后他就会自动去帮我们 1211 00:40:02,028 --> 00:40:03,368 去分配贼agent 1212 00:40:03,368 --> 00:40:04,808 还有怎么分配任务 1213 00:40:04,808 --> 00:40:06,668 就会自动帮我们一键输出报告了 1214 00:40:06,668 --> 00:40:07,588 是的 1215 00:40:07,588 --> 00:40:10,008 并且未来还就算不让大家去安装 1216 00:40:10,008 --> 00:40:11,168 因为大家还要找 1217 00:40:11,168 --> 00:40:12,248 让我们未来我们的 1218 00:40:12,248 --> 00:40:13,088 只要是一个agent 1219 00:40:13,088 --> 00:40:14,788 他自己可以去激活了一些贼agent的 1220 00:40:14,788 --> 00:40:15,808 也可以激活了一些专家 1221 00:40:15,808 --> 00:40:16,888 我看到我们粉丝朋友 1222 00:40:16,888 --> 00:40:18,888 如果生成结构化文档 1223 00:40:18,888 --> 00:40:22,928 前一张的输出是后一张的输入适合多Agent吗 1224 00:40:23,279 --> 00:40:37,279 那其實這裡有非常多一種情況。其實是如果端木你是想,比如你想生成一篇文档,那比如先生成了第一段,再生成了第二段,第一段是第二段的輸入。 1225 00:40:37,279 --> 00:40:38,039 输入 1226 00:40:38,299 --> 00:40:41,639 那其实第二段的生成必须要第一段已经生成了 1227 00:40:41,639 --> 00:40:45,219 其实多agents是适合这种并行的任务的 1228 00:40:45,479 --> 00:40:49,559 那个像我们的多agent他现在的一个agent的输入大概是一个文本 1229 00:40:49,559 --> 00:40:51,879 但是他可以生成像一个pdf文件 1230 00:40:51,879 --> 00:40:53,919 或者像端木说的一个结构化的文档 1231 00:40:53,919 --> 00:40:56,739 那么他端木的问题应该是在生成这个节目化文档之后 1232 00:40:56,739 --> 00:40:59,559 这一个输入是否可以被后一个比如说agent 1233 00:40:59,799 --> 00:41:00,579 然后给接收 1234 00:41:00,579 --> 00:41:02,119 那么我们现在的回复就是 1235 00:41:02,119 --> 00:41:04,159 如果是紫agent之间它是一个现成的关系 1236 00:41:04,159 --> 00:41:06,079 它是不能够吸收这种结构化文本 1237 00:41:06,079 --> 00:41:08,079 它只能接受文本的一个输入 1238 00:41:08,079 --> 00:41:09,079 但是我们的主A进程 1239 00:41:09,079 --> 00:41:10,759 可以把它的一个子A进程 1240 00:41:10,759 --> 00:41:11,519 做出来的PDF 1241 00:41:11,519 --> 00:41:12,919 Markdown文件要保存下来 1242 00:41:12,919 --> 00:41:14,919 让主A进程读后交给子A进程 1243 00:41:14,919 --> 00:41:16,559 这是我们的Octop的一个特色了 1244 00:41:16,559 --> 00:41:18,999 我们也是支持这种多结构化文本 1245 00:41:18,999 --> 00:41:19,719 从一个输入后 1246 00:41:19,719 --> 00:41:21,239 下一个输出也肯定是支持的 1247 00:41:21,239 --> 00:41:23,559 还有一位粉丝朋友问 1248 00:41:23,559 --> 00:41:26,359 这一老用户迁移到Octop后 1249 00:41:26,359 --> 00:41:30,639 原有记忆是否需要重新做GIMA转换 1250 00:41:30,639 --> 00:41:31,439 是这样的 1251 00:41:31,439 --> 00:41:33,439 在原有来靠ACE的记忆 1252 00:41:33,439 --> 00:41:34,639 其实大家知道 1253 00:41:34,639 --> 00:41:38,099 就是只有memory文件夹下的所有md文档 1254 00:41:38,099 --> 00:41:40,639 以及memory.md是记忆的所有真相语言 1255 00:41:40,639 --> 00:41:43,639 你做迁移可以一起迁移过来 1256 00:41:43,639 --> 00:41:44,879 我们现在记忆一遍 1257 00:41:44,879 --> 00:41:47,259 那memory.md是可以全量读得到的 1258 00:41:47,259 --> 00:41:50,359 那关于其他的一些结构化文档 1259 00:41:50,359 --> 00:41:54,399 我们也会推出一个支持的记忆格式转换 1260 00:41:54,399 --> 00:41:55,599 我看粉丝朋友问 1261 00:41:55,599 --> 00:41:57,639 好像不能多用户多智能力 1262 00:41:57,639 --> 00:41:58,759 以共同协作 1263 00:41:58,759 --> 00:41:59,119 对的 1264 00:41:59,119 --> 00:42:01,139 因为我们现在的一个思路是 1265 00:42:01,139 --> 00:42:02,939 每个用户和每个用户之间是隔离的 1266 00:42:02,939 --> 00:42:06,099 所以用户和用户之间是不能够进行一个协作的 1267 00:42:06,099 --> 00:42:07,059 但是如果你有需求 1268 00:42:07,059 --> 00:42:09,379 我觉得是不是未来一向英雄我们是不是可以 1269 00:42:09,379 --> 00:42:12,059 对看这位粉丝朋友的具体需求 1270 00:42:12,059 --> 00:42:16,299 我理解单用户你的多智能体是可以共同协作的 1271 00:42:16,299 --> 00:42:17,599 我们继续讲解 1272 00:42:17,599 --> 00:42:22,299 看大家对刚刚的竞品分析的演示有没有什么问题 1273 00:42:22,299 --> 00:42:26,659 我刚刚看到我们的October也是用一条简单的指令 1274 00:42:26,659 --> 00:42:30,379 立刻产出了一份比较完善角度 1275 00:42:30,379 --> 00:42:32,699 也比较齐全的竞品分析调研报告了 1276 00:42:32,699 --> 00:42:33,339 对 1277 00:42:33,339 --> 00:42:34,299 是的 1278 00:42:34,299 --> 00:42:36,459 看一下大家有什么问题没有 1279 00:42:36,459 --> 00:42:37,679 大家提问 1280 00:42:37,679 --> 00:42:40,559 那大家有没有什么想了解的场景 1281 00:42:40,559 --> 00:42:43,139 也可以现在在评论区打出来 1282 00:42:43,139 --> 00:42:46,779 或者是加入用户群里和我们一起探讨一下 1283 00:42:46,779 --> 00:42:47,739 收费不以后 1284 00:42:47,739 --> 00:42:48,899 我看有用户提问了 1285 00:42:48,899 --> 00:42:49,759 我们不收费 1286 00:42:49,759 --> 00:42:51,119 我们代码现在都开源的 1287 00:42:51,119 --> 00:42:54,919 我们未来也会在轻量云服务器的控制台上上镜像 1288 00:42:54,919 --> 00:42:57,639 对我们没有收费 1289 00:42:57,639 --> 00:42:58,819 对买一台服务器 1290 00:42:58,819 --> 00:43:01,579 包括你现在自己也可以去安装 1291 00:43:01,579 --> 00:43:03,859 安装方式可以去GitHub 1292 00:43:03,859 --> 00:43:05,059 看我们的ReadMe 1293 00:43:05,059 --> 00:43:06,619 未来我们也会在 1294 00:43:06,619 --> 00:43:07,919 腾讯社区里 1295 00:43:07,919 --> 00:43:09,219 推出更方便的 1296 00:43:09,219 --> 00:43:10,859 安装方式教学 1297 00:43:10,859 --> 00:43:11,159 对 1298 00:43:11,159 --> 00:43:12,559 好像我们的Optop了吗 1299 00:43:12,559 --> 00:43:13,319 还算不算便宜的 1300 00:43:13,319 --> 00:43:14,059 我们会想欢迎大家 1301 00:43:14,059 --> 00:43:15,199 来我们的Lighthouse里面来买 1302 00:43:15,199 --> 00:43:16,799 因为你买了一个后 1303 00:43:16,799 --> 00:43:18,019 那你可以是全家 1304 00:43:18,019 --> 00:43:18,599 全家都用 1305 00:43:18,599 --> 00:43:18,959 是的 1306 00:43:18,959 --> 00:43:20,439 有一个问题 1307 00:43:20,439 --> 00:43:21,819 假如说未来我们在 1308 00:43:21,819 --> 00:43:23,639 服务器上上了镜像之后 1309 00:43:23,639 --> 00:43:25,819 我们的多用户功能 1310 00:43:25,819 --> 00:43:26,819 也就是相当于 1311 00:43:26,819 --> 00:43:28,079 只要管理员 1312 00:43:28,079 --> 00:43:29,079 买了一台服务器 1313 00:43:29,079 --> 00:43:30,539 有一台Optop之后 1314 00:43:30,539 --> 00:43:32,259 我所设置的多用户 1315 00:43:32,259 --> 00:43:33,799 他们就不用再买了对吗 1316 00:43:33,799 --> 00:43:34,559 对的 1317 00:43:34,559 --> 00:43:36,099 一台服气的Octob 1318 00:43:36,099 --> 00:43:38,179 就能够多用户使用 1319 00:43:38,179 --> 00:43:39,559 我看到粉丝朋友问 1320 00:43:39,559 --> 00:43:40,199 上了镜像 1321 00:43:40,199 --> 00:43:41,679 到时候可以把Hermes镜像 1322 00:43:41,679 --> 00:43:42,779 换成Octob吗 1323 00:43:42,779 --> 00:43:44,019 可以 1324 00:43:44,019 --> 00:43:45,099 其实换镜像 1325 00:43:45,099 --> 00:43:47,379 就是一个实力重装 1326 00:43:47,379 --> 00:43:49,179 是关于服气的操作 1327 00:43:49,179 --> 00:43:51,419 其实都可以随时做的 1328 00:43:51,419 --> 00:43:53,939 我看还有黄医生问 1329 00:43:53,939 --> 00:43:54,759 ACE转移 1330 00:43:54,759 --> 00:43:56,219 包括记忆聊天记录 1331 00:43:56,219 --> 00:43:58,559 Skill这些无损切换到Octob 1332 00:43:58,559 --> 00:43:59,999 E和Skill 1333 00:43:59,999 --> 00:44:01,519 包括你通道配置 1334 00:44:01,519 --> 00:44:03,219 那些配置现在都是无损切换 1335 00:44:03,219 --> 00:44:04,959 但是聊天介络 1336 00:44:04,959 --> 00:44:07,059 现在的迁移工具还不支持 1337 00:44:07,059 --> 00:44:09,259 对如果有强烈需求的话 1338 00:44:09,259 --> 00:44:11,819 可以在用户群里讨论 1339 00:44:11,819 --> 00:44:13,899 未来可能看看升级迁移工具 1340 00:44:13,899 --> 00:44:15,279 或以其他方式支持 1341 00:44:15,279 --> 00:44:17,019 什么时候上了清亮云 1342 00:44:17,019 --> 00:44:18,099 很快了 1343 00:44:18,099 --> 00:44:20,739 我们进上工作还差最后的适配 1344 00:44:20,739 --> 00:44:23,439 最迟其实近两周就能上 1345 00:44:23,439 --> 00:44:25,179 对欢迎到周公开 1346 00:44:25,179 --> 00:44:25,679 是的 1347 00:44:25,679 --> 00:44:28,239 那我们两位研发工程师 1348 00:44:28,239 --> 00:44:30,619 关于October未来的一个产品规划 1349 00:44:30,619 --> 00:44:33,159 以及一些会上的功能能力 1350 00:44:33,159 --> 00:44:34,759 也可以简单的给大家剧透一下 1351 00:44:34,759 --> 00:44:35,819 大家可以期待一下 1352 00:44:35,819 --> 00:44:39,439 同时大家如果有什么想要上的功能 1353 00:44:39,439 --> 00:44:40,599 或者说上线的功能 1354 00:44:40,599 --> 00:44:42,539 也可以在评论区里面交流一下 1355 00:44:42,539 --> 00:44:45,379 那么也有请两位简单介绍一下 1356 00:44:45,379 --> 00:44:49,679 那由我先来简单的说说我们的一个初步打算 1357 00:44:49,679 --> 00:44:51,659 我们下一段的目标主要是 1358 00:44:51,659 --> 00:44:52,979 正在服务于大家的一个 1359 00:44:52,979 --> 00:44:55,219 从我们ACE前一到我们的TOP里面 1360 00:44:55,219 --> 00:44:56,919 我们在支持这种工序的升级 1361 00:44:56,919 --> 00:44:59,979 这之外我们还在积极地调远Agent Team的一个使用方式 1362 00:44:59,979 --> 00:45:02,799 以及未来的Octobre在我们的一个QQ群鸟里面 1363 00:45:02,799 --> 00:45:05,639 它怎么样服务好我们的整个一个家庭用户场景 1364 00:45:05,639 --> 00:45:09,579 怎么去把一个Agent服务多个用户的这种能力给发挥出来 1365 00:45:09,579 --> 00:45:10,799 包括我们也来积极地探索 1366 00:45:10,799 --> 00:45:12,619 像使用这种杀香的机制 1367 00:45:12,619 --> 00:45:15,539 像每位用户也可以一个家庭有一个Agent 1368 00:45:15,539 --> 00:45:17,999 像我确实也听到过像用户提问 1369 00:45:17,999 --> 00:45:20,079 比如说他希望他看到的东西 1370 00:45:20,079 --> 00:45:23,039 他的孩子和他的老婆都能够使用 1371 00:45:23,039 --> 00:45:24,459 包括特别是在QQ里面 1372 00:45:24,459 --> 00:45:25,619 未来我们的也会支持 1373 00:45:25,619 --> 00:45:26,899 像我们的群鸟 1374 00:45:26,899 --> 00:45:27,459 Agent的切能 1375 00:45:27,459 --> 00:45:29,099 我们会做一个类似于杀箱的机制 1376 00:45:29,099 --> 00:45:30,539 来支持这种东西 1377 00:45:30,539 --> 00:45:31,339 因为据我所知 1378 00:45:31,339 --> 00:45:34,059 现在还是没有一个Agent能够做的很好 1379 00:45:34,059 --> 00:45:34,819 包括Hammus也好 1380 00:45:34,819 --> 00:45:35,619 跟Clau也好 1381 00:45:35,619 --> 00:45:36,299 未来的Octobre 1382 00:45:36,299 --> 00:45:37,099 会把这个作为一个 1383 00:45:37,099 --> 00:45:39,179 我们的相对的一个竞争优势去完善长 1384 00:45:39,179 --> 00:45:40,259 是的 期待 1385 00:45:40,259 --> 00:45:41,859 希望能够加上类似于 1386 00:45:41,859 --> 00:45:44,019 OakBody项目的模式 1387 00:45:44,019 --> 00:45:44,739 应酶 1388 00:45:44,739 --> 00:45:46,259 我觉得其实我们也可以尝试 1389 00:45:46,259 --> 00:45:47,539 去往这方面去做一做 1390 00:45:47,539 --> 00:45:49,819 可以回去探讨一下 1391 00:45:49,819 --> 00:45:51,059 对 也欢迎黄众 1392 00:45:51,059 --> 00:45:52,739 现在就在我们的GitHub里面 1393 00:45:52,739 --> 00:45:53,579 机器给我们提issue 1394 00:45:53,579 --> 00:45:54,339 我们看到你的issue 1395 00:45:54,339 --> 00:45:55,499 也会把它作为一个 1396 00:45:55,499 --> 00:45:57,219 我们可以未来的发展方向 1397 00:45:57,219 --> 00:45:59,339 也欢迎您来给我们做做共同 1398 00:45:59,339 --> 00:45:59,819 做pr 1399 00:45:59,819 --> 00:46:00,659 因为我们这是开云的 1400 00:46:00,659 --> 00:46:02,539 也可以服务一下您的一个用户场景 1401 00:46:02,779 --> 00:46:04,139 单个用户的记忆数据 1402 00:46:04,139 --> 00:46:04,779 达到百万级 1403 00:46:04,779 --> 00:46:06,419 Octop怎么保证解锁能力 1404 00:46:06,419 --> 00:46:08,659 对这个我可以回答一下 1405 00:46:08,659 --> 00:46:09,779 刚刚其实讲到了 1406 00:46:09,779 --> 00:46:11,739 Octop现在的记忆层级 1407 00:46:11,739 --> 00:46:14,339 那其实首先我们会去 1408 00:46:14,339 --> 00:46:16,299 检索所谓的原子卡片 1409 00:46:16,299 --> 00:46:19,259 那其实如果对话数量达到百万级 1410 00:46:19,259 --> 00:46:20,059 我们理解 1411 00:46:20,059 --> 00:46:21,699 其实近身的原子卡片数量 1412 00:46:21,699 --> 00:46:22,659 并没有这么多 1413 00:46:22,659 --> 00:46:25,459 对那一我们是先召回原子卡片 1414 00:46:25,459 --> 00:46:27,059 然后分层检索 1415 00:46:27,059 --> 00:46:29,279 我理解其实我们就是先召回原子卡片 1416 00:46:29,279 --> 00:46:33,299 然后再从候选者最后再召回到原始事件 1417 00:46:33,299 --> 00:46:36,119 其实这是一个分层的检索forback 1418 00:46:36,119 --> 00:46:40,719 后续我们也其实会推出记忆接上向量的模式 1419 00:46:40,719 --> 00:46:42,119 如果是ACE老用户的话 1420 00:46:42,119 --> 00:46:45,259 可以知道现在ACE其实默认有一个向量模型机制 1421 00:46:45,259 --> 00:46:48,859 但是在Octop因为我们要做组件拆分 1422 00:46:48,859 --> 00:46:51,759 我们其实默认是FTS加BM25 1423 00:46:51,759 --> 00:46:56,239 但后续如果有更重的记忆需求 1424 00:46:56,239 --> 00:47:00,119 我们其实也在计划推出Octop Memory 1425 00:47:00,119 --> 00:47:01,659 配置项料模型 1426 00:47:01,659 --> 00:47:03,399 以及自己的项料数据库 1427 00:47:03,399 --> 00:47:05,179 可以欢迎后续期待一下 1428 00:47:05,179 --> 00:47:07,399 微信渠道可以多往上下 1429 00:47:07,399 --> 00:47:09,319 尽量做到QQ渠道的程度 1430 00:47:09,319 --> 00:47:10,759 关于这个问题我来回复一下 1431 00:47:10,759 --> 00:47:12,039 因为是我在GDF的 1432 00:47:12,039 --> 00:47:14,179 像微信渠道我们在积极的和微信里面 1433 00:47:14,179 --> 00:47:14,979 进行一个沟通 1434 00:47:14,979 --> 00:47:17,679 因为目前是它里面包括一些多艺景特能 1435 00:47:17,679 --> 00:47:20,479 包括它一些主动推送的一些限度 1436 00:47:20,479 --> 00:47:22,579 导致它没有办法像QQ通道做的这么全 1437 00:47:22,579 --> 00:47:24,239 那么等待微信通道里边 1438 00:47:24,239 --> 00:47:25,279 我相信他们也会很快更新 1439 00:47:25,279 --> 00:47:28,639 然后我们也会适时的去更新连带我们的微信通道 1440 00:47:28,639 --> 00:47:30,119 以及帮靠达更好的支持活动 1441 00:47:30,119 --> 00:47:30,439 对 1442 00:47:30,439 --> 00:47:34,079 我看那种说希望能提供SSO集成方案 1443 00:47:34,079 --> 00:47:39,039 支持企业部署成内部知识记忆中枢 1444 00:47:39,039 --> 00:47:39,719 好的 1445 00:47:39,719 --> 00:47:42,879 下来我们去探讨一下争取 1446 00:47:42,879 --> 00:47:44,919 不管是参观我们代码也好 1447 00:47:44,919 --> 00:47:47,919 还是给我们STAR或者提提提提提提提提 1448 00:47:47,919 --> 00:47:49,779 也欢迎加入我们的用户群 1449 00:47:49,779 --> 00:47:51,959 跟我们的研发和产品同学 1450 00:47:51,959 --> 00:47:53,139 做积极的交流 1451 00:47:53,139 --> 00:47:54,699 有意见或者有建议 1452 00:47:54,699 --> 00:47:56,319 都可以在里面跟我们提出来 1453 00:47:56,319 --> 00:47:57,559 是的那么本场之外 1454 00:47:57,559 --> 00:47:59,879 其实我们围绕Octop的技艺机制 1455 00:47:59,879 --> 00:48:03,099 以及竞品分析这个专家的能力 1456 00:48:03,099 --> 00:48:05,159 如何帮助我们去做日常调研 1457 00:48:05,159 --> 00:48:06,259 分析的工作 1458 00:48:06,259 --> 00:48:07,419 帮助我们提校 1459 00:48:07,419 --> 00:48:10,259 都进行了一个详细的讲 1460 00:48:10,259 --> 00:48:12,239 如果说云服务器一键 1461 00:48:12,239 --> 00:48:13,659 不需要建议多大的配置 1462 00:48:13,659 --> 00:48:15,299 这个因为我们现在 1463 00:48:15,299 --> 00:48:16,999 Octop支持多用户 1464 00:48:16,999 --> 00:48:19,079 其实多大配置取决于 1465 00:48:19,079 --> 00:48:22,479 这个用户箱就是这个机器或者Octop 1466 00:48:22,479 --> 00:48:23,739 支持多少个用户 1467 00:48:23,739 --> 00:48:27,539 我们后续也会出一个专门的配置推荐 1468 00:48:27,539 --> 00:48:29,859 来帮助大家选购服务器 1469 00:48:29,859 --> 00:48:32,559 全全老师这边说是100个员工左右的规模 1470 00:48:32,559 --> 00:48:33,079 好的 1471 00:48:33,079 --> 00:48:34,879 那我们推荐我们另外一款产品 1472 00:48:34,879 --> 00:48:35,539 Club Pro的 1473 00:48:35,539 --> 00:48:38,219 全全老师不知道有没有关注过Club Pro 1474 00:48:38,219 --> 00:48:39,459 可以去关注一下 1475 00:48:39,459 --> 00:48:42,759 当然如果非常想用我们Octop 1476 00:48:42,759 --> 00:48:45,159 我们后续也会给一个推荐 1477 00:48:45,159 --> 00:48:47,119 Emma问可以部署到本地吗 1478 00:48:47,119 --> 00:48:47,899 可以的可以的 1479 00:48:47,899 --> 00:48:50,379 Emma可以直接访问我们的DHub仓库 1480 00:48:50,379 --> 00:48:54,019 Vidmin有完整的部署的一个介绍 1481 00:48:54,019 --> 00:48:56,139 我们今天的直播就到这里结束了 1482 00:48:56,139 --> 00:48:56,699 好的 1483 00:48:56,699 --> 00:48:57,179 拜拜