Claude官方教你用 Loop：如何让Claude Code上夜班的四个交接点¶

Ch09.079 Claude官方教你用 Loop：如何让Claude Code上夜班的四个交接点¶

📊 Level ⭐⭐ | 9.8KB | entities/claude官方教你用-loop如何让claude-code上夜班的四个交接点.md

Claude官方教你用 Loop：如何让Claude Code上夜班的四个交接点¶

Claude Code 官方工程师分享 Loop 工程在代码生成中的四个关键交接点：需求理解→方案设计→代码生成→验证修复，以及如何让 Claude Code 在无人值守下持续工作。

摘要¶

Claude Code 团队 2026 年 6 月 30 日发布官方博客 "Getting started with loops"，将 loop 分为四类：turn-based、goal-based、time-based、proactive。本文以"人从哪一步退出来，退出来之前留下些什么"为主线，解读四种 loop 对应的人机协作交接点：先把检查写成 Skill，再用 /goal 定义停止条件，用 /loop 处理短期等待，最后用 /schedule 和 routine 完成长期任务编排。

核心要点¶

Loop 工程的核心不是让 Agent 多跑几轮，而是人从哪个位置退出来，每退一步系统都要补上一段更清楚的工程边界
四种 loop 类型对应四个工程交接点：检查（Skill）→ 停止（/goal）→ 等待（/loop）→ 决策（/schedule & routine）
/goal 的评估器不读文件也不跑命令，只评估对话中的内容——验证证据必须暴露给评估器可见
/loop 是会话内本地调度，适合"少切几次窗口"，不适合企业级长期任务
Routine 运行时没有权限确认提示，身份、权限、审计和责任边界成为 main problem

四个交接点¶

交接点一：先交检查（Skill）¶

第一步不是让 Claude Code "自己一直干"，而是先把验证标准写下来。官方推荐的实践是创建 PR 验收 Skill，包含六项检查：运行受影响区域的测试、运行 lint/typecheck、UI 变更时启动应用截图对比、检查浏览器 console 或服务日志、修复失败步骤并重验、最终输出命令/退出码/日志。

不先把检查步骤写成资产，后面的自动循环就没有地基。Agent 可以跑得很勤快，但每轮结束时仍然会回到同一个问题：它到底按什么标准说自己做完了？

交接点二：交停止条件（/goal）¶

/goal 的核心设计是"评估器与执行器分离"——每轮结束后由一个独立的评估模型判断目标是否达成。但它有两个重要边界：

评估器不会自己读文件或跑命令——只能看 Claude 已经放进对话里的内容
评估器不是全知裁判，所以更稳妥的方式是让 /goal 同时输出证据链

写好 /goal 的关键是同时定义"证据"和"刹车"：测试通过、lint 干净、diff 不越界是证据；最多 N 轮、连续无新增证据就停是刹车。

交接点三：交等待触发（/loop）¶

/loop 适合"我现在打开着这个任务，想让 Claude 过一会儿再看"的场景。它可以固定间隔跑，也可以由 Claude 根据当前情况动态选择下一次检查时间。动态 /loop 有时会用 Monitor 工具，靠常驻脚本持续拿输出，避免反复用 prompt 轮询。

但 /loop 的边界很清楚：它是会话级任务，关闭终端、开始新会话、过期机制都会影响它。需要脱离当前会话长期运行，就要看 routines、桌面定时任务或者 GitHub Actions。

交接点四：交身份与权限（/schedule + routine）¶

Routine 是一份保存下来的 Claude Code 配置：prompt、仓库、环境、连接器和触发器。它能按时间跑，也能被 API 或 GitHub 事件触发。这里最容易被忽略的是：routine 运行时没有权限确认提示，它通过创建者连接的身份做事——创建的分支、PR、Slack 消息会体现为创建者的账号动作。

因此，在实际使用 routine 前需要回答一系列"不酷但决定安全"的问题：是否只允许特定前缀分支、哪些 connector 被包含、网络访问范围是否受限、每次运行结果写到哪里、超过预算/连续失败时是停止还是通知人。

深度分析¶

Loop 的委托阶梯：从对话质量到授权执行¶

Claude Code 官方文章表面在讲四类 loop，实际在揭示一条更深的主线：当 Agent 从本地会话走向 routine，系统边界就从"对话质量"变成了"授权后的执行行为"。这个过程形成一个委托阶梯——每一级都改变了人与系统之间的关系性质。

层级	机制	委托什么	边界变化
L1	Skill	检查标准	团队验收规范资产化
L2	/goal	停止条件	评估器与执行器分离
L3	/loop	等待时机	短期自动化，会话级
L4	/schedule + routine	完整任务	身份、权限、审计进入系统
L5	Dynamic Workflows	决策流程	多 Agent 编排，需要独立复核

这个阶梯最有价值的洞察是：每一级委托都需要上一级的产物作为前提——没有 Skill 定义的检查标准，/goal 就无法判断完成；没有 /goal 定义的停止条件，/loop 就不知道何时停；没有 loop 的稳定运行数据，routine 就没有可信的基线。

Dynamic Workflows 的工程含义¶

Dynamic workflows 是官方博客中最容易被低估的部分。它把编排计划从 Claude 的上下文里挪到由 Claude 写出的 JavaScript 脚本中，由 runtime 执行，可以编排大量 subagents，并保留阶段、中间结果和交叉验证。

这意味着：这不是在一个聊天窗口里临场调度，而是真正的"可复用自动化工程"。但其反作用是——并发 Agent 越多，token 消耗、结果审查、文件冲突、权限风险和人类复核压力都会一起上涨。官方博客也提醒，dynamic workflows 可能启动大量 Agent，先小规模试跑再放量。

成本与可靠性视角¶

文章中提及的 /usage、/goal 状态和 /workflows 工具暗示了 Claude Code 正在从交互式编码助手向任务运行系统演进。但越像任务运行系统，越不能只靠 prompt 写得好不好——它需要权限、日志、状态、队列、成本、复核、降级和人工接手这些"传统"的工程基础设施。

一个能长期跑的 loop，最后要看两件事：它怎么自动开始，以及它能不能在证据不足、权限越界、成本异常和结果不可信的时候停下来。

实践启示¶

先写 Skill，再写 prompt——把团队的验收标准写成可复用的 Skill 资产，是 Agent 自动化的地基。没有明确的检查标准，Agent 跑多少轮都无法自证完成
/goal 要同时定义"证据"和"刹车"——"最多 8 轮"+"连续两轮无新增证据就停"的约束比单纯的"完成目标"更可操作，也更容易事后审查
/loop 适合少切窗口，不适合企业级长期任务——正确使用场景是"当前会话还在、本机环境还需要、外部状态会变化"，错误的使用场景是跨天/跨重启的持久化任务
Routine 安全边界先于功能实现——在设置 routine 前回答：它只能开特定前缀分支吗？它包含哪些 connector？网络范围是否受限？超过预算/连续失败时怎么办？
逐步委托，每退一步留一条证据链——从 Skill → /goal → /loop → /schedule 循序渐进，每一级输出命令、退出码、改动范围、失败路径和未解决风险。第二天早上看的不是"done"，而是完整的 transcript 和 diff

关联条目¶

Harness 即后端：当 Agent 基础设施消解于统一原语 — Loop Engineering 的底层架构视角
Agent 落地真相 — Agent 从可用到可靠的生产化路径
Skill Hub MVP 评估与发布 — Skill 生命周期管理的工程实践
Skill 编排的六大依赖 — Skill 间的依赖与编排模式

退出¶

→ 原文存档