LoopX：长运行 Agent 的状态内核与本地控制面
LoopX：长运行 Agent 的状态内核与本地控制面
一句话结论
LoopX 把长运行 agent 工作中最容易丢失的目标、门禁、todo、证据、quota、handoff 和调度提示放进一个本地、可审查的状态层。它不替代 Codex、Claude Code、Cursor 等执行器，而是让这些执行器每次只跑一个 bounded turn，同时由外层状态内核维护“下一步该谁做、做到什么证据才算完成、何时需要人类判断”。
为什么对用户重要
用户的 Hermes / llm-wiki 已经不是一次性问答系统，而是由 cron、skill、wiki、raw archive、vector index、Feishu/消息通道和人工审阅构成的持续工作系统。随着雷达、摄入、lint、优化文章等 loop 增多，真正瓶颈会从“模型会不会写内容”转向“跨天状态是否可恢复、失败是否可复盘、quota 是否可控、是否有明确 human gate”。LoopX 的价值在于把这些隐性运行约束产品化为 agent-agnostic control plane。
机制 / 一阶原理
LoopX 的机制可以抽象成：
- 状态外置：objective、gates、todos、scope、evidence、quota、history 不留在一次对话上下文里，而是成为可读写、可审查的持久对象。
- bounded execution：Codex / Claude Code / Cursor / shell agent 只负责执行下一片工作；外层 loop 判断是否继续、暂停、交给人类或切换 agent。
- peer-agent scheduling：注册 agent 是同级 worker，靠 claim、lease、capability、typed continuation 决定谁继续，而不是依赖一个永远在线的 leader identity。
- 证据驱动交接：每轮输出不只是自然语言总结，还要留下 evidence、gate 状态和下一步 continuation，让下一轮能从事实状态恢复。
一阶原理是：长任务失败多半不是单轮推理失败，而是状态、边界和评估断裂。把“记忆”和“控制”从模型上下文中抽出，可以降低 /clear、会话中断、工具切换和多 agent 并发带来的状态损失。
和现有 wiki 的关系
- 对 Loop-Engineering：补充“state kernel / local control plane”这一工程形态，把 loop 从抽象五动作推进到可运行的状态对象。
- 对 Harness-Engineering：LoopX 坐在 harness 之上，维护目标、门禁、quota 和 handoff；harness 负责一次运行的工具与边界，loop 负责跨轮连续性。
- 对 Context-Engineering：外置状态减少了把全部历史塞进上下文的冲动；每轮只需要注入当前 continuation、gate 和必要证据。
- 对 Agentic-Coding：长任务不应靠“一个巨大 prompt + 期望 agent 一次做完”，而应拆成可验证、可暂停、可恢复的 loop slices。
对 Hermes / llm-wiki 的可执行启发
- 每个 cron 类任务应有轻量 loop state：目标、输入源、上次成功证据、未完成项、失败原因、下一次策略，而不是只靠
log.md的 append-only 记录。 - 每日 AI radar 可把候选发现、打分、入库决策、未入库原因写成结构化 evidence，方便第二天避免重复搜索和重复判断。
- 对未来“自动修复 wiki 链接 / 自动合并重复页”这类任务，应采用 bounded slices + human gate：低风险修正自动做，高风险结构变更输出为待审建议。
- 可以把 ConversationSpec 与 llm-wiki 的关系重新界定：ConversationSpec 管本会话/任务状态，wiki 管沉淀知识，LoopX 式 state 管长期自动化运行状态。
失败模式 / 边界
- 状态内核如果没有简洁 schema，会变成另一个需要维护的复杂系统，甚至比原任务更难理解。
- 外置状态不能替代真实验证；gate 必须绑定测试、文件存在性、hash、链接检查或人工批准等证据。
- 多 agent peer scheduling 容易引入并发冲突；需要 worktree、lease 超时、scope 锁和冲突恢复策略。
- 对短任务或低频任务，LoopX 式控制面可能过度工程化；应优先用于跨天、可重复、可验证、可复盘的 loop。
深度判断
晋升为正式 source 页的原因：LoopX 不是普通 coding CLI，而是把用户当前最需要的“持续 agent 工作如何可管理、可复盘、可恢复”做成状态内核模式。它能直接指导 Hermes cron、llm-wiki radar、自动 ingest 和未来多 agent 工作流的控制层设计。
写入记录
- 2026-07-20 09:00 CST：新增 LoopX source 页，提炼 state kernel、bounded turn、peer scheduling、证据驱动交接及其对 Hermes/llm-wiki loop state 的启发。