실행 입력
실행 입력 (1.0) (Run Input)
애플리케이션에서 에이전트로 이동하는 단 하나의 메시지와, 그것의 각 필드가 무엇을 의무화하는지 다루는 페이지예요. 이벤트는 생산자에서 소비자로 흐르고, 정확히 하나의 메시지가 반대 방향으로 흐릅니다: 교환을 열기 위해 한 번 보내는 RunAgentInput이죠.
출처: 문서
본문
이벤트는 생산자에서 소비자로 흐릅니다. 정확히 하나의 메시지가 반대 방향으로 흐릅니다: 각 교환을 열기 위해 한 번 보내는 RunAgentInput이에요. 생산자가 대화에 대해 아는 모든 것은 그것을 통해 도착합니다. 그것이 요청하는 실행이 교환의 마지막 것입니다. 스레드 내역을 재생하는 스트림은 추가 입력 없이 이전 실행을 운반합니다.
스키마가 그것의 형태를 정의합니다. 이 페이지는 각 필드가 무엇을 의무화하는지 서술합니다. 생산자는 RUN_STARTED.input에 입력을 되돌려 보낼 수 있고(MAY), 그래서 요청을 만들지 않은 소비자도 에이전트가 무엇을 물었는지 볼 수 있습니다.
신원 (Identity)
threadId는 대화를, runId는 이 입력이 요청하는 실행을 이름 붙입니다. 둘 다 REQUIRED입니다. 스트림의 모든 실행은 그 경계 이벤트들 — 신원을 담는 두 개인 RUN_STARTED와 RUN_FINISHED — 에 입력의 threadId를 담으며, 각 실행의 두 경계 이벤트는 그들의 runId에 동의해야 합니다(MUST). 요청된 실행은 이 입력의 runId를 되돌아봅니다. 재생된 실행은 자신의 것을 담습니다. parentRunId는 OPTIONAL이며, 에이전트가 다른 에이전트를 별도 실행으로 시작할 때 이 실행을 만든 실행의 이름입니다.
protocolVersion
스키마에서 OPTIONAL입니다. 부재는 프로토콜이 버전을 담기 전의 피어를 식별하기 때문이죠. 그러나 이 버전을 구현하는 소비자는 오래된 파서가 거부할 위험을 감수하기보다 멤버를 생략한다는 것을 알지 않는 한, 여기서 자기 버전을 선언해야 합니다(MUST). 생산자는 RUN_STARTED에서 자신의 선언으로 응답합니다. 규칙은 버저닝 (Versioning)에 있습니다.
messages
REQUIRED. 지금까지의 대화를 순서대로 담습니다. 생산자는 그것을 보여지는 완전한 내역으로 취급해야 합니다(MUST) — 프로토콜에는 이전 턴이 도착하는 사이드 채널이 없습니다.
메시지 타입과 콘텐츠 형태 — 사용자 메시지와 프런트엔드 도구 호출에 답하는 도구 메시지에 텍스트, 이미지, 오디오, 비디오, 문서를 URL로, 인라인 데이터로, 또는 프로바이더 파일 핸들로 담는 다중 모달 ContentPart을 포함해서 — 은 스키마의 몫입니다. 두 가지 행동 규칙이 붙습니다:
- 사용할 수 없는 콘텐츠 부분을 가진 생산자 — 이미지를 받은 비전 없는 모델 — 는 그것 때문에 실행을 실패시키면 안 됩니다(MUST NOT). 사용하지 못하는 것을 건너뛰고 계속하는 것이 적합한 행동입니다. 다운그레이드된 나가는 경로에서 콘텐츠를 잃는 것은 다르며 경고를 의무화합니다(버저닝 (Versioning)).
- activity 메시지는 결코 생산자로 돌아가지 않습니다. 소비자는 보내기 전에
messages에서 그것을 떼어내야 합니다(MUST). 그것들은 소비자의 렌더링 자료이지, 에이전트가 이어가는 대화가 아닙니다.
프로바이더 파일 핸들 (Provider file handles)
미디어 부분의 source는 바이트가 어디 있는지 말합니다: 인라인으로 담기거나(data), URL로 가져올 수 있거나(url), 또는 프로바이더가 발급한 핸들 아래 모델 프로바이더에 이미 있거나(file) — OpenAI나 Anthropic 파일 id, Gemini 파일 URI, 그 프로바이더만 읽을 수 있는 스토리지 URL이죠. file source가 존재하는 이유는 핸들이 다른 두 가지 중 어느 것도 아니기 때문입니다. 그건 바이트를 담지 않고, 그것을 만든 프로바이더 외에는 누구도 가져올 수 없어요. 그래서 url에 넣으면 다른 모든 피어가 시도하게 됩니다.
filesource의value는 불투명합니다. 피어는 그것을 가져오거나, 파싱하거나, 스킴을 읽으면 안 됩니다(MUST NOT). 핸들을 프로바이더에게 건네거나, 부분을 사용하지 않습니다.provider는 생산자가 알 때 누가 핸들을 발급했는지 이름 붙입니다. OPTIONAL이고 — 에이전트는 이미 자신이 말하는 프로바이더를 압니다 — 있을 때는TokenUsage.provider가 쓰는 소문자 벤더 id여야 하며(SHOULD), 그래서 피어가 보내기 전에 핸들이 자신이 쓸 수 있는 것인지 알 수 있습니다.- 해결할 수 없는 핸들 — 다른 프로바이더의 것, 알 수 없는 프로바이더의 것, 만료된 것 — 을 받은 생산자는 위 첫 규칙이 이미 다루는 상황에 있습니다. 실행을 실패시키면 안 되고(MUST NOT), 부분을 건너뛰고 계속하며, 그렇게 말해야 합니다(SHOULD). 핸들의 수명은 프로바이더의 몫이고, 만료를 운반하고 싶은 생산자는 부분의
metadata에 그렇게 합니다. - source 팔(arm)은 닫힌 집합입니다. 피어가 인식하지 못하는
type을 가진 source는 통과되지 않고 검증을 실패합니다. 그래서 이 팔이 1.0에 있고 나중 마이너 버전이 아닙니다 — 1.0으로 빌드된 소비자는 그것을 절대 통과시킬 수 없었을 것입니다.
tools
OPTIONAL. 애플리케이션 자신의 도구 — 프런트엔드 도구 — 를 이 실행을 위해 에이전트에게 제공합니다: 이름, 설명, 그리고 도구가 인수를 받으면 파라미터 스키마. 애플리케이션이 실행하므로 에이전트가 아닙니다. 하나를 호출하면 실행 경계를 가로질러 통제를 되돌려 주는데, 왕복은 도구 호출 (Tool calls)이 지정합니다.
없는 목록과 빈 목록은 같은 뜻입니다: 도구 없음. 생산자는 빠진 tools를 빈 것과 정확히 같게 취급해야 하며(MUST), 소비자는 []를 보내기보다 빈 목록을 생략할 수 있습니다(MAY).
context
OPTIONAL. 애플리케이션이 에이전트의 컨텍스트에 넣고 싶은 정보를 description–value 쌍으로 담습니다. 그것은 주입되기 위해 존재합니다. 생산자는 모든 항목을 실행의 그라운딩의 일부로 모델에게 제공해야 합니다(SHOULD). 어떻게 — 시스템 프롬프트, 프리앰블, 프레임워크가 컨텍스트로 하는 것 — 은 생산자의 몫입니다. 프로토콜은 컨텍스트가 전송용 북키핑이 아니라 모델이 보는 것이라고만 말합니다.
부재는 tools에서와 정확히 같이 비어 있음과 같은 뜻입니다.
state
OPTIONAL. 실행이 시작하는 상태 — 소비자의 마지막 합의 값으로, 전형적으로 이전 실행의 상태 이벤트가 남긴 것입니다. 없는 state는 빈 객체를 의미합니다. 아무것도 합의되지 않았고, {}는 아무것도 아닙니다. 상태 델타를 내보내는 생산자는 자기 첫 스냅샷이 그것을 교체할 때까지 이 값에 대해 계산해야 합니다(MUST).
forwardedProps
OPTIONAL. 에이전트로 그대로 통과되는 애플리케이션 특화 채널입니다. 전체 null을 제외한 어떤 JSON 값도 — 전체 null은 필드가 생략된다는 뜻입니다. 페이로드 안의 null 값은 보존됩니다. 프로토콜은 페이로드에 의미를 붙이지 않으며, 중개자(intermediary)는 그것을 변경하면 안 됩니다(MUST NOT).
resume
OPTIONAL. 이 실행이 하나에서 이어질 때, 이전 실행을 끝낸 인터럽트에 대한 답입니다. 항목과 그 의무는 인터럽트와 재개 (Interrupts and Resume)에 지정됩니다.
오류 처리 (Error Handling)
생산자가 파싱할 수 없거나 잘못된 입력 — 스키마가 거부하는 값을 담은 알려진 필드 — 은 RUN_STARTED 전에, 전송의 오류 경로를 통해 거부됩니다. 실행은 결코 시작하지 않고, RUN_ERROR가 이동할 스트림도 없습니다. 거부가 어떻게 전달되는지는 각 전송 바인딩의 몫입니다.
입력의 인식되지 않는 멤버는 잘못된 것이 아닙니다. 처리 모델의 비대칭성은 이 방향에도 묶입니다. 인식하지 못하는 입력 자료를 만난 생산자는 그것을 경고와 함께 떼어내고 실행합니다. 그래서 더 새로운 소비자의 입력이 더 오래된 생산자에게 튕기지 않습니다.
더 알아보기 (Learn more)
- 아키텍처 (1.0) — 실행이 상호작용의 단위인 이유
- HTTP + SSE (1.0) — 기본 전송 바인딩
- 스키마 레퍼런스 —
RunAgentInput정의