Claude Code Loop Engineering 深度研究报告
目录
1. 研究概述与核心发现
Claude Code 的 Loop Engineering 涵盖了三层循环架构，从底层核心到上层编排依次为：
| 层级 | 名称 | 定位 | 核心机制 |
|---|---|---|---|
| L1 | 核心 Agentic Loop | 每一次响应的执行循环 | Gather → Act → Verify 三阶段 |
| L2 | 调度循环系统 | 跨会话的任务调度 | /loop（cron）/ /goal（Stop hook）/ ScheduleWakeup（自适应） |
| L3 | 编排层 | 大规模多 Agent 编排 | Dynamic Workflow（JS 脚本隔离运行时） |
核心发现
-
Claude Code 本身是一个"agentic harness"，所有能力构建在模型推理 + 工具执行这两大支柱上。来源：How Claude Code Works
-
/loop 和 Dynamic Workflow 的根本差异在于控制权归属：/loop 由 Claude 自身控制循环迭代，每次迭代结果入上下文；Dynamic Workflow 将循环控制权外移到 JavaScript 脚本中，上下文只保留最终结果。来源：Workflows
-
三层调度机制并存（Cloud routines / Desktop tasks / /loop），各有不同的持久性、基础设施和范围约束。来源：Scheduled Tasks
-
Agent SDK 复用与 Claude Code 相同的核心执行循环。来源：Agent Loop
2. 核心 Agentic Loop：三阶段自适应循环
2.1 循环架构
Claude Code 的核心是一个三阶段自适应代理循环（adaptive agentic loop）：
┌─────────────────────────────────────────────────────┐ │ AGENTIC LOOP │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Gather │ ──→ │ Take │ ──→ │ Verify │ │ │ │ Context │ │ Action │ │ Results │ │ │ └──────────┘ └──────────┘ └──────────┘ │ │ ↑ │ │ │ └─────────── 循环 ──────────────────┘ │ │ │ │ 两大支柱: Models that reason + Tools that act │ └─────────────────────────────────────────────────────┘
三个阶段:
-
Gather Context: 收集当前任务的上下文信息（文件内容、搜索结果、对话历史等）
-
Take Action: 执行操作（读/写文件、运行命令、调用工具等）
-
Verify Results: 验证操作结果，判断是否需要继续修正或完成
该循环是非顺序自适应的（non-sequential and adaptive）——Claude 可以链式执行数十个操作，并根据上一步的结果动态修正路径。
来源: How Claude Code Works — 官方文档原文："Claude Code operates on a three-phase agentic loop: gather context, take action, and verify results."
2.2 两大支柱
官方文档明确指出循环由两个基础组件驱动：
-
Models that reason（推理模型）— 决定"下一步做什么"的核心智能
-
Tools that act（行动工具）— 执行具体操作的接口集合
Claude Code 本身被定义为"围绕 Claude 的 agentic harness"（the agentic harness around Claude），提供工具集、上下文管理和执行环境。这意味着开发者可以聚焦于工具的定义和任务的编排，而不是自己实现 agent 循环的脚手架代码。
来源: How Claude Code Works — "powered by two fundamental components: models that reason and tools that act" / "Claude Code serves as the 'agentic harness' providing tools, context management, and execution environment."
2.3 与传统执行过程的差异
| 维度 | 传统执行（CLI/VSCode 扩展） | Claude Code Agentic Loop |
|---|---|---|
| 执行模式 | 单次执行，输入→处理→输出 | 三阶段循环，多轮迭代直到完成 |
| 上下文管理 | 由用户手动维护 | 自动收集和整合上下文 |
| 错误处理 | 被动等待用户发现问题 | 主动 Verify 结果，自动修正 |
| 工具调用 | 用户手动触发 | Claude 自主决策调用工具 |
| 反馈整合 | 用户手动反馈 | 基于执行结果自动调整策略 |
来源: 综合自 How Claude Code Works — 文档描述了三阶段循环结构与传统的单次执行模式的根本差异。
2.4 与 Agent SDK 的关系
Agent SDK 运行与 Claude Code 完全相同的核心执行循环（the same execution loop that powers Claude Code）：
接收提示 → 评估/响应（文本或工具调用）→ 执行工具 → 重复（直到无工具调用）→ 返回结果
关键设计: max_turns 参数仅计数工具调用轮次，不计数最后的纯文本响应。例如设置 max_turns=4 时，Agent 可以执行 4 轮工具调用 → 第 5 轮纯文本响应实际不计数。
来源: Agent SDK - Agent Loop — 官方文档提供了完整的循环周期图示和代码示例。来源：Agent SDK
3. /loop 命令：会话级调度循环
3.1 机制架构
/loop 是 Claude Code 提供的会话级调度循环，基于 cron 调度的定时任务系统。它不是一个持续运行的守护进程，而是一个定时排队系统：调度器每秒检查一次，符合条件的提示以低优先级插入执行队列。
┌─────────────────────────────────────────────────────────┐ │ /loop 架构图 │ │ │ │ ┌───────────┐ ┌──────────────┐ ┌─────────────┐ │ │ │ 用户输入 │ │ Cron 调度器 │ │ Agentic │ │ │ │ /loop 5m │ ──→ │ (每秒检查) │ ──→ │ Loop 执行 │ │ │ │ <prompt> │ │ │ │ 响应 │ │ │ └───────────┘ └──────────────┘ └─────────────┘ │ │ │ │ │ ┌────┴────┐ │ │ │ 低优先级 │ │ │ │ 仅会话间 │ │ │ └─────────┘ │ └─────────────────────────────────────────────────────────┘
关键机制:
-
最小粒度: 1 分钟（cron 表达式的最小单位）
-
触发时机: 仅在 Claude 的两轮响应之间触发，不会中断正在进行的执行
-
优先级: 低优先级排队
-
无追赶: 错过的执行不会补跑
来源: Scheduled Tasks — "minimum interval is 1 minute"、"scheduled prompts fire between your turns, not while Claude is mid-response"、"scheduler checks every second and enqueues at low priority"、"No catch-up for missed fires."
3.2 两种使用模式
固定间隔模式
# 每隔 N 间隔执行一次 /loop 5m <prompt> # 每 5 分钟 /loop 1h <prompt> # 每小时 /loop 30s <prompt> # 秒级→向上取整到 1 分钟 /loop 1d <prompt> # 每天
单位支持: s（秒）、m（分）、h（时）、d（天）。秒级间隔会向上取整到最近的分钟。
自定节奏模式
# 不指定间隔，Claude 根据观察到的进度动态选择 1-60 分钟 /loop <prompt>
自定节奏模式使用 ScheduleWakeup 工具——Claude 根据"观察到的进度"（observed progress）动态决定唤醒间隔。例如如果检测到任务快速推进，可能选择 30 秒；如果任务进展缓慢或出错，可能等待更长时间。
来源: Scheduled Tasks — "Claude picks a delay between one minute and one hour based on what it observed." / "Self-paced /loop uses ScheduleWakeup."
3.3 生命周期
-
会话范围: /loop 仅在当前会话中存在
-
7 天自动过期: 每 7 天触发最后一次后自动删除——"This bounds how long a forgotten loop can run"
-
--resume/--continue: 未过期的任务会在恢复时带回
-
新会话: 起始新会话会清除所有 /loop 任务
-
版本要求: Claude Code v2.1.72+
来源: Scheduled Tasks — "Recurring tasks automatically expire 7 days after creation…this bounds how long a forgotten loop can run"、"Tasks are session-scoped."
3.4 使用场景
-
持续监控：定时检查 CI 状态、部署状态
-
数据采集：定时抓取网页、检查 API 变化
-
进度跟踪：长时间运行任务的周期性汇报
-
自动修复：检测到失败时自动执行修复操作
4. /goal 命令：目标驱动循环
4.1 机制架构
/goal 是对会话级 prompt-based Stop hook 的封装。它不依赖时间间隔，而是基于目标是否达成来决定是否继续执行。
┌──────────────────────────────────────────────────────────┐ │ /goal 架构图 │ │ │ │ ┌──────────┐ ┌──────────────┐ ┌────────────────┐ │ │ │ 用户设置 │ │ Claude 执行 │ │ Evaluator │ │ │ │ /goal │ ──→│ Agentic │ ──→│ (Small Fast │ │ │ │ <目标> │ │ Loop 响应 │ │ Model) │ │ │ └──────────┘ └──────────────┘ └────────────────┘ │ │ │ │ │ ┌────────┴────────┐ │ │ │ Yes → 停止 │ │ │ │ No → 继续 │ │ │ └─────────────────┘ │ └──────────────────────────────────────────────────────────┘
关键特性:
-
评估机制: 每次 Claude 完成一轮响应后，目标条件和当前对话被发送给用户配置的小型快速模型（默认 Haiku）
-
纯判断: 评估器不调用工具、不运行命令——只根据 Claude 已在对话中呈现的内容做"是/否"判断
-
输出: 判断结果 + 简短理由
来源: Goal — 官方文档明确："/goal is a wrapper around a session-scoped prompt-based Stop hook." / "Each time Claude finishes a turn, the condition and the conversation so far are sent to your configured small fast model, which defaults to Haiku." / "It does not call tools, so it can only judge what Claude has already surfaced in the conversation."
4.2 与 /loop 的区别
| 维度 | /goal | /loop |
|---|---|---|
| 触发条件 | 目标未达成 | 时间间隔到达 |
| 决策方 | 小型评估模型（默认 Haiku） | Cron 调度器 |
| 执行时机 | 每次 Claude 响应完成后 | 两轮响应之间，按固定或自适应间隔 |
| 终止条件 | 目标达成自动终止 | 7 天后自动过期或手动取消 |
| 版本要求 | v2.1.139+ | v2.1.72+ |
驳斥记录: 曾有一条"goal 和 loop 使用根本不同的触发机制：goal 每轮结束后触发，loop 按时间间隔触发"的声明在验证中被驳回（1-2 投票），因为该声明虽然描述了正确的功能差异，但其"不管前一轮是否完成"的说法与官方文档中"fire between your turns"的描述不符。
5. Agent SDK 执行循环
5.1 架构
Agent SDK 的 Agent Loop 复用与 Claude Code 相同的核心执行机制，但暴露为可编程 API：
┌───────────────────────────────────────────────────────┐ │ Agent SDK Agent Loop │ │ │ │ ┌──────────────┐ ┌─────────────────┐ │ │ │ Receive │ │ Evaluate & │ │ │ │ Prompt │ ──→│ Respond │ │ │ └──────────────┘ │ (text or tools) │ │ │ └────────┬────────┘ │ │ │ │ │ ┌────────▼────────┐ │ │ │ Tool Calls? │ │ │ └──┬───────────┬──┘ │ │ Yes │ │ No │ │ ┌─────▼───┐ ┌────▼────────┐ │ │ │ Execute │ │ Return │ │ │ │ Tools │ │ Result │ │ │ └──────┬──┘ └─────────────┘ │ │ │ │ │ ┌─────▼──────┐ │ │ │ max_turns │ │ │ │ Exceeded? │ │ │ └─────┬──────┘ │ │ No │ │ Yes │ │ ┌──────▼──┐ ┌─▼──────────────┐ │ │ │ Repeat │ │ Return Result │ │ │ └─────────┘ └────────────────┘ │ └───────────────────────────────────────────────────────┘
5.2 Subagent 上下文隔离
Agent SDK 的 subagent 采用完全隔离的上下文设计：
-
每个 subagent 以全新对话开始（无之前消息历史）
-
subagent 看不到父级对话的轮次
-
只有 subagent 的最终响应返回给父级作为工具结果
这一设计保证了主对话上下文的精简——子任务的中间过程不会膨胀父级上下文窗口。
来源: Agent SDK - Subagents — "Each subagent starts with a fresh conversation (no prior message history). It does not see the parent's turns, and only its final response returns to the parent as a tool result."
5.3 max_turns 计数规则
max_turns 参数仅计数工具调用轮次（tool-use turns），不计数最后的纯文本响应轮次。例如设置 max_turns=4 的真实含义：
| 轮次 | 动作 | 计数 |
|---|---|---|
| Round 1 | 调用工具 A | 1/4 |
| Round 2 | 调用工具 B | 2/4 |
| Round 3 | 调用工具 C | 3/4 |
| Round 4 | 调用工具 D | 4/4 → 触发终止 |
| Round 5 | 纯文本响应 | 不计入 |
来源: Agent SDK - Agent Loop — 官方文档提供了详细的 4-turn 计数示例。
6. Dynamic Workflow：大规模编排引擎
6.1 架构
Dynamic Workflow 是 Claude Code 提供的大规模多 Agent 编排引擎。它运行一个 JavaScript 脚本在隔离运行时中执行，脚本负责控制循环、分支和中间结果，而 Claude 的上下文窗口只保留最终答案。
┌───────────────────────────────────────────────────────────┐
│ Dynamic Workflow 架构 │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Claude 上下文（仅最终答案） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Workflow Runtime (隔离 JS 运行时) │ │
│ │ │ │
│ │ ┌──────────────────────────────────────────────┐ │ │
│ │ │ Workflow Script │ │ │
│ │ │ │ │ │
│ │ │ const results = await pipeline( │ │ │
│ │ │ items, │ │ │
│ │ │ item => agent(...), │ │ │
│ │ │ result => verify(...) │ │ │
│ │ │ ) │ │ │
│ │ │ return { confirmed } ← 仅最终答案回 Claude │ │ │
│ │ └──────────────────────────────────────────────┘ │ │
│ │ │ │ │
│ │ ┌───────┐ ┌───────┐ ┌──┴────┐ ┌───────┐ │ │
│ │ │Agent 1│ │Agent 2│ │Agent N│ │Agent 16│ (并发) │ │
│ │ └───────┘ └───────┘ └───────┘ └───────┘ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 约束: 最多 16 并发 / 总共 1000 agent / 全局 token budget │
└───────────────────────────────────────────────────────────┘
关键设计决策:
-
上下文隔离: 脚本变量持有循环、分支和中间结果，Claude 上下文只保留最终答案
-
运行时隔离: 工作流运行时在独立于对话的隔离环境中运行
-
确定性控制流: 使用 JavaScript 语法（for/while/if/switch）而非模型驱动决策
-
并发控制: 最多 16 个并发 agent（在有限 CPU 核心上可能更少）
-
总计上限: 单次运行最多 1000 个 agent
来源: Workflows — "A dynamic workflow is a JavaScript script that orchestrates subagents at scale." / Limits table: "Up to 16 concurrent agents" and "1,000 agents total per run." / "A workflow script holds the loop, the branching, and the intermediate results itself, so Claude's context holds only the final answer." / "The workflow runtime executes the script in an isolated environment, separate from your conversation."
6.2 可恢复性
Dynamic Workflow 支持同会话内恢复：如果暂停运行，已完成 agent 返回缓存结果，其余部分继续运行。但退出 Claude Code 后恢复会话将从头开始。
来源: Workflows — "If you stop a run, you can resume it: agents that already completed return their cached results, and the rest run live. If you exit Claude Code while a workflow is running, the next session starts the workflow fresh."
6.3 常用编排模式
官方文档和质量模式文档展示了以下常见模式（来源：Workflows）：
| 模式 | 描述 | 适用场景 |
|---|---|---|
| pipeline() | 默认模式——每个 item 经过所有阶段，无阶段间屏障 | 多阶段处理，墙钟时间=最慢单个 item 链 |
| parallel() | 并发执行 + Barrier——等待所有结果后再继续 | 需要全部结果后再进行去重/合并/决策 |
| Loop-until-dry | 连续生成直到 K 轮无新发现 | 漏洞挖掘、边缘情况搜索 |
| Loop-until-budget | 根据 token budget 动态控制深度 | 资源敏感的大规模搜索 |
| Adversarial verify | 每个发现由 N 个独立 skeptics 试图反驳 | 防止"看似合理但实际错误"的结论幸存 |
| Judge panel | 从不同角度生成 N 个独立方案，并行评分 | 方案空间广阔的设计决策 |
| Multi-modal sweep | 并行 agent 各自用不同搜索方式 | 单一搜索角度难以覆盖全貌的场景 |
7. 三大调度机制全景对比
Claude Code Desktop 提供了三种不同的调度机制，各有不同的持久性、基础设施和范围约束。
| 维度 | Cloud Routines | Desktop Scheduled Tasks | /loop (Session) |
|---|---|---|---|
| 运行位置 | Anthropic 云基础设施 | 本地机器 | 本地机器（当前会话） |
| 最小间隔 | 1 小时 | 1 分钟 | 1 分钟 |
| 机器离线 | ✅ 继续运行 | ❌ 跳过执行 | ❌ 会话结束则终止 |
| 跨会话持久 | ✅ 持久化 | ✅ 持久化 | ❌ 仅当前会话 |
| 文件系统访问 | ❌ 无（可能 fresh clone） | ✅ 有 | ✅ 继承自会话 |
| 权限模型 | 预先授予 | 同本地权限 | 继承自会话 |
| 创建方式 | Desktop UI / CLI | Desktop UI / CLI | /loop 命令 |
| API 触发 | ✅ REST API（beta header） | ❌ | ❌ |
| 保活机制 | N/A（云运行） | "保持唤醒"设置（合盖仍会休眠） | N/A（会话运行） |
| 状态 | 研究预览 | 正式功能 | 正式功能 |
Cloud Routines 的 API 触发端点需要 anthropic-beta: experimental-cc-routine-2026-04-01 头。
来源: Routines — "Routines execute on Anthropic-managed cloud infrastructure, so they keep working when your laptop is closed." / "The minimum interval for a custom cron schedule on a routine is one hour." / "Research preview." 来源: Desktop Scheduled Tasks — "Tasks only run while the desktop app is running and your computer is awake." 来源: Scheduled Tasks — 三种机制的完整对比表。
8. 传统执行过程对比
8.1 单次执行 vs Agentic Loop
| 维度 | 传统 CLI / API 调用 | Claude Code Agentic Loop |
|---|---|---|
| 执行流程 | 线性：输入 → 处理 → 输出 | 循环：Gather → Act → Verify（多轮迭代） |
| 决策方式 | 用户手动决策 | Claude 自主推理决策 |
| 工具调用 | 用户显式调用 | Claude 自主选择并调用 |
| 错误恢复 | 用户发现并修复 | 自动验证结果并在 Verify 阶段修正 |
| 上下文利用 | 用户手动维护 | 自动收集、整合、利用 |
| 反馈回路 | 用户在下一轮输入中反馈 | 在 Verify 阶段自动整合执行结果反馈 |
| 典型场景 | 单次代码生成、文件操作 | 多步骤代码修改、复杂调试、项目级重构 |
8.2 单 Agent vs Agent SDK Subagent
| 维度 | 单个 Agent | Subagent（Agent SDK） |
|---|---|---|
| 上下文窗口 | 全量对话历史 | 全新对话（无历史） |
| 返回值 | 流式 / 完整响应 | 仅最终响应返回给父级 |
| 工具访问 | 全部可用工具 | 可配置工具集 |
| 隔离性 | 共享父级上下文 | 完全隔离 |
8.3 手动编排 vs Dynamic Workflow
| 维度 | 手动编排（写代码 + 循环） | Dynamic Workflow |
|---|---|---|
| 循环控制 | 需手动实现 for/while 循环 | JS 脚本原生控制 |
| 并发管理 | 手动实现并发控制 | 内置并发管理（最多 16） |
| 错误处理 | 手动 try-catch | pipeline 中 stage 失败自动 drop 为 null |
| 上下文管理 | 需注意上下文膨胀 | 脚本持有中间结果，上下文只保留最终答案 |
| 可恢复性 | 完全不支持 | 同会话内自动支持 |
9. /loop 与 Dynamic Workflow 详细对比
9.1 根本架构差异
这是 Claude Code Loop Engineering 中最重要的架构对比：
/loop 模型: ┌─────────────────────┐ │ Claude 上下文 │ │ (持有循环状态+结果) │◄── 每轮迭代结果都入上下文 └──────────┬──────────┘ │ 控制循环 ┌───────────▼───────────┐ │ Claude 自身决定下一步 │ └───────────────────────┘ Dynamic Workflow 模型: ┌──────────────────────┐ │ Claude 上下文 │ │ (仅持有最终答案) │ └──────────────────────┘ ▲ 返回 ┌──────────────────────┐ │ Workflow Script │◄── 循环/分支/中间结果全在脚本变量 │ (隔离 JS 运行时) │ └──────────────────────┘ │ ┌────────────┼────────────┐ ▼ ▼ ▼ Agent 1 Agent 2 Agent N
核心差异: 控制权归属——/loop 由 Claude 驱动每一次迭代，而 Dynamic Workflow 将循环控制权外移到 JavaScript 脚本。
9.2 维度对比
| 维度 | /loop | Dynamic Workflow |
|---|---|---|
| 本质 | 会话级定时任务系统 | 大规模多 Agent 编排引擎 |
| 控制权 | Claude 自身控制循环 | JavaScript 脚本控制循环 |
| 上下文影响 | 每轮结果写入 Claude 上下文（可能膨胀） | 仅最终答案回到 Claude 上下文 |
| 并发 | 单线程（Claude 单次执行） | 最多 16 并发 agent |
| 规模上限 | 7 天自动过期 | 最多 1000 agent / 运行 |
| 隔离性 | 会话内执行 | 隔离 JS 运行时 |
| 决策方式 | 模型驱动（Claude 决定下一步） | 代码驱动（脚本控制流） |
| 可编程性 | 仅提示词模板 | 完整 JavaScript（条件/循环/变量） |
| 状态持久 | 会话范围内 | 同会话可恢复 |
| 使用场景 | 定时轮询、持续监控、简单周期性任务 | 大规模审计、多维度代码审查、复杂编排 |
| 创建方式 | /loop 5m <prompt> |
Workflow({script, ...}) |
| 版本要求 | v2.1.72+ | v2.1.154+（2026 年 W22 发布） |
9.3 场景选择指南
| 你的需求 | 推荐选择 | 原因 |
|---|---|---|
| 每隔几分钟检查一次 CI 状态 | /loop |
轻量、简单、无需编程 |
| 持续监控文件变化直到条件满足 | /goal |
目标驱动，时间不确定 |
| 对大量文件做多维度代码审查 | Dynamic Workflow | 需要并发和控制流 |
| 全量安全审计（100+ 文件） | Dynamic Workflow | 需要 1000 agent 上限 |
| 定时生成报告发到消息通道 | Cloud Routine | 需要云持久化 |
| 本地文件变化的周期性处理 | Desktop Scheduled Task | 需要文件系统访问且跨会话持久 |
10. 综合对比表
10.1 所有循环/调度机制一览
| 机制 | 类型 | 触发方式 | 持久性 | 并发 | 上限 | 版本要求 |
|---|---|---|---|---|---|---|
| Agentic Loop | 核心执行循环 | 每次响应的底层机制 | 内置 | 单线 | 无硬限制 | 全部 |
| /loop（固定间隔） | 调度循环 | Cron（最小 1 分钟） | 会话级，7 天过期 | 单线 | 7 天 | v2.1.72+ |
| /loop（自定节奏） | 调度循环 | ScheduleWakeup（1-60 分钟） | 会话级，7 天过期 | 单线 | 7 天 | v2.1.72+ |
| /goal | 目标驱动循环 | Stop hook + 评估模型 | 会话级 | 单线 | 目标达成 | v2.1.139+ |
| Cloud Routine | 云调度 | Cron（最小 1 小时）/ API | 跨会话持久 | 单线 | 研究预览 | v2.1.154+ |
| Desktop Task | 本地调度 | Cron（最小 1 分钟） | 跨会话持久 | 单线 | 无 | v2.1.154+ |
| Agent SDK Agent | 可编程执行循环 | 代码调用 | 调用周期 | 单线 | max_turns | v2.1.154+ |
| Dynamic Workflow | 大规模编排 | JS 脚本 | 同会话可恢复 | 最多 16 | 1000 agent | v2.1.154+ |
10.2 版本时间线
v2.1.72+ ── /loop 命令引入 / 会话级定时任务 v2.1.139+ ── /goal 命令引入 / Stop hook 评估器 v2.1.154+ ── Dynamic Workflow 引入 / Agent SDK / Cloud Routines / Desktop Tasks (2026 W22) （约 2026 年 5 月底）
11. 最佳实践与选择指南
11.1 选择合适的循环机制
需要什么类型的自动化？ ├── 单次响应内的自动迭代 → Agentic Loop（内置，无需配置） ├── 需要定时运行 │ ├── 云上持久、离开离线 → Cloud Routine（研究预览） │ ├── 本地持久、跨会话 → Desktop Scheduled Task │ └── 当前会话内简单轮询 → /loop ├── 条件驱动 │ └── 目标达成时停止 → /goal ├── 大规模多 Agent 编排 │ └── 需要并发、复杂控制和大量 Agent → Dynamic Workflow └── 可编程的 Agent 调用 └── 嵌入到自定义工具链 → Agent SDK
11.2 上下文管理策略
| 机制 | 上下文管理建议 |
|---|---|
| /loop | 提示词应保持简洁，避免每次迭代上下文膨胀；考虑使用 --resume/--continue 策略管理会话 |
| Dynamic Workflow | 充分利用脚本变量持有中间结果，只在最终答案返回给 Claude；使用 schema 参数获取结构化输出 |
| Subagent | 充分利用"仅最终响应返回"的设计，将中间处理留在 subagent 内部 |
| 大规模验证 | 推荐 Dynamic Workflow 的 pipeline + adversarial verify 模式，在每维度发布验证阶段不阻塞其他维度 |
11.3 避免常见陷阱
-
/loop 遗忘风险: 7 天自动过期是安全网，但长期自动化应考虑 Desktop Task 或 Cloud Routine
-
上下文膨胀: 长时间 /loop 可能导致上下文窗口被历史撑满——Dynamic Workflow 对此有天然免疫
-
合盖休眠: Desktop Task 在合盖时跳过执行，长时间自动化任务应使用 Cloud Routine
-
Dynamic Workflow 不可恢复性: 退出 Claude Code 后恢复会从头开始——确保关键工作流有 checkpoint 意识
-
版本兼容: Dynamic Workflow 需要 v2.1.154+（2026 年 5 月底之后），旧版本无法使用
12. 附录：来源清单
所有来源均为 code.claude.com 的官方一级文档，每条均被多个验证器交叉验证。
一级来源（19 个）
| # | URL | 角度贡献 | 声明数 |
|---|---|---|---|
| 1 | How Claude Code Works | 核心架构 | 5 |
| 2 | Scheduled Tasks | /loop 调度 | 5 |
| 3 | Tools Reference | 工具与调度器 | 5 |
| 4 | Goal | 目标驱动循环 | 5 |
| 5 | Agent SDK | 可编程 Agent | 5 |
| 6 | Agent SDK - Agent Loop | 循环周期 | 5 |
| 7 | Agent SDK - Subagents | 子 Agent 隔离 | 5 |
| 8 | Workflows | 动态工作流 | 5 |
| 9 | Routines | 云例程 | 5 |
| 10 | Desktop Scheduled Tasks | 桌面调度 | 5 |
| 11 | Building Effective Agents | 最佳实践 | 5 |
| 12-19 | 各文档 .md 格式版本（同上内容） | 交叉验证 | — |
更多推荐
9
0- 0
已为社区贡献7条内容
所有评论(0)