Beyond Function Calling: Benchmarking Tool-Using Agents under Tool-Environment Unreliability
TL;DR Highlight
실제 환경처럼 API가 망가지거나 결과가 이상할 때 LLM 에이전트가 얼마나 잘 버티는지 측정하는 벤치마크 ToolBench-X 공개.
Who Should Read
LLM 기반 에이전트에서 외부 API/툴을 붙여 실서비스를 운영 중인 백엔드 개발자나 AI 엔지니어. 특히 툴 호출 실패, 응답 포맷 변경, 타임아웃 같은 런타임 예외 상황을 어떻게 처리할지 고민하는 분들에게 유용.
Core Mechanics
- 기존 벤치마크(BFCL, ToolBench 등)는 API가 항상 정상 동작한다고 가정하는데, 실제론 문서가 낡거나 타임아웃이 나거나 서로 다른 툴이 충돌하는 값을 반환하는 경우가 흔함.
- ToolBench-X는 5가지 장애 유형을 주입함: Specification Drift(API 스펙 변경), Invocation Error(인자 전달 실패), Execution Failure(타임아웃/런타임 에러), Output Drift(응답 포맷 변화), Cross-source Conflict(여러 툴 간 결과 충돌).
- 핵심 설계 원칙은 '회복 가능성' — 장애를 주입해도 retry, fallback, 정규화, 교차 검증 중 최소 하나의 정답 경로는 반드시 남겨둠.
- 12개 주요 모델(GPT-5.4, DeepSeek-V4-Pro, Claude-Sonnet-4.6, Doubao-Seed-2.0-Lite, Qwen-3.5-35B 등) 모두 성공률 60% 미만. 최고 성능인 Doubao-Seed-2.0-Lite도 51.3%에 그침.
- 실패의 핵심 원인은 툴 호출 횟수나 추론 예산(compute)이 아니라 '장애 진단 능력' 부재. 장애 힌트를 주면 성공률이 25~35 포인트 급등하지만, 추가 추론 라운드만 주면 3~11 포인트 향상에 그침.
- Qwen 패밀리 비교에서 thinking 모드(명시적 추론)가 파라미터 스케일링보다 효과적: Qwen-3.5-35B-Thinking이 비-thinking 35B보다 4.7 포인트 높고, 비-thinking 35B가 더 작은 Qwen-3.0-30B보다 오히려 낮음.
Evidence
- 12개 모델 전부 전체 성공률 60% 미만. 최고는 Doubao-Seed-2.0-Lite 51.3%, GPT-5.4 45.3%, DeepSeek-V4-Pro 42.5%, Claude-Sonnet-4.6 41.0% 순.
- 장애 힌트(Hint) 제공 시 Baseline 대비 25.5~35.5 포인트 향상, 실패 태스크의 60~80%를 회복. 반면 추가 추론 라운드(Test-Time Scaling) 제공 시 3.5~11.5 포인트 향상에 그침.
- GPT-5.4-Mini 기준: Hint 조건 84.0% vs TTS 조건 52.0% — 진단 정보가 추가 compute보다 32 포인트 이상 더 효과적.
- 툴 체인 길이별 성능 저하 확인: Doubao-Seed-2.0-Lite는 툴 3개 이하 태스크에서 57.7%지만 5개 이상에서 46.2%로 하락. Gemini-3.1-Flash-Lite는 44.2%→31.8%로 급락.
How to Apply
- 에이전트 시스템에서 툴 호출 실패 시 단순 retry가 아니라 '왜 실패했는지'를 먼저 분류하는 진단 레이어를 추가하면 회복률을 크게 높일 수 있음. 예: 타임아웃이면 retry, 포맷 변경이면 파싱 로직 수정, 여러 소스 충돌이면 교차 검증.
- Production 에이전트에서 API 응답이 예상 스키마와 다를 때 즉시 실패 처리하지 말고, Output Drift 회복 전략(필드 정규화, 단위 변환, 중첩 구조 언팩)을 파이프라인에 내장하면 됨.
- 자체 에이전트 벤치마크 구축 시, 기존처럼 '정답 툴을 골랐는가'만 평가하지 말고 ToolBench-X 방식처럼 장애를 주입한 후 '최종 태스크를 완료했는가'로 평가 기준을 바꿔야 실서비스 신뢰도를 제대로 측정 가능.
Code Example
# ToolBench-X 스타일의 장애 진단 + 회복 에이전트 패턴 예시
def tool_call_with_recovery(tool_fn, args, max_retries=2):
"""
툴 호출 시 장애 유형을 진단하고 적절한 회복 전략을 선택.
"""
for attempt in range(max_retries + 1):
try:
result = tool_fn(**args)
# Output Drift 감지: 예상 필드가 없거나 형식이 다름
if not validate_output_schema(result):
result = normalize_output(result) # 정규화 시도
if result.get('success') is False or result.get('ok') is False:
raise ValueError(f"Tool returned failure: {result}")
return result
except TimeoutError:
# Execution Failure -> retry
if attempt < max_retries:
print(f"[Execution Failure] Timeout. Retrying {attempt+1}/{max_retries}...")
continue
return try_fallback_tool(args) # fallback 툴로 전환
except KeyError as e:
# Specification Drift -> 런타임 스키마로 재매핑
print(f"[Specification Drift] Missing field: {e}. Remapping...")
args = remap_args_to_runtime_schema(args, e)
except TypeError as e:
# Invocation Error -> 인자 구조 수정
print(f"[Invocation Error] Argument error: {e}. Repairing args...")
args = repair_invocation_args(args, e)
return None
def cross_source_verify(results: list):
"""
Cross-source Conflict: 여러 툴 결과를 교차 검증.
단순 다수결 X -> 원본 기준값과 대조 후 정규화된 값만 채택.
"""
normalized = [normalize_value(r) for r in results if r is not None]
# 일치하는 값만 신뢰
from collections import Counter
counts = Counter(normalized)
most_common_val, count = counts.most_common(1)[0]
if count >= len(results) // 2 + 1: # 과반수 동의
return most_common_val
else:
# 충돌 해결 불가 -> 추가 검증 요청
raise ValueError(f"Cross-source conflict unresolved: {counts}")
# 에이전트 정책 프롬프트 (논문 Table 13 기반)
POLICY_PROMPT = """
You are a tool-orchestration policy model.
Rules:
- If a tool fails, diagnose WHY before retrying:
* TimeoutError -> retry once, then fallback
* Missing field -> remap to observed runtime schema
* Argument error -> repair argument structure
* Conflicting results -> cross-check all sources before finalizing
- Finish ONLY when all required evidence branches are resolved.
- Treat 'success=false', missing fields, and errors as UNRESOLVED.
- Do not mistake partial results for final answers.
Return JSON: {"action": "call_tool|retry|fallback|finish", "reason": "..."}
"""Terminology
Related Papers
Nearly Half of LG Smart TV Apps Contain Residential Proxy SDKs
6,038개의 LG·Samsung 스마트 TV 앱을 스캔했더니 2,058개에서 사용자의 IP를 몰래 팔아 트래픽을 중계하는 Residential Proxy SDK가 발견됐다. TV는 컴퓨터처럼 감시받지 않아서 프록시 호스트로 거의 이상적인 환경이다.
Prompt Injection as Role Confusion
LLM이 시스템 프롬프트, 사용자 입력, 툴 출력을 구분하지 못하는 구조적 결함이 prompt injection의 근본 원인이라는 ICML 2026 논문으로, 현재 LLM 보안 아키텍처의 한계를 명확히 분석한다.
GPT-5.5 hallucinates 3x more than MIT-licensed GLM-5.2
모델 크기가 커질수록 성능이 좋아진다는 통념에 반해, 오픈소스 753B 모델 GLM-5.2가 추정 1~2T 규모의 GPT-5.5보다 환각 비율이 3배 낮다는 벤치마크 결과가 나왔다. 단순히 파라미터 수와 벤치마크 점수만으로 모델을 선택하면 실제 업무에서 낭패를 볼 수 있다는 경고다.
Greed Is Learned: Visible Incentives as Reward-Hacking Triggers
AI 에이전트에게 KPI/잔고 대시보드를 보여주며 RL 학습시키면, 안전 정렬이 이미 된 모델도 대시보드를 위해 위험한 행동을 선택하게 된다.
How Much Can We Trust LLM Search Agents? Measuring Endorsement Vulnerability to Web Content Manipulation
공격자가 웹에 조작 페이지를 올리면 LLM 검색 에이전트가 그걸 사실처럼 추천해버리는 취약점을 13개 모델에서 체계적으로 측정한 연구.
MTG Bench: Testing how well LLMs can play Magic
카드 게임 MTG의 규칙 준수 능력으로 LLM의 복잡한 규칙 추론 능력을 측정하는 독창적인 벤치마크로, gpt-5.5가 95.4점으로 1위를 차지했다.
Related Resources
Original Abstract (Expand)
Large language models are increasingly deployed as agents that solve tasks by interacting with external tool environments. Although recent tool-use benchmarks increasingly cover complex task settings, they still largely assume clean, stable, and trustworthy tool environments, leaving tool-environment unreliability insufficiently examined. We introduce ToolBench-X, a benchmark for evaluating agents under recoverable reliability hazards. ToolBench-X contains executable multi-step tasks across diverse domains and sequential, parallel, and mixed workflows, each paired with deterministic tools and a canonical final answer for automatic evaluation. Starting from clean tool environments, ToolBench-X injects five structured hazard types: Specification Drift, Invocation Error, Execution Failure, Output Drift, and Cross-source Conflict. Crucially, each injected instance remains solvable through at least one valid recovery path, such as retrying, fallback, verification, or cross-checking. Experiments reveal a substantial reliability gap: agents that perform well with reliable tools often fail under recoverable hazards. Further analysis shows that failures are driven less by tool-use volume or inference budget than by limited hazard diagnosis and ineffective recovery. Targeted recovery hints recover many failed tasks, while test-time scaling yields more limited gains. These results suggest that tool-use evaluation should move beyond function-call accuracy toward task completion under unreliable tool environments. The code and data is available at https://github.com/Foreverskyou/ToolBench-X.