히스토리

• GitLab 18.2에서 이름이 Workflow에서 Agent Platform으로 변경되었습니다.

GitLab Duo Agent Platform을 실행하기 위한 로컬 개발 환경 구성 방법입니다.

사전 요구 사항#

• GitLab Ultimate 라이선스
• Vertex 액세스: GDK는 기본적으로 Vertex에 호스팅된 Anthropic을 사용하므로 GCP의 ai-enablement-dev-69497ba7 프로젝트에 대한 액세스가 필요합니다. 이 프로젝트 액세스는 GitLab의 모든 엔지니어가 사용할 수 있습니다.
  • 사정상 Vertex 액세스를 얻을 수 없다면 GitLab Duo Agent Platform Service에서 DUO_WORKFLOW__VERTEX_PROJECT_ID를 해제하고 ANTHROPIC_API_KEY에 일반 Anthropic API 키를 설정합니다
• GDK 설정 스크립트가 활성화해 주는 각종 설정과 기능 플래그

Agent Platform 로컬 개발 환경 설정#

Agent Platform은 다음 네 가지 서비스로 구성됩니다.

1. GitLab 인스턴스
2. GitLab AI Gateway의 일부인 GitLab Duo Agent Platform Service
3. GitLab Duo CLI (gitlab-lsp의 TypeScript 실행기이며 사전 컴파일된 바이너리로 배포됩니다)
4. GitLab Duo Agent Platform Webview

백엔드 컴포넌트 개발 환경 설정#

로컬 버전의 GitLab과 GitLab Duo Agent Platform Service를 실행하려면 GitLab Development Kit(GDK)로 GitLab Duo Agent Platform을 설정합니다.

이 구성은 공개 배포된 VS Code 확장 또는 GitLab Duo CLI와 그대로 함께 사용할 수 있습니다.

웹 UI에서 Agentic GitLab Duo Chat 테스트#

로컬 GitLab 인스턴스의 웹 UI에서 Agentic GitLab Duo Chat을 테스트하려면 다음 추가 설정 단계를 진행합니다.

1. GDK에서 NGINX를 활성화합니다. 루프백 인터페이스와 HTTPS는 필요하지 않으며, 기본 NGINX 설정만 있으면 됩니다.
2. http://gdk.test:8080으로 GDK에 접속합니다. GDK는 3000 포트에서도 계속 사용할 수 있지만, 8080 포트로 접속하면 NGINX를 거쳐 애플리케이션에 연결되며 웹에서 Agentic GitLab Duo Chat 이 동작하려면 이 경로가 필요합니다. 3000 포트로 애플리케이션에 접속해 Agentic GitLab Duo Chat을 사용하면 다음 오류 메시지가 나타납니다. Error: Unable to connect to workflow service. Please try again..

프론트엔드 컴포넌트 개발 환경 설정#

IDE에서 Agent Platform UI 변경 사항을 테스트할 때는 Agent Platform의 백엔드 컴포넌트를 설정할 필요가 없습니다.

로컬에서 확인해야 하는 GitLab Duo Agent Platform UI 변경 작업을 한다면 UI를 로컬에서 빌드해야 합니다. 아직 릴리스되지 않은 버전의 UI를 사용하려는 경우에도 로컬 빌드가 필요합니다.

IDE에서 GitLab Duo Agent Platform UI 로컬 개발을 시작하려면 Language Server 프로젝트의 GitLab Duo Agent Platform README 파일을 참고합니다.

개발 설정#

다음 설정은 VS Code의 사용자 설정에서 각각 켤 수 있습니다.

뷰 유형 변경#

GitLab Duo Agent Platform을 전체 화면 대신 사이드 패널로 사용합니다. 퍼블릭 베타에서는 이 방식이 기본값이 됩니다.

"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 job으로 전파되지 않습니다. :duo_workflow_id는 Gitlab::ApplicationContext::WEB_ONLY_KEYS에 속하므로 백그라운드 job은 값을 물려받지 않습니다. job에서 이 값을 쓰려면 명시적인 인수로 전달합니다.

플로 평가#

평가 실행#

로컬 구성을 평가하려면 GitLab Duo Agent Platform Tests 리포지터리를 참고합니다.

결과 비교#

평가를 마치고 LangSmith에서 실험 ID를 받았다면, GitLab Duo Agent Platform Notebooks 리포지터리의 이 노트북으로 결과를 비교합니다.