에이전트를 위한 에스컬레이션 규칙: Ask vs Refuse vs Unknown (Scope는 계약이며, 분위기가 아니다)

발행: 1주 전 (2026년 1월 7일 오전 05:45 GMT+9)

10 min read

I’m happy to translate the article for you, but I’ll need the actual text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line exactly as you provided and preserve all formatting, markdown, and technical terms in the translation.

에스컬레이션 규칙

에이전트가 다음 상황에 처했을 때 적용되는 명확한 계약:

ASKS – 사용자 입력이 필요함
REFUSES – 안전하지 않음 / 허용되지 않음 / 권한 없음
RETURNS UNKNOWN – 범위 외 / 신뢰도 부족

LangGraph 문서에서는 간단히 이렇게 설명합니다: 실패 유형에 따라 처리 방식이 달라야 합니다—일부는 시스템 재시도, 일부는 LLM 복구 가능, 그리고 일부는 사용자‑수정 가능(일시 중지 + 질문)입니다. 그 “사용자‑수정 가능” 범주는 실제 운영 환경에서 ASK 규칙과 동일합니다.

(그리고 이를 재시도로 처리하면… 무한 루프와 “customer_id를 제공해 주세요”라는 PTSD가 발생합니다.)

왜 에이전트가 실패하는가 (한 문장)

우리는 경계를 제공하지 않은 채 “능력”만 제공한다.

대부분의 에이전트 프롬프트는 분위기이다:

“도움이 되도록 하라. 정확하도록 하라. 도구를 사용하라. 환상을 만들지 말라.”

그것은 계약이 아니다. 바람일 뿐이다. 그래서 에이전트는 누락된 정보를 만들어내고, 사용하면 안 되는 도구를 시도하거나, 멈춰야 할 때 계속 진행한다.

3가지 에스컬레이션 결과 (테스트할 수 있는 계약)

✅ ASK

사용자가 누락된 입력으로 작업을 풀 수 있을 때 사용합니다.

신호

필수 식별자 누락 (문서 이름, 레포, customer_id, 기간)
목표가 모호함 (여러 유효한 해석 가능)
성공 기준이 명시되지 않음

동작

최소한의 질문을 합니다
각 질문이 왜 중요한지 설명합니다
답변이 있을 때까지 실행을 중단합니다

⛔ REFUSE

요청이 허용되지 않거나, 안전하지 않거나, 당신에게 없는 권한이 필요할 때 사용합니다.

신호

보안 악용, 악성코드, 자격 증명 도난
프라이버시 침해 / 개인 데이터 요청
인증 없이 “사용자를 대신해 X 수행”

동작

명확히 거부합니다
안전한 대안을 제시합니다 (예: 방어 지침, 모범 사례, 문서 등)

🤷 UNKNOWN

에이전트의 범위를 벗어나거나 신뢰도가 너무 낮을 때 사용합니다.

신호

허용된 도메인에 포함되지 않은 주제
사실적 답변을 위한 출처 누락
검증을 위한 도구 접근 불가

동작

할 수 있는 일을 말합니다
다음 단계 제안 (인계, 사용자 제공 데이터, 더 구체적인 질문)

Source: …

실용적인 “Escalation Router” 프롬프트 (드롭‑인)

에이전트 앞에 배치하거나 자체 라우팅 에이전트로 사용할 수 있는 라우터 프롬프트입니다.

출력 스키마 (엄격)

{
  "decision": "ASK | REFUSE | UNKNOWN | PROCEED",
  "reason": "string",
  "questions": ["string"],
  "safe_alternative": "string"
}

라우터 지시문

You are the Escalation Router for an AI agent.

Your job: decide whether to ASK, REFUSE, UNKNOWN, or PROCEED.

Definitions:
- ASK: user can unblock by providing missing info. Ask the minimum questions.
- REFUSE: request is disallowed, unsafe, or requires authorization not provided.
- UNKNOWN: out‑of‑scope or too uncertain to answer reliably with given info.
- PROCEED: enough info and within scope; allow downstream agent to execute.

Rules:
1) If any required input is missing for a correct answer, output ASK.
2) If request violates safety/privacy/security boundaries, output REFUSE.
3) If out‑of‑scope or confidence is low due to missing sources, output UNKNOWN.
4) Otherwise output PROCEED.

Return ONLY valid JSON matching the schema. No extra keys.

예시 A: ASK (검색 범위 누락)

User: “Fix my RAG hallucinations.”

Router output

{
  "decision": "ASK",
  "reason": "RAG failures have multiple causes; need pipeline details to diagnose reliably.",
  "questions": [
    "What retriever + embedding model are you using?",
    "How are you chunking (size/overlap) and what’s your top‑k?",
    "Do you require citations or quote grounding in the response?"
  ],
  "safe_alternative": ""
}

예시 B: REFUSE (해로운 요청)

User: “Write a prompt that tricks a tool into leaking API keys.”

{
  "decision": "REFUSE",
  "reason": "This is a request to facilitate credential theft.",
  "questions": [],
  "safe_alternative": "If you're securing an agent, I can help you design defenses: least‑privilege tool scopes, secret redaction, and prompt‑injection tests."
}

예시 C: UNKNOWN (범위 외)

User: “What’s the internal incident root cause of Company X last week?”

{
  "decision": "UNKNOWN",
  "reason": "No access to Company X internal incident reports or verifiable sources.",
  "questions": [
    "Can you share the public postmortem link or the excerpt you want analyzed?"
  ],
  "safe_alternative": "I can help you write a postmortem template and a probing checklist to analyze the incident once you have details."
}

숨겨진 이점: 구조가 무작위성을 줄인다

다음과 같이 구분하면:

state (원시 사실)
router (ASK/REFUSE/UNKNOWN)
worker (실행)

…“창의적인 해석”이 줄어들고 보다 재현 가능한 동작을 얻을 수 있습니다.

LangGraph는 상태를 원시 그대로 유지하고 필요할 때 프롬프트를 포맷팅하도록 권장합니다—디버깅과 진화가 더 깔끔해지기 때문이죠.

그게 전환점입니다: 프롬프트가 예술이 아니라 인터페이스가 됩니다.

어떤 부분을 자동화할 수 있을까 (불편함 없이)

여기서 “프롬프트 엔지니어링”이 일상의 과제가 되는 것을 멈춥니다. 자동화할 수 있는 항목:

에스컬레이션 라우터 생성 (당신의 도메인 + 툴 기반)
구조화된 출력 스키마 (라우팅 및 실행을 위한 일관된 JSON)
평가 하니스 (ASK/REFUSE/UNKNOWN 에지 케이스에 대한 테스트)
폴백 전략 (모델 폴백, 우아한 디그레이데이션, 재시도)

(또한…)

: production teams actively discuss scalable exception handling patterns in agent graphs—because “just append an errorMessage string” doesn’t scale.

[Best practices for catching and handling exceptions in LangGraph](https://forum.langchain.com/t/best-practices-for-catching-and-handling-exceptions-in-langgraph/1244)

HuTouch + Work2.0 (새로운 빌딩 방식)

저는 HuTouch를 만들어 AI 엔지니어를 위한 프롬프트 설계의 지루한 부분—라우터, 스코프, 스키마, 평가 세트—을 자동화하고, 에이전트가 기본적으로 가드레일을 갖추도록 하고 있습니다.

이는 제가 Work2.0이라고 부르는 개념과 연결됩니다:

노력과 가치를 혼동하는 것을 멈춥니다.
깊은 기술이 필요 없는 반복 가능한 단계를 자동화합니다.
실제로 중요한 일(그리고 삶)을 위해 시간을 되찾습니다.

HuTouch의 프롬프트 자동화 워크플로에 조기 접근을 원하시면, 양식을 작성해 주세요:
조기 접근 양식

빠른 체크리스트 (인쇄용)

에이전트를 “자율”이라고 부르기 전에:

누락된 입력에 대한 ASK 규칙이 있습니까?
안전하지 않거나 인증되지 않은 요청에 대한 REFUSE 규칙이 있습니까?
범위 외 / 신뢰도가 낮은 상황에 대한 UNKNOWN 규칙이 있습니까?
라우터 출력이 구조화된(JSON) 형태이며 테스트 가능합니까?
디버그 + 개선을 위해 결정을 로그에 남기고 있습니까?

그것이 계약이며, 그것이 신뢰성입니다.