Loop Engineering
AI 编程正从“单次手动提示（Prompter）”向“自动化循环设计（Loop Designer）”演进。
Source: 2026-06-17-x-x-com-gosailglobal-status-2066341302577340882-s-46（来源未公开）, 2026-06-20-xiaohongshu-xhslink-com-o-8GJI3rB6PT0（来源未公开）, 2026-06-24-x-x-com-0xcodez-status-2064374643729773029-s-46（来源未公开）, 2026-06-29-x-x-com-hanakoxbt-status-2065807526268920103-s-46（来源未公开）, 2026-06-29-xiaohongshu-xhslink-com-o-9V8xCcNLb4t（来源未公开）, 2026-06-29-xiaohongshu-xhslink-com-o-8c1fcm5zOEp（来源未公开） (Palantir 采购 Agent 实践)
1. 核心趋势
-
长时运行取代提示词 (Longer Runs over Smarter Prompts)：Kaize 指出，智能体的开发重点已从“编写更聪明的提示词（smarter prompts）”向“设计长时运行的自主循环（longer runs）”迁移。真正的技术门槛不再是“我该输入什么”，而是“智能体如何保持长时间的运行状态并解决未知”。 [来源：2026-07-07-x-x-com-0x_kaize-status-2073743517155774641-s-46（来源未公开）]
-
Boris Cherny (Claude Code 创作者) 的无提示理念：Boris Cherny 指出，在 AI 编程的最新演进中，人类开发者已经“不再写提示（prompts）了”。人类的真正工作变成了**“设计闭环 (Designing Loops)”**。在 Loop 设计中，人类是管理工人的经理，而传统的单次 Prompt 只是自己在做具体工作。如果你仍在手动复制错误、贴回对话、运行修改，你就是那个低效的 Loop 本体。 [来源：2026-07-01-x-x-com-elcopymaster-status-2071975894290248160-s-46（来源未公开）]
-
Prompter vs. Loop Designer：传统开发者手动输入 Prompt、等待、检查差异，效率受限。
-
Loop 框架：使用 LangGraph, AutoGen 等框架，将“代码生成-测试验证-Diff审查-错误修复”形成自动运转的闭环。
-
效率壁垒：掌握构建自动化循环（Loop 工程）的能力，是未来开发者的降维打击利器。
2. 循环的设计与局限
构成要素
要彻底移除开发中的“人类干预”，自动化循环必须包含两个要素：
- 触发器 (Trigger)：
- 手动触发（如手动输入命令行指令）。
- 定时触发（如每日夜间文档扫描）。
- 动作触发（如 PR 提交）。
- 目标 (Goal)：
- 可验证型 (Verifiable)：拥有确定性的验证路径与数学指标（例如“每页生产环境加载性能控制在 50 毫秒以内”）。
- 大模型裁判 (LLM-as-a-judge)：非确定性的质量标准，交由 LLM 自行评估（例如“重构代码直到架构清晰”、“自动补充遗漏的 logging 覆盖”）。
技术局限与警告
- Goal 设计困难：在非确定性的场景下，模型当裁判容易产生判断漂移。
- 不适用于前期大特性开发：由于不知 AI 的探索方向，无法做到对全新复杂系统的完整交付。
- 高额的 Token 预算：自运转循环会在短时间内消耗巨大算力和 Token，对预算敏感的开发环境需谨慎把控。
- 防止无限死循环：在 Agent 自主调用外部工具时，Harness 必须构建强有力的**“终点安全防护栏 (End Loop Guardrails)”**。如果没有明确的判定边界，Agent 在工具执行遇到意外阻碍时极易陷入盲目重试的无休止死循环中，导致 Token 快速耗尽或产生非预期的数据副作用。
3. 云端无监督运行与并行循环 (Boris Loops & Routines)
- Claude Code 的 /goal 与 /loop 指令：
/goal：针对拥有清晰终点（Verifiable goal）的任务。Claude 会自主开启任务推进循环，每步执行后自动调用另一独立的 Claude 实例作为裁判判断“是否达成目标”，不达标则生成下一步指令直到结束。/loop：针对周期性轮询与背景巡检（如“每早 30 分钟扫描一次收件箱并提炼任务”），支持设定时间心跳（如30m）。
- 状态文件 (State File) 的核心支柱作用：在自动化循环中，必须有一个持久化的状态文件来记录已完成的工作和当前进度。如果没有状态文件作为“上下文锚点”，每一次 Loop 的自动重启都会彻底洗牌、从零开始，极易发生偏航或死循环。 [来源：2026-07-01-x-x-com-elcopymaster-status-2071975894290248160-s-46（来源未公开）]
Boris 指出，为了让 AI 工程师真正提效，必须将其从单次交互式 Prompting 释放，升级为放置在云端服务器自动重复运行的循环：
- Routines (云端定时/事件例程)：脱离本地笔记本电脑，在云端 VPS 或服务器上配合定时任务（Cron）或 Webhook 触发 Routines。使 AI 智能体能够 24/7 在后台运行（如每 30 分钟轮询一次）。
- Parallel Loops (并行多线程循环)：在服务器上同时运行多条循环线来分摊日常重体力工作。一条循环专门监听 PR 状态并自动 rebase，一条专门局聚合生产环境异常并尝试编写 fix，另一条专门汇总每日用户反馈。
- 人在回路 (Human-in-the-Loop)：为了防范自动化失控，对涉及代码合并、大额资金或对外数据分发的步骤设置人工卡点（Approval Gate）。让 AI 跑完前 95% 的分析，人只做最后的 5% 风险决断。
4. 工业级决策闭环：Palantir 采购 Agent 落地实践
在非代码开发的大型复杂业务管理中，Loop 循环工程通过构建“人机协同公共本体 (Common Ontology)”同样能实现高度复杂的决策闭环：
- 统一本体关联 (Ontology)：将企业内部混乱的数据（如 PO 采购单、物料清单 BOM、交期日程、供应商数据库）进行本体化语义链接，为 Agent 提供统一的、面向物理调用的关系网络。
- 两阶段过滤与降噪 (Sizing)：在面临大规模物料变更（如网络设计微调引发 40,000 根多余线缆的级联变动）时，Agent 根据物理本体规则与兼容性检查（而非单纯文本 Diff），将变更划分为两类：一类是由 AI 极其确信可以自动合并的“自动接受堆栈”（大幅削减人工核对成本），另一类是存在冲突、需要人工复审的“待 Review 堆栈”。
- 多目标重调度与权衡：针对高危变更，Agent 结合各供应商 PO、各项目施工 schedules 和库存数据库进行交叉分析，提供多方案权衡推荐（例如推荐方案：追加 50 万美元购买新 switch 确保交付，同时 Agent 自动查找出另一个异地施工项目的 build 需求，将此项目多余的旧型 switch 直接调拨调配给后者，使综合总成本最低）。
- 决策判定沉淀与能力复利 (Ontology Compound)：每一次人类专家在待 Review 堆栈中所做出的采购取舍判断，都会自动 codify 并沉淀进本体数据库中。这种专家的商业判断力会发生“复利效应”，不断进化该系统内部所有 Agent 决策推荐的精度上限。
5. 循环工程实施前置测试 (4-Condition Test)
在开启自动化循环开发前，必须评估任务是否满足以下四个硬性指标，否则循环成本将远大于收益：
- 任务可重复 (Repetitive task)：任务必须是每周或定期重复发生的常规工作。对于单次性（one-off）任务，手动 Prompt 或一次性脚本更经济。
- 验证可自动化 (Automated verification)：必须有测试套件、类型检查器、代码规范校验器或构建链来自动判断是否出错。否则，人必须一直在电脑前审查 diff，失去了循环的意义。
- 环境可运行与调试 (Reproduction environment)：Agent 必须有高级开发工具，如获取错误日志、能够自主在沙盒中运行代码并重现 bug。没有运行环境，Agent 只能在黑暗中盲目迭代。
- Token 预算充足 (Token budget)：循环运行需要反复重读上下文、自我纠错和回溯，这会带来高额的 Token 消耗。
6. 自动化循环的五大核心积木 (Building Blocks)
- Automations (自动化驱动/心跳)：设定定时 cadences 或 lifecycle 事件钩子。
- Worktrees (多工作区并行隔离)：使用
git worktree开辟独立的物理工作目录和临时分支，彻底防止代码写入冲突。 - Skills (项目知识沉淀)：在
.agents/skills/<skill_name>/SKILL.md中写入开发规约，由 Agent 预读避免每次启动都重新推理基本上下文。 - Connectors (外部工具连接器)：基于 MCP 协议，让 Agent 能触及文件系统之外的工具（如 GitHub PR、Slack 警报）。
- Sub-agents (子智能体分工机制)：Maker（实现者）与 Checker（校验者）的分离，实现优化器-评估器（Evaluator-Optimizer）模式。
7. 2026年6月：行业共识时刻与五步循环框架
Source: 2026-07-07-x-x-com-0x_kaize-status-2073438517775003671-s-46（来源未公开）
2026年6月，三位工程师在彼此不知情的情况下，在数天内说出了几乎相同的话，标志着 Loop Engineering 成为行业共识：
- Peter Steinberger (OpenClaw 创建者)：发出两行帖子（8.9M 浏览）
- Boris Cherny：“我不再写 prompt 了，我有 loops 在运行，它们在帮我提示 Claude。”
- Addy Osmani：“Loop engineering 就是用系统来替代你作为提示者的角色。”
Osmani 进一步将循环从低到高分为四个抽象层：prompt → context → harness → loop。循环在最顶层，并新增三个动词：定时运行（timer）、派遣助手（spawn）、用今天的输出喂养明天（self-feed）。
每一个 Turn 的五步动作
“循环”≠“在原地转圈”。每一次 Turn 有 5 个具体动作，缺一不可：
| 步骤 | 名称 | 职责 |
|---|---|---|
| 1 | Discovery（发现） | 读取信息源，自己判断今天哪些值得做 |
| 2 | Handoff（交接） | 将任务分配给隔离的 worktree 中的 agent |
| 3 | Verification（验证） | 那个说”不行”的门——独立评估员判断是否达标 |
| 4 | Scheduling（调度） | 把今天的输出存入状态文件，喂给下一个 Turn |
| 5 | Token Management | 控制预算，防止无限扩张 |
验证阶段：结构性问题不能靠措辞解决
Anthropic工程师 Prithvi Rajasekaran 发现：让 agent 评估自己刚写的代码，它几乎永远会给自己打高分——不是因为模型蠢，而是结构性问题：上下文已充满”我为什么这么写”的自我辩护链，它看的不是结果，而是结果背后的论证。
解法（Maker-Checker 分离）：调一个全新的 agent，使用完全不同的 prompt（最好是不同的模型），从零开始看代码。它不带任何自我辩护链。
- 默认立场：ASSUME BROKEN（被证明前默认为坏）
- 评判行为不评判意图（运行测试+截图，而非”代码看上去没问题”）
- 拒绝时必须列出拒绝理由
- Stripe 经验：更小的模型 + 严格确定性门控，胜过最大的模型 + 宽松评估
三种循环疾病
| 疾病名 | 症状 | 修复 |
|---|---|---|
| Blind Loop（盲目循环） | 你仍在每天早上手动分配任务；循环从不让你”惊喜”，只做你已知要做的事 | 把 Judge（判断什么值得做）放进 SKILL.md，让循环自己选 |
| Tangled Loop（缠绕循环） | 并行 agent 写同一个文件，merge 时变成考古现场 | 每个任务一个独立 git worktree，agent 间物理隔离 |
| Nodding Loop（点头循环） | 循环数百次从未说过”不行”——在任何真实工作中这统计上不可能 | 独立评估员；评估员必须实际运行、点击、验证，而不是”感觉还好” |
8. PROGRESS.md 模式、自主性阶梯与循环复合
Source: 2026-06-30-x-x-com-mikenevermiss-status-2066401066518802637-s-46（来源未公开）
PROGRESS.md 命名规范
状态文件（State File）的规范命名是 PROGRESS.md 或 STATE.md，放置在所有循环迭代均可读写的位置。文件内容结构：
- 已完成内容（last run done）
- 进行中内容（in progress）
- 阻塞项（blocked）
- 下一步尝试（try next）
保持文件简短——Agent 要读 2000 行的 memory file，比没有 memory file 更糟糕。
这与 Section 3 中”状态文件的核心支柱作用”互为印证，并提供了规范化的命名与结构约定。
Boris Cherny 自主性阶梯（Autonomy Ladder）
Boris Cherny 提出了四级人机协作模型，用于确定循环投产前的信任层级：
| 级别 | 模式 | 描述 |
|---|---|---|
| Level 1 | Suggest Only | 循环只提出建议，人决定是否执行 |
| Level 2 | Draft | 循环生成完整草稿，由人应用 |
| Level 3 | Apply + Approve | 循环自动应用低风险变更，发布/合并前需人工审批 |
| Level 4 | Full Autonomy | 循环完整执行并留下审计日志，无需人工干预 |
操作原则：每个新循环都从 Level 1 或 Level 2 开始，运行一周后审查产出，确认无误后才升至下一级。Level 4 是挣来的（earned），不是假定的（assumed）。
循环产出分两类处理：
- 发现问题 → 进入分类收件箱（triage inbox）供人工审查
- 未发现问题 → 静默归档，绝不要求人工打开确认”什么都没发生”
Token 预检公式
在任何循环进入无监督运行之前，必须先手动执行 3-5 次迭代，测量每次的 Token 消耗，再计算最坏情况成本：
每次 Run 的最坏成本 = 每次迭代 Token × 最大迭代数
每日最坏成本 = 每次 Run 成本 × 每日触发次数
同时为可执行 shell 命令建立白名单，只允许循环真正需要的命令（如 npm, git, ls, cat），避免无限制 shell 权限成为安全问题。
循环复合效应（Compounding Loops）
单个循环之间可以形成数据流水线：
- 第一个循环（如每日 triage 循环）将结果写入共享状态文件
- 第二个循环读取该状态文件，挑选优先级最高的任务执行
- 两个循环各自独立运作，但合在一起形成”发现 → 行动”的自动化管道
此外，Skills 文件开始产生复利：一旦为某类任务写好 SKILL.md，所有后续访问该类任务的循环都自动复用，无需重新解释基本上下文。
9. 关联概念
- agentic-systems — 智能体系统演进
- harness-in-agentic-systems — 智能体分层记忆治理
- sdlc-bottleneck-in-ai — AI 时代的开发工具链瓶颈
- five-step-method — 乔布斯流程科学质疑
- bot-traffic-explosion — 互联网 Bot 流量海啸
- llm-training-pipeline — LLM 五阶段训练流水线
10. 吴恩达 (Andrew Ng) 论 “Loop Engineering” (2026年7月)
人工智能先驱吴恩达（Andrew Ng）在 2026 年 7 月撰文指出，“Loop engineering（循环工程）”正成为 AI 行业最核心的技术热词：
- 行业风向标：继 Boris Cherny (Claude Code 创作者) 和 Peter Steinberger (OpenClaw 创作者) 的论点在社交媒体上病毒式传播后，吴恩达为 Loop Engineering 正式定调。
- 自主迭代的基石：吴恩达强调，自动化循环（Loops）现在是我们引导 AI 智能体（AI Agents）在没有人类频繁干预下、进行长时间持续自主迭代以构建复杂软件系统的最关键路径与机制。这一范式已彻底超越了单次 Prompt 调优的落后模式。
Source: 2026-07-14-x-x-com-AndrewYNg-status-2071988145667928442-s-20（来源未公开）