AI Agent 的"敏捷开发"：为什么你的 Loop 需要 Sprint？

基础 Loop Engineering 让 Agent 自己能跑了。但面对 30 个模块、3 年周期的复杂项目，一个 Loop 跑到底会怎样？答案是：Sprint 6 之后，Loop 本身会成为瓶颈。本文提出 Sprint Loop Framework（SLF）——用敏捷 Sprint 的方式设计 Loop，让每个阶段有独立的验收标准、约束边界和退出策略。

一个被忽视的问题

2026 年 6 月，Loop Engineering 爆发了。

LangChain 发表了《The Art of Loop Engineering》，提出四层循环架构。Claude Code 推出了 /loop和 /goal命令。Qoder 发布了 Quest Goal 模式。各行各业都在说同一句话："不要再手动给 Agent 写 Prompt 了，设计一个循环让它自己跑。"

基础模型很简单，也很有效：

Agent 干活 → Grade 检查 → 不通过 → 带反馈重试 → 通过 → 交付

我自己在文档生成、合同生成等单模块场景中试过，效果确实不错。

但后来我开始思考一个问题：如果一个项目有 30 个模块、跨越 3 年、分成 36 个 Sprint，一个 Loop 从头跑到尾会怎样？

答案是：

• Sprint 1（3 个模块，150 个 Grade 检查点）：跑得动
• Sprint 12（10 个模块，350 个检查点）：每次回归跑 15 分钟
• Sprint 33（全部模块，900+ 个检查点）：Loop 本身成了瓶颈。Agent 改一行代码，触发 900 个检查，3 个不通过，反馈信息 300 行——Agent 根本不知道该修哪个。

不拆分的结果：Loop 随项目线性增长，维护成本指数增长。

这就是基础 Loop Engineering 没回答的问题。LangChain 的四层循环假设 Trace 数据能自动驱动 Loop 改进，但在复杂项目中，Trace 不能告诉你"Sprint 10 应该加什么检查"——那是 Sprint 目标决定的。

Sprint Loop Framework：四个核心原则

我提出来了一个方案：Sprint Loop Framework（SLF）。它把敏捷开发的 Sprint 理念和 Loop Engineering 结合起来。四个核心原则：

原则 1：Sprint 目标驱动，非 Trace 数据驱动

基础 LE 的假设是 Trace 数据自动分析 → 自动改进 Loop。这在复杂项目中不成立。正确的顺序是：先有 Sprint 目标（本 Sprint 要交付什么功能），再根据目标设计 Loop（需要什么 Skills、Harness、Grade）。Trace 数据是 Sprint 回顾的素材，不是 Sprint 的驱动者。

原则 2：每个 Sprint 独立设计四要素

每个 Sprint 需要明确定义：

• Skills（Agent 需要知道什么）——新增的技术知识 + 继承自之前 Sprint 的知识
• Harness（Agent 不能做什么）——新增的约束 + 继承的约束
• Grade（怎么验证做对了）——本 Sprint 的新增检查 + 对之前 Sprint 核心路径的回归
• Loop（失败后怎么处理）——重试策略、熔断条件、退出后的问题解决流程

原则 3：Loop 策略随项目 Phase 演进

不是一种策略跑到底。不同的项目阶段，Loop 的行为应该不同：

Phase 1（探索期）：激进重试，宽容熔断
  目的：大量试错，收集 Agent 的失败模式

Phase 2（成长期）：关键路径重试，性能/误报不重试
  目的：核心功能可靠，边缘 case 人工判断

Phase 3（成熟期）：保守重试，严格熔断
  目的：稳定压倒一切，任何退化立即停止

Phase 4（自治期）：极少重试，ML 相关问题不重试
  目的：Agent 只做确定性工作，不确定的升级给人

原则 4：退出不是"升级给人"，是一条多路径流程

传统 Loop 的退出模型只有一条路："重试 3 次 → 失败 → 升级给人"。这不符合人的实际工作方式。

人遇到复杂问题时，不会卡在原地死磕。人的做法是：先记录到 TODO，不阻塞当前工作；然后拉个专题讨论，从多个角度分析；找到一个 90% 的方案就先用着；剩下的 10% 留到下个版本。

所以 SLF 的退出流程是这样的：

重试 3 次仍不通过 →
  记录 TODO List（不阻塞当前 Sprint）
  → 已知故障模式：自动修复
  → 未知故障：多 Agent 议会（安全/架构/性能/产品 + 批评者）
  → 方案选择：
     ≥90% 解决 → 自动执行
     80-90% → 执行 + 剩余标记"已知限制"，传入下个 Sprint
     <80% → 生成分析报告，提交给人决策

关键变化：人不被 Agent 的失败打断。人只在决策点介入，而且收到的是分析报告，不是错误堆栈。

一切从 Landing Zone 开始

每个 Sprint 启动前，Agent 需要加载一个"出发区"——我称之为 Landing Zone。这个概念来自我之前在腾讯云发表的《Spec Coding 的 Landing Zone》一文。

Landing Zone 包含四个部分，每部分派生出 Loop 的不同组件：

这里有一个关键发现：Grade 的约 70% 可以直接从 Spec的 API契约自动生成。人写 Spec，大部分 curl + 断言不需要手写。Spec 变了，Grade 自动跟着变。Spec 的 API 和 Grade 是 1:1 映射。

但 Spec 不是唯一来源。约 30% 的 Grade 来源是安全最佳实践和团队编码规范——这些东西 Spec 通常不会写。比如"API 响应中不要返回 password_hash"、"不要在日志中打印密码"、"不用 bare except"——这些来自安全经验和团队约定，不来自 Spec。

一个具体例子

拿电商系统来说。我选择了电商作为 SLF 的示例项目——因为每个人都能理解对错，模块边界清晰，且每个模块可独立验证（API 请求 + 断言即可）。

项目拆分 12 个 Sprint：

Sprint 1-2:  用户模块     注册、登录、JWT、个人信息
Sprint 3-4:  商品模块     CRUD、分类、搜索、SKU
Sprint 5-6:  购物车       增删改、价格校验、库存校验
Sprint 7-8:  订单模块     创建、状态流转、取消、退款
Sprint 9-10: 库存模块     入库/出库、防超卖、预警
Sprint 11-12: 管理后台    审核、订单管理、报表

以 Sprint 1 为例，看看实际文件是什么。

Step 0：Landing Zone

技术栈: Python + Flask + SQLite + JWT + bcrypt
API:    POST /api/user/register → 200 + {user_id}
        POST /api/user/login → 200 + {token}
安全:   密码 bcrypt 加密 / JWT_SECRET 从环境变量取 / SQL 参数化
规范:   统一响应 {code, data, message} / 蛇形命名
范围:   只做注册+登录，不做个人信息管理和地址管理

Step 1-5：约束文件（按顺序编写）

01-grade.py              ← 从 API 契约派生：12 个 curl + 断言
02a-harness-guard.py     ← 从安全实践派生：路径白名单、命令白名单、代码扫描
02b-CLAUDE.md            ← 从 Sprint 范围派生：框架自动加载进提示词
03-skills.md             ← 从技术栈派生：Flask 语法、JWT 用法、数据库结构
04-memory.yaml           ← 状态分区配置
05-trigger.yaml          ← 触发规则配置

Grade 检查（12 个，全部机器可执行）：

01 ✅ 注册-正常           POST /api/user/register → 200
02 ✅ 注册-用户名已存在     重复 → 400
03 ✅ 注册-用户名过短       → 400
04 ✅ 注册-email非法        → 400
05 ✅ 注册-缺少必填字段      → 400
06 ✅ 登录-正常            → 200 + token
07 ✅ 登录-密码错误         → 401
08 ✅ 登录-用户不存在       → 401
09 ✅ 登录-账号锁定         5次错 → 第6次 423
10 ✅ Token-有效           → 200
11 ✅ Token-缺失           → 401
12 ✅ 安全-响应无密码       不含 password_hash

Harness（硬约束——Agent 绕不过）：

# 文件系统边界：每个 write_file 调用前检查
def guard_file_write(filepath):
    if 路径不在允许列表:
        return "Harness 拒绝"

# 命令白名单：每个 run_command 调用前检查
def guard_command(command):
    if command 包含 rm/sudo/git push:
        return "Harness 拒绝"

Step 6：Agent Loop 实际运行

第 1 次尝试:
  Agent 生成代码 → Grade 检查 → 0/12 通过
  反馈注入: "01-注册-正常 失败 status=404..."

第 2 次尝试:
  Agent 根据反馈修正 → 7/12 通过
  反馈注入: "06-登录-正常 失败 status=500..."

第 3 次尝试:
  Agent 继续修正 → 通过或进入退出流程

人做的事：定义 Landing Zone + 写约束文件。Agent 做的事：在约束下生成代码、自动验证、失败自动重试。代码是 Agent 在约束下生成的，不是人写的。

完整框架一览

┌─────────────────────────────────────────┐
│              Landing Zone               │
│   Spec + 安全实践 + 团队规范 + Sprint范围  │
├─────────────────────────────────────────┤
│        每个 Sprint 独立设计               │
│  ┌────────┬────────┬────────┬────────┐  │
│  │ Skills │Harness │ Grade  │  Loop  │  │
│  │ 知道什么 │不能做什么│ 怎么验证 │ 失败处理 │  │
│  └────────┴────────┴────────┴────────┘  │
├─────────────────────────────────────────┤
│          共享基础设施                     │
│  ┌──────────┬──────────┐                │
│  │ Trigger  │  Memory  │                │
│  │ 共享调度器 │ 各自分区  │                │
│  └──────────┴──────────┘                │
├─────────────────────────────────────────┤
│          多路径退出                       │
│  Tier 0: 重试 → Tier 1: TODO+分析        │
│  → Tier 2: 议会讨论 → ≥90%方案/升级       │
├─────────────────────────────────────────┤
│          跨 Sprint 资产沉淀               │
│  Grade/Harness/Loop Patterns             │
│  → 下个项目直接复用，从 2 个 Sprint 起步    │
└─────────────────────────────────────────┘

什么时候用 SLF

SLF 不是要替代基础 Loop Engineering。如果你的项目只有 1-3 个模块、几周就能完成，基础的 /goal命令完全够用。

适合 SLF 的项目：

• 项目周期超过 6 个月
• 模块数量超过 5 个
• 团队希望 Agent 逐步自治，而不是一步到位
• 需要跨版本管理 Agent 的交付质量

不需要 SLF 的场景：

• 单模块、短周期项目 → 基础 LE 足够
• Agent 只做辅助、人不依赖 Agent 的交付 → Grade 都不需要
• 一次性任务 → 直接 /goal跑完就好

写在最后

基础 Loop Engineering 解决了"让 AI Agent 自己跑起来"的问题。但它假设 Loop 是一次性设计、永远不变的。这在真实世界的复杂项目中不成立。

Sprint Loop Framework 把这个假设修正为：Loop 应该像代码一样，按 Sprint 迭代、跨项目复用、持续演进。

它不是替代 LangChain 或 Claude Code 的方案——它是跑在这些工具之上的一层。你仍然用 /goal和 /loop，但你不再一次性设计一个巨型 Loop，而是每个 Sprint 设计一个小而精准的 Loop，然后把它们串起来。

从 Landing Zone 出发，到每个 Sprint 的四要素，到多路径退出，到跨 Sprint 资产沉淀——SLF 提供了一条在复杂项目中让 AI Agent 持续交付的完整路径。

本文是 Sprint Loop Framework 系列的概述。完整的 Sprint 示例、代码文件和验证方案可在 GitHub查看。