에이전트 채팅룸
N명의 에이전트(기본값 3)를 시뮬레이션된 공유 대화에 소환합니다. 각 에이전트는 전체 채팅 기록을 읽고 이전 발언을 바탕으로 구축, 도전 또는 개선합니다. 사용자(조정자)는 PM 역할을 하며 — 라운드를 관리하고, 토론을 읽고, 최종 결과물을 추출합니다.
이것이 작동하는 이유: 순차적 핸드오프는 맥락을 잃습니다 — 두 번째 모델은 첫 번째 모델이 왜 그런 결정을 내렸는지 알지 못합니다. 공유 대화는 추론 체인을 보존하고 진정한 논쟁을 가능하게 합니다. 에이전트 A가 "이건 큐가 필요해"라고 말하고 에이전트 B가 "간단한 루프면 충분해"라고 말할 때, 그 불일치는 어느 한 에이전트의 자신만만한 단독 답변보다 더 가치 있습니다. 에이전트는 가정에 도전하고, 오류를 찾아내며, 다양한 추론 경로를 종합합니다.
실행
1. 요청 분석
사용자의 메시지에서 다음을 추출합니다:
- 논쟁할 문제/질문
- 에이전트 수 N — 기본값 3. 사용자가 재정의 가능("5명의 에이전트가 논쟁하게 하세요")
- 라운드 수 R — 기본값 3. 사용자가 재정의 가능("5라운드 동안 논쟁하세요")
- 에이전트 역할(선택 사항) — 사용자가 역할을 지정할 수 있음("아키텍트, 보안 엔지니어, 프론트엔드 개발자가 이 문제를 논쟁하게 하세요"). 지정되지 않은 경우 다양한 기본 역할을 할당합니다.
문제가 모호하면 소환 전에 사용자에게 명확히 해달라고 요청하세요.
2. 에이전트 역할 할당
각 에이전트는 생산적인 불일치를 최대화하기 위해 뚜렷한 관점을 받습니다. 사용자가 역할을 지정하지 않은 경우 문제 도메인에 따라 다음 기본 역할에서 선택하세요:
소프트웨어 엔지니어링:
- 아키텍트 — 시스템, 인터페이스, 확장성, 장기 유지보수성을 고려합니다.
- 실용주의자 — 빠른 출시, 최소한의 복잡성, "충분히 좋은" 솔루션에 최적화합니다.
- 비평가 — 엣지 케이스, 실패 모드, 보안 허점, 명시되지 않은 가정을 찾습니다.
제품/디자인:
- 사용자 옹호자 — UX, 단순성, 사용자 만족에 최적화합니다.
- 비즈니스 전략가 — 수익, 성장, 경쟁 우위에 최적화합니다.
- 엔지니어 — 토론을 기술적 실현 가능성과 비용에 기반합니다.
전략/결정:
- 낙관론자 — 기회, 상승 가능성, 행동할 이유를 봅니다.
- 회의론자 — 위험, 하락 가능성, 기다릴 이유를 봅니다.
- 종합자 — 중간 경로를 찾고, 두 관점을 통합합니다.
N > 3인 경우, 기존 역할과 생산적인 긴장을 만드는 역할을 추가하세요.
3. 채팅 파일 초기화
active/chatroom/chat.json을 다음 초기 구조로 생성합니다:
{
"problem": "{문제 설명}",
"context": "{관련 맥락, 코드, 제약 조건}",
"agents": [
{"name": "에이전트 A", "role": "{역할}", "framing": "{역할 설명}"},
{"name": "에이전트 B", "role": "{역할}", "framing": "{역할 설명}"},
{"name": "에이전트 C", "role": "{역할}", "framing": "{역할 설명}"}
],
"rounds": [],
"final_output": null
}
4. 논쟁 라운드 실행
각 라운드(1부터 R까지)에 대해 모든 N 에이전트를 병렬로 소환합니다. 각 에이전트는 전체 채팅 기록을 읽고 기여합니다.
에이전트 소환 설정:
subagent_type: "general-purpose"model: "sonnet"(기본값 — 사용자가 더 깊은 추론을 위해 opus로 재정의 가능)mode: "bypassPermissions"
라운드 절차:
라운드 1 — 시작 입장: 각 에이전트가 문제에 대한 초기 입장을 밝힙니다.
에이전트 프롬프트:
당신은 {역할}: {역할_설명}
문제:
{problem}
맥락:
{context}
이것은 다중 에이전트 논쟁의 1라운드입니다. 이 문제에 대한 초기 입장을 밝히세요. 구체적이고 명확하게 — 모호한 원칙이 아닌 실제 솔루션을 제안하세요. 명확한 입장을 취하세요.
다른 에이전트들이 다음 라운드에서 당신의 입장에 도전할 것이므로, 추론을 명시적으로 만드세요.
다음 형식으로 응답하세요:
입장: [한 문장으로 된 입장]
추론: [상세한 주장 — 3-5개의 핵심 요점]
제안: [구체적인 권장 사항]
우려사항: [접근 방식에서 잘못될 수 있는 점]
응답을 직접 작성하세요 — 파일에 쓰지 마세요.
라운드 2 이상 — 논쟁: 각 에이전트는 이전 모든 응답을 읽고 응답합니다.
에이전트 프롬프트:
당신은 {역할}: {역할_설명}
문제:
{problem}
이전 논의:
{모든 이전 라운드 항목, "에이전트 X (역할): 응답" 형식으로}
이것은 다중 에이전트 논쟁의 {N}라운드입니다. 이전 논의를 주의 깊게 읽으세요.
당신의 임무:
1. 당신의 입장에 대한 가장 강력한 반론에 응답하세요
2. 다른 에이전트와 동의하는 지점을 식별하세요(좋은 지점 인정)
3. 여전히 동의하지 않는 지점과 그 이유를 식별하세요
4. 지금까지의 논의를 바탕으로 제안을 개선하세요
이전 입장을 단순히 반복하지 마세요. 다른 사람들이 말한 내용에 대해 논쟁하세요. 더 나은 주장을 제시했다면 마음을 바꾸세요.
다음 형식으로 응답하세요:
동의: [다른 에이전트가 옳게 짚은 점]
반대: [여전히 다른 점과 그 이유]
개선된 제안: [업데이트된 권장 사항]
확신도: [1-10, 개선된 입장에 대한 확신 정도]
응답을 직접 작성하세요 — 파일에 쓰지 마세요.
각 라운드 후:
- 모든 에이전트 응답 수집
chat.json의rounds배열에 추가:
{
"round": 1,
"entries": [
{"agent": "에이전트 A", "role": "아키텍트", "response": "..."},
{"agent": "에이전트 B", "role": "실용주의자", "response": "..."},
{"agent": "에이전트 C", "role": "비평가", "response": "..."}
]
}
- 수렴 여부 확인: 모든 에이전트가 동의하면(확신도 8+, 제안 일치), 조기 중단 — 더 이상의 라운드 불필요
5. 최종 결과 종합
마지막 라운드 후, 사용자(조정자)는 전체 논쟁을 읽고 종합을 생성합니다. 다른 에이전트를 소환하지 마세요 — 직접 수행합니다.
분석:
- 에이전트가 어디에서 수렴했는가? — 이는 높은 신뢰도의 결론입니다
- 어디에서 분열된 상태로 남았는가? — 이는 사용자가 결정해야 할 진정한 트레이드오프입니다
- 제기되었지만 해결되지 않은 우려 사항은? — 이는 모니터링해야 할 위험입니다
- 에이전트가 마음을 바꾼 적이 있는가? — 마음의 변화는 강력한 신호입니다
6. 최종 보고서 작성
final_output으로 active/chatroom/chat.json을 업데이트하고, 사람이 읽을 수 있는 요약을 active/chatroom/chatroom_report.md에 작성합니다:
# 에이전트 채팅룸 보고서
**문제**: {problem}
**에이전트**: {N} | **라운드**: {R}
**날짜**: {date}
## 참가자
| 에이전트 | 역할 | 최종 확신도 |
|----------|------|------------|
| 에이전트 A | {role} | {confidence}/10 |
| 에이전트 B | {role} | {confidence}/10 |
| 에이전트 C | {role} | {confidence}/10 |
## 합의
{모든 에이전트가 최종 라운드까지 동의한 내용}
## 주요 이견
{에이전트들이 분열된 상태로 남은 부분 — 양측을 공정하게 제시}
## 권장 조치
{조정자로서의 종합 — 모든 관점을 고려한 최선의 진행 방향}
## 해결되지 않은 위험
{논쟁 중 제기되었지만 완전히 해결되지 않은 우려 사항}
## 논쟁 하이라이트
{가장 흥미로운 교환 — 마음이 바뀌거나 강력한 반론이 나온 부분}
## 전체 대화록
{chat.json 링크 또는 주요 교환 내용 인라인}
7. 결과 전달
사용자에게 제시:
- 논쟁 결과의 한 문단 요약
- 권장 조치(논쟁을 바탕으로 한 조정자로서의 결정)
- 가장 날카로운 이견(사용자 판단이 필요한 부분)
- 보고서 및 chat.json 파일 경로
설정
| 매개변수 | 기본값 | 설명 |
|---|---|---|
| N | 3 | 채팅룸의 에이전트 수 |
| R | 3 | 논쟁 라운드 수 |
| model | sonnet | 각 에이전트의 모델 |
| roles | auto | 에이전트 역할(자동 할당 또는 사용자 지정) |
사용자 재정의 가능: "opus 에이전트 5명이 4라운드 동안 논쟁하게 하세요" 또는 "아키텍트와 주니어 개발자 간의 논쟁".
비용 고려 사항
- 3 sonnet 에이전트 x 3라운드 = 9회 에이전트 호출 (~$0.30-0.50)
- 3 opus 에이전트 x 3라운드 = 9회 에이전트 호출 (~$3-5)
- 5 에이전트 x 5라운드 = 25회 호출 — opus 사용 시 비용 증가
- 기본값은 sonnet. 사용자가 명시적으로 요청하거나 문제가 깊은 기술적 추론을 필요로 하는 경우에만 opus를 사용하세요.
- 조기 수렴으로 비용 절감 — 모든 라운드 완료 전에 에이전트가 동의하면 중단하세요.
엣지 케이스
- N < 2: 사용자에게 경고 — 채팅룸에는 최소 2명의 에이전트가 필요합니다. 최소 2.
- 에이전트가 즉시 모두 동의: 라운드 1 이후 중단. 만장일치 합의 보고. 이는 유효한(그리고 저렴한) 결과입니다.
- 에이전트 교착 상태: R 라운드 후 수렴 없음, 교착 상태를 정직하게 보고. 이는 지배적인 답변이 없는 진정한 판단 호출이라는 발견입니다.
- 에이전트가 주제에서 벗어남: 해당 응답을 종합에서 제외하고 유효 에이전트 수를 기록.
- 기존 채팅룸 파일:
active/chatroom/에 기존 파일이 있는지 확인. 묻지 않고 덮어쓰기(임시 논쟁 산출물이며 영구 데이터가 아님). - 사용자가 사용자 정의 역할 지정: 정확히 지정한 대로 사용. 요청하지 않는 한 추가 역할을 추가하지 마세요.
출력 파일
| 파일 | 설명 |
|---|---|
active/chatroom/chat.json | 전체 구조화된 논쟁 대화록 |
active/chatroom/chatroom_report.md | 사람이 읽을 수 있는 종합 보고서 |
이전 보고서는 덮어씁니다 — 이는 임시 논쟁 도구이며 아카이브가 아닙니다.