文档(金鹏): 2026-08-28 章节 9 篇文章摘要归档

按主题分三组归档：Agent 工程纵深（经验治理/循环工程/
Token 成本治理/溯源生成）、最弱环节定律（推理链窃取/
GLM-5.3-Flash 开源）、人机共进（意志稀缺/数字员工化/
大学之问）；每组配 4K 题图与 160x90 缩略图共 3 组，
昇腾 WAIC 纯图片一文无法文本化按先例未收录

知识/微信公众平台/吕昊俣/2026-08-27_对Loop_Engineering的思考.md

@@ -0,0 +1,255 @@
+# 对Loop Engineering的思考
+
+> **来源**：微信公众平台（腾讯云开发者）  
+> **作者**：吕昊俣  
+> **发布日期**：2026-08-27  
+> **原文链接**：https://mp.weixin.qq.com/s/g3HtSeJfKfjtqDG4rPTpiw
+
+---
+
+OpenClaw 的创始人在 6月8日 凌晨 2:58 发布推文： Here's your monthly reminder that you shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents"。简单翻译一下就是：我们要设计一个循环去代替不停地Prompt，把人从流程中拔出来。loop是不是又是AI圈造了一个新词，不清楚，但是确实给我们看待"问题"提供了一个新的视角。
+
+## 01
+
+范式迁移：从 Harness 到 Loop 再到Graph Engineering
+
+  __1.1 五代工程演进__
+
+从 2022 到 2026，AI 辅助编程经历了清晰的开发__模式的转移__。
+
+工程师的核心工作，逐渐从__"直接写业务代码"__转向__"设计系统，并让系统生成代码"__的阶段。
+
+![图片](https://mmbiz.qpic.cn/mmbiz_png/ZRhjO8xAWr7ibViczAfdicicAUxnpN9LVxeicl0w7KLlQibvsHLLZChbPqelo6nic3t7JUYbOZibLjXJSHAic7DTXpKVM1SFUdfpXicooIrSydXicvic5lg/640?wx_fmt=png&from=appmsg&tp=webp&wxfrom=5&wx_lazy=1#imgIndex=0)
+
+每一代都是一次__精进__：
+
+1. __Prompt Engineering__（2023）解决了"怎么问，模型才答得好"，把质量押在一次提示词上。缺点是：答错了没有自动纠偏，只能人工重来。
+2. __Context Engineering__（2025）解决了"模型缺背景、答不准"，上下文管理让信息更充分。缺点是：只有信息、没有手脚，缺标准化执行环境，也缺验证闭环。
+3. __Harness Engineering__（2026 2月）解决了、"单次执行不可控、不可信"，生产级运行外壳让 Agent 能安全、可控、可验证地跑通一次。缺点是：仍要人触发、让人盯，人成了生产节点的最大瓶颈。
+4. __Loop Engineering__（2026 6月）解决了"__靠人盯"，自动化调度实现最大限度的无人值守，但仍面临着成本失控的问题。
+5. __Graph Engineering__（2026 7月）解决了"Loop间的编排、协同、调度等问题"，构建起工程级复杂 AI 任务系统。
+
+  __1.2 它们的结构关系：层层依赖 逐步递进__
+
+每一次的演进，__并不是一次替代__，而是建立在上一代的能力之上。
+
+就拿Harness和Loop的关系来说，创始人Addy Osmani 给出了精准的概括：
+
+__Harness 是 AI 代理的受控运行环境；Loop 是在这个环境之上，叠加了自驱动能力的持续执行流程。__
+
+Harness 是地基，Loop 是上层调度，没有Harness，Loop 则是无源之水。         
+
+而把它们结合在一起看，更为直观明了。
+
+  __1.3 从技术Loop到产品Loop__
+
+跳出单纯的技术视角，__吴恩达__则给出了不同的__"取景框"__，把 Loop 的涉众范围扩大去思考。
+
+（见：https://www.deeplearning.ai/the-batch/three-key-loops-for-building-great-software）
+
+文中给出了三个环：__技术->产品->用户，__它们__三层嵌套、不同速度、层层驱动__。
+
+__技术 Loop__解决的是 "系统会不会收敛、会不会停、会不会认错"；
+
+__产品 Loop__ 解决的是 "这个闭环是否持续创造用户价值、是否值得继续放大、是否能形成长期增长飞轮"；
+
+__用户Loop__则反应了用户对产品的一种__"情绪"，最终将以__某种形式__回到产品本身。
+
+  __1.4 Loop的工程基础 : 控制论__
+
+大约160年前，英国通过了《红旗法案》，此法案要求机动车__前必须有人持红旗引导__，以保护人的安全，是不是有点匪夷所思，但160年后的今天，在AI编程领域，__历史在重演__，人就站在AI的前头，时时刻刻盯着。一个字 : 累。
+
+从原理上看，LLM是一个概率模型，本质上，它就是在：__猜__。
+
+虽是猜，但有人会说，现在猜的已经很准了，正确率接近__90%__。
+
+是的，90%听起来很不错，但是，事实上可能很糟糕，因为，软件工程一定会使用__分治的方法__解决复杂问题，顺其自然的，一个复杂任务就变成了N多子任务的叠加，那么就变成了一个指数运算，仅仅六次后，概率就接近50%， 这不是就是__抛硬币吗__！                 
+
+为了解决这个问题，于是乎，很自然地就想，有没有一种机制可以__修正这个损失概率？__有，这种机制就是控制论。
+
+而控制论的思想，早从__VibeCoding__时，我们就在每天下意识的使用它。
+
+只是这个__系统=我+AI__，比如在构建Prompt的过程：
+
+而控制论的本质一句话就可以说明白__：通过负反馈机制去收敛目标函数。__说白了，Loop Engineering就是控制论在AI领域的一次落地应用。
+
+  __1.5 控制论四大公理__
+
+于是乎，最近又翻开了大学时候没有好好上的课程：__《反馈控制系统设计》__，温习了一下控制论中最基本的几点思想：
+
+1. __构建负反馈闭环__
+2. __可观测性__
+3. __可控性约束__
+4. __离散迭代纠偏__
+
+而这些点，更好的帮助我去理解Loop Engineering，我会清晰的看到，它们__一一对应，同根同源__。
+
+映射如下：
+
+## 02
+
+从"写Prompt" 到 "设计Loop"
+
+  __2.1 回到问题本身：要设计一个"无人值守"的系统，咋做？__
+
+我常常有这样的期待：一个任务，在晚上睡觉前 设计好，我睡觉，他干活，早上起来，完事。但现实往往是早上起来一看，什么东西！借助Loop的思维，我们如何重新思考这个问题？让AI可以在一定的成本下 完成任务。我想这里关键的实践路径是：__从小闭环做起，不断扩展边界__
+
+在设计一个Loop的时候，我们往往会陷入到一个惯性思维里：
+
+一上来就像做__一个全自动开发、全自动修复__的万能循环，结果往往差强人意。而比较实现的做法是：
+
+__先跑通一个最小可收敛闭环，再逐步放大自治边界，并从中建立起闭环和闭环之间的联系。把小闭环跑通，才有资格谈大闭环，大循环是在一个个小循环上长出来的。__
+
+而不管是大小闭环，最核心的是想清楚下面几个问题：
+
+1. 如何定义__问题__？
+2. 如何定义__开始__？
+3. 如何设计__反馈__？
+4. 如何定义__结束__？
+
+__"设计反馈"__的背后是说，你需要设计一个__机制__，让模型真的会__说"不"__，这种"不" 并不是在提示词里一些拒绝意图的Prompt，这种看似在否定，但其实还是在肯定，而这种"不"是基于__某种不可否认的事实__，而从这种不，就天然形成了最关键的__"负反馈"__链路。
+
+__"如何结束"__的背后是说，你需要设计一个__机制__，保证不会__无限循环__，看看你的Token账单，你知道我在说什么吧。
+
+按我们带着以上的问题，看看官方的__参考答案__如何。
+
+  __2.2 五大组件+记忆模块__
+
+在《Loop Engineering 循环工程》（https://addyosmani.com/blog/loop-engineering/）一文中，详细讲解了这几个部分，如下图所示：
+
+1. __一个唤醒机制： Automations__
+
+   以往和AI协作，__是我推一下，它动一下__。讲道理，很累人。一个唤醒机制就保证了，人不用再去__"盯着，去喊"，__这是整套自动化系统运行的前提。
+2. __安全独立的沙箱环境： Worktrees__
+
+   多Agent协同必然会变成一种趋势，为每个任务分配独立代码工作区，就杜绝文件覆盖、环境互相污染等问题。
+3. __对抗性思维：Maker-Checker 双校验模式__
+
+   Maker-Checker模式本质上就是保证了：__让模型不要自说自话__，采用__"一方做、一方质疑"__的制衡思路，结合Skills的经验库。二者互补修正，大幅提升输出质量。
+4. __通信模式：Connectors__
+
+   作为一种系统间的沟通手段，比如MCP、Functioncall等等，就是为了打通所有的上下游系统，把系统链接起来，
+5. __长任务记忆系统： Memory__
+
+   防止任务"失忆"。长流程任务没法全塞进 AI 有限上下文里，记忆组件会全程记录任务进度、过往尝试，防止多轮迭代后系统忘记目标、丢失执行记录。
+
+## 03
+
+如何让模型说"不"？
+
+  __3.1 方法一：践行TDD！！！__
+
+让模型说"不"，最关键就是__有硬性__的__不可怀疑__的证据。
+
+而在软件工程中，测试不过就是铁的依据。
+
+因此，AI时代，我们需要重新思考：__TDD的价值以及如何实践？__
+
+而从Loop的视角重新看TDD，我们会发现：
+
+TDD的价值并不是多写几个测试用例，而是，__可以把需求翻译成反馈信号__。
+
+这做到这里的前提，就是：落实TDD__左移__。
+
+多少次实践中，我也常常会等到开发完之后，再给AI补一句：__请补充测试用例。__
+
+而这种习以为常的习惯，其实已经__偏离__的TDD的本质。
+
+所以，我们有必要在回看一下TDD的理念：__先定标准、后做开发、以结果反向驱动过程__。
+
+构建出一个最小的Loop__：Red-Green-Refactor__
+
+- __红__：先编写失败测试用例，定义"__什么是错、什么是对__"的终态标准。
+- __绿__：迭代编写代码，直到全部测试用例通过。
+- __重构__：在测试兜底前提下优化代码，保证质量不退化。
+
+以往这个循环为什么玩不起来，因为，这个循环的控制者是人，但是到了AI时代，__控制权交给Agent__，这个结构没有发生变化，但是你变轻松了。
+
+在分布式系统中，每个服务都是全局中的一个局部，针对局部的一个模块，测试会有三个维度，也分别对应着三个环：
+
+1、__单元测试环__：看似容易，其实不容器做到，这里难点在于：单元测试其实是和函数耦合的，也就是说，需要先定义好骨架，顾开发的流程应该是：__定义桩函数-> 写测试用例->写实现 。__
+
+2、__接口测试环__：需要可以让AI可以自己发包，以及收日志，这样就可以在服务维度建立Loop。
+
+3、__流程测试环__：以功能为单位进行验证，因为它更加上层，一般都是用来回归验证，如何构建这个环，以便AI可以站在全局修复问题，仍然值得思考。
+
+  __3.1.1 反向思考：TDD不能做什么？__
+
+虽然TDD好，但，也不是万能药，我们需要清晰的知道它的边界：
+
+它__适合__：
+
+- 明确的业务规则
+- API的输入、输出行为
+- 数据转换和边界条件
+- 回归Bug修复
+- 编译、lint、类型检查
+
+它__不适合__：
+
+- 纯体验问题
+- 架构品味
+- 产品决策
+
+知道了__适不适合__，就可以更好的思考，它__应该被放在哪里__？
+
+在开发过程中，我们都应该反问自己：__这个功能是否可以被测试表达？这部分如何变成Loop？__
+
+  __3.1.2 以"规则"为核心的构建测试用例__
+
+上面我们主要讲了如何构建环？下面来讲讲如何设计测试用例。
+
+测试用例的设计非常重要！！！因为一旦设计有误，所有AI生成的代码都是在错误的基础上改动代码，结果怎么改都是错。
+
+而这里的解决思路是：__以需求为出发点，构建规则集合。__
+
+  __3.2 方法二： 证据胜于一切，建立证据链__
+
+Maker-Checker双校验架构听起来是很不错的，但是细想，一个问题很自然的就出来了：__Checker凭什么就说Maker做的不行呢？是靠猜吗？肯定不是。__
+
+这很像是一场辩论赛，反方选手说你不行，那不能靠感觉，要靠依据，那依据是什么呢？没事，是__证据链__。
+
+Maker 通过事实（产品规则）推演，输出落地代码。
+
+Cherker 使用__证据链__进行追溯，Review代码。
+
+而这种设计，本质上就是__对抗性思维__的一种极致体现！
+
+  __3.3 方法三：预算思维__
+
+在设计一个Loop时，不仅需要考虑技术实现，更需要考虑一个很现实的点：__预算__
+
+预算收紧的今天，谁都不想，月初额度就用了一半！所以需要有一些策略应对：
+
+__策略一：模型选择__
+
+首先，预算思维的本质是：__资源倾斜 ，背后的问题是：什么样的任务我愿意投入更多的资源？__
+
+针对高价值的任务，用聪明的模型，而针对低价值的重复任务，绝不用贵的模型。
+
+选择不合适的模型，成本差距巨大，Opus的输出成本是GLM4-Flash的__180倍__。
+
+__策略二：设置退出机制__
+
+设置退出机制就是针对每个任务要设置一个阈值上线，常见的有：
+
+1. 最大的步骤限制
+2. 预算熔断机制
+
+__策略三：上下文压缩__
+
+面对长周期 Agent 任务的成本问题，上下文压缩，是一个常见的方式，一般的做法是：用廉价模型对全量上下文反复重压缩，但这种操作，往往会__实则会让核心规则持续稀释、过程噪音不断累积__。最终导致任务跑偏、全链路已经投入的 Token 全部作废。
+
+而这里我个人的一些应对思路是：高密度核心规则全程人为把控（不参与压缩）+增量信息克制压缩
+
+把人的强判断力用在不可出错的核心约束上，把模型的压缩能力用在可损耗的过程信息上，从根源上避免压缩噪音污染核心逻辑。
+
+## 04
+
+写在最后
+
+Loop不是一个技术框架，而是一种思维模式。让我们更好的去思考：人和AI如何协作完成一个Loop？把人从Loop中更多的环节拔出来，把注意力真正的还给人自己。
+
+-End-
+
+原创作者｜吕昊俣

知识/微信公众平台/吕昊俣/2026-08-27_对Loop_Engineering的思考_摘要.md

@@ -0,0 +1,76 @@
+# 📊 文章摘要：对Loop Engineering的思考
+
+> **原文**：[2026-08-27_对Loop_Engineering的思考](./2026-08-27_对Loop_Engineering的思考.md)
+> **原文链接**：https://mp.weixin.qq.com/s/g3HtSeJfKfjtqDG4rPTpiw
+> **来源**：微信公众平台（腾讯云开发者）
+> **作者**：吕昊俣
+> **发布日期**：2026-08-27
+> **摘要日期**：2026-08-27
+> **价值评级**：⭐⭐⭐ 高
+
+---
+
+## 核心命题
+
+> **循环工程** — AI 辅助编程的范式正从"写 Prompt"迁移到"设计 Loop"：用控制论的负反馈闭环驯服 LLM 的概率性错误，让人从流程的每个环节中拔出来，实现无人值守的自动收敛。
+
+---
+
+## 文章概要
+
+本文提出 AI 辅助编程的五代演进框架（Prompt→Context→Harness→Loop→Graph Engineering），指出当前正处于 Loop Engineering 阶段——解决 Harness 时代"仍要人盯"的瓶颈。文章的独特贡献是把 Loop Engineering 追溯到控制论根基：LLM 单次 90% 的正确率在分治法下指数衰减（六次嵌套后接近抛硬币），唯一解药是负反馈机制。作者给出可操作的落地路径——设计 Loop 的四问（定义问题/开始/反馈/结束）、让模型说"不"的三种方法（TDD 反馈信号、证据链、预算思维），以及 Addy Osmani 的五大组件参考架构（Automations/Worktrees/Maker-Checker/Connectors/Memory）。价值在于提供了从工程哲学到具体实践的完整链条，局限是缺乏自己的量化落地数据，五代演进的分期也带有作者的主观建构。
+
+---
+
+## 关键要点
+
+1. **五代工程演进层层依赖而非替代** — Prompt（2023）→Context（2025）→Harness（2026.2）→Loop（2026.6）→Graph（2026.7），每一代解决上一代遗留瓶颈；Harness 是受控运行环境（地基），Loop 是其上的自驱动持续执行流程（上层调度）。 `[分类: 共识]`
+2. **概率正确率的指数衰减是 Loop 的第一性动因** — 单步 90% 正确率经分治法分解为 N 个子任务后指数衰减，六次后接近 50%；这不是模型不行，而是软件工程结构放大了概率损失，需要控制论修正。 `[分类: 范式突破]`
+3. **控制论四大公理与 Loop 一一同构** — 构建负反馈闭环、可观测性、可控性约束、离散迭代纠偏，与 Loop Engineering 的反馈设计、监控、沙箱、迭代修正一一对应；"通过负反馈机制去收敛目标函数"是本质概括。 `[分类: 共识]`
+4. **从小闭环做起** — 先跑通最小可收敛闭环，再逐步放大自治边界；大循环是在一个个小循环上长出来的。 `[分类: 共识]`
+5. **设计反馈 = 让模型真的会说"不"** — 基于不可否认的事实（测试失败、证据链）而非提示词里的拒绝意图；提示词里的"不"看似否定实则肯定。 `[分类: 共识]`
+6. **TDD 的 Loop 视角重估** — TDD 的价值不是多写测试，而是把需求翻译成反馈信号；控制权从人交给 Agent 后，Red-Green-Refactor 循环的结构不变但人变轻松；需知其边界（不适合体验、品味、产品决策）。 `[分类: 共识]`
+7. **Checker 凭证据链质疑 Maker** — 对抗性双校验中质疑方不能靠猜，要靠产品规则推演与证据链追溯的对抗。 `[分类: 共识]`
+8. **预算思维三策略** — 模型分级（Opus 输出成本是 GLM4-Flash 的 180 倍）、退出机制（步骤上限+预算熔断）、上下文压缩（核心规则人为把控不参与压缩，过程信息克制压缩）。 `[分类: 共识]`
+
+---
+
+## 批判性分析
+
+### 假设前提
+
+作者默认：(1) 五代演进是真实规律而非事后叙事（时间标注精确到月，但 Graph Engineering 2026.7 才出现即宣称"解决了 Loop 编排问题"，验证期过短）；(2) 控制论框架足以刻画 LLM 系统的反馈（LLM 的"负反馈"依赖语义判断而非物理测量，噪声特性不同）；(3) TDD/证据链在真实项目中可覆盖足够的反馈面。
+
+### 论据与逻辑
+
+主体是框架整合与推演：引用 Addy Osmani 的推文与博文、吴恩达的三层 Loop、控制论教材，属于"站在权威上的综合"而非一手实验。90%→50% 的指数衰减算术正确且有力，但真实 Agent 任务并非纯串联，含并行、重试、回滚等结构，衰减幅度会被高估。上下文压缩"核心规则人为把控"的建议是作者个人经验，未给出验证。
+
+### 边界与局限
+
+适用于代码类、可测试表达的任务闭环；对探索性任务（调研、创作）反馈信号难以客观化，Loop 设计失效。全文无落地数据支撑，五大组件仅为官方参考架构转述。控制论映射虽有启发性，但 LLM 反馈回路存在延迟不可控、信号不可复现等超出经典控制论假设的特性。
+
+---
+
+## 可引用金句
+
+> "Harness 是 AI 代理的受控运行环境；Loop 是在这个环境之上，叠加了自驱动能力的持续执行流程。"
+
+> "90%听起来很不错，但是……仅仅六次后，概率就接近50%，这不就是抛硬币吗！"
+
+> "控制论的本质一句话就可以说明白：通过负反馈机制去收敛目标函数。"
+
+> "把小闭环跑通，才有资格谈大闭环，大循环是在一个个小循环上长出来的。"
+
+> "这种'不'是基于某种不可否认的事实，而从这种不，就天然形成了最关键的'负反馈'链路。"
+
+---
+
+## 总体评价
+
+**亮点**：五代演进框架为分散的概念（Prompt/Context/Harness/Loop/Graph）建立了清晰的结构关系；控制论溯源赋予 Loop Engineering 理论合法性，指数衰减论证直观有力；"让模型说不"三法（TDD/证据链/预算）可直接操作。
+
+**不足**：无作者自己的落地数据，全篇为文献综合与思辨；五代分期时间线（精确到月）主观性强；控制论映射停留在类比层面，未讨论 LLM 反馈与物理反馈的本质差异。
+
+**适用场景**：向团队解释"为什么要从提示工程转向循环工程"的框架性材料；设计自动化开发闭环（CI 中的 Agent、夜间无人值守任务）时的检查清单；预算治理策略（模型分级、熔断、压缩）的直接参考。
+
+**关联建议**：与 2026-08-20《从 OpenCode 升级到 V2，我们看到上下文工程与驾驭工程的三个趋势》衔接——本文的五代演进是该文"驾驭工程"叙事的细化；与同批《靠这10个优化点，我们把Multi-Agent工作流成本降了50%以上》互补：一文讲 Loop 的预算思维，一文给出成本的工程实测；TDD 部分可与 superpowers:test-driven-development skill 实践互证。