도구로 조사하는 AI 에이전트를 만들고 추측으로 답하지 않는지 테스트하기

## 조사 엔진과 서비스별 플러그인 분리하기 시스템을 명시적인 계층으로 구성하십시오. 사용자용 진입점, 설정 로드, 조사 엔진, 도구 관리자, 그리고 교체 가능한 출처, 도구 모음, 프롬프트, 목적지를 두십시오. 진입점은 요청을 라우팅하고 로깅을 설정해야 합니다. 설정 계층은 설정값을 검증하고 통합 기능을 구성해야 합니다. 엔진은 도구를 선택하고, 증거를 수집하고, 결과를 분석하고, 선택적으로 권한이 있는 목적지에 발견 사항을 반환해야 합니다. 제공자별 동작은 플러그인 뒤에 두어 핵심 루프가 안정적인 도구 계약을 기준으로 추론할 수 있게 하십시오. 검증된 설정에서 통합 기능을 동적으로 불러오고, 출처 수집, 조사, 목적지 쓰기를 서로 구분하여 읽기 전용 진단이 암묵적으로 외부 상태 변경으로 바뀌지 않게 하십시오. ## 도구는 얇은 래퍼로 만들고 실패 내용을 정확히 돌려주기 하나의 외부 엔드포인트나 작업을 감싸는 얇은 래퍼를 우선하십시오. 각 통합 기능에는 검증된 소규모 설정 객체, 명시적인 선행 조건 또는 상태 검사, 매개변수가 기반 요청에 직접 대응하는 도구 함수를 제공하십시오. 투명한 전송 호출을 사용하면 동작과 오류를 더 쉽게 살펴볼 수 있는 경우에는 무거운 클라이언트 추상화를 피하십시오. 호출자가 스스로 바로잡을 수 있을 만큼 충분한 실패 맥락을 반환하십시오. 정확한 쿼리나 명령, 시간 범위, 필터, 관련 매개변수, 응답 상태, 기반 오류 메시지를 포함하십시오. 데이터 없음 결과에는 무엇을 어디에서 검색했는지 명시해야 합니다. 접근 제어를 유지하고, 실행 가능한 명령을 검증하고, 도구를 기본적으로 읽기 전용으로 유지하며, 기밀 정보를 절대 노출하거나 커밋하지 마십시오. ## AI가 읽기 전에 도구가 돌려주는 데이터 양 제한하기 도구를 통해 범위가 제한되지 않은 컬렉션을 절대 노출하지 마십시오. 대규모 결과 집합을 반환할 수 있는 엔드포인트에는 서버 측 필터를 요구하고, 호출자가 가장 중요한 범위 매개변수를 생략할 수 없도록 스키마를 설계하십시오. 제한 없는 목록 작업 때문에 발생하는 토큰 또는 메모리 초과는 프롬프트 문제가 아니라 도구 계약의 결함입니다. 원격 서비스가 충분히 필터링할 수 없으면 최대 깊이, 결과 수 제한, 필드 선택, 구조화된 쿼리 표현식과 같은 명시적인 클라이언트 측 제어를 추가하십시오. 잘림과 적용된 범위를 보고하십시오. 기본 응답은 간결하게 유지하되, 조사에 더 많은 증거가 필요할 때는 대상을 한정하여 확장할 수 있게 하십시오. ## 옛 설정 이름도 계속 받고 공통 동작은 알맞은 클래스 계층에 두기 설정 필드의 이름을 바꿀 때는 더 이상 권장되지 않는 이름도 추가 입력으로 받아 현재 필드에 매핑하고, 사용 중단 경고를 표시하십시오. 호환성 때문에 생성된 설정이나 후속 로직이 오염되지 않도록 공개 스키마와 직렬화된 결과에는 현재 이름만 유지하십시오. 이름이 지정된 통합 기능에 필드, 메서드, 시간 제한 또는 재시도 정책을 추가하기 전에 클래스 계층과 같은 계열의 구현을 살펴보십시오. 공유 동작은 실제로 필요한 가장 일반적인 계층에 배치하십시오. 명시적인 시도 횟수와 지연 정책을 갖춘 검증된 재시도 기능을 사용하십시오. 표준 메커니즘으로 요구사항을 표현할 수 없는 경우에만 사용자 정의 루프를 작성하고 그 이유를 문서화하십시오. ## 단위 테스트부터 에이전트 평가까지 세 계층으로 테스트하기 서로 보완하는 세 계층을 사용하십시오. 단위 테스트는 로컬 동작을 격리하고, 통합 테스트는 도구와 서비스의 경계를 실행하며, 에이전트 평가는 현실적인 프롬프트와 픽스처를 사용해 처음부터 끝까지 조사 동작을 검증합니다. 새로운 로컬 동작에는 단위 테스트 범위가 필요하고, 새로운 통합 기능에는 경계 테스트 범위가 필요하며, 복잡한 조사에는 평가 사례가 필요합니다. 소스 구조와 테스트 구조를 일치시키십시오. 요청 동작을 테스트할 때는 상위 수준 함수를 대체하지 말고 전송 계층의 HTTP 모의를 사용하여 헤더, URL, 매개변수, 어댑터가 실제로 실행되게 하십시오. 실제 도구는 의도적으로 설정한 환경에서만 실행하고, 일반적인 결정론적 테스트와 모델 자격 증명이나 외부 서비스가 필요한 평가를 구분하십시오. ## 지어낸 답(환각)을 잡아내는 평가 만들기 각 프롬프트가 평가에서 검사하는 정확한 사실을 요청하도록 만드십시오. 주입한 고유 식별자, 정확한 개수, 제목, 오류 코드처럼 쿼리해야만 발견할 수 있는 예상값을 우선하십시오. 예상 답변은 에이전트에게 보이지 않아야 합니다. 답변이 너무 일반적이어서 발견 사실을 입증할 수 없다면 올바른 도구가 호출되었다는 증거를 요구하십시오. 인식이 아니라 발견을 테스트하십시오. 중립적인 리소스 이름, 현실적인 시나리오, 구현이나 가능한 해결책을 드러내지 않는 프롬프트를 사용하십시오. 모델이 도메인 지식으로 추측할 수 있는 일반적인 단언을 피하십시오. 등록된 테스트 태그, 고유한 리소스 이름, 고정된 종속 항목 또는 이미지 버전만 사용하고, 준비 과정에서 서비스가 작동함을 입증할 수 없으면 명시적으로 실패 종료하십시오. ## 여러 테스트 실행이 클라우드 리소스를 서로 망가뜨리지 않고 함께 쓰게 하기 여러 브랜치의 클라우드 기반 평가가 동일한 계정에서 겹쳐 실행될 수 있다고 가정하십시오. 준비 과정은 멱등적이어야 합니다. 리소스가 이미 존재해도 실패하지 않고 생성하거나 재사용해야 합니다. 정리 과정에서는 다른 실행이 아직 사용할 수 있는 정적 공유 리소스를 절대 지우면 안 됩니다. 정리를 생략하거나 고유한 실행 범위 식별자로 제한하십시오. 준비 상태만 확인하지 말고 실제 API 응답으로 기능을 검증하십시오. 생성 경쟁 상태를 처리할 수 있도록 재시도 범위를 제한하여 폴링하고, 예상 콘텐츠가 끝내 나타나지 않으면 조기에 실패 처리하며, 시간 초과 시 진단 정보를 수집하십시오. 여러 테스트에 같은 서비스가 필요하면 표준화된 공유 인프라를 재사용하되, 각 테스트의 데이터와 식별자는 격리하십시오. ## 터미널 화면 깨짐과 평가 하락의 원인을 실제 실행 기록으로 찾기 대화형 터미널 결함은 의사 터미널에서 재현하고 원시 이스케이프 시퀀스를 수집하십시오. 커서 이동과 지우기 작업을 렌더링된 프레임 높이와 비교한 다음, 강제 터미널 인메모리 스트림을 통해 렌더러를 테스트하십시오. 드리프트를 만드는 프레임 또는 새로 고침 계약을 수정하십시오. 터미널 하단에서 동작이 달라질 때 커서 이동만 무작정 수정하지 마십시오. 에이전트 평가의 회귀에서는 소스 차이나 집계 통계에 의존하기 전에 동일한 테스트와 모델에 대한 기준 트레이스 하나와 현재 트레이스 하나를 비교하십시오. 렌더링된 프롬프트, 도구 호출 순서, 호출별 지표, 반환된 증거를 살펴보십시오. 템플릿이 소스에서는 커지지만 런타임에서는 작아질 수 있고, 집계 분산은 실행별로 발생하는 결정론적 변화를 숨길 수 있습니다. 의심되는 리비전에서 가장 눈에 띄는 파일만 되돌리기 전에 전체 변경 집합을 읽으십시오. ## 포맷과 검사는 대상 파일에만 하고 허락 없이 푸시하지 않기 저장소별 스타일, 타입 지정, 테스트, 버전 관리 정책을 따르십시오. 다만 사용자가 명시적으로 요청하거나 적용되는 워크플로에서 요구하지 않는 한, 관련 없는 파일을 변경한다고 알려진 광범위한 자동 수정, 서식 지정 또는 저장소 전체 검사를 실행하지 마십시오. 자동 서식 지정과 린트는 범위 안의 파일로 한정하고, 해당 테스트와 함께 검토 범위를 집중하십시오. 프로젝트 규칙에 따라 임포트와 공유 유틸리티를 배치하고, 되돌릴 수 있는 이력을 보존하며, 명시적인 권한이 없으면 강제적인 이력 재작성을 피하십시오. 로컬 작업 자체는 커밋, 푸시, 게시 또는 외부 상태 변경을 승인하지 않습니다. 어떤 검증을 실행했고 어떤 검사를 의도적으로 제외했는지 보고하십시오. ## 문서 페이지나 제목이 바뀌면 모든 참조 고치기 공개 웹사이트를 참조하기 전에 저장소 문서를 프로젝트 동작의 일차 출처로 사용하십시오. 페이지가 이동하거나 파일 이름이 바뀌거나 제목 변경으로 앵커가 달라지면 문서, 소스 문자열, 최상위 안내서, 주석을 포함한 전체 저장소에서 이전 경로와 앵커를 검색한 뒤 영향을 받은 모든 참조를 업데이트하십시오. 이름만 비슷하고 활성화되지 않은 설정이 아니라 문서 시스템의 실제 내비게이션 소스를 업데이트하십시오. 필요한 빈 줄과 유효한 제목 계층을 포함하여 렌더러별 구조를 유지하십시오. 오래된 기능 목록과 반복적인 보안용 군더더기를 피하고, 간결한 예시와 통합된 문제 해결 블록을 우선하십시오. 통합 기능을 추가할 때는 개요, 인덱스, 전용 페이지, 내비게이션 항목, 시각 자료를 함께 업데이트하십시오.