163 lines
22 KiB
Markdown
163 lines
22 KiB
Markdown
---
|
||
status: historical-snapshot
|
||
applies-to-version: "registry 62 roles / 26 families / 11 lenses (작성 시점 스냅샷)"
|
||
superseded-by: "현재 정본 registry 73 roles / 28 families / 12 lenses — org-os/00-role-registry/*"
|
||
exclude-from: [must-read, default-search]
|
||
note: "이 문서의 62/26/11 등 수치는 2026-07-07 시점 스냅샷이다. 현재 수치·구조는 org-os 레지스트리를 정본으로 한다(finding #20)."
|
||
---
|
||
|
||
# Org OS 하네스 vs. 업계 멀티에이전트 오케스트레이션 — 설계 효율성 비교
|
||
|
||
> 작성: 2026-07-07 · 방법: WebSearch + WebFetch(공식 문서/논문/1차 엔지니어링 블로그) · 날조 없음, 모든 판정은 아래 출처에 접지.
|
||
|
||
## BLUF (Bottom Line Up Front)
|
||
|
||
- **판정: 사용자 하네스의 골격은 업계 정설과 정합하며, 두 개의 가장 중요한 실무 교훈을 명시적으로 코드화했다.** (1) Anthropic의 "멀티에이전트는 병렬 리서치/분석엔 이기고 코딩엔 진다" → `collaboration-default`의 **fan-out(판단·설계·분석) vs collapse(코드·실행)** 분기로 반영. (2) Cognition의 "요약 말고 전체 트레이스를 공유하라" → `synthesis-rehydration`(하위 `.report.yaml` 전문 재적재)으로 반영. 대부분의 프레임워크(MetaGPT/ChatDev/CrewAI)는 이 둘을 구분하지 않는다.
|
||
- **주된 실무 리스크는 토큰·지연 비용이다.** Anthropic 관측상 멀티에이전트는 채팅 대비 **~15배 토큰**을 쓰고 토큰량이 성능분산의 **80%**를 설명한다. 사용자 하네스는 fan-out + 전문 재적재(rehydration)를 기본 경로에 두므로, `mode×tier` 게이팅과 렌즈 상한이 규율대로 강제되지 않으면 비용이 폭증한다.
|
||
- **다양성을 headcount(62역할)가 아니라 11 렌즈로 고정한 것은 옳은 선택**이다 — Anthropic이 경고한 "단순 질의에 subagent 50개 spawn" 낭비를 구조적으로 억제한다.
|
||
|
||
---
|
||
|
||
## 조사한 하네스 (each target · approach · well / limitation · 사용자와 비교)
|
||
|
||
### 1. Anthropic — "How we built our multi-agent research system" (1차 엔지니어링 블로그)
|
||
- **approach**: Orchestrator-worker. Lead(Opus)가 질의를 분해→subagent(Sonnet)를 병렬 spawn, 각자 **독립 context window**로 탐색 후 lead가 종합.
|
||
- **well**: 병렬화·context 압축·다양한 툴 인터페이싱이 필요한 리서치에서 단일 Opus 대비 **+90.2%**. 복잡 질의 리서치 시간 최대 **90% 단축**. subagent 각자 context로 자연 압축.
|
||
- **limitation**: 채팅 대비 **~15배 토큰**(agent 단독은 4배). 토큰량만으로 성능분산 80% 설명 → 고가치 과제에만 경제성. "**대부분 코딩 과제는 리서치보다 병렬화 가능 부분이 적다**"며 코딩·강결합 과제엔 부적합. lead 소폭 변경이 subagent 거동을 예측불가하게 바꾸는 창발성.
|
||
- **comparison-to-user**: **가장 직접적 원형.** 사용자의 Orchestrator+fan-out worker+각자 clean context 구조가 동일 패턴. 사용자는 여기에 (a) 코드=collapse로 Anthropic의 코딩 경고를 명시 반영, (b) tier로 고가치 과제만 heavy fan-out 하도록 경제성 게이트를 추가 — Anthropic이 글로만 언급한 것을 정책으로 강제.
|
||
|
||
### 2. Cognition (Devin) — "Don't Build Multi-Agents" (1차 엔지니어링 블로그, 반론 진영)
|
||
- **approach**: **단일 스레드 선형 에이전트 권장.** context가 연속. 초과 시 히스토리를 핵심 결정으로 압축(하되 "제대로 하기 어렵다").
|
||
- **well**: 원칙 2개가 날카롭다 — (1) "개별 메시지가 아니라 **전체 agent trace를 공유**하라", (2) "행동은 암묵적 결정을 내포하고, 충돌하는 결정은 나쁜 결과를 낳는다". Flappy Bird 예: 한 subagent는 마리오 배경, 다른 subagent는 안 맞는 새 → 사전 미명시 가정 충돌.
|
||
- **limitation**: 병렬성·확장성을 포기. 대규모·초장기 과제의 cross-agent context 전달 문제는 미해결로 남김. 2025 현재 "협업 다중 에이전트는 취약한 시스템만 낳는다"는 강한 입장(장기적으론 낙관).
|
||
- **comparison-to-user**: **사용자 하네스가 명시적으로 인용·방어한 상대.** `handoff-context-policy`에 "요약만으로 축소하지 않는다(Cognition)", `synthesis-rehydration`에 "요약은 관점을 유실 → 원본 전문 재적재"로 정확히 대응. 다만 Cognition의 핵심 우려(병렬 워커가 미명시 가정에서 발산)는 **단일 fan-out phase 내부**에서 여전히 살아있고, 사용자는 이를 cascade(상위 Packet을 하위 입력으로 전달)로 완화한다.
|
||
|
||
### 3. MetaGPT (ICLR 2024 oral, arXiv 2308.00352)
|
||
- **approach**: 인간 SOP(표준운영절차)를 프롬프트 시퀀스로 인코딩한 **역할기반 assembly-line**. 역할 접두 프롬프트 + 구조화 중간산출물.
|
||
- **well**: SOP·구조화 산출물이 "LLM 단순 체이닝의 연쇄 환각"을 억제. 역할별 도메인지식 주입.
|
||
- **limitation**: 워터폴형 고정 파이프라인이라 유연성 낮음. 역할이 코딩까지 fan-out → 코드 강결합엔 Anthropic/Cognition 경고 적용.
|
||
- **comparison-to-user**: 역할기반·구조화 산출물 강제(=사용자의 `.report.yaml`+E0~E5 증거등급)는 유사. 차이: 사용자는 코드 단계를 **collapse**로 접어 assembly-line을 코드에까지 적용하지 않음(더 방어적).
|
||
|
||
### 4. ChatDev (ACL 2024, arXiv 2307.07924)
|
||
- **approach**: 워터폴(설계→코딩→테스트→문서)을 **chat-chain**으로. 각 노드=서브태스크, instructor/assistant **2-에이전트 대화** + communicative dehallucination.
|
||
- **well**: 단계·2자 대화로 구조화. 요청-확인 패턴으로 환각 완화.
|
||
- **limitation**: 2자 대화 체인이라 관점 다양성·병렬성 제한. 고정 워터폴.
|
||
- **comparison-to-user**: 사용자의 cascade(결정→설계→세부→구현)와 위상 유사. 그러나 사용자는 각 phase에서 **N-way fan-out(다관점)** 후 종합 — ChatDev의 2자 대화보다 다양성 우선. dehallucination ≈ 사용자의 evidence-grade/독립 검증.
|
||
|
||
### 5. AutoGen / AG2 (Microsoft, 오픈소스)
|
||
- **approach**: **대화 주도(conversation-first).** 에이전트들이 메시지로 자유 협상, 인간 참여·코드 실행 루프.
|
||
- **well**: 유연·범용, human-in-the-loop·코드 실행에 강함.
|
||
- **limitation**: 자유 대화라 **워크플로 예측불가**·수렴 불안정. 거버넌스/감사 배선은 별도 구축 필요.
|
||
- **comparison-to-user**: 정반대 철학. 사용자는 자유 대화 대신 **파일기반·계약기반(context-package, report-return-contract)**으로 예측가능성·감사성을 택함. 유연성↓ 대신 재현·감사·거버넌스↑.
|
||
|
||
### 6. CrewAI (오픈소스)
|
||
- **approach**: **role/goal/backstory**를 가진 crew, sequential/hierarchical **task pipeline**.
|
||
- **well**: 역할 분해가 직관적, 비엔지니어도 이해. 팀형 구조화 과제에 적합.
|
||
- **limitation**: 역할 정의는 있으나 렌즈 다양성·증거등급·DRAI 결정권 같은 거버넌스는 없음. 종합·dissent 보존 개념 부재.
|
||
- **comparison-to-user**: 사용자 하네스는 CrewAI의 role-pipeline을 **거버넌스로 감싼** 상위집합 — DRAI(결정권), lens(다양성 바닥), evidence(접지), human-gate(위험 승인)가 추가.
|
||
|
||
### 7. LangGraph (LangChain)
|
||
- **approach**: 노드=에이전트/툴, 엣지=허용 전이인 **그래프/유한상태기계(FSM)**. 중앙 공유 state + checkpoint + guard/approval 노드.
|
||
- **well**: 제어흐름을 개발자가 설계(flow engineering)해 **장기거동 디버그·정렬 용이**. 조직 제약을 그래프 노드로 삽입.
|
||
- **limitation**: 그래프를 사람이 설계해야 함(구축비용). 공유 state 모델이라 관점 격리(발산)는 별도 설계.
|
||
- **comparison-to-user**: 사용자 하네스는 LangGraph의 "명시적 제어흐름·승인노드"를 **YAML 상태머신**(state-transition-rules, acceptance-gates)으로 구현. 차이: LangGraph는 공유 state 중심, 사용자는 발산 시 **격리 context**(관점 오염 방지)로 갈라짐 — 발산/수렴을 분리한 게 더 정교.
|
||
|
||
### 8. OpenAI Swarm → Agents SDK
|
||
- **approach**: **routines(지시+툴) + handoffs(다른 에이전트를 반환하는 함수)**. Swarm은 stateless·경량 교육용, Agents SDK가 guardrail·tracing·handoff를 프로덕션화.
|
||
- **well**: 극단적 단순함·경량. handoff로 제어 이양이 명료.
|
||
- **limitation**: stateless·경량이라 거버넌스·증거·다관점 종합은 사용자가 구축. 오케스트레이션 로직이 얇음.
|
||
- **comparison-to-user**: 사용자의 cross-group-edges(선언된 handoff 채널)가 Swarm handoff와 개념 유사하나, 사용자는 방향별 **handoff-artifact 계약**·미전달 시 Blocked까지 규정 — 훨씬 두꺼운 계약.
|
||
|
||
### 9. Microsoft Magentic-One (2024.11, arXiv/MSR)
|
||
- **approach**: Orchestrator + 특화 에이전트 4(WebSurfer/FileSurfer/Coder/Terminal). **Task Ledger(사실·계획) + Progress Ledger(진척·자기반성) 듀얼 원장.**
|
||
- **well**: 듀얼 원장으로 계획·진척을 분리 추적, 교착 시 재계획. 범용 웹/파일 과제.
|
||
- **limitation**: 소수 특화 에이전트라 다관점 종합·거버넌스는 범위 밖. 오케스트레이터 창발성 리스크(Anthropic과 공통).
|
||
- **comparison-to-user**: **직접 차용.** 사용자 `/plan-wave`의 "Magentic 듀얼 원장(plan.md + progress.yaml)"이 바로 이 Task/Progress Ledger 패턴. 사용자는 여기에 렌즈 다양성·DRAI·증거등급을 얹어 조직 운영으로 확장.
|
||
|
||
### 10. AWS Bedrock 멀티에이전트 협업 (supervisor 패턴)
|
||
- **approach**: **Supervisor + collaborator** 특화 에이전트. routing mode(단순→직접 라우팅) vs full orchestration(복잡→분해·병렬·종합). conversation-history 공유 옵션.
|
||
- **well**: 관리형·관측성(AgentCore Observability). "책임 중복 최소화"를 공식 베스트프랙티스로 명시. routing/full 이원화로 경량-중량 경로 분리.
|
||
- **limitation**: 벤더 종속. 관점 다양성·dissent·증거등급 개념 없음(도메인 라우팅 중심).
|
||
- **comparison-to-user**: routing vs full = 사용자의 **light vs heavy tier / converge vs divergent**와 동형. AWS의 "책임 중복 최소화"는 사용자의 `capability-families invocation-triggers/exclusions`가 대응 — 다만 62→26 taxonomy가 커서 중복 리스크는 사용자 쪽이 더 크다(권고 참조).
|
||
|
||
### 11. 12-Factor Agents (HumanLayer)
|
||
- **approach**: 프레임워크가 아닌 **원칙 12개**. Factor 3 "own your context window"가 핵심, 그 외 own your prompts, unify execution+business state, contact humans with tool calls, own your control flow 등.
|
||
- **well**: "context window를 명시적으로 소유·구성하라", "중간 데이터는 구조화 포맷으로", 40~60% 구간의 **'dumb zone'**(회상력 저하) 경고. 프로덕션 신뢰성 지향.
|
||
- **limitation**: 원칙만 제공, 오케스트레이션 구현체는 없음.
|
||
- **comparison-to-user**: 사용자 하네스는 이 원칙들의 **구현 사례**에 가깝다 — `.report.yaml` 구조화 산출물(own context/structured), `re-hydration-control`(forbid raw-logs, structured-summary만 pass), DRAI human-gate(contact humans), state-machine(own control flow), evidence-grade(unify state). 정합성 높음.
|
||
|
||
---
|
||
|
||
## 사용자 하네스와 비교 (요약 매트릭스)
|
||
|
||
| 축 | 사용자 Org OS | 가장 가까운 업계 | 사용자의 차별점 |
|
||
|---|---|---|---|
|
||
| 상위 구조 | Orchestrator + fan-out worker | Anthropic, Magentic-One, AWS supervisor | 코드=collapse 분기로 코딩 경고 반영 |
|
||
| 코드 vs 판단 | fan-out(판단/설계/분석) / collapse(코드/실행) | Anthropic(코딩엔 멀티에이전트 비권장) | **정책으로 강제**(대부분 프레임워크는 미구분) |
|
||
| context 공유 | synthesis-rehydration(전문 재적재) | Cognition(full trace 공유) | Cognition 우려를 명시 인용·방어 |
|
||
| 진척 추적 | plan.md + progress.yaml 듀얼 원장 | Magentic-One Task/Progress Ledger | 직접 차용 + 거버넌스 확장 |
|
||
| 다양성 | 11 렌즈(불가침 바닥), headcount와 분리 | (업계에 뚜렷한 대응 없음) | **고유 강점** — 토큰 낭비 억제 장치 |
|
||
| 결정권/승인 | DRAI + human-gate(heavy) | AWS/12-factor(human-in-loop) | 문서유형별 RACI로 세분화 |
|
||
| 소통 매체 | 파일기반 `.report.yaml`→MD | LangGraph checkpoint/AWS observability | 감사·재현성 우선(지연 감수) |
|
||
| 경량/중량 경로 | mode×tier(light/standard/heavy) | AWS routing vs full | 2직교축으로 더 세분 |
|
||
| 증거 접지 | E0~E5 + hook 강제 자기채점 금지 | MetaGPT/ChatDev(dehallucination) | 아티팩트 검증까지 강제 |
|
||
|
||
---
|
||
|
||
## 효율성 평가 (Verdict)
|
||
|
||
### 강점 (근거 접지)
|
||
1. **fan-out/collapse 분기는 업계 최선의 판단과 정합.** Anthropic은 "대부분 코딩 과제는 리서치보다 병렬화 가능 부분이 적다"며 코딩·강결합에 멀티에이전트를 비권장했고, Cognition은 코딩에 단일 스레드를 권장했다. 사용자 하네스는 **판단·설계·분석·수익=fan-out, 코드·실행=collapse**로 정확히 이 선을 그었다. MetaGPT/ChatDev/CrewAI는 코드까지 다중 역할을 굴려 이 구분이 없다 → 사용자 설계가 더 방어적이고 토큰 효율적이다.
|
||
2. **synthesis-rehydration이 Cognition의 1순위 비판을 정면으로 방어.** "요약이 아니라 하위 `.report.yaml` 전문을 읽는다"는 규칙은 Cognition의 "individual messages가 아니라 full agent trace를 공유하라"와 동일 처방이다. 대부분 프레임워크가 종합 단계에서 요약으로 관점을 유실하는 지점을, 사용자는 명시적으로 막았다.
|
||
3. **다양성을 렌즈(11)로 고정한 것이 토큰 폭증의 구조적 방파제.** Anthropic은 "단순 질의에 subagent 50개 spawn"을 대표적 실패로 지목했다. 사용자는 다양성 바닥을 role 62가 아니라 lens 11로 두고, 같은 렌즈 중복은 collapse(`family-collapse`), 공유 렌즈는 primary carrier 1개만 대변(`shared-lens-selection`)한다 → spawn 폭발을 스펙 차원에서 억제. 이것은 조사 대상 중 **가장 독창적인 효율 장치**다.
|
||
4. **경제성 게이트(mode×tier)가 Anthropic의 "고가치 과제에만 멀티에이전트"를 정책화.** `mode==converge && tier==light → 멤버 분리 생략, 단일 종합`은 저위험 과제에서 15배 토큰 경로를 회피한다. AWS의 routing-vs-full 이원화와 동형이되 2직교축으로 더 세밀.
|
||
5. **파일기반·계약기반 소통은 "org OS"(내구·감사) 목적에 정확히 맞는 트레이드오프.** 12-factor의 own-your-context/structured-output, LangGraph의 checkpoint, AWS observability와 같은 계열. 인메모리 대화(AutoGen)보다 느리지만 재현·감사·거버넌스를 얻는다. 지연에 민감한 코드 루프는 어차피 collapse로 접히므로 손해가 상쇄된다.
|
||
|
||
### 약점 / 리스크 (근거 접지)
|
||
1. **토큰·지연 비용이 최대 리스크.** Anthropic: 멀티에이전트 ~15배 토큰, 토큰량이 성능분산 80% 설명. 사용자 하네스는 fan-out(DECIDE 7 C-level + DESIGN 8 family) **위에 다시** synthesis-rehydration(전문 재적재)을 쌓는다 → 종합 지점 context가 특히 무겁다. tier 게이팅과 렌즈 상한이 **규율대로 강제**되지 않으면(현재 일부는 정책 텍스트로만 존재) 기본 converge 경로에서 비용이 통제 불능이 될 수 있다.
|
||
2. **단일 fan-out phase 내부의 발산 리스크는 잔존.** Cognition의 Flappy Bird(미명시 가정 충돌)는 phase 간 cascade(상위 Packet→하위 입력)로 완화되지만, **한 phase 안에서 8개 family가 clean context로 병렬 시작**하면 여전히 서로 모르는 가정으로 발산할 수 있다. 재조정 부담이 전적으로 종합자(synthesizer)에게 몰린다.
|
||
3. **종합자(synthesizer)가 품질 병목이자 미검증 지점.** 스펙은 "dissent 삭제 금지"를 명시하나, 종합 결과가 실제로 dissent를 보존했는지 검증하는 강제기가 fan-out 종합 단계엔 약하다. Anthropic도 종합·창발을 실패원으로 지목했다.
|
||
4. **Orchestrator 창발성·프롬프트 취약성.** Anthropic: "lead의 소폭 변경이 subagent 거동을 예측불가하게 바꾼다." 사용자 하네스는 모든 fan-out을 Orchestrator가 구동하므로 그 프롬프트/스펙이 취약 레버. `gen_agents.py`가 워커를 스펙에서 생성해 워커 drift는 막지만, Orchestrator 자체 프롬프트는 단일 실패점.
|
||
5. **62→26 taxonomy의 책임 중복 리스크.** AWS 공식 베스트프랙티스는 "collaborator 책임 중복 최소화"를 강조한다. 26 family + 33 워커는 라우팅 중복·경계 모호 위험이 업계 사례보다 크다. `invocation-triggers/exclusions`가 있으나, family 수가 많을수록 유지비와 오라우팅 확률이 오른다.
|
||
|
||
### 종합 판정
|
||
사용자 하네스는 **"멀티에이전트를 아무데나 쓰지 말고, 병렬 이득이 있는 판단/리서치에만 쓰고, 종합 시 관점을 요약으로 죽이지 말라"**는 2025~2026 업계 합의를 스펙으로 성문화한, 이례적으로 자기인식이 높은 설계다. 골격의 효율성 근거는 탄탄하다. 실패는 구조가 아니라 **운영 규율**에서 온다 — 즉 tier 게이트·렌즈 상한·dissent 보존 검증을 강제기로 실제 배선했는가가 15배 토큰 비용의 통제 여부를 가른다.
|
||
|
||
---
|
||
|
||
## 개선 권고 (근거 포함)
|
||
|
||
1. **wave당 토큰·비용을 계측하고 tier별 fan-out 예산을 강제하라.** *(근거: Anthropic — 멀티에이전트 15배 토큰, 토큰량이 성능분산 80% 설명)* `agent-operating-kpi.yaml`에 tokens/wave·cost-per-decision KPI를 추가하고, tier=light/standard에서 fan-out 폭(활성 워커 수)에 하드 상한을 두어 예산 초과 시 자동으로 collapse/단일 종합으로 강등. 지금의 "정책 텍스트"를 hook 강제로 승격.
|
||
|
||
2. **standard tier의 fan-out 폭을 family가 아니라 lens로 상한하라.** *(근거: Anthropic — 단순 질의에 50 subagent spawn 실패 사례; 사용자 자신의 `shared-lens-selection`)* "공유 렌즈는 primary carrier 1개만 대변, heavy일 때만 sub-angle 분화"를 scorecard/Orchestrator에서 **기본 강제**로 만들고, heavy에서만 carrier 확장. 이미 스펙에 있는 원칙을 실행 배선으로 끌어올리는 것.
|
||
|
||
3. **fan-out phase 내부에 '공유 제약 pre-brief'를 주입해 발산을 억제하라.** *(근거: Cognition — 행동은 암묵적 결정을 내포, 미명시 가정 충돌이 Flappy Bird 실패를 낳음)* cascade가 phase 간에는 Packet을 전달하지만, **한 phase 내 병렬 워커들에게도** 승인된 ExecutiveDecisionPacket + 공통 설계 제약 헤더를 context-package에 동봉해, 워커들이 서로 모르는 가정에서 발산하지 않게 하라. (발산 다양성은 유지하되 '충돌하는 결정'만 사전 정렬.)
|
||
|
||
4. **종합자에 dissent-보존 검증 강제기를 붙여라.** *(근거: 스펙의 "dissent 삭제 금지" must-not + Anthropic이 종합을 실패원으로 지목)* 종합 `.report.yaml`에 `dissent`/`conflicts` 필드 존재와 하위 보고서 참조 링크를 `validate_report` hook이 검사하도록 확장. synthesis-rehydration이 실제로 관점을 보존했는지 아티팩트로 검증(자기채점 금지 원칙과 정합).
|
||
|
||
5. **초장기 wave용 명시적 compaction 에이전트를 두되 결정 재적재 경로에서는 배제하라.** *(근거: 12-factor Factor 3 'own your context'·'dumb zone' 40~60%; Cognition·Anthropic 모두 context 초과를 최난제로 지목)* fan-out 워커의 **원시 트레이스**가 context를 넘길 때만 핵심 결정으로 압축하는 compaction 단계를 형식화하고, 결정/종합 지점의 `synthesis-rehydration`(구조화 `.report.yaml` 전문)은 압축 대상에서 제외해 관점 유실을 막아라. (raw-log는 이미 forbid — 이를 '압축 후 통과' 파이프라인으로 명문화.)
|
||
|
||
---
|
||
|
||
## 출처 (URL 목록)
|
||
|
||
**1차 (직접 fetch/공식):**
|
||
- Anthropic, "How we built our multi-agent research system" — https://www.anthropic.com/engineering/multi-agent-research-system
|
||
- Cognition, "Don't Build Multi-Agents" — https://cognition.com/blog/dont-build-multi-agents
|
||
- Cognition, "Multi-Agents: What's Actually Working" — https://cognition.com/blog/multi-agents-working
|
||
- MetaGPT (ICLR 2024 oral), arXiv 2308.00352 — https://arxiv.org/abs/2308.00352
|
||
- ChatDev (ACL 2024), arXiv 2307.07924 — https://arxiv.org/abs/2307.07924 · ACL: https://aclanthology.org/2024.acl-long.810/
|
||
- Magentic-One, Microsoft Research — https://www.microsoft.com/en-us/research/articles/magentic-one-a-generalist-multi-agent-system-for-solving-complex-tasks/ · PDF: https://www.microsoft.com/en-us/research/wp-content/uploads/2024/11/MagenticOne.pdf
|
||
- Magentic-One (AutoGen 문서) — https://microsoft.github.io/autogen/stable//user-guide/agentchat-user-guide/magentic-one.html
|
||
- OpenAI Swarm (GitHub) — https://github.com/openai/swarm
|
||
- AWS Bedrock 멀티에이전트 협업 (공식 문서) — https://docs.aws.amazon.com/bedrock/latest/userguide/agents-multi-agent-collaboration.html
|
||
- AWS, "Introducing multi-agent collaboration for Amazon Bedrock" — https://aws.amazon.com/blogs/aws/introducing-multi-agent-collaboration-capability-for-amazon-bedrock/
|
||
- 12-Factor Agents (HumanLayer, GitHub) — https://github.com/humanlayer/12-factor-agents · Factor 3: https://github.com/humanlayer/12-factor-agents/blob/main/content/factor-03-own-your-context-window.md
|
||
|
||
**2차 (해설/비교):**
|
||
- Anthropic 아키텍처 해설 (ByteByteGo) — https://blog.bytebytego.com/p/how-anthropic-built-a-multi-agent
|
||
- Jason Liu, "Why Cognition does not use multi-agent systems" — https://jxnl.co/writing/2025/09/11/why-cognition-does-not-use-multi-agent-systems/
|
||
- CrewAI vs AutoGen (DataCamp) — https://www.datacamp.com/tutorial/crewai-vs-langgraph-vs-autogen
|
||
- LangGraph 멀티에이전트 오케스트레이션 (AWS ML 블로그) — https://aws.amazon.com/blogs/machine-learning/build-multi-agent-systems-with-langgraph-and-amazon-bedrock/
|
||
- OpenAI Swarm 가이드 (Galileo) — https://galileo.ai/blog/openai-swarm-framework-multi-agents
|