oxi · Agent OS · Rust
oxios
Agent Operating System. LLM은 chat box에 갇혀 있다 — oxios는 그 chat box를 운영체제로 바꾼다. Supervisor로 에이전트를 띄우고, Ouroboros로 스펙을 만들고, A2A로 다른 에이전트와 협업한다.
0. 주요 화면
mock 데이터로 빌드된 React SPA 실제 화면. daemon 없이 /api를 mock 가로채고 zustand chat store를 pre-seed했다 (Web UI 섹션 참조).
1. 무엇을 풀려는가
| 문제 | 해결책 |
|---|---|
| chat 닫으면 에이전트도 죽음 | Supervisor: fork / exec / wait / kill — Unix 프로세스처럼 |
| 스펙 없이 실행 → 출력 신뢰 불가 | Ouroboros: assess → crystallize → execute → review |
| 앱마다 브라우저/실행 재발명 | Built-in engine: 헤드리스 브라우저(oxibrowser) · 호스트 exec · MCP 브리지 · 스킬 |
| 세션 사이 기억 없음 | Vector memory: 지속·검색·시맨틱 회상 |
| 에이전트 사이 보안 경계 없음 | Access Manager: RBAC · 경로 샌드박스 · Merkle-chain 감사 로그 |
| LLM 프로바이더 장애가 연쇄 전파 | Circuit Breaker: 3-state 보호 |
| 에이전트 간 작업 위임 프로토콜 없음 | A2A: Google의 agent-to-agent 프로토콜 |
2. 레이어 아키텍처
KernelHandle 파사드로 노출한다. 모든 실행은 oxicode-sdk 기반.
2.1 KernelHandle — 22개 API
외부에서 Kernel을 다룰 때의 단일 진입점.
- State · Agent · Security · Persona · Extension
- MCP · Infra · Space · Exec · Browser
- A2A · Knowledge
3. 핵심 서브시스템
3.1 Supervisor
Oxios의 init. Unix의 fork/exec/wait/kill을 에이전트에 그대로 적용. Send+Sync 트레잇 객체로 어디든 띄울 수 있다.
3.2 Ouroboros Protocol
"스펙 없이 실행하지 않는다"는 원칙을 강제. 4단계 unified flow (재시도 2회):
- assess — 의도와 요구사항 평가
- crystallize — 실행 가능한 스펙 생성
- execute — 실행
- review — 결과 검토, 실패 시 최대 2회 재시도
3.3 Built-in Browser
oxibrowser를 내장. 별도 Chromium 설치나 헤드리스 브라우저 subprocess 없음 — 모두 in-process. AI 에이전트는 kernel.browser 한 줄로 웹 자동화를 시작한다.
3.4 Skills
프롬프트 스킬 시스템 (brainstorming, code review, …). 사용자가 정의한 스킬도 동적 로드.
3.5 Vector Memory
시맨틱 검색 가능한 영속 메모리. 세션 간 컨텍스트 유지.
3.6 Spaces
에이전트 작업 컨텍스트 분리 (worktree 기반 isolation과 결합).
3.7 MCP & A2A
MCP(Model Context Protocol)로 외부 도구 통합. A2A로 다른 에이전트와 수평 통신.
3.8 Persona System
사용자/에이전트 페르소나 정의. 작업 톤과 권한을 페르소나 단위로 묶는다.
3.9 Circuit Breaker
3-state (Closed/Open/Half-Open) 보호. LLM 프로바이더 장애가 한 호출에서 시스템 전역으로 번지지 않는다.
3.10 Git Integration
worktree 기반 작업 격리. 에이전트 작업이 메인 브랜치를 오염시키지 않는다.
3.11 Cron Scheduler · Budget Manager · Resource Monitor
백그라운드 작업, 토큰 예산, 리소스(CPU/RAM/디스크) 모니터링.
4. 워크스페이스 구조
oxios-kernel
Supervisor · Orchestrator · Scheduler · 13 서브시스템
oxios-gateway
채널 무관 메시지 라우팅 (Web · CLI · Telegram)
oxios-ouroboros
스펙 우선 프로토콜 엔진 — Seed/Phase/Evaluation 타입
oxios-memory
Vector memory — 시맨틱 회상·영속
oxios-mcp
MCP(Model Context Protocol) 통합
oxios-markdown
마크다운 렌더링·문서 도구
oxios-calendar
시간 기반 트리거·스케줄링
5. 보안 모델
- 최소 권한: 에이전트는 최소 권한으로 시작, 추가 권한은 명시적 부여 필요
- 변조 방지 감사: 모든 보안 관련 행동은 Merkle-chain으로 연결된 감사 로그에 기록
- 경로 샌드박스: 파일 시스템 접근은 화이트리스트 기반
- 샌드박스 escape 표면 제거: 컨테이너 없음, 직접 호스트 실행이지만 권한/경로 레이어로 차단
6. 디자인 철학
Unix
한 가지만 잘한다. 작은 조각을 조합한다. 에이전트에 fork/exec/wait/kill. 이벤트에 pipe. 컨테이너 없음.
Ouroboros
스펙 없이 실행하지 않는다. assess → crystallize → execute → review (재시도 2회).
No reimplementation
oxicode-sdk를 재사용. 이미 있는 걸 다시 만들지 않는다.
7. 3자 통합 — oxicode-sdk · oxibrowser · oxios
oxios는 두 개의 foundation tier를 동시에 합성한다.
7.1 oxicode-sdk 통합
oxicode-sdk의 멀티 에이전트 빌더 패턴을 oxios-kernel이 그대로 사용한다.
AgentRuntime이 oxicode_sdk::AgentLoop를 감싸고, 에이전트 정의는 동일한 Rust 타입.
oxicode CLI에서 만든 에이전트 그룹이 oxios에서도 동작한다.
7.2 oxibrowser 통합
kernel.browser API는 oxibrowser를 in-process로 임베드한다 (oxios/Cargo.toml의
oxibrowser = "0.17" 의존). subprocess Chromium, Playwright dependency, 외부 바이너리 호출 없음.
헤드리스 브라우저가 24MB 단일 바이너리에 들어간다. oxicode도 같은 oxibrowser를 다른 트레잇 레이어(browser)로 사용한다 — 같은 foundation을 공유하지만 각자의 도구 호출 모델에 맞게 노출한다.
7.3 통합의 효과
- 단일 바이너리 배포: oxios 사용자 입장에서 oxibrowser 설치/관리가 없다
- 낮은 리소스: 100개 에이전트가 동시에 브라우저를 띄워도 추가 프로세스 없음
- 공통 철학: 둘 다 Rust-first · single-binary · AI-agent-first
- Composition over reimplementation: oxios는 자체 브라우저를 만들지 않고 oxibrowser를 재사용
oxicode-sdk와 oxibrowser가 foundation tier를 이루고, oxios가 둘을 합성한다.