Claude Code를 위한 로컬 우선 라우팅 레이어 구축: 요청 처리 에이전트 결정, 접근 권한 제어 및 감사 가능한 영수증 형태의 핸드오프

저는 Claude Code, Codex, Gemini, Cursor 및 터미널 워크플로와 같은 AI 런타임(runtime)을 위한 로컬 우선(local-first) 라우팅 레이어인 Agentlas Network (Hephaestus Network)를 구축했습니다. 저는 이를 Claude Code로 구축했으며, 이는 추론 런타임(reasoning runtime)으로서 Claude Code 위에서 실행됩니다.

기능: 여러 에이전트(agent), 기술(skill), 플러그인(plugin), 프로젝트 메모리(project memory) 및 로컬 도구(local tool)를 갖추게 되면, 어떤 에이전트가 요청을 처리할지, 무엇에 접근할 수 있는지, 어떤 메모리가 로컬에 유지되고 무엇이 허브(Hub)로 전송될지를 결정하는 무언가가 필요합니다. Agentlas Network가 바로 그 라우팅 레이어(routing layer)입니다.

/hephaestus-network <request>를 통해 호출하면, 라우팅 카드(routing card)를 사용하여 작업이 어디로 갈지를 결정합니다. 각 에이전트, 팀 또는 플러그인은 자신이 처리해야 할 사항, 처리하지 말아야 할 사항, 필수 입력값, 역량(capabilities), 리스크 프로필(risk profile), 메모리 동작, 엔트리포인트(entrypoints) 및 벤치마크 케이스를 선언하는 표준화된 라우팅 카드를 제공합니다. 라우터는 다음 순서에 따라 로컬 카드를 먼저 확인합니다: 명시적 명령(explicit commands), 프로젝트 라우팅 오버라이드(project routing overrides), 로컬 라우팅 카드, 그 다음 Agentlas Hub 폴백(fallback).

Hub 폴백 시: Hub는 사용자의 원문 프롬프트(raw prompt)나 로컬 프로젝트 메모리가 아닌, 비식별화된 키워드(redacted keywords)만 수신합니다. 만약 Hub 에이전트가 선택되면, Network는 런타임 번들(runtime bundle)을 가져오고 사용자의 자체 런타임이 작업을 실행합니다.

모든 라우팅 결정은 영수증(receipt)을 작성하므로, 무엇이 선택되었는지, 왜 선택되었는지, Hub 폴백이 사용되었는지, 어떤 실행 번들이 준비되었는지, 그리고 어떤 로컬 라우팅 상태가 관여되었는지를 검사할 수 있습니다.

경로가 선택된 후의 실행을 위해 별도의 구성 요소인 Hephaestus Stormbreaker가 있습니다: 스코프 잠금(scope locks), 이슈 계약(issue contracts), 실패 메모리(failure memory), 증거 루프(evidence loops), 리뷰 게이트(review gates) 및 최종 증명(final proof)을 담당합니다.

Claude Code가 도움이 된 점: 저는 주로 아키텍처 연구 및 설계를 위해 Claude Code를 사용했습니다. Claude Code는 라우팅 패턴을 연구하고 핵심 요소들, 즉 라우팅 카드 스키마(routing card schema), 로컬 우선 폴백 순서, 영수증 로깅 형식 등을 구체화하며, 설계가 변경됨에 따라 멀티 에이전트(multi-agent) 구조를 반복적으로 개선하고 리팩터링(refactor)하는 데 도움을 주었습니다.

무료 체험: 이 프로젝트는 오픈 소스이며 무료로 실행할 수 있습니다.

GitHub에서 저장소(repo)를 클론(Clone)하고, 실행 환경(runtime)에서 /hephaestus-network를 호출하여 직접 체험해 보세요:

https://github.com/agentlas-ai/Hephaestus
제출자: /u/Hot-Leadership-6431
[link] [comments]