20260704-03 | Loop Engineering 火了:AI Agent 的杠杆,正在从 Prompt 移到 Loop
來源:Youtube | 建立:2026-07-04T18:23:43 | HTML:2026-07-04T18:25:42
開啟原始影片 note.md transcript.txt transcript.vtt

影片筆記:Loop Engineering 火了:AI Agent 的杠杆,正在从 Prompt 移到 Loop

YouTube 影片框會固定在左上方;點擊右側逐字稿時間戳可跳到對應時間。

一句話總結

隨著 AI Coding Agent(如 Claude Code、Codex)能力的提升,開發重點正從單次的「提示詞工程(Prompt Engineering)」轉向設計自我迭代與可審計的「Loop 工程(Loop Engineering)」,透過雙執行機制、模組化架構及人工閘口,實現 Agent 的企業級可控與自動化複利。

核心重點

趨勢轉變:矽谷熱門趨勢顯示,開發者應從主動提示 Coding Agent 轉向設計引導 Agent 的循環(Loop)。這是由於 Agent 具備長任務執行能力、工具調用增強,以及企業對可重複、可審計工作流的需求。

Loop 的核心機制

Loop Engineering 架構

實戰關鍵要素

詳細大綱

I. Loop 概念的興起與背景

Coding Agent(如 Claude Code, Codex)具備處理長任務能力。

模型調用工具(插件、API)能力增強,更新頻繁。

企業端關注可重複、可測試、可審計的 Agent 工作流。

真實企業任務中,Token 成本、失敗率及權限風險成為問題,需將 Agent 升級為可控的 Loop。

II. Agent Loop 的核心機制

提示詞工程(Prompt Engineering):提升模型對單次輸入的理解力。

工作流工程(Workflow Engineering) / 上下文工程(Context Engineering):解決任務流串聯與大項目背景理解。

Harness 工程(Harness Engineering):解決運行層問題,搭建執行環境、工具反饋、權限框架與驗證信號(CC 與 Codex 在此層表現較好)。

Loop 工程(Loop Engineering):設計 Agent 自我演進的閉環,系統替代人工進行提示、檢查與糾偏。

III. Loop Engineering 的架構解析(基於 Addy 博客)

自動化(Automation)

工作樹(Worktree)

技能(Skill)

連接器(Connector)

子代理(Sub Agents)

狀態記憶(Memory)

IV. 講者補充的實戰關鍵要素

V. 總結與呼籲

工具 / 模型 / 名詞整理

操作流程整理

啟動與自動化

環境隔離與準備

執行與工具調用

雙執行與反思

權限檢查與人工介入

記憶沉澱與迭代

可觀察性監控

值得注意的限制或風險

逐字稿辨識疑點

可延伸追問

逐字稿時間軸

右側可一路往下捲;左側影片框會固定。點擊時間戳會讓左側影片跳到對應秒數。

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: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: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: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: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: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: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: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.933 → 00:07:55.500
当然这里是数字员工
00:07:55.533 → 00:07:58.600
他就可以持续的可靠的可控
00:07:58.600 → 00:08:01.366
的在这个系统里面去运行
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.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: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: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: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: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:07.700 → 00:11:10.833
我可以通过Codex去收取和回复邮箱
00:11:10.833 → 00:11:14.000
也可以在这里用Codex来剪辑视频生成MV
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: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: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: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.933 → 00:13:15.466
所以你要定期的去写入记忆
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: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: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: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: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: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: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
我们下期再见啦拜拜