开云新闻
开云的世界杯中国登录网址 2026年玩AI必备妙技: 不是提醒词, 是轮回工程
2026 年，会不会用 AI 不再看 Prompt（提醒词）才调了，而是要看会不会盘算轮回。
上周，谷歌云 AI 总监 Addy Osmani 的一篇博客著述《Loop Engineering》激勉了社区的讨论。
Addy Osmani 是一位在前端开导、Web 性能优化以及 AI 开导者用具界限都有影响力的工程师和技巧诱骗者。他最广为东谈主知的身份是曾任 Chrome 开导者体验团队的诱骗东谈主。
他所讨论的「轮回工程」看法相干盘算代码智能体实行轮回考证晋升的方式。Addy Osmani 默示，就算是使用同样的大模子，会不会用这种念念路，产生的结束将会完全不同。
让咱们望望这篇著述是若何说的：
「轮回工程」（Loop engineering）指的是不再由你躬行向编程智能体（coding agent）发送指示，而是盘算一套系统来自动奉行这一过程。这里的「轮回」不错分解为一种递归式方针：你设定一个意图，AI 则不断迭代直至任务完成。这一模式大致包含五个中枢组件，而 Claude Code 和 Codex 现在都已具备了这全部五个要素。
我敬佩，这很可能就是咱们改日与编程智能体互助的主流方式。不外，现在尚处于早期阶段，我对此持保留派头；此外，你必须荒谬眷注 Token 资本问题（凭据 Token 预算的充裕程度，使用模式可能会有一丈差九尺）。同期，若何确保代码质料不下滑亦然个问题，东谈主们对于产出低质料代码的担忧不无真理。话虽如斯，让咱们深入辩论一下这究竟是若何一趟事。
龙虾作家 Peter Steinberger 最近指出：「你不应再胜利向编程智能体发送指示，而应盘算简略自动向智能体发送指示的『轮回』。」
Anthropic 旗下 Claude Code 的认真东谈主 Boris Cherny 也抒发了近似的不雅点：「我不再胜利向 Claude 发送指示了。我运行着一些轮回递次，由它们认真向 Claude 发送指示并决定下一步作念什么。我的职责酿成了编写这些轮回递次。」
那么，这一切具体意味着什么呢？
畴昔约莫两年里，愚弄编程智能体完成任务的方式平凡是：编写高质料的提醒词（prompt）并提供迷漫的陡立文信息。你输入指示，搜检反映，再输入下一条指示。智能体就像一件用具，你耐久抓着它，进行着一轮又一轮的交互。那种模式某种程度上一经逾期了 —— 至少量多东谈主合计它行将成为畴昔式。
如今，你需要构建一个小系统来发现任务、分拨任务、查验结束、记载进程并决定下一走路动；由这个系统去驱动智能体，而不是由你躬行动手。我之前写过对于「智能体支撑框架工程」（agent harness engineering）的内容 —— 即构建单个智能体运行的环境，以及「工场模子」（即构建软件的系统）。「轮回工程」则处于支撑框架之上：它基于定时器运行，能生成微型支持递次，并能达成自我驱动。
令我诧异的是，这已不再只是是对于「用具」的问题了。一年前，若是你想要达成这种轮回，往往需要编写一大堆 Bash 剧本，并耐久调养这堆代码 —— 那是完全属于你个东谈主的东西。如今，这些组件已胜利内置于产物之中。
Steinberger 建议的要素清单简直完全对应于 Codex 应用，同期也基本适用于 Claude Code。一朝你发现两者的模式如出一辙，便无需再纠结于聘请哪款用具；你只需盘算一套职责闭环，非论身处哪个平台，这套进程都能顺畅运行。
五大要素及相干阐发
一个完好的职责闭环需要五个要素，外加一个用于存储信息的载体：
按预定计较自动运行，并能自主进行任务发现与分拣的自动化机制。
营救多职责树（worktrees）机制，能确保并行职责的智能体互不烦躁。
用于记载状貌学问的 skill 模块，幸免智能体在败落信息时只可靠「猜」来行事。
插件与衔尾器，用于将智能体接入你现存的用具链中。
子智能体机制，达成由一个智能体构念念决议，而由另一个进行考证的互助模式。
终末是第六个要素：操心存储。这不错是一个 Markdown 文献、一块 Linear 看板，或是任何放心于单次对话除外、用于记载已完成职责及后续计较的载体。这听起来似乎微不及谈，但这恰是系数耐久运行的智能体所依赖的环节机制 —— 正如我在辩论「耐久运行智能体」时所分析的，模子在两次运行之间会渐忘系数信息，因此操心必须存储在磁盘上，而不可仅依赖陡立文（context）。智能体会渐忘，但代码仓库（repo）会保留记载。
如今，Claude Code 与 Codex 已具备了上述全部五个要素。
天然各处的定名略有各异，但中枢功能是一样的。让咱们一一辩论，因为说真话，细节往往决定了一个轮回（loop）是能郑重运行，照旧会悄无声气地出现多样问题。
自动化（Automations）
中枢驱能源
恰是自动化让「轮回」名副其实，使其不单是是一次性的单次运行。在 Codex 应用中，你不错在「自动化」标签页创建一个任务，指定状貌、要运行的提醒词、奉行频率，以及是在腹地检出（local checkout）的代码上运行，照旧在后台职责树（background worktree）上运行。发现问题的运行结束会进入「分类收件箱」（Triage inbox），而未发现问题的运行则会自动存档 —— 这终点轻便。OpenAI 里面愚弄它来处理一些败兴琐碎的任务，比如逐日问题分类、回首 CI 失败情况、撰写提交选录，或是查找上周有东谈主引入的 Bug。
此外，自动化任务还不错调用 skill，从而保证重叠性任务的可调养性：你只需触发 $skill-name，而无需将一大段冗长的指示硬塞进一个没东谈主会去更新的调度竖立里。
Claude Code 达成了同样的方针，但禁受的是调度（scheduling）和 hooks 机制。你不错使用 /loop 按固定间隔运行提醒词或呐喊，不错栽种 cron 任务，不错通过钩子在智能体生命周期的特定节点触发 Shell 呐喊，或者将其推送到 GitHub Actions，以便在你合上札记本电脑后任务仍能络续运行。理念完全一致：界说一个自主任务，设定奉行节律，让结束自动反映给你，而无需你躬行四处查验。
还有一个值得了解的会话内原语（primitive），它更逼近本文的主题。/loop 是按节律重叠运行的；而 /goal 则会不断运行，直到餍足你设定的条款为止。在每一轮运行收尾后，会有一个放心的微型模子来查验任务是否完成，这意味着编写代码的智能体并不认真评估结束。你只需设定近似「test/auth 目次下的系数测试通过且代码查验（lint）无误」这样的方针，然后就不错去作念别的事了。
Codex 也有同样的功能，同样称为 /goal：它跨轮次不断职责，直到餍足可考证的住手条款，并营救暂停、规复和拔除操作。同样的机制，同样的用具 —— 这恰是连结整篇著述的模式。
这就是将职责服从呈现出来的关节。轮回的其余部分认真对它进行操作。
Worktree（职责树）
幸免并行操作激勉零乱
一朝运行多个智能体，文献冲突就会导致失败。两个智能体写入归拢个文献，就像两个工程师在未相易的情况下修改归拢溜代码一样令东谈主头疼。Git Worktree 处分了这个问题：它是在归拢仓库历史基础上、位于放心分支上的放心职责目次，因此一个智能体的修改都备不会影响另一个智能体的检出（checkout）内容。
Codex 内置了对 Worktree 的营救，允很多个线程同期走访归拢个仓库而互不烦躁。Claude Code 也通过 Git Worktree 提供了同样的进犯机制：使用 --worktree 秀气不错在放心检出环境中开启会话，开云2026世界杯(中国)官方登录入口或者在子智能体上栽种 isolation: worktree，让每个支持智能体获取一个全新的检出环境，并在职务收尾后自动计帐。我在「编排资本」（orchestration tax）一文中辩论了其中的东谈主为身分：Worktree 处分了机械性的冲突问题，但东谈主依然是瓶颈所在 —— 决定你能执走运行几许个智能体的是你的代码审查才调，而不是用具本人。
Skills
无需每次都再行解释状貌
「妙技」机制能让你解脱那种像金鱼一样、在每次会话中都要反复解释状貌布景的窘境。这两种用具禁受同样的口头：一个包含 SKILL.md 文献的文献夹（其中存有指示和元数据），以及可选的剧本、参考府上和资源文献。Codex 会在用户通过 $ 或 /skills 调用时，或者当任务与妙技形容匹配时自动运行该妙技 —— 这恰是精确、平实的形容要优于花哨形容的原因。Claude Code 的运作方式也如出一辙，我在「智能体妙技」一文中详备推崇了这一模式。
「妙技」亦然处分「意图资本」反复铺张问题的环节。智能体每次会话都是从零初始的，它会自信地填补你意图中的任何空缺。而「skill」就是将这些意图（如沿袭成习的模范、构建设施、诸如「因为某次事故是以咱们不这样作念」之类的阅历教养）显式地记载下来；只需编写一次，智能体每次运行时都会读取。若是莫得妙技，轮回会在每个周期从零初始再行推导系数这个词状貌；有了妙技，学问蕴蓄就能产生叠加效应。率先要明确一丝：Skill 指的是创作口头，而 Plugin 则是寄托它的方式。当你需要在不同代码仓库间分享 Skill，或者将多个 Skill 组合在沿路时，就不错把它们打包成 Plugin。这一逻辑在 Codex 和 Claude Code 中均适用。
Plugins 与 Connector
让「轮回」简略与你的执行用具交互
若是一个「轮回」只可走访文献系统，那它的才调将终点有限。基于 MCP 构建的衔尾器（Connectors）则冲破了这一局限，让智能体简略读取 Issue 跟踪系统、查询数据库、调用预发布环境（staging）的 API，甚而在 Slack 上发送音信。由于 Codex 和 Claude Code 都营救 MCP 模范，因此你为其中一个编写的衔尾器，平凡也能胜利在另一个中运行。此外，插件将衔尾器和 Skill 整合在沿路，轻便你的团队成员一键装配并使用整套竖立。
而不是完全凭操心重新重建。
这就是「只会说『栽种决议如下』的智能体」与「能自动提交 PR、关联 Linear 工单并在 CI 通事后在频谈示知的轮回」之间的区别。恰是因为有了衔尾器，轮回才能在你的执行环境中给与行动，而不单是泛论它「若是能操作的话」会作念什么。
子智能体
将「奉行者」与「查验者」分离
在轮回机制中，最有用的结构性盘算莫过于将编写代码的脚色与查验代码的脚色分离开来。认真写代码的模子在评估我方的「功课」时往往过于优容；而另一个领有不同指示（或然甚而使用不同模子）的智能体，则能发现第一个智能体因自我合理化而忽略的问题。
Codex 仅在你明确要求时才会启动子智能体，让它们并走运行，终末将结束汇总为一个谜底。你不错通过 .codex/agents/ 目次下的 TOML 文献界说我方的智能体，每个智能体包含称号、形容、指示以及可选的模子和推理强度栽种；这样，你的安全审查员不错是高推理强度的高大模子，而认真探索任务的智能体则不错是快速、只读的轻量级模子。Claude Code 也有近似机制，愚弄 .claude/agents/ 中的子智能体和智能体团队在彼此间传递任务。在这两种用具中，常见的脚色单干平凡是：一个认真探索，一个认真达成，另一个凭据模范进行考证。
我之前曾两次推崇过这一理念：一次是将其称为「代码智能体编排（orchestra）」，另一次则称之为「挣扎式代码审查」。之是以在轮回机制中这一丝尤为蹙迫，是因为轮回是在你无东谈主值守的情况下运行的；独一领有一个你果真信任的考证者，你才能定心性离开。子智能体如实会铺张更多 Token（因为每个智能体都要放心进行模子调用和用具操作），因此应将资源插足到那些值得获取「第二意见」的关节中。这其实亦然 Claude Code 的 /goal 呐喊在底层运作的旨趣：由一个全新的模子（而非奉行任务的阿谁模子）来判断轮回是否收尾 —— 行将「奉行者」与「查验者」分离的原则应用到了断绝条款的判定上。
一个轮回的典型形态
将这些组件组合起来，单一的奉行流就酿成了一个微型戒指面板。以下是我往往禁受的一种模式。
针对代码仓库，每天早上运行一次自动化任务。它的提醒词（prompt）会调用一个「分诊」妙技（triage skill），该妙技读取昨天的 CI 失败记载、未处分的问题（open issues）和最近的代码提交，并将分析结束写入 Markdown 文献或 Linear 看板中。对于每一项值得处理的问题，进程会创建一个放心的职责树（worktree），并叮属一个子智能体（sub-agent）草拟栽种决议，随后由第二个子智能体凭据状貌的既有妙技和现存测试用例对该草案进行审查。
通过衔尾器（connectors），该轮回简略自动创建 PR 并更新工单情景。但凡轮回无法处理的事项，都会进入「分诊收件箱」恭候我躬行处理。情景文献是系数这个词系统的中枢，它记载了已尝试的操作、已通过的任务以及未完成的职责，确保明早的运行能从今天中断的地方络续进行。
追想一下你执行作念了什么：你只进行了一次盘算，而无需针对后续的每一设施单独下达指示。这恰是 Steinberger 不雅点的具体达成；非论是在 Codex 照旧 Claude Code 中，其轮回逻辑都是一样的，因为底层的组件是同样的。
轮回仍然无法代劳的事项
轮回改造了职责方式，但并未将你从职责中剔除。事实上，跟着轮回才调的晋升，有三个问题反而会变得愈加难办，而非变得纰漏。
考证职责依然由你认真。一个无东谈主值守运行的轮回，也可能在无东谈主监督的情况下犯错。将考证子智能体与奉行子智能体分离开来，其主张恰是为了赋予轮回所声称的「已完成」情景以实质真理 —— 即便如斯，「已完成」也只是一种声明，而非可信的讲授。有句适用于 AI 期间代码审查的话：你的职责是寄托那些经你证据同平时运行的代码。
若是你疏于调养，你对代码的分解就会冉冉退化。轮回寄托非你亲手编写代码的速率越快，现存代码与你执行掌抓情况之间的鸿沟就越大。这就是「分解债务」（comprehension debt）；除非你躬行阅读轮回生成的代码，不然高效的轮回只会让这种债务蕴蓄得更快。
没错，那种看似空闲的情景往往伴跟着风险。当轮回自动运行时，东谈主很容易毁灭放心念念考，转而全盘接受它给出的结束。我称之为「领略战胜」（cognitive surrender）。盘算轮回时，若能保持判断力，它等于良方；若只是为了秘密念念考而盘算，它便成了加快恶化的催化剂 —— 同样的算作，结束却迥然相异。
构建轮回，遵守工程师执行。我合计这预示了咱们职责方式的演变场所。话虽如斯，若是我不躬行审查代码，或者完全依赖自动化轮回来栽种问题，产物的质料就会受损。我就怕会堕入恶性轮回，越陷越深。
天然，你不错入部属手构建这些轮回，但别忘了，胜利向智能体下达指示依然行之有用。环节在于找到安妥的均衡点。
同样的轮回机制，因使用者不同，结束也可能迥然相异。两个东谈主构建完全同样的轮回，可能会得出完全相悖的论断：一个东谈主愚弄它来加快处理我方深切分解的职责，而另一个东谈主则愚弄它来透顶逃避对职责的分解。轮回本人无法别离这两者，但你能。
正因如斯，盘算轮回比编写提醒词更具挑战性。
这是工程职责，并未变得更随性。并非职责本人变纰漏了，而是环节的杠杆点发生了回荡。
去构建这个轮回吧。但构建时开云的世界杯中国登录网址，要怀着一种「激越深耕工程界限」的心态，而不单是是作念一个只会按下启动键的东谈主。
备案号: