内容来源：X 社区文章引用材料。https://x.com/mvanhorn/status/2064887887578136666
作者：@mvanhorn
原发布时间：2026-06-11

Long-running agent workflow source cover

Claude Code 长任务工作流：目标、预算和停止条件

Claude Code 越强，越容易让人把任务交得更大：修一个复杂 bug、重构一组模块、补齐测试、做一次 UI 改版、自动生成文档，甚至让它连续跑几个小时。

长任务不是短任务的简单放大。短任务里，Claude Code 只需要理解一个局部目标；长任务里，它还要持续管理上下文、判断优先级、避免跑偏、控制成本，并知道什么时候该停。

这篇社区资料虽然不是 Claude Code 专文，但里面关于长时间 Agent 工作流的几个观点，适合整理进 Claude Code 专区：不要只给步骤，要给目标；不要只看输出，要给停止条件；不要默认最大投入，要管理预算。

用结果目标，而不是手把手步骤

很多人写长任务提示词时，会把每一步都拆得很细。这样看起来安全，但也会把模型限制在你预设的路径里。路径一旦错了，Claude Code 会很认真地沿着错误路径执行。

更好的方式是给结果目标和边界：

  • 最终要达到什么状态；
  • 哪些文件或模块属于范围内；
  • 哪些行为不能改变；
  • 允许 Claude 自己选择实现路径；
  • 每个阶段都要给出证据。

例如，不要只写：

先改 A 文件，再改 B 文件，然后加测试。

可以改成：

目标是让订单导出支持按状态筛选。保持现有导出格式不变，不改动支付逻辑。你可以先探索代码再提出计划。实现后运行相关测试，并说明哪些行为被验证。

这样 Claude Code 有空间做工程判断，同时不会失去任务边界。

长任务必须有停止条件

长任务最危险的不是失败，而是无休止地“继续尝试”。Claude Code 如果没有停止条件，可能会不断读文件、改实现、跑测试、修新问题，最后上下文变长、成本升高、结果也不一定更好。

停止条件可以是：

  • 指定测试通过；
  • 构建通过；
  • 页面截图符合目标；
  • bug 复现脚本不再失败；
  • 产出指定数量的文档；
  • 达到时间或 token 上限；
  • 连续两轮没有实质进展就停下汇报。

对于 Claude Code，可以在提示词里明确写：

如果连续两次尝试后同一个测试仍失败，不要继续猜。停止修改，输出你已经验证的信息、可能根因和下一步建议。

这比让它无限重试更可靠。

给预算，而不是默认“尽力而为”

“尽力而为”对人类听起来积极，但对 Agent 来说可能意味着不可控成本。

长任务最好提前定义预算：

  • 最多探索多少文件；
  • 最多改多少个模块；
  • 最多跑几轮；
  • 是否允许安装依赖；
  • 是否允许访问外部服务；
  • 是否允许做破坏性操作；
  • 如果超出范围，必须先询问。

例如：

先用 10 分钟探索，不做修改。只读相关路由、service 和测试。探索结束后给计划，我确认后再实现。

或者：

这次只修复失败测试，不做架构重构。如果发现需要大改，先停下来说明原因。

预算不是为了限制模型能力，而是让任务可以被管理。

强模型做编排，便宜模型做执行

长任务里，不同阶段对模型能力的要求不同。

高价值阶段通常包括：

  • 理解复杂需求；
  • 做架构取舍；
  • 判断根因；
  • 设计验证方式；
  • 复盘失败路径。

这些阶段适合更强的模型。相对明确的执行阶段，例如批量改文案、补测试样例、整理文档、按模板生成文件，则可以交给更快或成本更低的模型。

在 Claude Code 工作流里，可以把这种思路写进任务：

  • 先让强模型规划；
  • 规划确认后再执行；
  • 执行完成后用独立上下文复核；
  • 最终由人查看 diff 和验证证据。

这不是为了省每一分钱，而是避免把强推理模型浪费在机械执行上，也避免让执行模型承担复杂判断。

调整努力程度，而不是永远拉满

长任务不等于每一步都要最高强度思考。对于简单文件整理、格式转换、固定模板输出，过高推理投入可能只会增加延迟和成本。

可以按任务类型调整：

  • 探索和设计：高投入；
  • 批量机械修改：中低投入；
  • 验证和审查：中高投入；
  • 总结和归档：中低投入。

如果平台支持 effort 或 thinking 相关设置，可以结合任务阶段调整。即使不支持，也可以在提示词里表达：

这个阶段只做机械替换，不要引入额外抽象。

或者：

这个阶段需要先深入分析根因，不要急着改代码。

用截图作为高密度 UI 上下文

视觉任务只靠文字描述，往往很难说清楚。截图可以一次性传达布局、间距、层级、颜色、状态和错误位置。

对 Claude Code 做前端任务时，建议把截图纳入工作流：

  • 修改前截图；
  • 目标设计截图；
  • 修改后截图；
  • 差异说明；
  • 再修改。

如果可以配合 Playwright 截图和像素检查，Claude Code 就能把“看起来不对”变成更具体的验证信号。

Agent UI context source image

给真实业务上下文，而不是玩具任务

长任务 Agent 的价值，通常来自真实业务上下文。让 Claude Code 处理玩具 demo，它可能能展示能力，但很难发现真正有价值的自动化机会。

更好的方式是给它真实材料：

  • 最近的用户反馈；
  • 线上错误日志；
  • 客服工单；
  • 产品指标；
  • 设计稿；
  • 历史 PR；
  • 团队发布记录。

然后让它回答：

这里面有哪些高杠杆、低风险、适合 Claude Code 先自动化处理的工作？

这样 Claude Code 不只是执行任务，还能帮助团队发现哪些流程值得被自动化。

把成功长任务沉淀成 Skills

长任务如果跑成功了，不要只停留在一次会话里。应该把成功路径沉淀下来：

  • 起始提示词；
  • 必要上下文；
  • 读取哪些文件；
  • 验证命令；
  • 停止条件；
  • 常见失败；
  • 人工确认点。

这些内容可以变成 Claude Code Skill、slash command、CLAUDE.md 规则或内部 runbook。下一次同类任务就不需要重新摸索。

对团队来说，这是从“个人会用 Claude Code”走向“团队拥有 Claude Code 工作流资产”的关键。

长任务提示词模板

可以从这个模板开始：

目标：
请完成 [具体结果]。

范围：
只处理 [目录/模块/功能]，不要改动 [明确排除项]。

流程：
1. 先探索代码和相关上下文，不要修改文件。
2. 输出计划、风险和验证方式。
3. 我确认后再实现。
4. 实现后运行验证，并给出证据。

预算：
如果连续两轮没有进展，或发现需要超出范围的大改，请停止并汇报。

完成标准：
[测试/构建/截图/文档/人工确认标准]。

这个模板的重点不是格式，而是让 Claude Code 同时看到目标、边界、预算和停止条件。

小结

Claude Code 长任务工作流的核心，不是让模型“多努力”，而是让它在正确边界内持续推进。

可靠的长任务应该具备：

  • 清晰结果目标；
  • 明确范围；
  • 可执行计划；
  • 成本和时间预算；
  • 停止条件；
  • 验证证据；
  • 成功后沉淀为可复用工作流。

如果没有这些约束，长会话很容易变成昂贵的试错循环。反过来，一旦目标、预算和验证都清楚，Claude Code 就可以承担更长、更复杂、更接近真实工作的任务。