요약: Anthropic은 Claude의 Research 기능을 통해 복잡한 주제를 더 효과적으로 탐색할 수 있는 멀티 에이전트 시스템을 개발했습니다. 이 시스템은 리드 에이전트가 연구 계획을 세우고 전문화된 서브에이전트들이 병렬로 정보를 검색하여 연구를 수행합니다. 멀티 에이전트 시스템은 연구와 같은 개방형 문제 해결에 특히 효과적이며, 단일 에이전트 시스템보다 90.2% 더 우수한 성능을 보였습니다. 하지만 토큰 사용량이 많고, 에이전트 간 조정 및 평가에 새로운 과제가 발생하는 등의 단점도 존재합니다. 신중한 프롬프트 엔지니어링, 도구 설계, 포괄적인 테스트, 견고한 운영 관행을 통해 프로덕션 환경에서 안정적으로 운영할 수 있습니다.
Claude는 이제 웹, Google Workspace 및 모든 통합을 통해 검색하여 복잡한 작업을 수행할 수 있는 Research 기능을 갖추게 되었습니다.
이 멀티 에이전트 시스템이 프로토타입에서 프로덕션으로 가는 여정은 시스템 아키텍처, 도구 설계, 프롬프트 엔지니어링에 대한 중요한 교훈을 가르쳐주었습니다. 멀티 에이전트 시스템은 함께 작동하는 여러 에이전트(루프에서 자율적으로 도구를 사용하는 LLM)로 구성됩니다. 우리의 Research 기능은 사용자 쿼리를 기반으로 연구 프로세스를 계획한 다음 도구를 사용하여 정보를 동시에 검색하는 병렬 에이전트를 만드는 에이전트를 포함합니다. 여러 에이전트가 있는 시스템은 에이전트 조정, 평가, 신뢰성에 있어 새로운 과제를 도입합니다.
이 게시물은 우리에게 효과가 있었던 원칙들을 상세히 설명합니다. 여러분이 자신만의 멀티 에이전트 시스템을 구축할 때 적용하는 데 도움이 되기를 바랍니다.
멀티 에이전트 시스템의 이점
연구 작업은 미리 필요한 단계를 예측하기 매우 어려운 개방형 문제를 포함합니다. 복잡한 주제를 탐색하는 과정은 본질적으로 동적이고 경로 의존적이므로 고정된 경로를 하드코딩할 수 없습니다. 사람들이 연구를 수행할 때는 연구 과정에서 발생하는 단서를 따르며 발견에 따라 접근 방식을 지속적으로 업데이트하는 경향이 있습니다.
이러한 예측 불가능성은 AI 에이전트가 연구 작업에 특히 적합하게 만듭니다. 연구는 조사가 전개됨에 따라 피벗하거나 인접한 연결을 탐색할 수 있는 유연성을 요구합니다. 모델은 중간 발견 사항을 기반으로 추구할 방향에 대해 결정을 내리며 자율적으로 여러 턴 동안 작동해야 합니다. 선형적이고 일회성 파이프라인은 이러한 작업을 처리할 수 없습니다.
검색의 본질은 압축입니다. 방대한 말뭉치에서 통찰력을 추출하는 것입니다. 서브에이전트는 자체 컨텍스트 창으로 병렬로 작동하여 질문의 다양한 측면을 동시에 탐색한 다음 가장 중요한 토큰을 리드 연구 에이전트를 위해 압축함으로써 압축을 용이하게 합니다. 각 서브에이전트는 또한 관심사의 분리—별개의 도구, 프롬프트, 탐색 궤적—을 제공하며, 이는 경로 의존성을 줄이고 철저하고 독립적인 조사를 가능하게 합니다.
지능이 임계값에 도달하면 멀티 에이전트 시스템은 성능을 확장하는 중요한 방법이 됩니다. 예를 들어, 개별 인간은 지난 100,000년 동안 더 지능적으로 되었지만, 인간 사회는 정보 시대에 집단 지능과 조정 능력 덕분에 기하급수적으로 더 capable해졌습니다. 일반적으로 지능적인 에이전트도 개별적으로 작동할 때는 한계에 직면합니다. 에이전트 그룹은 훨씬 더 많은 일을 성취할 수 있습니다.
내부 평가에 따르면 멀티 에이전트 연구 시스템은 여러 독립적인 방향을 동시에 추구하는 너비 우선 쿼리에 특히 뛰어납니다. Claude Opus 4를 리드 에이전트로, Claude Sonnet 4 서브에이전트를 사용하는 멀티 에이전트 시스템은 내부 연구 평가에서 단일 에이전트 Claude Opus 4보다 90.2% 더 우수한 성능을 보였습니다. 예를 들어, S&P 500 정보 기술 부문 회사의 모든 이사회 멤버를 식별하라는 요청에서 멀티 에이전트 시스템은 이를 서브에이전트를 위한 작업으로 분해하여 정답을 찾았지만, 단일 에이전트 시스템은 느린 순차적 검색으로 인해 답을 찾지 못했습니다.
멀티 에이전트 시스템은 주로 문제를 해결하는 데 충분한 토큰을 소비할 수 있게 하기 때문에 작동합니다. 우리의 분석에서 세 가지 요인이 BrowseComp 평가(브라우징 에이전트가 찾기 어려운 정보를 찾는 능력을 테스트함)의 성능 분산의 95%를 설명했습니다. 토큰 사용량 자체가 분산의 80%를 설명하며, 도구 호출 수와 모델 선택이 다른 두 가지 설명 요인입니다. 이 발견은 병렬 추론을 위한 더 많은 용량을 추가하기 위해 별도의 컨텍스트 창이 있는 에이전트 간에 작업을 분배하는 우리의 아키텍처를 검증합니다. 최신 Claude 모델은 토큰 사용에 대한 큰 효율성 승수 역할을 합니다. Claude Sonnet 4로 업그레이드하는 것이 Claude Sonnet 3.7에서 토큰 예산을 두 배로 늘리는 것보다 더 큰 성능 향상을 가져옵니다. 멀티 에이전트 아키텍처는 단일 에이전트의 한계를 초과하는 작업에 대해 토큰 사용을 효과적으로 확장합니다.
단점도 있습니다. 실제로 이러한 아키텍처는 토큰을 빠르게 소비합니다. 우리의 데이터에 따르면 에이전트는 일반적으로 채팅 상호작용보다 약 4배 더 많은 토큰을 사용하고, 멀티 에이전트 시스템은 채팅보다 약 15배 더 많은 토큰을 사용합니다. 경제적 실현 가능성을 위해 멀티 에이전트 시스템은 작업의 가치가 높아서 향상된 성능에 대한 비용을 지불할 수 있는 작업이 필요합니다. 또한, 모든 에이전트가 동일한 컨텍스트를 공유해야 하거나 에이전트 간에 많은 종속성이 포함된 일부 도메인은 현재 멀티 에이전트 시스템에 적합하지 않습니다. 예를 들어, 대부분의 코딩 작업은 연구보다 진정으로 병렬화 가능한 작업이 적으며, LLM 에이전트는 아직 실시간으로 다른 에이전트에 조정하고 위임하는 데 뛰어나지 않습니다. 우리는 멀티 에이전트 시스템이 강력한 병렬화, 단일 컨텍스트 창을 초과하는 정보, 그리고 수많은 복잡한 도구와 인터페이스하는 작업에 뛰어나다는 것을 발견했습니다.
Research 시스템의 아키텍처 개요
우리의 Research 시스템은 오케스트레이터-워커 패턴을 사용하는 멀티 에이전트 아키텍처를 사용하며, 리드 에이전트는 프로세스를 조정하고 병렬로 작동하는 전문화된 서브에이전트에 작업을 위임합니다.
작동 중인 멀티 에이전트 아키텍처: 사용자 쿼리는 다양한 측면을 병렬로 검색하는 전문화된 서브에이전트를 만드는 리드 에이전트를 통해 흐릅니다.
사용자가 쿼리를 제출하면 리드 에이전트가 이를 분석하고 전략을 개발한 다음 서브에이전트를 생성하여 다양한 측면을 동시에 탐색합니다. 위 다이어그램에서 볼 수 있듯이, 서브에이전트는 반복적으로 검색 도구를 사용하여 정보(이 경우 2025년 AI 에이전트 회사에 대한 정보)를 수집하는 지능형 필터 역할을 한 다음 회사 목록을 리드 에이전트에 반환하여 최종 답변을 컴파일할 수 있도록 합니다.
검색 증강 생성(RAG)을 사용하는 전통적인 접근 방식은 정적 검색을 사용합니다. 즉, 입력 쿼리와 가장 유사한 청크 세트를 가져와서 이 청크를 사용하여 응답을 생성합니다. 이에 비해 우리의 아키텍처는 관련 정보를 동적으로 찾고, 새로운 발견에 적응하며, 결과를 분석하여 고품질 답변을 공식화하는 다단계 검색을 사용합니다.
우리의 멀티 에이전트 Research 시스템의 전체 워크플로우를 보여주는 프로세스 다이어그램입니다. 사용자가 쿼리를 제출하면 시스템은 LeadResearcher 에이전트를 만들고 이 에이전트는 반복적인 연구 프로세스에 들어갑니다. LeadResearcher는 접근 방식을 숙고하고 컨텍스트 유지를 위해 계획을 Memory에 저장하는 것으로 시작합니다. 컨텍스트 창이 200,000 토큰을 초과하면 잘리며 계획을 유지하는 것이 중요하기 때문입니다. 그런 다음 특정 연구 작업이 있는 전문화된 Subagent(여기서는 2개가 표시되지만 임의의 수일 수 있음)를 만듭니다. 각 Subagent는 독립적으로 웹 검색을 수행하고, 인터리빙된 사고를 사용하여 도구 결과를 평가한 다음 발견 사항을 LeadResearcher에 반환합니다. LeadResearcher는 이 결과를 종합하고 더 많은 연구가 필요한지 여부를 결정합니다. 필요한 경우 추가 서브에이전트를 만들거나 전략을 수정할 수 있습니다. 충분한 정보가 수집되면 시스템은 연구 루프를 종료하고 모든 발견 사항을 CitationAgent에 전달합니다. CitationAgent는 문서와 연구 보고서를 처리하여 인용의 구체적인 위치를 식별합니다. 이는 모든 주장이 출처에 올바르게 귀속되도록 보장합니다. 인용이 포함된 최종 연구 결과는 사용자에게 반환됩니다.
연구 에이전트를 위한 프롬프트 엔지니어링 및 평가
멀티 에이전트 시스템은 조정 복잡성의 급속한 증가를 포함하여 단일 에이전트 시스템과 핵심적인 차이가 있습니다. 초기 에이전트는 단순한 쿼리에 대해 50개의 서브에이전트를 생성하고, 존재하지 않는 출처를 위해 웹을 끝없이 긁으며, 과도한 업데이트로 서로를 방해하는 등의 오류를 범했습니다. 각 에이전트는 프롬프트에 의해 조정되므로, 프롬프트 엔지니어링은 이러한 동작을 개선하는 주요 수단이었습니다. 다음은 에이전트 프롬프트에 대해 학습한 몇 가지 원칙입니다:
- 에이전트처럼 생각하세요. 프롬프트를 반복하려면 효과를 이해해야 합니다. 이를 돕기 위해 우리는 Console을 사용하여 우리 시스템의 정확한 프롬프트와 도구로 시뮬레이션을 구축한 다음 에이전트가 단계별로 작동하는 것을 지켜보았습니다. 이는 즉시 실패 모드를 드러냈습니다. 이미 충분한 결과가 있는데도 계속 진행하는 에이전트, 지나치게 장황한 검색 쿼리를 사용하는 에이전트, 잘못된 도구를 선택하는 에이전트 등입니다. 효과적인 프롬프트는 에이전트의 정확한 정신적 모델을 개발하는 데 의존하며, 가장 영향력 있는 변화를 분명하게 만들 수 있습니다.
-
오케스트레이터에게 위임 방법을 가르치세요. 우리 시스템에서 리드 에이전트는 쿼리를 하위 작업으로 분해하고 이를 서브에이전트에 설명합니다. 각 서브에이전트는 목표, 출력 형식, 사용할 도구 및 출처에 대한 가이드, 그리고 명확한 작업 경계가 필요합니다. 상세한 작업 설명 없이 에이전트는 작업을 중복하고, 간격을 남기거나 필요한 정보를 찾지 못할 수 있습니다. 우리는 리드 에이전트가 ‘반도체 부족 조사’와 같은 간단하고 짧은 지시를 허용하는 것으로 시작했지만, 이러한 지시가 종종 모호하여 서브에이전트가 작업을 잘못 해석하거나 다른 에이전트와 정확히 동일한 검색을 수행한다는 것을 발견했습니다. 예를 들어, 한 서브에이전트는 2021년 자동차 칩 위기를 탐색한 반면, 다른 2개의 에이전트는 효과적인 분업 없이 현재 2025년 공급망을 조사하는 작업을 중복했습니다.
-
노력을 쿼리 복잡성에 맞게 조정하세요. 에이전트는 다양한 작업에 대한 적절한 노력을 판단하는 데 어려움을 겪으므로 우리는 프롬프트에 스케일링 규칙을 포함했습니다. 간단한 사실 확인은 3-10번의 도구 호출이 있는 1개의 에이전트만 필요하고, 직접 비교는 10-15번의 호출이 있는 2-4개의 서브에이전트가 필요할 수 있으며, 복잡한 연구는 명확하게 분할된 책임이 있는 10개 이상의 서브에이전트를 사용할 수 있습니다. 이러한 명시적인 가이드라인은 리드 에이전트가 리소스를 효율적으로 할당하고 단순한 쿼리에 과도하게 투자하는 것을 방지하는 데 도움이 되며, 이는 초기 버전의 일반적인 실패 모드였습니다.
-
도구 설계 및 선택이 중요합니다. 에이전트-도구 인터페이스는 인간-컴퓨터 인터페이스만큼 중요합니다. 올바른 도구를 사용하는 것이 효율적이며, 종종 엄격히 필요합니다. 예를 들어, Slack에만 존재하는 컨텍스트를 위해 웹을 검색하는 에이전트는 시작부터 실패할 운명입니다. 모델이 외부 도구에 액세스할 수 있는 MCP 서버를 사용하면 이 문제가 더욱 심각해지며, 에이전트는 품질이 천차만별인 설명이 있는 본 적 없는 도구를 접하게 됩니다. 우리는 에이전트에 명시적인 휴리스틱을 제공했습니다. 예를 들어, 사용 가능한 모든 도구를 먼저 검사하고, 도구 사용을 사용자 의도와 일치시키고, 광범위한 외부 탐색을 위해 웹을 검색하거나, 일반 도구보다 전문화된 도구를 선호하는 것 등입니다. 나쁜 도구 설명은 에이전트를 완전히 잘못된 경로로 보낼 수 있으므로 각 도구는 고유한 목적과 명확한 설명이 필요합니다.
-
에이전트가 스스로 개선하도록 하세요. 우리는 Claude 4 모델이 훌륭한 프롬프트 엔지니어가 될 수 있다는 것을 발견했습니다. 프롬프트와 실패 모드가 주어지면 에이전트가 실패하는 이유를 진단하고 개선 사항을 제안할 수 있습니다. 우리는 도구 테스트 에이전트를 만들기도 했습니다. 결함이 있는 MCP 도구가 주어지면 도구를 사용하려고 시도한 다음 실패를 피하기 위해 도구 설명을 다시 작성합니다. 도구를 수십 번 테스트함으로써 이 에이전트는 주요한 뉘앙스와 버그를 발견했습니다. 도구 인체 공학을 개선하는 이 프로세스는 새로운 설명을 사용하는 향후 에이전트의 작업 완료 시간이 40% 감소했습니다. 대부분의 실수를 피할 수 있었기 때문입니다.
-
넓게 시작한 다음 좁혀가세요. 검색 전략은 전문적인 인간 연구를 반영해야 합니다. 세부 사항을 파기 전에 지형을 탐색합니다. 에이전트는 종종 결과가 거의 없는 지나치게 길고 구체적인 쿼리를 기본으로 합니다. 우리는 에이전트에 짧고 광범위한 쿼리로 시작하도록 프롬프트하여 사용 가능한 것을 평가한 다음 점차 초점을 좁혀가도록 하여 이 경향을 방지했습니다.
-
사고 과정을 안내하세요. Claude가 보이는 사고 과정에서 추가 토큰을 출력하게 하는 확장된 사고 모드는 제어 가능한 스크래치패드 역할을 할 수 있습니다. 리드 에이전트는 사고를 사용하여 접근 방식을 계획하고, 작업에 적합한 도구를 평가하며, 쿼리 복잡성과 서브에이전트 수를 결정하고, 각 서브에이전트의 역할을 정의합니다. 우리의 테스트에 따르면 확장된 사고는 명령 따르기, 추론, 효율성을 향상시켰습니다. 서브에이전트도 계획한 다음 도구 결과 후에 인터리빙된 사고를 사용하여 품질을 평가하고, 간격을 식별하며, 다음 쿼리를 수정합니다. 이는 서브에이전트가 모든 작업에 적응하는 데 더 효과적입니다.
-
병렬 도구 호출이 속도와 성능을 변화시킵니다. 복잡한 연구 작업은 자연스럽게 많은 출처를 탐색하는 것을 포함합니다. 우리의 초기 에이전트는 순차적 검색을 실행했는데, 이는 참을 수 없을 정도로 느렸습니다. 속도를 위해 우리는 두 가지 유형의 병렬화를 도입했습니다. (1) 리드 에이전트는 직렬이 아닌 병렬로 3-5개의 서브에이전트를 생성합니다. (2) 서브에이전트는 병렬로 3개 이상의 도구를 사용합니다. 이러한 변경으로 인해 복잡한 쿼리의 연구 시간이 최대 90% 단축되었으며, 다른 시스템보다 더 많은 정보를 다루면서 연구를 몇 시간이 아닌 몇 분 안에 더 많은 작업을 수행할 수 있게 되었습니다.
우리의 프롬프팅 전략은 엄격한 규칙보다 좋은 휴리스틱을 심어주는 데 중점을 둡니다. 우리는 숙련된 인간이 연구 작업에 접근하는 방법을 연구하고 이러한 전략을 프롬프트에 인코딩했습니다. 어려운 질문을 더 작은 작업으로 분해하고, 출처의 품질을 신중하게 평가하며, 새로운 정보에 따라 검색 접근 방식을 조정하고, 깊이(한 주제를 상세히 조사)에 집중할 때와 너비(많은 주제를 병렬로 탐색)에 집중할 때를 인식하는 전략 등입니다. 우리는 또한 에이전트가 통제 불능 상태가 되는 것을 방지하기 위해 명시적인 가드레일을 설정하여 의도하지 않은 부작용을 사전에 완화했습니다. 마지막으로 우리는 관찰 가능성과 테스트 케이스가 있는 빠른 반복 루프에 중점을 두었습니다.
에이전트의 효과적인 평가
좋은 평가는 신뢰할 수 있는 AI 애플리케이션을 구축하는 데 필수적이며 에이전트도 예외가 아닙니다. 그러나 멀티 에이전트 시스템을 평가하는 것은 독특한 과제를 제시합니다. 전통적인 평가는 종종 AI가 매번 동일한 단계를 따른다고 가정합니다. 입력 X가 주어지면 시스템은 경로 Y를 따라 출력 Z를 생성해야 합니다. 하지만 멀티 에이전트 시스템은 이렇게 작동하지 않습니다. 동일한 시작점이 있어도 에이전트는 목표에 도달하기 위해 완전히 다른 유효한 경로를 취할 수 있습니다. 한 에이전트는 세 개의 출처를 검색할 수 있고 다른 에이전트는 10개를 검색할 수 있거나, 동일한 답을 찾기 위해 다른 도구를 사용할 수 있습니다. 항상 올바른 단계가 무엇인지 알지 못하므로 사전에 규정한 “올바른” 단계를 에이전트가 따랐는지 확인할 수 없습니다. 대신 에이전트가 적절한 프로세스를 따르면서 올바른 결과를 달성했는지 판단하는 유연한 평가 방법이 필요합니다.
작은 샘플로 즉시 평가를 시작하세요. 초기 에이전트 개발에서는 낮은 과일이 풍부하기 때문에 변경 사항이 큰 영향을 미치는 경향이 있습니다. 프롬프트 조정으로 성공률이 30%에서 80%로 높아질 수 있습니다. 이러한 효과 크기가 크면 몇 가지 테스트 케이스만으로도 변경 사항을 발견할 수 있습니다. 우리는 실제 사용 패턴을 나타내는 약 20개의 쿼리 세트로 시작했습니다. 이러한 쿼리를 테스트하면 종종 변경 사항의 영향을 명확하게 볼 수 있었습니다. 우리는 종종 AI 개발자 팀이 수백 개의 테스트 케이스가 있는 대규모 평가만 유용하다고 믿기 때문에 평가 생성을 지연한다고 듣습니다. 그러나 더 철저한 평가를 구축할 때까지 기다리는 대신 몇 가지 예로 소규모 테스트를 즉시 시작하는 것이 가장 좋습니다.
잘 수행하면 LLM-as-judge 평가가 확장됩니다. 연구 출력은 자유 형식 텍스트이고 거의 단일 올바른 답이 없으므로 프로그래밍 방식으로 평가하기 어렵습니다. LLM은 출력을 등급 매기기에 자연스러운 적합성을 가집니다. 우리는 루브릭의 기준에 대해 각 출력을 평가하는 LLM 판사를 사용했습니다. 사실적 정확성(주장이 출처와 일치하는가?), 인용 정확성(인용된 출처가 주장과 일치하는가?), 완전성(요청된 모든 측면이 포함되었는가?), 출처 품질(1차 출처를 더 낮은 품질의 2차 출처보다 사용했는가?), 도구 효율성(올바른 도구를 합리적인 횟수만큼 사용했는가?) 등입니다. 각 구성 요소를 평가하기 위해 여러 판사를 실험했지만, 0.0-1.0 점수와 합격-불합격 등급을 출력하는 단일 프롬프트가 있는 단일 LLM 호출이 가장 일관성이 있고 인간 판단과 일치한다는 것을 발견했습니다. 이 방법은 평가 테스트 케이스가 명확한 답이 있는 경우 특히 효과적이었으며, LLM 판사를 사용하여 단순히 답이 올바른지 확인할 수 있었습니다(예: 상위 3개의 가장 큰 R&D 예산이 있는 제약 회사를 정확하게 나열했는가?). LLM을 판사로 사용하면 수백 개의 출력을 확장 가능하게 평가할 수 있었습니다.
인간 평가는 자동화가 놓치는 것을 포착합니다. 에이전트를 테스트하는 사람들은 평가가 놓치는 엣지 케이스를 발견합니다. 여기에는 드문 쿼리에 대한 환각 답변, 시스템 실패, 미묘한 출처 선택 편향 등이 포함됩니다. 우리의 경우 인간 테스터는 초기 에이전트가 학술 PDF나 개인 블로그와 같은 권위 있지만 순위가 낮은 출처보다 SEO 최적화된 콘텐츠 팜을 일관되게 선택한다는 것을 발견했습니다. 프롬프트에 출처 품질 휴리스틱을 추가하면 이 문제가 해결되었습니다. 자동화된 평가의 세계에서도 수동 테스트는 여전히 필수적입니다.
멀티 에이전트 시스템은 특정 프로그래밍 없이 발생하는 emergent 동작을 가집니다. 예를 들어, 리드 에이전트에 대한 작은 변경이 서브에이전트가 작동하는 방식을 예측할 수 없게 변경할 수 있습니다. 성공에는 개별 에이전트 동작뿐만 아니라 상호 작용 패턴에 대한 이해가 필요합니다. 따라서 이러한 에이전트에 대한 가장 좋은 프롬프트는 엄격한 지시가 아니라 노동 분할, 문제 해결 접근 방식 및 노력 예산을 정의하는 협력 프레임워크입니다. 이를 올바르게 수행하려면 신중한 프롬프트 및 도구 설계, 견고한 휴리스틱, 관찰 가능성, 그리고 긴밀한 피드백 루프가 필요합니다. 우리 시스템의 예시 프롬프트는 Cookbook의 오픈 소스 프롬프트를 참조하세요.
프로덕션 신뢰성 및 엔지니어링 과제
전통적인 소프트웨어에서 버그는 기능을 깨거나 성능을 저하시키거나 중단을 일으킬 수 있습니다. 에이전트 시스템에서는 사소한 변경이 큰 동작 변경으로 연쇄되어 장기 실행 프로세스에서 상태를 유지해야 하는 복잡한 에이전트에 대한 코드를 작성하는 것이 매우 어렵습니다.
에이전트는 상태를 유지하고 오류가 누적됩니다. 에이전트는 오랜 기간 동안 실행할 수 있으며 여러 도구 호출에 걸쳐 상태를 유지합니다. 이는 오류를 처리하면서 코드를 내구성 있게 실행해야 함을 의미합니다. 효과적인 완화 조치 없이 사소한 시스템 실패는 에이전트에게 재앙이 될 수 있습니다. 오류가 발생하면 처음부터 다시 시작할 수 없습니다. 다시 시작하는 것은 비용이 많이 들고 사용자에게 좌절감을 줍니다. 대신 우리는 에이전트가 오류가 발생했을 때 그곳에서 다시 시작할 수 있는 시스템을 구축했습니다. 우리는 또한 모델의 지능을 사용하여 문제를 우아하게 처리합니다. 예를 들어, 도구가 실패하고 있을 때 에이전트에게 알리고 적응하도록 하는 것은 놀랍도록 잘 작동합니다. 우리는 Claude에 구축된 AI 에이전트의 적응성을 재시도 논리와 정기적 체크포인트와 같은 결정론적 안전장치와 결합합니다.
디버깅은 새로운 접근 방식의 혜택을 받습니다. 에이전트는 동적 결정을 내리며 동일한 프롬프트라도 실행 간에 비결정적입니다. 이는 디버깅을 더 어렵게 만듭니다. 예를 들어, 사용자는 에이전트가 “명백한 정보를 찾지 못한다”고 보고했지만 우리는 이유를 볼 수 없었습니다. 에이전트가 나쁜 검색 쿼리를 사용했나요? 나쁜 출처를 선택했나요? 도구 실패에 직면했나요? 전체 프로덕션 추적을 추가하여 에이전트가 실패한 이유를 진단하고 문제를 체계적으로 수정할 수 있었습니다. 표준 관찰 가능성을 넘어 개별 대화 내용을 모니터링하지 않고 사용자 프라이버시를 유지하면서 에이전트 결정 패턴과 상호 작용 구조를 모니터링합니다. 이러한 높은 수준의 관찰 가능성은 근본 원인을 진단하고 예기치 않은 동작을 발견하며 일반적인 실패를 수정하는 데 도움이 되었습니다.
배포에는 신중한 조정이 필요합니다. 에이전트 시스템은 거의 연속적으로 실행되는 프롬프트, 도구 및 실행 논리의 고도로 상태 유지형 웹입니다. 이는 업데이트를 배포할 때마다 에이전트가 프로세스의 어느 단계에나 있을 수 있음을 의미합니다. 따라서 우리의 의도적인 코드 변경이 기존 에이전트를 깨지 않도록 방지해야 합니다. 모든 에이전트를 동시에 새 버전으로 업데이트할 수 없습니다. 대신 우리는 무지개 배포(rainbow deployments)를 사용하여 실행 중인 에이전트를 중단하지 않습니다. 두 버전을 동시에 실행하면서 트래픽을 이전 버전에서 새 버전으로 점진적으로 이동합니다.
동기식 실행은 병목 현상을 만듭니다. 현재 우리의 리드 에이전트는 서브에이전트를 동기식으로 실행하며, 각 서브에이전트 세트가 완료될 때까지 기다렸다가 진행합니다. 이는 조정을 단순화하지만 에이전트 간의 정보 흐름에 병목 현상을 만듭니다. 예를 들어, 리드 에이전트는 서브에이전트를 조정할 수 없고, 서브에이전트는 조정할 수 없으며, 전체 시스템은 단일 서브에이전트가 검색을 완료할 때까지 차단될 수 있습니다. 비동기 실행은 추가 병렬화를 가능하게 합니다. 에이전트가 동시에 작동하고 필요할 때 새 서브에이전트를 생성합니다. 하지만 이러한 비동기성은 서브에이전트 간의 결과 조정, 상태 일관성 및 오류 전파에 과제를 추가합니다. 모델이 더 길고 복잡한 연구 작업을 처리할 수 있게 됨에 따라 성능 향상이 복잡성을 정당화할 것으로 기대합니다.
결론
AI 에이전트를 구축할 때 마일리지는 종종 대부분의 여정이 됩니다. 개발자 머신에서 작동하는 코드베이스는 신뢰할 수 있는 프로덕션 시스템이 되기 위해 상당한 엔지니어링이 필요합니다. 에이전트 시스템에서 오류의 복합적 특성은 전통적인 소프트웨어의 사소한 문제가 에이전트를 완전히 벗어나게 할 수 있음을 의미합니다. 한 단계가 실패하면 에이전트가 완전히 다른 궤적을 탐색하게 되어 예측할 수 없는 결과로 이어질 수 있습니다. 이 게시물에 설명된 모든 이유로 인해 프로토타입과 프로덕션 사이의 격차는 종종 예상보다 넓습니다.
이러한 과제에도 불구하고 멀티 에이전트 시스템은 개방형 연구 작업에 가치가 있는 것으로 입증되었습니다. 사용자들은 Claude가 고려하지 않았던 비즈니스 기회를 찾고, 복잡한 의료 옵션을 탐색하고, 까다로운 기술적 버그를 해결하고, 혼자서는 찾지 못했을 연결을 발견하여 최대 며칠의 작업을 절약하는 데 도움을 주었다고 말했습니다. 멀티 에이전트 연구 시스템은 신중한 엔지니어링, 포괄적인 테스트, 세부적인 프롬프트 및 도구 설계, 견고한 운영 관행, 그리고 현재 에이전트 기능을 강하게 이해하는 연구, 제품 및 엔지니어링 팀 간의 긴밀한 협력을 통해 규모에서 안정적으로 작동할 수 있습니다. 우리는 이미 이러한 시스템이 사람들이 복잡한 문제를 해결하는 방식을 변화시키는 것을 보고 있습니다.
사람들이 오늘 Research 기능을 사용하는 가장 일반적인 방법을 보여주는 Clio 임베딩 플롯입니다. 상위 사용 사례 카테고리는 전문 도메인에 걸친 소프트웨어 시스템 개발(10%), 전문 및 기술 콘텐츠 개발 및 최적화(8%), 비즈니스 성장 및 수익 창출 전략 개발(8%), 학술 연구 및 교육 자료 개발 지원(7%), 그리고 사람, 장소 또는 조직에 대한 정보 연구 및 확인(5%)입니다.
감사의 말
Jeremy Hadfield, Barry Zhang, Kenneth Lien, Florian Scholz, Jeremy Fox, Daniel Ford가 작성했습니다. 이 작업은 Research 기능을 가능하게 한 Anthropic의 여러 팀의 집단적 노력을 반영합니다. Anthropic 앱 엔지니어링 팀에게 특별히 감사드리며, 그들의 헌신이 이 복잡한 멀티 에이전트 시스템을 프로덕션으로 가져왔습니다. 또한 훌륭한 피드백을 주신 초기 사용자들에게도 감사드립니다.
부록
멀티 에이전트 시스템에 대한 몇 가지 추가 팁입니다.
여러 턴에 걸쳐 상태를 변경하는 에이전트의 최종 상태 평가. 다중 턴 대화에서 지속적인 상태를 수정하는 에이전트를 평가하는 것은 독특한 과제를 제시합니다. 읽기 전용 연구 작업과 달리 각 작업은 후속 단계에 대한 환경을 변경할 수 있으며, 이는 전통적인 평가 방법이 처리하기 어려운 종속성을 만듭니다. 우리는 턴별 분석보다 최종 상태 평가에 중점을 두어 성공을 거두었습니다. 에이전트가 특정 프로세스를 따랐는지 판단하는 대신 올바른 최종 상태를 달성했는지 평가합니다. 이 접근 방식은 에이전트가 동일한 목표에 대한 대체 경로를 찾을 수 있음을 인정하면서 의도한 결과를 전달하도록 보장합니다. 복잡한 워크플로우의 경우 모든 중간 단계를 검증하려고 시도하는 대신 특정 상태 변경이 발생해야 하는 개별 체크포인트로 평가를 분할합니다.
장기 대화 관리. 프로덕션 에이전트는 수백 턴에 걸친 대화에 참여하며 신중한 컨텍스트 관리 전략이 필요합니다. 대화가 확장되면 표준 컨텍스트 창이 불충분해지므로 지능적인 압축 및 메모리 메커니즘이 필요합니다. 우리는 에이전트가 완료된 작업 단계를 요약하고 새 작업으로 진행하기 전에 필수 정보를 외부 메모리에 저장하는 패턴을 구현했습니다. 컨텍스트 한도에 접근하면 에이전트는 깨끗한 컨텍스트가 있는 새로운 서브에이전트를 생성하면서 신중한 인수톤을 통해 연속성을 유지할 수 있습니다. 또한 컨텍스트 한도에 도달할 때 이전 작업을 잃는 대신 연구 계획과 같은 저장된 컨텍스트를 메모리에서 검색할 수 있습니다. 이러한 분산 접근 방식은 확장된 상호 작용에서 대화의 일관성을 유지하면서 컨텍스트 오버플로우를 방지합니다.
‘전화 게임’을 최소화하기 위한 파일 시스템에 대한 서브에이전트 출력. 직접 서브에이전트 출력은 특정 유형의 결과에 대해 메인 조정자를 우회할 수 있으며, 이는 충실도와 성능 모두를 향상시킵니다. 서브에이전트가 모든 것을 리드 에이전트를 통해 통신하도록 요구하는 대신 전문화된 에이전트가 독립적으로 지속되는 출력을 만들 수 있는 아티팩트 시스템을 구현합니다. 서브에이전트는 도구를 호출하여 작업을 외부 시스템에 저장한 다음 가벼운 참조를 조정자에게 다시 전달합니다. 이는 다단계 처리 중에 정보 손실을 방지하고 대화 기록을 통해 큰 출력을 복사하는 것에서 오는 토큰 오버헤드를 줄입니다. 이 패턴은 일반 조정자를 통해 필터링하는 것보다 서브에이전트의 전문화된 프롬프트가 더 나은 결과를 생성하는 코드, 보고서 또는 데이터 시각화와 같은 구조화된 출력에 특히 잘 작동합니다.
핵심 포인트
- 멀티 에이전트 시스템은 리드 에이전트가 연구 계획을 세우고 전문화된 서브에이전트들이 병렬로 정보를 검색하여 연구를 수행하며, 단일 에이전트 시스템보다 90.2% 더 우수한 성능을 보임
- 토큰 사용량이 많아 채팅보다 약 15배 더 많은 토큰을 소비하지만, 복잡한 연구 작업과 너비 우선 쿼리에 특히 효과적
- 프롬프트 엔지니어링, 도구 설계, 포괄적인 평가, 신중한 배포 전략이 프로덕션 환경에서의 신뢰성 있는 운영의 핵심
- LLM-as-judge 평가, 인간 평가, 작은 샘플로의 빠른 시작이 멀티 에이전트 시스템 평가의 효과적인 접근 방식
- 동기식 실행은 병목 현상을 만들지만, 비동기 실행은 추가 병렬화를 가능하게 하면서 새로운 과제도 도입
출처: How we built our multi-agent research system \ Anthropic
