WEBVTT

00:00:00.000 --> 00:00:20.100
过去一年,我们一直在训练AI,变得越来越聪明。但有一个奇怪的现象就是,单个AI的能力确实是越来越强了,但不同AI之间却依然像隔着一堵墙。不是因为它们没有交流能力,而是因为今天的大多数AI产品都被设计成独立的系统。

00:00:20.100 --> 00:00:22.280
它们有不同的平台

00:00:22.280 --> 00:00:23.580
不同的数据边界

00:00:23.580 --> 00:00:25.000
不同的运行环境

00:00:25.000 --> 00:00:28.400
但却没有一个天然共享的组织空间

00:00:28.400 --> 00:00:29.380
当然

00:00:29.380 --> 00:00:33.120
你可以通过API把不同的模型连接起来

00:00:33.120 --> 00:00:34.760
但对于个人用户来说

00:00:34.760 --> 00:00:37.360
一旦想让Agent24小时运行

00:00:37.360 --> 00:00:38.680
持续调用模型

00:00:38.680 --> 00:00:42.220
那API的费用很快就会成为一个现实问题

00:00:42.220 --> 00:00:45.460
而包裕的拆窗口虽然很便宜

00:00:45.460 --> 00:00:46.160
很好用

00:00:46.160 --> 00:00:49.700
但它们通常还是一个一个孤立的智能体

00:00:49.700 --> 00:00:52.560
所以一个运行在云端的AI

00:00:52.560 --> 00:00:55.320
和另一个运行在你私人服务器上的AI

00:00:55.320 --> 00:00:57.180
并不会像两个同事一样

00:00:57.180 --> 00:00:59.740
自然进入同一个会议室来协作

00:00:59.740 --> 00:01:04.140
最近Google JamLab Pro用户开放了Spark智能体

00:01:04.140 --> 00:01:05.620
我用了几天之后

00:01:05.620 --> 00:01:07.360
一个最大的感受就是

00:01:07.360 --> 00:01:09.880
它不像普通的JamLab聊天窗口

00:01:09.880 --> 00:01:12.280
当你给它一个复杂任务时

00:01:12.280 --> 00:01:14.340
它会主动的拆解问题

00:01:14.340 --> 00:01:15.360
寻找资料

00:01:15.360 --> 00:01:17.440
不断修正自己的答案

00:01:17.440 --> 00:01:18.440
甚至让我觉得

00:01:18.440 --> 00:01:21.980
它已经非常接近一个真正的智能助手

00:01:21.980 --> 00:01:23.120
而有意思的是

00:01:23.120 --> 00:01:26.200
这种体验和我一直使用的Hermis Agent

00:01:26.200 --> 00:01:27.700
有一种相似之处

00:01:27.700 --> 00:01:30.800
就是他们都不是简单等待指令

00:01:30.800 --> 00:01:34.440
而是在目标驱动下主动推进任务

00:01:34.440 --> 00:01:35.820
而且最爽的一点是

00:01:35.820 --> 00:01:38.060
以前如果想让Hermis

00:01:38.060 --> 00:01:39.680
这样用类似Gemlite的能力

00:01:39.680 --> 00:01:41.960
通常需要通过API接入

00:01:41.960 --> 00:01:45.040
然后还要考虑Token消耗和账单问题

00:01:45.040 --> 00:01:48.080
而现在订阅用户就可以直接体验了

00:01:48.080 --> 00:01:50.160
那种感觉有一点像

00:01:50.160 --> 00:01:51.900
终于不用担心账单

00:01:51.900 --> 00:01:53.940
可以放心好谷歌的羊毛了

00:01:53.940 --> 00:01:57.160
但是很快我就遇到了一个更有意思的问题

00:01:57.160 --> 00:01:59.420
就是如果Spark那么强

00:01:59.420 --> 00:02:01.720
那我不属在hostinger VPS上

00:02:01.720 --> 00:02:03.860
24小时运行的Hermes呢

00:02:03.860 --> 00:02:06.120
为什么他们不能一起工作呢

00:02:06.120 --> 00:02:07.980
为什么一个在Google云端

00:02:07.980 --> 00:02:10.460
一个在我的hostinger VPS上的AI

00:02:10.460 --> 00:02:13.160
他们之间还是隔着一堵墙呢

00:02:13.160 --> 00:02:16.000
以前我的解决方法非常原始

00:02:16.000 --> 00:02:18.240
就是手动复制粘贴

00:02:18.240 --> 00:02:19.780
再复制再粘贴

00:02:19.780 --> 00:02:21.840
我必须做人肉搬一工

00:02:21.840 --> 00:02:23.120
把Spark的思考

00:02:23.120 --> 00:02:24.280
搬给Hermes

00:02:24.280 --> 00:02:26.540
再把Hermes的回复搬回来

00:02:26.540 --> 00:02:28.440
这显然不是一个好方法

00:02:28.440 --> 00:02:31.320
我突然想到了我管理过的公司

00:02:31.320 --> 00:02:32.320
在公司里

00:02:32.320 --> 00:02:33.700
员工不会靠CEO

00:02:33.700 --> 00:02:35.800
每天复制邮件传递信息

00:02:35.800 --> 00:02:37.320
他们有办公室

00:02:37.320 --> 00:02:38.180
有会议

00:02:38.180 --> 00:02:39.060
有文档

00:02:39.060 --> 00:02:39.700
有历史

00:02:39.700 --> 00:02:40.780
所以最近

00:02:40.780 --> 00:02:42.420
我尝试做了一件事情

00:02:42.420 --> 00:02:45.120
就是给AI建了一间会议室

00:02:45.120 --> 00:02:47.720
我想验证一个非常简单的问题

00:02:47.720 --> 00:02:51.840
就是如果两个原本无法直接通信的智能体

00:02:51.840 --> 00:02:53.820
拥有了同一个共享空间

00:02:53.820 --> 00:02:56.600
它们能不能真正形成协作呢

00:02:56.600 --> 00:02:58.260
为了测试这件事情

00:02:58.260 --> 00:03:00.300
我做了一个非常简单的实验

00:03:00.300 --> 00:03:03.500
我打开Spark开始了一轮正常讨论

00:03:03.500 --> 00:03:04.880
讨论过程中

00:03:04.880 --> 00:03:06.380
我又像平时一样

00:03:06.380 --> 00:03:09.340
把一个新的想法交给外部顾问拆GPT

00:03:09.340 --> 00:03:11.360
请他提供第三方意见

00:03:11.360 --> 00:03:12.580
对我来说

00:03:12.580 --> 00:03:14.360
这种模式其实非常自然

00:03:14.360 --> 00:03:16.940
因为不同模型有不同的特点

00:03:16.940 --> 00:03:19.640
有时候我会让一个模型来提出方案

00:03:19.640 --> 00:03:22.580
再让另一个模型来负责挑战和审查

00:03:22.580 --> 00:03:24.100
所以接下来

00:03:24.100 --> 00:03:26.640
我把ChaiGPT的建议带回Spark

00:03:26.640 --> 00:03:28.440
继续进行了几轮讨论

00:03:28.440 --> 00:03:30.840
整个过程其实很普通

00:03:30.840 --> 00:03:33.260
这就是我平时和多个AI模型

00:03:33.260 --> 00:03:34.820
进行交流的方式

00:03:34.820 --> 00:03:37.540
但是真正有意思的部分来了

00:03:37.540 --> 00:03:40.220
接下来我打开Hermis的新对话窗口

00:03:40.220 --> 00:03:42.960
注意我没有告诉他前面发生了什么

00:03:42.960 --> 00:03:44.580
没有复制聊天记录

00:03:44.580 --> 00:03:46.280
没有重新解释背景

00:03:46.280 --> 00:03:47.920
我只输入了一句话

00:03:47.920 --> 00:03:51.760
进入会议室了解一下刚才关于这个问题的讨论

00:03:51.760 --> 00:03:54.420
然后你可以看到他的回复

00:03:54.420 --> 00:03:56.880
他不仅知道Spark之前讨论了什么

00:03:56.880 --> 00:04:00.500
还知道中间有一个外部顾问ChadGPT参与

00:04:00.500 --> 00:04:05.640
甚至理解了ChadGPT提出的建议和整个讨论的发展过程

00:04:05.640 --> 00:04:08.320
接下来我又回到了Spark窗口

00:04:08.320 --> 00:04:09.120
我告诉他

00:04:09.120 --> 00:04:11.000
Hermes刚刚参加了会议

00:04:11.000 --> 00:04:14.340
你总结一下他提出的几个值得考虑的方向

00:04:14.340 --> 00:04:18.300
你可以看到Spark没有要求我重新介绍Hermes

00:04:18.300 --> 00:04:20.860
也没有让我复制Hermes的回复

00:04:20.860 --> 00:04:23.180
他直接继续了这场会议

00:04:23.180 --> 00:04:25.880
就像两个员工进入了同一个会议室

00:04:25.880 --> 00:04:27.780
然后继续讨论

00:04:27.780 --> 00:04:29.840
而这次实验真正验证的

00:04:29.840 --> 00:04:33.580
并不是Spark或者Hermes每一个智能体更聪明

00:04:33.580 --> 00:04:36.460
因为今天的大模型已经足够强大了

00:04:36.460 --> 00:04:40.580
真正的问题是当多个智能体开始工作的时候

00:04:40.580 --> 00:04:42.980
他们能不能拥有共同的历史

00:04:42.980 --> 00:04:45.280
人类组织之所以能够协作

00:04:45.280 --> 00:04:47.340
并不是因为员工聪明

00:04:47.340 --> 00:04:48.280
更重要的是

00:04:48.280 --> 00:04:50.740
他们享受同一个办公室

00:04:50.740 --> 00:04:51.780
同一套流程

00:04:51.780 --> 00:04:52.900
同一份会议记录

00:04:52.900 --> 00:04:55.900
以及过去所有决定留下来的历史

00:04:55.900 --> 00:04:58.000
而这一次我第一次看到

00:04:58.000 --> 00:05:00.120
两个运行在不同地方的AI

00:05:00.120 --> 00:05:01.700
一个在Google云端

00:05:01.700 --> 00:05:04.500
一个在我的Hostinger VPS服务器上

00:05:04.500 --> 00:05:07.800
开始像同一个组织里的成员一样协作起来

00:05:07.800 --> 00:05:10.420
过去我们把AI当成工具

00:05:10.420 --> 00:05:14.320
而现在我开始尝试让AI形成组织

00:05:14.320 --> 00:05:15.940
欢迎回到All Insight

00:05:15.940 --> 00:05:17.940
在继续今天的视频之前

00:05:17.940 --> 00:05:20.720
我想先感谢一直支持这个频道朋友

00:05:20.720 --> 00:05:23.540
我知道还有不少观看我视频的朋友

00:05:23.540 --> 00:05:24.600
还没有订阅频道

00:05:24.600 --> 00:05:27.120
如果你觉得我的内容对你有所帮助

00:05:27.120 --> 00:05:28.400
欢迎订阅我的频道

00:05:28.400 --> 00:05:30.160
并点赞分享我的视频

00:05:30.160 --> 00:05:32.240
也欢迎加入我的频道会员

00:05:32.240 --> 00:05:34.220
每月一杯咖啡的钱

00:05:34.220 --> 00:05:35.780
不仅是对我的支持

00:05:35.780 --> 00:05:37.740
也会帮助我继续制作

00:05:37.740 --> 00:05:42.480
更多关于AI 智能体和未来技术方向的深度内容

00:05:42.480 --> 00:05:45.100
好的 接下来进入今天的主题

00:05:45.100 --> 00:05:47.580
如果今天你只有一个人

00:05:47.580 --> 00:05:50.080
那你仍然可以拥有一个程序员

00:05:50.080 --> 00:05:52.040
一个架构师 一个审计专家

00:05:52.040 --> 00:05:55.440
而且他们不是三个孤立的聊天窗口

00:05:55.440 --> 00:05:57.860
而是共享同一份组织记忆

00:05:57.860 --> 00:05:59.720
知道过去做过什么决定

00:05:59.720 --> 00:06:01.420
为什么做出这个决定

00:06:01.420 --> 00:06:04.700
那你觉得这还只是一个AI工具吗

00:06:04.700 --> 00:06:08.840
过去公司需要通过招聘员工来组成团队

00:06:08.840 --> 00:06:10.600
每个人有自己的岗位

00:06:10.600 --> 00:06:11.840
有固定的职责

00:06:11.840 --> 00:06:12.860
有会议记录

00:06:12.860 --> 00:06:13.900
有项目历史

00:06:13.900 --> 00:06:17.520
而现在我们普通人完全可以尝试

00:06:17.520 --> 00:06:21.080
用不同的方式构建属于自己的AI组织

00:06:21.080 --> 00:06:23.280
在搭建这套系统之前

00:06:23.280 --> 00:06:25.340
我思考了一个很久的问题就是

00:06:25.340 --> 00:06:27.460
AI如果要成为组织

00:06:27.460 --> 00:06:30.580
它首先需要一个不会消失的办公室

00:06:30.580 --> 00:06:32.500
对于个人开发者来说

00:06:32.500 --> 00:06:34.420
这个办公室必须得便宜

00:06:34.420 --> 00:06:37.860
要24小时在线稳定有固定身份

00:06:37.860 --> 00:06:40.100
那我们人类员工入职公司时

00:06:40.100 --> 00:06:43.560
会有工位邮箱会议记录历史档案

00:06:43.560 --> 00:06:45.780
但今天的大部分AI agent

00:06:45.780 --> 00:06:47.820
即使拥有自己的记忆

00:06:47.820 --> 00:06:50.040
也往往只是保存自己的上下文

00:06:50.040 --> 00:06:53.280
而不是整个组织共同形成的历史

00:06:53.280 --> 00:06:55.460
他们知道自己做过什么

00:06:55.460 --> 00:06:58.600
却不知道整个团队为什么这么决定

00:06:58.600 --> 00:07:02.120
真正的问题不是让AI记住更多信息

00:07:02.120 --> 00:07:05.420
而是让一个AI组织拥有持续的历史

00:07:05.420 --> 00:07:08.740
共享的经验和可追溯的决策过程

00:07:08.740 --> 00:07:12.400
我想解决的核心问题不是让AI更聪明

00:07:12.400 --> 00:07:15.820
而是给AI建立一个固定物理住所

00:07:15.820 --> 00:07:18.460
加上一套组织记忆系统

00:07:18.460 --> 00:07:23.120
我想让Agent拥有24小时常驻运行的服务器生命

00:07:23.120 --> 00:07:25.020
但我遇到了三个难题

00:07:25.020 --> 00:07:29.420
第一 直接调API的按量气费成本和轮巡焦虑

00:07:29.420 --> 00:07:32.160
高频上下文轮询和代码分析

00:07:32.160 --> 00:07:35.880
如果每个request都走API按token计费

00:07:35.880 --> 00:07:39.020
阅读账单会带来巨大的不确定性

00:07:39.020 --> 00:07:39.740
第二

00:07:39.740 --> 00:07:44.020
不同agent之间缺少共享上下文和组织历史

00:07:44.020 --> 00:07:47.440
每个agent可能都有自己的记忆能力

00:07:47.440 --> 00:07:51.100
但他们并不知道另一个agent为什么做出某个决定

00:07:51.100 --> 00:07:54.800
也无法自动继承彼此之间的讨论过程

00:07:54.800 --> 00:07:55.840
最开始

00:07:55.840 --> 00:07:58.900
Spark和Hermes之间没有共享空间

00:07:58.900 --> 00:07:59.960
我只能

00:08:00.000 --> 00:08:05.820
最開始,Spark和Hermes之間沒有共享空間,我只能充當人工中轉戰,在兩個智能體之間不斷複製黏貼轉述上下文。

00:08:06.080 --> 00:08:11.020
這種方式不僅低效,也讓整個協作過程失去了連續性。

00:08:11.020 --> 00:08:15.780
第三个难题是服务器选型与长期运行成本

00:08:15.780 --> 00:08:18.940
对于个人开发者和实验项目来说

00:08:18.940 --> 00:08:22.400
最大的成本压力往往不是第一次部署

00:08:22.400 --> 00:08:24.120
而是长期运行

00:08:24.120 --> 00:08:28.120
传统大厂云服务通常采用按量机费模式

00:08:28.120 --> 00:08:30.800
当agent开始24小时运行

00:08:30.800 --> 00:08:33.860
频繁调用模型和同步数据的时候

00:08:33.860 --> 00:08:36.680
成本就很容易变得不可预测

00:08:36.680 --> 00:08:39.520
所以我选择了一台轻量级VPS

00:08:39.520 --> 00:08:41.600
作为Hermes的长期住所

00:08:41.600 --> 00:08:42.880
比如我现在使用的

00:08:42.880 --> 00:08:45.300
Hostinger KVM2 VPS节点

00:08:45.300 --> 00:08:48.120
它更像是一个永远在线的办公室

00:08:48.120 --> 00:08:50.100
而不是一次性的计算资源

00:08:50.100 --> 00:08:51.540
我们来算一笔账

00:08:51.540 --> 00:08:53.620
8.79美金的VPS

00:08:53.620 --> 00:08:57.000
加上19.99美金的GemLab Pro订阅

00:08:57.000 --> 00:08:59.220
等于每月不到30美元

00:08:59.220 --> 00:09:01.460
那么在合理使用范围内

00:09:01.460 --> 00:09:03.300
你就已经可以拥有一个

00:09:03.300 --> 00:09:05.500
7×24小时在线的

00:09:05.500 --> 00:09:07.580
个人AI agent的基础设施

00:09:07.580 --> 00:09:10.580
而且不需要承担传统API

00:09:10.580 --> 00:09:13.040
按Token计费带来的不确定性

00:09:13.040 --> 00:09:15.980
那如果你也想尝试搭建自己的

00:09:15.980 --> 00:09:17.940
个人AI Agent的基础设施

00:09:17.940 --> 00:09:19.880
我这次合作的Hostinger

00:09:19.880 --> 00:09:21.960
提供了一个频道专属优惠

00:09:21.960 --> 00:09:24.420
使用我的专属优惠码All Insight

00:09:24.420 --> 00:09:27.120
可以获得额外10%的折扣

00:09:27.120 --> 00:09:29.860
链接我会放在视频简介的最上方

00:09:29.860 --> 00:09:32.480
以及评论期的置顶位置

00:09:32.480 --> 00:09:33.760
在存储方面

00:09:33.760 --> 00:09:36.680
Google Drive提供了足够大的共享空间

00:09:36.680 --> 00:09:39.080
作为AI组织的sheld workspace

00:09:39.080 --> 00:09:43.620
当然如果你希望进一步增强Hermes的推理能力

00:09:43.620 --> 00:09:46.820
也可以给它配置额外的大模型服务

00:09:46.820 --> 00:09:50.620
例如利用一些免费额读API去处理轻量任务

00:09:50.620 --> 00:09:53.400
把复杂推理交给更强的模型

00:09:53.400 --> 00:09:56.680
或者订阅像ChattieT这样的一些服务

00:09:56.680 --> 00:09:59.420
让Hermes拥有更强的决策能力

00:09:59.420 --> 00:10:02.660
这里还有一个我自己的真实变化

00:10:02.660 --> 00:10:06.280
过去我曾经让Mac mini M4运行Hermes

00:10:06.280 --> 00:10:09.420
把它作为家里的常驻agent的节点

00:10:09.420 --> 00:10:11.000
但实际体验下来

00:10:11.000 --> 00:10:13.680
一个云端VPS在稳定性

00:10:13.680 --> 00:10:16.920
网络可达性和24小时运行方面

00:10:16.920 --> 00:10:19.680
其实更适合作为agent的办公室

00:10:19.680 --> 00:10:23.040
所以我已经把Mac mini上的Hermes停止运行了

00:10:23.040 --> 00:10:25.560
把它迁移到了云端VPS上了

00:10:25.560 --> 00:10:27.600
我的Mac mini和MacBook

00:10:27.600 --> 00:10:30.420
现在更多的是承担本地创作

00:10:30.420 --> 00:10:31.980
开发和生产任务

00:10:31.980 --> 00:10:34.020
而Hermes则拥有了一个

00:10:34.020 --> 00:10:37.100
不会关机不会离家的云端住所

00:10:37.100 --> 00:10:38.780
这也是我想验证的一件事情

00:10:38.780 --> 00:10:40.980
就是未来个人开发者

00:10:40.980 --> 00:10:43.520
可能不需要购买昂贵的服务器

00:10:43.520 --> 00:10:46.260
也不需要准备一台永远开机的电脑

00:10:46.260 --> 00:10:48.280
一个低成本云端节点

00:10:48.280 --> 00:10:51.900
就可以成为属于自己的AI组织基础设施

00:10:51.900 --> 00:10:53.360
刚才你看到的实验

00:10:53.360 --> 00:10:55.700
其实没有什么神秘的agent的魔法

00:10:55.700 --> 00:10:59.820
Spark、Hermes甚至中间参与讨论的ChagPT

00:10:59.820 --> 00:11:02.560
他们之所以能够像一个团队一样协作

00:11:02.560 --> 00:11:04.680
其实核心只有一个

00:11:04.680 --> 00:11:08.020
就是他们拥有了一个共同的工作空间

00:11:08.020 --> 00:11:11.460
这个空间成为整个AI组织的记忆中心

00:11:11.460 --> 00:11:13.640
这里需要强调一点就是

00:11:13.640 --> 00:11:16.440
Google Drive本身并不是关键

00:11:16.440 --> 00:11:19.260
真正重要的是背后的组织协议

00:11:19.260 --> 00:11:22.920
也就是让不同agent能够共享同一份历史

00:11:22.920 --> 00:11:26.120
并且理解这些历史为什么产生

00:11:26.120 --> 00:11:29.440
这就是我说的AI组织操作系统

00:11:29.440 --> 00:11:30.800
很多人可能会问

00:11:30.800 --> 00:11:32.640
为什么不直接属于MCP

00:11:32.640 --> 00:11:34.680
让两个agent连接起来呢

00:11:34.680 --> 00:11:35.740
实际上

00:11:35.740 --> 00:11:37.340
MCP非常重要

00:11:37.340 --> 00:11:39.140
但它解决的是另一个问题

00:11:39.140 --> 00:11:40.660
MCP解决的是

00:11:40.660 --> 00:11:44.460
agent如何调用工具和访问外部的能力

00:11:44.460 --> 00:11:46.580
而我现在遇到的问题是

00:11:46.580 --> 00:11:49.580
多个agent如何共享组织历史

00:11:49.580 --> 00:11:52.540
一个电话可以让两个员工交流

00:11:52.540 --> 00:11:55.120
但它不会自动变成公司的答案系统

00:11:55.120 --> 00:11:58.200
MCP更像公司的业务接口

00:11:58.200 --> 00:12:00.060
而Shield Workspace

00:12:00.060 --> 00:12:04.360
更像办公室里的会议室 档案库和项目历史

00:12:04.360 --> 00:12:08.500
未来真正强大的AI组织一定需要两者结合

00:12:08.500 --> 00:12:12.080
那就是Agent通过MCP获得行动能力

00:12:12.080 --> 00:12:15.100
而且通过组织记忆获得连续性

00:12:15.100 --> 00:12:17.020
在这个共享空间里

00:12:17.020 --> 00:12:19.260
我搭建了一个简单的AI董事会

00:12:19.260 --> 00:12:21.560
他们可不是三个聊天窗口

00:12:21.560 --> 00:12:23.980
真正让他们成为一个组织的

00:12:23.980 --> 00:12:27.040
是背后的会议记录和决策历史

00:12:27.040 --> 00:12:29.060
现在AI最大的问题

00:12:29.060 --> 00:12:30.760
并不是他不知道答案

00:12:30.760 --> 00:12:32.320
而是他知道答案

00:12:32.320 --> 00:12:35.620
却不知道为什么当初选择了这个答案

00:12:35.620 --> 00:12:36.720
一个真正的组织

00:12:36.720 --> 00:12:39.700
不是靠数据库保存所有文件

00:12:39.700 --> 00:12:41.680
而是靠历史去理解

00:12:41.680 --> 00:12:43.180
为什么做出这个决定

00:12:43.180 --> 00:12:44.940
为什么放弃另一个方案

00:12:44.940 --> 00:12:47.580
哪些原则是不能被轻易改变的

00:12:47.580 --> 00:12:49.600
所以我真正想解决的

00:12:49.600 --> 00:12:52.080
不是让AI保存更多的知识

00:12:52.080 --> 00:12:55.260
而是让它保存知识形成的过程

00:12:55.260 --> 00:12:57.440
这也是为什么我们加入了

00:12:57.440 --> 00:13:00.060
SOPF自动实施落盘

00:13:00.060 --> 00:13:02.140
它就像AI组织里的秘书

00:13:02.140 --> 00:13:04.800
人类公司为什么需要秘书呢

00:13:04.800 --> 00:13:06.940
不是因为CEO不会写字

00:13:06.940 --> 00:13:08.800
而是因为一个组织

00:13:08.800 --> 00:13:12.480
不能依赖某一个人的大脑保存所有历史

00:13:12.480 --> 00:13:14.520
秘书负责记录会议

00:13:14.520 --> 00:13:15.520
整理决定

00:13:15.520 --> 00:13:16.520
保存上下文

00:13:16.520 --> 00:13:20.500
让未来加入的人能够快速理解过去发生了什么

00:13:20.500 --> 00:13:22.340
AI组织也是一样

00:13:22.340 --> 00:13:26.640
SOPF负责把重要的讨论冲突和决定

00:13:26.640 --> 00:13:28.120
自动写入这个文件

00:13:28.120 --> 00:13:31.720
让每一次会议都成为组织记忆的一部分

00:13:31.720 --> 00:13:34.720
那为什么采用单文圈会议记录呢

00:13:34.720 --> 00:13:37.440
因为理解一个长期项目

00:13:37.440 --> 00:13:39.500
最重要的不是文件数量

00:13:39.500 --> 00:13:41.320
而是时间连续性

00:13:41.320 --> 00:13:44.740
比如事情是如何一步一步发展到今天的

00:13:44.740 --> 00:13:47.540
为什么当初选择A而不是B

00:13:47.540 --> 00:13:50.800
这些信息才构成项目的真正的背景

00:13:50.800 --> 00:13:52.860
所以这个文件承担的

00:13:52.860 --> 00:13:54.840
其实不是普通的日志功能

00:13:54.840 --> 00:13:57.080
而是一种情景记忆

00:13:57.080 --> 00:13:58.400
而在这套协议里

00:13:58.400 --> 00:14:02.060
我认为最有价值的设计之一就是异议日志

00:14:02.060 --> 00:14:04.120
未来AI最大的问题

00:14:04.120 --> 00:14:06.460
可能不是不知道现在发生什么

00:14:06.460 --> 00:14:10.280
而是不知道为什么当初没有选择另一个方向

00:14:10.280 --> 00:14:11.300
例如半年之后

00:14:11.300 --> 00:14:12.600
Hermes可能建议

00:14:12.600 --> 00:14:15.100
我们应该迁移到Vector Database

00:14:15.100 --> 00:14:18.260
但是他查看异议日志之后

00:14:18.260 --> 00:14:19.100
他会发现

00:14:19.100 --> 00:14:22.280
过去Audit Agent已经提出过这个建议

00:14:22.280 --> 00:14:25.360
而当时CEO选择继续使用简单方案

00:14:25.360 --> 00:14:28.540
原因是当前阶段简单优异复杂

00:14:28.540 --> 00:14:32.340
未来当规模达到某个条件时再重新评估

00:14:32.340 --> 00:14:36.760
这时候AI理解的就不只是一个技术选择

00:14:36.760 --> 00:14:38.640
而是一套工程哲学

00:14:38.640 --> 00:14:40.100
这就是组织文化

00:14:40.100 --> 00:14:41.780
其实回头看

00:14:41.780 --> 00:14:45.160
这套设计延续了我过去一直探索的问题

00:14:45.160 --> 00:14:47.580
就是个人如何管理知识

00:14:47.580 --> 00:14:50.320
AI如何理解知识之间的关系

00:14:50.320 --> 00:14:53.440
组织如何保存自己的决策历史

00:14:53.440 --> 00:14:56.620
过去Obsidian更关注个人知识组织

00:14:56.620 --> 00:15:01.500
MemGraph Reg探索的是知识之间如何连接和推理

00:15:01.500 --> 00:15:06.720
而现在我更关注一个AI组织如何保存自己的经验

00:15:06.720 --> 00:15:08.200
因为确实可以复制

00:15:08.200 --> 00:15:11.640
但决策历史才构成一个组织真正的灵魂

00:15:11.640 --> 00:15:15.540
没有这一层再多agent的也只是工具集合

00:15:15.540 --> 00:15:16.680
有了这一层

00:15:16.680 --> 00:15:19.180
AI才开始接近一个真正的组织

00:15:19.180 --> 00:15:23.640
另外我还加入了类似Gate Comet的S.O.P.E

00:15:23.640 --> 00:15:26.400
它记录当前系统状态

00:15:26.400 --> 00:15:29.260
活跃agent 版本信息和核心约束

00:15:29.260 --> 00:15:31.540
这样新的agent加入会议室时

00:15:31.980 --> 00:15:38.480
這樣新的agent加入會議室時,不需要重新閱讀幾萬次的歷史,而是通過最新狀態快照,快速理解當前環境。

00:15:38.480 --> 00:15:45.080
這也是為什麼我把這個方向稱為loop engineering。目標不是讓AI完成一次任務,

00:15:45.080 --> 00:15:48.000
而是让一个系统能够观察自己的状态

00:15:48.000 --> 00:15:49.240
记录自己的经验

00:15:49.240 --> 00:15:52.780
并在长期运行中不断形成更强的组织能力

00:15:52.780 --> 00:15:55.960
当然今天这间AI会议室只是一个开始

00:15:55.960 --> 00:15:58.700
Building my personal AI company这个系列

00:15:58.700 --> 00:16:01.700
并不是说我要真的开一间AI公司

00:16:01.700 --> 00:16:04.320
这里的公司更像是一个隐喻

00:16:04.320 --> 00:16:08.600
就是如果我们普通人也可以拥有多个AI agent

00:16:08.600 --> 00:16:10.440
他们有不同职责

00:16:10.440 --> 00:16:12.380
共享技艺持续协作

00:16:12.380 --> 00:16:16.740
那么一个人的生产方式会不会开始接近一个小型组织呢

00:16:16.740 --> 00:16:21.420
所以接下来我想用一系列实验去测试一个AI组织

00:16:21.420 --> 00:16:23.160
到底需要哪些能力

00:16:23.160 --> 00:16:26.220
这一集我们建立了第一件AI会议室

00:16:26.220 --> 00:16:30.420
测试的问题是两个原本无法直接通信的职能体

00:16:30.420 --> 00:16:33.520
能不能共享历史理解过去的决定

00:16:33.520 --> 00:16:35.600
并像团队成员一样继续协作

00:16:35.600 --> 00:16:40.120
答案就是今天你看到的Spark加上Hermes AI董事会

00:16:40.120 --> 00:16:44.060
下一集我们会给AI介入真正的工程能力

00:16:44.060 --> 00:16:46.540
通过Cloud Code加上VCC

00:16:46.540 --> 00:16:50.040
测试AI是否不仅能够讨论代码

00:16:50.040 --> 00:16:52.500
而是可以真正参与软件开发

00:16:52.500 --> 00:16:57.320
像阅读项目 修改代码 运行测试 修复问题这些

00:16:57.320 --> 00:17:01.860
第三集我们会探讨AI能不能建立自己的情报网络

00:17:01.860 --> 00:17:04.800
因为一个组织不能只等待信息

00:17:04.800 --> 00:17:08.660
下一阶段我们会让AI拥有自己的情报部门

00:17:08.660 --> 00:17:11.560
通过OmniHunter加上Knowledge Graph

00:17:11.560 --> 00:17:14.960
让AI持续追踪代码论文博客

00:17:14.960 --> 00:17:17.100
以及开放网络中的重要信息

00:17:17.100 --> 00:17:18.920
并形成自己的知识地图

00:17:18.920 --> 00:17:21.140
在第四集我们会探讨

00:17:21.140 --> 00:17:23.920
AI能不能形成长期知识体系

00:17:23.920 --> 00:17:25.460
知道信息还不够

00:17:25.460 --> 00:17:28.060
真正的组织需要积累经验

00:17:28.060 --> 00:17:31.520
在这一集我们会探索MemGraph Reg

00:17:31.520 --> 00:17:34.580
Obsidian以及更复杂的知识结构

00:17:34.580 --> 00:17:37.080
让AI的记忆从简单文件

00:17:37.080 --> 00:17:39.020
逐步变成可以检索

00:17:39.020 --> 00:17:41.260
可以关联和可以推理的知识网络

00:17:41.260 --> 00:17:42.620
那在第五集

00:17:42.620 --> 00:17:43.760
也就是最后一集

00:17:43.760 --> 00:17:47.040
我们会探讨AI能不能形成自己的协作网络

00:17:47.040 --> 00:17:50.100
我们会继续探索Hermes Agent Math

00:17:50.100 --> 00:17:51.840
让不同设备

00:17:51.840 --> 00:17:52.960
不同服务器

00:17:52.960 --> 00:17:54.180
不同云端Agent

00:17:54.180 --> 00:17:58.420
形成一个更加完整的个人AI协作网络

00:17:58.420 --> 00:18:00.960
那这一套系列真正想探索的

00:18:00.960 --> 00:18:03.020
并不是我用了多少AI工具

00:18:03.020 --> 00:18:04.660
而是一个更大的问题

00:18:04.660 --> 00:18:07.340
就是当AI从一个聊天窗口

00:18:07.340 --> 00:18:10.140
逐渐变成多个拥有职责

00:18:10.140 --> 00:18:12.560
记忆和反馈循环的智能体势

00:18:12.560 --> 00:18:14.260
一个人的工作方式

00:18:14.260 --> 00:18:17.220
会不会开始出现类似组织的形态

00:18:17.220 --> 00:18:19.320
我不知道AI公司时代

00:18:19.320 --> 00:18:20.840
是否真的已经开始

00:18:20.840 --> 00:18:23.820
但我想亲自验证一个普通开发者

00:18:23.820 --> 00:18:26.480
今天到底能不能搭建属于

00:18:26.480 --> 00:18:28.100
自己的第一个AI组织

00:18:28.100 --> 00:18:30.180
今天的视频我们就先聊到这里

00:18:30.180 --> 00:18:30.880
感谢观看

00:18:30.880 --> 00:18:31.760
我们下期再见