에이전트 워크플로 대체에 관심을 기울여야 하는 이유는 무엇입니까?
프로덕션급 에이전트 워크플로를 구축할 때 가장 큰 환상은 "모델이 예상대로 돌아올 것"이라는 것입니다. 실제 작업에서는 LLM 호출이 시간 초과되고, 도구 체인이 끊어지고, 컨텍스트가 오버플로될 수 있습니다. 대체가 없으면 한 번의 오류로 인해 전체 에이전트가 정지되고 사용자는 인터페이스가 응답하지 않거나 컨텍스트를 벗어난 응답을 받게 됩니다.
에이전트의 실패 모드는 기존 서비스보다 더 다양합니다. 모델 반환 형식 오류로 인해 구문 분석 예외가 발생하고, 외부 API 현재 제한이 429를 반환하고, 다단계 추론의 특정 루프 출력이 기대에 미치지 못합니다. 폴백은 옵션이 아니라 에이전트 엔지니어링의 핵심입니다.
대체의 핵심 메커니즘: 단순한 재시도가 아닙니다
많은 사람들이 대체를 재시도 메커니즘과 동일시하지만 에이전트 워크플로의 대체는 더 많은 차원을 처리해야 합니다.
1. 시간 초과 및 현재 제한 롤백
LLM 호출과 도구 호출 모두 시간 초과 창이 있습니다. LLM 호출이 10초 이상 반환되지 않으면(모델 및 시나리오에 따라 조정됨) 폴백은 결과 캐싱으로 전환하거나, 답변을 다운그레이드하거나("지금은 처리할 수 없습니다. 나중에 다시 시도하십시오") 여러 모델을 지원하는 아키텍처에서 더 작고 빠른 모델로 전환할 수 있습니다.
# 简化示例：超时 fallback 到缓存
import asyncio
async def call_llm_with_fallback(prompt, cache, fallback_model=None):
try:
result = await asyncio.wait_for(llm_api(prompt), timeout=10)
cache.update(prompt, result)
return result
except asyncio.TimeoutError:
cached = cache.get(prompt)
if cached:
return cached
if fallback_model:
return await fallback_model(prompt)
return "当前请求超时，请稍后重试"
这个阶段最容易犯的错误是不设置合理的超时值。设置太短会导致正常慢响应被截断，设置太长会让用户等待过久。建议根据模型 P99 延迟动态调整，并配合客户端感知的进度反馈。
2. 工具调用失败的回退路径
Agent 工作流通常涉及多个工具调用，比如搜索、数据库查询、代码执行。任何一个工具失败，如果只是抛出异常，工作流就会中断。好的 fallback 应该是给 agent 一个“绕行”选项。
真实场景：一个客服 agent 需要查询订单物流信息，但下游物流 API 暂时不可用。这时 fallback 策略可以是：
- 尝试从本地缓存获取历史数据
- 切换到备选物流查询服务
- 告知用户“物流信息暂时无法查询，请稍后重试”，并记录工单
实现时，可以在工具定义中声明 fallback 行为：
tools = [
{
"name": "track_order",
"description": "查询订单物流状态",
"fallback": [
{"type": "cache", "ttl": 300},
{"type": "alternative_api", "endpoint": "https://backup-logistics.example.com"},
{"type": "user_message", "content": "物流查询暂时不可用，已记录您的请求"}
]
}
]
3. 추론 경로의 폴백: 에이전트가 무한 루프에 빠진 경우
에이전트는 동일한 키워드를 지속적으로 검색하는 등 특정 단계에서 동일한 결정을 반복적으로 내릴 수 있습니다. 이는 일반적으로 프롬프트가 잘못 설계되었거나 외부 조건이 충족되지 않기 때문에 발생합니다. 이 시점에서 폴백은 루프를 중단하거나 새 정보를 제공하거나 상태를 재설정하여 개입해야 합니다.
실용적인 접근 방식: 워크플로에 "루프 감지" 모듈을 추가하여 마지막 N 단계의 결정이 반복되는지 여부를 계산합니다. 루프가 발견되면 폴백은 다음 메시지를 강제로 삽입합니다. "동일한 작업을 3번 반복했습니다. 다른 방법을 시도해 보십시오. 예를 들어 사용자에게 "더 정확한 정보를 찾을 수 없습니다"라고 직접 대답하거나 사용자에게 자세한 내용을 제공하도록 요청합니다.
가장 쉬운 함정: 순차 폴백과 병렬 폴백
폴백을 설계할 때 많은 사람들은 순차 판단을 작성하는 데 익숙합니다. A가 실패하면 B를 시도하고 B가 실패하면 C를 시도합니다. 이는 일부 시나리오에 해당되지만 B 및 C에 대한 호출이 비싸거나 시간 창이 있는 경우 순차 차단으로 인해 지연이 선형적으로 추가됩니다. 더 나은 전략은 병렬 대체입니다. A와 B(두 개의 후보 모델 또는 도구)를 동시에 실행하고 오류가 아닌 결과를 반환하는 항목을 먼저 사용합니다.
순차 또는 병렬 간의 선택은 오류 모드의 대기 시간 특성에 따라 달라집니다. 주요 실패가 형식 오류이지만 정상적인 응답이 빠른 경우 순차적 재시도로 충분합니다. 주요 오류가 시간 초과 또는 제한인 경우 병렬 대체를 통해 사용자가 인식하는 대기 시간을 크게 줄일 수 있습니다.
특정 실패 사례: 팀은 에이전트에 대해 3단계 폴백을 구성했습니다. 먼저 모델을 더 큰 크기로 조정한 다음 시간 초과 후 모델을 더 작은 크기로 조정하고 시간 초과 후 고정 응답을 조정합니다. 병렬 실행이 없기 때문에 각 폴백에는 10초의 시간 초과가 필요하며 사용자는 "처리할 수 없습니다."라는 문장을 받기까지 최대 30초를 기다려야 합니다. 병렬화로 변경한 후 3초 이내에 소형 모델의 결과를 얻었습니다.
Fallback의 적용 가능한 경계 및 제한 사항
폴백은 만병통치약이 아닙니다. 입력 프롬프트 자체가 보안 위험을 초래하거나 모델의 지식 범위를 초과하는 경우 폴백으로 인해 오류가 증폭될 수 있습니다. 예를 들어, 악성 프롬프트가 기본 모델의 보안 가드레일을 우회하는 경우 대체 모델의 보안이 더욱 약화될 수 있습니다. 이 시점에서 더 나은 접근 방식은 대체보다는 서비스를 거부하는 것입니다.
또 다른 제한 사항: 폴백은 특히 여러 폴백 체인을 유지 관리할 때 시스템 복잡성을 증가시킬 수 있습니다. 무한 반복을 방지하려면 각 에이전트 워크플로에 대해 최대 대체 깊이를 설정하는 것이 좋습니다.
실행 가능한 접근 방식: 대체 목록 작성
- 에이전트 워크플로의 각 호출 지점(LLM 호출, 도구 호출, API 호출)을 정렬합니다.
- 각 지점에 대한 실패 모드(시간 초과, 형식 오류, 비즈니스 예외, 컨텍스트 오버플로)를 결정합니다.
- 각 모드(재시도, 캐시, 모델 다운그레이드, 대체 도구, 사용자 메시지)에 대한 대체 작업을 설계합니다.
- 대체 실행 순서(순차 또는 병렬)를 결정하고 최대 시도 횟수를 설정합니다.
- 개발 환경에서 오류를 시뮬레이션하여 폴백이 예상대로 트리거되는지 확인합니다.
- 대체 트리거 속도를 모니터링합니다. 대체가 자주 발생하는 경우 대체를 위해 대체에 의존하기보다는 기본 경로의 안정성을 개선해야 함을 의미합니다.
실패 시 대체 계획
모든 대체가 실패하면 에이전트의 성능이 정상적으로 저하되어야 합니다. 최소 요구 사항은 친숙한 오류 메시지를 반환하고, 사용자에게 무슨 일이 일어났는지 알리고, 대체 작업 항목(예: 수동 고객 서비스 또는 다시 시도)을 제공하는 것입니다. 비어 있거나 불완전한 답변을 반환하지 마십시오.
대안 목록:
- 정적 응답을 반환하고 사용자에게 나중에 다시 시도하라는 메시지를 표시합니다.
- 후속 분석을 용이하게 하기 위해 실패 세부 사항을 로그에 기록합니다.
- 운영 및 유지보수 담당자에게 개입을 비동기적으로 알립니다.
에이전트 초심자에서 에이전트 엔지니어로
폴백은 에이전트 엔지니어링의 기본 기능입니다. 폴백을 마스터한다는 것은 "데모 에이전트 작성"에서 "프로덕션 수준 에이전트 구축"으로 전환하기 시작한다는 의미입니다. 그러나 폴백만으로는 모든 안정성 문제를 해결할 수 없습니다. 또한 권한 관리, 메모리 관리, 컨텍스트 제어, 평가 및 반복을 이해해야 합니다.
아직 댓글이 없습니다