Orbit 循环驱动

要解决什么问题

长时间自治的 Agent 循环很容易在「看起来还在跑」和「其实已经卡住」之间失真：重复语义等价的工具调用、上下文窗口被大段输出撑爆、state.env 与 progress.md 不一致，却仍在没有外部证据时声明 DONE。Orbit 面向的是 nexus-autoloop 这一类有界循环：把用户目标、PDM 叶子项或 sprint 固化为可衡量的循环合同，生成可运行的脚本集，并在运行期用证据审计状态、分类故障、从漂移中恢复。

技能如何工作

Orbit 按工作流阶段推进，而不是泛泛给建议：

• INTAKE / CONTRACT：将请求分为 GENERATE、AUDIT、RECOVER、PROACTIVE_AUDIT；为每个循环编写 3～6 条可验证 AC，定义页脚语义（如 READY / CONTINUE / DONE）和可恢复状态设计。
• 生成与审计：generate 产出运行器与支持脚本；audit 解析 goal.md、progress.md、state.env、runner.log，用故障分类法评估收敛性、振荡与去重窗口（DEDUP_WINDOW）。
• 弹性与终止：重试、超时、断路器作为单一弹性单元；外部运行器强制执行迭代上限、超时或预算，不依赖 Agent 自评结束；工具输出 >1KB 时走内存指针模式，避免上下文膨胀。
• 生态对接：可与 Nexus apex（Phase 6，Codex CLI）、summit（Phase 5，三引擎 PDCA）、enact（Charter §10 DoD 作 DONE 门控）等委托模式衔接；完成侧向 Builder、Guardian、Radar、Beacon、Triage 等做最小交接。

方案上，plan 只产出 LOOP_PLAN.md（文档优先）；generate 从目标或已批准计划生成脚本；recover 针对 STATE_DRIFT、VERIFY_GAP 等做检查点重放式恢复。

适用边界与注意点

• Orbit 不直接改业务代码，实现类工作应交给 Builder 等角色；多 Agent 链编排归 Nexus，无循环的任务分解归 Sherpa。
• 没有工件证据不得声明 DONE；验证通过 alone 不够，需结合占位符检测或独立评判模型等门控。
• 未经明确批准不得禁用断路器；未设 Token/USD 预算上限时不应跑无人监视循环。
• 循环开始时 goal.md、AC 文件等若已 sha256 固定，运行中变异应视为 ABORT 条件，而非静默忽略。