智能体循环工程

智能体循环工程关注的不是单次回答，而是智能体如何持续工作：什么时候启动、怎样推进、何时停止、如何验证、失败后如何恢复，以及资源预算如何被约束。

四种循环形态

常见循环可以分成四类，区别不在于“自主程度”本身，而在于谁负责触发下一轮、谁负责判断该停下：

形态	触发方式	停止条件	适合场景
回合循环	用户提示	智能体判断完成，或需要补充上下文	短任务、探索性任务、非固定流程
目标循环	用户启动明确目标	可验证条件达成，或达到轮次上限	结果必须收敛到可测量状态的任务
时间循环	本地间隔或云端计划任务	用户取消，或被观察的工作完成	轮询、周期输入、外部系统检查
主动循环	事件或云端排程	单个任务达成目标；例程持续运行直到关闭	定义清晰、可无人值守的重复工作流

这些形态不是可以互换的命令。选择时先问两个问题：什么会启动下一轮？什么能证明这一轮应该结束？

两层运行时循环

pigo 将运行时拆成两个层次：

• 单轮循环：向模型发起流式请求，累积内容块，执行工具，再把工具结果送回模型，直到该轮不再产生工具调用。
• 多轮循环：在单轮结束后处理 steering、follow-up、停止条件和上下文压缩，判断是否启动下一轮。

这种分层让工具协议与任务级控制分开：单轮循环保证每个工具调用都有匹配结果，多轮循环负责目标、预算、用户干预和终止决策。智能体运行时契约则为两层提供统一事件和停止原因。

Claude Code 的循环原语

Claude Code 把循环拆成几种可组合的原语：

• 普通回合把检查责任交回给用户。
• goal 命令把停止条件交给验证器，适合“达到某个分数”“通过某些测试”这类可外部检查的目标。
• loop 命令把下一次触发交给本地时间间隔，适合周期检查和轮询。
• schedule 命令把时间循环搬到云端，适合离开本地会话后继续运行的例程。
• 主动式工作流可以把计划任务、目标、动态工作流、自动模式和复审智能体组合起来，处理持续到来的 bug、issue、迁移或依赖升级。

从回合循环走向计划任务和主动循环后，智能体就不再只是对话工具，而是进入自动化系统的范畴。

关键工程约束

一个循环需要明确几件事：

• 触发条件：由用户、时间、事件、CI、Webhook 还是调度器启动。
• 停止条件：完成、预算耗尽、验证失败、重复失败、需要人工确认。
• 验证机制：测试、lint、schema、链接检查、部署状态、业务指标。
• 执行环境：本地会话、无头进程、CI、云函数或服务器任务。
• 资源预算：时间、token、模型档位、API 额度、并发限制。

缺少这些约束时，循环很容易变成不可审计、不可停止、不可复现的自动化脚本。

成本和质量边界

循环越长，越需要把质量和成本写进系统，而不是靠最后一句提示补救：

• 先用回合循环验证任务形状，再升级为持续循环。
• 用技能、脚本和端到端检查让智能体能自我验证。
• 确定性步骤优先交给脚本，减少重复推理消耗。
• 让轮询频率匹配外部状态变化频率。
• 大规模派生多个智能体前，先在小范围估算 token 和失败模式。
• 用用量报告、目标轮次和工作流级 token 拆分定位预算消耗。

当某次循环产物不达标时，最好不要只修当前结果，而是把失败转成技能、测试、Hook、仓库规则或评审流程，让后续循环自动受益。

与其他页面的关系

智能体无头执行解决循环离开人工会话后的运行问题；智能体反馈循环解决执行后的验证问题；智能体成本控制解决持续运行的费用边界；智能体 Harness 工程把这些约束装进可维护的运行时。