WEBVTT
Kind: captions
Language: zh

00:00:00.066 --> 00:00:02.300
大家好欢迎来到灵姐说AI

00:00:02.400 --> 00:00:05.333
最近有一组概念在硅谷非常的火

00:00:05.333 --> 00:00:07.766
叫做Loop l o o p

00:00:07.866 --> 00:00:09.000
Loop循环

00:00:09.133 --> 00:00:11.566
Openclaw的创始人Peter Steinberger在

00:00:11.566 --> 00:00:13.766
6月初发布了一条消息

00:00:13.800 --> 00:00:14.933
他是这么说的

00:00:15.000 --> 00:00:18.700
他说here is your monthly reminder that you

00:00:18.700 --> 00:00:21.733
shouldn't be promoting coding agents anymore

00:00:22.133 --> 00:00:23.666
他说提醒大家一下啊

00:00:23.666 --> 00:00:26.600
你不应该再主动的去

00:00:26.600 --> 00:00:29.200
提示你的coding agent了

00:00:29.200 --> 00:00:30.933
你现在要干的事情是什么呢

00:00:30.933 --> 00:00:35.366
you should be designing loops that prompts your agents

00:00:35.666 --> 00:00:40.133
你应该为你的agent去设计一些循环

00:00:40.533 --> 00:00:44.200
这个帖子发布后有830万的观看

00:00:44.200 --> 00:00:45.500
另外Boris Cherny

00:00:45.566 --> 00:00:47.566
他作为Claude code的

00:00:47.566 --> 00:00:49.566
创始人和负责人之一

00:00:49.566 --> 00:00:51.900
他是一位资深的软件工程师

00:00:51.966 --> 00:00:54.466
他在最近的一次访谈中

00:00:54.466 --> 00:00:55.333
他这么说

00:00:55.400 --> 00:00:57.866
my job is writing loop

00:00:58.066 --> 00:01:00.066
我的工作就是写Loop

00:01:24.266 --> 00:01:27.133
另外一位来自谷歌系的工程师Addy

00:01:27.266 --> 00:01:30.866
他是长期负责谷歌Chrome的开发者体验

00:01:30.933 --> 00:01:34.700
现在主要聚焦于Google cloud AI和agent

00:01:34.700 --> 00:01:37.500
开发生态的这么一个工程的领导者

00:01:37.533 --> 00:01:40.400
他写了一篇文章叫做Loop engineering

00:01:40.866 --> 00:01:43.100
专门阐述了Loop相关的概念

00:01:43.100 --> 00:01:45.766
可以说Loop这个概念和思路啊

00:01:45.766 --> 00:01:47.900
最近在硅谷非常的火

00:01:48.000 --> 00:01:48.700
实际上啊

00:01:48.700 --> 00:01:50.000
不谦虚的说

00:01:50.000 --> 00:01:53.533
我们在一年前就开始用Loop的

00:01:53.533 --> 00:01:57.066
这个思路在进行AI的应用和实践

00:01:57.200 --> 00:02:00.466
我正式把Loop这个想法和大家分享

00:02:00.466 --> 00:02:02.866
是在2025年的12月

00:02:02.866 --> 00:02:04.466
在12月那条视频里面

00:02:04.466 --> 00:02:08.300
我教大家怎么用Loop思维进行科研制图

00:02:08.300 --> 00:02:10.033
并且在最近4月份的时候

00:02:10.033 --> 00:02:13.400
我又给大家去专门讲了这个Loop思维

00:02:13.466 --> 00:02:16.533
怎么在组织提效中践行Loop

00:02:16.533 --> 00:02:17.800
做到AI first

00:02:17.933 --> 00:02:19.633
就仅仅从这个角度来讲

00:02:19.633 --> 00:02:22.266
我认为我的频道的很多的实践

00:02:22.266 --> 00:02:25.633
思想应用都是走在非常前沿的

00:02:25.633 --> 00:02:27.600
这期视频会进一步的和大家

00:02:27.600 --> 00:02:30.600
分享Loop思维怎么运用和实践

00:02:30.733 --> 00:02:33.466
这里的Loop实际上会涉及两层概念

00:02:33.466 --> 00:02:35.000
一层是agent Loop

00:02:35.033 --> 00:02:37.200
实际上这是底层的机制

00:02:37.233 --> 00:02:40.366
还有一层叫做Loop engineering其实呢

00:02:40.366 --> 00:02:43.166
这个就是机制化产品化和工程化

00:02:43.166 --> 00:02:45.333
我们这期视频就会一起来结合

00:02:45.333 --> 00:02:48.400
这些大佬的一些思想和表达

00:02:48.400 --> 00:02:50.166
看看我们自己怎么应用

00:02:50.233 --> 00:02:51.933
我之所以把Loop这个

00:02:51.933 --> 00:02:54.133
思维反复的拿出来讲

00:02:54.133 --> 00:02:56.066
第一个它确实很重要

00:02:56.166 --> 00:02:58.333
第二个它最近在硅谷这么火

00:02:58.366 --> 00:03:01.766
确实实际的操作的情形和整个的

00:03:01.766 --> 00:03:04.066
技术发展又到了一个新的阶段

00:03:04.366 --> 00:03:06.266
它最近这么火也是有原因的

00:03:06.266 --> 00:03:08.666
它刚好跟几个趋势叠加在了一起

00:03:08.666 --> 00:03:10.600
第一个是像Claude code

00:03:10.600 --> 00:03:13.200
和Codex这类coding agent

00:03:13.533 --> 00:03:16.033
它已经能够做长任务了

00:03:16.100 --> 00:03:20.066
第二个模型调用工具的能力日渐增强

00:03:20.066 --> 00:03:23.433
你可以看到Codex几乎是每天一更新

00:03:23.433 --> 00:03:25.800
它能够它能够调用的插件

00:03:25.800 --> 00:03:28.100
调用的API越来越丰富

00:03:28.166 --> 00:03:30.566
背后的工具skill越来越多

00:03:30.733 --> 00:03:32.533
由于agent的能力

00:03:32.633 --> 00:03:34.933
包括整个Harness框架的成熟

00:03:35.166 --> 00:03:37.133
这些应用到企业端

00:03:37.133 --> 00:03:41.900
企业会慢慢的开始关心这些可重复

00:03:41.900 --> 00:03:45.366
可测试可审计的这种agent工作流

00:03:45.366 --> 00:03:47.800
怎么在我自己的企业里面去实践

00:03:47.933 --> 00:03:51.500
第四个当AI的模型真的跑在

00:03:51.500 --> 00:03:53.566
真实的企业任务中时

00:03:53.566 --> 00:03:56.200
这时候TOKEN的成本任务的

00:03:56.200 --> 00:03:59.366
失败率包含权限风险都会

00:03:59.366 --> 00:04:01.800
开始成为一个真实的问题

00:04:01.933 --> 00:04:04.566
所以让agent多跑几轮还不够

00:04:04.733 --> 00:04:08.400
必须让它升级为可控的一个loop

00:04:08.433 --> 00:04:10.733
这是它的一个大的背景

00:04:10.766 --> 00:04:13.533
我们再来回过来讲这个Loop的机制

00:04:13.600 --> 00:04:16.633
这里讲到的一个核心的概念是agent Loop

00:04:16.800 --> 00:04:18.233
这里的agent Loop实际上

00:04:18.233 --> 00:04:20.166
是它的底层的机制

00:04:20.233 --> 00:04:23.133
之前我给大家讲的Loop的应用啊

00:04:23.133 --> 00:04:25.333
可能跟目前的agent阶段不一样

00:04:25.333 --> 00:04:27.100
但是它底层的思路

00:04:27.333 --> 00:04:30.300
和方法整个的链路闭环是一致的

00:04:30.300 --> 00:04:32.133
我们先有目标设定

00:04:32.133 --> 00:04:33.933
然后基于设定的目标

00:04:34.000 --> 00:04:35.533
规划它的任务步骤

00:04:35.600 --> 00:04:37.200
然后进行执行

00:04:37.233 --> 00:04:38.500
在执行这个阶段呢

00:04:38.500 --> 00:04:39.800
就会输出结果

00:04:39.833 --> 00:04:42.166
大部分人就会停到这一步

00:04:42.166 --> 00:04:43.600
它不是闭环的

00:04:43.766 --> 00:04:44.633
这个时候呢

00:04:44.633 --> 00:04:46.766
你应该合适的方式应该

00:04:46.766 --> 00:04:48.766
对他的这个执行的结果

00:04:48.800 --> 00:04:52.566
包括执行的过程进行observe观察

00:04:52.633 --> 00:04:55.766
看看里面有没有值得改进的地方

00:04:55.800 --> 00:04:57.800
这里值得改进反思复盘

00:04:57.800 --> 00:04:59.800
的过程不只是针对结果

00:04:59.833 --> 00:05:02.400
而且针对过程和步骤

00:05:02.733 --> 00:05:04.800
最后再基于要达成的目标

00:05:04.833 --> 00:05:06.900
不断的循环往进

00:05:07.000 --> 00:05:08.633
而agent loop要做的就是

00:05:08.633 --> 00:05:13.166
我要设置这么一个循环的机制我经常

00:05:13.433 --> 00:05:16.133
跟大家讲的是一种双执行的玩法

00:05:16.133 --> 00:05:18.533
比如说让Codex去执行

00:05:18.600 --> 00:05:21.333
让另外一个AI可以是CC或者

00:05:21.333 --> 00:05:24.300
是让GPT来进行观察反思

00:05:24.300 --> 00:05:26.833
这相当于给前面的执行者有

00:05:26.833 --> 00:05:29.366
了一个评审的第三方机制

00:05:29.533 --> 00:05:32.266
促使他去不断的迭代演进

00:05:32.266 --> 00:05:34.833
那未来像Openai也说

00:05:34.866 --> 00:05:36.766
他们未来会做一个超级APP

00:05:36.833 --> 00:05:38.466
这样的具体的操作层

00:05:38.466 --> 00:05:40.600
的方式可能会迭代

00:05:40.600 --> 00:05:41.533
可能会演进

00:05:41.566 --> 00:05:44.866
但是它底层的核心机制是一致的

00:05:44.866 --> 00:05:47.333
就是你要让这个agent有

00:05:47.333 --> 00:05:49.966
自我迭代自我演进的

00:05:50.166 --> 00:05:51.833
要设计出这么一个Loop

00:05:51.866 --> 00:05:53.466
为什么说这个Boris说

00:05:53.466 --> 00:05:56.000
我现在的工作是在写Loop

00:05:56.000 --> 00:05:58.666
而不是在写提示词写代码

00:05:58.666 --> 00:06:00.266
那么整个的这个

00:06:00.300 --> 00:06:02.366
工程化产品化的过程呢

00:06:02.366 --> 00:06:04.933
其实也经历了几个演进的阶段

00:06:05.100 --> 00:06:07.166
一开始我们讲我们用好AI

00:06:07.166 --> 00:06:08.566
讲的很多的就是

00:06:08.666 --> 00:06:11.066
提示词工程prompt engineering

00:06:11.066 --> 00:06:13.533
就是我怎么向AI

00:06:13.900 --> 00:06:15.300
提问问好这个问题

00:06:15.366 --> 00:06:18.500
这个时候核心的杠杆是我们的表达

00:06:18.500 --> 00:06:21.266
怎么精确地让AI去理解

00:06:21.533 --> 00:06:24.566
提升模型对单次输入的理解力

00:06:24.566 --> 00:06:26.000
然后再往前演进啊

00:06:26.000 --> 00:06:28.333
这里写的是workflow engineering

00:06:28.400 --> 00:06:31.533
很多人还听的是叫做context engineering

00:06:31.533 --> 00:06:32.866
就是上下文工程

00:06:33.100 --> 00:06:35.066
实际上这里的底层是一致的

00:06:35.066 --> 00:06:36.600
这里解决的是一个

00:06:36.733 --> 00:06:38.700
任务流的串联的问题

00:06:38.700 --> 00:06:42.300
就是一个整的大的工作和项目背景的

00:06:42.400 --> 00:06:43.300
这么一个问题

00:06:43.333 --> 00:06:47.366
相当于是用一种确定性的逻辑链条

00:06:47.366 --> 00:06:50.366
一个更加完整的上下文背景

00:06:50.366 --> 00:06:53.733
去提升AI对项目的理解程度

00:06:53.733 --> 00:06:55.533
去提升任务的完成率

00:06:55.566 --> 00:06:56.966
而到了第三个阶段

00:06:56.966 --> 00:06:58.533
前段时间也非常流行

00:06:58.533 --> 00:06:59.866
Openclaw出来之后

00:06:59.866 --> 00:07:01.600
这个Harness engineering

00:07:01.900 --> 00:07:05.000
就是他解决的是运行层的问题

00:07:05.066 --> 00:07:07.200
他需要给这个项目搭建

00:07:07.200 --> 00:07:09.700
一个比较好的执行环境

00:07:09.800 --> 00:07:12.700
解决工具和反馈的问题

00:07:12.966 --> 00:07:16.900
给这个agent去提供合适的权限框架

00:07:16.900 --> 00:07:18.666
还有可以验证的信号

00:07:18.700 --> 00:07:20.866
现在大家认可度比较高的

00:07:20.866 --> 00:07:22.066
CC还有Codex

00:07:22.066 --> 00:07:24.100
在Harness engineering这一层

00:07:24.166 --> 00:07:25.666
它都是做得比较好的

00:07:25.666 --> 00:07:27.700
它的精准执行任务的

00:07:27.700 --> 00:07:29.266
能力都是比较强的

00:07:29.500 --> 00:07:32.166
现在我们讲这个agent Loop的概念

00:07:32.166 --> 00:07:33.700
讲到了这个第四层

00:07:33.700 --> 00:07:35.266
叫做Loop engineering

00:07:35.600 --> 00:07:37.800
就是设计一个agent

00:07:37.866 --> 00:07:40.166
可以自我演进的闭环

00:07:40.400 --> 00:07:43.566
让系统替代人去提示

00:07:43.733 --> 00:07:45.866
检查和纠偏的agent

00:07:46.033 --> 00:07:48.800
就相当于你在工作环境里面

00:07:48.866 --> 00:07:51.766
设计了一个比较好的激励机制

00:07:51.766 --> 00:07:53.000
一个考核机制

00:07:53.100 --> 00:07:53.933
这些员工

00:07:53.933 --> 00:07:55.500
当然这里是数字员工

00:07:55.533 --> 00:07:58.600
他就可以持续的可靠的可控

00:07:58.600 --> 00:08:01.366
的在这个系统里面去运行

00:08:01.400 --> 00:08:01.933
在这里呢

00:08:01.933 --> 00:08:03.366
我也和大家一起去读

00:08:03.366 --> 00:08:05.500
一下Addy写的这篇博客

00:08:05.700 --> 00:08:06.966
他的Loop engineering

00:08:07.166 --> 00:08:07.866
在这里面

00:08:07.866 --> 00:08:09.966
他是怎么定义和理解

00:08:09.966 --> 00:08:11.500
这个Loop engineering的

00:08:11.500 --> 00:08:13.133
在Addy的博客里面

00:08:13.133 --> 00:08:15.366
他把Loop拆成了5个

00:08:15.366 --> 00:08:17.400
模块和一个记忆机制

00:08:17.500 --> 00:08:20.533
它们刚好对应了一个长期运行的

00:08:20.533 --> 00:08:23.066
agent系统必须解决的几个问题

00:08:23.100 --> 00:08:27.666
而刚好Claude code与Codex都具备这些组件

00:08:27.700 --> 00:08:29.200
只是命名不同

00:08:29.200 --> 00:08:31.833
这个就是他博客原文的表达

00:08:31.966 --> 00:08:35.533
作为一个谷歌的agent生态的工程师

00:08:35.566 --> 00:08:39.566
那他把Codex和CC放在这里来表达

00:08:39.566 --> 00:08:41.933
来讲这个Loop engineering的机制

00:08:42.200 --> 00:08:44.333
从某种程度上面来说

00:08:44.400 --> 00:08:48.233
也是在认可CC和Codex在通用

00:08:48.233 --> 00:08:50.866
agent它整个机制的完备性

00:08:50.866 --> 00:08:53.066
它包含了这五大要素

00:08:53.166 --> 00:08:56.366
自动化工作树技能插件

00:08:56.366 --> 00:08:57.666
还有子代理人

00:08:57.666 --> 00:09:00.633
还有一层就是它的状态记忆层

00:09:00.633 --> 00:09:01.766
我们一个个来看

00:09:01.766 --> 00:09:03.533
自动化这个是它的心跳

00:09:03.533 --> 00:09:06.033
在Codex里面就是它的心跳机制

00:09:06.033 --> 00:09:09.033
在claudecode里面是通过Loop的定时

00:09:09.033 --> 00:09:11.400
任务的运行符来进行运行的

00:09:11.400 --> 00:09:15.366
Automation本质上是来解决谁来启动循环

00:09:15.466 --> 00:09:17.766
就是让agent在特定的条件

00:09:17.766 --> 00:09:20.266
或者固定频率下自动醒来

00:09:20.266 --> 00:09:21.200
如果没有它

00:09:21.266 --> 00:09:23.433
loop只是手工跑了一次

00:09:23.666 --> 00:09:25.700
人还是要不断的提示

00:09:25.900 --> 00:09:30.066
但是Codex的Automation或者是CC的定时任务

00:09:30.066 --> 00:09:33.733
可以让整个的循环去定时的运行

00:09:33.733 --> 00:09:35.266
左侧这个边栏的自动化

00:09:35.266 --> 00:09:37.033
就是刚刚讲的自动

00:09:37.033 --> 00:09:38.900
运行循环机制的地方

00:09:38.900 --> 00:09:40.400
第二个板块是Worktree

00:09:40.400 --> 00:09:41.333
是隔离仓

00:09:41.466 --> 00:09:43.466
它解决的是多个agent

00:09:43.566 --> 00:09:45.266
同时工作会不会打架

00:09:45.300 --> 00:09:47.933
多个worktree它是共享Git历史

00:09:47.933 --> 00:09:50.833
但是它的文本副本是独立的

00:09:50.833 --> 00:09:53.266
可以让并行不变成混乱

00:09:53.300 --> 00:09:55.366
在你的Codex里面点到设置

00:09:55.433 --> 00:09:56.500
再点一下设置

00:09:56.633 --> 00:09:58.633
再点到左边的这个工作数

00:09:58.633 --> 00:10:00.866
就能够看到你对应的work tree

00:10:00.933 --> 00:10:02.433
第三个板块是skill

00:10:02.466 --> 00:10:03.866
这个板块其实大家这个

00:10:03.866 --> 00:10:06.400
概念目前应该是比较熟悉了

00:10:06.400 --> 00:10:08.966
它解决的是agent每次它

00:10:08.966 --> 00:10:11.233
都不是从零理解项目

00:10:11.233 --> 00:10:14.500
它会有一些固定的沉淀的工作流

00:10:14.600 --> 00:10:17.800
有一些封装下的沉淀的能力体系

00:10:17.900 --> 00:10:19.000
要搞清楚的是

00:10:19.100 --> 00:10:20.900
skill本身它是经验

00:10:20.900 --> 00:10:24.366
而Loop是让整个的经验运用起来

00:10:24.366 --> 00:10:26.033
循环执行的系统

00:10:26.033 --> 00:10:27.466
大家在你的对话框里面

00:10:27.466 --> 00:10:28.466
在Codex里面

00:10:28.466 --> 00:10:29.600
可以通过斜杠

00:10:29.833 --> 00:10:31.766
这样子可以快速的找到

00:10:31.766 --> 00:10:33.800
你看我这里封装的非常多的

00:10:33.800 --> 00:10:36.266
包括个人的和系统的skill

00:10:36.366 --> 00:10:39.066
你也可以通过对话让它给你去列举

00:10:39.300 --> 00:10:42.000
你在Codex里面去沉淀的这些skill

00:10:42.100 --> 00:10:45.033
可以对skill进行删除合并

00:10:45.066 --> 00:10:46.433
各种多种操作

00:10:46.466 --> 00:10:47.966
第四个部分是Connector

00:10:48.033 --> 00:10:50.033
这里包含了MCP

00:10:50.166 --> 00:10:51.433
包含了插件

00:10:51.600 --> 00:10:53.200
包含了API的接口

00:10:53.400 --> 00:10:55.866
很多时候我们说Codex可以剪辑

00:10:55.866 --> 00:10:59.433
实际上Codex本身是不能够剪辑的

00:10:59.433 --> 00:11:01.966
它通过接入外部的工具

00:11:01.966 --> 00:11:04.366
而让自己这个通用的agent有

00:11:04.366 --> 00:11:06.966
了非常多的泛化的能力

00:11:06.966 --> 00:11:07.700
包括在这里

00:11:07.700 --> 00:11:10.833
我可以通过Codex去收取和回复邮箱

00:11:10.833 --> 00:11:14.000
也可以在这里用Codex来剪辑视频生成MV

00:11:14.000 --> 00:11:14.800
生成音乐

00:11:14.833 --> 00:11:17.633
这些能力本身不是Codex自有的

00:11:17.633 --> 00:11:19.500
而是它通过接入插件

00:11:19.600 --> 00:11:21.233
接入这些连接器

00:11:21.266 --> 00:11:22.600
给它赋能的

00:11:22.600 --> 00:11:24.600
把外部的agent接入进来

00:11:24.666 --> 00:11:26.500
变成了自己的手脚

00:11:26.533 --> 00:11:28.466
第五个模块是SUB agents

00:11:28.666 --> 00:11:29.900
他原文是这么写的

00:11:30.100 --> 00:11:33.600
SUB agents keep the maker away from the Tracker

00:11:33.700 --> 00:11:37.533
就是让这个检查者和制图者

00:11:37.533 --> 00:11:39.466
他是分开两个角色

00:11:39.600 --> 00:11:41.666
平常我在讲这个Loop的时候

00:11:41.666 --> 00:11:43.200
我之前讲的这两个角色

00:11:43.200 --> 00:11:45.633
一个可能是一个Codex

00:11:45.700 --> 00:11:47.700
另外一个是GPT或者是CC

00:11:47.833 --> 00:11:49.933
或者是分开两个窗口

00:11:49.933 --> 00:11:53.600
或者是分开两个非常高级别的AI

00:11:53.600 --> 00:11:54.400
一个是Gemini

00:11:54.400 --> 00:11:55.200
一个是GPT

00:11:55.200 --> 00:11:56.133
都是可以的

00:11:56.266 --> 00:11:57.300
那么在这里呢

00:11:57.300 --> 00:11:59.100
可以通过子角色的

00:11:59.100 --> 00:12:00.900
方式来完成这个设定

00:12:00.900 --> 00:12:02.866
就相当于一个SUB agent

00:12:03.000 --> 00:12:06.066
它是整个的工作的运行者执行者

00:12:06.100 --> 00:12:07.400
另外一个SUB agent

00:12:07.433 --> 00:12:08.866
它是一个审核者

00:12:08.866 --> 00:12:11.033
它们的目标和角色不一样

00:12:11.033 --> 00:12:12.933
你看他这里花了比较多

00:12:12.933 --> 00:12:14.466
的笔墨来讲这个问题

00:12:14.466 --> 00:12:16.500
如果说你的审核的人和

00:12:16.500 --> 00:12:18.500
执行者不是分开循环的

00:12:18.500 --> 00:12:21.400
有可能会过拟合或出现一些问题

00:12:21.633 --> 00:12:22.433
他这里说啊

00:12:22.433 --> 00:12:24.400
就是一个要负责探索

00:12:24.500 --> 00:12:26.133
负责代码的编排

00:12:26.133 --> 00:12:27.566
另一个代理需要负责

00:12:27.566 --> 00:12:30.300
对现有规范进行验证

00:12:30.400 --> 00:12:32.133
执行本身值得花TOKEN

00:12:32.166 --> 00:12:35.266
而审查本身也值得花TOKEN

00:12:35.300 --> 00:12:37.866
这两个地方都非常重要

00:12:37.900 --> 00:12:40.800
很多人做任务的时候只管创建

00:12:40.833 --> 00:12:42.833
但是对应的检查没有做

00:12:42.866 --> 00:12:45.466
或者对应的检查者的这个角色

00:12:45.466 --> 00:12:48.433
没有和创建者的这个角色分离

00:12:48.533 --> 00:12:51.833
把创建者和检查者进行分离

00:12:51.900 --> 00:12:53.766
不断地循环迭代

00:12:53.866 --> 00:12:56.933
实现他们这个信息的互通共联

00:12:56.966 --> 00:13:00.366
是实现这个循环的非常关键的点啊

00:13:00.366 --> 00:13:02.166
而这五个模块之外的

00:13:02.166 --> 00:13:05.266
就是一个非常重要的状态记忆

00:13:05.400 --> 00:13:06.733
一个记忆机制

00:13:07.133 --> 00:13:09.400
模型可能会忘了它曾经做过的事

00:13:09.400 --> 00:13:12.100
但是如果你把它记在仓库里面

00:13:12.100 --> 00:13:12.933
它就不会

00:13:12.933 --> 00:13:15.466
所以你要定期的去写入记忆

00:13:15.466 --> 00:13:16.566
去更新记忆

00:13:16.666 --> 00:13:17.766
定期的复盘

00:13:17.800 --> 00:13:20.500
定期的给这个Loop系统升级

00:13:20.633 --> 00:13:22.466
如果说没有记忆机制

00:13:22.533 --> 00:13:25.166
那么Loop它每一次都是新的

00:13:25.166 --> 00:13:27.066
有了这样的记忆机制

00:13:27.200 --> 00:13:29.366
它把所有的经验进行沉淀

00:13:29.400 --> 00:13:31.266
所有的错误进行规避

00:13:31.533 --> 00:13:34.033
所有的工作都是留痕的

00:13:34.033 --> 00:13:36.166
那么这个Loop才是真正的Loop

00:13:36.166 --> 00:13:38.600
因为它是产生复利的Loop

00:13:38.600 --> 00:13:40.433
所以看完Addy的文章啊

00:13:40.433 --> 00:13:42.433
实际上这里闭环起来

00:13:42.433 --> 00:13:44.566
就是一个控制系统

00:13:44.600 --> 00:13:46.000
定时的去启动

00:13:46.100 --> 00:13:48.100
然后读取外部的输入

00:13:48.433 --> 00:13:51.633
调用agent里面的skill去理解任务

00:13:51.733 --> 00:13:55.300
并且创建一个彼此隔离的work tree

00:13:55.300 --> 00:13:56.800
让他们不容易污染

00:13:56.800 --> 00:13:58.000
不要互相打架

00:13:58.033 --> 00:14:00.300
然后组的agent执行

00:14:00.600 --> 00:14:03.366
然后有一个单独的分离的

00:14:03.366 --> 00:14:06.366
子agent角色审查这些规范

00:14:06.533 --> 00:14:10.566
然后再进行工具验证测试

00:14:10.700 --> 00:14:12.800
可以通过这个dry run或者

00:14:12.800 --> 00:14:15.133
是通过smoke test冒烟测试

00:14:15.300 --> 00:14:16.600
然后进行验证

00:14:16.733 --> 00:14:19.533
i接着就可以开PR去更新任务

00:14:19.566 --> 00:14:21.366
如果有失败就记录原因

00:14:21.366 --> 00:14:22.333
然后重试

00:14:22.500 --> 00:14:25.566
把所有的原因过程的记录写入memory

00:14:25.900 --> 00:14:27.966
然后再到下一轮继续

00:14:28.100 --> 00:14:29.733
进入一个闭环

00:14:29.800 --> 00:14:31.266
完成一个Loop

00:14:31.266 --> 00:14:32.600
Addy讲的5个模块加一

00:14:32.600 --> 00:14:33.700
个记忆机制的方式

00:14:33.700 --> 00:14:35.000
其实已经很完善了

00:14:35.033 --> 00:14:36.733
结合我自己的实操实践

00:14:36.733 --> 00:14:38.100
我觉得以下的

00:14:38.333 --> 00:14:40.600
四个板块也是非常重要的

00:14:40.600 --> 00:14:42.800
第一个是这个验收标准

00:14:42.833 --> 00:14:44.833
这个验收标准就是说这个

00:14:44.833 --> 00:14:47.466
Loop什么时候是持续执行的

00:14:47.466 --> 00:14:48.733
什么时候这个Loop

00:14:48.933 --> 00:14:50.633
是应该停止下来的

00:14:50.633 --> 00:14:53.233
需要有一个明确的标准给到它

00:14:53.333 --> 00:14:55.800
当然这个验收标准可以写在

00:14:55.800 --> 00:14:57.900
你一开始启动目标的时候

00:14:57.900 --> 00:15:00.400
你在写这个goal的时候就把它写进去

00:15:00.666 --> 00:15:01.933
第二个我觉得要重视的

00:15:01.933 --> 00:15:04.066
就是一个权限的边界

00:15:04.266 --> 00:15:06.133
特别是在企业中

00:15:06.133 --> 00:15:08.833
这些企业级的loop一定要有

00:15:09.066 --> 00:15:11.266
这个最小权限的原则

00:15:11.300 --> 00:15:13.866
到底这些东西是能不能改

00:15:13.866 --> 00:15:14.733
能不能删

00:15:14.866 --> 00:15:17.200
能不能访问特定的网络

00:15:17.200 --> 00:15:19.866
能不能自动地去支付API

00:15:19.933 --> 00:15:23.100
啊能不能去发这个呃消息发slack

00:15:23.400 --> 00:15:24.466
啊直接创建

00:15:24.466 --> 00:15:26.066
直接就合并完成了

00:15:26.066 --> 00:15:29.033
这些权限的边界一定要写清楚

00:15:29.066 --> 00:15:31.700
当然这个权限的边界的背后

00:15:31.700 --> 00:15:32.833
就是带来另外一个点

00:15:32.833 --> 00:15:35.100
就是这里的human review human gate

00:15:35.500 --> 00:15:37.433
什么时候超出这个

00:15:37.433 --> 00:15:39.533
特定的权限边界的时候

00:15:39.533 --> 00:15:40.733
人需要观察

00:15:40.733 --> 00:15:44.666
而哪些情况下是需要人工去介入

00:15:44.666 --> 00:15:46.133
这个loop需要暂停

00:15:46.133 --> 00:15:48.333
需要人来协助拍板的

00:15:48.333 --> 00:15:50.333
这个我认为也非常的重要

00:15:50.333 --> 00:15:53.533
就是权限边界和这个human gate human review

00:15:53.866 --> 00:15:55.733
是一个事情的两面

00:15:55.833 --> 00:15:56.466
另外一个呢

00:15:56.466 --> 00:15:58.033
就是可观察性

00:15:58.033 --> 00:15:59.666
这个概念我在其他的

00:15:59.666 --> 00:16:01.400
视频里面也讲解到

00:16:01.400 --> 00:16:04.233
就是可观察性的重要性在于说

00:16:04.233 --> 00:16:07.333
我们不仅要求结果的可观察性

00:16:07.333 --> 00:16:09.900
还需要Loop的整个的过程

00:16:10.233 --> 00:16:11.633
它是可观察的

00:16:11.633 --> 00:16:13.200
整个的loop的记录

00:16:13.200 --> 00:16:14.933
包括它的任务的拆解

00:16:15.033 --> 00:16:17.733
执行的动作过程都是可观察的

00:16:17.733 --> 00:16:20.833
这样它在闭环执行的时候

00:16:20.866 --> 00:16:24.100
才是能够基于这个审核

00:16:24.100 --> 00:16:26.400
对比的机制来不断的提升

00:16:26.400 --> 00:16:28.866
它最后执行任务的有效性的

00:16:28.866 --> 00:16:31.300
如果这期视频真的想让大家学到什么

00:16:31.300 --> 00:16:33.666
我想就是把Loop的思维

00:16:33.666 --> 00:16:36.033
运用到你每一次AI的运用

00:16:36.033 --> 00:16:37.533
你的每一个任务中

00:16:37.700 --> 00:16:41.900
Loop能够让AI成为你的真正的生产系统

00:16:42.200 --> 00:16:43.533
现在真正高级的玩家

00:16:43.533 --> 00:16:46.333
不再是写多漂亮多长的prompt

00:16:46.400 --> 00:16:50.133
而是把你的任务设计为一个可以循环

00:16:50.200 --> 00:16:53.700
可以迭代可以沉淀的生产机制的系统

00:16:53.700 --> 00:16:55.433
把你瞬间的灵感变成

00:16:55.433 --> 00:16:56.933
一个长效的工作机制

00:16:56.933 --> 00:16:59.333
把你单次的对话转向一个

00:16:59.333 --> 00:17:01.266
自动化复利的一个过程

00:17:01.266 --> 00:17:03.933
如果你觉得你对Loop的理解还不够

00:17:03.933 --> 00:17:06.466
可以把我前两期关于Loop的

00:17:06.466 --> 00:17:08.966
解读和实战拿出来看一看

00:17:09.033 --> 00:17:10.766
如果你是灵姐的粉丝

00:17:10.766 --> 00:17:14.033
我希望你能真正的学会Loop思维

00:17:14.100 --> 00:17:15.700
关于AI的实操应用

00:17:15.700 --> 00:17:17.433
你还有什么想聊的

00:17:17.533 --> 00:17:19.700
也欢迎在评论区留下你的想法

00:17:19.700 --> 00:17:21.266
如果觉得视频做的还不错

00:17:21.266 --> 00:17:22.733
欢迎给我点赞

00:17:22.766 --> 00:17:23.766
订阅我的频道

00:17:23.766 --> 00:17:25.133
打开你的小铃铛

00:17:25.133 --> 00:17:27.300
我们下期再见啦拜拜