장기 실행 AI 에이전트 작업을 위한 로컬 제어 평면 (local control plane).

Codex, Claude Code, Cursor 또는 사용자의 자체 런타임 (runtime)이 제한된 턴 (turns)을 실행하는 동안 목표 (objectives), 게이트 (gates), 할 일 (todos), 증거 (evidence), 할당량 (quota) 및 인계 (handoffs)를 안정적으로 유지합니다.

LoopX 시도하기 · 실제 루프 보기 · 작동 방식 · 호스팅된 프론트스테이지 (frontstage) · 사용자 매뉴얼 · 简体中文

일할 줄 아는 에이전트 (Agent)를 관리 가능하고, 복기 가능하며, 지속적으로 개선할 수 있는 디지털 직원으로 연결하세요.

루프 엔지니어링 (loop engineering)을 위한 경량 상태 커널 (state kernel)이자 에이전트 불가지론적 (agent-agnostic) 로컬 제어 평면 (local control plane)인 LoopX는 장기 실행 작업을 검토 가능하고, 재시작 가능하며, 턴 (turns), 도구 (tools) 및 에이전트 (agents) 간의 인계 (handoff)를 더 쉽게 만들어 줍니다. 이는 사용자의 에이전트 런타임 (agent runtime)을 대체하지 않습니다.

장기 실행 AI 에이전트 및 피어 에이전트 (peer agent) 팀을 위한 루프 엔지니어링 (loop engineering).

루프를 계속 움직이게 하세요. 판단은 인간이 내리게 하세요.

에이전트는 한 세션 내에 작업을 완료할 수 있습니다. 하지만 장기 실행 작업은 더 어렵습니다. 목표 (objectives)가 변경되고, 소유자의 결정이 나타나며, 증거 (evidence)가 오래되어 쓸모없게 되고, 에이전트가 동료에게 작업을 넘기며, 스케줄러 (scheduler)가 더 이상 유용한 전환이 남지 않았음에도 계속 비용을 지출할 수 있습니다. 채팅 메모리 (Chat memory)와 타이머 (timer)만으로는 이를 관리하기에 충분하지 않습니다.

LoopX는 내구성이 있는 제어 상태 (control state)를 하나의 컴팩트한 레이어 (layer)에 유지합니다:

objective / issue / project
│
▼
...

유용한 사고 모델은
**장기 실행 작업을 위한 에이전트 네이티브 칸반 (agent-native Kanban)**입니다.
카드에는 정체성 (identity), 권한 (authority), 증거 (evidence) 및 연속성 (continuation)이 담겨 있습니다. 이동은 claim, gate, monitor, writeback과 같은 검증된 연산자 (operators)에 의해 이루어집니다. 보드는 투영 (projection)일 뿐이며, LoopX 상태가 진실의 원천 (source of truth)으로 남습니다.

등록된 에이전트들은 피어 (peers)입니다. claim, lease, 작업 경계 (task boundaries), 역량 (capabilities) 및 유형화된 연속성 (typed continuation)이 다음에 누가 행동할지를 결정하며, 내구성이 있는 리더 정체성 (leader identity)은 필요하지 않습니다.

LoopX는 다음과 같은 경우에 유용합니다:

• 며칠씩 걸리는 엔지니어링, 연구, 벤치마크 또는 실험 목표;
• 범위 (scope), 증거 (evidence) 및 검토 상태 (review state)를 보존해야 하는 이슈 (issue) 및 PR 루프;
• 반복적인 하트비트 (heartbeat) 또는 모니터링 (monitor) 작업;
• 소유자, 안전, 출판 또는 개인 데이터 게이트 (gates)가 있는 프로젝트;
• 소유권 (ownership), 임대 (leases) 및 인계 (handoff)가 중요한 피어 에이전트 (peer-agent) 팀;
• 진행 상황이 엔지니어링 전문 지식이 없는 운영자에게도 읽기 쉬워야 하는 크리에이터, 연구 또는 운영 워크플로 (workflows).

LoopX는 자율적인 프로덕션 컨트롤러 (production controller)가 아닙니다. 위험한 권한, 게시 (publishing), 프로덕션 쓰기 (production writes), 그리고 최종 소유권은 인간에게 유지됩니다.

이것들은 단발성 데모가 아닙니다. OpenViking Issue-Fix 및 Auto ML 궤적 (trajectories)은 각각 수많은 제한된 턴 (turns), 결정 (decisions), 그리고 증거 업데이트 (evidence updates)를 거치며 **200시간 이상의 경과된 루프 수명 (elapsed loop lifetime)**에 걸쳐 있습니다. 경과된 수명 (Elapsed lifetime)은 실제 프로젝트 시간 (wall-clock project time)을 의미하며, 200시간 동안 모델이 연속적으로 실행되었다거나 관리되지 않는 프로덕션 자율성 (production autonomy)을 주장하는 것이 아닙니다. 각 시각 자료를 열어 공개적으로 안전한 그래프 (public-safe graph), 증거 브랜치 (evidence branches), 그리고 턴 (turns) 전반에 걸쳐 보존된 결정들을 검토하십시오.

200시간 이상의 공개 기여 아크 (contribution arc): PR 전달과 재사용 가능한 수정 지식 (fix knowledge)이 함께 진화합니다.

LoopX의 제작자는 OpenViking 기여자로서 이 경로를 사용합니다. 표현된 공개 기여 시퀀스 (contribution sequence)는 첫 PR 생성부터 가장 최근에 표현된 리뷰 또는 업데이트까지 200시간 이상의 경과된 시간을 포함합니다. Issue-Fix 기능은 계속해서 흐르는 리포지토리 컨텍스트 (repository context), 리비전 스탬프가 찍힌 수정 지식 (revision-stamped fix knowledge), 그리고 리뷰어 대상 선호도 (reviewer-facing preferences)를 분리하여 유지합니다. 연결된 PR과 현재 체크아웃된 소스 및 테스트가 권위 있는 정보 (authoritative)로 남습니다.

200시간 이상의 소유자 운영 실험 아크 (experiment arc): 가설 (hypotheses), 일치하는 증거 (matched evidence), 무효한 계보 (invalid lineages), 실행 중인 복제본 (running replicates), 그리고 승인/중단 게이트 (promote/stop gates)가 하나의 그래프에 표시됩니다.

비식별 처리된 공개 안전 그래프 (redacted public-safe graph)는 해당 200시간 이상의 경과된 기간 동안의 결정 계보 (decision lineage)를 보존합니다. 이것은 궤적 증거 (trajectory evidence)이며, 연속적인 컴퓨팅 (continuous compute), 독립적인 재현 (independent reproduction), 또는 프로덕션 결과 (production result)를 주장하는 것이 아닙니다.

제안자 (Proposer), 실행자 (executor), 그리고 평가자/승인자 (evaluator/promoter) 에이전트들이 할 일 (todo), 할당량 (quota), 증거 (evidence), 그리고 타겟 웨이크 (targeted wake)가 보이는 동안 병렬로 반복 (iterate)합니다.

더 자세히 검토 가능한 요소들:

• 호스팅된 프런트스테이지 (frontstage) 및 공개 데모 스크립트;
• 차단된-P0 안전 로테이션 (blocked-P0 safe rotation), LoopX 자기 반복 (self-iteration), 그리고 동적 워크플로 오케스트레이션 (dynamic workflow orchestration)을 포함한 쇼케이스 카탈로그;
• 크로스 런타임 구현 리뷰 (cross-runtime implementation review) 데모;
• 공개 사용자 매뉴얼.

요구 사항: Python 3.11+, curl, tar

, 그리고 macOS 또는 Linux 셸이 필요합니다. Git은 기여자(contributor)의 클론(clone)/카나리(canary) 워크플로우에만 필요합니다. Python 패키지는 표준 라이브러리 외에 별도의 런타임 의존성(runtime dependencies)이 없습니다.

클론 없이 설치하기:

curl -fsSL https://raw.githubusercontent.com/huangruiteng/loopx/main/scripts/install-from-github.sh | bash
export PATH="$HOME/.local/bin:$PATH"
loopx doctor

그 다음 프로젝트 루트에서 연결하세요:

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

프로젝트가 초기화되지 않았고 connect 명령이 상태(state)가 누락되었다고 알려주는 경우, 가이드 모드(guided path)를 사용하세요:

loopx start-goal --guided --project . --goal-text "Your long-running objective"

LoopX는 기존 상태를 덮어쓰는 대신 재사용해야 합니다. .loopx/, .codex/goals/, .local/ 디렉토리는 무시(ignored) 상태로 유지하세요.

정확하게 복사하여 사용할 수 있는 설정 메시지와 호스트 복구 경로(host recovery paths)는 Getting Started에 있습니다. 호스트 통합(Host integrations)은 Codex App 호스트 명령 레지스트리 계약(command registry contract), Codex CLI 패키지 설치 경로, 또는 Claude Code 어댑터를 검사할 수 있습니다.

커스텀 러너(custom runners)의 경우, Embed LoopX in Your Agent Runner 및 worker bridge 설치 계약을 읽어보세요. 핵심 틱(core tick)은 의도적으로 작게 설계되었습니다:

loopx quota should-run # 등록된 에이전트가 지금 작동해야 하는가?
loopx todo claim # 이 슬라이스(slice)의 소유자는 누구인가?
loopx todo update # 무엇이 변경되었는가?
...

연결이 성공하면 다음과 같은 상태를 가집니다:

loopx doctor가 통과됨;
.loopx/registry.json 및 예상되는 활성 목표 상태(projected active goal state);
loopx status가 현재 목표, 구체적인 사용자 게이트(user gate), 그리고 다음 에이전트 할 일(todo)을 보여줌;

• 가시적인 루프 드라이버(loop driver) 또는 정확한 활성화 지침;
• 커밋(commit)되는 대신 무시되는 로컬 런타임 상태.

클론(Clone) 기반 설치는 라이브 카나리 래퍼(live canary wrapper)를 원하는 기여자(contributors)를 위한 것입니다:

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

LoopX는 제어 평면(control-plane) 메커니즘을 다섯 가지 질문으로 접어 넣습니다:

출시된 프리미티브(primitives)에는 수명 주기 목표(lifetime goals), 구체적인 사용자 게이트(concrete user gates), 감사된 안전한 폴백(audited safe fallbacks), 피어 할 일 소유권(peer todo ownership), 할당량 및 조종(quota and steering), 압축된 실행 이력(compact run history), 증거 기반 핸드오프(evidence-backed handoff), 읽기 우선 관리 표면(read-first management surface), 프로젝트 수준의 가치 신호(project-level value signals), 그리고 공개/비공개 경계 검사(public/private boundary checks)가 포함됩니다.

실행 경로(execution path)는 Agent -> Capability -> Provider이며, 제어 경로(control path)는 Provider readback -> Capability transition -> Kernel로 반환됩니다. 확장은 선택적인 프로바이더가 어떻게 패키징되고 관리되는지에 관한 것이지, 또 다른 컨트롤 플레인(control-plane) 소유자가 아닙니다. Architecture 및 Extensions and Capabilities를 참조하세요.

첫 번째 유용한 루프는 모든 선택적 인터페이스(optional surface)를 필요로 하지 않습니다. 작업에 필요한 경우에만 이를 추가하세요.

고급 경로를 활성화하기 전에 현재 목표의 읽기 전용 커패빌리티 카탈로그(read-only capability catalog)를 검사하십시오:

loopx configure-goal --goal-id <goal-id>

--execute 없이 실행하면, 프로젝트 상태를 변경하지 않고 현재/기본 상태, 적합성, 경계 및 복사 가능한 명령을 보고합니다.

안전한 프리셋(presets)은 일일 분류(daily triage), 변경 로그 초안(changelog drafts), PR 모니터링(PR watching)을 지원합니다. 단일 명령 연구 경로(one-command research path)는 할당량과 증거를 가시적으로 유지하면서 제안자(proposer), 실행자(executor), 그리고 평가자/승격자(evaluator/promoter) 역할을 조정합니다. 초보자 프리셋 가이드와 Auto Research 명령 경로를 참조하세요.

loopx preset list
loopx preset show daily-triage

프리셋 검사는 읽기 전용입니다. 연결된 반복 목표(recurring goal)의 경우, loopx ready-score --goal-id <goal-id> --agent-id <agent-id>를 통해 루프가 반복해서 실행될 준비가 되었는지 보고합니다.

LoopX는 검증된 영수증(validated receipt), 최신 할당량 상태(fresh quota state), 그리고 프로바이더 중립적인 예산(provider-neutral budget)으로부터 하나의 순수하고 제한된 턴 결정(bounded turn decision)을 생성할 수 있습니다. 현재 Codex CLI 퀵스타트 및 활성화 계약은 LoopX Turn for Codex CLI에 문서화되어 있습니다.

Explore 기능은 지원되지만 선택 사항이며, 기본적으로는 꺼져 있습니다. 이 기능은 작업에 측정 가능한 오프라인 평가 (offline evaluation), 베이스라인 (baseline), 처치 (treatment), 그리고 가드레일 (guardrails)이 있을 때 가장 효과적입니다. 이는 운영 환경 승인 (production approval)을 대체하는 것이 아닙니다. Explore 기능과 그 Lark 프레젠테이션 매핑 (presentation mapping)부터 시작하세요.

loopx review-packet 명령어를 사용하면,

결정 사항, 증거 (evidence), 검증 (validation), 그리고 해결되지 않은 게이트 (unresolved gates)를 소유자 관점에서 간결하게 확인할 수 있습니다. 지능형 관리 인터페이스 (intelligent management surface)는 운영 모델 (operator model)을 설명하며, 프로젝트 수준의 보상 모델 (project-level reward model)은 출력량, 품질, 토큰 비용, 그리고 사용자 주의 비용 (user attention cost) 전반에 걸친 보수적인 가치 신호를 설명합니다.

하나의 구체적인 피어 워크플로우 (peer workflow) 사례로, 크로스 런타임 구현 리뷰 데모를 참조하십시오: Claude가 구현하고 Codex가 리뷰하는 동안, LoopX는 소유권, 증거, 할당량 (quota), 그리고 핸드오프 (handoff)를 명시적으로 유지합니다.

• 로컬 Read-first UI: 대시보드 가이드
• 공개 안전 제품 뷰: 호스팅된 프런트스테이지 (frontstage)
• Feishu/Lark 투영: Lark 칸반 (Kanban) 어댑터
• 범용 호스트 통합: 통합 가이드
• 커스텀 멀티 에이전트 러너: 커스텀 러너 통합

선택적 투영 (projections)은 상태 검사를 용이하게 하지만, 이것이 신뢰할 수 있는 단일 원천 (source of truth)이 되지는 않습니다.

다음 명령어로 일일 점검을 시작하십시오:

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

자동 턴 (Automatic turns)은 반드시 할당량을 먼저 확인해야 하며, 검증된 쓰기 작업 (validated writeback) 이후에만 비용 지출을 추가해야 합니다. 조용한 건너뛰기 (Quiet skips), 사전 점검 실패 (preflight failures), 그리고 드라이 런 (dry-run) 미리보기는 비용을 소모하지 않습니다. 사용자 게이트 (user gate)가 하나의 경로를 차단할 때, 별도로 감사된 안전한 폴백 (safe fallback)이 계속될 수 있지만, 반드시 게이트를 우회해서는 안 됩니다.

피어 에이전트 (Peer agents)는 전달 전에는 loopx todo claim을, 검증 후에는 loopx todo update를 사용하여 소유권과 증거가 계속 가시적으로 유지되도록 합니다.

스케줄러 주기 (Scheduler cadence)는 quota should-run.scheduler_hint를 따릅니다. 설치된 Codex App 자동화는 반환된 ack_hint.cli_args를 통해 현재 힌트를 확인합니다. 충돌 복구 (Collision recovery), 모니터 의미론 (monitor semantics), 자가 수리 (self-repair), 그리고 정확한 운영자 명령은 Getting Started, Quota Allocation, 그리고 Long-Task Cadence Policy에 유지 관리됩니다.

공개 문서(public docs)나 예제를 게시하기 전에:

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

본인의 역할(role)과 일치하는 경로로 시작하세요. 문서 인덱스(documentation index)는 전체 지도로 유지됩니다.