본문으로 건너뛰기

Deep Agent Builder 멀티에이전트 실행 흐름

이 페이지는 서브에이전트가 포함된 실행이 어디서 시작되고, 어떤 경계를 거쳐 Runtime에 도달하며, 결과가 사용자와 부모 모델에 어떻게 전달되는지 설명합니다. 에이전트에 서브에이전트를 연결하는 저장 절차는 서브에이전트 할당하기, 구성 원칙은 멀티에이전트 개념에서 확인하세요.

실행은 세 경계를 통과합니다​

멀티에이전트 실행을 하나의 호출로 보지 말고 다음 세 구간으로 나눠 보세요.

구간담당확인할 내용
요청과 정책 결정Service API부모 에이전트, 선택한 thread와 실행 모드에서 사용할 자원을 모으고 권한 결과를 만듭니다.
dispatch와 재검증Runtime전달받은 permission bundle의 만료, 실행 식별자, 재사용 여부, 자원 목록과 권한을 다시 검사합니다.
그래프 실행과 결과 전달Runtime과 클라이언트검사를 통과한 뒤 graph를 호출하고, task 결과를 사용자 화면과 부모 모델에 서로 다른 형태로 전달합니다.

이 구분은 저장된 연결 목록과 실제 실행 가능 여부를 섞지 않게 해 줍니다. 연결 저장이 끝났어도 실행 시점의 자원 상태와 권한 검사를 다시 통과해야 합니다.

1. Service API가 실행을 준비합니다​

실행 요청에는 actor user ID, 부모 agent, 선택적인 thread, run UID와 mode가 사용됩니다. Service API는 부모 에이전트와 thread에서 참조하는 자원을 모아 RBAC와 ABAC 자료를 평가합니다. workspace는 이 dispatch 범위의 입력이나 권한 경계로 사용되지 않습니다.

허용 결과는 실행에 사용할 권한 묶음으로 보존되고 Runtime에 전달됩니다. 이 묶음은 실행 중 사용할 자원과 권한 판단 결과를 함께 담습니다.

여기서 확인할 것은 다음과 같습니다.

  1. 실행 주체와 부모 에이전트가 요청에 맞게 식별됐는지 확인합니다.
  2. 부모 에이전트가 실제로 사용할 model, tool, middleware, skill과 직접 연결된 subagent resource를 권한 평가 대상에 포함했는지 확인합니다.
  3. Service API의 허용 결과와 실행에 전달된 권한 묶음이 같은 실행을 가리키는지 확인합니다.

2. Runtime이 dispatch를 다시 검사합니다​

Runtime은 Service API의 정책 결정을 처음부터 다시 만들지 않습니다. 대신 전달받은 권한 묶음의 형식과 필수 값이 유효한지 확인한 뒤 fail-closed 방식으로 검사합니다.

검사 순서는 다음과 같습니다.

  1. 권한 묶음이 만료되지 않았는지 확인합니다.
  2. 권한 묶음의 실행 식별자가 현재 dispatch 대상과 일치하는지 확인합니다.
  3. 같은 권한 묶음을 이전 실행에서 사용하지 않았는지 확인합니다.
  4. graph가 실제로 사용할 model, tool, middleware, skill과 직접 연결된 subagent resource가 허용 목록에 포함됐는지 확인합니다.
  5. 각 resource에 실행에 필요한 사용 권한이 있는지 확인합니다.

검사 결과에 따라 실행 전 다음과 같이 중단됩니다.

조건판정
Service API의 정책 결정이 거부됨권한 거부
정책 결정 시간이 초과됨fail-closed로 실행 중단
권한 묶음이 만료됨만료 오류
권한 묶음이 이미 사용됨재사용 오류
실행 대상, resource 또는 권한이 맞지 않음권한 묶음 불일치

이 단계에서 실패하면 graph를 구성하거나 호출하지 않습니다. 따라서 실행이 시작되지 않을 때는 먼저 에이전트 편집 화면이 아니라 권한 묶음의 만료, 실행 식별자, 직접 연결된 자원과 사용 권한 결과를 확인해야 합니다.

이 문서가 설명하는 것은 기본 dispatch 경계입니다. 동적으로 새 subagent를 찾거나 위임별로 권한을 다시 판정하는 별도 내부 API의 지원 여부는 이 흐름만으로 판단하지 않습니다.

3. 통과한 실행이 graph와 task를 호출합니다​

Runtime gate가 모든 검사를 통과하면 graph를 구성하고 호출합니다. subagent가 task tool을 통해 결과를 반환하면 원본 tool-result frame은 클라이언트로 전달됩니다. 사용자는 이 frame에서 산출물을 확인할 수 있습니다.

동시에 다음 부모 model 요청에는 원본 산출물 전체를 그대로 넣지 않습니다. Runtime은 provider로 보내는 요청 복사본에서 산출물 블록을 짧은 placeholder로 바꿉니다. 원본 메시지와 실행 상태에는 산출물이 유지되므로 사용자 화면과 부모 model의 입력이 서로 다른 것은 오류가 아니라 의도된 경계입니다.

placeholder에는 다음 정보가 남습니다.

  • 산출물 식별자
  • 파싱된 type과 title
  • 본문 문자 수
  • 후속 작업에 원문이 필요할 때 조회하라는 안내

산출물 표시 구조가 닫히지 않았거나 중첩된 경우처럼 입력이 유효하지 않으면 Runtime은 부분 치환하지 않고 원래 메시지를 통과시킵니다. 따라서 부모 model에 placeholder가 보이지 않는 상황은 산출물 자체의 성공 여부와 분리해 확인해야 합니다.

4. 부모 model은 필요할 때만 원문을 회수합니다​

산출물 조회 기능은 parent graph에만 등록되는 경로입니다. 부모 model이 원문을 후속 작업에 사용해야 할 때만 산출물 식별자를 조회합니다.

  1. 인자 없이 호출하면 현재 회수할 수 있는 산출물의 식별자와 요약 정보를 확인합니다.
  2. 산출물 식별자를 전달하면 표시용 태그를 제거한 본문을 받습니다.
  3. 일반적인 경우에는 실행 상태의 task 결과에서 산출물을 다시 찾습니다.
  4. 결과가 별도 저장소로 이동한 경우에도 실행 상태가 가리키는 원문을 다시 찾습니다.

존재하지 않는 식별자를 조회하면 조회할 수 있는 산출물 목록과 함께 실패 결과가 반환됩니다. 조회 결과에서는 표시용 태그가 제거되므로 같은 결과가 다시 artifact card로 렌더링되지 않습니다.

부모 model의 다음 답변에 산출물 내용이 자동으로 모두 합쳐진다고 가정하지 마세요. 화면에 원본 결과가 보였는지, 부모 model이 placeholder를 받았는지, 후속 조회가 필요한지 각각 확인해야 합니다.

실행 결과를 확인하는 방법​

실행이 끝난 뒤에는 다음 순서로 판단합니다.

  1. 권한 실패라면 권한 거부, 정책 결정 시간 초과, 만료, 재사용, 권한 묶음 불일치 중 실제 판정을 확인합니다.
  2. 권한 검사를 통과했다면 graph 호출과 task 결과 frame이 도착했는지 확인합니다.
  3. 사용자 화면에 원본 task 결과가 한 번 표시됐는지 확인합니다.
  4. 부모 model의 입력에 원문이 아니라 placeholder가 전달됐는지 확인합니다.
  5. 부모 후속 작업에 본문이 필요한 경우에만 부모 전용 산출물 조회가 실행됐는지 확인합니다.

원본 산출물이 화면에 표시됐다는 사실은 부모 model이 그 내용을 다음 답변에 사용했다는 뜻이 아닙니다. 두 결과를 분리해서 확인해야 중복 표시와 누락을 구분할 수 있습니다.

다음 문서​