无限循环
Agent 一直行动但不收敛。用最大轮数、超时和成本预算做硬边界。
Loop Engineering：设计与风险
设计 Loop 的重点不是“让 Agent 多跑几轮”，而是提前把一套持续运行的规则写清楚：要做什么、什么时候开始、在哪里做、能用什么、谁来验证、失败怎么办、什么时候停下来。
如果这些边界没有设计好，Loop 可能会一直跑、跑偏、跑贵，甚至把错误结果做成看起来很专业的产物。
设计 Loop 时，可以把它拆成 11 个问题。每个问题都要能落到配置、代码、规则或检查项里。
| 要素 | 设计问题 | 示例 |
|---|---|---|
| 目标（Objective） | Loop 最终要达成什么？ | 保持 CI 绿色、完成合同初审 |
| 触发（Trigger） | 什么时候启动？ | 定时扫描、CI 失败、工单创建 |
| 发现（Discover） | 从哪里找到待处理任务？ | CI 日志、GitHub Issues、待处理目录 |
| 工作空间（Workspace） | Agent 在哪里安全操作？ | Git worktree、文件系统沙盒、临时目录 |
| 上下文（Context） | Agent 需要哪些稳定知识？ | SKILL.md、AGENTS.md、项目规则、业务政策 |
| 委托（Delegation） | 谁执行，谁验证，谁调度？ | Maker、Checker、Orchestrator |
| 验证（Verification） | 怎么证明结果是对的？ | 测试通过、金额校验、规则匹配、只读复核 |
| 状态（State） | 哪些信息要跨轮保存？ | checkpointer、进度文件、看板、操作日志 |
| 预算（Budget） | 运行到什么程度必须停？ | 最大轮数、Token 上限、时间限制、成本上限 |
| 升级（Escalation） | 什么时候交给人处理？ | 三次失败、权限不足、高风险操作 |
| 退出（Exit） | 什么条件下算完成？ | 验证通过、状态写入、Checker 通过、日志闭环 |
不要一上来就写 Agent 代码。更稳的方式是先把 Loop 的边界画出来，再逐步补能力。
-
先定义目标和退出条件
目标必须可验证。不要写“提升代码质量”，而要写“指定测试全部通过、lint 无报错、Checker 复核通过”。
-
再定义触发和任务发现
明确 Loop 是定时启动、事件启动，还是围绕目标持续运行；同时说明它从哪里读取待处理任务。
-
划清工作空间和工具权限
给 Agent 分配沙盒、worktree 或临时目录。只读工具、写入工具、不可逆操作要分层。不可逆操作就是退款、删除数据、发布上线、合并代码这类影响较大、很难撤回的动作。
-
设计执行者和验证者
Maker 负责产出，Checker 负责独立复核，Orchestrator 负责调度、重试、升级和退出。
-
加上状态、预算和升级策略
保存进度和结果，限制最大轮数、时间和成本。超过阈值后停止自动重试，交给人处理。
怎么理解这些要素
Section titled “怎么理解这些要素”目标是终点，触发是开关。
目标要写成能验收的结果，比如“指定测试全部通过”，而不是“优化一下代码”。触发要根据任务节奏来选：紧急问题适合事件触发，周期任务适合定时触发，复杂修复适合目标驱动。
判断标准：Agent 启动前，系统应该已经知道“为什么开始”和“做到什么算结束”。
发现决定任务从哪里来，空间决定 Agent 能在哪里动手。
发现机制可以是扫描目录、读取工单、分析 CI 日志或监听 Webhook。工作空间要尽量隔离，比如用 Git worktree、临时目录或文件系统沙盒，让 Agent 的修改先发生在安全区域。
判断标准：Agent 找得到任务，也不会直接污染主项目。
上下文是做事依据，状态是接着做的依据。
上下文包括项目规则、业务政策、Skill、历史知识，解决“Agent 凭什么判断”的问题。状态包括当前进度、上一轮结果、失败次数、是否已升级，解决“下一轮从哪里继续”的问题。
判断标准：重启或换一轮执行后，Loop 仍然知道任务进度和关键约束。
委托解决谁来干，验证解决谁来判。
Maker 负责执行，Checker 负责独立复核，Orchestrator 负责调度、重试、升级和退出。验证条件要尽量客观，比如测试是否通过、金额是否合规、状态是否写入，而不是让 Agent 自己判断“差不多完成了”。
判断标准：干活的人和打分的人分开，验证依据能被复查。
预算防止无限消耗，退出防止无限循环。
预算要限制最大轮数、最长时间、Token 成本和工具调用次数。退出条件要由测试、状态、日志或独立 Checker 支撑；超过预算还没通过，就停止自动重试并升级给人。
判断标准：Loop 不会因为“还想再试试”而一直跑下去。
Loop 跑起来之后，风险不再只是“Agent 不干活”，而是“Agent 在错误方向上干了很多活”。自动化越强，越要把验证、权限和人工介入设计清楚。
| 风险 | 描述 | 防控措施 |
|---|---|---|
| 无限循环 | Agent 不断优化但永远无法完成 | 设置硬性 max_steps 上限 |
| 目标漂移 | 需求模糊，Agent 越做越偏 | 明确可验证的终止条件 |
| 上下文溢出 | 长会话导致早期目标和约束被稀释 | 定期压缩、使用摘要、持久化关键状态 |
| 静默失败 | 产出看起来不错，但实际没有进展 | 独立 Checker 重新读取原始材料并验证 |
| Token 成本爆炸 | 多 Agent 多轮调用导致成本飙升 | Token 预算、成本监控、分层使用模型 |
| 理解负债 | 工程师长期不读生成代码，不再理解系统变化 | 强制 Code Review 和变更摘要 |
| 认知投降 | 开发者停止形成独立判断，只相信 Agent 结论 | 定期人工抽查真实产出 |
静默失败
结果看起来专业，但没有真实进展。用独立 Checker、测试、日志和状态做客观验证。
权限失控
写入工具不能随便给所有 Agent。查询可以默认开放，退款、删除、发布、合并代码这类操作必须审核。
理解负债
自动化越高，人越容易不了解系统真实变化。Loop 可以提 PR，但合并前必须有人看懂。
设计风险控制时，可以抓住四条原则：
- 验证独立：干活的 Agent 不能给自己打分，Checker 要有独立上下文和只读权限。
- 权限最小化：默认只给只读工具，写入和不可逆操作必须单独授权。
- 状态可追踪：每轮关键决策、工具结果、失败原因、升级原因都要有记录。
- 成本有上限：轮数、时间、Token、调用次数都要有硬限制。
Loop Engineering 后面会沿着几个比较清晰的方向发展：
Maker-Checker 成为默认架构
不是所有场景都需要 Checker，但只要 Agent 的结果会被直接应用，比如代码合并、退款执行、合同审批，独立验证就不是额外成本，而是保险。
记忆系统决定 Agent 上限
模型能力会逐渐接近，但企业知识不会趋同。退款政策、合同模板、审批流程、历史处理经验，能否沉淀为 Skill 和记忆，决定 Loop 能处理多复杂的任务。
可观测性变成必须项
24 小时运行的 Loop 必须有运行日志、成本追踪、成功率监控和异常告警。没有可观测性，就很难算生产系统。
开发者的新角色
Section titled “开发者的新角色”Loop Engineering 不是替代 Prompt Engineering，而是把 Prompt 放进一个可运行的系统里。Prompt 仍然存在，只是更多由 Loop 根据任务、上下文和工具结果自动生成和调试。
工程师的重点也随之变化：不再只是“怎么问 AI 一个好问题”，而是“怎么设计一个系统，让系统持续问正确的问题、调用正确的工具，并验证真实结果”。
| 新角色 | 要做什么 | 关键能力 |
|---|---|---|
| 设计循环（Design the Loop） | 定义目标、触发、上下文、验证、预算、升级和退出 | 判断什么值得自动化，什么必须人工介入 |
| 训练系统（Train the System） | 把错误、漏判、人类经验沉淀到 Skill、规则和记忆中 | 将经验变成可执行检查清单 |
| 验证产出（Verify Output） | 定期审查真实结果，而不是只看 Agent 摘要 | 保留独立判断力 |