호스트된 에이전트 디버그

Microsoft Foundry를 사용하여 에이전트를 빌드, 실행 및 배포할 때 발생하는 일반적인 문제를 진단하고 해결합니다azd ai agent. 진단 명령으로 시작합니다. 그런 다음 증상 기반 섹션을 사용하여 인증, 로컬 개발, 배포, 직접 명령, 로그 및 루틴 문제를 해결합니다.

사전 요구 사항

진단 컨텍스트 수집

특정 오류를 살펴보기 전에 다음 명령을 사용하여 컨텍스트를 수집합니다.

# Check extension version
azd ai agent version

# Verify Azure authentication
azd auth login

# Show current environment configuration
azd env get-values

# View agent details
azd ai agent show

# Show the resolved Foundry project endpoint and where it came from
azd ai project show

# Stream production logs
azd ai agent monitor --follow

구조화된 상태 보고서를 보려면 azd ai agent doctor를 실행하세요. 자세한 내용은 에이전트 의사와 프로젝트 진단을 참조하세요.

호출 대기 시간 진단

대기 시간 디버그 헤더를 사용하여 느린 호스트된 에이전트 요청이 플랫폼에서 시간을 소비했는지, 인프라를 프로비전하거나, 컨테이너를 기다리거나, 에이전트에서 요청을 처리하는지 확인합니다. 이러한 헤더는 SLA 또는 청구 메트릭이 아닌 진단 신호입니다.

x-ms-debug-latency-enabled: true를 설정하여 각 요청에 대해 진단을 사용하도록 설정합니다. 요청에 이 헤더가 포함되지 않으면 응답에 헤더가 x-ms-debug-latency-* 포함되지 않습니다.

  1. 호스트된 에이전트 응답 또는 호출 프로토콜 요청에 대기 시간 헤더를 추가합니다. 이 예제에서는 응답 프로토콜을 사용합니다.

    ENDPOINT="https://{account}.services.ai.azure.com/api/projects/{project}"
API_VERSION="v1"
TOKEN=$(az account get-access-token \
  --resource https://ai.azure.com \
  --query accessToken -o tsv)
AGENT="my-code-agent"

curl --http2 -i -X POST \
  "$ENDPOINT/agents/$AGENT/endpoint/protocols/openai/responses?api-version=$API_VERSION" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "x-ms-debug-latency-enabled: true" \
  -d '{"model":"gpt-5.4-mini","input":"Hello, agent!","stream":false}'

  2. 응답 헤더를 검사합니다. 모든 대기 시간 값은 정수 밀리초입니다.

    Header Meaning
    x-ms-debug-latency-session-start-type 요청이 트리거한 세션 시작 유형: 콜드 스타트(cold), 웜 스타트(warm) 또는 유휴 상태에서 재개(resume).
    x-ms-debug-latency-platform-preprocessing-ms 접수, 인증, 세션 조회 및 오케스트레이션을 위한 플랫폼 시간 마이크로 VM 프로비저닝 또는 컨테이너 준비 지연은 포함되지 않습니다. 콜드 부팅, 웜 부팅 및 재개된 세션 시작에 대해 사용 가능.
    x-ms-debug-latency-infra-setup-ms 마이크로 VM을 프로비전하는 시간입니다. 웜 요청의 경우 생략됨.
    x-ms-debug-latency-container-readiness-ms 마이크로 VM 생성부터 컨테이너가 준비될 때까지의 시간입니다. 웜 요청의 경우 생략됨.
    x-ms-debug-latency-container-response-ms 프록시 전달에서 응답 헤더가 커밋될 때까지의 시간입니다. 요청 전송, 연결 설정, 에이전트 처리, 재시도 및 출력 정책 버퍼링이 포함됩니다.
    x-ms-debug-latency-response-begin-ms 응답 헤더가 커밋될 때까지 서비스 승인의 총 시간입니다. 이 값은 첫 번째 응답 본문 바이트 또는 첫 번째 서버 전송 이벤트에 대한 시간이 아닙니다.

    4개의 타이밍 구성 요소를 합하면 x-ms-debug-latency-response-begin-ms이 됩니다. 콜드 또는 다시 시작 요청에서 플랫폼이 모든 프로비전 경계를 캡처할 수 없는 경우 인프라 및 준비 헤더를 생략하고 플랫폼 전처리에 해당 시간을 포함합니다.

  3. 세션 시작 유형 및 가장 큰 타이밍 구성 요소를 사용하여 지연의 원인을 식별합니다.

    Result 해석 무엇을 해야 할지
    x-ms-debug-latency-session-start-type는 cold 또는 resume이고, x-ms-debug-latency-infra-setup-ms는 높습니다 플랫폼은 마이크로 VM을 프로비전하는 데 시간을 보냈습니다. 여러 건의 콜드 요청 또는 재개된 요청을 비교합니다. 지연이 지속되면 지원 요청에 대한 응답 ID, 타임스탬프 및 대기 시간 헤더를 기록합니다.
    x-ms-debug-latency-session-start-type가 cold 또는 resume이고 x-ms-debug-latency-container-readiness-ms는 높습니다 컨테이너가 시작되고 준비 완료 상태라고 보고되기까지 시간이 오래 걸렸습니다. 시작 로그의 초기화 단계를 측정하고, 준비 엔드포인트를 사용할 수 있게 되기 전에 작업을 줄이고, 가능한 경우 애플리케이션 코드를 미리 컴파일합니다.
    x-ms-debug-latency-platform-preprocessing-ms 값이 모든 세션 시작 유형에서 높습니다 마이크로 VM 프로비저닝 또는 컨테이너 준비 전에 플랫폼에서 지연이 발생했습니다. 지원 요청을 만듭니다. 응답 ID, 타임스탬프, 세션 시작 유형 및 대기 시간 헤더를 포함합니다.
    x-ms-debug-latency-container-response-ms, x-ms-debug-latency-first-byte-ms 또는 예고편의 first_byte_ms이 높음 프록시 전달이 시작된 후 지연이 발생했습니다. 요청 처리기를 계측하고 에이전트 로그, 모델 호출, 도구 호출, 재시도 및 출력 버퍼링을 검사합니다.

컨테이너 준비 시간 단축

컨테이너 준비 값에는 프로세스를 시작하고, 애플리케이션을 로드하고, HTTP 200 /readiness을 반환하는 데 필요한 시간이 포함됩니다. 시작 로그에 타임스탬프를 추가하여 느린 가져오기, 종속성 로드, 네트워크 호출 및 기타 초기화 작업을 식별합니다.

식별되는 느린 단계에 이러한 최적화를 적용합니다.

  • 이미지를 빌드할 때 종속성을 설치하고 코드를 컴파일합니다. 컨테이너 시작 시 패키지 설치, 복원 또는 컴파일을 실행하지 마세요.
  • 다단계 빌드를 사용하고 런타임 이미지에서 빌드 도구, 패키지 캐시, 테스트 및 기타 개발 파일을 제외합니다.
  • 준비 전에 모델 호출, 마이그레이션, 도구 검색 및 자산 다운로드를 방지합니다. 먼저 완료해야 하는 독립 초기화를 병렬화합니다.
  • /readiness 에이전트가 요청을 수락할 수 있는지 여부에 계속 집중합니다. 초기화를 연기하는 경우 첫 번째 요청을 측정하여 시작 지연을 요청 처리로 이동하지 않았는지 확인합니다.

런타임 이미지에 복사하는 가상 환경에 종속성을 설치합니다. 타사 패키지에서 분리할 수 없는 파일이 빌드에 실패하지 않도록 최상의 방법으로 종속성을 컴파일합니다. 구문 오류가 빌드에 실패할 수 있도록 애플리케이션을 엄격하게 컴파일합니다.

FROM python:3.13-slim AS build

WORKDIR /app
RUN python -m venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .
RUN PYTHONDONTWRITEBYTECODE= python -m compileall -q /opt/venv \
      || true; \
    PYTHONDONTWRITEBYTECODE= python -m compileall -q /app

FROM python:3.13-slim AS final

ENV PATH="/opt/venv/bin:$PATH"
WORKDIR /app

COPY --from=build /opt/venv /opt/venv
COPY --from=build /app /app

# Precompile the standard library in the runtime image.
RUN PYTHONDONTWRITEBYTECODE= python -m compileall -q \
    "$(python -c "import sysconfig; print(sysconfig.get_path('stdlib'))")" \
    || true

CMD ["python", "main.py"]

PYTHONDONTWRITEBYTECODE 이 빌드 단계를 지우면 Python 바이트 코드를 이미지에 쓸 수 있습니다. 환경 변수는 읽기가 아닌 바이트코드 쓰기를 차단하므로 실행 중인 컨테이너는 컴파일된 파일을 계속 사용할 수 있습니다.

참조: compileall - 바이트 컴파일 Python 라이브러리

호스팅된 에이전트에 필요한 x86-64 아키텍처용 두 이미지 중 하나를 빌드합니다.

docker build --platform linux/amd64 -t my-agent:latest .

linux/amd64 여기서는 .NET 런타임 식별자가 아닌 Docker 플랫폼입니다.

참조: 호스트된 에이전트 컨테이너 요구 사항

에이전트 및 모델 대기 시간 조사

컨테이너 준비 상태가 빠르지만 컨테이너 응답 또는 첫 번째 바이트 시간이 높은 경우 전달이 시작된 후 요청 경로에 조사에 집중합니다. 요청을 재현하는 동안 azd ai agent monitor --follow를 실행하고, 모델 호출, 도구 호출, 외부 서비스, 재시도, 그리고 응답 직렬화 전반에 추적을 추가합니다. 자세한 내용은 호스트된 에이전트 로그 모니터링을 참조하세요.

큰 언어 모델을 호출하는 에이전트의 경우 배포를 변경하기 전에 모델 대기 시간을 별도로 측정합니다. 첫 번째 토큰과 시간, 토큰 간 시간, 생성된 토큰 수, 프롬프트 크기, 배포 사용률 및 제한을 비교합니다. 그런 다음 모델 선택, 출력 토큰 제한, 스트리밍 및 워크로드 분리를 평가합니다. Azure OpenAI 성능 향상을 참조하세요.

측정값에 예측 가능한 워크로드에 대한 지속적인 용량 압력이 표시되면 프로비전된 배포를 평가하고 관찰된 입력 토큰, 출력 토큰 및 요청 속도에 맞게 크기를 조정합니다. 프로비전된 처리량을 참조하세요.

완료 시점 확인

HTTP/2 이상에서는 서비스가 가능한 최선의 x-ms-debug-latency-final 응답 트레일러를 반환할 수 있습니다. 응답 헤더 값을 반복하고 다음 필드를 추가할 수 있습니다.

Field Meaning
first_byte_ms 서비스 수락 시간부터 첫 번째 응답 본문 바이트 또는 서버 전송 이벤트까지입니다.
total_last_byte_ms 응답 전달이 완료될 때까지의 서비스 수락 시간입니다.

예고편은 버전이 지정된 세미콜론으로 구분된 형식을 사용합니다.

x-ms-debug-latency-final: v=1;start=cold;platform_pre_ms=...;
  infra_ms=...;ready_ms=...;container_response_ms=...;
  response_begin_ms=...;first_byte_ms=...;total_last_byte_ms=...

HTTP/1.1 응답에는 이 예고편이 포함되지 않습니다. 취소, 클라이언트 연결 끊기, 중간 스트림 오류 또는 게이트웨이 또는 SDK가 트레일러를 유지하지 않는 경우 트레일러가 없을 수도 있습니다. 응답 헤더를 보장된 진단 계약으로 처리합니다.

저장된 대기 시간 결과 검색

서비스는 응답 또는 호출을 사용하여 캡처된 타이밍을 저장합니다. 동일한 응답 또는 호출 ID에 대한 이후 GET 요청은 원래 요청의 타이밍을 응답 헤더로 반환합니다. GET 요청에는 대기 시간 헤더가 필요하지 않으며 GET 요청 자체를 측정하지 않습니다.

GET 요청은 이러한 완료 값을 일반 헤더로 반환할 수도 있습니다.

Header Meaning
x-ms-debug-latency-first-byte-ms 첫 번째 응답 본문 바이트까지의 시간입니다.
x-ms-debug-latency-total-last-byte-ms 응답 전달이 완료될 때까지의 시간입니다.

스토리지는 결국 일관성이 있으므로 원래 요청 직후 GET 요청에 헤더가 아직 포함되지 않을 수 있습니다. 비동기 응답 또는 호출의 경우 세션 시작 유형, 플랫폼 전처리, 인프라 설정 및 컨테이너 준비 상태와 같은 플랫폼 오버헤드 값만 사용할 수 있습니다. 실패한 프록시 응답 또는 WebSocket(invocations_ws) 요청에 대해 대기 시간 헤더가 내보내지지 않습니다.

인증 오류 수정

수정 AuthenticationError

증상: 에이전트가 로컬로 시작하지 못하거나 AI 모델을 호출할 때 401/403을 반환합니다.

원인 및 수정:

  • 만료된 자격 증명 -- 실행 azd auth login 하여 Azure 세션을 새로 고칩니다.
  • 잘못된 구독 -- azd env get-values | grep AZURE_SUBSCRIPTION_ID로 확인하고 Foundry 프로젝트의 구독과 비교하세요.
  • RBAC 역할 누락 - ID에 Foundry 사용자 또는 Foundry 프로젝트에 대한 동등한 액세스 권한이 필요합니다.

중요합니다

Foundry RBAC 역할의 이름이 최근에 바뀌었습니다. Foundry User, Foundry OwnerFoundry 계정 소유자 및 Foundry Project Manager는 이전에 Azure AI 사용자, Azure AI 소유자, Azure AI 계정 소유자 및 Azure AI Project Manager로 이름이 지정되었습니다. 이름 바꾸기가 롤아웃되는 동안 일부 위치에서는 이전 이름이 계속 표시될 수 있습니다. 역할 ID 및 핵심 권한은 이름 바꾸기에 의해 변경되지 않습니다.

또한 모델 배포를 사용하려면 ID에 Cognitive Services OpenAI 사용자가 필요합니다.

프로비저닝 중 AuthorizationFailed 수정

증상:azd up 또는 azd provision 사용 권한 오류와 함께 실패합니다.

수정: Azure 구독에 대한 기여자 역할을 요청합니다. CI/CD의 경우 서비스 주체에 Foundry Owner 권한도 필요합니다.

수정 SubscriptionNotRegistered

증상: 필요한 리소스 공급자가 등록되지 않아 프로비저닝이 실패합니다.

해결 방법:

az provider register --namespace Microsoft.CognitiveServices
az provider register --namespace Microsoft.ContainerRegistry

로컬 개발 문제 해결

포트 8088에서 연결이 거부됨 수정

증상:azd ai agent invoke --local 을(를) 연결하지 못합니다.

원인 및 수정:

  • 에이전트가 실행되지 않음 - 별도의 터미널에서 시작 azd ai agent run 합니다.

  • 포트 충돌 - 다른 프로세스는 포트 8088을 사용합니다. 중지하거나 사용자 지정 포트를 사용합니다.

    azd ai agent run --port 9090
azd ai agent invoke --local --port 9090 "Hello!"

  • 시작 시 충돌 -- azd ai agent run이 실행 중인 터미널에서 오류 출력을 확인하세요. 일반적인 원인으로는 누락된 종속성, 임포트 오류 또는 startupCommand의 잘못된 azure.yaml이 있습니다.

종속성 설치 실패 수정

증상:azd ai agent run 은 종속성 설치 중에 실패합니다.

원인 및 수정:

  • 잘못된 런타임 버전 - Python 3.10 이상 또는 .NET 8 이상이 설치되어 있는지 확인합니다.
  • 누락 requirements.txt 되거나 .csproj -- CLI는 이러한 파일에서 프로젝트 형식을 자동으로 검색합니다. 에이전트 디렉터리에 있는지 확인합니다.
  • 네트워크 문제 - 패키지 레지스트리가 회사 프록시에 의해 차단될 수 있습니다. pip 또는 dotnet 구성을 확인하세요.

ResourceNotFound 또는 DeploymentNotFound 수정

증상: 에이전트가 시작되지만 모델을 호출하려고 할 때 실패합니다.

원인 및 수정:

  • 엔드포인트 불일치 -- azd env get-values을(를) 실행하고 FOUNDRY_PROJECT_ENDPOINT가 Foundry 포털에 표시된 엔드포인트와 일치하는지 확인합니다.
  • 모델 배포 이름 불일치 - 구성된 azure.yaml 모델 배포 이름이 Foundry 프로젝트의 배포 이름과 일치해야 합니다. 포털에서 Deployments 아래를 확인하세요.
  • 리소스가 프로비전되지 않음 - 아직 실행 azd up 하지 않은 경우 클라우드 리소스가 존재하지 않습니다. 먼저 실행 azd up 한 다음 로컬로 테스트합니다. 로컬 에이전트는 여전히 클라우드 호스팅 모델을 호출합니다.

배포 문제 해결

컨테이너 빌드 오류 수정

증상:azd up 는 Docker 빌드 단계 중에 실패합니다.

원인 및 수정:

  • Dockerfile이 없습니다 -- 에이전트 디렉터리에 Dockerfile가 있는지 확인하세요. 템플릿에서 초기화한 경우 자동으로 생성됩니다.
  • 빌드 컨텍스트 오류 -- 서비스 Dockerfile 경로project에서 지정한 azure.yaml 디렉터리에 있어야 합니다.
  • Docker의 종속성 설치 - 컨테이너 내에서 pip/dotnet 복원이 실패하는 경우 모든 requirements.txt.csproj 종속성이 올바르게 고정되었는지 확인합니다.

azd up 중단 또는 시간 제한을 수정하십시오

증상: 프로비전 또는 배포에는 비정상적으로 오랜 시간이 걸립니다.

원인 및 수정:

  • 첫 번째 배포 - 첫 번째 azd up 배포는 Foundry 프로젝트, ACR, 관리 ID 및 모델 배포를 비롯한 모든 Azure 리소스를 프로비전하며 5~10분이 걸릴 수 있습니다. 후속 배포는 더 빠릅니다.
  • 원격 빌드 -- 기본적으로 컨테이너 이미지는 ACR에서 원격으로 빌드됩니다. 속도가 느려질 수 있지만 로컬로 Docker가 필요하지는 않습니다. 대신 로컬로 빌드하려면 서비스 구성에서 docker.remoteBuild: false 설정합니다azure.yaml.
  • 지역 용량 - 일부 지역에서는 특정 모델 SKU에 대한 용량이 제한될 수 있습니다. 프로비저닝이 일관되게 실패하는 경우 다른 지역을 사용해 보세요.

배포하지만 응답하지 않는 에이전트 수정

증상:azd ai agent invoke이 배포 성공 후 시간이 초과되거나 오류를 반환합니다.

원인 및 수정:

  • 상태 확인 프로브 실패 -- 컨테이너는 포트 8088에서 GET /readiness에 200 상태 코드로 응답해야 합니다. azd ai agent monitor --follow로 로그를 확인합니다.
  • 프로토콜 불일치 -- 서비스에 정의된 프로토콜이 azure.ai.agent 코드가 azure.yaml 구현하는 것과 일치하는지 확인합니다. azure.yaml에서는 responses라고 명시되어 있는데 코드가 invocations만 처리하거나, 그 반대인 경우 요청이 실패합니다.
  • 컨테이너 크래시 -- 시스템 로그에서 다시 시작 이벤트를 azd ai agent monitor --type system확인합니다. 일반적인 원인으로는 처리되지 않은 예외 및 메모리 부족 문제가 있습니다. 필요한 경우 컨테이너 리소스를 늘입니다 azure.yaml .

직접 명령 오류 수정

이러한 오류는 azd ai직접 명령(예: azd ai connection, azd ai toolbox, azd ai routine)을 Foundry 프로젝트를 대상으로 실행할 때 발생합니다.

Foundry 프로젝트 엔드포인트를 확인할 수 없는 문제 수정

증상: 직접 명령이 No Foundry project endpoint resolved. Run azd ai project set to set one, or pass --project-endpoint.와 함께 종료됩니다.

원인: CLI가 지원되는 어떤 소스에서도 Foundry 프로젝트 엔드포인트를 찾을 수 없었습니다: --project-endpoint 플래그, 활성 azd 환경, 전역 구성 또는 FOUNDRY_PROJECT_ENDPOINT 환경 변수.

수정 사항:

  • 엔드포인트를 전역 azd ai project set <endpoint> 구성(azd)에 저장하려면 ~/.azd/config.json을(를) 실행하세요.
  • 각 명령에 --project-endpoint(-p)를 전달합니다: azd ai connection list -p https://my-proj.services.ai.azure.com/api/projects/my-project.
  • 셸 환경에서 FOUNDRY_PROJECT_ENDPOINT을 설정하세요.

전체 해상도 순서 및 각 원본이 이길 때는 azd 프로젝트 컨텍스트 이해를 참조하세요.

기존 리소스에 대한 만들기 실패 수정

증상:azd ai connection create, azd ai toolbox create, azd ai routine create, 또는 azd ai skill create은(는) "이미 존재합니다" 오류와 함께 실패합니다.

원인: 설계상 create는 업서트가 지원되지 않습니다. 기본 실패 모드는 한 개발자가 공유 Foundry 프로젝트에서 다른 개발자의 상태를 자동으로 덮어쓰지 못하도록 합니다.

수정 사항:

  • 다른 이름을 선택하고 다시 실행합니다.
  • --force 명령이 지원하는 경우 create를 전달하여 ARM PUT을 통해 기존 리소스를 대체합니다. 대체는 파괴적입니다. 기존 리소스를 해당 위치에서 그대로 덮어쓰므로, 포털에서 수동으로 편집한 내용이나 메타데이터 또는 자격 증명으로 인해 발생한 차이는 모두 사라집니다. azd ai toolbox create 명령은 --force를 지원하지 않습니다. 기존 도구 상자를 삭제하거나 대신 새 이름을 사용합니다.

connection show 자격 증명 출력 수정

증상:azd ai connection show <name> 는 연결의 이름, 종류, 대상 및 인증 형식을 반환하지만 API 키 또는 자격 증명 값은 반환하지 않습니다.

원인: 기본적으로 자격 증명 값은 반환되지 않습니다. 명시적 --show-credentials 플래그가 필요합니다.

해결 방법:

azd ai connection show tavily-conn --show-credentials

이렇게 하면 데이터 평면 API가 호출되고 Foundry 사용자 또는 이와 동등한 Foundry 프로젝트에 대한 데이터 평면 권한이 필요합니다. 관리 평면 Reader 또는 Contributor 액세스 권한만 있는 경우 403으로 호출이 실패합니다. 프로젝트 소유자에게 데이터 평면 역할을 요청합니다.

에이전트 로그 읽기

에이전트 동작을 검사하는 데 사용합니다 azd ai agent monitor .

# Stream all recent logs
azd ai agent monitor --follow

# View system-level events (container starts, crashes, restarts)
azd ai agent monitor --type system

# Filter to a specific session
azd ai agent monitor --session-id <session-id>

일반적인 로그 패턴은 다음과 같습니다.

로그 메시지 Meaning
Listening on 0.0.0.0:8088 에이전트가 성공적으로 시작되었습니다.
AuthenticationError 자격 증명 또는 RBAC 문제입니다. 관리 ID를 확인합니다.
ModelNotFound 모델 배포 이름이 azure.yaml와 일치하지 않습니다.
시스템 이벤트에서 컨테이너 다시 시작 충돌 루프입니다. 코드 오류를 확인하거나 리소스 제한을 늘입니다.

일상적인 오류 진단

오류를 표시할 호출자가 없기 때문에 루틴이 대화형 agent invoke 호출과 다르게 실패합니다. 루틴은 타이머, 반복 일정, GitHub 이슈 또는 사용자 지정 이벤트에 의해 트리거되는 에이전트 실행입니다. 무슨 일이 있었는지 검사하는 데 사용합니다 azd ai routine run list .

이전 실행 확인

# Recent runs of a routine: trigger time, agent input/output, status, trace link
azd ai routine run list daily-digest

실패로 필터링

# Failed runs only, with an OData filter
azd ai routine run list daily-digest --filter "status eq 'failed'"

창을 넓히거나 좁히려면 --top와 함께 사용하세요.

단일 실행 자세히 보기

# Full detail for the most recent runs as JSON, then look up the run you care about
azd ai routine run list daily-digest --top 5 --output json

JSON 출력에는 입력 페이로드, 에이전트의 응답 및 분산 추적에 대한 딥 링크, 대화형 호출에 대해 표시되는 것과 동일한 추적이 포함됩니다.

루틴을 수동으로 다시 시도

오류를 재현하거나 수정을 테스트해야 하는 경우 다음을 사용하여 주문형 dispatch루틴을 실행합니다.

azd ai routine dispatch daily-digest
azd ai routine dispatch triage-issues --input '{"issue":{"number":42}}'

dispatch 는 비동기적으로 실행되고 디스패치 ID를 출력합니다. azd ai routine run list <name>를 사용하여 결과를 확인합니다.

실패한 루틴 실행 수정

azd ai routine run list는 status: failed를 사용한 실행을 표시합니다. 추적 링크를 따라 모델 오류, 도구 오류 또는 시간 제한과 같은 기본 에이전트 오류를 확인합니다. 에이전트 쪽 수정은 대화형 오류와 동일합니다. 인증 오류 수정 및 에이전트 로그 읽기를 참조하세요.

전혀 실행되지 않는 루틴 수정

azd ai routine run list에서 실행 결과가 전혀 반환되지 않으면, 트리거 자체가 실행되지 않는 것입니다:

  1. 루틴이 활성화되어 있는지 확인합니다 azd ai routine show <name>. 를 찾습니다 enabled: true.
  2. timer 트리거의 경우 --at가 미래 시점에 있고 아직 실행되지 않았는지 확인하세요.
  3. recurring 트리거의 경우 --cron 식이 유효한지, 그리고 --time-zone가 예상한 것인지 확인합니다.
  4. github-issue 트리거의 경우, --connection-id이 정상 연결로 확인되는지, 그리고 GitHub 리포지토리와 --issue-event가 리포지토리에서 보내는 이벤트와 일치하는지 확인합니다.
  5. custom 트리거의 경우 --provider, --event-name 및 --parameters 범위가 공급자가 게시하는 이벤트와 일치하는지 확인합니다.

더 많은 도움말 보기

관련 콘텐츠

  • 에 마지막으로 업데이트됨