企业官网建设流程全解析

LoopX无进展自修复机制：Agent卡住时控制平面如何自救

【免费下载链接】loopxLong-horizon agent control plane for durable, governed work across Codex, Claude Code, and other harnesses.项目地址: https://gitcode.com/GitHub_Trending/lo/loopx

LoopX 是一个面向长时程任务的 AI Agent 控制平面，它统一管理跨 Codex、Claude Code 等执行框架的持续工作。当 Agent 在任务中"无进展"、反复空转或卡住时，LoopX 的自修复（Self-Repair）机制会自动诊断根因、重规划路线，并把事故沉淀为永久修复——本文带你快速看懂这套"控制平面自救"体系。

为什么需要无进展自修复

长时程 Agent 任务最大的风险不是失败，而是假装在工作的停滞：任务状态看似健康，实际连续多个心跳都没有产出可验证的进展。传统做法是等用户发现异常再人工介入，而 LoopX 把这件事做成了机器可判定的契约：

• 停滞阈值：同一个 Todo 连续 2 次心跳无实质性进展（AUTONOMOUS_REPLAN_STALL_THRESHOLD = 2），控制平面即标记为停滞，见 autonomous_replan_obligation.py
• 进展指纹：每次"进展"会被提炼成类型化指纹（typed progress fingerprint），重复提交相同指纹不会被视为新进展，typed_progress_repeat直接触发重规划义务
• 拒绝文字游戏：维护性写回（改状态、刷日志）不能关闭重规划义务，只有"类型化语义增量"才算真正的新方向

这意味着 Agent 想靠"换个说法汇报进展"来糊弄系统是不可行的。

七步自修复循环：从异常到永久修复

自修复的完整流程定义在 skills/loopx-self-repair/SKILL.md 中，共 7 步：

1. 暂停交付选择—— 先别继续烧配额干活，停下来说清楚"为什么之前的工作是有效的"
2. 构建证据包—— 用loopx diagnose、quota should-run、history等结构化命令收集事实
3. 分类故障—— 对照已知模式表，匹配症状到已知模式
4. 定位责任层—— 分清是 Agent 行为错误、状态投影 Bug、活跃状态缺失，还是文档流程问题
5. 在最低持久层修复—— 一次性错误就修正状态；投影误导 Agent 就修 CLI 投影并加 smoke 测试
6. 验证后恢复—— 跑一个"本可以提前抓到问题"的最小检查再放行
7. 写回教训—— 把修复经验写回活跃状态、文档或技能文件，让同类故障下次可见

这套流程的核心思想是：把一次意外的 Agent 行为变成持久修复，而不是道歉或一次性解释。

证据优先：最小证据包

自修复有一条铁律：不要靠猜解决矛盾的数据。如果recommended_action、写入边界、Todo 列表和交互契约彼此矛盾，优先当作投影 Bug 处理。标准的最小证据包模板如下（来自技能参考文档）：

goal_id: / observed_surprise: / quota_state: / interaction_contract: agent_todo_open_count: / recommended_action: / responsible_layer: / repair:

保持证据包紧凑且"公共安全"——只存摘要，原始日志和私有轨迹留在本地忽略路径中。

模式库：200+ 条实战教训沉淀

真正让 LoopX 自修复"越修越强"的，是这张持续生长的诊断表：repair-patterns.md。每条记录包含模式名、症状、应读的证据、可能根因、持久修复五列，例如：

• tiny_turn_under_delivery：心跳很多但每次只做一小步，Agent 在规避错误而非交付批量成果
• monitor_replan_noop_loop：监控目标实质性等价，维护性写回不断成功但没有新假设、新探针
• stale_recommended_action：推荐动作没有从最新状态重新生成

每解决一个真实事故，就补一行。规则简单粗暴：如果现有模式匹配不上症状，修完后必须新增一个。

重规划写回：vision replan 契约

当自修复发现"LoopX 自己没注意到缺失的结果或验收条件"时，会写回一个有界契约goal_vision_replan_contract_v0，包含三个关键字段：

• vision_summary：修正后的路线或验收目标
• acceptance_summary：机器可见的必须成立的条件
• replan_trigger_summary：当前前沿为什么不够

然后通过loopx refresh-state --vision-replan-trigger ...写回状态。若判断现有愿景仍然正确，则用--vision-unchanged-reason关闭检查点，而不是编造一个假补丁。这个契约是人类/Agent 洞察通往配额可见重规划状态的桥梁——洞察停留在聊天里不算数，必须落成机器可读的状态。

回归契约：自修复本身也要被测试

自修复机制不会"自我豁免"。仓库中专门的回归入口 regression/no-progress-self-repair-contract.py 会调用 examples/autonomous-replan-obligation-smoke.py，验证"无进展 → 停滞检测 → 重规划义务 → 类型化语义写回"整条链路。更完整的长任务可靠性设计思路可参考 long-running-agent-reliability-diagnostics-governed-delivery-v0.zh-CN.md。

总结

LoopX 的无进展自修复机制可以概括为三句话：

1. 停滞是机器可判定的——进展指纹 + 停滞阈值，Agent 糊弄不了
2. 修复必须持久化——七步循环把事故变成模式库里的永久条目
3. 洞察必须落状态——vision replan 契约确保每条纠正都进入下一轮配额决策

对普通用户而言，你只需要知道：当 Agent 卡住时，控制平面会先停下、收集证据、定位责任层、修好再放行——而不是默默空转，直到你发现配额已经烧光了。

【免费下载链接】loopxLong-horizon agent control plane for durable, governed work across Codex, Claude Code, and other harnesses.项目地址: https://gitcode.com/GitHub_Trending/lo/loopx