콘텐츠로 이동

용어집

문서를 읽다 낯선 단어가 나오면 여기서 먼저 의미를 잡고 돌아가세요. 각 항목의 링크는 더 자세한 설명이 있는 문서로 이어집니다.

용어한 줄 정의자세히
Registry모델·프롬프트·가드레일·MCP를 ID로 보관·관리하는 중앙 서버. 에이전트는 ID만 참조하고, 메타데이터는 런타임에 로드합니다.Registry 기반 에이전트
에이전트 (agent)A2A 요청을 받아 LLM·툴·가드레일·메모리를 조합해 응답하는 기본 실행 단위. 단일 에이전트로 끝나면 llamon agent, 여러 단계를 엮으면 floworchestrator를 씁니다.Registry 기반 에이전트
플로우 (flow)여러 노드(에이전트·비즈니스 로직·HTTP)를 한 호출 안에서 연결한 정적 그래프. flow-seq·flow-parallel·flow-route·flow-http 네 가지 템플릿이 있습니다.상태와 헬퍼
노드 (node)플로우 그래프의 한 단계. Registry 에이전트 노드, Python 비즈니스 로직 노드, HTTP 노드 등이 있습니다.플로우 템플릿
오케스트레이터 (orchestrator)여러 자식 에이전트를 contextId 기준으로 묶어 선택·실행·재개·최종 응답을 관리하고, 턴 사이에 업무 상태를 누적하는 워크플로우.오케스트레이터 시작하기
AgenticProgramTOML에 선언한 model·prompt·tool allowlist·호출 상한 안에서만 동작하는 bounded controller loop. 앱은 내부 executor를 직접 조립하지 않습니다.Agentic 워크플로우
rules-first / fullAgenticProgram의 적용 범위. rules-first는 OKF 고정 경로를 먼저 실행하고 나머지만 controller가 판단하며, full은 첫 의미 판단부터 controller가 맡습니다.Agentic 워크플로우
result transitionread-only 도구가 직접 반환한 exact-schema 결과에 따라 controller 재호출을 complete하거나 continue하는 순서형 규칙. FinalResponse와 output guardrail은 건너뛰지 않습니다.Agentic 결과 정책
deterministic run_turn(ctx)controller LLM 없이 호출 순서·병렬 실행·트랜잭션을 애플리케이션 코드에 명시하고, @managed_run_turn이 최종 emit을 소유하는 고급 workflow.Deterministic 워크플로우
WorkflowStateorchestrator의 턴 간 상태. remember는 덮어쓰고, reduce는 누적하며, get으로 읽습니다. flow의 한 호출 상태와 달리 턴을 넘어 유지됩니다.멀티턴 상태와 재개
state_backendorchestrator의 WorkflowState 저장소. in_memory는 개발·데모용, postgres는 영속·멀티 워커 운영용입니다.orchestrator.toml 설정
AgentCallResult / combine_resultsctx.call 자식 결과(.text · .data · .data_parts · .files)와, 여러 결과를 한 최종 응답으로 합치는 SDK 헬퍼. combine_resultsdata_parts를 이어붙이고 text·files는 마지막 결과를 따릅니다.ctx API 레퍼런스
DataPart fold/compact오케스트레이터에서 직전 입력 DataPart와 이번 ctx.data를 합치거나, OCR·debug 같은 큰 데이터를 줄이는 순수 헬퍼. fold_data는 명시적으로 사용할 때만 동작하며 현재 입력은 항상 보존합니다.OrchestratorContext API
deciderorchestrator의 run_turn 안에서 쓰는 작은 LLM 판단 유틸. 스코프 분류·중복 판정·모호 해소처럼 흐름 중간의 의미 판단만 맡고, 응답 생성은 하지 않습니다.Agentic 워크플로우
Studio노드·그래프·스킬·설정을 시각적으로 편집하는 UI. nodes.py·graph.py·agent_card.py·config.py 파일을 읽고 쓰며, LLM/MCP를 직접 호출하지 않습니다.Studio AI와 OKF
RuntimeAdapter모델 출력을 검증·정규화output_text/output_data를 보장하는 어댑터. 구조화 출력 에이전트(agent-structured)의 핵심.RuntimeAdapter 고급
Runtime EvaluatorAgent·Flow·Orchestrator의 completed 출력에 기본 또는 custom evaluator를 적용해 0~1 Numeric score와 평가 observation을 남기는 opt-in 실행 경계.Runtime Evaluator Framework
VerificationEvaluatorAdapterORCH evaluator에 들어오는 request DataPart 하나와 나가는 decision DataPart 하나를 모델 호출 전후에 fail-closed로 검증하는 opt-in RuntimeAdapter.결과 검증 루프
InputContracts인바운드 A2A DataPart/FilePart예상 스키마·형태에 일치하는 것만 골라내는 입력 계약.입력 선별
guardrail입력 또는 출력이 정책을 어기는지 검사하는 경계 보호 장치. Registry 기반 가드레일, regex 규칙, prompt 기반 judge를 조합할 수 있습니다.에이전트 구성
확정 MCP 호출 (deterministic_tool)LLM 판단 전에 규칙으로 특정 MCP tool을 확정 호출하는 데코레이터. 비용·지연 절감과 결정적 동작에 사용.확정 MCP 호출
skip_llmprimary LLM 로드·호출을 우회하는 LLMConfig 옵션. RuntimeAdapter·가드레일·passthrough로 응답을 조립하는 에이전트에 적합합니다.LLM 호출 우회
upstream parts플로우에서 이전 노드가 만든 A2A parts. replace(기본)/append 정책으로 다음 노드 전달 방식을 제어합니다.Upstream Parts 정책
도메인 에러비즈니스 의미를 담은 에러를 표준 A2A 에러(domainCode·domainTitle)로 매핑하는 방식.도메인 오류
용어한 줄 정의자세히
A2A (Agent-to-Agent)에이전트 간 메시지·이벤트 표준 프로토콜(0.3.x). 요청은 message/send·message/stream.A2A 메시지 요청
TextPart / DataPart / FilePartA2A 메시지 본문 단위. 자연어는 TextPart, 구조화 JSON은 DataPart, 파일 URI·bytes는 FilePart로 전달합니다.A2A 메시지 요청
artifact에이전트가 호출자에게 돌려주는 최종 산출물 묶음. SDK는 text/data/files를 A2A artifact의 parts로 직렬화합니다.플로우 상태와 헬퍼
contextIdA2A 대화/세션 ID. 같은 대화를 이어가려면 모든 message/send·message/stream 요청에 같은 값을 보내야 합니다.A2A 메시지 요청
params.metadata사용자 식별·관측·라우팅용 메타데이터 위치. message.metadata가 아니라 params 바로 아래에 넣어야 SDK가 인식합니다.A2A 메시지 요청
trace / Langfuse요청 처리 과정을 관측하기 위한 추적 정보와 대표 백엔드. sessionId·workflowName 같은 metadata로 trace를 묶어 볼 수 있습니다.관측성·로깅
ReActLLM이 추론(Reasoning)과 도구 호출(Acting)을 반복하는 루프. 반복 상한은 SDK가 안전 기본값으로 관리합니다.ReAct 반복 상한
reasoning / verbosity / provider_extraLLM 호출 튜닝 옵션. reasoning은 추론 방식, verbosity는 OpenAI native 출력 분량, provider_extra는 제공자별 raw 옵션 전달 통로입니다.문제 해결 → reasoning 모드
MCP (Model Context Protocol)외부 도구를 LLM/에이전트가 호출할 수 있게 연결하는 프로토콜. Registry에서 MCP 서버를 ID로 참조하거나, flow 노드에서 MCPHandle로 직접 호출할 수 있습니다.플로우 작성 규칙
HITL (Human-in-the-loop)실행 중간에 사람의 확인·입력을 받는 흐름(interruptinput-required → resume). 선택지는 HITLQuestion/HITLOption으로 선언합니다.HITL 가이드
멀티턴 메모리대화 히스토리를 유지해 이전 맥락을 참고하는 기능(in_memory/postgres). 선택적으로 thread-scoped fact recall을 켤 수 있습니다.멀티턴 메모리
checkpointerLangGraph 대화 상태를 저장·복원하는 저장 계층. PostgreSQL 메모리 모드에서는 checkpointer가 세션별 상태를 유지합니다.멀티턴 메모리
용어한 줄 정의자세히
폐쇄망 (air-gapped)런타임에 외부 네트워크가 전혀 없는 환경. prepare-offline으로 tar.gz 산출물을 만들어 반입합니다. (≠ SSH로 접근 가능한 원격 서버 배포)로컬 실행 + 폐쇄망 준비
wheelhouse의존성 wheel을 미리 받아 둔 디렉토리. 빌드 시 온라인 PyPI 대신 이 디렉토리를 사용합니다(vendor-deps가 생성).로컬 실행 + 폐쇄망 준비
인프라 프로필 (.llamon/profiles)배포 환경별 설정 묶음(.llamon/profiles/<name>.toml). SDK가 prod·stage를 기본 제공.인프라 프로필
Registry 런타임 vs local 런타임--runtime-source registry는 Registry의 노드를, local은 Registry 없이 노드별 LLM을 직접 연결합니다. llamon run의 “로컬 실행”(Docker 기동)과는 다른 개념입니다.직접 모델 연결
PgBouncerPostgreSQL 앞에 두는 연결 풀러. SDK의 PostgreSQL 메모리/checkpointer 경로는 PgBouncer session 모드를 전제로 합니다.멀티턴 메모리 → PgBouncer 호환성