나는 비용이 많이 드는 API 루프를 Lobster 기반 파이프라인과 Honcho 메모리 관리 방식으로 대체했으며, 왜 오직 디버거만 유료 엔드포인트에 접근하는지 설명한다.

우리는 모두 이 딜레마를 알고 있습니다. 진정한 멀티에이전트 지능—지속적인 메모리, 서브에이전트 핸드오프, 장기 계획—을 원하지만, 유료 API의 토큰 비용(특히 루핑 메모리 검색 시)은 프로젝트가 출시되기 전에 이를 죽일 수 있습니다.

나는 이 문제를 OpenClaw 설정을 처음부터 다시 구축하여 해결하기로 했다. 목표: 메모리 작업에 대한 추론 비용이 영인 하이브리드 멀티에이전트/서브에이전트 아키텍처와 작업 위임에 대한 거의 영 오버헤드.

여기서 내가 정확히 어떻게 했는지 보여 준다.

아키텍처: 하이브리드 멀티에이전트 + 서브에이전트 스웜

대부분의 구현에서는 모든 에이전트를 일급 API 호출자로 취급한다. 이로 인해 토큰이 소모된다.

내 OpenClaw 설정은 하이브리드 모델을 사용한다:

• 주요 에이전트(오케스트레이터)는 로컬 추론 또는 무료 티어 엔드포인트에서 실행된다.
• 서브에이전트는 일시적이며—특정 작업(검색, 요약, 검증)을 위해 생성되고 즉시 소멸됩니다.
• 비결은? 서브에이전트는 ‘기억’하지 않습니다. 중앙 메모리 저장소를 쿼리하고 실행한 뒤 사라집니다. 이렇게 하면 컨텍스트 윈도우가 작게 유지됩니다. 세션 상태를 보유하는 것은 오직 기본 에이전트뿐입니다.

황금 규칙: 유료 API와 통신하는 것은 오직 디버거뿐이다.

여기서 모든 것을 바꾼 제약 조건이 있습니다.

내 워크플로에서는 유료 API 엔드포인트에 접근할 수 있는 구성 요소는 정확히 하나이며, 바로 디버거입니다.

다른 모든 에이전트—기본 에이전트, 서브에이전트, 오케스트레이터, 메모리 워커—는 로컬 추론(Ollama, LM Studio 또는 무료 티어 클라우드)에서 실행됩니다. 디버거만이 GPT-4, Claude 또는 기타 유료 모델을 호출할 수 있습니다.

왜일까요? 세 가지 이유 때문입니다:

1. 강제된 아키텍처 규율

무언가 오류가 발생하면 디버거가 이를 추적합니다. 하지만 디버거가 유일한 유료 경로이기 때문에, 파이프라인 전반에 API 호출을 뿌려서 “속임수”를 쓸 수 없습니다. 로컬 추론과 메모리 검색을 최적화하도록 강요받습니다.

2. 디버깅은 런타임 의존성이 아닌 유료 티어 서비스이다

시스템은 99%의 시간을 유료 API에 접근하지 않고 실행됩니다. 에이전트가 실패할 때—예상치 못한 출력, 스키마 불일치, 무한 루프—디버거가 활성화됩니다. 디버거는 실패 컨텍스트를 받아 수정을 제안하고 이를 로컬 에이전트에 전달합니다. 이로 인해 유료 API는 런타임 의존이 아닌 예외 처리기로 작동하게 됩니다.

3. 비용은 사용량이 아닌 문제 규모에 따라 증가한다

건전한 파이프라인은 비용이 $0입니다. 버그가 있는 파이프라인은 진단에 몇 센트만 듭니다. 이는 모든 에이전트의 각 턴이 correctness와 관계없이 비용이 발생하는 기존 멀티 에이전트 시스템과 비교해 볼 때 그렇습니다.

Honcho 메모리 관리: 지속 가능, 검색 가능, 무비용

메모리에 대해, 저는 로컬 우선 프로그래밍 가능한 메모리 레이어인 Honcho를 통합했습니다. Honcho가 제공하는 것은:

• 지속 가능한 사용자/세션 저장소
• 클라우드 벡터 데이터베이스 없이 벡터 검색
• 메모리 읽기/쓰기에 대한 API 호출 없음

모든 에이전트 상호작용은 Honcho에 기록됩니다. 모든 서브 에이전트는 Honcho에서 읽어서 자신의 컨텍스트를 초기화합니다. 유료 임베딩은 없습니다. 외부 메모리 서비스는 없습니다.

그리고 디버거가 메모리 작업을 절대 건드리지 않기 때문에 Honcho는 완전히 무료로 실행됩니다.

시간적 감소 + MMR: 오래된 메모리 극복

메모리가 최근 컨텍스트를 압도하면 무용지물이 됩니다. 저는 Honcho 안에 두 가지 검색 메커니즘을 구현했습니다:

1. 시간적 감소

오래된 기억은 지수적으로 가중치가 감소합니다. 10분 전의 사실은 10일 전의 유사한 사실보다 더 관련성이 높습니다. 이로 인해 에이전트가 오래된 정보를 기반으로 행동하는 것을 방지합니다.

2. MMR (최대 마진 관련성)

에이전트가 메모리를 쿼리할 때, MMR은 다양성을 보장합니다. 거의 동일한 메모리 열 개를 반환하는 것을 피합니다. 대신 관련성과 다양성을 얻습니다—이는 넓은 컨텍스트가 필요한 서브에이전트에게 필수적입니다.

둘 다 로컬에서 실행됩니다. 비용: $0. 디버거는 절대 이를 보지 못합니다.

Lobster: 오버헤드 없는 작업 위임 및 파이프라이닝

여기가 토큰 사용이 급감하는 지점입니다.

나는 선형 에이전트 체인을 Lobster (경량 태스크 파이프라인 런타임)으로 대체했다. Lobster는 작업의 방향성 비순환 그래프(DAGs)를 정의할 수 있게 해준다.

내 워크플로:

1. 주요 에이전트가 요청을 서브태스크로 분해한다.
2. 각 서브태스크는 파이프라인 노드로 Lobster에 푸시됩니다.
3. Lobster는 로컬 서브에이전트를 사용하여 서브태스크를 병렬 또는 순차적으로 실행합니다.
4. 노드가 실패하거나 예기치 않은 출력을 생성하면 Lobster가 이를 플래그합니다.
5. 그때서야 디버거가 활성화되어—실패한 노드의 컨텍스트를 받고, 수정을 생성하고, 파이프라인을 다시 시작합니다.

Lobster 파이프라인이 컨텍스트를 재사용하고 중복 LLM 호출을 피하기 때문에, 비교 가능한 작업 부하에서 토큰 소비를 약 70-80% 줄였습니다. 그리고 디버거가 예외만 처리하기 때문에 이 70-80% 감소는 유료 사용에 특별히 적용됩니다.

토큰 사용에 미치는 실제 영향 (유료 API)

숫자에 대해 이야기해 봅시다.

이 설정 이전에는 일반적인 멀티에이전트 대화가 3명의 에이전트가 각각 GPT-4를 호출하는 형태였습니다. 모든 프롬프트에 메모리 검색이 추가되었습니다. 결과: 사용자 상호작용당 8,000–12,000 토큰.

OpenClaw + Honcho + Lobster + debugger-only 유료 액세스 이후: 주요 에이전트는 로컬에서 실행됩니다. 서브 에이전트는 로컬에서 실행됩니다. 메모리는 로컬에서 실행됩니다. Lobster는 API 호출 없이 모든 것을 오케스트레이션합니다. 유료 API 사용은 오류 시에만 발생하며—파이프라인 안정화 후에는 상호작용의 <5%에서 발생합니다.

결과: 유료 API당 상호작용당 50–500 토큰이며, 대부분의 상호작용은 $0 비용이 듭니다.

이는 기존 멀티 에이전트 시스템에 비해 유료 토큰 사용량이 20-100x 감소함을 의미합니다.

대용량 애플리케이션—고객 지원, 연구 에이전트, 자동화—에서는 이것이 실행 가능한 제품과 돈 먹는 함정 사이의 차이를 만듭니다. 하루에 10,000번의 상호작용이 있을 때, 기존 설정은 $200–$500 정도 비용이 들 수 있습니다. 이 설정은 거의 비용이 들지 않으며, 비용이 발생하더라도 몇 페니 수준입니다.

디버거 전용 제약이 더 나은 엔지니어링을 강요하는 이유

여기서 반직관적인 통찰을 얻을 수 있습니다: 디버거에 유료 API 사용을 제한하면 시스템 신뢰성이 향상되며, 이는 비용 절감 이상의 효과를 가져옵니다.

모든 에이전트가 GPT-4를 호출할 수 있다면, 성가신 프롬프트, 불량한 메모리 검색, 취약한 파이프라인을 용인하게 됩니다. 유료 API는 균열을 메워 줍니다.

디버거만 해당 권한을 갖게 되면, 다음과 같이 강요됩니다:

• 엣지 케이스를 처리하는 강력한 로컬 프롬프트를 작성하라.
• 적절한 메모리 감소와 MMR을 설계하여 끊임없는 관리 없이 검색이 작동하도록 하라.
• 명확한 성공/실패 기준을 갖춘 Lobster 파이프라인을 설계하라.
• 유료 모델을 노동자가 아닌 조사자로 대하라.

결과는 우아하게 실패하고, 스스로 디버그하며, 운영 비용이 거의 들지 않는 시스템이다.

왜 이것이 중요한가

비용이 많이 드는 클라우드 메모리나 끊임없는 API 루프 없이도 지능형 에이전트를 구축할 수 있다.

OpenClaw, Honcho, Lobster 그리고 디버거 전용 유료 API 제약을 활용하면 다음과 같은 것을 구축할 수 있습니다:

• 시간적 감쇠와 MMR을 갖는 지속적 메모리
• 하이브리드 에이전트/서브에이전트 군집
• 작업 파이프라인 및 자동 장애 복구
• 유료 API가 런타임 의존성이 아닌 예외 처리기인 시스템

...모든 동시에 유료 API 비용을 0에 가깝게 유지하면서

저는 이것을 제한하지 않습니다. 설정 파일, Honcho 스키마, Lobster DAG 정의, 또는 파이프라인 실패 시에만 디버거가 활성화되도록 내가 어떻게 연결했는지에 대해 물어보세요.

더 저렴하게 구축합시다. 더 똑똑하게 구축합시다. 유료 API를 첫 번째 본능이 아닌 마지막 수단으로 만듭시다.