Agent Research

에이전트 팀 기반 종합 리서치 스킬. 조사 대상의 성격을 분석하여 전문가 풀에서 최적의 에이전트를 동적으로 선택하고, 교차 검증을 거쳐 분석적 종합 보고서를 산출한다.

실행 모드: 에이전트 팀

전문가 풀

리더는 아래 11개 전문가 중에서 조사 대상에 맞는 2~6개를 선택한다.

프롬프트 템플릿: [references/agent-prompts.md](references/agent-prompts.md)

조사 깊이 선택

워크플로우

Phase 1: 대상 분석 및 팀 설계

이 Phase가 핵심이다. 리더가 조사 대상을 분석하여 최적의 팀을 구성한다.

1단계: 대상 파악

1. 사용자 입력에서 조사 대상, 조사 깊이, 출력 경로, 조사 기간 파악
2. 입력이 파일이면 읽어서 주제 추출, 텍스트면 그대로 사용
3. 핵심 키워드 3~5개 도출

2단계: 조사 차원 식별

조사 대상의 성격에 따라 어떤 차원의 조사가 필요한지 판단한다:

위 표는 가이드라인이다. 리더는 대상의 고유한 특성을 분석하여 자유롭게 조합한다.
사용자가 특정 관점을 명시적으로 요청한 경우 (예: "재무 중심으로", "커뮤니티 반응 위주로") 해당 전문가를 반드시 포함한다.

media 전문가 포함 판단 기준: media를 제외하면 미디어 보도 수집이 다른 에이전트에 분산되어 깊이가 얕아질 수 있다. 다음 경우 media를 반드시 포함한다:

• 대상이 대중적 관심이 높은 이슈 (광범위한 미디어 보도 예상)
• 미디어 논조 분석(호의적/비판적 분류)이 보고서 핵심일 때
• 영상 콘텐츠(YouTube, 팟캐스트) 분석이 필요할 때
• 에이전트 수 예산에 여유가 있을 때 (4개 이상)

media 제외 시: official(공식 보도), community(여론/반응), reputation(평판 보도)이 미디어 영역을 분담. 단, 미디어 보도의 논조 분석 깊이는 떨어짐을 인지.

3단계: 팀 구성 결정

깊이에 따라 에이전트 수를 결정하고, 전문가 풀에서 선택한다:

선택 기준:
1. 조사 대상에 필수적인 차원의 전문가를 먼저 선택
2. 깊이 예산 내에서 선택 차원의 전문가를 추가
3. 전문가 간 시너지를 고려 (예: financial + industry는 상호 보완적)
4. 사용자가 명시적으로 요청한 관점이 있으면 반드시 포함

결정 사항 기록 (리더가 팀 구성 근거를 workspace/teamdesign.md에 기록):

# 팀 설계

## 조사 대상: {target}
## 핵심 키워드: {keywords}
## 조사 깊이: {depth}
## 조사 기간: {time_range}

## 선택된 전문가 ({N}명)

| # | 전문가 | 선택 이유 |
|---|--------|----------|
| 1 | {specialist} | {이 전문가가 필요한 이유} |
| 2 | {specialist} | {이 전문가가 필요한 이유} |
| ... | ... | ... |

## 제외된 전문가 (해당 시)

| 전문가 | 제외 이유 |
|--------|----------|
| {specialist} | {불필요한 이유} |

## 보고서 구조 (예상)

{선택된 전문가에 기반한 보고서 섹션 구조}

4단계: 조사 기간 결정 (사용자 미지정 시 기본 3개월):

Phase 2: 팀 구성 및 병렬 조사 시작

1단계: TeamCreate로 팀 생성 + 팀원 스폰

TeamCreate(
  team_name: "research-{slug}",
  members: [
    {
      name: "{specialist-1}-researcher",
      agent_type: "general-purpose",
      model: "opus",
      prompt: // references/agent-prompts.md 템플릿을 커스터마이즈 (아래 규칙 참조)
    },
    {
      name: "{specialist-2}-researcher",
      agent_type: "general-purpose",
      model: "opus",
      prompt: // ...
    },
    // ... N개 팀원
  ]
)

TeamCreate 호출 시 모든 팀원이 즉시 스폰된다. 별도로 에이전트를 개별 실행할 필요 없다.

2단계: TaskCreate로 작업 등록

TaskCreate(tasks: [
  { title: "{specialist-1} 조사", description: "{조사 지시}", assignee: "{specialist-1}-researcher" },
  { title: "{specialist-2} 조사", description: "{조사 지시}", assignee: "{specialist-2}-researcher" },
  // ... N개 조사 태스크
  { title: "교차 검증", description: "리더가 수행", assignee: "leader", depends_on: ["조사 태스크 전체"] },
  { title: "종합 보고서", description: "리더가 수행", assignee: "leader", depends_on: ["교차 검증"] }
])

팀원들은 자신에게 할당된 태스크를 자동으로 수행하고, 완료 시 TaskUpdate로 상태를 갱신한다.

프롬프트 커스터마이즈 규칙:

• references/agent-prompts.md의 해당 전문가 기본 템플릿을 가져온다
• {target} 변수를 조사 대상으로 치환
• {keywords} 변수를 핵심 키워드로 치환
• {teammate_list}를 실제 선택된 팀원 목록으로 치환
• 교차 공유 트리거를 실제 팀원 구성에 맞게 조정 (없는 팀원에게 공유하도록 되어 있으면 가장 가까운 역할의 팀원으로 대체하거나, 없으면 리더에게 공유)
• 대상 특성에 맞는 추가 조사 지시를 프롬프트에 삽입

Phase 3: 리더 모니터링 및 팀 조율

TeamCreate 후 팀원들은 자율적으로 조사를 수행한다. 리더는 다음을 수행:

모니터링:

• TaskGet으로 전체 태스크 진행 상황 확인
• 팀원이 유휴 상태가 되면 자동 알림 수신
• 특정 팀원이 막혔다는 SendMessage를 보내면 키워드 제안 등으로 지원

개입이 필요한 상황:

• 팀원이 조사 범위 확장을 요청 → 승인/거부 판단
• 상충 정보가 교차 공유됨 → Phase 4에서 해결할 것을 메모
• 팀원이 에러로 중지 → 1회 재시도 또는 나머지 결과로 진행 결정

모든 팀원 공통 행동:

• general-purpose 타입 (WebSearch, WebFetch 필요)
• 교차 공유 의무: 조사 중 다른 팀원에게 유용한 정보 발견 시 SendMessage로 즉시 공유
• 완료 시 TaskUpdate로 태스크 완료 처리 + SendMessage로 리더에 보고

에이전트 간 교차 공유 프로토콜

에이전트들은 조사 중 다음 상황에서 다른 팀원에게 SendMessage로 정보를 공유한다:

SendMessage 형식:

[교차공유] {발견 유형}: {핵심 내용} (출처: {URL})
→ {수신자}에게 권장 행동: {추가 조사 방향}

교차 공유 수신 시 의무:

• 다른 팀원으로부터 교차 공유를 수신한 에이전트는 해당 정보가 자신의 조사 방향에 영향을 미쳤는지 기록해야 한다
• 조사 결과 파일의 ## 교차 공유 로그 섹션에 수신한 공유 + 이에 따른 조사 방향 변경을 기록:

```

```

• 이 기록은 Phase 4 교차 검증에서 에이전트 간 협업 효과를 평가하는 데 사용

Phase 4: 교차 검증 (quick 모드에서는 생략)

모든 에이전트 조사 완료 후, 리더가 직접 수행:

1. N개 조사 파일을 Read로 읽기
2. 상충 정보 식별: 에이전트 간 모순되는 정보를 추출
3. 검증 조사: 상충 정보에 대해 리더가 직접 WebSearch로 추가 검증 (최대 3건)
4. 신뢰도 판정: 각 상충 정보에 대해 어느 쪽이 더 신뢰할 수 있는지 판정하되, 판정 불가 시 양론 병기
5. 검증 결과를 workspace/crossvalidation.md에 기록

상충 정보 해결 우선순위:

1. 1차 소스 (공식 문서, 당사자 발언, 원본 데이터) > 2차 소스 (미디어 보도, 분석)
2. 최신 정보 > 오래된 정보
3. 다수 소스 일치 > 단일 소스
4. 해결 불가 시: 양론 병기 + 각 출처 명시

Phase 5: 갭 분석 및 보충 조사 (quick 모드에서는 생략)

교차 검증 결과를 바탕으로 갭 분석은 standard/deep 모두 필수 수행:

5-1. 갭 분석 (standard/deep 필수)

1. 정보 갭 식별: 보고서 예상 구조의 각 섹션에 대해 다음 체크리스트로 평가:

- [ ] 해당 섹션에 1차 소스가 1개 이상 있는가? - [ ] 핵심 수치/주장이 2개 이상 소스에서 확인되었는가? - [ ] 반대 관점/리스크가 포함되었는가?

1. 갭 목록 작성: 부족한 영역을 심각도 순으로 정렬 (최대 3개)
2. 갭 분석 결과를 workspace/crossvalidation.md에 추가 기록

5-2. 보충 에이전트 실행 (조건부)

• 보충 에이전트는 서브 에이전트로 실행한다 (팀원 간 통신 불필요, 결과 전달만 필요하므로)
• Agent(subagenttype: "general-purpose", model: "opus", runin_background: true) 로 1~2개 실행
• 전문가 풀에서 추가 전문가를 선택하거나, 이미 투입된 전문가의 범위를 좁힌 보충 조사도 가능
• 보충 결과를 workspace/supplement{area}.md에 저장

Phase 6: 종합 보고서 작성

모든 조사 + 검증 + 보충 완료 후:

1. 전체 조사 파일 + 교차 검증 결과를 Read로 읽기
2. 보고서 구조를 동적으로 설계: 선택된 전문가와 수집된 데이터에 기반하여 보고서 섹션을 구성

보고서 구조 동적 생성 규칙

보고서 구조는 고정이 아니라, 다음 원칙에 따라 동적으로 결정한다:

1. 핵심 요약 (Executive Summary) — 항상 포함
2. 개요/배경 — 항상 포함
3. [선택된 전문가별 핵심 섹션] — 각 전문가의 조사 결과에서 도출
4. 교차 분석 — 에이전트 간 교차 발견 패턴
5. 결론 및 전망 — 항상 포함
6. 참고 자료 — 항상 포함
부록 A: 교차 검증 결과
부록 B: 정보 갭 및 한계

전문가별 → 보고서 섹션 매핑 가이드:

리더는 위 매핑을 참고하되, 수집된 데이터의 실제 분량과 중요도에 따라 섹션을 병합하거나 세분화한다.

분석적 종합 프레임워크

보고서의 각 섹션은 다음 3층 구조를 가이드라인으로 따른다:

적용 원칙: 3층 구조는 사고 프레임워크이지 기계적 포맷이 아니다. 각 섹션에 "사실:", "분석:", "인사이트:" 같은 마커를 기계적으로 삽입하지 않는다. 자연스러운 서술 흐름 안에서 팩트→해석→시사점이 유기적으로 흐르도록 한다. 핵심은 팩트만 나열하지 않고, 분석과 인사이트를 반드시 포함하는 것이다.

종합 시 금지 사항:

• 에이전트별 결과를 순서대로 나열하는 것 (단순 concatenation)
• 동일 정보를 다른 표현으로 반복하는 것
• 출처 없는 주장

종합 시 필수 사항:

• 에이전트 간 교차 발견된 패턴을 하이라이트
• 상충 정보는 양쪽 근거와 함께 제시 (교차 검증 결과 반영)
• 각 정보의 신뢰도 등급 표시

정보 신뢰도 등급

모든 주장에 등급을 달 필요 없음. 핵심 주장, 수치 데이터, 논란 사항에만 표시.

1. 보고서 파일명: {대상}_종합보고서.md
2. 보고서 메타 헤더:

# {대상} 종합 조사 보고서

> **작성일**: {date}
> **조사 기간**: {time_range} 이내 ({start_date} ~ {end_date})
> **조사 깊이**: {depth}
> **투입 전문가**: {specialist_list}
> **교차 검증**: 상충 {n}건 중 해결 {m}건

1. TaskUpdate로 보고서 태스크 완료 처리

Phase 7: 정리

1. 모든 에이전트에 SendMessage(type: "shutdown_request") 전송
2. 종료 확인 후 TeamDelete로 팀 정리
3. _workspace/ 디렉토리 보존 (중간 산출물은 삭제하지 않음 — 사후 검증·감사 추적용)
4. 사용자에게 결과 요약 보고:

- 종합 보고서 파일 경로 - 투입된 전문가 목록과 선택 이유 - 조사 커버리지 요약 (각 영역별 수집 정보량) - 교차 검증에서 발견된 상충 사항 수 - 보충 조사 수행 여부 및 영역

데이터 흐름

Phase 1: [리더: 대상 분석 + 팀 설계] → team_design.md

Phase 2: [리더] → TeamCreate(model: opus) + TaskCreate
                          │
                    ┌─────┼─────┐── ... ──┐
                    ↓     ↓     ↓          ↓
              [specialist-1] ... [specialist-N]   ← 팀원 자동 스폰
                    │     │     │          │
Phase 3:            ├──SendMessage──┤  (교차 공유, 리더 모니터링)
                    │     │     │          │
                    ↓     ↓     ↓          ↓
              research_1  ...  research_N        ← TaskUpdate로 완료 보고
                    │     │     │          │
                    └─────┼─────┘── ... ──┘
                          ↓
Phase 4:            [리더: 교차 검증] → cross_validation.md

Phase 5:            [리더: 갭 분석]
                          ↓ (보충 필요 시)
                    [Agent(서브에이전트) 1~2개] → supplement_*.md

Phase 6:            [리더: 동적 보고서 구조 설계 + 분석적 종합]
                          ↓
                    종합보고서.md

Phase 7:            [TeamDelete + 정리]

에러 핸들링

핵심 규칙

• 모든 보고서는 한글로 작성
• 모든 정보에 출처 URL 포함 필수
• 팀 설계가 최우선: Phase 1에서 대상 분석과 전문가 선택에 충분한 시간을 투자
• 모든 에이전트는 model: "opus"로 실행
• 선택된 에이전트는 TeamCreate 한 번으로 동시에 스폰
• 교차 공유 의무: 에이전트는 다른 팀원에게 유용한 발견을 SendMessage로 공유
• 종합 보고서는 분석적 종합 — 단순 취합 금지, 3층 구조(사실/분석/인사이트) 적용
• 보고서 구조는 동적 — 고정 템플릿이 아니라 투입된 전문가와 수집 데이터에 맞게 설계
• 핵심 주장에 신뢰도 등급 표시
• 사용자 입력이 파일(스크립트, 기사 등)인 경우 내용을 분석하여 검색 키워드 자동 도출
• 최신성 우선: 조사 기간 내의 최신 정보를 우선적으로 수집
• 각 에이전트는 검색 시 현재 연도를 포함한 쿼리 사용

테스트 시나리오

시나리오 1: 기술 제품 조사 (standard)

1. 입력: "Claude Code 조사해줘"
2. Phase 1: 대상=AI 개발 도구, 깊이=standard, 키워드=[Claude Code, Anthropic, AI coding, CLI]
3. 팀 설계: official(공식 문서) + technical(기술 분석) + community(개발자 반응) + industry(경쟁 환경) = 4명
4. Phase 2: 팀 구성, 6개 태스크
5. Phase 3: 4개 에이전트 병렬 실행
6. Phase 4: 교차 검증
7. Phase 6: 보고서 구조 = 개요 → 기능·아키텍처 → 개발자 반응 → 경쟁 환경(Cursor, Copilot) → 전망
8. 결과: ClaudeCode종합보고서.md

시나리오 2: 인물 조사 (deep)

1. 입력: "Jensen Huang 심층 조사해줘"
2. Phase 1: 대상=기업인, 깊이=deep, 키워드=[Jensen Huang, NVIDIA, GPU, AI]
3. 팀 설계: career(경력) + works(업적) + media(인터뷰/발언) + financial(NVIDIA 재무) + reputation(평판) + industry(반도체 산업) = 6명
4. Phase 3: 6개 에이전트 병렬 실행
5. Phase 5: 보충 조사 — 최근 GTC 키노트 관련 추가 조사
6. Phase 6: 보고서 구조 = 인물 개요 → 경력 → NVIDIA 경영 성과 → 재무·주가 → 미디어·발언 → 반도체 산업 내 위상 → 평판·평가 → 전망

시나리오 3: 사회 이슈 조사 (quick)

1. 입력: "EU AI Act 간단히 조사해줘"
2. Phase 1: 대상=규제 정책, 깊이=quick, 키워드=[EU AI Act, AI regulation, 인공지능 규제]
3. 팀 설계: policy(규제 분석) + official(공식 문서) = 2명
4. Phase 3: 2개 에이전트 병렬 실행
5. Phase 4~5: 생략 (quick)
6. Phase 6: 보고서 구조 = 개요 → 주요 조항 → 영향 분석 → 시사점

에러 흐름

1. Phase 3에서 financial-researcher가 에러로 중지
2. 리더가 유휴 알림 수신, 1회 재시도
3. 재시도 실패 → 나머지 결과로 Phase 4 진행
4. 보고서의 재무 관련 섹션에 "데이터 미수집 — industry 에이전트의 부분 데이터로 대체" 명시
5. 사용자에게 부분 완료 알림