이 게시물은 자동으로 번역되었습니다. 원본 버전은 여기를 클릭하세요.

코딩 에이전트를 위한 미션 컨트롤: VS Code의 통합 경험

하나의 코딩 어시스턴트는 이해하기 쉽습니다. 여러 에이전트가 다양한 장소에서 작동하는 경우는 그렇지 않습니다.

한 에이전트는 VS Code에서 로컬로 실행됩니다. 또 다른 에이전트는 클라우드에서 GitHub 이슈에 대해 작업합니다. CLI 에이전트는 터미널에 있습니다. 타사 코딩 에이전트는 다른 세션 모델과 다른 제한이 있을 수 있습니다. 공유된 보기 없이 개발자는 작업 감독보다 작업 추적에 더 많은 시간을 소비합니다.

VS Code의 통합 에이전트 경험은 Agent Sessions으로 이 조율 문제를 해결합니다. 에이전트를 실행하고, 상태를 확인하고, 대화를 열고, 계획이 변경될 때 개입할 수 있는 한 곳입니다.

이것은 또 다른 에이전트를 추가하는 것보다는 여러 에이전트를 관리 가능하게 만드는 것에 관한 것입니다.

다양한 작업 유형을 위한 하나의 보기

출처 기사에서는 네 명의 서로 다른 참여자를 설명합니다. 로컬 GitHub Copilot, 클라우드의 Copilot Coding Agent, GitHub Copilot CLI, 그리고 적격 Copilot 구독자를 위한 OpenAI Codex입니다.

그들은 서로 다른 강점을 가지고 있습니다.

로컬 에이전트는 현재 작업 공간을 검사하고 빠른 변경을 수행할 수 있습니다.
클라우드 코딩 에이전트는 이슈에서 비동기적으로 작업하고 풀 요청을 열 수 있습니다.
CLI 에이전트는 터미널 중심 워크플로우 및 운영 명령에 적합합니다.
다른 제공자는 다른 모델이나 추론 스타일을 제공할 수 있습니다.

Agent Sessions은 이러한 작업에 공통의 홈을 제공합니다. 무엇이 실행 중인지, 무엇을 하고 있는지, 그리고 대화를 계속할 위치를 볼 수 있습니다.

이 가시성은 자율 작업이 조율을 제거하지 않기 때문에 중요합니다. 오히려 조율을 일급 엔지니어링 작업으로 만듭니다.

중단은 워크플로우의 일부입니다

출처는 간단한 관찰을 합니다. “프롬프트를 보낸 후 중요한 것을 깜빡했다는 것을 깨닫는 것이 일반적입니다.” 이전에는 선택 사항이 대기 또는 취소인 경우가 많았습니다. 채팅 편집기를 사용하면 활성 세션을 열고 에이전트가 작업하는 동안 정보를 추가할 수 있습니다.

이것은 실제 협업에 더 가깝습니다. 요구 사항이 변경됩니다. 테스트가 가정을 드러냅니다. 검토자가 API가 역호환성을 유지해야 함을 알아챕니다. 유용한 에이전트는 결코 수정이 필요 없는 것이 아니라, 전체 작업을 잃지 않고 수정을 흡수할 수 있는 것입니다.

.NET 작업의 경우 중단은 다음과 같이 간단할 수 있습니다.

Keep the existing public route unchanged. Add the new behavior behind the application service,
use the existing ProblemDetails convention, and add a test for the old response shape.

명령은 저장소가 이미 더 큰 컨텍스트를 포함하고 있기 때문에 간단합니다. 세션은 전체 시스템을 다시 설명하는 것이 아니라 방향을 수정하는 곳입니다.

사용자 정의 에이전트는 팀 습관을 역할로 변환합니다

VS Code는 또한 Plan과 같은 전문화된 에이전트를 소개합니다. 즉시 구현하는 대신 계획 에이전트는 구현 사양을 생성하기 전에 범위, 구성 요소, 라이브러리 및 제약 조건에 대해 질문합니다.

이 패턴은 기본 제공 에이전트를 넘어서 유용합니다. 팀은 초점이 맞춰진 역할을 정의할 수 있습니다.

Research는 증거를 수집하고 짧은 결정 기록을 작성합니다.
Review는 저장소 규칙에 대한 변경을 확인합니다.
Testing은 누락된 경우를 식별하고 테스트 계획을 제안합니다.
Architecture는 파일을 수정하지 않고 옵션을 비교합니다.

작은 사용자 정의 에이전트 정의는 다음과 같이 보일 수 있습니다.

type: agent
name: plan
description: "Refines vague requests into clear implementation specs"
prompt: |
  Ask about scope, constraints, existing patterns, and edge cases.
  Produce a concise specification before any implementation begins.

유용한 부분은 YAML이 아닙니다. 책임의 명시적 분리입니다. 계획 에이전트는 조용히 프로덕션 코드를 편집하면 안 됩니다. 검토 에이전트는 평가해야 할 설계를 다시 작성하면 안 됩니다.

서브에이전트는 컨텍스트 충돌을 줄입니다

긴 대화는 관련 없는 컨텍스트를 축적합니다. 서브에이전트는 제한된 연구 작업을 위한 격리된 작업 공간을 제공한 다음 결과를 주 세션으로 반환합니다.

이것은 다음과 같은 질문에 적합합니다.

Analyze the API project and recommend an authentication strategy.
Return trade-offs and a decision record. Do not edit files.

주 에이전트는 구현에 집중하고 연구 에이전트는 더 좁은 질문을 처리합니다. 동일한 원칙이 팀에 적용됩니다. 명확한 위임은 겹치는 권한을 가진 여러 에이전트를 시작하는 것보다 더 나은 결과를 생성합니다.

주의: 더 많은 에이전트는 더 많은 조율을 의미합니다

Agent Sessions는 활동을 표시할 수 있지만 충돌하는 소유권을 해결할 수 없습니다. 같은 영역을 편집하는 두 에이전트는 여전히 병합 문제를 만들 수 있습니다. 클라우드 에이전트와 로컬 에이전트는 호환되지 않는 가정을 할 수 있습니다. 사용자 정의 에이전트는 다른 에이전트가 무시하는 권장 사항을 생성할 수 있습니다.

경계를 설정하십시오.

한 에이전트가 주어진 분기의 구현을 소유합니다.
연구 에이전트는 추적되지 않은 편집이 아닌 결과물을 반환합니다.
풀 요청은 검토 경계로 남습니다.
에이전트 이름 및 프롬프트는 변경할 수 있는 것을 명시합니다.
세션 출력은 중요한 결정을 설명할 때 보존됩니다.

제 생각

멀티에이전트 미래는 채팅 창의 대기열이 아닙니다. 역할, 핸드오프 및 책임이 있는 작은 팀입니다.

Agent Sessions이 가치 있는 이유는 그 현실을 인정하기 때문입니다. 편집기, 터미널 및 클라우드 전체에서 이미 발생하고 있는 작업에 대한 제어 표면을 개발자에게 제공합니다. 다음 생산성 향상은 더 많은 에이전트를 갖는 것보다는 그들의 경계를 명확하게 만드는 것에서 나올 것입니다.

.NET 팀의 경우 하나의 계획 에이전트와 하나의 구현 에이전트로 시작합니다. 계획 출력을 이슈 또는 풀 요청 사양으로 사용한 다음 구현 에이전트가 해당 경계 내에서 작동하도록 합니다. 더 많은 역할을 추가하기 전에 재작업을 측정하십시오.

최고의 미션 컨트롤은 여전히 소유권을 명확하게 만드는 것입니다.