发帖
雷达卡
AI Coding 圈又现新词：Loop Engineering。来自于 Addy Osmani 在 2026 年 6 月 7 日发的同名文章。
Addy 长期在 Google Chrome 负责开发者体验相关工作，最近也在写很多关于 Google Cloud、Gemini 和 AI Agent 工程化的文章。他这篇文章引用了两个信号：Peter Steinberger 在 X 上那句别再手写 prompt，应该设计会提示 agent 的 loops；Boris Cherny 在 Claude Code 访谈整理稿里说，自己的工作已经从提示 Claude，转成写自动运行的 loops。
Addy 做的事，是把这两个信号整理成一个工程框架：人退出持续 prompt agent 的位置，转去设计一个系统，让系统发现工作、分派任务、检查结果、记录状态，再决定下一步。
这个说法听起来很容易被误解。很多人会下意识把 loop 理解成 cron，把 prompt 每 5 分钟跑一次。真按这个方向做，成本会涨，风险也会涨，结果只得到一个更会重复犯错的 Agent。
我更愿意把 Loop Engineering 理解成 AI Coding 的控制面。它关心的重点不在 Agent 跑了几轮，重点在每一轮有没有目标、证据、边界和停止条件。
从 Prompt 到 Loop
这条线往回看，其实是 AI Coding 抽象层级连续上移。
Prompt Engineering 解决的是单次调用怎么说清楚。角色设定、输出格式、few-shot 示例、语气和约束，都属于这个阶段。人在旁边逐轮驾驶，模型答一次，人判断一次。
Context Engineering 解决的是模型该看什么。RAG、repo map、AGENTS.md、memory、progress file、skills progressive disclosure，都在把正确材料送进上下文。问题也很明显：材料给够了，模型依然可能跑偏。
Harness Engineering 解决的是 Agent 怎么在工程环境里可靠行动。Addy 在 4 月那篇《Agent Harness Engineering》里把 harness 说成模型外面的一整套脚手架：prompt、tools、context policy、hooks、sandbox、subagents、feedback loops、recovery paths。这个阶段开始把模型放进一个有工具、有权限、有反馈的运行时里。
Loop Engineering 再往上一层。Harness 让单个 Agent 能行动，Loop 让一组 Agent 或自动化任务持续发现工作、分派工作、验证工作、沉淀状态。Addy 说它位于 harness 上一层，我觉得这个说法很准。
Loop 到底是什么
Addy 在原文里拆了六个 primitive：automations、worktrees、skills、plugins/connectors、subagents 和 state。它们放在一起，才像一个能持续工作的 loop。
Claude Code 现在已经把 /loop 写进官方 scheduled tasks 文档。你可以用自然语言描述一个任务：每 5 分钟检查我的 PR 构建，如果失败就读日志并修复。也可以直接用 /loop 命令设置 interval 和 expiry。
Developers Digest 那篇文章把它和外部 cron 做了一个很直接的对比：外部 cron 每次调用 claude -p 都是冷启动。没有上一轮记忆，不知道发生了什么变化，也没有同一个 MCP 连接和工具上下文。
Claude Code 的 loop 活在当前 session 里。它继承上下文、工具权限、MCP、skills，也能基于上一轮结果继续做判断。官方文档还提到一种动态模式：如果你省略固定 interval，Claude 可以根据当前观察到的状态决定下次什么时候醒来。
Codex 这边也有相似形状：Automations 负责定时发现和 triage，/goal 负责 run-until-done，worktree 负责隔离并行任务，skills 负责沉淀项目知识，connectors 负责接入外部系统。工具名字不同，架构形状已经很接近。
cron 只回答什么时候执行。loop 要回答看到什么状态后，下一步该做什么。
Harness 控制面
Loop 和 Harness 的关系，是这次最值得补的一块。
Harness 是 Agent 的运行环境。它把一个模型包进工具、上下文、权限、状态、hooks、sandbox、日志和恢复路径里，让模型有能力对真实工程环境行动。
Loop 是 harness 之上的持续控制流程。它决定什么时候启动 Agent，分派给哪个 Agent，怎么隔离并行任务，读什么外部状态，用什么标准验收，什么时候停止。
Martin Fowler 把 coding agent harness 拆成 guides 和 sensors。Guides 是行动前的前馈控制，比如规则、技能、架构文档、上下文注入。Sensors 是行动后的反馈控制，比如测试、lint、typecheck、浏览器回归、日志、静态分析。
Anthropic 的长时应用 harness 也走这个方向。它把任务拆成 planner、generator、evaluator。Planner 把需求扩展成可验收的 contract，generator 负责实现，evaluator 用真实环境检查页面、API、数据库状态，再把失败项反馈回来。
这张图是我对控制面的拆法：用户目标在最上层，下面是规划器、执行 Agent、工具层、传感器和状态层。右边的 hook 拦截生命周期，在工具调用前、工具调用后、会话准备停止时做决策。
把两者放在一起看，边界会清楚很多。
Harness 关注单次行动的可靠性：工具是否合适、上下文是否干净、危险命令是否会被拦截、测试失败能否反馈给模型、工作区是否隔离。
Loop 关注持续推进的可靠性：是否有新任务需要处理、是否该继续等待外部状态、是否该 spawn helper、是否该进入下一轮、是否该把结果写回 issue、Linear、progress file 或 triage inbox。
没有 harness，loop 只是反复调用模型。没有 loop，harness 仍然需要人持续点火、分派、验收。
这里有个关键变化：完成不能只靠执行者自报。
Agent 很容易说自己已经修好了。但工程系统要看的东西更硬：测试有没有过，CI 有没有绿，截图有没有变化，日志里错误有没有消失，性能有没有退化，diff 有没有超出范围。
如果这些信号不存在，loop 只会放大模型的自信。
Loop 不是 Cron
还有个误会就是把 loop 当成 cron 的 AI 版本。
Cron 适合固定机械任务。比如每天 9 点跑脚本、每小时同步一次文件、每晚生成报表。它不需要理解上下文。
GitHub Actions 适合云端可靠任务。比如 CI/CD、PR 检查、定时安全扫描。它有日志、有权限边界，也能在机器关机后继续运行。
Loop 更适合工作中的临时自动化。你在一个开发会话里等 CI、等 review、等部署、等长测试，它可以在后台盯着状态变化，读反馈，做下一步。
它的优势是上下文还在。它的短板也很明显：session 关了就停，长时间运行会产生 token 成本，权限和工具面也要管住。
所以我不会把 loop 当成长期后台 job。需要可靠运行几天几周的任务，还是应该走 Actions、云端 routine 或专门的自动化系统。
哪些任务适合先做
一个任务值不值得 loop，我现在会看三个条件：反馈清不清楚，边界窄不窄，失败能不能恢复。
CI 修复很适合。每一轮都能读到失败日志，修改后能跑测试，结果很清楚。
PR babysitting 也适合。review comments、冲突、CI 状态都在外部系统里，Agent 可以持续读取并处理。
依赖升级、文档同步、日志巡检、长测试结束后的失败分析，也都比较合适。这些任务的共同点是：每轮都会产生新证据。
反过来，目标很空的大重构就不适合一上来开 loop。比如把架构优化一下、让产品体验更好、整理一下权限系统。这种任务缺少外部完成标准，Agent 可能跑很多轮，结果只是把系统改得更难 review。
生产权限、支付、安全链路也要谨慎。能发消息、改 issue、push branch、查数据库、部署服务的 loop，本质上就是自动化操作外部世界。默认应该只读、draft、PR，必要时让人确认。
工程师的新工作
Boris 那段话有意思的地方，不在他不用 IDE 了这个姿态，在于工程师的位置变了。
以前我们写代码。后来我们提示模型写代码。再往后，我们开始设计让模型持续工作的系统。
这个系统里要有目标契约，要有工具，要有外部状态，要有检查器，要有停止条件。写 prompt 仍然有用，只是 prompt 被放进了一个更大的反馈闭环里。
这也是 open-source harness 套件正在做的事。
oh-my-openagent 在 OpenCode 上做多 Agent 编排、模型路由、Oracle 验证、编辑协议。oh-my-claudecode 用 Claude Code 的 plugin、skills、subagents、hooks、MCP、.omc 状态文件接管生命周期。ECC、GSD 这类项目更像跨 harness 方法论包，把 rules、skills、eval、worktree、fresh context、goal-backward verification 做成可迁移资产。
它们的共同点不是 agent 数量更多。真正的差异在控制面：怎么分工，怎么验证，怎么隔离副作用，怎么恢复状态，怎么决定停。
采用清单
我会用一张很土但管用的清单判断要不要开 loop。
这个任务能自动验证吗？
失败能回滚吗？
成本可控吗？
边界清楚吗？
每一项答不上来，就先别急着自动化。先补测试、补验收标准、降权限、写计划门。
这里其实也能回到实验设计。不要为了让流程看起来完整，把所有任务都套一遍 loop。低边际信息增益的循环会消耗时间和 token，还会制造噪声。
高价值的 loop 应该服务决策：这一轮结果能不能告诉我继续、停止、回滚，还是交给人。
总结
Loop Engineering 这个词可能会火一阵，也可能换个名字继续存在。名字不重要，变化已经很明显。
AI Coding 的竞争点正在从模型会不会写代码，转向系统能不能让 Agent 在真实工程约束里持续推进。
真正要学的重点不在怎么让 Agent 一直跑，重点在怎么让它进入可验证的循环。目标要清楚，传感器要可靠，权限要收住，停止条件要硬。
对团队来说，最好的起点不是搞一个全自动开发流水线。先挑一个小闭环：CI 修复、PR 评论处理、日志巡检、依赖升级。把目标、工具、检查、停止、回滚跑通，再扩大范围。
未来工程师的工作会越来越像 harness designer。写代码还在，但更大的价值会落在设计环境、反馈和控制面上。
”
原文作者： Vibe编码
原文链接： https://mp.weixin.qq.com/s/0-HurMKOQfJuW_t5oKRIng
来源： 微信公众号
推荐学习书籍 《CDA一级教材》适合CDA一级考生备考，也适合业务及数据分析岗位的从业者提升自我。完整电子版已上线CDA网校，累计已有10万+在读~ !
京公网安备 11010802022788号
