차단은 실패가 아닙니다: 에이전트에게는 경계 피드백이 필요합니다
대부분의 에이전트 설정은 차단된 동작을 도구 실패(tool failure)로 취급합니다.
에이전트가 도구를 호출합니다. 요청이 규칙을 위반합니다. 시스템이 일반적인 오류를 반환합니다. 도구 호출이 실패합니다.
처음에는 이것이 괜찮아 보입니다. 안전하지 않은 동작이 중단되었으니까요. 하지만 이는 문제의 절반만 해결할 뿐입니다.
일반적인 오류는 에이전트가 자신의 한계 내에서 작동하도록 돕지 못합니다. 정책적 결정을 단순한 노이즈로 만들어 버립니다. 에이전트는 해결책을 추측하려 할 수도 있고, 같은 실수를 반복하거나 다른 페이로드를 시도할 수도 있습니다. 이는 무의미한 재시도의 루프를 만듭니다.
차단된 동작은 예상치 못한 충돌(crash)이 아니라 구조화된 결정이어야 합니다.
요청이 차단될 때 외부 시스템은 변경되어서는 안 됩니다. 하지만 응답은 에이전트에게 어떻게 안전하게 진행해야 하는지 알려주어야 합니다.
단순한 오류 대신 구조화된 응답을 사용하세요.
에이전트가 계획을 세우는 동안 변경된 파일에 쓰기를 시도한다고 가정해 봅시다. 일반적인 오류는 "실패(failed)"라고 말합니다. 구조화된 응답은 다음과 같이 말합니다:
- 결정 상태: 충돌(conflict)
- 결과 상태: 영향 없음(no impact)
- 이유: 오래된 상태(stale state)
- 다음 작업: 대상 상태 재읽기(re-read target state)
이제 에이전트는 목표가 불가능한 것이 아님을 알게 됩니다. 단지 정보를 업데이트하기만 하면 됩니다. 에이전트는 추측을 멈추고 올바른 다음 단계를 밟습니다.
이는 많은 시나리오에서 작동합니다:
- 경로가 범위를 벗어난 경우, 허용된 경로를 제안합니다.
- 효과가 이미 존재하는 경우, 결과를 재사용하도록 제안합니다.
- 영향이 너무 큰 경우, 사람의 검토를 기다리도록 제안합니다.
이것이 경계를 느슨하게 만드는 것은 아닙니다. 동작은 여전히 차단된 상태로 유지되며, 시스템은 안전하게 유지됩니다. 단지 막다른 길을 안내된 경로로 바꾸는 것뿐입니다.
이를 보안과 균형 있게 다루어야 합니다. 정밀한 피드백은 악의적인 에이전트가 경계를 탐색(probe)하는 데 도움을 줄 수 있습니다.
오래된 데이터나 잘못된 형식의 입력과 같은 운영상의 마찰에 대해서는 명확한 이유 코드(reason codes)를 사용하세요. 에이전트가 의심스러운 행동을 보이거나 힌트를 무시하면, 일반적인 거부 또는 사람의 검토로 전환하십시오.
에이전트 피드백을 감사 점수(audit scores)와 분리하십시오. 에이전트는 어떻게 규정을 준수해야 하는지 알아야 합니다. 시스템은 에이전트가 부적절하게 행동하고 있는지 알아야 합니다. 이 두 가지 역할을 혼동하지 마십시오.
에이전트가 실제 시스템에서 작동할 만큼 유용해지고 있기 때문에 경계가 존재하는 것입니다. 실제 업무에는 규칙과 한계가 있습니다.
실패만을 반환하는 경계는 벽입니다. 가이드를 제공하는 경계는 도구입니다.
'Blocked'는 다음을 의미해야 합니다:
- 요청한 영향이 발생하지 않음.
- 원인이 파악됨.
- 다음으로 취할 안전한 조치가 명확함.
출처: https://dev.to/davidloibner/blocked-is-not-failed-agents-need-boundary-feedback-bbg
선택 사항 학습 커뮤니티: https://t.me/GyaanSetuAi