히스토리

• 이름 변경: GitLab 18.2에서 Workflow에서 Agent Platform으로 변경.

GitLab Duo 에이전트 플랫폼을 실행하기 위한 로컬 개발 환경 설정 방법입니다.

사전 요건#

• GitLab Ultimate 라이선스
• Vertex 접근: GDK가 기본적으로 Vertex에서 호스팅된 Anthropic을 사용하기 때문에 GCP의 ai-enablement-dev-69497ba7 프로젝트에 접근이 필요합니다. 이 프로젝트에 대한 접근은 GitLab의 모든 엔지니어에게 제공되어야 합니다.
  • 어떤 이유로 Vertex 접근이 없는 경우, GitLab Duo 에이전트 플랫폼 서비스에서 DUO_WORKFLOW__VERTEX_PROJECT_ID를 해제하고 ANTHROPIC_API_KEY를 일반 Anthropic API 키로 설정해야 합니다
• GDK 설정 스크립트로 활성화되는 다양한 설정 및 피처 플래그

에이전트 플랫폼 로컬 개발 설정#

에이전트 플랫폼은 네 가지 별도 서비스로 구성됩니다:

1. GitLab 인스턴스
2. GitLab Duo 에이전트 플랫폼 서비스 - GitLab AI Gateway의 일부
3. GitLab Duo CLI (gitlab-lsp의 Node/TypeScript 실행기)
4. GitLab Duo 에이전트 플랫폼 웹뷰

백엔드 구성 요소 개발 설정#

GitLab 개발 키트(GDK)로 GitLab Duo 에이전트 플랫폼 설정하여 GitLab 및 GitLab Duo 에이전트 플랫폼 서비스의 로컬 버전을 실행해야 합니다.

이 설정은 공개적으로 사용 가능한 VS Code 확장 버전 또는 GitLab Duo CLI와 함께 그대로 사용할 수 있습니다.

웹 UI에서 에이전틱 GitLab Duo Chat 테스트#

로컬 GitLab 인스턴스의 웹 UI에서 에이전틱 GitLab Duo Chat을 테스트하려면 다음 추가 설정 단계를 따르세요:

1. GDK에 NGINX 활성화. 루프백 인터페이스와 HTTPS는 필요하지 않으며, 기본 NGINX 구성만 필요합니다.
2. http://gdk.test:8080에서 GDK에 접근합니다. GDK는 여전히 포트 3000에서 사용 가능하지만 포트 8080에서 접근하면 NGINX를 통해 애플리케이션에 접근하며, 이는 웹에서 에이전틱 GitLab Duo Chat이 작동하는 데 필요합니다. 포트 3000에서 애플리케이션에 접근하여 에이전틱 GitLab Duo Chat을 시도하면 오류 메시지가 표시됩니다: Error: Unable to connect to workflow service. Please try again.

프론트엔드 구성 요소 개발 설정#

IDE에서 에이전트 플랫폼 UI의 변경 사항을 테스트하기 위해 에이전트 플랫폼의 백엔드 구성 요소를 설정할 필요는 없습니다.

GitLab Duo 에이전트 플랫폼 UI 변경 사항을 로컬에서 확인해야 하거나 아직 릴리스되지 않은 UI 버전을 사용하려면 로컬 빌드가 필요합니다.

IDE에서 GitLab Duo 에이전트 플랫폼 UI의 로컬 개발을 시작하려면 Language Server 프로젝트의 GitLab Duo 에이전트 플랫폼 README 파일을 참조하세요.

개발 설정#

이러한 설정들은 VS Code의 사용자 설정에서 활성화할 수 있습니다.

뷰 유형 변경#

GitLab Duo 에이전트 플랫폼을 전체 화면 대신 사이드패널로 활성화합니다. 이것이 공개 베타의 기본값이 될 것입니다.

"gitlab.featureFlags.duoWorkflowPanel": true,

도구 승인#

터미널 명령 실행과 같이 승인이 필요한 도구에 사용자가 접근할 수 있도록 허용합니다.

"gitlab.duo.workflow.toolApproval": true

워크플로 세션으로 API 요청 추적#

GitLab Duo 워크플로에서 시작된 요청은 X-Gitlab-Duo-Workflow-Id 헤더를 전달합니다. Rails 미들웨어 Gitlab::Middleware::DuoWorkflowId가 이 헤더를 Gitlab::ApplicationContext로 읽어 들입니다. 그러면 워크플로 ID를 요청 기간 동안 애플리케이션 코드와 구조화된 요청 로그에서 사용할 수 있습니다.

두 가지 경로에서 헤더가 자동으로 설정됩니다:

• 도구 API 호출. 에이전트가 GitLab API에 도달하는 도구를 호출하면, Workhorse가 호출을 프록시하고 헤더를 첨부합니다.

• 에이전트를 실행하는 러너의 glab 호출. 러너가 DUO_WORKFLOW_WORKFLOW_ID를 내보내고, glab CLI가 자신이 수행하는 모든 API 호출에 헤더를 설정합니다.

애플리케이션 코드에서 값을 읽습니다:

Gitlab::ApplicationContext.current_context_attribute(:duo_workflow_id)

구조화된 로그에서 Grape는 이 값을 meta.duo_workflow_id로 노출하고(api_json.log 및 graphql_json.log), Lograge는 최상위 수준에서 duo_workflow_id로 노출합니다(development_json.log 및 production_json.log).

워크플로 ID로 로그 필터링#

세션이 생성한 모든 요청을 확인하려면 API 및 GraphQL 로그를 meta.duo_workflow_id로 필터링하거나 Lograge 로그를 duo_workflow_id로 필터링합니다. 오작동하는 세션을 디버깅할 때 이 방법을 사용하세요. 예를 들면 다음과 같습니다:

jq 'select(."meta.duo_workflow_id" == "<workflow_id>")' log/api_json.log

세션이 생성한 리소스를 세션에 연결#

리소스를 생성하거나 수정하는 서비스 내부에서 워크플로 ID를 읽고, 이를 리소스와 함께 저장합니다. 그러면 리소스를 이를 생성한 세션으로 다시 추적할 수 있습니다.

class CreateService
  def execute
    issue = Issue.create!(params)

    if workflow_id = Gitlab::ApplicationContext.current_context_attribute(:duo_workflow_id)
      # Persist workflow_id alongside the issue.
    end

    issue
  end
end

이 값은 요청 범위이며 Sidekiq 작업으로 전파되지 않습니다. :duo_workflow_id는 Gitlab::ApplicationContext::WEB_ONLY_KEYS에 속하므로 백그라운드 작업은 이를 상속하지 않습니다. 작업에서 값을 사용하려면 명시적 인수로 전달하세요.

플로우 평가#

평가 실행#

로컬 설정을 평가하려면 GitLab Duo 에이전트 플랫폼 테스트 저장소를 참조하세요.

결과 비교#

평가를 완료하고 LangSmith에서 실험 ID가 생성되면, GitLab Duo 에이전트 플랫폼 노트북 저장소의 이 노트북을 사용하여 결과를 비교합니다.