AI 行业热衷于给旧模式重新命名。但这一次确实发生了一些真正的变化。一位 Forward Deployed Engineer 视角企业在开始构建 loops 之前实际需要什么。你最近可能读到过类似这样的话“You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”- Peter Steinberger你的第一反应大概是等等那我现在到底该做什么不是“这是新东西吗”也不是“这不是已经存在了吗”真正让人感到失去方向的是这句话暗含的意思你一直在做的事——编写 prompts、迭代 prompts、逐渐变得擅长 prompts——已经不再是工作本身。现在的工作上升到了更高一层。这个转变值得认真对待。因为如果你把它当作炒作而不屑一顾你会错过其中真实存在的部分。而如果你不加批判地接受它你会为了那些一个 bash script 在 40 毫秒内就能处理的问题烧掉大量 tokens。过去几个月里我一直以 Forward Deployed Engineer 的身份在企业环境中部署 agents。下面是我对正在发生的事情的真实看法。在我之前的文章中我认为 agent harness engineering 有 90% 都是我们一直熟悉的 systems design只是应用到了一个新的底层载体上。剩下的 10% 确实是新东西因为你现在是在封装一个 non-deterministic core。这个框架依然成立。但 loop engineering 位于 harness 之上一层在你把它当作营销词汇而否定之前这个差异值得仔细拆解。让我解释一下它到底是什么哪些质疑是合理的以及哪些地方确实发生了真实变化。什么是 loop engineering这里有一个最清晰的定义来自 Peter Steinberger“Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.”Anthropic 负责 Claude Code 的 Boris Cherny 也说过几乎相同的话“I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.”当我第一次读到这句话时我的思路大概和你一样reactive workflows。Event-driven pipelines。里面放了更聪明任务的 cron jobs。这个形态很熟悉。差异在于 loop 内部是什么。传统的 cron job 执行固定步骤。它运行一个 SQL query写入一个文件发送一封 email。这些步骤是 deterministic 的并且在编写时就已经定义好。你完全知道它会做什么。而 Steinberger 和 Cherny 所描述意义上的 loop执行的是由模型在 runtime 决定的步骤。loop 说“triage yesterday’s CI failures”然后模型决定哪些 failure 值得处理、如何排序优先级、尝试什么修复以及什么时候停止。loop 的行为受到作者从未显式编程进去的 context 影响。这是一个真实差异。不是革命性的。但是真实存在。哪些质疑是正确的下面这些质疑是合理的。术语被夸大了。 每隔三个月就会出现一个新的复合名词用来描述你已经知道的某种模式。Context engineering、agent harness、agentic workflows、loop engineering。其中一些确实是词汇的自然演进。另一些则是 SEO 和会议演讲标题。合理的默认态度是在你理解这个词背后的概念之前先不要信任这个词。成本问题很严肃。 一个按计划运行、生成并行 sub-agents、并持续迭代直到达成目标的 loop会以高度不稳定的速率消耗 tokens具体取决于你如何设计它。对大多数团队来说写一个简单的 Python script 来检查 deployment status要比每 15 分钟付费让一个 frontier model 思考这件事更好。除非问题确实需要在 runtime 进行动态判断否则这种能力并不能证明其开销是合理的。演示案例经过精心挑选。 用来说明 loop engineering 的例子——daily CI triage、commit briefings、从上周 commits 中寻找 bug——恰好都是模型的动态判断能力能带来价值的场景。它给人的印象是 loops 普遍优于 scripts。但事实并非如此。只有当工作需要无法预先指定的 reasoning 时loops 才在特定场景下更好。harness engineering 和 loop engineering 实际上如何关联这是大多数解释都会一笔带过的部分。Harness engineering 关注的是单个 agent 运行其中的执行环境。它处理 context management、tool permissions、retries、logging、跨调用的 state persistence。harness 的作用是防止单个 agent 幻觉出 tool call、在 40 轮对话后忘记自己的目标或者以高度自信的方式静默地产生错误输出。如果你构建过真实的 backend systems那么你已经理解了 harness 所做事情的 80%。Loop engineering 关注的是随着时间推移对多个 agents 和多次 runs 进行 orchestration。它回答这样的问题谁来发现工作谁来完成工作谁来检查工作明天的 run 如何知道今天的 run 完成了什么loop 是位于 harness 之上的 control plane。可以这样理解。harness 是单个 agent 生存其中的环境。loop 决定何时启动一个 agent、给它什么任务以及如何处理它返回的结果。你两者都需要而且它们解决的是不同问题。来自 Addy 的博客中loop 的五个结构性组成部分是Automations按计划或由事件触发的 prompts用来暴露待处理工作。在 Claude Code 中这就是/loop、/goal和 scheduled tasks。在 Codex app 中则是带有 Triage inbox 的 Automations tab。Worktrees为并行 agents 提供隔离。两个 agents 同时写同一个文件和两个工程师在没有协调的情况下提交同一批代码行是同一种 failure mode。Skills把项目知识一次性写下来放在 conversation 之外这样 agent 不必每次 run 都从头重新推导你的约定。我曾单独写过这部分称之为 SKILL.md。ConnectorsModel Context Protocol (MCP) integrations使 loop 能够在你的真实环境中行动比如打开 PRs、更新 tickets、ping channels。Sub-agentsmaker/checker 分离。写代码的 agent 不应该是给代码打分的那个 agent。第六个东西也是整个结构的脊梁是 state。一个 markdown 文件。一个 Linear board。任何位于 conversation 之外、能够保存已尝试内容、已通过内容、仍未解决内容的东西。模型会在 runs 之间遗忘。repo 不会。/goalprimitive 是最有趣的部分大多数 loop 机制都足够熟悉。但有一个 primitive 没有清晰的 prior-art 类比值得关注。Claude Code 和 Codex 都暴露了一个/goalcommand。你给它一个可验证的停止条件“all tests in test/auth pass and lint is clean。”loop 会持续运行直到这个条件为真。每一轮之后一个独立的更小模型会评估 goal 是否已经达成因此执行工作的 agent 并不是给工作评分的 agent。把这种 maker/checker 分离应用到停止条件本身确实是新的设计领域。它不是 cron job。cron job 在 script 退出时停止。这个机制则是在一个独立 judge 确认结果满足 spec 时停止。这是否值得 token 成本完全取决于问题。对于“CI 是否通过”写一个 bash check 就行。对于“考虑到我们的 security conventions这个 PR 是否可以安全 merge”模型判断可能值得付费。诚实的结论Loop engineering 并不是一个根本性的新范式。它是构建在 agent harness primitives 之上的一种 orchestration pattern用于解决随时间推进的 autonomous multi-agent work 问题。新的部分是/goalprimitive以及针对停止条件的 maker/checker 分离。这是真正的设计贡献无法干净地映射到以往的 reactive workflow patterns。被夸大的是这样一种表述你应该停止 prompting agents转而开始设计 loops并把它当作通用原则。对某一类特定问题来说这是正确方向。但对于人们会立刻尝试套用它的大多数事情来说这是浪费。最贴切的类比是你不会仅仅因为 microservices 存在就把每个 function call 都替换成一个 microservice。只有当 scaling problem 足以证明这种复杂性合理时你才会使用它们。loops 也是一样。在问题需要 loop 的地方构建 loop。也要足够了解你的 harness才能看出什么时候更简单的方案才是正确选择。从结论走向生产Loop engineering 还足够新目前还没有经过实战检验的 playbooks。大多数尝试它的团队仍在弄清楚它到底在哪些地方有帮助哪些地方其实用更简单的 script 就可以。从 Forward Deployed Engineer 的角度诚实的建议是不要从 loop 开始。先识别一个反复出现的 workflow其中 decision logic 在 runtime 确实是模糊的是 script 无法预先指定的。先用 agent 手动运行几次。观察它在哪里失败、哪里需要判断、哪里会产出你不经过 review 就无法信任的东西。这些观察就是你的 loop design。还要留意 token consumption并检查与之相关的 cost。每一个新的行业 buzzword 都会把团队推向在基础尚未准备好之前就去尝试它。demo 会卡住或者更糟的是它进入 production 后失败。这里给大家精心整理了一份全面的AI大模型学习资源包括AI大模型全套学习路线图从入门到实战、精品AI大模型学习书籍手册、视频教程、实战学习、面试题等资料免费分享扫码免费领取全部内容1. 成长路线图学习规划要学习一门新的技术作为新手一定要先学习成长路线图方向不对努力白费。这里我们为新手和想要进一步提升的专业人士准备了一份详细的学习成长路线图和规划。可以说是最科学最系统的学习成长路线。2. 大模型经典PDF书籍书籍和学习文档资料是学习大模型过程中必不可少的我们精选了一系列深入探讨大模型技术的书籍和学习文档它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。书籍含电子版PDF3. 大模型视频教程对于很多自学或者没有基础的同学来说书籍这些纯文字类的学习教材会觉得比较晦涩难以理解因此我们提供了丰富的大模型视频教程以动态、形象的方式展示技术概念帮助你更快、更轻松地掌握核心知识。4. 2026行业报告行业分析主要包括对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。5. 大模型项目实战学以致用当你的理论知识积累到一定程度就需要通过项目实战在实际操作中检验和巩固你所学到的知识同时为你找工作和职业发展打下坚实的基础。6. 大模型面试题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我们将提供精心整理的大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。7. 资料领取全套内容免费抱走学 AI 不用再找第二份不管你是 0 基础想入门 AI 大模型还是有基础想冲刺大厂、了解行业趋势这份资料都能满足你现在只需按照提示操作就能免费领取扫码免费领取全部内容