过去两年做编程Agent的标准姿势就是写Prompt → 等结果 → 读diff → 再写一遍Prompt。9成开发者从来没给自己的Agent写过一个能自动跑的Loop——没有自动化、没有状态文件、没有验证器也没有定时调度。但杠杆点已经从会不会写Prompt挪到了会不会设计一套让Agent自己跑的系统。这篇文章把这件事拆成14步、3个层次:先判断到底需不需要写Loop,再学5个核心积木,最后用最小代价把第一个Loop跑起来,且不会反过来伤到自己。材料主要来自Anthropic的工程文档、Addy Osmani关于Loop工程的长文,以及最近几篇测量类研究。第一部分:为什么要写Loop,以及怎么判断你到底需不需要01. Loop工程,就是把那个手动写Prompt的你替换掉过去两年,跟编程Agent打交道的方式基本是这样:写一段Prompt,把上下文喂过去,看它返回什么,再写下一段Prompt。Agent是工具,你是那只一直握着工具的手。这个阶段正在结束。所谓Loop工程,就是搭一套小系统:它自己找到要干的活、丢给Agent去做、检查结果、记录发生了什么、然后决定下一步——全程不用你盯着。你只设计一次这套系统,从此以后,是它在替你给Agent发Prompt。Addy Osmani把整件事拆成了六块。Anthropic自己的工程师团队,2026年每天合并的代码量是2024年的8倍——Anthropic自己也说这个数字几乎可以肯定夸大了真实的生产力提升。数字有争议,但机制本身没争议:杠杆点从敲Prompt挪到了设计那个替你敲Prompt的Loop。02. 动手前先做4条件测试Loop不是免费的。只有4个条件都满足,它的收益才能覆盖成本。少一个,它的开销就大于它带来的好处。这是AlphaSignal的分析里最实在、也是X上大多数线程都跳过的部分。任务必须重复发生。Loop的搭建成本要靠多次运行摊薄。一次性的活,写个好Prompt更快更便宜。如果这事不是每周都来一遍,那不叫Loop,叫一次性脚本。验证必须能自动完成。Loop需要一个不用你在场就能枪毙差结果的东西——测试套件、类型检查、Linter、构建脚本都行。如果没有自动化的检查,你就得回到椅子上一行行读diff,而这正是Loop本该替你省掉的活。Token预算得扛得住浪费。Loop会反复读上下文、反复重试、反复探索,不管最后有没有产出东西,Token都在烧。这个技术的可行性是和预算挂钩的,所以那些Token实际免费的人觉得这不显而易见吗,而按量付费的人觉得这也太鲁莽了吧——两边说的都是真话。**Agent得有资深工程师的工具**。日志、可复现环境、能跑自己写的代码看到底哪里崩了的能力。没有这些,Loop就是闭着眼睛瞎跑。03. 谁吃肉谁喝汤:Loop偏爱能烧钱的那群人这件事的经济学并不普适。觉得Loop工程显而易见的人,往往是Token不限量的那群;觉得它鲁莽的人,多半是用着20美元消费版套餐、跑重验证Loop会撞限制或者吃天价账单的人。实际能从中获益的,是那种工作可重复、可机器校验,并且有预算把Loop跑起来的团队——比如持续的CI失败分诊、依赖版本升级、Lint修复、在测试覆盖率扎实的代码库上把Issue自动转成PR草稿。代码库本身的测试套件够硬,是个隐含前提:如果一个初级工程师拿着checklist能干这活,测试套件又能兜住他的错,那这活就适合丢给Loop。异步优先、已经在用多Agent模式的团队也很合适,对他们来说Loop就是缺的那个编排层。反过来,今天就该避开Loop的人也很清楚:消费版套餐的独立开发者——Token账单到手比生产力红利来得快得多;代码没有任何自动化验证的项目——Loop跑起来就是Agent自己跟自己反复点头;瓶颈本来就在Review而不是打字速度的团队——Loop会生成更多代码,只会把Review队列拉得更长。一次性任务、探索性工作、或者完成是个判断题的场景,单独一发瞄准的Prompt依然更优。这篇文章诚实版本的结论是:Loop工程是真东西,但大多数开发者今天还用不到它。04. 30秒Loop检查清单第2步那个4条件测试是战略判断,这一步是战术判断——打算把某个具体任务做成Loop之前,先过一遍这个checklist。少一项就别上,老老实实手动Prompt。第一,这个任务至少每周来一次,不够频繁,搭建成本就摊不下来。第二,有测试、类型检查、构建或Linter能否决坏输出,没有自动闸门,Agent就是在自己批自己的作业。第三,Agent能跑自己改的代码,没有可复现环境,迭代就是盲动。第四,Loop有硬性的停止条件——Token预算、迭代次数或时间上限——没有的话它就一直跑到有人发现账单为止。第五,合并、部署或依赖变更前必须有人审核,任何不可逆的操作都需要人工审批闸门。适合做第一个Loop的任务大概是这几类:CI失败分诊(每晚扫一遍失败、归类原因、给容易的开个修复PR)、依赖版本升级PR(每周扫一遍更新、测兼容性、自动开PR)、Lint与代码风格修复(PR打开时自动跑)、不稳定测试的复现(一直跑直到能稳定复现),以及测试足够强的代码库上的Issue转PR草稿——反正坏输出会被测试套件挡掉。不适合做Loop、必须真人在椅子上的活也很明确:架构重写、认证或支付相关的代码、生产部署、模糊的产品需求,以及任何完成是个判断题的事。第二部分:5个核心积木05. Automations:Loop的心跳Automation是让一个Loop真的成为Loop而不是一次性运行的东西。它按定时、按事件或按某个触发条件启动。它是心跳,Loop的其他一切都挂在它上面。落到两个真正重要的工具上:Codex有Automations标签页——选项目、设Prompt、定节奏、选本地checkout还是后台worktree。跑出东西的Run进Triage收件箱,没跑出东西的自己归档。Claude Code用三个原语组合出同样的形状:/loop管会话内的节奏,桌面端的Scheduled Tasks让任务能扛住重启,Routines让笔记本合上之后也能在云上跑,再配合Hooks处理生命周期事件。在Automation里有两个原语,决定你的Loop到底是能用的还是烧钱的:/loop按节奏重跑,不管状态如何都定期检查;/goal一直跑到你写的那个条件真正成立——而且是由一个独立的小模型去检查是否完成,写代码的那个Agent不参与打分。这是造和验分离原则在停止条件层面的应用。 /loop 30m /goal All tests in test/auth pass and lint is clean. Scan src/auth for new failures, propose fixes in claude/auth-fixes, open draft PR when goal condition holds.▲ Claude CronCreate(*/30 * * * * : auth quality loop) Stop condition: tests pass lint clean (verified by checker)✓ Scheduled. Will continue past intermediate completions until /goal condition is met by independent checker.06. Worktrees:并行而不撞车只要你跑超过一个Agent,文件就开始打架。两个Agent写同一个文件,跟两个工程师在不打招呼的前提下往同一段代码里提交,是一样的麻烦事。git worktree能解决这件事——它是同一个仓库历史下,挂在独立分支上的另一个工作目录。一个Agent的修改在物理上就触不到另一个的checkout。两边的工具都内建了这件事:Codex直接做了worktree支持,多个线程可以同时打同一个仓库不撞车;Claude Code把git worktree直接暴露出来,有个--worktreeflag让会话开在独立checkout里,子Agent上有个isolation: worktree设置,让每个子Agent都拿到一个跑完自己清理掉的新鲜checkout。不过worktree只解决了机械上的冲突,瓶颈其实是你自己——你的Review带宽决定了你真正能并行跑多少Agent,工具决定不了。07. Skills:项目知识写一次,每次运行都能读到Skill就是用来防止你像金鱼一样、每个会话都把项目背景从头解释一遍的东西。两边工具用的是同一种格式:一个文件夹,里面有一个SKILL.md,写指令和元数据,再加上可选的脚本、参考资料和资产。为什么这事对Loop特别重要:一个没有Skill的Loop,每个循环都要从零推导一遍整个项目上下文。有了Skill,意图能复利累积——约定、构建步骤、“我们之所以不那么干是因为去年踩过那个坑”——写一次在外面,每次运行都能读到。name: ci-triagedescription: Classify CI failures by root cause (env, flake, real bug, dependency, infra), draft fixes for the easy ones, escalate the rest. Trigger whenever a workflow run fails or on the morning triage loop.---# CI triage skill## Classification rules- env: missing secret, wrong env var, infra not provisioned. # human- flake: passes on retry without code change. # retry once, then file- bug: deterministic failure tied to recent commit. # draft fix- dependency: failure tied to a version bump. # draft rollback- infra: timeout, OOM, runner issue. # escalate## Fix patterns- Auth tests → check src/auth/middleware first- Database tests → verify migration applied in CI env- E2E tests → check selectors against the latest UI snapshot## Never do- Disable failing tests — always file as escalation instead- Modify CI config without human approval- Touch src/payments/ or src/billing/ (in claude/permissions.md)## StateUpdate STATE.md after each run: file paths checked, classifications,PRs opened, items escalated.08. Connectors:Loop能碰到你真实的工具链(通过MCP)只能看文件系统的Loop是个特别小的Loop。Connector是建在Model Context Protocol(MCP)之上的,让Agent能读你的工单系统、查数据库、打staging API、往Slack里丢条消息。Codex和Claude Code都说MCP这门话,所以你给一个写的Connector,另一个那边基本能直接用。这是Agent告诉你’修法是这样’“和Loop直接帮你开PR、链上Linear工单、CI变绿后在频道里人之间的区别。Connector是Loop能在你真实环境里动手的原因——不是在那儿告诉你如果我能动的话我会怎么做”。收益最快的Connector排序大概是:GitHub——读仓库、建分支、开PR、评论Issue、响应Webhook事件,是任何代码类Loop第一天就能见效的最大单点收益;Linear或Jira——Loop跑着的时候顺手更新工单、把PR反向链回Issue、验证通过自动关闭条目;Slack——发分诊结果、升级时人、第二天早上把整夜跑的活总结成一段;Sentry或你用的错误追踪工具——让Loop直接调查线上告警,给高频的那几条画修复草稿。09. Sub-agents:让写的人和查的人分开Loop里结构上最有用的一件事,就是把写代码的Agent和检查代码的Agent分开。Osmani的说法很精确:写了代码的那个模型,“在批自己作业的时候简直太温柔了”。一个用不同指令、有时甚至用不同底模的第二Agent,能逮到第一个Agent给自己说服过去的那些东西。这就是Anthropic 2024年12月那篇工程文章里说的评估器-优化器(evaluator-optimizer)模式换了个名字而已:一个模型生成,另一个批评,重复。2026年火出圈的这套词,18个月前就有了文档。落到工具上,Codex只在你主动要求时才派子Agent,并行跑完再把结果折叠回一个答案。你自己在.codex/agents/下定义TOML文件——名字、描述、指令、可选的模型和推理强度。你的安全审查员可以是高推理强度的强模型,而你的代码探索员可以是个快速、只读的小模型。Claude Code在.claude/agents/下做同样的事,并且有Agent Teams在彼此之间传递工作。常见的拆法是:一个负责探索,一个负责实现,一个对照规格做验证。这事在Loop里特别重要的原因是:Loop跑的时候你不在场,所以一个你真的信得过的验证器,是你敢离开的唯一理由。子Agent会多烧Token——每个子Agent自己跑模型、自己用工具——把这部分Token花在第二意见真的值的地方。第三部分:把它建对,否则就别建10. 状态文件:Agent会忘,文件不会这部分听上去蠢到不值得说,但其实是每个能用的Loop的脊椎。一个Markdown文件,一个Linear面板,一个JSON状态——任何活在单次对话之外、记录做了什么、下一步是什么的东西都行。为什么这事关键:Agent默认是短记忆,它这个会话学到的东西,明天就没了,除非你把它写下来。Osmani的原则是:Agent会忘,仓库不会。没有持久状态的Loop每次都从头开始,有状态的Loop能接着上次跑。# Loop state · ci-triage## Last run2026-06-09 03:30 UTC · 7 failures classified, 3 fixes drafted, 4 escalated## In progress- claude/fix-auth-token-refresh — tests passing locally, awaiting CI- claude/fix-flaky-payment-webhook — retry pattern applied, monitoring## Completed today- claude/bump-axios-1.7.4 → merged (CI green, deps loop verified)- claude/lint-fix-pass-june-9 → merged## Escalated to humans- src/billing/refund.ts — tests failing in 3 ways, root cause unclear- ci/staging-runner — infra timeouts, not a code issue## Lessons learned (write here, not in chat)- 2026-06-08: PowerShell hits TLS 1.2 issue on this Windows runner. Use bash.- 2026-06-07: tests/e2e/checkout requires Stripe webhook secret in env. Skip if missing.## Stop conditions met since last review- /goal all tests pass lint clean achieved on commit 3a7b8c1 at 02:14 UTC状态文件放哪里有两种思路:放仓库里的Markdown,比如根目录或.claude/下的STATE.md,纳入版本控制、简单、diff好读,适合个人或小团队;或者放外部系统,比如Linear、GitHub Issues、数据库,跨仓库存活、可查询、支持团队级可见,适合需要多人看到Loop在干什么的生产级Loop。长跑Loop有跑偏目标的风险,所以状态文件之外,最好再配一份常驻的高阶规格——叫VISION.md或者AGENTS.md都行——让Agent每次跑之前重读一遍。状态文件告诉Agent它在哪里,规格文件告诉它要去哪里。11. 最小可行Loop如果第2步那个4条件测试你过了,那在搞复杂玩意之前,先建一个能跑的最小版本:四个零件,不堆Agent群。一个Automation:按节奏触发、按明确条件停止。Claude Code里用/loop,Codex里用Automation,需要跑到某状态成立为止的时候配上/goal。一个Skill:一个SKILL.md,把Agent本来每次都要从零推导的项目上下文存一份。一个状态文件:Markdown或Linear面板,记录做了什么、下一步是什么,明天的运行能接着跑而不是重启。一个闸门:能自动否决坏工作的测试、类型检查或构建。这一件零件决定了Loop是真帮忙还是只烧钱。顺序很重要:先让单次手动运行稳定下来,再把它沉淀成Skill,再用Loop把它包起来,最后才上调度。跳步是Loop在生产里翻车的标准走法。唯一真正值得盯的指标是每个被接受的变更花了多少成本——不是花了多少Token、不是尝试了多少任务、不是调度了多少次Loop。如果接受率低于50%,说明你在干Loop本来该替你省掉的Review工作,Loop就是在亏。12. Ralph Wiggum Loop:那种悄悄翻车的Loop工程师Geoffrey Huntley记录并命名了这种失败模式(Ralph Wiggum是辛普森一家里出了名笨笨的角色)。本来应该在真的完成时才发出完成token的Agent,提前发了,Loop就在半成品上退出了。没有硬闸门,Loop会悄悄翻车然后继续烧钱。它通常长这样:没有真正的Verifier,只有第二个Agent被叫去Review一下,没有客观信号——两个乐观主义者互相点头;完成条件太软,完成由Agent的判断而不是测试/构建/类型检查定义;没有硬停止,Loop一直跑到外部东西杀掉它(限流、你发现了)。修法就是第11步说的闸门——一个能客观否决工作的东西。一个跑过或跑不过的测试,一个编不编得过的构建,一个返回0还是非0的Linter,不是一个有意见的Verifier。其他几种实测过的失败模式也值得知道:长会话目标漂移——每一次摘要总结都是有损的,第47轮的时候别做X这个约束已经消失了,解药是常驻的VISION.md或AGENTS.md每次重跑都读一遍。自我偏好偏差——写代码的Agent批自己作业太温柔,解药是用一个没接触过造方推理过程的独立Verifier子Agent。Agent的惰性——Loop在还没真完成时就宣布差不多得了,解药是/goal配一个由新模型核对的客观停止条件。13. 理解力欠债和认知投降这个失败模式有个反直觉的特点:Loop越好用,它越严重。Osmani那篇文章里命名了两个具体风险。理解力欠债:Loop越快地往仓库里塞你没写过的代码,仓库里有什么和你实际理解什么之间的差距就越大。真正会让你疼的不是Token账单,是某天你必须去debug一套没人读过的系统。认知投降:那种不再形成自己的判断、直接接受Loop返回结果的诱惑。设计Loop这件事本身——带着判断力去做,是解药;为了逃避思考去做,是助推剂。同一个动作,截然相反的结果。应对方法都不是技术性的:读diff——不读Loop交付的东西,就是在按复利租理解力欠债。抽查闸门——挑几个Loop开的PR,验证下放它过去的那个测试,是不是真的能逮到你在乎的那种失败模式,闸门会烂。别让Loop碰架构——把它压在小型、可机器校验的变更上,一旦让它碰判断题,理解力欠债开始加速。两个人一起设计Loop——设计时多一双眼睛,能逮到你单人会被Loop永久利用下去的盲点。14. 安全税:无人值守的Loop就是无人值守的攻击面一个没人盯的Loop,同时也是一个没人盯的攻击面。威胁模型大概是这样:生成代码未经Review就出货——Loop开PR的速度比人读PR的速度快,没有包含安全检查的闸门(SAST、依赖审计、密钥扫描),不安全的代码就会自动合并。Skill本身就是注入向量——自动安装Skill的Loop,会继承藏在Skill描述里的所有Prompt注入,安装前审查Skill来源。凭证泄到日志里——长跑Loop如果开了详细调试日志,密钥会散到你从来不看的日志里,生产Loop关掉冗余日志,能写出去的也要做脱敏。权限范围悄悄扩大——为了方便给只读权限的Loop就加一个写权限,然后再也没人复查,每30天复查一次权限。那些会把Loop变成烧钱坑的常见错误没做4条件测试就建Loop——第2步存在是有原因的,大多数开发者至少有一项不满足。没有客观闸门——让第二个AgentReview一下而不是测试/类型检查/构建,那只是两个乐观主义者。同一个Agent又写又验——自我偏好偏差,造方批自己作业永远都是A。没有状态文件——明天的运行从零重启而不是接着跑。停止条件太模糊——看起来不错就行永远不成立,用测试、类型通过或者构建通过。没有Token预算上限——Loop会反复读上下文、反复重试,没有上限的话野心大的Loop能烧掉你预期的5到10倍。消费版套餐上跑重验证Loop——Token账单或者限流,反正有一样会逮到你。自动安装社区Skill——被审计的17,022个Skill里有520个会泄密,安装前读一下源码。让Loop碰判断题——架构、认证、支付、模糊的产品决策,把Loop压在Lint修复上,别让它碰战略。不读diff——理解力欠债按复利涨,某天去debug一套没人读过的系统的代价,比你这辈子烧的Token还贵。写在最后:杠杆点挪了,你的活也跟着挪了过去两年,跟编程Agent合作的杠杆在Prompt层——更好的Prompt、更好的上下文、更好的一次成型输出。这个阶段正在结束。Agent已经足够好了,下一个杠杆点上移了一层:决定Agent干什么、什么时候干、用什么闸门、运行之间什么状态能存活下来的那套系统。但这个故事诚实的版本不是所有人都该立刻去搭Loop。大多数开发者今天还用不到——除非任务在重复、验证能自动做、预算扛得住浪费、Agent又有资深工程师的工具。少一个,Loop的代价就大于它带来的好处。如果过了那个测试,就从小开始建:一个Automation、一个Skill、一个状态文件、一个闸门。先让单次手动运行稳定,再沉淀成Skill,再用Loop包起来,最后才上调度。顺序很重要,跳步建出来的系统没人理解,最后是你买单。Cherny那句话的意思不是活变轻松了。是杠杆点挪了。建好Loop,继续当那个工程师。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】