长程智能体控制面loopx-project/loopx

LoopX

面向长程 Agent 的开放、有状态、Provider-neutral 控制面。

在 Codex、Claude Code、Cursor 等 agent harness 之上，持久保存目标、gate、todo、证据、quota 与交接状态。LoopX 负责跨轮次的状态与执行边界，harness 负责有界执行。

License Release Discord TypeScript core Python Local first Loop Agents

产品首页 · 博客 · 文档 · 开发者手册 · 试用 LoopX · 查看真实 Loop · 理解工作原理 · English

LoopX 是开放且 Provider-neutral 的轻量 state kernel，也是 local-first
的 Loop Engineering 控制面。它运行在不同 agent harness 之上，而不是替代
它们：LoopX 提供长程状态、语义决策、治理、恢复与人机协同，让跨轮次、
跨工具、跨 agent 的工作可审阅、可恢复、可接力。

让 Loop 持续向前，让关键判断留在人手里。

学习 LoopX

- 开发者手册 - 从控制面基础到项目接入和开发者贡献的双语学习路径。简体中文 · English
- 快速开始 - 安装、连接项目并运行第一个受治理的 Loop。指南
- 文档站 - 完整参考与运维文档。LoopX Docs

认识个人 Agent 工作区

把长程目标收进同一个 local-first 工作区。Goal、待关注事项、对话、任务、
文件、定时计划与恢复状态跨天数、跨重启、跨 harness 保持持久。重新打开项目时，
可以检查上一轮的状态与证据，再继续下一项允许执行的工作。

LoopX 1.0 将这些长程控制状态汇入 Personal Workspace。你可以在一个页面中：

- 看清哪些事项正在等你、执行中、观察中、已安排或已停止；
- 配置 Goal 的 Capability，区分机器默认值与 Goal 覆盖，预览变更后再应用；
- 从关联的飞书会话进行实时 steering、消息排队或异步收件，不丢失 Goal/Agent/Session 路由；
- 查看交付文件、周期报告与关联证据；
- 在 Codex、Claude Code、direct-model 等已注册 Agent 会话之间延续工作，
不丢失 Goal 状态与证据；
- 通过 typed preview、显式确认与 receipt 审阅受保护变更；浏览器只负责投影，
LoopX state 始终是权威事实源。

loopx dashboard

loopx dashboard 是受支持的浏览器 / PWA 启动方式。也可从
1.0 Release 下载桌面预览版，
复用同一组 loopback 服务与 Goal 状态。Apple Silicon macOS 支持签名 App 更新，
将桌面壳与内置运行时配套升级，并提供修复与恢复入口；需要 Python 3.11+，
App 为 ad-hoc 签名，尚未 notarize。Windows 预览版目前手动更新，需单独安装 CLI。
桌面安装、更新与源码开发指南。

在源码 checkout 中运行 python -m demo.workspace serve，可探索社区活动、家庭能源比较
和社区网站发布三个复杂项目；每个项目有四个工作角色、18 项任务、两项决策与两项观察。
上图来自这份可复现工作区。场景与回放说明。

观看 32 秒完整演示
· 阅读工作区指南
· 开始五分钟体验

为什么需要 LoopX

一个 agent 可以在单次会话里完成任务。长程工作更难：目标会变化，用户决策会出现，
证据会过期，平级 agent 会交接，scheduler 也可能在已经没有有效状态迁移时继续消耗。
聊天记忆和定时器不足以治理这些问题。

LoopX 把长期控制状态留在同一层紧凑状态里：

目标 / issue / project
│
▼
LoopX state：objective + gate + todo + scope + evidence + quota
│
├─ 需要人类判断？ ── 是 ─▶ 提出具体问题并等待
│
├─ 有安全侧路？ ─────────▶ 执行一个有界 agent slice
│
▼
Codex / Claude Code / Cursor / shell agent 执行一轮
│
▼
写回证据 + handoff + next todo ─▶ quota 决定下一次 tick

Agent runtime 负责执行，LoopX 负责治理跨运行延续的控制状态，让工程、
研究、discovery 和运营 Loop 能持续推进。它不是又一个 agent framework，也不是
绑定某一 Provider 的编排 runtime。

LoopX control-plane board

一个形象化理解是：LoopX 是
面向长程 Agent 的可执行看板。
卡片带有稳定身份、权限、证据和 continuation；移动卡片要经过 claim、gate、
monitor、validate、writeback 等 typed operator。看板是 projection，LoopX state
才是事实源。

注册 agent 彼此平级。todo claim、lease、任务边界、能力门和 typed continuation
共同决定下一步谁执行，不需要一个长期拥有全局权限的 leader agent。

LoopX 适合：

- 多天或多周的工程、研究、benchmark、实验目标；
- 需要跨轮保留 scope、证据和 review 状态的 issue / PR Loop；
- recurring heartbeat 或 monitor-style agent 工作；
- 带 owner、安全、发布或私有数据 gate 的项目；
- 需要 ownership、lease 和 handoff 的平级 agent team；
- 需要把进展、阻塞和反馈入口清晰呈现给非技术用户的创作、研究或运营工作。

LoopX 不是生产自动化控制器。危险权限、生产写入、公开发布和最终 ownership
仍由人类负责。

证据

OpenViking 的公开贡献序列与脱敏的 owner-run Auto ML showcase 各自跨越
200+ 小时自然时长，保留多轮 Todo、决策和证据更新。这里衡量的是项目经过的
wall-clock 时间，不是连续模型执行时长或无人值守的生产自治。点击原图查看
公开安全的任务图、证据分支和跨轮决策；各案例分别说明来源与可复现边界。

开源 Issue Fix

超过 200 小时的公开贡献轨迹：Focused PR 交付与可复用修复知识互相反哺。

LoopX 的创建者以
OpenViking contributor
身份把这条路径用于持续的 issue-to-PR 修复。图中公开贡献序列从首个 PR 创建到
最后一次所示 review 或 update，跨越 200+ 小时。
Issue-Fix 能力说明把 rolling
repository context、带 revision 的修复知识和 reviewer-facing preference
分开管理；所链接 PR 与当前 checkout 的源码、测试始终具有最高权威。

Auto ML Experiment

经过脱敏的 owner-run showcase：超过 200 小时的实验轨迹把假设、matched
evidence、无效谱系、运行中复现和 promote / stop gate 留在同一张图中。*

这张 public-safe graph 保留了该 200+ 小时自然时间窗口中的决策谱系。它是
owner-run showcase，不代表连续算力执行、独立复现、生产结果，也不代表公司或
雇主背书；脱敏后的图片本身不足以让第三方独立复现实验。

Auto Research

可复现的公开 KNN demo：Proposer、executor、evaluator/promoter 并行迭代，
todo、quota、证据与 targeted wake 同屏可见。

这张截图来自 LoopX 内置的 exact-KNN demo。公开 task、可编辑与受保护文件、
deterministic CPU evaluator、dev / held-out 命令均在仓库内。可按
showcase walkthrough
或 demo 命令路径复现工作流；它是 demo
结果，不是生产研究结论。

真实项目中的使用

- 外部独立用户 · >13h C++ 精度修复。 用户报告多阶段任务持续对齐目标，
触发 public research 后采用公开代码记忆工具，
最终精度明显提升。查看证据边界。
- 外部独立用户 · 4d 无人干预运行。 用户报告 Agent 连续四天无需人工
干预，持续处理有价值的工作，并提供周期报告入口。
查看脱敏案例。
- 外部独立用户 · 7 个合并 PR。 一次归因于 LoopX 的 Engine 重构可由
公开 Issue和七个合并 PR 检查；
LoopX 归因与用户报告的 10 亿+ token 规模仍按用户自述标记。
检查完整案例。

这里长期只维护当前最强的三个案例，不复制全量清单。完整的 contributor case、
creator dogfooding、reproducible demo 和证据强度标签见
Showcase 全量目录。

探索性 Benchmark 研究

- SWE-Marathon：
在相同的 15 个任务上对照 5 种执行模式，比较自验证行为、得分与成本。
更多自验证并未稳定转化为更高得分。
- LHTB × LoopX：
在 46 个长程终端任务上对比 5 种执行机制，研究持久状态、Todo、replan
与 fresh executor session。
- DeepSWE 行为分析：
通过精选案例观察领域提示、需求保留与验证选择之间的关系，提出有待复验的机制假设。

SWE-Marathon 与 LHTB 每个任务、每种模式仅保留一条有效轨迹；DeepSWE 包含精选案例与
事后分析。目前三者均不足以证明普遍的性能提升。

更多可检查入口：

- 产品首页：查看产品叙事、快速开始和长程证据；
- Showcase 全量目录和
中英双语托管索引；
- 跨 runtime 实现审阅演示；
- 公开用户手册。

试用 LoopX

要求：Python 3.11+ 与 Node.js 22.18.0+，推荐使用 Node.js 24 LTS。使用 console
scripts 已加入 PATH 的 Python 环境；macOS 和 Linux 使用 POSIX shell，原生
Windows 使用 PowerShell 7。Node.js 运行 LoopX 自动启动、空闲退出的 TypeScript
Effect core，无需手工维护 daemon。Git 仅用于源码贡献与 clone/canary 工作流。

无需 clone，直接从 PyPI 安装：

python3 -m pip install --upgrade loopx
loopx workflow-skills --install
loopx doctor

已有安装可使用 loopx update plan 与 loopx update apply；LoopX 会保留检测到
的 pip、pipx 或 archive owner，不会在升级时暗中切换安装渠道。

原生 Windows PowerShell 7 可直接使用同一 PyPI release，不需要 POSIX 兼容层：

py -3.11 -m pip install --upgrade loopx
loopx workflow-skills --install
loopx doctor

首次安装后重启 Agent host，使其重新加载 workflow skills。pipx、host command
surfaces、原生 Windows checkout 安装、升级、回滚、卸载与 archive fallback 见
Installing LoopX。

然后在项目根目录连接：

cd /path/to/your-project
loopx connect
loopx status

如果项目尚未初始化，且 connect 明确提示缺少状态，可以走 guided path：

loopx start-goal --guided --project . --goal-text "你的长程目标"

已有 LoopX state 应复用，不要覆盖。确保 .loopx/、.codex/goals/、.local/
不会被提交。

从你已经在用的 Agent 启动

| Host | 推荐入口 | Loop driver |
| --- | --- | --- |
| Codex App | 让 agent 在当前项目里连接 LoopX、运行 loopx doctor、保留已有状态，并汇报当前 gate 和下一条 todo；然后用 $loopx  或 /skills 里的 loopx。 | Codex App heartbeat；cadence 跟随 quota should-run.scheduler_hint |
| Codex App over SSH | loopx agent-onboard --agent-type codex-app-ssh --project . | 返回的可见 /goal  |
| Codex CLI | 在项目里启动 codex，让它连接并诊断 LoopX，然后用 $loopx  或 /skills。 | 可见 /goal ；默认不走隐藏 headless 执行 |
| Claude Code | 安装 opt-in adapter，然后运行 /loopx ，再运行 /loop。 | 由 LoopX gate 的原生 Claude Code /loop |
| KunlunCode | 运行 loopx-kunluncode connect --project . --goal-id  --agent-id ，添加一条有边界的 todo，再运行 loopx-kunluncode run --project .。 | 经 app-server 驱动原生 Goal Pro；只有 strict verification 通过后，LoopX 才写回完成与 quota |
| OpenCode | 安装静态 command facade；recurring goal 显式 opt in --with-goal-bridge。 | OpenCode command facade 与显式 goal bridge |
| Pi | 用 loopx slash-commands --install --surface pi 安装 opt-in goal extension，然后在受信任的 Pi 会话里用 /loopx 。 | 由 LoopX quota gate 的可见 Pi goal extension（loopx_goal_activate + agent_settled 续跑） |
| ZCode | 用 loopx slash-commands --install --surface zcode 安装 skill facade，然后在项目里的 ZCode 会话中调用 $loopx skill（或 /loopx ）。 | ZCode 会话自身的 turn loop；每次续跑都从 quota should-run 进入 |
| Antigravity CLI（agy） | 用 loopx slash-commands --install --surface agy 安装 skill facade，然后在项目里的 agy 会话中调用 loopx skill（或 /loopx ）。 | 会话原生 /goal 循环（审计至 ）加 schedule 自唤醒，随会话存活；facade 指示每次 turn/唤醒都先过 quota should-run——advisory 节流，非宿主强制 gate |
| Kiro CLI | 用 loopx slash-commands --install --surface kiro-cli 安装 skill facade，然后在项目里的 kiro-cli 会话中执行 /loopx 。 | 会话原生 /goal --max   Done when:  循环，验收条件写入目标语句本身（宿主由该语句推导验收标准），由宿主自己的迭代预算兜底（默认 5），并通过内置 goal 完成契约收口；facade 指示每次 turn 与迭代都先过 quota should-run——advisory 节流，非宿主强制 gate |
| DeepSeek Harness（dsh） | 安装 DSH 原生 Plugin，在技能选择器中点 loopx，然后直接描述任务；dsh goal-mode adapter 继续支持 headless turn。 | 原生同会话续跑与 GoalBar，或 headless dsh 工作段；两条路径都遵守 LoopX authority |
| Cursor、shell、自有 runner | 使用同一 installer 和 loopx doctor，再手动连接或由 runner 调用。 | 你的 shell、scheduler 或 runner |

可直接粘贴的完整 setup message、host-specific 路由和故障恢复见
Getting Started。Host 集成还可以查看
Codex App host command registry、
Codex CLI packaged install和
Claude Code adapter、
KunlunCode 原生 Goal adapter、
Kiro CLI goal-mode adapter，以及
DeepSeek Harness turn adapter。

可查看 60 秒 DSH × LoopX Replan 真实录屏和可复现
fixture：安装 Plugin、选择一个
skill、加入新的关键约束，并检查完整保留的决策证据链。

自有 runner 请先看
最小自定义 Runtime 示例
（python3 examples/custom-runtime-minimal-cli-turn-smoke.py），再读完整的
把 LoopX 嵌入你的 Agent Runner
与 Worker Bridge Install Contract。
核心 tick 很小：

loopx quota should-run      # 当前注册 agent 是否应该执行？
loopx todo claim            # 谁拥有这个 slice？
loopx todo update           # 发生了什么？
loopx refresh-state         # 下一轮应该看到什么？
loopx quota spend-slot      # 为完成并验证的 slice 记账

首次运行反馈

如果 LoopX 帮你跑通了第一个任务，欢迎用一分钟提交一条公开反馈（可选，无任何
遥测；不要粘贴日志、路径、凭据、内部项目名或 goal 内容）：

- 首次运行反馈
- 长程使用案例

loopx first-run-report 会在本地打印同样的预填链接，不会发送任何数据。

成功连接后应该满足：

- loopx doctor 通过；
- 项目具有 .loopx/registry.json 和 active goal projection；
- loopx status 能显示当前目标、具体 user gate 和下一条 agent todo；
- 有可见 Loop driver，或 agent 给出精确 activation 指令；
- 本地 runtime state 被 ignore，而不是提交。

Clone 安装只面向需要 live canary wrapper 的贡献者：

git clone https://github.com/loopx-project/loopx ~/loopx
~/loopx/scripts/install-local.sh
loopx doctor

能力

LoopX 显式保留架构边界，使同一个受治理结果在更换 Agent harness 或外部 Provider
后仍然成立。以下术语描述的是不同边界，而不是几种可以互换的插件：

| 边界 | 含义 | 深入阅读 |
| --- | --- | --- |
| Kernel | 持有持久化 goal、todo、gate、evidence、quota、恢复和调度事实。 | 核心架构 |
| Capability | 定义稳定、provider-neutral 的合同，从 LoopX 状态交付一个有界、可验证的调用者结果。 | Capability 目录 |
| Provider | 调用外部系统或本地实现，返回有界 observation、effect result 和 readback。 | Provider 运行责任 |
| Extension | 通过显式安装、readiness、启用、升级、停用和回滚生命周期交付可选 Provider。 | Extension 生命周期 |

--available-capability shell 等 host 声明描述的是已观测到的执行支持；在这张
产品图里属于 runtime capacity，不是产品 Capability，也不授予权限。真正执行前，
Capability 仍须应用自己的 policy 和 authority check，再提出 typed transition。

控制面核心承诺

Kernel 把控制面归结为五个用户可以直接行动的问题。每个问题对应一个产品
承诺：目标 → 长程状态；下一步 → 语义决策；人类判断 → 人机协同；
证据 → 恢复；能否继续 → 治理。

| 问题 | LoopX 保持可见的状态 |
| --- | --- |
| 当前目标是什么？ | Active goal、明确 scope 和当前 authority。 |
| 下一步是什么？ | 有序 user / agent todo、ownership、claim 和 lease。 |
| 哪一步需要人判断？ | 具体 user gate，而不是模糊的“等待 owner”。 |
| 证据发生了什么变化？ | 紧凑 run history、验证、blocker 和已接受 writeback。 |
| Loop 是否可以继续？ | Quota、capability、安全侧路、scheduler hint 和停止条件。 |

控制面能力

| Surface | 作用 | 从这里开始 |
| --- | --- | --- |
| Goal state 与 status | 跟踪 active state、todo、claim、gate、evidence、run history 和首屏关注点。 | loopx status、loopx diagnose、loopx review-packet |
| Quota 与 interaction contract | 决定一轮应该执行、提问、等待、自修复还是静默。 | loopx quota should-run、Quota Allocation |
| Agent runtime bridge | 让 Codex App、Codex CLI、Claude Code 和 generic worker 服从同一 guard。 | loopx heartbeat-prompt、loopx codex-cli-bootstrap-message、loopx worker-bridge |
| Operator surface | 呈现紧凑状态，但不让浏览器成为状态事实源。 | loopx serve-status、Dashboard |
| External projection | 把 todo / gate 投影到协作表面，同时保持 LoopX 权威。 | loopx lark-kanban、Lark Kanban adapter |
| Domain capability | 打包 Issue Fix、内容运营、value connector、ML 实验、benchmark 与 Explore 等可重复泳道。 | loopx issue-fix、loopx content-ops、loopx value-connectors、loopx ml-experiment、loopx benchmark、Explore |
| 实验性上下文学习 | 通过 ignored、默认关闭的项目配置，为明确注册的 agent 试用 provider-neutral Reward Memory；OpenViking 是 provider 之一，不是全局依赖。 | loopx reward-memory experiment-status、Reward Memory 中文架构 |
| Governance pattern | 沉淀可复用的 routing、gate、evidence、projection 和 planning 形状。 | Interaction Pattern Catalog、State Model |

这些能力共同提供 lifetime goal、具体 user gate、经过审计的安全侧路、平级 todo
ownership、quota 与 steering、紧凑 run history、证据化 handoff、read-first 管理面、
项目级价值信号和 public/private boundary check。

产品 Capability 路径

Capability 把上述通用原语组成 outcome-owned 工作泳道。先按结果选择，再检查当前
已注册实现及其写入边界：

| 你需要…… | Capability | 从这里开始 |
| --- | --- | --- |
| 把公开 issue 推进为可审查、有证据的变更 | Issue Fix | loopx capability show issue-fix --format json |
| 在交付前对精确 final diff 做质量验收 | Change Quality | loopx capability show change-quality-qualification --format json |
| 维护由多个已审查分支组成、持续变化的集成栈 | Integration Branch | loopx capability show integration-branch-reconcile --format json |
| 在不丢失假设和发现的前提下探索不确定研究问题 | Explore | loopx capability show explore --format json |
| 基于当前证据和已验证结果重新建立决策上下文 | Decision Context | loopx capability show decision-context --format json |
| 生成带 receipt 的定时或进展触发报告 | Periodic Report | loopx capability show periodic-report --format json |

运行 loopx capability list --format json，读取当前安装版本的权威目录。Capability
详情包含用户价值、成熟度、Provider readiness、入口命令、写入边界、协议和持久
验证。可从人类可读 Capability 索引按结果选择；安装或
开发 Provider 时，再进入Extension 与 Capability。

四种运行责任

| 角色 | 负责什么 |
| --- | --- |
| Agent | 通过 host/runtime 完成方案、分析、工具使用和一次有界执行。 |
| Provider | 调用外部系统，返回 observation、effect result 与 readback。 |
| Capability | 定义调用者结果，归一化并验证 provider 输出，提出 typed transition。 |
| Kernel | 持久化 todo、gate、monitor、已接受 writeback、quota、恢复与调度。 |

执行路径是 Agent -> Capability -> Provider，控制结果沿
Provider readback -> Capability transition -> Kernel 返回。Extension 负责可选
provider 的打包和生命周期，不是另一个控制面 owner。详见
核心架构与
Extension / Capability 参考。

进阶路径

第一次有用的 Loop 不依赖全部可选能力。只有工作真正需要时再开启这些路径。

启用进阶能力前，先只读查看当前目标的能力目录：

loopx configure-goal --goal-id

不带 --execute 时，它只报告当前/默认状态、适用条件、边界和可复制命令，
不会修改项目状态。

Preset 与 Auto Research

安全 preset 覆盖 Daily Triage、Changelog Draft 和 PR Watch。更高级的 CI /
Dependency Sweeper 需要明确授权、隔离 worktree、verifier、quota/cost gate 和人工
review。Auto Research 通过 proposer、executor、evaluator/promoter 协作，同时保持
quota 和证据可见。详见
入门 Preset 指南和
Auto Research Demo Path。

loopx preset list
loopx preset show daily-triage

查看 preset 是只读操作。对已连接的周期性目标，可运行
loopx ready-score --goal-id  --agent-id ，检查它是否适合重复运行。

Governed Turn

LoopX 可以根据 validated receipt、fresh quota state 和 provider-neutral budget
生成一次纯函数、有界的 turn decision。当前 Codex CLI 启动路径和 activation contract
见 LoopX Turn Codex CLI Quickstart。

Explore Graph / Harness

Explore 正式支持、可选、默认关闭。它适合具有可量化 offline eval、baseline、
treatment 和 guardrail 的任务，不替代生产审批。先读
Explore Capability及其
Lark Presentation Mapping。

审阅 Agent 工作

loopx review-packet 提供 owner-facing 的紧凑视图：决策、证据、验证和未解决 gate。
Intelligent Management Surface
解释 operator model；Project-Level Reward Model
定义产出数量、质量、token cost 和 user attention cost 的保守价值信号。

App 与 Projection

- 本地 read-first UI：Dashboard Guide
- 公开产品概览：产品首页
- 文档门户：线上文档
- 飞书投影：Lark Kanban Adapter
- 通用 host 集成：Integration Guide
- 自有 multi-agent runner：
最小自定义 Runtime 示例，
再看 Custom Runner 中文指南

可选 projection 让状态更易检查，但不会成为新的事实源。

日常操作与恢复

日常检查从这三个命令开始：

loopx status
loopx history --goal-id your-project-goal
loopx quota should-run --goal-id your-project-goal

自动轮次必须先检查 quota，只有完成验证与 writeback 后才记录 spend。静默 skip、
preflight failure 和 dry-run preview 不消耗 quota。一个 lane 被 user gate 阻塞时，
独立审计过的安全侧路可以继续，但不能绕过 gate。

平级 agent 在执行前使用 loopx todo claim，验证后使用 loopx todo update，
让 ownership 与证据持续可见。

Scheduler cadence 跟随 quota should-run.scheduler_hint；Codex App automation
通过 payload 返回的 ack_hint.cli_args 确认当前 hint。Collision recovery、monitor、
self-repair 和精确 operator 命令统一维护在
Getting Started、
Quota Allocation和
Long-Task Cadence Policy。

公开发布前运行：

loopx check \
--scan-path README.md \
--scan-path docs/ \
--scan-path examples/

当前技术方向

LoopX 当前有三个活跃战略计划和一个架构与研究孵化器。这些内容用于表达方向，
不是交付承诺；main、已发布 artifact 和 stable reference contract 仍然定义真实
已交付行为。

- 长程 Benchmark 与证据：在互补 benchmark 环境中建立可复现的能力证据，
并开展受控的机制研究。
方向 Tracker
- Operator Surface 与 IM Integration：建设 operator workspace、session
record 与有界协作表面；当前在专用 integration branch 孵化，由 @maxliux5
作为 implementation lead。
方向 Tracker
- Shared Goal Authority 与跨 Host 协作：为显式共享 goal 提供
provider-neutral 协调；NoKV 是尚未晋级的 provider candidate，而不是新的控制面
权威。
方向 Tracker
- 架构与研究孵化器：以明确不同的成熟度推进 Effect Program hardening、
TypeScript parity migration、hierarchical stride、research exploration、human
attention、artifact lifecycle 与 memory utility。
方向 Tracker

完整阶段、promotion gate、贡献者安全切片和 ownership 边界见
当前技术方向地图；社区讨论使用置顶的
GitHub Discussion。核心控制面
可靠性继续作为这些计划共同的底座。

进阶文档

按当前任务选择入口；线上文档
提供发布后的浏览入口，完整文档索引仍是权威地图。这里仅保留
精选入口；每个分类索引负责承接更深层的文档和版本化协议。

使用与运维

- Getting Started：安装、连接、诊断、heartbeat、
dashboard、开发和命令参考。
- 用户手册：
公开 onboarding、概念、FAQ 和案例。
- Operations：goal continuation、todo、cadence、
attention 和 authority 工作流。
- Quota Allocation与
Heartbeat Automation Prompt：scheduler
eligibility、spend 和定时续跑。
- Dashboard与
Status Data Contract：面向操作者的状态与投影契约。
- Release Readiness：安装升级、兼容性 gate、
release note 和稳定表面。

理解控制面

- Architecture：lifetime-goal invariant 与 kernel。
- State Interaction Model：actor、store、
interaction contract 与 writeback。
- Concepts：可复用的 routing、gate、evidence、
projection 与 planning pattern。
- Product Foundations：Loop Engineering
原则、project-level reward 和 reward-style replanning。
- Product Vision：更广义的 Loop Agent 产品方向。

集成与扩展

- Integration Guide
- 最小自定义 Runtime 示例
- Custom Agent Runner 中文指南
- Integrations：runtime、host、协作和外部系统 adapter，
包括 worker bridge 与 Lark。
- Extensions and Capabilities

构建与评审 LoopX

- Developer Guide：贡献者工作流、benchmark 开发、
文档布局和质量 gate。
- Reference and Protocols：稳定契约和版本化实现协议，
包括 host command 与 reward memory architecture。
- 控制面开发者 9 讲。
- Testing and Quality：分层验证与风险检查。
- Public/Private Boundary：安全的 fixture、示例、
evidence 与发布边界。

查看结果与证据

- Showcase Catalog：public-safe 案例和 evidence label。
- Research and Evidence：benchmark 调查和有来源的结论。
- Update Notes：公开安全的进展记录。

项目与社区

- 当前技术方向
- Project Governance
- Contributing与Contributor Tasks
- Authors and Contributors
- Project History
- Name and Marks
- 对外品牌使用指南：开源项目、公司和用户如何引用 LoopX、描述集成并使用图形素材
- ADOPTERS：项目与用户自愿维护的采用目录
- 生态采用清单 - 我们观察并持续追踪的
真实集成、采样借鉴与衍生周边

合作伙伴项目

LoopX 欢迎与其他开源项目协作，共建长程 Agent 生态。已确认的合作伙伴包括：

- OpenViking - 面向 AI Agent 的自进化
上下文数据库
- NoKV - AI 原生分布式文件系统

用户群与反馈

LoopX 已在真实长程 agent 目标上持续运行，并处于活跃迭代期。最需要真实长程
agent 项目里的反馈：控制面帮到了哪里、哪里太重，哪些 gate、handoff 或 scope
仍然不够清楚。

- 可复现 bug、安装问题、功能建议：请提
GitHub Issue。
- 文档修正、showcase 补充、小型 public-safe 示例：欢迎开 PR。
- 参与社区讨论：可加入 Discord 社区，也可在
下方直接加入飞书群或通过微信申请入群。

渠道分工、支持边界和官方发布源见 Support。

飞书：扫码直接加入微信：huangrt00 · 好友申请备注 LoopX

贡献

公开、可认领的任务见 Contributor Tasks。贡献前请读
Contributing，尤其是 public/private 边界、smoke 保留规则和
benchmark 证据边界。

项目角色与维护权限见 Governance，创建者与贡献者归属见
Authors and Contributors，关键公开演进见
Project History，名称与标识使用见
Name and Marks。

不要提交 .loopx/、.codex/goals/、live ACTIVE_GOAL_STATE.md、内部链接、
raw benchmark task/log/trajectory/verifier output、credentials、token、私有路径或
未脱敏的用户与团队信息。

当前状态

LoopX 1.0 已经是一套可用的长程 Agent 本地控制面，正在进入更广泛的采用阶段。
LoopX 不是完整 agent platform，不是 agent runtime，也不是自治生产控制器。

目前 LoopX 已交付围绕 goal、typed todo / decision scope、平级 claim / lease、
evidence / writeback、quota-aware scheduling 和跨轮 continuation 的 durable state
kernel。在这套共享控制状态之上，已经提供 guided start、recurring heartbeat、
隔离 Codex CLI Turn、evidence-backed Issue-Fix admission、可选 Explore / auto
research 路径、公开 validation canary，以及多项目 Personal Workspace。

不同表面的支持等级仍需明确区分：state 与 CLI contract 是稳定核心；部分 host
integration 和进阶路径仍是 optional、default-off 或 experimental。LoopX 不会自行
获得 credential，不会替用户批准 destructive / production action，不会在未授权时
公开发布，也不会把未经验证的 run 当成成功证据。

当前投入按技术方向地图组织：长程
benchmark 证据、operator surface 与 IM integration、shared-goal 跨 host 协作，以及
明确分阶段的架构与研究孵化器。

Star 趋势

由仓库授权的 workflow 每 6 小时基于 GitHub 官方 stargazer 时间戳生成；仅当拉取条数与 GitHub 当前 Star 总数一致时发布。GitHub 图片缓存可能延迟刷新。

License

从 v0.4.8 起采用 Apache License 2.0，见 LICENSE 与
NOTICE。v0.4.7 及更早版本永久保留原 MIT 许可；历史许可证全文与
notice 保存在 LICENSE-MIT。许可证政策
说明版本、贡献、专利授权与 open-core 边界。