企业官网建设流程全解析

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

什么时候该继续往下做？

什么时候该停下来？

它怎么判断自己做对了？

哪些任务值得自动化循环，哪些一轮对话就够了？

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

基于轮次的循环
1

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

适用场景：短任务、临时任务，或者当你自己也还在探索、不确定下一步该怎么做的时候。

典型例子：“帮我加一个 like 按钮。”Claude 读代码、改代码、跑测试，然后吐出一个它认为完工的版本。接下来要不要继续，完全由你来判断。

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

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

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

SKILL 示例：

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
2

这个 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来创建长期定时日程。

主动循环
3

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

适用场景：重复、边界清晰、验收方式高度明确的工程管线。例如：Bug 报告初筛、Issue 分类、第三方依赖自动升级、过时 API 迁移、PR 自动化跟进。
/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.
上面这个是个示例，采用了以下组合：

用/schedule定时去扫外部的新反馈；

用/goal严格定义每次处理到什么程度才算合格；

用skills声明具体的验证和测试手段；

用dynamic workflows编排多个不同职责的 Agent 协同；

用auto mode让整个日程在不频繁打扰人类的前提下静默执行。

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

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

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

谁来触发？是用户手动发 Prompt，还是靠/goal里的评估器推着它往前走？是基于/loop设定的固定时间步长，还是等/schedule或外部的 Webhook 事件来唤醒？

什么时候停？是让模型自己判断收工，还是等测试全部通过、指标达到阈值？是看到 PR 被成功合并，还是单纯触达了你设定的最大尝试次数上限？

怎么控制质量与成本？

质量往往来自系统，而非单纯来自模型。代码库本身要干净，因为 Agent 极度擅长模仿已有代码；验证步骤也要严密，否则 Agent 很容易“钻空子作弊”绕过检查；另外，最好把 Code Review 交给一个全新上下文的 Agent，毕竟当局者迷，前一个 Agent 很容易陷入思维定势。

成本控制则需要策略。小任务就别上复杂的循环；能用小模型或者写个 Bash 脚本搞定的硬编码逻辑，就别让大模型每次去重新推理；在跑大面积的复杂流之前，先小范围 Pilot 试错；轮询间隔也要 match 任务变化的频率。如果数据一天才更新一次，真没必要每分钟去 poll 一次。

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

4