소개
이 시리즈의 첫 번째 기사에서는 AI 에이전트가 무엇인지, 언제 사용해야 하는지 정의했습니다. 이제 이를 지배하는 메커니즘의 핵심에 접근할 시간입니다. 세 가지 기본 개념 모든 최신 에이전트 시스템의 중추를 형성합니다. OODA 루프 에 대한 의사결정 구조, 반응 패턴 추론-행동 교대를 위해, 그리고 도구 호출 외부 세계와의 상호 작용을 위해.
이는 추상적인 학문적 개념이 아닙니다. 모든 개발자가 사용하는 구현 패턴입니다. 효과적이고 안정적이며 디버깅 가능한 에이전트를 구축하려면 마스터해야 합니다. 랭그래프, 크루AI AutoGen은 이를 모두 내부적으로 구현하지만 이론적 토대를 이해하는 것이 개발자를 구별하는 사람 미국 새로운 사람의 프레임워크 이해하다 아키텍처를 갖추고 있으며 문제가 발생할 때 이를 해결하는 방법을 알고 있습니다.
이 기사에서 배울 내용
- OODA(Observe-Orient-Decide-Act) 루프와 이를 AI 시스템에 적용
- ReAct 패턴: 구조화된 방식으로 추론과 행동을 번갈아 사용하는 방법
- 도구 호출 메커니즘: 개념에서 구현까지
- ReAct, Chain-of-Thought 및 순수 함수 호출 비교
- 고급 패턴: 생각의 나무와 계획 우선
- 에이전트를 설계할 때 피해야 할 일반적인 실수
OODA 루프: 관찰-방향-결정-행동
루프 우다 (관찰, 지향, 결정, 행동)은 의사 결정 프레임워크입니다. 대령이 개발한 존 보이드 1970년대 미 공군의 원래는 상황에 따른 전투기 조종사의 의사 결정을 모델링하기 위한 것이었습니다. 빠른 속도와 불확실성. Boyd는 공중전에서 승리한 조종사가 조종사가 아니라는 점을 관찰했습니다. 반드시 가장 빠른 비행기를 가진 비행기가 있어야 하지만 사이클을 완료한 비행기도 있어야 합니다. 상대방보다 의사결정이 더 빠르다.
이 모델은 군사 전략부터 군사 전략까지 매우 다재다능한 것으로 입증되었습니다. 사이버 보안부터 인공 지능까지 비즈니스. 에이전트 시스템에 적용, OODA 루프는 AI 에이전트가 처리하는 방식을 이해하기 위한 구조적 프레임워크를 제공합니다. 정보를 얻고 결정을 내립니다.
OODA 루프의 4단계
1. 관찰하다
관찰 단계는 다음과 같이 구성됩니다. 환경에서 데이터 수집. AI 에이전트의 경우 관찰 소스에는 다음이 포함됩니다.
- 사용자 입력: 받은 메시지, 질문 또는 지침
- 도구 결과: 외부 도구 호출에서 반환된 데이터 (검색 결과, API 데이터, 파일 내용)
- 기억의 상태: 이전 상호작용의 맥락, 장기기억에 저장된 정보
- 환경으로부터의 피드백: 오류 메시지, HTTP 상태 코드, 예외, 시스템 측정항목
- 작업의 현재 상태: 어떤 하위 목표가 완료되었는지, 아직 해야 할 일이 무엇인지
관찰 단계의 품질은 나머지 주기의 품질을 결정합니다. 충분한 데이터를 수집하지 않거나 중요한 신호(예: 코드)를 무시하는 에이전트 HTTP 오류 429 속도 제한)은 최적이 아닌 결정을 내립니다.
2. 방향 잡기(방향 파악)
Boyd는 이것이 전체 루프의 가장 중요한 단계라고 생각했습니다. 오리엔테이션은 다음과 같이 구성됩니다. 상황화하고 해석하기 관찰하는 동안 수집된 데이터. 데이터를 보유하는 것만으로는 충분하지 않습니다. 현재 상황에서 데이터가 무엇을 의미하는지 이해해야 합니다.
AI 에이전트의 경우 오리엔테이션에는 다음이 포함됩니다.
- 복수: 수신된 데이터를 중요한 구성요소로 분해합니다.
- 패턴 매칭: 이미 직면한 상황과 유사한 상황을 인식합니다.
- 우선순위: 급한 일, 중요한 일, 기다릴 수 있는 일을 정하라
- 맥락 평가: 새로운 데이터가 작업의 전체 그림에 어떻게 들어맞는가
- 정보 격차 식별: 취해야 할 정보 중 누락된 정보 정보에 입각한 결정
실제로 이 단계는 다음에 해당합니다. LLM 추론: 모델 전체 컨텍스트(시스템 프롬프트, 기록, 도구 결과)를 분석하고 공식화합니다. 현재 상황에 대한 이해. 여기서는 시스템 프롬프트의 품질이 매우 중요합니다. 모델이 상황을 명시적으로 고려하고 평가하도록 안내하는 프롬프트 대안을 찾고 위험을 식별하면 훨씬 더 효과적인 지침이 생성됩니다.
3. 결정하다 (결정하다)
방향에 따라 상담원은 수행할 작업을 선택하세요.. 결정은 다음과 같습니다.
- 도구 호출: 데이터를 얻기 위해 외부 함수를 호출합니다. 또는 작업을 수행
- 응답 생성: 사용자를 위한 최종 출력을 생성합니다.
- 추가 입력 요청: 사용자에게 설명을 요청합니다.
- 계획을 재구성하라: 현재의 접근방식을 버리고 시도해 보세요. 대안 전략
- 마치다: 목표가 달성되었다고 결론을 내립니다. 사용 가능한 리소스로는 연결할 수 없습니다)
4. 행동
대리인 내린 결정을 실행한다. 이 단계는 의도를 변화시킵니다. 구체적인 작업: 도구가 호출되고, 응답이 생성되고, 요청이 설명이 공식화되었습니다. 작업 후 루프는 관찰 단계에서 재개됩니다. 에이전트는 작업 결과를 수집하고 새 주기를 시작합니다.
AI 에이전트에 적용된 OODA 루프
| OODA 단계 | AI 에이전트 | 기술 구성 요소 |
|---|---|---|
| 관찰하다 | 사용자 입력, 도구 결과, 메모리 상태 수집 | 입력 처리, 컨텍스트 어셈블리 |
| 동양 | 맥락을 분석하고, 격차를 파악하고, 우선순위를 정하세요. | LLM 추론, 시스템 프롬프트 안내 |
| 그는 결정한다 | 선택: 도구 호출, 최종 응답 또는 입력 요청 | LLM 출력 구문 분석, 작업 선택 |
| 행동 | 도구 실행, 출력 생성, 상태 변경 | 도구 실행, 응답 생성 |
주기 시간: 주요 지표
Boyd는 경쟁 우위는 단일 제품의 품질에 있는 것이 아니라고 주장했습니다. 결정했지만, 전체 사이클이 완료되는 속도. 같은 원칙은 AI 에이전트에 적용됩니다: 여러 OODA 루프를 빠르게 완료하는 에이전트, 각 반복에 적응하면 도달하려는 에이전트보다 더 효과적입니다. 단 한번의 긴 주기로 완벽해집니다.
실질적으로 이는 에이전트를 다음과 같이 설계하는 것을 의미합니다. 원자적이고 빠른 도구 모놀리식의 느린 도구보다는 단일 쿼리를 신속하게 실행하고 밀리초 단위로 결과를 반환하면 에이전트가 빠르게 반복할 수 있습니다. 10개의 서로 다른 소스에서 데이터를 집계하고 30초가 필요한 도구는 전체 주기를 차단합니다.
ReAct 패턴: 추론 + 행동
패턴 반응하다 (추론+행동), 2022년 연구자들이 선보인 Princeton과 Google의 논문 "ReAct: Synergizing Reasoning and Acting in Language Models"에서, AI 에이전트 설계의 근본적인 혁신을 나타냅니다. ReAct 이전에도 존재했습니다. 두 가지 별도의 접근 방식: 생각의 사슬 (CoT), 기능을 향상시켰습니다. 모델을 추론했지만 외부 행동을 예측하지 못했고 시스템은 행동 계획, 행동을 수행했지만 투명한 추론 없이.
ReAct는 이 두 가지 접근 방식을 단일 구조 루프로 통합합니다. 생각의 단계와 행동의 단계를 명시적으로 번갈아 나타냄:
Thought: Devo trovare le vendite globali di EV nel 2025.
Cerchero prima i dati aggregati più recenti.
Action: web_search("global electric vehicle sales 2025 data")
Observation: I risultati mostrano che nel 2025 sono stati venduti
18.2 milioni di EV a livello globale, con una crescita
del 25% rispetto al 2024...
Thought: Ho i dati aggregati. Ora ho bisogno della suddivisione
per produttore per identificare i leader di mercato.
Action: web_search("top EV manufacturers market share 2025")
Observation: BYD guida con il 23% del mercato, seguita da Tesla
con il 18%, Hyundai-Kia con il 9%...
Thought: Ho dati sufficienti per la prima parte del report.
Posso ora sintetizzare le informazioni raccolte
in un formato strutturato per l'utente.
Action: generate_response(report strutturato con dati e trend)
ReAct 루프의 구조
ReAct 루프는 세 가지 반복 구성요소가 있는 엄격한 순환 패턴을 따릅니다.
- 생각: 모델은 자신의 추론을 명시적으로 표현합니다. 지금까지 무엇을 알고 있나요? 그가 무엇을 놓치고 있나요? 어떤 도구를 사용해야 하며 그 이유는 무엇입니까? 생각과 보이는 행동을 투명하게 만드는 에이전트 추적에서 e 디버깅 가능.
- 행동: 모델이 생각을 바탕으로 도구를 선택합니다. 특정 매개변수로 호출됩니다. 행동이 구체적이고 검증 가능합니다. 통제할 수 있습니다. 어떤 도구가 호출되었는지, 어떤 인수를 사용하여 호출되었는지, 호출이 성공했는지 여부입니다.
- 관찰: 작업의 결과가 반환됩니다. 모델에게. 관찰은 이후의 사고를 위한 맥락의 일부가 됩니다. 목표를 향한 추론을 안내하는 지속적인 피드백 루프를 생성합니다.
ReAct 루프 의사코드
def react_loop(user_query, tools, max_iterations=10):
context = [system_prompt, user_query]
for i in range(max_iterations):
# Il modello genera Thought + Action
response = llm.generate(context)
# Parse della risposta
thought = extract_thought(response)
action = extract_action(response)
# Se l'azione è "final_answer", termina il loop
if action.name == "final_answer":
return action.arguments["answer"]
# Esegui il tool
try:
observation = execute_tool(action.name, action.arguments)
except ToolError as e:
observation = f"Errore: {str(e)}"
# Aggiungi thought, action e observation al contesto
context.append(f"Thought: {thought}")
context.append(f"Action: {action.name}({action.arguments})")
context.append(f"Observation: {observation}")
# Limite di iterazioni raggiunto
return "Impossibile completare il task nel limite di iterazioni"
ReAct가 추론만 하는 것보다 더 나은 이유
순수한 사고 사슬에 비해 ReAct의 주요 장점은 모델이 그는 자신의 내부 지식(이것은 더 이상 사용되지 않거나 불완전하거나 부정확할 수 있습니다.) 작업을 통해 모델은 다음을 수행할 수 있습니다. 새로운 정보를 얻으세요 현실 세계에서 가져와 이를 사용하여 개선합니다. 당신 자신의 추론.
ReAct 패턴의 구체적인 이점은 다음과 같습니다.
- 추론의 투명성: 모든 논리적 단계가 추적에 표시됩니다. 에이전트가 예상치 못한 결과를 생성할 때 디버깅 및 사후 분석을 촉진합니다.
- 사실에 근거: 도구의 관찰이 추론을 고정시킵니다. 실제 데이터에 적용하여 모델의 환각과 조작을 줄입니다.
- 적응성: 에이전트는 실시간으로 전략을 변경할 수 있습니다. 엄격한 계획에 얽매이지 않고 행동의 결과에 따라
- 우수한 성능: 실증적 연구에 따르면 ReAct가 더 나은 성능을 발휘하는 것으로 나타났습니다. 추론 및 의사결정 벤치마크에 대한 CoT 단독 및 실행 계획 단독
도구 호출: AI와 현실 세계를 잇는 다리
Il 도구 호출 (OpenAI에서는 "함수 호출"이라고도 함)은 메커니즘입니다. 이를 통해 AI 에이전트는 외부 세계와 구체적으로 상호 작용합니다. 도구 호출 없이, LLM은 텍스트만 생성할 수 있습니다. 호출 도구를 사용하면 웹 검색 및 쿼리를 수행할 수 있습니다. 데이터베이스, 파일 생성, 이메일 보내기, API 호출 등 다양한 작업을 수행할 수 있습니다.
메커니즘은 세 가지 기본 단계로 작동합니다.
- 모델은 구조화된 도구 호출 요청을 생성합니다.: 생산하는 대신 자유 텍스트인 경우 모델은 호출할 도구를 지정하는 JSON 개체를 생성합니다. 어떤 매개변수. 모델은 다음을 결정할 때 이 형식을 생성하도록 학습되었습니다. 외부 조치가 필요하다는 것입니다.
- 런타임은 해당 기능을 실행합니다.: 프레임워크(LangGraph, CrewAI 또는 사용자 정의 런타임)이 요청을 수신하고, 매개변수를 검증하고, 기능을 실행합니다. 결과를 캡처합니다.
- 결과는 모델로 반환됩니다.: 도구 출력이 추가됩니다. 대화의 맥락에 따라 "관찰"을 수행하고 모델은 계속해서 새로운 정보로 추론하기.
도구의 정의: 스키마
각 도구는 모델이 이해할 수 있는 명확한 스키마로 정의되어야 합니다. 스키마에는 도구 이름, 도구 설명의 세 가지 기본 요소가 포함됩니다. 자연어(LLM이 이해하기 위해 사용하는 언어) 언제 사용) 및 사양 LLM이 이해하기 위해 사용하는 매개변수 ~처럼 그것을 사용하십시오).
{
"name": "search_database",
"description": "Cerca record nel database dei clienti. Usa questo tool quando l'utente chiede informazioni su clienti specifici, ordini o dati storici. Supporta ricerca per nome, email o ID ordine.",
"parameters": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "Il termine di ricerca (nome cliente, email o ID ordine)"
},
"filter_type": {
"type": "string",
"enum": ["name", "email", "order_id"],
"description": "Il tipo di campo su cui filtrare"
},
"limit": {
"type": "integer",
"default": 10,
"description": "Numero massimo di risultati da restituire"
}
},
"required": ["query", "filter_type"]
}
}
도구 호출의 흐름
모델이 도구를 사용하기로 결정한 순간부터 도구 호출의 전체 흐름을 살펴보겠습니다. 결과가 반환될 때까지 도구:
1. L'utente chiede: "Trova gli ordini del cliente Mario Rossi"
|
v
2. L'LLM analizza la richiesta e i tool disponibili
|
v
3. L'LLM genera una tool call strutturata:
{
"tool": "search_database",
"arguments": {
"query": "Mario Rossi",
"filter_type": "name",
"limit": 5
}
}
|
v
4. Il runtime:
a) Valida gli argomenti contro lo schema del tool
b) Esegue la funzione search_database("Mario Rossi", "name", 5)
c) Cattura il risultato
|
v
5. Il risultato viene restituito all'LLM:
{
"results": [
{"order_id": "ORD-2024-1542", "date": "2024-03-15", "total": 249.99},
{"order_id": "ORD-2024-1897", "date": "2024-06-22", "total": 89.50}
],
"total_count": 2
}
|
v
6. L'LLM genera la risposta finale per l'utente:
"Ho trovato 2 ordini per Mario Rossi:
- ORD-2024-1542 del 15/03/2024: 249.99 EUR
- ORD-2024-1897 del 22/06/2024: 89.50 EUR"
도구 설명: 가장 중요한 요소
La 도구에 대한 설명 전체 메커니즘의 가장 중요한 요소입니다. 도구 호출에 대한 내용이 있지만 간과되는 경우가 많습니다. LLM은 코드를 실행하지 않고 설명을 읽습니다. 자연어를 기반으로 도구를 호출할지 여부와 시기를 결정합니다. 그 설명에.
효과적인 설명은 세 가지 질문에 답해야 합니다.
- 도구의 기능은 무엇인가요? 기능에 대한 명확하고 간결한 설명
- 언제 사용하나요? 도구가 적합한 특정 사용 사례 (그리고 암시적으로, 그것을 사용하지 않을 때)
- 그것을 사용하는 방법? 예상 매개변수, 제약조건, 형식에 대한 정보
예: 좋음과 나쁨 설명
잘못된 설명: "데이터베이스를 검색해 보세요."
너무 모호합니다. LLM은 어떤 데이터베이스, 어떤 유형의 데이터가 포함되어 있는지, 언제 적절한지 알지 못합니다. 사용 가능한 다른 도구와 비교하여 이 도구를 사용하거나 쿼리에 어떤 형식이 있어야 하는지를 알아보세요.
좋은 설명: “기업 고객 데이터베이스에서 기록을 검색해 보세요. 사용자가 고객, 주문 또는 송장에 대한 정보를 요청할 때 이 도구를 사용하세요. 고객 이름(일부 또는 전체), 이메일, 주문 ID(ORD-YYYY-NNNN 형식)로 검색 지원 또는 송장 번호. 내림차순으로 정렬하여 최대 50개의 결과를 반환합니다."
구체적이고 상황에 맞는 LLM에 도움이 되는 형식 및 제한 사항에 대한 정보가 포함되어 있습니다. 올바른 매개변수를 생성합니다.
비교: ReAct vs 사고 사슬 vs 함수 호출
제시된 패턴에 대한 이해를 강화하기 위해 표로 비교해 보겠습니다. 구조적 차이점, 장점 및 한계를 강조합니다.
추론 패턴 비교표
| 특성 | CoT(사고 사슬) | 순수 함수 호출 | 반응하다 |
|---|---|---|---|
| 명시적 추론 | 예(단계별) | 아니요(암시적) | 예(생각이 눈에 보인다) |
| 외부 조치 | No | Si | Si |
| 최신 데이터에 액세스 | 아니요(학습 데이터만 해당) | 예(도구를 통해) | 예(도구를 통해) |
| 디버깅 가능성 | 높음(추적 표시) | 평균(I/O 도구만 해당) | 매우 높음(생각 + 행동) |
| 환각의 위험 | 높음(접지 없음) | 낮음(실제 데이터) | 낮음(접근 + 추론) |
| 토큰 비용 | 중간 | 베이스 | 높음(생각 + 행동 + 관찰) |
| 이상적인 사용 사례 | 수학적 추론, 논리 | API를 사용한 간단한 작업 | 복잡한 다단계 작업 |
| 채택자 | 고급 엔지니어링 프롬프트 | OpenAI 함수 호출 | LangGraph, 현대 에이전트 |
패턴 선택은 사용 사례에 따라 다릅니다. 순전히 인지적인 작업(추론 수학적, 논리적 분석), 생각의 사슬이면 충분합니다. 간단한 작업의 경우 단일 외부 작업(API 호출, 데이터베이스 쿼리)이 필요합니다. 순수 함수 호출은 효율적이고 경제적입니다. 요구되는 복잡한 작업의 경우 여러 작업을 통한 반복 추론, ReAct가 최고의 표준입니다.
고급 패턴: 생각의 나무와 계획 우선
기본적인 패턴 외에도 AI 에이전트 분야의 연구를 통해 추론의 질과 능력을 향상시키기 위한 보다 정교한 접근법 계획의. 두 가지 패턴에 특별한 관심을 기울일 필요가 있습니다.
생각의 나무(ToT)
Il 생각의 나무, 2023년에 제안된 사고 사슬 확장 선형 체인에서 광고 구조로 나무. 팔로우하는 대신 단일 추론 경로를 통해 모델이 탐색합니다. 여러 대안 병렬로, 각 지점을 평가하고 가장 유망한 지점을 선택하십시오.
실제로 이는 에이전트가 다음을 의미합니다.
- 문제를 해결하기 위해 몇 가지 가능한 전략을 생성합니다.
- 타당성 점수와 성공 확률로 각 전략을 평가합니다.
- 가장 유망한 분기를 탐색하되 나머지 분기는 대체 항목으로 유지하세요.
- 선택한 분기가 실패하면 역추적하여 대안을 시도해 보세요.
ToT는 명확하지 않은 해결책(퍼즐, 계획)이 있는 문제에 특히 효과적입니다. 전략적, 복잡한 상충관계가 있는 결정), 계산 비용이 높음 트리의 각 노드에 대해 여러 세대가 필요하기 때문입니다.
계획 우선
접근 방식 계획 우선 전통적인 ReAct의 논리를 뒤집습니다. 대신 생각과 행동을 점진적으로 번갈아 가며 에이전트 계획을 세우다 작업을 수행하기 전에 완료그런 다음 단계별로 계획을 실행하고, 필요한 경우 이를 조정합니다.
계획 우선 흐름은 다음 구조를 따릅니다.
[FASE 1: PIANIFICAZIONE]
Input: "Crea un report sulle performance del team Q4 2025"
Piano generato dall'agente:
Step 1: Recuperare i dati di sprint completati Q4 2025
Step 2: Calcolare velocity media e trend
Step 3: Identificare i blockers più frequenti
Step 4: Generare grafici delle metriche chiave
Step 5: Sintetizzare il report in formato strutturato
[FASE 2: ESECUZIONE]
Eseguire il piano step-by-step, con possibilità di:
- Re-pianificare se un step fallisce
- Aggiungere step intermedi se necessario
- Saltare step non più rilevanti
Plan-First는 개요가 필요한 길고 복잡한 작업에 유리합니다. 근본적. 위험은 초기 계획이 나타나는 잘못된 가정을 기반으로 한다는 것입니다. 실행 중에만 실행되므로 비용이 많이 드는 재계획이 필요합니다. 이러한 이유로, 현대적인 구현은 Plan-First와 ReAct의 유연성을 결합합니다. 하지만 각 반복마다 계획을 조정할 수 있는 능력은 그대로 유지됩니다.
OODA, ReAct 및 도구 호출 간의 상호 작용
이 글에서 제시하는 세 가지 개념은 대안이 아니라, 상호보완적이고 상호연결되어 있다. OODA는 의사결정 프레임워크를 제공합니다. 높은 수준에서 ReAct는 그 내에서 추론-행동 패턴을 구현합니다. 프레임워크이며 도구 호출은 작업을 가능하게 하는 기술적 메커니즘입니다.
세 가지 개념이 통합되는 방식
| 수준 | 개념 | 역할 |
|---|---|---|
| 전략적 | OODA 루프 | 의사결정 프레임워크: 추론 및 행동 주기를 구조화하는 방법 |
| 전술적 | 패턴 리액트 | 구현 패턴: 생각과 행동을 명시적으로 번갈아 사용하는 방법 |
| 운영 중 | 도구 호출 | 기술적 메커니즘: 에이전트가 실제로 외부 작업을 수행하는 방법 |
예를 들어 LangGraph 에이전트에서 상태 그래프는 OODA 루프(각 노드)를 구현합니다. 단계에 해당함) 추론 노드는 ReAct(Thought-Action-Observation) 패턴을 따르며, 도구 호출을 통해 작업이 구체화됩니다(모델은 JSON 도구 호출을 생성하고, 런타임이 이를 실행합니다.) 세 가지 수준을 모두 이해하는 것이 디자인에 필수적입니다. 동시에 효과적이고 디버깅이 가능하며 유지 관리가 가능한 에이전트입니다.
피해야 할 일반적인 실수
AI 에이전트의 설계에는 효율성을 저하시킬 수 있는 특정 함정이 있습니다. 시스템의 신뢰성과 보안. 가장 흔히 발생하는 실수와 이를 방지하는 방법은 다음과 같습니다.
에이전트 설계에서 가장 자주 발생하는 7가지 오류
-
1. 무한 루프: 에이전트가 솔루션으로 수렴하지 않고 계속 반복합니다.
일반적인 원인: 종료 기준이 모호하거나 없습니다. 해결 방법: 항상 설정
에
max_iterations루프 감지 메커니즘을 구현합니다. (마지막 N개의 작업이 동일하면 오류 메시지로 끝납니다). - 2. 모호한 도구 설명: 도구 설명이 정확하지 않은 경우 LLM은 언제 사용해야 할지 모르거나 부적절하게 사용할 것입니다. 각 설명은 다음을 지정해야 합니다. 도구의 기능, 사용 시기, 예상되는 매개변수 등입니다. 테스트 설명 모호한 쿼리는 기본적인 관행입니다.
- 3. 정지 조건의 부족: 상담원은 언제 끝날지 모릅니다. 시스템 프롬프트에는 구성 요소에 대한 명시적인 지침이 포함되어야 합니다. 성공적인 완료 및 에이전트가 루프를 중단하고 결과를 반환해야 하는 경우.
- 4. 컨텍스트 오버플로: 루프가 반복될 때마다 컨텍스트에 토큰이 추가됩니다. 여러 번 반복하면 LLM 컨텍스트 창을 초과하여 다음이 발생할 위험이 있습니다. 잘림 또는 오류. 컨텍스트 압축 전략 구현(요약 이전 반복에서는 관련 정보만 유지하세요).
- 5. 오류 처리 실패: 도구가 실패할 수 있습니다(시간 초과, 속도 제한, 잘못된 데이터). 에이전트는 오류를 처리하도록 설계되어야 합니다. 정상적으로: 백오프, 대체 도구, 성능 저하 제어를 통한 재시도 부분적인 대답.
- 6. 너무 세분화되거나 단일화된 도구: 작업이 너무 적은 도구 에이전트가 너무 많은 반복을 거치도록 강제합니다. 유연성을 너무 많이 감소시키는 도구 디버깅을 어렵게 만듭니다. 최적의 세분성은 단일 개념, 단일 도구에 대한 책임.
- 7. 가드레일 부재: 동작 제한 없이 Agent 실행 가능 파괴적인 행위(데이터 삭제, 잘못된 이메일 보내기, 승인되지 않은 구매) 승인됨). 항상 구현: 세션당 비용 제한, 작업 허용 목록 권한, 되돌릴 수 없는 작업에 대한 사람의 승인 지점입니다.
결론
이 글에서 우리는 행동을 지배하는 세 가지 기본 기둥을 탐구했습니다. 모든 최신 AI 에이전트의 그만큼 OODA 루프 의사결정 프레임워크를 제공합니다. 높은 수준에서 관찰, 방향 설정, 결정 및 행동의 지속적인 주기를 구조화합니다. 그만큼 반응 패턴 명시적인 토글을 사용하여 이 프레임워크를 구현합니다. 에이전트의 추론을 투명하고 디버그 가능하게 만드는 생각과 행동. 그만큼 도구 호출 에이전트를 활성화하는 기술적 메커니즘을 제공합니다. 의도를 실제 세계의 구체적인 작업으로 변환합니다.
또한 Tree-of-Thought, Plan-First 등 고급 패턴을 도입하여 분석했습니다. 에이전트 설계에서 가장 일반적인 오류. 이러한 탄탄한 이론적 기초를 바탕으로 우리는 실제적인 구현으로 나아갈 준비가 되어 있습니다.
다음 기사에서는 "LangChain 및 LangGraph: 상태 그래프를 사용하여 에이전트 구축", 코드 작성을 시작하겠습니다. LangGraph를 설치하는 방법, 상태 그래프를 정의하는 방법, 추론 및 작업 노드를 구현하고 첫 번째 작업 에이전트를 구축합니다. 도구 호출 및 메모리를 사용합니다. 개념에서 코드까지: 여정은 계속됩니다.