스킬과 선택 방식

**스킬(skill)**은 작업 방식을 패키징한 것입니다: 적용되는 시기를 나타내는 짧은 문장, 전체 절차(procedure), 그리고 해당 절차가 필요로 하는 도구들입니다. 이 문장은 매 턴마다 프롬프트에 포함되며, 절차는 스킬이 선택된 후에야 가져옵니다. 이러한 분리가 에이전트가 매 메시지마다 비용을 지불하지 않고도 많은 기능을 수행할 수 있게 해줍니다.

이 페이지는 어려운 부분에 관한 것입니다: 사용 가능한 모든 것 중 어떤 것이 사용되는가 — 그리고 명확하게 맞는 것이 없을 때 어떤 일이 발생하는가.

두 개의 라이브러리, 하나의 공간

모든 에이전트는 두 곳에서 스킬을 가지며, 첫 번째에 대해 알려줄 필요는 없습니다:

• 플랫폼 스킬 — 일반적인 작업 방법(경쟁사 조사, 규정 읽기, 리드 평가 등). 모든 에이전트에게 기본적으로 제공됩니다.
• 사용자의 스킬 — 사용자가 자사 비즈니스를 위해 작성한 것으로, 에이전트별로 연결됩니다.

이들은 함께 검색됩니다. 공간을 공유한다고 해서 사용자 자신의 스킬이 불리해지지 않습니다: 193개의 일반 스킬에 섞인 18개의 진정으로 산업별 스킬을 측정했을 때, 산업별 스킬이 더 reliably(안정적으로) 인식되었습니다(86% 대 79%). 산업별 어휘(HS 코드, 수출 환급, 매장 규정 준수 등)는 일반 방법 어휘와 멀리 떨어져 있으므로, 선택하기가 더 어렵지 않고 더 쉽습니다.

검색, 전체 목록이 작동하지 않기 때문에

대략 8개 미만의 스킬인 경우, 이 모든 것이 실행되지 않습니다 — 전체 목록이 이전처럼 표시됩니다. 그 크기에서는 목록이 이미 정확하며, 검색은 실패할 수 있는 새로운 방법만 추가할 뿐입니다: 올바른 스킬이 단축 목록에서 누락되고, 모델이 자체 지식에서 답변하며, 로그에 그 사실이 기록되지 않습니다.

절차가 도구보다 먼저

스킬 고유의 도구는 턴 시작 시점에 사용 가능하지 않습니다. 스킬을 로드해야 그 도구들이 사용 가능해집니다.

이 순서는 프롬프트에서 요청하는 것이 아니라 코드에서 강제되며, 그 이유는 측정 결과 때문입니다. 회사의 경쟁사를 조사하라는 요청에 대해 절차와 도구를 함께 제공했을 때, 모델은 웹 검색을 세 번 호출했고 절차를 전혀 읽지 않았습니다. 모델은 기억에서 경쟁사 이름을 생성하고, 그 가짜 이름들을 검색했으며, 아무것도 찾지 못했습니다 — 존재하지 않는 이름들이었습니다 — 그리고 이를 답변으로 작성했습니다. 절차의 첫 번째 단계는 *"먼저 이 회사가 실제로 무엇을 판매하는지 확인하라"*라고 명시하고 있었습니다.

선택적 절차는 읽히지 않습니다. 에이전트가 자체적으로 보유한 도구는 영향을 받지 않습니다: web_search가 에이전트에 있다면, 그 턴 내내 사용 가능하게 유지됩니다. 오직 스킬 때문에 도착하는 도구들만 해당 스킬을 기다립니다.

일부 스킬은 시작하기 전에 자료를 받습니다

빈 책상에서 시작하는 조사 스킬이 사실을 가져올 수 있는 곳은 한 군데뿐입니다. 모델 자신의 기억입니다. 그래서 이를 선언한 스킬에 대해서는 플랫폼이 스킬이 실행되기 전에 첫 번째 조사를 대신 수행합니다. 방문자의 문장을 검색어로 바꾸어 실행하고, 그 결과를 번호가 붙은 사실 표로 건네줍니다. 답변은 그 표를 출처로 표시해야 합니다.

폭은 스킬마다 정합니다. 공짜가 아니기 때문입니다. 얼마인지, 어떤 제한이 있는지, 내 데이터를 어떻게 빼내는지처럼 여러 갈래가 한꺼번에 담긴 질문은 두 번의 검색으로 답할 수 없습니다. 바로 그 질문으로 측정했을 때, 좁은 조사는 2,957자에 출처 5개를 달았고, 거기 적힌 가격은 모두 어떤 출처에도 없는 구체적인 숫자였습니다. 조사형 스킬의 폭을 넓히자 같은 질문이 출처 17개와 함께 돌아왔고, 기술 비교는 5.7개에서 11.7개가 되었습니다. 초안을 쓰거나 고쳐 쓰거나 계산하는 스킬은 아무것도 선언하지 않고 아무것도 검색하지 않습니다.

같은 스킬의 지침에는 평범한 말로 자료에 없는 가격은 절대 쓰지 말 것이라고 이미 적혀 있었습니다. 그래도 썼습니다. 프롬프트 안의 규칙은 요청일 뿐입니다. 답을 바꾼 것은 충분한 자료였습니다.

이와 함께 바꿔야 할 것이 하나 더 있었습니다. 최악의 조합—검색은 했는데 본문을 한 페이지도 열지 않아 답이 발췌문에서만 나올 수 있는 상황—을 지키는 장치는 이미 있었습니다. 그 장치가 물은 것은 모델이 검색했는지였습니다. 플랫폼이 스킬을 대신해 검색한 턴에서는 모델이 아무것도 호출하지 않았으므로, 이 장치는 정작 가장 필요한 턴에서 물러나 있었습니다. 이제는 누가 실행했든 이번 턴에 검색 결과가 있는지를 묻습니다.

명확하게 맞는 것이 없을 때, 질문합니다

일부 요청은 진정으로 하나의 스킬을 지시하지 않습니다. 플랫폼은 그 상황에 있는지 확인할 수 있습니다 — 모델이 확신이 있는지 묻는 것이 아니라, 검색 점수들이 얼마나 밀집되어 있는지 살펴봄으로써. 상위 15개 후보들이 거의 차이 없이 분리되어 있을 때, 검색은 의견을 가지지 않으며, 여전히 답변하는 것은 동전 던지기입니다: 그 밴드에서 올바른 스킬이 첫 번째로 순위 매겨진 비율은 **26%**인 반면, 점수들이 퍼져 있을 때는 **85%**입니다.

따라서 그 밴드에서, 그리고 오직 그곳에서, 에이전트는 먼저 한 가지 질문을 합니다 — 매개변수를 요청하는 대신 두 가지 또는 세 가지 평이한 옵션을 제시합니다("현재 시장 가격을 원하시나요, 아니면 이 특정 자산의 가치를 평가해 드릴까요?"). 가장 어려운 4분의 1의 요청에서 이는 정확도를 **36.7%에서 63.3%**로 높였으며, 평균 1.5개의 질문이 필요했습니다.

모델이 스스로 언제 질문할지 결정하게 하는 것은 작동하지 않습니다: 판단을 요청받았을 때, 모델은 **81.5%**의 턴에서 질문했습니다 — 그 중 올바르게 맞혔을 것들이었던 턴들도 포함됩니다. 점수 확산에 게이트를 두었을 때, 모델은 **11%**의 턴에서 질문했으며, 동일한 이점을 얻었습니다.

이것이 실무에서 의미하는 바

• 에이전트는 구성되지 않아도 일반적인 작업 방법을 알고 있으며, 더 많은 방법을 알더라도 메시지당 비용은 들지 않습니다.
• 사용자의 스킬은 자사 비즈니스에서 승리합니다 — 산업별 어휘가 그 역할을 합니다.
• 스킬은 절차대로 따르거나, 전혀 실행되지 않습니다. 도구를 가져와서 즉흥적으로 수행하며 반쯤 따를 수 없습니다.
• 조사형 스킬은 기억이 아니라 출처를 책상에 놓고 시작합니다. 작성한 내용은 그 자료를 출처로 표시하고, 자료가 다루지 않은 것은 찾지 못했다고 보고합니다.
• 모호한 요청은 추측이 아닌 질문을 받습니다 — 그리고 시스템이 진정으로 구분할 수 없는 소수의 턴에서만 질문이 도착합니다.