WEBVTT

00:00:00.466 --> 00:00:01.233
过去一年

00:00:01.233 --> 00:00:04.433
我们一直在训练 AI 变得越来越聪明

00:00:04.566 --> 00:00:06.500
但有一个奇怪的现象就是：

00:00:06.600 --> 00:00:09.566
单个 AI 的能力确实是越来越强了

00:00:09.600 --> 00:00:13.100
但不同 AI 之间却依然像隔着一堵墙

00:00:13.466 --> 00:00:15.300
不是因为它们没有交流能力

00:00:15.300 --> 00:00:18.133
而是因为今天的大多数 AI 产品

00:00:18.166 --> 00:00:20.333
都被设计成独立的系统

00:00:20.766 --> 00:00:25.266
它们有不同的平台、不同的数据边界、不同的运行环境

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

00:00:29.000 --> 00:00:29.700
当然

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

00:00:33.233 --> 00:00:34.866
但对于个人用户来说

00:00:34.866 --> 00:00:37.533
一旦想让 Agent 24 小时运行

00:00:37.566 --> 00:00:38.733
持续调用模型

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

00:00:42.766 --> 00:00:46.366
而包月的 Chat 窗口虽然很便宜、很好用

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

00:00:50.300 --> 00:00:52.733
所以，一个运行在云端的 AI

00:00:52.766 --> 00:00:55.600
和另一个运行在你私人服务器（VPS / 本地）上的 AI

00:00:55.600 --> 00:00:57.333
并不会像两个同事一样

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

00:01:00.266 --> 00:01:04.366
那最近呢 Google Gemini Pro 用户开放了 Spark 智能体

00:01:04.500 --> 00:01:05.700
我用了几天之后

00:01:05.700 --> 00:01:07.633
一个最大的感受就是：

00:01:07.633 --> 00:01:10.133
它不像普通的 Gemini 聊天窗口

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

00:01:12.366 --> 00:01:17.433
它会主动拆解问题、寻找资料、不断修正自己的答案

00:01:17.600 --> 00:01:18.666
甚至让我觉得

00:01:18.666 --> 00:01:22.133
它已经非常接近一个真正的智能助理

00:01:22.166 --> 00:01:23.333
而有意思的是

00:01:23.366 --> 00:01:27.900
这种体验和我一直使用的 Hermes Agent 有一种相似之处

00:01:27.900 --> 00:01:31.000
就是：它们都不是简单等待指令

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

00:01:34.400 --> 00:01:36.033
而且最爽的一点是：

00:01:36.033 --> 00:01:39.933
以前如果想让 Hermes 调用类似 Gemini 的能力

00:01:39.966 --> 00:01:42.000
通常需要通过 API 接入

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

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

00:01:48.566 --> 00:01:50.366
那种感觉有一点像：

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

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

00:01:54.366 --> 00:01:55.033
但是

00:01:55.033 --> 00:01:57.333
很快我遇到了一个更有意思的问题

00:01:57.333 --> 00:01:57.966
就是：

00:01:57.966 --> 00:01:59.600
如果 Spark 这么强

00:01:59.600 --> 00:02:04.133
那我部署在 Hostinger VPS 上、24 小时运行的 Hermes 呢？

00:02:04.200 --> 00:02:06.166
为什么它们不能一起工作？

00:02:06.233 --> 00:02:08.100
为什么一个在 Google 云端

00:02:08.100 --> 00:02:10.700
一个在我的 Hostinger VPS 上的 AI

00:02:10.700 --> 00:02:13.433
它们之间还是隔着一堵墙呢？

00:02:13.800 --> 00:02:16.533
以前我的解决方法非常原始，就是：

00:02:16.566 --> 00:02:20.066
手动复制、粘贴、再复制、再粘贴

00:02:20.166 --> 00:02:21.933
我必须做人肉搬运工

00:02:21.966 --> 00:02:24.466
把 Spark 的思考搬给 Hermes

00:02:24.466 --> 00:02:26.466
再把 Hermes 的回复搬回来

00:02:26.666 --> 00:02:28.733
但这显然不是一个好方法！

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

00:02:31.600 --> 00:02:32.433
在公司里

00:02:32.433 --> 00:02:36.066
员工不会靠 CEO 每天复制邮件传递信息

00:02:36.100 --> 00:02:39.966
他们有办公室、有会议、有文档、有历史

00:02:40.166 --> 00:02:42.533
所以最近，我尝试做了一件事情

00:02:42.566 --> 00:02:45.433
就是：给 AI 建了一间会议室

00:02:45.666 --> 00:02:47.866
我想验证一个非常简单的问题：

00:02:48.566 --> 00:02:52.066
如果两个原本无法直接通信的智能体

00:02:52.066 --> 00:02:54.033
拥有了同一个共享空间

00:02:54.033 --> 00:02:56.866
它们能不能真正形成协作呢？

00:02:57.066 --> 00:02:58.433
为了测试这件事情

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

00:03:00.833 --> 00:03:03.733
我打开 Spark，开始了一轮正常讨论

00:03:04.000 --> 00:03:09.466
讨论过程中，我又像平时一样把一个新的想法交给外部顾问 ChatGPT

00:03:09.466 --> 00:03:11.866
请它提供第三方意见

00:03:11.866 --> 00:03:14.500
对我来说，这种模式其实非常自然：

00:03:14.500 --> 00:03:17.233
因为不同模型有不同的特点

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

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

00:03:23.266 --> 00:03:24.133
所以接下来

00:03:24.166 --> 00:03:26.900
我把 ChatGPT 的建议带回 Spark

00:03:26.966 --> 00:03:28.700
继续进行了几轮讨论

00:03:29.100 --> 00:03:31.066
整个过程其实很普通

00:03:31.166 --> 00:03:35.066
这就是我平时和多个 AI 模型进行交流的方式

00:03:35.300 --> 00:03:37.866
但是，真正有意思的部分来了

00:03:37.866 --> 00:03:38.366
接下来

00:03:38.366 --> 00:03:40.500
我打开 Hermes 的新对话窗口

00:03:40.666 --> 00:03:43.233
注意：我没有告诉它前面发生了什么

00:03:43.233 --> 00:03:46.533
没有复制聊天记录、没有重新解释背景

00:03:46.566 --> 00:03:49.100
我只输入了一句话：“进入会议室

00:03:49.100 --> 00:03:51.733
了解一下刚才关于这个问题的讨论

00:03:51.733 --> 00:03:52.266
”

00:03:52.266 --> 00:03:54.633
然后，你可以看到它的回复

00:03:54.633 --> 00:03:57.066
它不仅知道 Spark 之前讨论了什么

00:03:57.066 --> 00:04:00.733
还知道中间有一个外部顾问 ChatGPT 参与

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

00:04:06.166 --> 00:04:08.400
接下来，我又回到了 Spark 的窗口

00:04:08.400 --> 00:04:11.000
我告诉它：“Hermes 刚刚参加了会议

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

00:04:14.266 --> 00:04:14.833
”

00:04:14.866 --> 00:04:15.666
你可以看到：

00:04:15.666 --> 00:04:18.566
Spark 没有要求我重新介绍 Hermes

00:04:18.700 --> 00:04:21.133
也没有让我复制 Hermes 的回复

00:04:21.166 --> 00:04:23.100
它直接继续了这场会议

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

00:04:25.966 --> 00:04:27.566
然后继续讨论

00:04:27.900 --> 00:04:29.933
而这一次实验真正验证的

00:04:29.966 --> 00:04:33.900
并不是 Spark 或者 Hermes 哪一个智能体更聪明

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

00:04:36.700 --> 00:04:37.866
真正的问题是：

00:04:37.866 --> 00:04:40.766
当多个智能体开始工作时

00:04:40.833 --> 00:04:43.200
它们能不能拥有共同的历史？

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

00:04:45.466 --> 00:04:47.433
并不只是因为员工聪明

00:04:47.466 --> 00:04:48.533
更重要的是：

00:04:48.566 --> 00:04:53.066
他们共享同一个办公室、同一套流程、同一份会议记录

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

00:04:56.433 --> 00:04:58.200
而这一次，我第一次看到：

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

00:05:00.400 --> 00:05:01.733
一个在 Google 云端

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

00:05:04.800 --> 00:05:07.766
开始像同一个组织里的成员一样协作

00:05:08.433 --> 00:05:10.633
过去，我们把 AI 当成工具

00:05:10.633 --> 00:05:14.633
而现在，我开始尝试让 AI 形成组织

00:05:14.833 --> 00:05:16.233
欢迎回到 WOW Insight！

00:05:16.266 --> 00:05:18.000
在继续今天的视频之前

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

00:05:21.100 --> 00:05:24.866
我知道还有不少观看我视频的朋友还没有订阅频道

00:05:24.866 --> 00:05:27.266
如果你觉得我的内容对你有帮助

00:05:27.266 --> 00:05:30.300
欢迎订阅我的频道并点赞、分享我的视频

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

00:05:32.500 --> 00:05:34.433
每月一杯咖啡的钱

00:05:34.433 --> 00:05:35.833
不仅是对我的支持

00:05:35.833 --> 00:05:42.766
也会帮助我继续制作更多关于 AI、智能体和未来技术方向的深度内容

00:05:43.000 --> 00:05:45.333
好的，接下来进入今天的主题

00:05:45.633 --> 00:05:47.700
如果今天你只有一个人

00:05:47.700 --> 00:05:52.266
但你仍然可以拥有一个程序员、一个架构师、一个审计专家

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

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

00:05:58.033 --> 00:05:59.933
知道过去做过什么决定

00:05:59.966 --> 00:06:01.700
为什么做出这个决定

00:06:01.966 --> 00:06:04.966
那你觉得，这还只是一个 AI 工具吗？

00:06:05.200 --> 00:06:05.900
过去

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

00:06:09.200 --> 00:06:11.900
每个人有自己的岗位，有固定的职责

00:06:11.900 --> 00:06:14.166
有会议记录，有项目历史

00:06:14.233 --> 00:06:15.033
而现在

00:06:15.033 --> 00:06:19.133
我们普通人完全可以尝试用不同的方式

00:06:19.166 --> 00:06:21.366
构建属于自己的 AI 组织

00:06:21.766 --> 00:06:23.300
在搭建这套系统之前

00:06:23.300 --> 00:06:25.633
我思考了一个很久的问题是：

00:06:25.633 --> 00:06:27.666
AI 如果要成为组织

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

00:06:31.166 --> 00:06:32.533
对于个人开发者来说

00:06:32.566 --> 00:06:34.366
这个办公室必须得便宜

00:06:34.433 --> 00:06:38.100
要 24 小时在线、稳定、有固定身份

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

00:06:40.166 --> 00:06:43.833
会有工位、邮箱、会议记录、历史档案

00:06:43.900 --> 00:06:46.033
但今天的大部分 AI Agent

00:06:46.100 --> 00:06:47.900
即使拥有自己的记忆

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

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

00:06:53.833 --> 00:06:55.500
它们知道自己做过什么

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

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

00:07:02.266 --> 00:07:09.033
而是让一个 AI 组织拥有连续的历史、共同的经验和可追溯的决策过程

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

00:07:12.600 --> 00:07:18.366
而是给 AI 建立一个固定物理住所 + 一套组织记忆系统

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

00:07:23.466 --> 00:07:25.233
但我遇到了三个难题：

00:07:25.233 --> 00:07:25.700
第一

00:07:25.700 --> 00:07:29.700
直接调 API 的按量计费成本和轮询焦虑

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

00:07:32.366 --> 00:07:36.133
如果每个 Request 都走 API 按 Token 计费

00:07:36.266 --> 00:07:39.233
月度账单会带来巨大的不确定性

00:07:39.300 --> 00:07:39.900
第二

00:07:39.900 --> 00:07:44.266
不同 Agent 之间缺少共享上下文和组织历史

00:07:44.500 --> 00:07:47.600
每个 Agent 可能都有自己的记忆能力

00:07:47.600 --> 00:07:51.233
但它们并不知道另一个 Agent 为什么做出某个决定

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

00:07:55.300 --> 00:07:56.066
最开始

00:07:56.066 --> 00:07:59.133
Spark 和 Hermes 之间没有共享空间

00:07:59.233 --> 00:08:01.566
我只能充当“人工中转站”，

00:08:01.700 --> 00:08:06.133
在两个智能体之间不断复制、粘贴、转述上下文

00:08:06.366 --> 00:08:08.066
这种方式不仅低效

00:08:08.066 --> 00:08:11.266
也让整个协作过程失去了连续性

00:08:11.600 --> 00:08:12.866
第三个难题是

00:08:12.866 --> 00:08:16.033
服务器选型与长期运行成本

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

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

00:08:22.466 --> 00:08:24.333
而是长期运行

00:08:24.600 --> 00:08:28.233
传统大厂云服务通常采用按量计费模式

00:08:28.233 --> 00:08:34.066
当 Agent 开始 24 小时运行、频繁调用模型和同步数据时

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

00:08:37.200 --> 00:08:41.800
所以我选择了一台轻量级 VPS 作为 Hermes 的长期住所

00:08:41.800 --> 00:08:46.133
比如我现在使用的 Hostinger KVM 2 VPS 节点

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

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

00:08:50.600 --> 00:08:51.766
我们来算一笔账：

00:08:52.066 --> 00:08:59.500
$8.79 的 VPS + $19.99 的 Gemini Pro 订阅 = 每月不到 30 美元

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

00:09:01.633 --> 00:09:07.866
你就已经可以拥有一个 7*24 在线的个人 AI Agent 基础设施

00:09:07.966 --> 00:09:13.300
而且不需要承担传统 API 按 Token 计费带来的不确定性

00:09:13.566 --> 00:09:18.233
那如果你也想尝试搭建自己的个人 AI Agent 基础设施

00:09:18.266 --> 00:09:22.233
我这次合作的 Hostinger 提供了一个频道专属优惠

00:09:22.233 --> 00:09:24.566
使用我的专属优惠码 WOWINSIGHT

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

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

00:09:30.033 --> 00:09:32.366
以及评论区的置顶位置

00:09:32.600 --> 00:09:34.000
在存储方面

00:09:34.000 --> 00:09:37.000
Google Drive 提供了足够大的共享空间（5TB 存储）

00:09:37.000 --> 00:09:39.500
作为 AI 组织的 Shared Workspace

00:09:39.766 --> 00:09:40.466
当然

00:09:40.466 --> 00:09:43.833
如果你希望进一步增强 Hermes 的推理能力

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

00:09:46.833 --> 00:09:50.833
例如利用一些免费额度 API 去处理轻量任务

00:09:50.833 --> 00:09:53.666
把复杂推理交给更强的模型；

00:09:53.766 --> 00:09:56.866
或者订阅像 ChatGPT 这样的一些服务

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

00:10:00.033 --> 00:10:02.866
这里还有一个我自己的真实变化

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

00:10:06.633 --> 00:10:09.666
把它作为家里的常驻 Agent 节点

00:10:09.766 --> 00:10:10.933
但实际体验下来

00:10:10.933 --> 00:10:17.133
一个云端 VPS (+ Gemini Spark)在稳定性、网络可达性和 24 小时运行方面

00:10:17.166 --> 00:10:19.933
其实更适合作为 Agent 的“办公室”。

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

00:10:23.300 --> 00:10:25.766
把它迁移到了云端 VPS上了

00:10:25.900 --> 00:10:27.866
我的 Mac mini 和 MacBook

00:10:27.900 --> 00:10:32.133
现在更多的是承担本地创作、开发和生产任务

00:10:32.166 --> 00:10:37.033
而 Hermes 则拥有了一个不会关机、不会离家的云端住所

00:10:37.266 --> 00:10:39.533
这也是我想验证的一件事情，就是：

00:10:39.566 --> 00:10:43.733
未来个人开发者可能不需要购买昂贵的服务器

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

00:10:46.366 --> 00:10:48.433
一个低成本云端节点

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

00:10:52.066 --> 00:10:53.400
刚才你看到的实验

00:10:53.400 --> 00:10:55.900
其实没有什么神秘的 Agent 魔法

00:10:56.066 --> 00:10:57.266
Spark、Hermes

00:10:57.266 --> 00:11:00.066
甚至中间参与讨论的 ChatGPT

00:11:00.100 --> 00:11:02.800
它们之所以能够像一个团队一样协作

00:11:02.800 --> 00:11:05.233
其实核心只有一个，就是：

00:11:05.233 --> 00:11:07.933
它们拥有了一个共同的工作空间

00:11:08.200 --> 00:11:08.900
这个空间

00:11:08.900 --> 00:11:11.533
成为整个 AI 组织的记忆中心

00:11:11.533 --> 00:11:13.800
这里需要强调的一点就是：

00:11:13.800 --> 00:11:16.666
Google Drive 本身并不是关键

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

00:11:19.333 --> 00:11:19.900
也就是：

00:11:19.900 --> 00:11:23.033
让不同 Agent 能够共享同一份历史

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

00:11:26.600 --> 00:11:29.500
这就是我所说的 AI 组织操作系统（Cognitive OS）

00:11:29.500 --> 00:11:31.033
那很多人可能会问：

00:11:31.066 --> 00:11:32.900
为什么不直接使用 MCP

00:11:32.900 --> 00:11:34.933
让两个 Agent 连接起来呢？

00:11:35.200 --> 00:11:37.533
实际上，MCP 非常重要

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

00:11:39.600 --> 00:11:40.933
MCP 解决的是：

00:11:40.933 --> 00:11:44.700
Agent 如何调用工具和访问外部的能力

00:11:44.866 --> 00:11:46.766
而我现在遇到的问题是：

00:11:46.800 --> 00:11:49.866
多个 Agent 如何共享组织历史

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

00:11:52.733 --> 00:11:55.366
但它不会自动变成公司的档案系统

00:11:55.666 --> 00:11:58.433
MCP 更像公司的业务接口

00:11:58.433 --> 00:12:04.633
而 Shared Workspace 更像办公室里的会议室、档案库和项目历史

00:12:04.933 --> 00:12:06.933
未来真正强大的 AI 组织

00:12:06.933 --> 00:12:08.633
一定需要两者结合

00:12:08.633 --> 00:12:09.400
那就是：

00:12:09.400 --> 00:12:12.333
Agent 通过 MCP 获得行动能力

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

00:12:15.733 --> 00:12:17.100
在这个共享空间里

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

00:12:19.866 --> 00:12:21.966
它们可不是三个聊天窗口哦

00:12:22.100 --> 00:12:24.000
真正让它们成为一个组织的

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

00:12:27.600 --> 00:12:29.100
现在 AI 最大的问题

00:12:29.100 --> 00:12:30.666
并不是它不知道答案

00:12:30.666 --> 00:12:32.266
而是：它知道答案

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

00:12:35.666 --> 00:12:36.933
一个真正的组织

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

00:12:39.933 --> 00:12:41.900
而是靠历史去理解：

00:12:41.900 --> 00:12:43.300
为什么做出这个决定？

00:12:43.300 --> 00:12:44.900
为什么放弃另一个方案？

00:12:44.900 --> 00:12:47.833
哪些原则是不能被轻易改变的？

00:12:48.133 --> 00:12:49.700
所以我真正想解决的

00:12:49.700 --> 00:12:52.300
不只是让 AI 保存更多的知识

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

00:12:55.700 --> 00:12:58.500
这也是为什么我们加入了：SOPF：

00:12:58.666 --> 00:13:00.500
自动实时落盘（AutoSave on Reply）

00:13:00.500 --> 00:13:02.466
它就像 AI 组织里的秘书

00:13:02.733 --> 00:13:05.066
人类公司为什么需要秘书呢？

00:13:05.233 --> 00:13:07.166
不是因为 CEO 不会写字

00:13:07.266 --> 00:13:12.700
而是因为一个组织不能依赖某一个人的大脑保存所有历史

00:13:12.833 --> 00:13:16.700
秘书负责记录会议、整理决定、保存上下文

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

00:13:21.033 --> 00:13:22.566
AI 组织也是一样

00:13:22.600 --> 00:13:28.433
SOPF 负责把重要的讨论、冲突、和决定自动写入这个文件（99meetingminutes

00:13:28.433 --> 00:13:28.633
md）

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

00:13:32.333 --> 00:13:34.966
那为什么采用单文件会议记录呢？

00:13:35.266 --> 00:13:37.600
因为理解一个长期项目

00:13:37.600 --> 00:13:39.466
最重要的不是文件数量

00:13:39.466 --> 00:13:41.533
而是时间连续性

00:13:41.700 --> 00:13:45.066
比如事情是如何一步一步发展到今天的？

00:13:45.066 --> 00:13:47.766
为什么当初选择 A，而不是 B？

00:13:48.033 --> 00:13:48.900
——这些信息

00:13:48.900 --> 00:13:51.100
才构成项目的真正的背景

00:13:51.266 --> 00:13:52.833
所以这个文件承担的

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

00:13:54.933 --> 00:13:57.133
而是一种情景记忆（Episodic Memory）

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

00:13:58.400 --> 00:14:00.566
我认为最有价值的设计之一

00:14:00.566 --> 00:14:02.566
就是异议日志（Dissent Log）

00:14:02.700 --> 00:14:04.200
未来 AI 最大的问题

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

00:14:06.633 --> 00:14:07.433
而是不知道：

00:14:07.433 --> 00:14:10.066
为什么当初没有选择另一个方向

00:14:10.266 --> 00:14:11.400
例如半年后

00:14:11.400 --> 00:14:15.433
Hermes 可能建议：“我们应该迁移到 Vector Database

00:14:15.633 --> 00:14:18.300
” 但是它查看异议日志（Dissent Log） 之后

00:14:18.300 --> 00:14:19.133
它会发现：

00:14:19.133 --> 00:14:22.466
过去 Auditor Agent 已经提出过这个建议

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

00:14:25.600 --> 00:14:28.766
原因是：当前阶段，简单优先于复杂

00:14:28.866 --> 00:14:31.400
未来当规模达到某个条件

00:14:31.400 --> 00:14:32.633
再重新评估

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

00:14:36.900 --> 00:14:38.933
而是一套工程哲学

00:14:39.033 --> 00:14:40.333
这就是组织文化

00:14:40.700 --> 00:14:41.966
其实回头看

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

00:14:45.266 --> 00:14:47.800
就是：个人如何管理知识？

00:14:47.800 --> 00:14:50.566
AI 如何理解知识之间的关系？

00:14:50.600 --> 00:14:53.600
组织如何保存自己的决策历史？

00:14:53.600 --> 00:14:56.866
过去，Obsidian 更关注个人知识组织；

00:14:57.033 --> 00:15:01.766
MemGraphRAG 探索的是知识之间如何连接和推理；

00:15:01.800 --> 00:15:03.600
而现在，我更关注：

00:15:03.600 --> 00:15:06.733
一个 AI 组织如何保存自己的经验

00:15:06.833 --> 00:15:09.466
因为知识可以复制，但决策历史

00:15:09.466 --> 00:15:11.933
才构成一个组织真正的灵魂

00:15:12.066 --> 00:15:13.033
没有这一层

00:15:13.033 --> 00:15:15.766
再多 Agent 也只是工具集合

00:15:15.833 --> 00:15:16.866
有了这一层

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

00:15:19.600 --> 00:15:20.300
另外

00:15:20.300 --> 00:15:23.733
我还加入了类似 Git Commit 的：SOPE 系统状态快照（State Snapshot）

00:15:24.266 --> 00:15:29.500
它记录当前系统状态、活跃 Agent、版本信息和核心约束

00:15:29.500 --> 00:15:31.700
这样新的 Agent 加入会议室时

00:15:31.700 --> 00:15:34.300
不需要重新阅读几万字的历史

00:15:34.300 --> 00:15:38.300
而是通过最新状态快照快速理解当前环境

00:15:38.500 --> 00:15:40.733
这也是为什么我把这个方向称为：

00:15:40.733 --> 00:15:42.066
Loop Engineering

00:15:42.333 --> 00:15:45.000
目标不是让 AI 完成一次任务

00:15:45.000 --> 00:15:49.266
而是让一个系统能够观察自己的状态、记录自己的经验

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

00:15:52.933 --> 00:15:55.000
当然，今天这间 AI 会议室

00:15:55.000 --> 00:15:56.233
只是一个开始

00:15:56.333 --> 00:15:58.900
《Building My Personal AI Company》这个系列

00:15:58.900 --> 00:16:01.933
并不是说我要真的开一家 AI 公司

00:16:02.066 --> 00:16:04.533
这里的“公司”，更像是一个隐喻

00:16:04.533 --> 00:16:05.233
就是：

00:16:05.233 --> 00:16:06.600
如果我们普通人

00:16:06.600 --> 00:16:08.833
也可以拥有多个 AI Agent

00:16:09.000 --> 00:16:12.666
它们有不同职责、共享记忆、持续协作

00:16:12.666 --> 00:16:14.133
那么一个人的生产方式

00:16:14.133 --> 00:16:16.966
会不会开始接近一个小型组织呢？

00:16:17.266 --> 00:16:19.933
所以接下来，我想用一系列实验

00:16:19.933 --> 00:16:23.433
去测试一个 AI 组织到底需要哪些能力

00:16:23.666 --> 00:16:24.466
这一集呢

00:16:24.466 --> 00:16:26.400
我们建立了第一间 AI 会议室

00:16:26.400 --> 00:16:27.533
测试的问题是：

00:16:27.533 --> 00:16:30.633
两个原本无法直接通信的智能体

00:16:30.633 --> 00:16:33.633
能不能共享历史、理解过去的决定

00:16:33.633 --> 00:16:35.900
并像团队成员一样继续协作？

00:16:35.900 --> 00:16:36.433
答案

00:16:36.433 --> 00:16:40.366
就是今天你看到的 Spark + Hermes AI 董事会

00:16:40.600 --> 00:16:41.533
那下一集

00:16:41.533 --> 00:16:44.300
我们会给 AI 接入真正的工程能力

00:16:44.300 --> 00:16:46.900
通过 Claude Code + ECC（Engineering Command Center）

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

00:16:50.200 --> 00:16:52.600
而是可以真正参与软件开发：

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

00:16:57.733 --> 00:16:59.433
第三集我们会探讨：

00:16:59.433 --> 00:17:02.133
AI 能不能建立自己的情报网络？

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

00:17:05.266 --> 00:17:06.233
那下一阶段

00:17:06.233 --> 00:17:08.900
我们会让 AI 拥有自己的情报部门：

00:17:08.900 --> 00:17:11.733
通过 OmniHunter + Knowledge Graph

00:17:11.800 --> 00:17:17.333
让 AI 持续追踪代码、论文、博客以及开放网络中的重要信息

00:17:17.333 --> 00:17:19.166
并形成自己的知识地图

00:17:19.400 --> 00:17:21.366
那在第四集我们会探讨：

00:17:21.400 --> 00:17:24.166
AI 能不能形成长期知识体系？

00:17:24.266 --> 00:17:25.733
知道信息还不够

00:17:25.733 --> 00:17:28.300
真正的组织，需要积累经验

00:17:28.466 --> 00:17:29.433
那在这一集

00:17:29.433 --> 00:17:32.533
我们会探索 MemGraphRAG、Obsidian

00:17:32.533 --> 00:17:34.866
以及更复杂的知识结构

00:17:34.933 --> 00:17:37.300
让 AI 的记忆从简单文件

00:17:37.300 --> 00:17:41.533
逐渐变成可以检索、可以关联和可以推理的知识网络

00:17:41.700 --> 00:17:43.866
那在第五集，也就是最后一集

00:17:43.866 --> 00:17:44.900
我们会探讨：

00:17:44.900 --> 00:17:47.333
AI 能不能形成自己的协作网络？

00:17:47.400 --> 00:17:50.300
我们会继续探索 Hermes AgentMesh：

00:17:50.433 --> 00:17:54.466
让不同设备、不同服务器、不同云端 Agent

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

00:17:58.533 --> 00:18:00.933
那这套系列真正想探索的

00:18:00.933 --> 00:18:03.200
并不是“我用了多少 AI 工具”。

00:18:03.200 --> 00:18:05.333
而是一个更大的问题，就是：

00:18:05.333 --> 00:18:07.466
当 AI 从一个聊天窗口

00:18:07.466 --> 00:18:12.833
逐渐变成多个拥有职责、记忆和反馈循环的智能体时

00:18:12.900 --> 00:18:14.333
一个人的工作方式

00:18:14.333 --> 00:18:17.500
会不会开始出现类似组织的形态？

00:18:17.733 --> 00:18:21.033
我不知道 AI 公司时代是否真的已经开始

00:18:21.033 --> 00:18:22.600
但我想亲自验证：

00:18:22.600 --> 00:18:23.933
一个普通开发者

00:18:23.933 --> 00:18:28.366
今天到底能不能搭建属于自己的第一个 AI 组织

00:18:28.433 --> 00:18:30.233
好的，今天的视频我们就先聊到这里

00:18:30.233 --> 00:18:31.933
感谢观看，我们下期再见！