도구 및 MCP

도구만 호출하는 에이전트는 작업을 당신에게 떠넘깁니다. 이 페이지에서는 플랫폼이 에이전트가 작동하도록 하는 방법을 다룹니다: 툴이 호출될 때 턴(turn) 내에서 어떤 일이 일어나는지, 그로 인해 대화가 파괴되는 것을 어떻게 방지하는지, 그리고 귀하의 시스템이 어떻게 연결되는지입니다.

도구 루프

턴은 단일 모델 호출이 아닙니다. 모델은 답변할 수도 있고, 도구 호출을 요청할 수도 있습니다. 모델이 도구를 호출하면 그 결과가 대화에 추가되고, 모델은 해당 결과를 가지고 다시 실행됩니다. 그런 다음 다른 도구를 호출할 수도 있습니다. 루프는 모델이 답변을 생성하거나 반복 횟수 제한에 도달할 때까지 계속됩니다.

이 제한이 중요한 이유는, 도구를 계속 호출하는 모델(매우 흔한 실패 사례)이 무한히 실행되어 토큰을 소모하고 고객이 답신을 기다리도록 방치할 수 있기 때문입니다.

루프가 수행하지 않는 작업은 축적된 모든 내용을 바탕으로 고객의 답변을 작성하는 것입니다. 도구 호출이 완료되면 요청이 깨끗하게 재구성됩니다 — 에이전트의 지시사항, 짧은 요약, 이 턴에서 발견된 사실, 그리고 질문 — 그리고 그로부터 답변이 생성됩니다. 그 이유는 신중하며, 이는 Why agents get worse as context grows에서 다루는 주제입니다.

모델 실행 전 도구 선택 결정

위에서 설명한 루프는 모델이 올바른 도구를 요청한다고 가정합니다. 종종 그렇지 않으며, 그 이유는 정확히 이해할 가치가 있습니다. 이는 지식 문제가 아니기 때문입니다.

사람들은 소프트웨어가 원하는 방식으로 요청을 표현하지 않습니다. *"그와 비슷한 다른 것들이 있나요?"*는 도구, 주제, 수량을 명시하지 않습니다. 그것들은 두 메시지 전에 언급되었습니다. 그런 내용을 받은 모델은 "그와 비슷한" 것이 무엇을 지칭하는지 해석하고, 도구 호출이 필요한지 결정하며, 어떤 도구인지 파악하고, 인수를 채우고, 좋은 답변을 작성해야 합니다. 이는 하나의 샘플에서 다섯 가지 작업을 수행하는 것입니다. 보통 도구가 호출하는 작업이 생략되며, 고객은 제품 목록이 있어야 할 곳에 문단 하나를 받게 됩니다.

이것은 여러 유형의 요청을 포괄합니다. "그와 비슷한 다른 것들이 있나요?"는 항목을 표시하는 것을 원하며, "읽기 수준별 도서 분포를 보여주세요"는 카탈로그를 집계하고 차트로 그리는 것을 원합니다. 두 번째 요청에 스스로 맡기면, 모델은 작업을 수행하는 대신 그 과정을 서술할 것입니다. — 우리는 하나가 "데이터베이스를 쿼리해 보겠습니다"라고 말한 후 6번 반복하고, SQL 문을 답변으로 출력하는 것을 목격했습니다. 이는 도구의 입력값이며 독자가 볼 내용이 아닙니다.

따라서 도구가 명확히 암시된 요청의 경우, 플랫폼이 먼저 한 단계를 수행합니다. 작고 저렴한 호출 하나를 통해 대화를 읽고 사실만 반환합니다 — 무엇을 요청하는지, 그리고 그 수를요. 이는 대화만 보며, 에이전트의 지시사항이나 검색된 자료는 보지 않으므로 답변으로 흐르지 않습니다. 그런 다음:

• 플랫폼이 지시사항을 작성합니다. 실제로 도구가 응답하는 문구로, 누락된 맥락을 다시 채워 넣습니다.
• 해당 턴에는 하나의 도구만 표시됩니다. 따라서 선택할 대상이 없습니다.

그중 첫 번째가 중요하며, 잘못하기 쉽습니다. 모델이 자신의 요청을 다시 작성하게 하는 것은 측정 가능한 변화를 가져오지 못했습니다 — 다른 단어로 같은 추측일 뿐이었습니다. 플랫폼이 도구의 자체 정의를 바탕으로 해당 문장을 구성하는 것은, 자체 호스팅 35B 모델의 동일한 요청에 대한 성능을 **16%에서 70%**로 끌어올렸습니다. 도구에 전달되는 문구는 소프트웨어가 계산할 수 있는 것이므로, 소프트웨어가 계산합니다 — 차트 데이터와 카드 내용을 모델의 손이 아닌 서버에 유지하는 것과 같은 추론입니다.

플랫폼이 의도적으로 수행하지 않는 세 번째 작업도 있습니다: 프로토콜 수준에서 호출을 강제하는 것입니다. 해당 옵션은 존재하며, 호출 수를 더 높입니다. 그러나 이를 디코딩 제약으로 구현한 자체 호스팅 서버에서는 모델을 반복 루프에 빠뜨립니다 — 우리가 측정한 바에 따르면 약 4번 중 1번의 턴에서 발생하며, 그중 하나는 동일한 조각을 2분 동안 출력하는 데 소비했습니다. 도착하지 않는 답변은 문단으로 답변하는 것보다 더 나쁩니다.

알아둘 가치가 있는 두 가지 결과가 있습니다. composed instruction이 영어로 작성되더라도 답변은 여전히 고객의 언어로 돌아옵니다 — 이것도 플랫폼이 고정하며, 모델이 알아차리도록 맡기지 않습니다. 또한 턴이 무언가를 전달해야 하는데 대신 문단을 전달한 경우, 플랫폼이 이를 감지하고 한 번 더 요청합니다. 건너뛴 단계를 명시하고 정직한 탈출구를 제시합니다("어떤 자료도 적합하지 않으면 그렇게 말하라") — 제한된 모델이 탈출구 없이 강요당하면 하나를 만들어내기 때문입니다. 여덟 가지 제품을 설명하지만 아무것도 표시하지 않는 에이전트는, 기다리는 사람에게 질문을 무시한 에이전트와 정확히 동일하게 읽힙니다.

이 확인은 어떤 모양이 보이는지가 아니라, 실제로 무엇이 돌아왔는지를 살펴봅니다. 결과의 형태를 학습한 모델은 작업을 수행하지 않고 형태만 작성할 수 있습니다 — 빈 블록이거나, 수행하지 않은 조회에 대한 참조입니다. 둘 다 전달된 것이 없는 것으로 처리됩니다.

이 추가 단계는 수분의 1초 정도 소요되며, 그것이 필요한 것처럼 보이는 메시지에만 실행됩니다 — 일반적인 질문은 비용을 지불하지 않습니다. 실행 중일 때, 대화는 현재 수행 중인 작업을 표시합니다. 결정의 어떤 부분이 명확하지 않은 경우, 턴은 그것이 없었을 때와 동일하게 진행됩니다.

두 가지 예산, 하나가 아님

도구 결과는 대화의 컨텍스트가 파괴되는 가장 흔한 방법입니다. 단일 CRM 쿼리는 모델의 전체 컨텍스트 창보다 많은 텍스트를 반환할 수 있습니다.

개별 결과에 한도를 두는 것은 명백한 방어 수단이며, 충분하지 않습니다. 결과는 반복 횟수 동안 누적됩니다 — 대화는 계속 성장하므로 — 최악의 경우, 반복 횟수 제한에 반복당 여러 도구를 곱한 값에 개별 결과 한도를 곱한 값입니다. 각 결과는 자체 한도를 통과하지만 총합은 여전히 오버플로우됩니다.

따라서 두 가지 예산이 있습니다: 개별 결과 한도와 전체 턴에 대한 집계 예산입니다. 집계 예산이 고갈되면, 추가 결과는 추가되는 대신 짧은 플레이스홀더로 대체됩니다.

그 플레이스홀더에 무엇이 들어가는지는 잘림 자체만큼이나 중요합니다. 조용히 잘린 결과는 none보다 나쁩니다. 모델은 절반의 기록에서 추론하고 있다는 방법을 알 수 없기 때문입니다. 잘림 알림과 고갈 플레이스홀더 모두 콘텐츠가 불완전하며 누락된 부분을 발명하지 말라고 모델에게 지시한다고 명시합니다 — "첫 몇 주문만 볼 수 있었습니다"라고 말하는 에이전트와 나머지를 자신 있게 만들어내는 에이전트의 차이입니다.

잘림은 도구 이름과 크기와 함께 로그에 기록됩니다. 예산을 정기적으로 오버플로우하는 도구는 더 적은 필드를 반환해야 하는 도구이기 때문입니다 — 이는 확인 가치가 있는 구성 문제입니다.

적절한 도구 호출을 생성하지 않는 모델

모든 모델이 구조화된 도구 호출을 reliably하게 생성하지 않습니다. 일부는 응답의 텍스트로 호출을 생성합니다. 이를 실패한 턴으로 처리하는 대신, 루프는 메시지 내용에서 도구 호출을 파싱하고, 고객에게 답변이 도달하기 전에 손상된 조각을 제거합니다 — 따라서 모델이 잠시 어긋난 경우에도 JSON이 대화에 유출되는 대신 약간 더 느린 턴으로 저하됩니다.

귀하의 시스템 연결

도구는 두 곳에서 옵니다.

내장 도구는 플랫폼과 함께 제공됩니다 —フォロー업 예약, 알림 생성, 연락처 정보 캡처, 스킬 호출, 문서 편집, 차트 그리기, 웹 검색 등.

이들 대부분은 당신이 결정하는 사항이 아닙니다. 모든 에이전트에게 사용 가능하며 필요한 턴에 연결됩니다. 이것이 그들이 비용을 발생시키지 않는 이유입니다 — 방문자의 메시지가 사용할 이유가 없는 도구는 해당 턴의 목록에 전혀 없으므로 컨텍스트를 차지하지 않으며, 모델이 실수로 선택할 대상도 없습니다. 유지해야 할 체크리스트가 없으며, 에이전트가 전화번호를 받을 능력이 없이 조용히 결여된 구성도 존재하지 않습니다.

스킬 자체의 도구는 예외이며, 의도적으로 그렇습니다. 그들은 스킬이 로드된 후에만 도착하며, 그 전에는 없습니다. 기능 팩은 작업 방식이며, 도구는 그 방법의 일부입니다 — 별도로 제공하면 모델이 방법을 건너뛸 수 있습니다. Skills and how one gets chosen을 참조하십시오.

결정이 필요한 유일한 것은 공개 소스에서 답변하는 것입니다 — 이 에이전트가 웹을 검색하고 발견한 내용을 읽을 수 있는지, 아니면 귀하의 자료에서만 답변해야 하는지 여부입니다. 단일 스위치인 이유는 단일 질문이기 때문입니다 — 검색과 가져오기는 함께 켜지며, 페이지는 찾을 수 있지만 읽을 수 없는 에이전트는 세 가지 구성 중 측정 가능한 최악입니다. 기본적으로 꺼져 있으며, 켜졌을 때 에이전트가 수행하는 작업 — 레이블링, 검토 대기열 등 — 은 Retrieval에서 설명합니다.

귀하의 시스템은 MCP를 통해 연결됩니다. 테넌트는 MCP 서버를 등록하며, 그들의 도구는 해당 테넌트의 에이전트에게 사용 가능해집니다. 세 가지 전송이 지원됩니다: 로컬 서브프로세스용 stdio, 원격 서버용 streamable_http 및 sse. 호스팅 CRM이나 내부 API의 경우 원격 HTTP 서버가 일반적인 선택입니다 — 플랫폼 옆에 설치할 것이 없으며, 연결은 테넌트별로 이루어집니다.

도구 정의가 테넌트별로 등록되므로, 한 테넌트의 에이전트는 다른 테넌트의 도구 또는 엔드포인트를 볼 수 없습니다.

실제 적용 시 의미

• 에이전트는 문장 중간에 무언가를 조회하고 실제 값으로 답변할 수 있습니다.
• 고객에게 수행하라고 말하는 대신, 이미 실행 중인 시스템에 예약, 파일 저장 및 기록을 수행할 수 있습니다.
• 도구가 턴이 보유할 수 있는 것보다 많은 내용을 반환할 경우, 에이전트는 합리적인 허구로 간극을 채우는 대신 자신의 시야가 부분적이었음을 말합니다.

답변하는 대신 행동하는 것에 대한 비즈니스 논리는 Agents that act에서 확인할 수 있습니다.