当你开始用 Coding Agent 写代码时，会非常容易把它当成一个“高级版 ChatGPT”来用——依旧维持着“一问一答”的习惯。

举个例子，你和它说：“帮我加一个按钮。”Agent 改完代码，跑了测试，回复说搞定了。你一验收，发现细节不对，就又补一句：“这里状态管理漏了，再改一下。”

这其实是一个简化的 Agent loop。Claude / Codex 在执行你那句简单指令时，背后已经默默做了一连串动作：读取代码 $$\rightarro$$ 做出修改 $$\rightarro$$ 检查结果 $$\rightarro$$ 发现问题 $$\rightarro$$ 继续修复。只是在这个阶段，整个循环的“方向盘”依然死死握在你的手里。

Claude Code 团队在最新的文章《Getting started with loops》中，对 loop 给出了一个很纯粹的定义：Agent 重复执行一轮轮工作，直到满足某个停止条件。

毕竟在 Agent 工程落地时，真正的难点一般不是“如何让模型回答一次”，而是如何让它拥有以下工程感：

- 什么时候该继续往下做？
    
- 什么时候该停下来？
    
- 它怎么判断自己做对了？
    
- 哪些任务值得自动化循环，哪些一轮对话就够了？
    

为了理清这些问题，Claude Code 把 loop 细分成了四种类型。我们不妨来看看它们分别解决什么场景下的问题。

## 基于轮次的循环

![](https://developer.qcloudimg.com/http-save/yehe-12464096/1524a651df5e6fdf6728da18f1797993.png)

这是最常见的模式。你发一个 prompt，Claude 做一轮工作，然后把结果交还给你。

- 适用场景：短任务、临时任务，或者当你自己也还在探索、不确定下一步该怎么做的时候。
    
- 典型例子：“帮我加一个 like 按钮。”Claude 读代码、改代码、跑测试，然后吐出一个它认为完工的版本。接下来要不要继续，完全由你来判断。
    

缺点：这种方式虽然简单，但验收极其依赖人工。你需要亲自去看页面、点按钮、查控制台、看截图，然后再把反馈喂给 Agent。

优化小技巧：把验收步骤写进`SKILL.md`。

以前端改动为例，文档要明确 UI 改动不能只看代码有没有改完，必须启动 dev server、打开页面、模拟点击、检查 console 报错，必要时跑一遍性能 trace。这样，Agent 就能把一部分“人工验收动作”写进自己的闭环里。

SKILL 示例：

```YAML
--- 
name: verify-frontend-change 
description: Verify any UI change end-to-end before declaring it done. 
--- 

# Verifying frontend changes 
Never report a UI change as complete based on a successful edit alone. Verify it the way a human reviewer would: 

1. Start the dev server and open the edited page in the browser. 

2. Interact with the change directly. For a new control (button, input, toggle): click it, confirm the expected state change, and screenshot before/after. 

3. Check the browser console: zero new errors or warnings. 

4. Use the Chrome Devtools MCP, run a performance trace and audit Core Web Vitals.

If any step fails, fix the issue and rerun from step 1 — do not hand back partially verified work.
```

## 基于目标的循环：`/goal`

![](https://developer.qcloudimg.com/http-save/yehe-12464096/92afae4339952837ee8b384142ca2333.png)

这个 loop 主要解决一轮对话绝对搞不定，但你心里很清楚“什么样才算做好了”的那些任务。

- 语法示例：`/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.`
    
- 适用场景：有明确、可量化验收标准的任务。比如测试全部通过、Lint 错误清零、某个 Bug 无法复现、或者迁移脚本跑完且两端数据一致。
    

在这里，你交给 Agent 的不只是一个任务，还包含了一个停止条件。它不用自己去猜“是不是差不多可以收工了”，每次想退出时，都会通过评估器检查目标是否达成。达成了就停，没达成就继续调整代码，直到触发目标或达到你设定的最大尝试次数，上面的示例就设置为尝试 5 次。

**/goal 的核心逻辑是要用代码或指标定义清楚“什么叫完成了”。**

## 基于时间的循环：`/loop` 与 `/schedule`

这一类循环的重点不在于“完成标准”，而在于外部环境的触发方式。很多任务不是你当下问一次就行了，因为外部状态在不断变化：

- 提交的 PR 随时可能有人提 review comments；
    
- CI/CD 流程可能过几分钟才会报错；
    
- Slack 或 Issue 队列里持续有新的反馈涌入。
    

这时你可以用`/loop`让 Claude 按照固定的时间间隔，重复执行同一个 prompt。

- 语法示例：`/loop 5m check my PR, address review comments, and fix failing CI`
    

上面这个示例的意思是每 5 分钟检查一次 PR，有评论就回复/修改，CI 挂了就去修。

`/loop`命令运行在你本地电脑的终端，电脑一关循环就断了。如果你希望它在云端全天候运行，推荐使用`/schedule`来创建长期定时日程。

## 主动循环

![](https://developer.qcloudimg.com/http-save/yehe-12464096/af086d54327faf6471946a562623d396.png)

这个循环很接近理想中的“长期运行的 Agent 工作流”。它由特定的系统事件或定时日程触发，不用你坐在电脑前盯着。每次触发后，它会在目标达成时自动退出，但这个 Routine 本身会一直常驻在后台，直到你手动关闭它。

- 适用场景：重复、边界清晰、验收方式高度明确的工程管线。例如：Bug 报告初筛、Issue 分类、第三方依赖自动升级、过时 API 迁移、PR 自动化跟进。
    

```Bash
/schedule every hour: check #project-feedback for bug reports. /goal: don't stop until every report found this run is triaged, actioned, and responded to. When fixing a bug, use a workflow to explore three solutions in parallel worktrees and have a judge adversarially review them.
```

上面这个是个示例，采用了以下组合：

1. 用`/schedule`定时去扫外部的新反馈；
    
2. 用`/goal`严格定义每次处理到什么程度才算合格；
    
3. 用`skills`声明具体的验证和测试手段；
    
4. 用`dynamic workflows`编排多个不同职责的 Agent 协同；
    
5. 用`auto mode`让整个日程在不频繁打扰人类的前提下静默执行。
    

来完成了从“我来操作 Agent”到“我来设计 Agent 系统”的转变。

## 最佳实践

看着上面这些实操性很强的 Tips，你可能已经跃跃欲试了。不过先别急着大干一场，Claude 官方在这里特别提了一嘴：“Keep it simple.”——也就是优先用最简单的方案来设计 Agent 系统。

很多团队刚接触这些概念，很容易一上来就堆复杂的动态工作流或者多 Agent 协同，这会把系统搞得不可控。在动手设计任何一个 Loop 之前，作为设计者的你，只要能把下面这三个底层问题想清楚，逻辑自然就顺了：

1. **谁来触发？**是用户手动发 Prompt，还是靠`/goal`里的评估器推着它往前走？是基于`/loop`设定的固定时间步长，还是等`/schedule`或外部的 Webhook 事件来唤醒？
    
2. **什么时候停？**是让模型自己判断收工，还是等测试全部通过、指标达到阈值？是看到 PR 被成功合并，还是单纯触达了你设定的最大尝试次数上限？
    
3. **怎么控制质量与成本？**
    
    1. 质量往往来自系统，而非单纯来自模型。代码库本身要干净，因为 Agent 极度擅长模仿已有代码；验证步骤也要严密，否则 Agent 很容易“钻空子作弊”绕过检查；另外，最好把 Code Review 交给一个全新上下文的 Agent，毕竟当局者迷，前一个 Agent 很容易陷入思维定势。
        
    2. 成本控制则需要策略。小任务就别上复杂的循环；能用小模型或者写个 Bash 脚本搞定的硬编码逻辑，就别让大模型每次去重新推理；在跑大面积的复杂流之前，先小范围 Pilot 试错；轮询间隔也要 match 任务变化的频率。如果数据一天才更新一次，真没必要每分钟去 poll 一次。
        

## 总结

所以，读完这篇文章，最不重要的其实是具体命令的参数，最重要的是这张 Agent Loop 场景选择指南：

![](https://developer.qcloudimg.com/http-save/yehe-12464096/a2725c4400107e802e82b89d804bed6f.png)

Agent 工程的本质，并不是去写一段更长、更完美的 Prompt。

它是从这三个底层问题开始的：触发条件是什么？停止条件是什么？验证方式是什么？当你把这三个工程问题想透的时候，Agent 就不再只是聊天框里陪你唠嗑的 AI，而是真正能帮你跑通自动化流水线的虚拟队友了。

当你开始用 Coding Agent 写代码时，会非常容易把它当成一个“高级版 ChatGPT”来用——依旧维持着“一问一答”的习惯。

loop 最佳实践：从 /goal 到 /loop，让 Agent 工作流循环起来

本文详解Coding Agent的四种核心循环模式：基于轮次（人工驱动）、目标导向（/goal）、时间触发（/loop与/schedule）及主动循环，强调Agent工程的关键在于明确“谁触发、何时停、如何验”，而非仅优化Prompt。

人工智能

开发工具

编程语言

CodingAgent提供四种循环模式优化开发流程：基于轮次的简单任务处理、基于目标的量化标准执行、基于时间的定时检查以及主动触发的长期工作流。文章强调设计Agent系统时要明确触发条件、停止条件和验证方式，建议从简单方案入手，逐步构建自动化开发流水线。

代码解释

ChatGPT

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

loop 最佳实践：从 /goal 到 /loop，让 Agent 工作流循环起来-腾讯云开发者社区-腾讯云

loop 最佳实践：从 /goal 到 /loop，让 Agent 工作流循环起来

loop 最佳实践：从 /goal 到 /loop，让 Agent 工作流循环起来

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐