Microsoft Agent Framework에서 도구로서의 에이전트 (Agents as Tools)

이 글은 Microsoft Agent Framework에 관한 제 시리즈의 11번째 파트입니다. 원문 게시물은 lukaswalter.dev에서 읽으실 수 있습니다.

이전 기사에서는 수동 멀티 에이전트 라우팅 (manual multi-agent routing)을 살펴보았습니다.
작은 의도 에이전트 (intent agent)가 요청을 분류했습니다.
그 후 일반적인 C# 코드가 어떤 전문 에이전트 (specialist agent)를 실행할지 결정했습니다.

이 패턴은 애플리케이션이 라우팅에 대한 제어권을 유지해야 할 때 유용합니다.
하지만 알아둘 가치가 있는 또 다른 패턴이 있습니다. 바로 에이전트를 도구 (tool)로 노출하는 것입니다.

C#에서 라우팅하는 대신, 코디네이터 에이전트 (coordinator agent)에게 다른 에이전트들을 함수 도구 (function tools)로서 접근할 수 있는 권한을 부여합니다.
그러면 코디네이터는 언제 집중된 내부 에이전트 (inner agent)에게 작업을 위임할지 결정할 수 있습니다.

이것이 마법처럼 비용을 줄여주는 방법은 아닙니다.
워크플로 (workflows)를 대체하는 것도 아닙니다.
이는 하나의 에이전트가 너무 광범위해졌지만, 전체 워크플로 그래프 (workflow graph)를 구축하기에는 너무 과한 경우를 위한 경량화된 구성 패턴 (composition pattern)입니다.

도구가 너무 많은 단일 에이전트의 문제점

먼저 왜 도구가 너무 많은 단일 에이전트가 문제가 되는지 논의해 보겠습니다.
에이전트에 도구를 추가하는 것은 쉽습니다.
에이전트가 너무 빠르게 비대해지는 이유도 바로 이 때문입니다.

첫 번째 버전은 질문에 답하기만 할 수도 있습니다.
그다음에는 몇 가지 문자열 유틸리티 (string utilities)가 추가됩니다.
그다음에는 몇 가지 숫자 도구 (number tools)가 추가됩니다.
그다음에는 문서 검색 도구 (documentation search tool)가 추가됩니다.
그다음에는 티켓팅 도구 (ticketing tool)가 추가됩니다.
그다음에는 배포 도우미 (deployment helper)가 추가됩니다.

어느 시점에 이르면, 모든 요청이 너무 많은 짐을 지게 됩니다.
모델은 다음과 같은 것들을 받게 됩니다:

• 광범위한 지침 (broad instructions)
• 많은 도구 이름 또는 작은 에이전트들
• 많은 도구 설명 (tool descriptions)
• 필요하지 않은 도구에 대한 파라미터 스키마 (parameter schemas)
• 현재 요청과 무관한 도메인에 대한 규칙들

이는 우리가 수동 라우팅에서 보았던 것과 동일한 문제를 일으킵니다.
에이전트는 처리해야 할 컨텍스트 (context)가 더 많아지고, 선택할 수 있는 도구가 더 많아지며, 잘못된 동작을 선택할 수 있는 방법도 더 많아집니다.

작은 에이전트들에게는 이 문제가 그리 중요하지 않습니다.
하지만 상세한 도구가 많은 에이전트의 경우, 도구 정의 (tool definitions)가 모델 컨텍스트의 일부이기 때문에 오버헤드 (overhead)가 빠르게 눈에 띄게 됩니다.

도구로서의 에이전트 (Agents as Tools)

Agent Framework를 사용하면 AsAIFunction()을 사용하여 AIAgent를 함수 도구 (function tool)로 변환할 수 있습니다.
그 도구는 이후 다른 에이전트에게 전달될 수 있습니다.

이는 당신이 함수 도구를 지원하는 에이전트 유형을 사용하고 있음을 전제로 합니다.
실제 적용 시에는 이 패턴을 설계하기 전에 에이전트와 제공자 (provider)의 지원 여부를 확인하십시오.

외부 에이전트는 내부 에이전트를 다른 일반적인 도구와 동일하게 인식합니다.
내부 에이전트는 여전히 자신만의 지침 (instructions), 도구 (tools), 모델 호출 (model calls) 및 동작 (behavior)을 가집니다.

개념적으로 흐름은 다음과 같습니다:

중요한 부분은 격리 (isolation)입니다.
코디네이터 (coordinator)는 모든 전문가 에이전트 (specialist agent) 뒤에 있는 모든 저수준 도구 (low-level tool)를 알 필요가 없습니다.
코디네이터는 어떤 전문가 에이전트가 사용 가능한지, 그리고 각 에이전트가 무엇을 잘하는지만 알면 됩니다.

작은 예시

두 가지 전문 분야를 가진 간단한 어시스턴트를 상상해 보세요:

• 문자열 변환 (string transformations)
• 수치 계산 (numeric calculations)

모든 도구를 하나의 에이전트에 담을 수도 있습니다.
작은 데모라면 괜찮습니다.
하지만 각 전문가가 자신만의 도구를 소유할 때 구조가 더 명확해집니다.

using System.ComponentModel;
using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;
...

이제 내부 에이전트들을 생성합니다.

AIAgent stringAgent = chatClient.AsAIAgent(
    name: "string-agent",
    description: "Handles string transformations such as uppercase and reverse text.",
...

name과 description은 매우 중요합니다. 에이전트가 도구로 노출되면 이 정보들이 코디네이터 모델의 라우팅 표면 (routing surface)의 일부가 되기 때문입니다.
모호한 설명은 코디네이터에게 적절한 전문가를 신뢰성 있게 선택할 수 있는 정보를 너무 적게 제공하게 됩니다.

이제 해당 에이전트들을 코디네이터에게 도구로서 노출합니다.

AIAgent coordinatorAgent = chatClient.AsAIAgent(
    name: "coordinator-agent",
    instructions: """
...

코디네이터는 두 가지 도구 옵션을 받습니다:

• 문자열 에이전트 호출 (Call the string agent)
• 숫자 에이전트 호출 (Call the number agent)

ToUppercase, ReverseText, Multiply에 대한 원시 스키마 (raw schemas)를 직접적인 도구 (tools)로 받지 않습니다.
해당 스키마들은 전문 에이전트 (specialist agents)에 속해 있습니다.

실제로 토큰을 절약하는 방법

토큰 절약의 이점은 가시적인 도구 표면 (tool surface)을 좁히는 데서 옵니다.

위임 (delegation)이 없다면, 하나의 거대한 에이전트가 해당 에이전트를 호출할 때마다 모든 도구 스키마를 받게 됩니다:

에이전트를 도구로 사용하면, 코디네이터 (coordinator)는 더 작고 상위 수준인 도구 세트만 보게 됩니다:

이를 통해 코디네이터 호출에 필요한 입력 토큰 (input tokens)을 줄일 수 있습니다.
하지만 위임은 추가적인 에이전트 호출 (agent invocations)을 발생시키기도 합니다.

코디네이터가 하나의 내부 에이전트를 호출한다면, 코디네이터 호출 비용과 내부 에이전트 호출 비용을 모두 지불해야 합니다.
만약 세 개의 내부 에이전트를 호출한다면, 그 모든 비용을 지불해야 합니다.

이 패턴은 다음과 같은 경우에 효과적입니다:

• 대부분의 요청이 단 하나의 전문 영역만 필요할 때
• 내부 에이전트들이 항상 노출될 필요가 없는 많은 도구를 가지고 있을 때
• 코디네이터가 전문 에이전트들보다 더 작은 모델을 사용할 수 있을 때
• 전문 에이전트들이 집중력을 유지하며 짧게 유지될 수 있을 때

반면, 다음과 같은 경우에는 효과적이지 않을 수 있습니다:

• 모든 요청이 어차피 대부분의 내부 에이전트를 필요로 할 때
• 도구 목록이 이미 작을 때
• 코디네이터가 무엇을 할지 결정하기 위해서만 긴 컨텍스트 (context)가 필요할 때
• 토큰 비용보다 지연 시간 (latency)이 더 중요할 때

사용자의 프롬프트 (prompts), 도구 (tools), 모델 (models), 그리고 트래픽 형태 (traffic shape)를 바탕으로 직접 측정해 보십시오.

위임은 모델 주도적 (Model-Driven)입니다

이것이 이전 글과의 주요 차이점입니다.

수동 라우팅 (manual routing)에서는 애플리케이션이 결정합니다:

에이전트를 도구로 사용하는 경우에는 코디네이터 모델이 결정합니다:

이는 도구로서의 에이전트 (Agents as tools)를 더욱 유연하게 만듭니다.
코디네이터 (Coordinator)는 한 명의 전문가, 여러 명의 전문가, 또는 아무도 호출하지 않을지를 결정할 수 있습니다.
또한 사용자에게 답변하기 전에 결과들을 결합할 수도 있습니다.

하지만 이는 C#의 switch 문만큼 명시적이지는 않습니다.
모델이 유용한 전문가를 건너뛸 수도 있습니다.
잘못된 전문가를 호출할 수도 있습니다.
직접적인 답변으로 충분했을 상황임에도 권한을 위임 (Delegate)할 수도 있습니다.

좋은 에이전트 설명 (Agent descriptions)이 도움이 되긴 하지만, 위임 (Delegation)을 결정론적 (Deterministic)으로 만들어주지는 않습니다.

애플리케이션 소유의 예측 가능한 제어가 필요할 때는 수동 라우팅 (Manual routing)을 사용하세요.
코디네이터가 위임 (Delegation)이 유용한지 여부를 추론 (Reason)해야 할 때는 에이전트를 도구로서 사용하세요.

컨텍스트는 자동으로 전달되지 않습니다

내부 에이전트 (Inner agent)는 단순히 외부 에이전트 (Outer agent)의 연속이 아닙니다.
그것은 도구 호출 (Tool call)로서 실행됩니다.
이는 내부 에이전트가 자신만의 다음 요소들을 가진다는 것을 의미합니다:

• 지침 (Instructions)
• 도구 (Tools)
• 모델 호출 (Model invocation)
• 컨텍스트 제공자 (Context providers)
• 세션 동작 (Session behavior)

내부 에이전트는 외부의 전체 대화 기록이나 모든 외부 컨텍스트 조각을 자동으로 상속받지 않습니다.
코디네이터는 도구 호출 (Tool call)을 통해 관련 작업 정보 (Task information)를 전달해야 합니다.

AsAIFunction()에 공유된 AgentSession을 전달하는 경우, 주의해서 다루어야 합니다.
결과로 생성된 함수는 상태 유지 (Stateful) 방식이므로, 여러 대화에서 이를 동시에 재사용하면 예측 불가능한 동작이 발생할 수 있습니다.

이는 좋은 경계 (Boundary)가 되지만, 예상치 못한 상황을 만들 수도 있습니다. 이전 예제에 나왔던 커피 에이전트를 생각해 봅시다.

예를 들어, 사용자가 5턴 전에 선호하는 커피 비율을 말했다 하더라도, 코디네이터가 이를 전달하거나 내부 에이전트가 자체적인 메모리/컨텍스트 설정을 통해 로드할 수 없다면 내부 커피 에이전트는 그 사실을 모를 수 있습니다.

따라서 실질적인 규칙은 다음과 같습니다:

공유된 컨텍스트 (Shared context)를 가정하지 마세요.
필요한 작업 컨텍스트 (Task context)를 의도적으로 전달하거나, 내부 에이전트에게 자체적인 컨텍스트 제공자 (Context provider)를 부여하세요.

내부 에이전트의 집중도를 유지하세요

이 패턴의 핵심은 다른 에이전트 내부에 복잡성을 숨기는 것이 아닙니다.
핵심은 더 작고 명확한 기능 경계 (Capability boundary)를 만드는 것입니다.

유용한 내부 에이전트는 다음과 같은 특성을 가져야 합니다:

• 좁은 책임 범위
• 명확한 이름
• 구체적인 설명
• 필요한 도구 (Tools)만 보유
• 짧은 지침 (Instructions)
• 예측 가능한 출력 기대치

만약 내부 에이전트가 또 다른 범용 어시스턴트 (General-purpose assistant)가 된다면, 당신은 문제를 단지 한 단계 아래로 옮겼을 뿐입니다.

예를 들어, string-agent는 유용한 경계입니다.
이 에이전트는 문자열을 변환합니다.
문자열 관련 도구들을 가지고 있습니다.
문서 검색, 티켓 생성, 또는 배포 권한은 필요하지 않습니다.

명심하세요:

operations-agent-that-can-do-everything은 유용한 경계가 아닙니다.
그것은 단지 이름만 바뀐, 기존의 과부하된 에이전트일 뿐입니다.

부작용 (Side Effects)을 주의하세요

에이전트 도구는 하나의 코디네이터 가시적 호출 (Coordinator-visible call) 뒤에 여러 개의 하위 수준 도구 호출 (Lower-level tool calls)을 숨길 수 있습니다.
이는 구성 (Composition) 측면에서 유용합니다.
동시에 관찰 가능성 (Observability)이 필요하다는 것을 의미하기도 합니다.

외부 에이전트는 내부 에이전트의 결과를 받습니다.
이것이 당신의 유일한 감사 표면 (Audit surface)이 되어서는 안 됩니다.
만약 내부 에이전트가 도구를 호출할 수 있다면, 해당 도구 호출이 발생하는 지점에서 로그를 남기세요.
다음 사항들을 검사할 수 있도록 트레이싱 (Tracing) 또는 미들웨어 (Middleware)를 사용하세요:

• 어떤 내부 에이전트가 호출되었는지
• 어떤 입력을 받았는지
• 어떤 도구들을 호출했는지
• 승인이 필요했는지 여부
• 어떤 결과를 반환했는지
• 각 단계가 얼마나 걸렸는지

참고: 관찰 가능성에 대해서는 이후 포스트에서 자세히 다루겠지만, 지금은 Aspire Dashboard에 멀티 에이전트 설정을 디버깅할 때 정말 유용한 GenAI 시각화 도구가 포함되어 있다는 점을 언급하고 싶습니다. 배경 지식은 OpenTelemetry 기사인 GenAI observability with OpenTelemetry and Aspire Dashboard를 참조하세요.

로컬 도구에서 사용했던 것과 동일한 안전 규칙이 여전히 적용됩니다:

내부 에이전트 (inner agent)가 비용을 지출하거나, 데이터를 변경하거나, 메시지를 보내거나, 배포 (deployments)를 트리거할 수 있는 경우, 코디네이터 프롬프트 (coordinator prompt)를 안전 경계 (safety boundary)로 신뢰하지 마십시오.
실제 동작을 수행하는 도구 (tool) 뒤에 승인 (approval), 권한 부여 (authorization), 검증 (validation) 및 로깅 (logging)을 배치하십시오.

내부 에이전트는 구성 경계 (composition boundary)입니다.
그 자체로 보안 경계 (security boundary)는 아닙니다.

에이전트를 도구로 사용하기 (Agents as Tools) vs. 워크플로 (Workflows)

에이전트를 도구로 사용하는 것은 가벼운 위임 (delegation)에 유용합니다.
이는 워크플로 (workflows)와 동일하지 않습니다.

코디네이터 (coordinator)가 무엇을 호출할지 결정할 수 있고, 작업이 일반적인 도구 호출 (tool-calling) 흐름 내에서 완료될 수 있을 때는 에이전트를 도구로 사용하십시오.

오케스트레이션 (orchestration) 자체가 명시적이어야 할 때는 워크플로를 사용하십시오.
예를 들어:

• 고정된 실행 순서 (fixed execution order)
• 체크포인트 (checkpoints)
• 재개 가능성 (resumability)
• 단계 사이의 인간의 승인 (human approval)
• 단계 간의 타입이 지정된 엣지 (typed edges)
• 장기 실행 프로세스 (long-running processes)
• 더 명확한 운영 가시성 (operational visibility)

코디네이터 에이전트는 다음 작업에 충분할 수 있습니다:

1. 사용자 요청 읽기.
2. 적절한 전문가 (specialist) 호출.
3. 결과 결합.
4. 답변.

프로세스 자체가 제품인 경우에는 워크플로가 더 적합합니다.
예를 들어, 지원 사례 분류 (triage), 복구 계획 (remediation plan) 생성, 승인 요청, 변경 사항 실행, 그리고 결과 저장과 같은 과정입니다.

에이전트를 도구로 사용해야 하는 경우

다음과 같은 경우에 에이전트를 도구로 사용하십시오:

• 하나의 에이전트가 너무 많은 관련 없는 도구들을 축적하고 있을 때
• 전문가 에이전트 (specialist agents)가 명확한 도메인 (domains)을 소유할 수 있을 때
• 코디네이터가 위임 (delegation)이 필요한지 여부를 결정해야 할 때
• 서로 다른 전문가들이 서로 다른 도구, 프롬프트 또는 모델을 사용해야 할 때
• 내부 작업이 도구 호출 (tool call)과 최종 결과로 표현될 수 있을 때
• 위임 경로 (delegation path)를 관찰하고 테스트할 수 있을 때

다음과 같은 경우에는 에이전트를 도구로 사용하지 마십시오: