当你开始用 Coding Agent 写代码时往往会把它当成“高级版 ChatGPT”，仍然保持“一问一答”的习惯。你说这方面，“帮我加一个按钮。话说回来，”Agent 改完代码、跑了测试后回复搞定了。 你验收时发现细节不对，又补一句：“这里状态管理漏了再改一下。 ”这看似简单的交互，隐藏了一系列循环步骤，却仍然由人类紧握“方向盘”。

使用者痛点

• 验收依赖人工：每次改动后都要手动打开页面、点击按钮、检查控制台，耗时且易出错。
• 循环不透明：Agent 在内部做了读取、修改、测试、修复等多步，但开发者难以看到每一步的进度和依据。
• 缺乏停止准则：没有明确的“完成”标准，导致无限迭代或过早结束。
• 资源浪费：对简单任务使用复杂循环，会消耗不必要的模型算力和时间。

Loop 的本质定义

Claude Code 团队在《Getting started with loops》中给出的定义是：Agent 重复执行工作轮次直到满足预设的停止条件。真正的难点不是让模型回答一次而是让它具备工程感，包括：

• 何时继续往下做？
• 何时停下来？
• 它怎么判断自己做对了？
• 哪些任务值得自动化循环，哪些只需一轮对话？

基于轮次的循环

场景描述：最常见的模式——你发一个 prompt，Claude 完成一轮工作并把结果交还给你。

• 适用场景：短任务、临时需求或探索阶段。
• 典型例子：“帮我加一个 like 按钮。”Claude 读取代码、改代码、跑测试。接下来返回它认为完成的版本，由你决定是否继续。

痛点映射：

• 人工验收成本高——需要开发者逐一检查 UI、控制台和性能指标。
• 容易遗漏细节——如果没有统一的验收流程，容易出现状态管理漏掉等问题。

调整小技巧：把验收步骤写进 S K I L L . md让 Agent 能在闭环中自行完成部分验证。

S K I L L 示例：

---
至于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 way a human reviewer would:
- Start dev server and open edited page in browser.
- Interact with change directly. For a new control :
click it。confirm expected state change,and screenshot before/after.
- Check browser console: zero new errors or warnings.
- Use Chrome DevTools MCP,run a performance trace and audit Core Web Vitals.
If any step fails,fix issue and rerun from step — do not hand back partially verified work.

为什么要写 Skill？

指令，Agent 能在自己的执行链路里加入“人工验收”的步骤。从而减少人类介入频率，降低重复劳动带来的痛点。

基于目标的循环：/goal

主要思路：为任务设定明确、可量化的目标与停止条件，让 Agent 在每次迭代后评估是否已达标。

• 语法示例：/goal get homepage Lighthouse score to ≥90。stop after 5 tries.
• 适用场景：需要明确验收标准的任务，如全部单元测试通过、Lint 错误清零、Bug 不再复现或迁移脚本数据一致性校验。 不过，

对应痛点：

• No clear “done” definition → 无限迭代或过早结束。
• Lack of quantitative metrics → 难以自动判断成功与否。

/goal 的关键要素：

1. 使用代码或指标定义“完成”。
2. 设置最大尝试次数防止死循环。
3. L​oop 中每一次退出前都运行评估器检查目标达成情况。

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

场景特征：任务并非一次性完成。而是受外部状态持续影响，需要定期检查或响应变化。

• P​R 示例：/loop 5m check my PR,address review comments。and fix failing CI.
• P​R 场景：P​R 可能随时收到 Review 评论；CI/CD 流程可能延迟报错；Slack/Issue 队列持续涌入新反馈。

Pain Point 对应：

• A​gent 只能在触发时才工作 → 无法主动监控外部变化。T​ime‑based polling 如果间隔设置不合理，会导致资源浪费或响应迟缓。

  /loop 的局限性：

  • L​ocal terminal 必须保持开启；关机即终止循环，

  If you need a persistent cloud‑side solution,use /schedule,which creates long‑running cron‑like jobs that survive local shutdowns.

  主动循环

  This is ideal “always‑on” Agent workflow. It is triggered by system events or scheduled jobs,runs until its goal is met,n returns to idle state while staying resident in background.

  • A​pplicable scenarios: Bug triage automation,Issue classification,Dependency upgrades,API migration pipelines,PR follow‑up automation.

  /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 m.
  

  The above combines four building blocks:

  1. Create a periodic trigger with /schedule.
  2. Add a concrete success condition via /goal.
  3. Cite specific S K I L L S to guarantee quality.
  4. Select dynamic workflows that orchestrate multiple specialized Agents.
  5. Enable /auto mode ,allowing silent execution without frequent human interruptions.

  This shifts you from “I operate Agent” to “I design an autonomous Agent system.”

  常用方法

  The official advice is simple: “Keep it simple.” Over‑engineering dynamic workflows can quickly become unmanageable. Before building any loop,clarify se three foundational questions:

  1. "谁来触发？"
     • User manual prompt?
     Goal evaluator pushing forward? Fixed interval via /loop ? Webhook / schedule event?话说回来，
  2. "什么时候停？"
  3. "怎么控制质量与成本？"
     1. Quality comes from systematic checks rar than raw model output. Keep validation strict .
     2. Cost control strategies:
        • Small tasks → no complex loops.
        • Replace heavy model calls with lightweight scripts when possible.
        • Pilot‑test large flows on a subset first.
        • Align polling frequency with data change rate .

  Separate concerns – Let one Agent focus on implementation while anor performs an independent code review. * Explicit test suites – Embed unit / integration tests inside your Skill files so that failures automatically trigger revisions. * Metric thresholds – Define numeric thresholds instead of vague “looks good”。

  成本控制技巧

  • Task sizing – Only wrap loops around tasks that truly benefit from iteration.
  • Model selection – Use smaller models for simple lint/fmt fixes;reserve large models for architectural decisions.
  • Adaptive intervals – Dynamically adjust /loopinterval based on recent change frequency.
  < Li>

< Li>

html

⚠️ 实际落地建议：先挑一个最小可行 Loop。写好对应 Skill 验证，接下来逐步 到时间循环或主动循环。不要一开始就把所有环节堆在一起，否则调试成本会爆炸。