2026年AI工程师的核心技能：Loop（循环）工程 ✍ Rahul🕐 2026-06-10📦 17.3 KB 🟢 已读 𝕏 文章列表 文章探讨了2026年AI工程范式的转变：从单纯的“提示词工程”转向设计自动化的“循环系统”。OpenAI与Anthropic的专家指出，工程师的角色已变为编写控制Agent的循环。文章深入解析了循环工程的定义、单体Agent与编队模式的区别，以及开放式与封闭式循环的差异。此外，文章重点讨论了循环模式带来的高昂Token成本问题，指出DeepSeek等低成本、大上下文的中国大模型是解决这一经济瓶颈的关键。 AI工程AgentDeepSeekLoopOpenAIClaude成本优化工作流自动化编程范式 # Loops: What Every AI Engineer Needs to Know in 2026 **作者**: Rahul **日期**: 2026-06-09T09:26:15.000Z **来源**: [https://x.com/sairahul1/status/2064277888216555684](https://x.com/sairahul1/status/2064277888216555684) ---   Peter Steinberger, creator of OpenClaw, who now works with OpenAI. Yesterday he posted this: > "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." Then Boris Cherny, head of Claude Code at Anthropic, said the same thing differently: > "I don't prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops." Two of the most senior AI engineers alive. Same message. Most people read it and thought: what does that actually mean? I went deep on it. Here is everything — broken down simply. No jargon. Just the mental model you need. Save this. It will change how you think about AI. ## BUT FIRST: THE REASON MOST PEOPLE NEVER BUILD LOOPS > Loops sound great. Then you see the bill.  Here is what nobody tells you upfront. A single agent loop on a medium coding task: 50,000–200,000 tokens. A fleet loop with an orchestrator and 3 specialists: 500,000–2,000,000 tokens. A loop running on a schedule every morning: millions of tokens per week. At standard API pricing, a week of serious loop engineering costs more than most people's entire monthly AI budget. This is why Peter Steinberger's replies were full of people saying: > "Easy for you to say — you have unlimited OpenAI access." They are not wrong. Loop engineering on a normal budget breaks fast. Every retry costs. Every self-correction costs. Every subagent costs. Every verification pass costs. The open loop that explores freely? Burns tokens at a rate that makes your eyes water. This is the hidden blocker nobody talks about. Loops are not hard to design. They are hard to afford. That is exactly what Chinese LLMs solve. Models like DeepSeek, Kimi, and MiniMax make agent loops economically viable. The biggest problem with autonomous agents is not intelligence. It is token burn. Loops consume tokens fast. A single run can easily burn 50K–200K tokens. Run multiple agents, schedule loops daily, or work on large codebases — and costs spiral quickly. This is where DeepSeek changes the equation. DeepSeek V4 is currently one of the cheapest frontier-level models for running loops at scale. What you get: → 1M context window — built for large projects and long-running workflows → 384K max output — handles bigger generations without breaking → DeepSeek V4 Flash + Pro models → Extremely low token pricing → Tool calls + JSON output for agent workflows → High concurrency (up to 2500 requests on Flash) Why the 1M context window matters: Loops need memory. A coding loop working on a large project needs to keep: — previous runs — current errors — architecture docs — test results — codebase context all in memory at the same time. Most models lose context midway. Your loop starts forgetting what happened earlier. DeepSeek holds significantly more context, so long-running loops stay coherent. And because pricing is so low: Loops stop breaking the bank. ## PART 1: THE OLD WAY VS THE NEW WAY For the last two years, we prompted agents one task at a time.  You type a prompt. The agent responds. You review it. You fix what is wrong. You prompt again. You are the loop. That is starting to change. Instead of asking an agent to build a landing page and then driving every step yourself, you set up a loop that handles discovery, planning, the work, checking, and iterating — until the goal is met. The difference: Old way (prompting): You → Prompt → Agent → Output → You review → You fix → Repeat New way (looping): You set the goal → Loop runs → Agent discovers → Plans → Executes → Verifies → Iterates → Done You are not prompting each step anymore. The agent repeats the cycle for you. A prompt gives the agent instructions. A loop gives the agent a job. ## PART 2: WHAT LOOP ENGINEERING ACTUALLY IS  Loop Engineering is the practice of designing repeatable feedback cycles that guide AI agents from attempt to verified outcome — without constant human intervention. Looping is a setup you build. Almost any agent harness can run it. It just depends on how you wire it up. At its simplest, one agent works on itself: → Researches → Drafts → Checks the draft against a goal → Fixes what is weak → Runs that cycle again until the work clears the requirements Every loop — no matter how simple or complex — moves through the same 5 stages: DISCOVER → PLAN → EXECUTE → VERIFY → ITERATE Pass verification → ship. Fail verification → loop again. That is the whole idea. Everything else in this article is just how you build that cycle properly. ## PART 3: ONE AGENT VS A FLEET There are two scales of looping:  SINGLE-AGENT LOOP One agent runs the whole cycle on its own. Think of it like a person redoing their own draft. It discovers what is needed, plans the work, executes, verifies quality, and iterates if something is wrong. Good for: → Focused tasks → Simple goals → Limited scope One brain. One loop. Self-improving. ━━━ FLEET LOOP The bigger version is a fleet looping. You give an orchestrator agent a goal. It breaks the goal into pieces. Hands each piece to a specialist agent. Those specialists hand smaller jobs to their own subagents. The whole tree keeps looping through discovery, planning, execution, and verification — until the goal is met. Think of it like a whole team running a project end-to-end. The structure: → Orchestrator owns the goal → Specialists own the steps → Subagents do the narrow work → Eval gates make sure it is not slop Example: "Build a productivity app" > Orchestrator (owns the mission) > ↓ ↓ ↓ > Research Engineering QA > Specialist Specialist Specialist > ↓ ↓ ↓ > Web Code Writer Test Writer > Researcher + Debugger + Bug Tracker Every agent in the tree runs the same 5-stage loop. Discover → Plan → Execute → Verify → Iterate. The important thing: A single-agent loop is like a person redoing their own draft. A fleet loop is a whole team running a project end-to-end. ## PART 4: OPEN LOOPS VS CLOSED LOOPS This is the most important practical distinction in 2026:  Not all loops are equal. There are two types. OPEN LOOPING Exploratory. Wide space to move in. You give the agent a goal and let it roam. It can try different paths, discover things, build something you did not fully spec out. This is the exciting end. It is what Peter Steinberger and others are doing at OpenAI. The catch? It burns an insane amount of tokens. For the 90% of people without unlimited API budgets, open looping is not practical yet. Pointed at projects with loose standards, it turns into a slop machine. Fast. Messy. Expensive. CLOSED LOOPING Bounded. A human designs the end-to-end path first. → Clear goal → Defined steps → An evaluation at each step → A point where it stops or hands back to you The agents still loop — but inside a framework you built. It gets better every run because each pass feeds the next. It runs on a normal budget because the path is tight. The standard keeps it honest. Without a quality gate: AI drifts. With a quality gate: AI improves. For most real work today, closed looping is the one that pays off. Which one should you use? Start with closed loops. Build a tight system that works reliably. Then open it up once you have the quality gates. ## PART 5: THE 6 BUILDING BLOCKS OF EVERY GOOD LOOP Every loop that holds together has these 6 things:  Now the practical part. A loop has 5 stages conceptually. But what do you actually build to make it run? 6 things. Both Claude Code and Codex ship all of them now. Here they are — and what each one is really doing inside the loop. 1. AUTOMATIONS This is what triggers DISCOVER and kicks the loop into motion. The heartbeat of the loop. An automation is what makes a loop an actual loop — and not just one run you did once. You define a prompt, a cadence, and a goal. The loop runs on schedule. Findings come to you. You are not the one going around checking. → /loop re-runs on a cadence → /goal keeps going until a condition you wrote is actually true Give it: "all tests in test/auth pass and lint is clean." Walk away. 2. WORKTREES This is what lets multiple EXECUTE stages run in parallel without breaking each other. Parallel agents without chaos. The second you run more than one agent, files start colliding. Two agents writing the same file is the same problem as two engineers committing to the same lines without talking. A git worktree gives each agent its own isolated working directory on its own branch — same repo history, zero collisions. One agent's edits literally cannot touch the other's checkout. 3. SKILLS This is what makes DISCOVER faster — the agent already knows your project before it starts. Stop explaining your project from zero every run. A skill is a folder with a SKILL.md inside — project conventions, build steps, the "we don't do it this way because of that incident." Written once. Read every loop. Without skills: the loop re-derives your whole project from zero every cycle. With skills: it compounds. The agent knows your project before it starts. → VISION.md — what success looks like → ARCHITECTURE.md — the tech stack and folder structure → RULES.md — what the agent is never allowed to do 4. PLUGINS AND CONNECTORS This is what makes EXECUTE real — the loop acts in your actual environment, not just your filesystem. A loop that can only see the filesystem is a tiny loop. Connectors (built on MCP) let the agent read your issue tracker, query a database, hit a staging API, drop a message in Slack. This is the difference between an agent that says "here is the fix" and a loop that opens the PR, links the Linear ticket, and pings the channel once CI is green — by itself. 5. SUBAGENTS This is what makes VERIFY honest — the checker is never the same agent as the maker. Keep the maker away from the checker. The model that wrote the code is too nice grading its own homework. A second agent with different instructions — sometimes a different model — catches the stuff the first one talked itself into. The split that works: → One agent explores → One agent implements → One agent verifies against the spec This is also what /goal does under the hood. A fresh model decides if the loop is done — not the one that did the work. 6. MEMORY This is what makes the loop persistent — DISCOVER on run 47 knows everything runs 1 through 46 already tried. The spine of the whole loop. A markdown file. A Linear board. Anything that lives outside the single conversation. The model forgets everything between runs. The repo does not. The memory file holds: what got tried, what passed, what is still open. Tomorrow morning the loop picks up where today stopped. It sounds too simple to matter. Every long-running loop depends on it. ## PART 6: REAL LOOP EXAMPLES What loops look like in practice:  The Coding Loop ``` Read VISION.md + ARCHITECTURE.md ↓ Plan the next change ↓ Edit the code ↓ Run tests automatically ↓ If tests fail → read error → fix → retest ↓ If tests pass → summarize changes ↓ Stop ``` No human in the middle. The agent writes, tests, fixes, and verifies on its own. ━━━ The Research Loop ``` Define research question ↓ Search for sources ↓ Summarize findings ↓ Verify claims against sources ↓ Compare conflicting information ↓ Synthesize final answer ↓ Stop when confidence threshold met ``` ━━━ The Content Loop ``` Topic + audience + goal defined ↓ Draft created ↓ Critique agent reviews draft ↓ Rewrite based on critique ↓ Score against success criteria ↓ If score passes → publish ↓ If score fails → rewrite again ``` ━━━ The Sales Outreach Loop ``` ICP (Ideal Customer Profile) defined ↓ Find leads matching profile ↓ Enrich with company data ↓ Qualify against criteria ↓ Personalize message ↓ Quality review ↓ Send or escalate to human ``` Every loop has the same skeleton: Goal → Action → Check → Fix → Repeat until done. ## PART 7: PROMPT ENGINEER VS LOOP ENGINEER The skill gap opening up in 2026:  Prompt Engineer → Craft better instructions → Linguistic skill → Better prompt → better single output → Still reviews output manually after every run → You are the feedback loop Loop Engineer → Design better feedback cycles → Software engineering skill → Better loop → reliable verified outcomes → System runs, checks, and self-corrects → The system is the feedback loop Prompt Engineer -> "Write me a function" Loop Engineer -> "Write → test → fix until green" Writes better prompts Writes VISION.md Reviews output manually Tests review automatically Runs agent once Builds repeating system Pays per single output Pays for verified outcome The tools are the same. The mindset is completely different. Prompt engineers ask AI for output. Loop engineers design systems that produce verified outcomes. The highest-paid AI engineers in 2026 are not writing better English sentences. They are writing the logic that governs how agents discover, plan, check their own work, and know when they are done.  ## CLOSING That is Loop Engineering. Let me recap everything: The shift: → For two years we prompted agents one task at a time → Now we design loops that run the whole cycle The 6 things you actually build: → Automations — the heartbeat, triggers discovery → Worktrees — parallel agents without collisions → Skills — project knowledge that compounds every run → Plugins and connectors — loop acts in your real tools → Subagents — maker and checker are never the same agent → Memory — loop never forgets between runs Two scales: → Single agent: one brain, self-improving → Fleet: orchestrator + specialists + subagents — every agent runs the same loop Two types: → Open loop: exploratory, powerful, expensive, needs unlimited budget → Closed loop: bounded, reliable, affordable, the one that pays off today The 5 parts of every good loop: → Goal — define what done means precisely → Context — VISION.md, ARCHITECTURE.md, RULES.md → Action — only what the agent actually needs → Feedback — tests, type checks, linters, structured errors → Stop condition — when the loop knows it's finished The cost problem: → Loops burn tokens fast → $20 on DeepSeek goes dramatically further than most frontier models → That removes the last real blocker The big shift: → Prompt engineers ask AI for output → Loop engineers design systems that produce verified outcomes Peter Steinberger said it right: Stop prompting your agents. Start designing loops. Because one reliable loop is worth a thousand perfect prompts. One more thing nobody says out loud. Two people can build the exact same loop and get completely opposite results. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all. The loop does not know the difference. You do. That is what makes loop design harder than prompt engineering — not easier. Boris Cherny's point is not that the work got easier. It is that the leverage point moved. Build the loop. But build it like someone who intends to stay the engineer — not just the person who presses go. Because one reliable loop is worth a thousand perfect prompts. And with 1.7 billion tokens for $20, you can finally afford to build one. If this helped: → Repost to share with your network → Follow @sairahul1 for more breakdowns like this → Bookmark this — the 5-part framework is worth revisiting I write about AI, building products, and systems that run while you sleep. ## 相关链接 - [Rahul](https://x.com/sairahul1) - [@sairahul1](https://x.com/sairahul1) - [1.7M](https://x.com/sairahul1/status/2064277888216555684/analytics) - [@sairahul1](https://x.com/@sairahul1) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [5:26 PM · Jun 9, 2026](https://x.com/sairahul1/status/2064277888216555684) - [1.7M Views](https://x.com/sairahul1/status/2064277888216555684/analytics) - [View quotes](https://x.com/sairahul1/status/2064277888216555684/quotes) --- *导出时间: 2026/6/10 12:46:02* --- ## 中文翻译 # 循环：2026 年每位 AI 工程师必须知道的知识 **作者**: Rahul **日期**: 2026-06-09T09:26:15.000Z **来源**: [https://x.com/sairahul1/status/2064277888216555684](https://x.com/sairahul1/status/2064277888216555684) ---   Peter Steinberger，OpenClaw 的创造者，现任职于 OpenAI。 昨天他发布了这段话： > "你不应该再手动去 Prompt 编码代理了。你应该去设计循环，让循环去 Prompt 你的代理。" 随后，Anthropic 的 Claude Code 负责人 Boris Cherny 换了个说法表达了同样的观点： > "我不再手动 Prompt Claude 了。我有循环在运行，它们去 Prompt Claude 并弄清楚该做什么。我的工作就是编写循环。" 这是当今世上最资深的两位 AI 工程师。传达的信息是一样的。 大多数人看到后想的是：这到底是什么意思？ 我深入研究了一番。 这里有一切——拆解得通俗易懂。 没有行话。只有你需要的心智模型。 收藏这篇文章。它会改变你对 AI 的看法。 ## 但首先：大多数人从未构建循环的原因 > 循环听起来很棒。直到你看到账单。  这是没人一开始就告诉你的事。 在一个中等编码任务上的单个代理循环：50,000–200,000 tokens。 包含一个编排器和 3 个专家的集群循环：500,000–2,000,000 tokens。 每天定时运行的循环：每周数百万 tokens。 按标准的 API 价格，一周认真的循环工程成本超过了大多数人的整月 AI 预算。 这就是为什么 Peter Steinberger 的回复里充满了人说： > "你说得倒轻巧——你又无限制的 OpenAI 访问权限。" 他们没说错。 在正常预算下做循环工程很快就会破产。 每次重试都要钱。每次自我修正都要钱。每次子代理调用都要钱。每次验证环节都要钱。 自由探索的开放式循环？其消耗 token 的速度让你咋舌。 这就是没人谈论的隐形阻碍。 循环并不难设计。 难的是负担得起。 这正是中国大语言模型（LLM）所解决的问题。 像 DeepSeek、Kimi 和 MiniMax 这样的模型让代理循环在经济上变得可行。 自主代理最大的问题不是智能。 而是 token 消耗。 循环消耗 token 的速度很快。 单次运行很容易烧掉 5 万到 20 万 tokens。 运行多个代理，每天定时循环，或者处理大型代码库——成本会迅速螺旋上升。 这就是 DeepSeek 改变局面的地方。 DeepSeek V4 目前是大规模运行循环的最便宜的前沿模型之一。 你能得到： → 1M 上下文窗口——为大型项目和长工作流打造 → 384K 最大输出——处理更大的生成任务而不中断 → DeepSeek V4 Flash + Pro 模型 → 极低的 token 价格 → 工具调用 + JSON 输出用于代理工作流 → 高并发（Flash 模型高达 2500 个请求） 为什么 1M 上下文窗口很重要： 循环需要记忆。 在大型项目上工作的编码循环需要同时保持： ——之前的运行记录 ——当前的错误信息 ——架构文档 ——测试结果 ——代码库上下文 都在记忆中。 大多数模型在途中就会丢失上下文。 你的循环会开始忘记之前发生了什么。 DeepSeek 能保持显著更多的上下文，因此长循环能保持连贯。 而且因为价格极低： 循环不再烧钱。 ## 第 1 部分：旧方式与新方式 在过去两年里，我们一次一个任务地 Prompt 代理。  你输入一个 Prompt。代理响应。你审查。你修正错误。再次 Prompt。你就是那个循环。 这正在开始改变。 与其让代理构建一个落地页然后你自己驱动每一步，不如设置一个循环来处理发现、规划、工作、检查和迭代——直到目标达成。 区别： 旧方式（Prompting）： 你 → Prompt → 代理 → 输出 → 你审查 → 你修正 → 重复 新方式（Looping）： 你设定目标 → 循环运行 → 代理发现 → 规划 → 执行 → 验证 → 迭代 → 完成 你不再手动 Prompt 每一步。 代理为你重复这个循环。 Prompt 给代理指令。 循环给代理一份工作。 ## 第 2 部分：循环工程到底是什么  循环工程是设计可重复反馈循环的实践， 该循环引导 AI 代理从尝试走向验证结果—— 无需持续的人工干预。 循环是一种你构建的设置。 几乎任何代理框架都可以运行它。 这只取决于你如何连接它。 在最简单的情况下，一个代理自我循环： → 调研 → 起草 → 根据目标检查草稿 → 修正薄弱之处 → 再次运行该循环直到工作符合要求 每个循环——无论简单或复杂——都经历 相同的 5 个阶段： 发现 → 规划 → 执行 → 验证 → 迭代 通过验证 → 交付。 验证失败 → 再次循环。 这就是核心理念。 这篇文章的其他部分只是关于如何正确构建那个循环。 ## 第 3 部分：单一代理与集群 循环有两个规模尺度：  单代理循环 一个代理自行运行整个循环。 把它想象成一个人重写自己的草稿。 它发现所需内容，规划工作，执行，验证质量，如果有问题就迭代。 适用于： → 专注的任务 → 简单的目标 → 有限的范围 一个大脑。一个循环。自我改进。 ━━━ 集群循环 更大的版本是集群循环。 你给一个编排代理设定目标。 它将目标拆解。 将每一部分交给一个专家代理。 这些专家将更小的工作交给他们自己的子代理。 整个树状结构不断循环通过发现、规划、执行和验证——直到目标达成。 把它想象成一个团队端到端运行一个项目。 结构： → 编排者拥有目标 → 专家拥有步骤 → 子代理做具体工作 → 评估门确保结果不是垃圾 示例：“构建一个生产力应用” > 编排者（拥有任务） > ↓ ↓ ↓ > 调研 工程 质保 > 专家 专家 专家 > ↓ ↓ ↓ > Web 代码编写者 测试编写者 > 调研员 + 调试员 + Bug 追踪者 树中的每个代理都运行相同的 5 阶段循环。 发现 → 规划 → 执行 → 验证 → 迭代。 关键在于： 单代理循环就像一个人重写自己的草稿。 集群循环是一个团队端到端运行一个项目。 ## 第 4 部分：开放式循环与封闭式循环 这是 2026 年最重要的实际区别：  并非所有循环都是平等的。 有两种类型。 开放式循环 探索性的。移动空间广阔。 你给代理一个目标并让它漫游。 它可以尝试不同的路径，发现事物，构建你没有完全规划出来的东西。 这是令人兴奋的一端。这也是 Peter Steinberger 和其他人在 OpenAI 正在做的。 缺点？ 它烧掉多得离谱的 token。 对于 90% 没有无限制 API 预算的人来说，开放式循环目前还不现实。 如果用于标准宽松的项目，它会变成垃圾制造机。 快。乱。贵。 封闭式循环 有界的。人类首先设计端到端的路径。 → 清晰的目标 → 定义的步骤 → 每一步的评估 → 一个停止或交还给你的点 代理仍然在循环——但在你构建的框架内。 因为每一次通过都为下一次提供依据，所以每次运行都会变得更好。 它在正常预算下运行，因为路径是紧凑的。 标准让它保持诚实。 没有质量门：AI 偏离。 有质量门：AI 改进。 对于当今大多数实际工作，封闭式循环才是有回报的那个。 你应该用哪一个？ 从封闭循环开始。 构建一个可靠运行的紧凑系统。 一旦你有了质量门，再放开它。 ## 第 5 部分：每个优秀循环的 6 个构建块 每个能运转的循环都有这 6 样东西：  现在进入实战部分。 循环在概念上有 5 个阶段。 但你到底构建什么来让它运行？ 6 样东西。Claude Code 和 Codex 现在都打包了所有功能。 这里列出了它们——以及每个在循环里实际在做什么。 1. 自动化（AUTOMATIONS） 这是触发“发现”并让循环启动的东西。 循环的心跳。 自动化让循环成为真正的循环——而不只是你运行一次的东西。 你定义一个 Prompt，一个节奏，和一个目标。 循环按时间表运行。结果呈现给你。你不是那个到处检查的人。 → /loop 按节奏重新运行 → /goal 持续运行直到你写的条件实际为真 给它：“test/auth 中的所有测试通过且 lint 干净。” 然后走开。 2. 工作树（WORKTREES） 这让多个执行阶段能并行运行而不互相破坏。 没有混乱的并行代理。 你运行超过一个代理的瞬间，文件就开始冲突。 两个代理写同一个文件，就像两个工程师不说话就提交同一行代码一样。 Git worktree 给每个代理它自己的独立工作目录在自己的分支上——同样的仓库历史，零冲突。 一个代理的编辑字面上无法触及另一个的检出。 3. 技能（SKILLS） 这让发现更快——代理在开始前已经知道你的项目。 停止每次运行都从零解释你的项目。 技能是一个里面有 SKILL.md 的文件夹——项目约定，构建步骤，“我们不那样做是因为那次事故。” 写一次。每个循环读一次。 没有技能：循环每个周期都从零重新推导你的整个项目。 有技能：它会复利。代理在开始前就知道你的项目。 → VISION.md —— 成功长什么样 → ARCHITECTURE.md —— 技术栈和文件夹结构 → RULES.md —— 代理永远不能做的事 4. 插件和连接器（PLUGINS AND CONNECTORS） 这让执行变得真实——循环在你的实际环境中行动，而不只是你的文件系统。 只能看文件系统的循环是微型循环。 连接器（基于 MCP 构建）让代理读你的 issue 追踪器，查数据库，打 staging API，在 Slack 里发消息。 这就是说“这是修复”的代理和自动打开 PR，关联 Linear 票据，并在 CI 绿了时 ping 频道的循环之间的区别——全靠它自己。 5. 子代理（SUBAGENTS） 这让验证变得诚实——检查者永远不是做事情的代理。 让制造者远离检查者。 写代码的模型给自己的作业打分太宽容了。 带有不同指令的第二个代理——有时是不同的模型——能抓住第一个自己忽悠自己的地方。 有效的分工： → 一个代理探索 → 一个代理实现 → 一个代理根据规格验证 这也是 /goal 底层做的事。 一个新的模型决定循环是否完成——不是做那个工作的模型。 6. 记忆（MEMORY） 这让循环持久化——第 47 次运行的发现知道第 1 到 46 次已经尝试了什么。 整个循环的脊梁。 一个 markdown 文件。一个 Linear 看板。任何活在单次对话之外的东西。 模型在运行之间忘记一切。 仓库不会。 记忆文件保存：尝试了什么，通过了什么，还开放着什么。 明天早上循环从今天停止的地方接上。 听起来太简单而不重要。 每个长循环都依赖它。 ## 第 6 部分：真实循环示例 循环在实践中是什么样子的：  编码循环 ``` 读取 VISION.md + ARCHITECTURE.md ↓ 计划下一次变更 ↓ 编辑代码 ↓ 自动运行测试 ↓ 如果测试失败 → 读错误 → 修复 → 重测 ↓ 如果测试通过 → 总结变更 ↓ 停止 ``` 中间没有人类。 代理自己写代码，测试，修复，并验证。 ━━━ 调研循环 ``` 定义研究问题 ↓ 搜索来源 ↓ 总结发现 ↓ 根据来源验证声明 ↓ 对比冲突信息 ↓ 综合最终答案 ↓ 当达到置信度阈值时停止 ``` ━━━ 内容循环 ``` 定义主题 + 受众 + 目标 ↓ 创建草稿 ↓ 批评代理审查草稿 ↓ 基于批评重写 ↓ 根据成功标准打分 ↓ 如果分数通过 → 发布 ↓ 如果分数失败 → 再次重写 ``` ━━━ 销售外联循环 ``` 定义 ICP（理想客户画像） ↓ 寻找匹配画像的线索 ↓ 丰富公司数据 ↓ 根据标准筛选 ↓ 个性化消息 ↓ 质量审查 ↓ 发送或升级给人类 ``` 每个循环都有相同的骨架： 目标 → 行动 → 检查 → 修复 → 重复直到完成。 ## 第 7 部分：Prompt 工程师与循环工程师 2026 年正在扩大的技能差距：  Prompt 工程师 → 撰写更好的指令 → 语言技能 → 更好的 Prompt → 更好的单次输出 → 依然每次运行后手动审查输出 → 你是反馈循环 循环工程师 → 设计更好的反馈循环 → 软件工程技能 → 更好的循环 → 可靠的验证结果 → 系统运行，检查，并自我修正 → 系统是反馈循环 Prompt 工程师 -> "给我写个函数" 循环工程师 -> "写 → 测试 → 修复直到绿色" 写更好的 Prompt 写 VISION.md 手动审查输出 自动测试审查 运行代理一次 构建重复系统 为单次输出付费 为验证结果付费 工具是一样的。 心态完全不同。 Prompt 工程师向 AI 索要输出。 循环工程师设计产生验证结果的系统。 2026 年薪酬最高的 AI 工程师不是在写更好的英语句子。 他们在写支配代理如何发现、规划、检查自己的工作以及知道何时完成的逻辑。  ## 结语 这就是循环工程。 让我总结一下一切： 转变： → 两年来我们一次一个任务地 Prompt 代理 → 现在我们设计运行整个周期的循环 你实际构建的 6 样东西： → 自动化——心跳，触发发现 → 工作树——无冲突的并行代理 → 技能——每次运行都复利的项目知识 → 插件和连接器——循环在你的真实工具中行动 → 子代理——制造者和检查者绝不是同一个代理 → 记忆——循环在运行之间从不忘记 两个尺度： → 单代理：一个大脑，自我改进 → 集群：编排器 + 专家 + 子代理——每个代理运行相同的循环 两种类型： → 开放循环：探索性的，强大的，昂贵的，需要无限制预算 → 封闭循环：有界的，可靠的，负担得起的，当今有回报的那个 每个优秀循环的 5 个部分： → 目标——精确定义完成意味着什么 → 上下文——VISION.md，ARCHITECTURE.md，RULES.md → 行动——只有代理实际需要的 → 反馈——测试，类型检查，linter，结构化错误 → 停止条件——循环何时知道它完成了 成本问题： → 循环快速烧掉 token → 在 DeepSeek 上花 20 美元比在大多数前沿模型上走得远得多 → 这消除了最后一个真正的阻碍 大转变： → Prompt 工程师向 AI 索要输出 → 循环工程师设计产生验证结果的系统 Peter Steinberger 说得对： 停止 Prompt 你的代理。 开始设计循环。 因为一个可靠的循环抵得上一千个完美的 Prompt。 还有一件事没人明说。 两个人可以构建完全相同的循环并得到完全相反的结果。 一个使用 i
为 为什么顶级 AI 工程师不再写提示词：Loops 与 Harness 的崛起 文章指出，AI 交互方式正在从单一的“提示词”转向“循环”。顶级工程师不再手动编写 Prompt，而是设计自动化循环，让智能体自我迭代直至任务完成。以 Slate 工具为例，介绍了如何通过编写 JavaScript“程序”来掌控循环逻辑，实现多模型并行处理和真实世界交互，从而构建更强大的智能系统。 技术 › Agent ✍ Rahul🕐 2026-07-18 AI工程AgentLoopSlate自动化Claude编程提示词工作流JavaScript
O OpenAI 工程师的 9 条 Codex 用法，DeepSeek 用户也能用 文章介绍了 OpenAI 工程师 Jason Liu 分享的 9 条 Codex 高效工作法，包括持久线程、共享记忆、语音输入、实时纠偏、操作电脑浏览器等。这些方法将 Agent 从单纯的聊天工具转变为能记住上下文、主动执行任务并操作真实应用的长期资产。作者指出，这套通用的 Agent 逻辑不仅适用于 Codex，通过 OpenCode、Playwright 等工具，在 DeepSeek 环境下也能完美复现。 技术 › Agent ✍ 沐光钱行🕐 2026-05-25 OpenAICodexDeepSeekAgent工作流开发工具自动化Jason Liu教程
深 深入解读 Harness Engineering：AI 工程的第三次范式转移 Anthropic 和 OpenAI 几乎同时发布关于 Harness Engineering 的文章，引发 AI 社区热议。本文梳理了从 Prompt Engineering 到 Context Engineering 再到 Harness Engineering 的演变，解析了 Anthropic 的“生成器+评估器”循环架构与 OpenAI 的“百万行代码零手写”分层实践，并结合多位博主的观点，探讨了 Agent 时代工程师角色的转变与未来工程实践的方向。 技术 › Harness Engineering ✍ Jason Zhu🕐 2026-03-31 AI工程AgentAnthropicOpenAI范式转移ClaudeCodex架构设计自动化开发者工具
如 如何使用Linear管理Agent并构建软件工厂 作者分享了使用Linear工具管理编程Agent的实战经验。他将任务按结果层级组织，利用分流箱收集问题，并通过分批处理工作流来提高效率。文章重点强调了制定清晰的Ticket契约（目标、原因、结果）、确保Agent完整完成任务以及实现无监督并行工作，从而打造个人“软件工厂”以提升生活质量。 技术 › Agent ✍ Fred Jonsson🕐 2026-07-20 LinearAgent自动化工作流软件工程编程LLM生产力Claude效率
B Build Your Whole Team With Claude 文章介绍了如何将 Claude 转变为一个完整的虚拟团队，通过安装 42 个涵盖开发、设计、营销、财务和法律等部门的特定技能（Skills），构建一个类真实的组织架构。这改变了传统的使用 AI 的方式，从重复提示转变为向专业员工委托任务，极大提高了个人或小团队的工作效率。 技术 › Skill ✍ Hamza Khalid🕐 2026-07-18 ClaudeSkillAgent生产力团队构建自动化工作流效率工具虚拟团队
构 构建可复用十年的AI写作框架 本文探讨了如何构建一个健康、可持续的AI写作框架，旨在帮助写作者避免被特定软件厂商或AI模型绑架。作者提出了一套基于文件夹系统和Agent工具的“AI外骨骼”工作台，强调让AI辅助而非替代创作，实现数据的自主掌控和灵活迁移，从而让作者专注于故事创作本身。 技术 › 工具与效率 ✍ 忒修斯的船板🕐 2026-07-16 AI写作工作流自动化写作技巧AgentClaudeObsidian方法论
O Obsidian+AI：如何搭建自动化内容生产线 本文介绍了如何利用 Obsidian 结合 AI（Copilot/Claude）搭建一套高效的内容生产流水线。通过“先积累后分类”的方法，利用本地文件确保数据安全，并借助插件和自动化脚本实现素材的自动归类、整理与选题生成。文章详细阐述了从零开始的安装步骤、避坑指南、实用分类法（PARA/Zettelkasten）以及具体的 AI 工作流配置，帮助内容创作者解决素材管理混乱和选题枯竭的问题。 技术 › 工具与效率 ✍ 宋宋🕐 2026-07-10 ObsidianAI知识管理内容创作DeepSeekClaude工作流笔记法自动化素材库
L Loop 入门指南：别再一句句写提示词了 本文探讨了 Claude Code 中的“Loop（循环）”概念，即 Agent 反复循环工作直到满足停止条件。文章详细介绍了四类 Loop：回合制、目标制、时间制和主动式，并分析了各自的最佳适用场景及如何控制 Token 消耗与保证代码质量。 技术 › Claude Code ✍ 老白（每日 AI 干货）🕐 2026-07-09 Claude CodeAgentLoopAI 编程提示词工作流自动化
使 使用 Fable 5 构建自我改进 Agent 系统的 14 步指南 文章深入探讨了如何充分利用 Claude Fable 5 的潜能，而非仅仅将其视作上下文窗口更大的 Sonnet。作者提出了构建“自我改进系统”的 14 步路线图，区分了自我学习与自我改进，并详细阐述了基于 Loops、Dynamic Workflows 和 Routines 的三层架构。文章还提供了 Fable 5、Opus 和 Sonnet 在系统中的成本与任务分配策略。 技术 › LLM ✍ Codez🕐 2026-07-09 Fable 5AgentClaude架构设计提示工程工作流自动化自我改进系统架构最佳实践
C Claude 官方关于 Loop Engineer 的入门解读 文章介绍了 Claude 官方提出的 Loop Engineer 概念，该概念将现有的 Agent 工作流程进行了系统化梳理。文中详细讲解了四种 Loop 类型：回合制循环、基于目标的循环（GOAL 模式）、基于时间的循环以及主动循环。此外，作者还分享了关于代码库质量维护和 Token 消耗管理的优化建议，并提及了 Codex、Skills 和 Hooks 等相关工具。 技术 › LLM ✍ 歸藏🕐 2026-07-08 Loop EngineerClaudeAgentClaude CodeCodexGOAL 模式工作流自动化Token 管理
万 万物皆可 Skill：如何基于 Codex 把任何内容变成可复用 AI 能力 文章提出了“万物皆可 Skill”的理念，指出高阶的 AI 使用方式应从临时性的提示词升级为可复用的 Skill（能力包）。文章详细阐述了 Skill 的本质（任务边界、流程、标准及失败处理）、与 Prompt 及 Workflow 的区别，并介绍了基于 Codex 构建 Skill 的标准结构、设计原则（如渐进披露）以及通过“元编程”视角实现 Skill 递归进化的方法。 技术 › Skill ✍ 知识猫图解🕐 2026-07-06 AI工程化CodexSkill设计提示词进阶AgentOpenAI工作流自动化方法论最佳实践
多 多模型整合指南：用 Hermes Desktop 统一管理 ChatGPT、Grok 与 DeepSeek 本文介绍如何使用 Hermes Desktop 将 ChatGPT、Grok、DeepSeek 和 MiniMax 等多个 AI 模型接入同一个桌面应用。文章详细讲解了通过图形界面一键配置模型账号、连接 Telegram/Discord 消息通道、以及设置 10 个实用的自动化工作流（如每日简报、竞品监控）的步骤，旨在无需编程即可实现多模型协同与自动化任务处理。 技术 › Hermes ✍ Wei🕐 2026-07-03 HermesAgentDeepSeekChatGPTGrok工作流教程自动化工具与效率多模型