FIM One의 DAG 실행 엔진은 의도적인 절제로 설계되었습니다. 멀티 에이전트 프레임워크에서 일반적인 여러 패턴을 평가했으며 의도적으로 제외했습니다. 이 페이지는 그러한 결정과 그 뒤의 추론을 문서화합니다.Documentation Index
Fetch the complete documentation index at: https://docs.fim.ai/llms.txt
Use this file to discover all available pages before exploring further.
핸드오프 — 필요 없음
패턴: 에이전트 간의 명시적 작업 핸드오프. 한 에이전트가 작업을 완료하고 다음 에이전트에 제어권을 넘기는 경우. 제외 이유: DAG 선형 체인은 이미 순차적 작업 핸드오프를 자연스럽게 다룹니다. 스텝 B가 스텝 A에 의존할 때, 실행기는 A가 완료될 때까지 대기한 후 의존성 메커니즘을 통해 A의 결과를 B의 컨텍스트에 전달합니다. 이는 구조적으로 핸드오프와 동등하지만, 별도의 추상화 계층이 필요하지 않습니다. 명시적 핸드오프 프로토콜을 추가하면 스텝 의존성이 이미 제공하는 기능이 중복되며, 추가적인 표현력도 없습니다.역흐름 — 필요 없음
패턴: 다운스트림 단계에서 결과를 업스트림 단계로 다시 피드백하여 재평가하는 것 (역전파라고도 함). 제외 이유: PlanAnalyzer 재계획 루프가 이미 이 사용 사례를 다룹니다. 모든 단계가 완료된 후, 분석기는 원래 목표가 달성되었는지 평가합니다. 달성되지 않았다면 (그리고 신뢰도가 중지 임계값 아래라면), 이전 라운드의 결과에서 얻은 컨텍스트를 포함하여 전체 재계획을 트리거합니다 — 무엇이 잘못되었는지와 무엇을 배웠는지 포함. 이는 단계별 역흐름보다 더 거친 입도이지만 더 견고한 접근 방식입니다. 단계별 역흐름은 디버깅하기 어렵고 무한 사이클로 이어질 수 있는 복잡한 피드백 루프를 만듭니다. 재계획 루프는 더 깔끔한 실행 모델로 동일한 수정 효과를 달성합니다: 계획, 실행, 평가, 필요하면 재계획.Teams (에이전트 간 통신) — 불필요
패턴: 실행 중에 서로 통신하는 여러 전문화된 에이전트, 하위 작업 소유권 협상, 또는 공유 상태에 대한 협업. 제외 이유: DAG 종속성 체인은 데이터 종속성 작업에 충분합니다. 단계 C가 단계 A와 단계 B의 결과를 모두 필요로 할 때, 종속성 엣지가 이를 직접 표현합니다. 단계 C는 A와 B의 출력을 컨텍스트에서 받습니다 — 에이전트 간 메시징 프로토콜이 필요하지 않습니다. DAG 모델은 에이전트 간 통신보다 더 간단하고 예측 가능합니다. 에이전트는 협상할 필요가 없습니다. 플래너가 실행 구조를 미리 결정하고, 실행기가 종속성 해결을 통해 데이터 흐름을 강제합니다. 이는 다중 에이전트 메시징이 도입하는 조정 오버헤드와 비결정성을 피합니다.agent_hint / role_hint — 필요하지 않음
패턴: 각 단계를 처리할 에이전트 또는 페르소나의 유형을 명시적으로 지정하는 힌트 (예: “연구원 에이전트 사용” 또는 “코더 에이전트 사용”). 제외 이유: 기존의 세 가지 필드 조합이 이미 충분한 지침을 제공합니다:task— 단계가 달성해야 할 작업의 자연어 설명입니다. 잘 작성된 작업은 필요한 전문성을 암묵적으로 나타냅니다.tool_hint— 단계가 사용해야 할 도구를 제안합니다 (예:web_search,python_exec). 이는 모호한 역할 레이블보다 실행 방식을 더 정확하게 제한합니다.model_hint— 단계가 빠른 모델 또는 추론 모델 계층을 사용할지 여부를 제어하며, 이는 가장 영향력 있는 실행 결정입니다.
agent_hint 또는 role_hint를 추가하면 이 세 필드와 중복되며, 플래너 LLM이 올바르게 처리해야 할 또 다른 구성 축을 도입하게 됩니다. 힌트 표면을 작게 유지하면 계획 오류를 줄일 수 있습니다.
깊은 다중 에이전트 오케스트레이션 — 전략적 연기
위의 “Teams” 제외는 엔지니어링 논거입니다: DAG 엣지는 이미 데이터 의존성을 표현합니다. 이 섹션은 전략적 논거를 추가합니다: 모델 능력이 오케스트레이션 복잡성을 흡수하는 산업 동향입니다.모델이 오케스트레이션 레이어를 대체하는 이유
다중 에이전트 계층 구조는 모델의 한계를 우회하기 위한 임시방편으로 등장했습니다. 하나의 모델이 복잡한 작업을 처리할 수 없으면 전문화된 에이전트들 간에 분해했습니다. 최신 모델의 각 세대는 이러한 논리를 약화시킵니다:| 모델 기능 | 대체되는 것 |
|---|---|
| 확장된 컨텍스트 윈도우 (200K → 1M 토큰) | 제한에 맞추기 위해 에이전트 간에 컨텍스트 분할 |
| 확장된 사고 / 체인-오브-소트 | 명시적 Planner → Executor 에이전트 파이프라인 |
| 네이티브 에이전트 루프 (Claude Code, Codex) | 프레임워크 오케스트레이션 다중 단계 실행 |
| 네이티브 다중 에이전트 프로토콜 (Google A2A, OpenAI Swarm) | 프레임워크 수준 에이전트 조정 |
깊이의 비용
모델이 능력이 부족하더라도 깊은 에이전트 계층 구조는 누적 비용을 초래합니다:- 토큰 곱셈 — 각 중첩 수준은 시스템 프롬프트와 컨텍스트를 다시 주입합니다. 3단계 깊이에서 총 토큰 지출은 단일 에이전트 접근 방식의 5-10배가 될 수 있습니다.
- 레이턴시 누적 — 각 수준은 완전한 LLM 왕복입니다. 사용자는 가장 느린 체인을 기다립니다.
- 정보 손실 압축 — 위임된 에이전트는 원본 데이터가 아닌 요약을 반환합니다. 각 수준마다 충실도가 손실됩니다.
- 디버그 불투명성 — “어느 수준에서 작업을 잘못 이해했는가?”는 깊이 > 2에서 진단하기 거의 불가능합니다.
FIM One의 위치
CallAgentTool을 통한 1단계 위임이 최적의 지점입니다: “나는 일반가이지만, 이 부분 작업은 SQL 전문가가 필요하다.” 이는 더 깊은 계층의 복합 비용 없이 실제 위임 요구사항의 대다수를 충족합니다.
깊은 다중 에이전트 오케스트레이션은 무기한 연기되었습니다 — 구축이 어렵기 때문이 아니라, 최첨단 모델의 궤적이 이것이 불필요해질 것임을 시사하기 때문입니다. FIM One의 가치는 도구 공급 계층(Connectors, MCP, Governance)에 있으며, 모델이 빠르게 내재화하고 있는 오케스트레이션 깊이에 있지 않습니다.