LoopX 长任务控制平面
让跨会话、跨 Agent 的长期任务保持可恢复、可审查和可交接。
最小权限有本地优先、默认关闭实验、只读检查、边界测试、受限工作流权限及不持久化检出凭据等支持，但安装命令采用远程脚本直接管道执行，且可选投影和运行时会接触外部系统，因此未给满分。用户确认处理充分：具体人工门、所有者复核、危险权限与发布留给人类，并明确禁止自动发布提升。数据流说明了 Agent、Capability、Provider、Kernel 的路径以及本地状态和外部投影关系，但所给材料没有覆盖每个适配器的字段级流向。敏感数据方面明确无遥测、反馈中不得含凭据或内部内容、公开投影会裁剪私有字段，工作流密钥也说明只读范围；不过缺少完整的加密、留存和删除策略。依赖安全较强：核心无运行时第三方依赖，构建依赖固定版本，测试依赖有范围，GitHub Actions 多数固定提交或明确版本，并启用依赖审查。外部效果受配额、门、声明和验证写回约束，但可选 Provider、调度器和投影的具体授权机制未在材料中完整展示。恢复性有可重启状态、保留既有状态、租约、历史和碰撞恢复说明，但没有通用事务回滚或撤销外部写入的证据。来源归属清楚地区分创建者案例、独立用户报告、公开贡献和演示，并标明报告性或不可复现边界，因此满分。
README、包元数据、安全政策和测试在本地优先、Python 版本、无核心依赖、人工复核和读写边界上高度一致；架构测试还强制核心层、扩展层和展示层的依赖方向，因此自洽性充分。核心依赖可用性较好且仅需 Python 标准库，但安装路径仍依赖 GitHub Pages、curl、tar、受支持主机以及可选生态，材料也未提供离线安装保证，所以扣分。失败信息有明确的结构化错误、非零退出、隐私路径抑制、证据不足状态和回归阻断测试，处理充分。
材料明确覆盖工程、研究、实验、运维、内容工作、单代理与对等代理团队，也为非工程操作员提供视图，受众与场景充分。能力边界明确区分运行时执行、Provider 观察、Capability 转换、Kernel 控制，并反复声明它不是生产自治控制器。触发精度有配额 should-run、scheduler_hint、声明、租约、具体人工门、安全回退和停止条件，且跳过、预检失败和预览不计费，证据充分。环境适配涵盖 Codex、Claude Code、Cursor、OpenCode、Pi、SSH、Shell 和自定义运行时；但快速安装仅明确支持 macOS/Linux 与 Python 3.11+，Windows及其他环境没有同等支持证据，因此扣分。
README 使用学习、安装、能力、架构、运行恢复和高级文档的分层导航，并指向完整索引，信息架构充分。安装说明包含需求、无克隆路径、连接、诊断、主机专用入口、贡献者安装及成功判据，处理彻底。命名稳定性由版本化 schema、协议名称、兼容门面许可清单及架构测试支持。示例和常见问题路径丰富，包括最小自定义运行时、可复现 KNN 演示、跨运行时演示和用户手册。已知限制被明确陈述，包括非生产自治控制器、可选功能默认关闭、人工最终权限、演示与用户报告的证据边界。MIT 许可证文件与包元数据一致，满分。版本号、发布徽章、安全支持策略和发布就绪文档提供了更新路径，但所给文件没有实际变更日志内容，因此版本与变更日志扣一分。维护责任有私密漏洞报告渠道、五个工作日确认目标和最新版本支持政策，但作者仅标为 LoopX contributors，发布者身份未验证且没有更具体的维护人员或治理结构，因此未给满分。
输出可用性强：状态、历史、审查包、结构化 JSON、具体下一步、所有者门和紧凑证据均面向操作与交接。边际价值有长时状态、配额、租约、证据与跨运行时交接机制以及可复现演示支持，但最强的现实成效部分仍包含创建者案例、脱敏案例和独立用户报告，缺少独立对照验证，因此为中等分。成本收益通过配额、槽位消费、安静跳过、令牌与用户注意力成本模型和基线比较结构得到处理，但没有提供可独立核验的总体节省数据，故未满分。
主张可追踪性充分：README 将主要案例连接到具体文档、公开贡献、仓库内命令和演示，并明确权威来源与证据层。跨来源佐证由 README、元数据、安全政策、工作流和测试共同支持架构及安全主张，但现实效果主要依赖仓库自述、创建者材料或用户报告，独立佐证有限。事实与推断分离处理彻底：明确区分经过验证的公开结果、用户报告、演示、脱敏图、墙钟时长与连续计算，并列出不得宣称的基准结论。
- 快速安装使用“curl | bash”；在采用前应固定并审阅安装脚本版本，尤其是在企业或高权限环境中。
- 外部 Provider、Lark 投影、调度器及主机桥接的完整权限、数据字段和撤销行为未包含在本次材料中，应分别审计后再启用。
- 不要把 200+ 小时案例或独立用户报告解释为连续无人值守计算、生产安全性或独立验证的效果提升。
- 项目只承诺维护最新发布版本；部署方需要明确升级和回退策略。
- 发布者身份未知；这不是风险证据，但组织采用时应单独确认维护联系人、签名发布和供应链来源。
这个 Agent 能做什么，适合哪些场景？
LoopX 是面向长期 AI Agent 工作流的轻量状态内核与本地优先控制平面，并不替代实际执行任务的 Agent 运行时。它把目标、决策门、待办、作用域、证据、配额、认领与租约保存在持久状态中，使工作能够跨轮次恢复和交接。Codex、Claude Code、Cursor、Shell Agent 或自定义运行器负责执行有界任务片段，LoopX 则决定是否应继续、等待用户判断或停止调度。项目主要通过 `loopx` CLI 操作，并提供 Codex、Claude Code、通用 worker、自定义运行器、状态面板和 Lark 看板投影等接入路径。运行结果包括更新后的目标状态、待办、证据、运行历史、交接信息和下一次调度提示；本地状态仍是事实来源。它适合需要长期可追踪执行的工程、研究和运维流程，但不负责生产审批、危险权限授予或未经授权的发布。
LoopX 从项目中的持久状态读取当前目标、作用域、用户决策门、Agent 待办、认领、租约、证据和配额。运行器先调用 loopx quota should-run 判断已注册 Agent 是否应执行，再用 loopx todo claim 认领一个工作片段；Codex、Claude Code、Cursor、Shell Agent 或自定义运行器随后完成实际分析和工具调用。验证完成后，运行器通过 loopx todo update 写入变化与证据，执行 loopx refresh-state 生成下一轮所需状态，并用 loopx quota spend-slot 记录一个已验证片段的消耗。loopx status、loopx history、loopx diagnose 和 loopx review-packet 分别提供当前状态、历史、诊断及面向所有者的审查材料。调度器依据 quota should-run.scheduler_hint 安排后续唤醒；若某条工作线受用户决策门阻塞，只有经过审计的独立安全后备任务可以继续。可选能力还包括 loopx issue-fix、loopx content-ops、loopx value-connectors、loopx ml-experiment、loopx benchmark、Explore、Auto Research、只读面板以及 Lark 投影。
- 维护者处理持续数天的 Issue 或 PR 时，用 LoopX 保存范围、审查状态、修复证据和下一步待办，避免跨会话丢失上下文。
- 研究或机器学习团队运行多轮实验时，用目标、配额、证据门和停止条件管理假设、重复实验及晋级决策。
- 同时使用 Codex 与 Claude Code 的团队需要明确实现、复核和交接责任时，用同一份状态记录认领、租约和验证结果。
- 运维人员执行周期性监控或心跳任务时，用
quota should-run和调度提示避免在没有有效状态变化时继续消耗。 - 自定义 Agent 运行器的开发者需要加入持久目标和可验证写回时，可从最小 CLI turn 示例及 worker bridge 合约开始集成。
- 需要让非工程管理者查看长期任务进展的团队，可使用只读状态面板或 Lark 看板投影，同时保持 LoopX 本地状态为事实来源。
这个 Agent 有哪些优点和局限？
- 核心状态与执行运行时分离，可由 Codex、Claude Code、Cursor、Shell Agent或自定义运行器共同使用，降低单一模型提供商锁定。
- 目标、具体用户决策门、待办认领、租约、证据、配额和交接集中在同一持久控制层，适合跨多轮和多 Agent 的工作。
- 配额检查、验证后计费、停止条件和调度提示为周期性自动执行提供明确约束。
- 本地状态是事实来源；面板和 Lark 等外部视图仅作为投影，不会取代控制状态。
- 提供可复制的安装命令、CLI 流程、最小自定义运行器示例以及面向 Codex 和 Claude Code 的接入路径。
- 目前要求 Python 3.11+、
curl、tar和 macOS 或 Linux Shell，未提供 Windows 原生安装路径。 - 它不是 Agent 运行时或完整 Agent 平台；用户仍需配置 Codex、Claude Code、Cursor、Shell Agent 或自己的执行器。
- Claude Code 需要安装可选适配器，部分主机集成和高级路径仍为可选、默认关闭或实验性功能。
- 它不会授予凭据、批准危险或生产操作，也不会替用户完成最终发布和所有权决策，因此仍需人工治理。
- 公开案例包含用户报告、脱敏展示和演示结果；部分长期运行证据不能独立复现实验，也不代表持续计算或生产自治。
如何安装或部署这个 Agent？
要求 Python 3.11+、curl、tar，以及 macOS 或 Linux Shell。通过网络安装：
curl -fsSL https://huangruiteng.github.io/loopx/install.sh | bash
export PATH="$HOME/.local/bin:$PATH"
loopx doctorPython 包除标准库外没有运行时依赖。文档没有要求 API 密钥或云端凭据。Git 仅用于贡献者的克隆与 canary 工作流；贡献者可运行：
git clone https://github.com/huangruiteng/loopx ~/loopx
~/loopx/scripts/install-local.sh
loopx doctor如何使用这个 Agent？
进入现有项目并连接：
cd /path/to/your-project
loopx connect
loopx status如果项目尚无状态且 connect 报告缺失，可执行：
loopx start-goal --guided --project . --goal-text "Your long-running objective"成功连接后，loopx doctor 应通过，项目应出现 .loopx/registry.json 和投影后的活动目标状态，loopx status 应显示目标、当前用户决策门与下一项 Agent 待办。将 .loopx/、.codex/goals/ 和 .local/ 加入忽略列表，不要提交活动状态。每个受治理的执行片段采用以下顺序：
loopx quota should-run
loopx todo claim
loopx todo update
loopx refresh-state
loopx quota spend-slot自动轮次必须先检查配额，并且只能在验证写回完成后计入消耗。Codex App 或 Codex CLI 可使用 $loopx <complex task>；Claude Code 需要先安装可选适配器，再运行 /loopx <task> 和 /loop。自定义运行器可从 python3 examples/custom-runtime-minimal-cli-turn-smoke.py 开始。
常见问题
LoopX 会直接执行编码、研究或外部系统操作吗？
是否需要云端账户、API 密钥或付费服务？
当任务需要人工判断时会怎样？
自动调度如何避免无效消耗？
loopx quota should-run，调度器遵循返回的 scheduler_hint。静默跳过、预检失败和 dry-run 不计入消耗，只有完成验证写回后才执行 loopx quota spend-slot。