How to Test Your Agents on Real Tasks With Harbor - Xander Song, Arize AI

한 줄 핵심

Harbor를 이용해 실제 데이터와 실제 작업 기준으로 에이전트를 샌드박스에서 평가하면, 감이 아니라 증거에 기반해 프롬프트·도구·스킬 변경의 효과를 빠르게 검증할 수 있다.

시간별 요약

1. 0:00
   증거에 기반한 배포 Harbor는 실제 데이터가 있는 격리된 샌드박스에서 에이전트를 평가하는 오픈소스 프레임워크이며, 목표는 감이 아니라 증거로 에이전트와 하네스를 반복 개선하는 데 있다.
2. 1:28
   Harbor가 무엇인지 자연어 지시로 정의한 현실적인 작업을 에이전트에 주고, 환경 내부의 결과를 검증하는 verifier로 성공 여부를 채점하는 구조다. 같은 작업과 검증기를 유지한 채 구현만 바꾸면 개선과 회귀를 빠르게 판단할 수 있다.
3. 3:37
   작업, 환경, 검증기의 구조 작업은 markdown 지시문, 환경은 Docker file로 정의되며, 데이터는 SQLite나 git repository처럼 무엇이든 들어갈 수 있다. 각 작업에는 test directory의 스크립트형 verifier가 붙고, 여러 trial을 독립적으로 돌려 확률적인 LLM 동작을 보정한다.
4. 6:08
   Trajectories, job, oracle ATIF는 에이전트의 내부 단계를 기록하는 JSON 추적 형식으로, 디버깅과 로그에 유용하다. 전체 작업 묶음과 여러 trial, verifier 실행, trajectory 수집을 합친 실행 단위를 Harbor는 job으로 부르며, oracle은 에이전트 투입 전에 데이터·환경·검증기의 정합성을 점검하는 정답 스크립트다.
5. 7:58
   실패하는 migration 수정 예시 실패한 migration을 고치는 코딩 에이전트 사례로, 지시문·SQL/DDL·소스코드·검증 스크립트·정답 스크립트가 어떻게 배치되는지 설명한다. 검증기는 에이전트가 수정한 파일과 데이터베이스 상태를 확인하며, 실행 중에는 검증기와 해답이 보이지 않도록 분리된다.
6. 10:48
   블랙박스 통합 테스트로서의 검증기 검증기는 에이전트 구현을 보지 않고 결과물과 사이드 이펙트만 평가하는 블랙박스 방식이 이상적이며, 통합 테스트와 같은 역할을 한다. 이 덕분에 구현을 크게 바꿔도 작업 정의와 검증 기준을 고정한 채 안전하게 리팩터링할 수 있다.
7. 14:21
   병렬 샌드박스에서의 대규모 실행 작업과 trial이 모두 독립적이어서 Docker나 Daytona, Modal, E2B 같은 샌드박스에서 수평 확장이 가능하다. 여러 에이전트와 여러 trial을 병렬로 돌린 뒤 pass@k 같은 집계 지표로 빠르게 성능을 비교할 수 있다.
8. 17:04
   Phoenix와의 연동 Harbor의 dataset, trial, reward, trajectory는 Phoenix의 dataset, experiment, evaluation, open inference 형식으로 매핑된다. 이를 통해 추적, 버전 관리, 시각화, CLI와 MCP 접근이 가능해지고, Harbor만 단독으로 쓸 때보다 실험 관찰성이 높아진다.
9. 20:37
   Phoenix 팀이 Harbor를 쓰는 방식 Phoenix는 단일 노드 서버, SQLite/Postgres, REST·GraphQL, CLI·MCP·서버사이드 에이전트 Pixie로 구성되며, 이 전체를 Docker에 넣어 Harbor로 평가한다. 실제 사용자 질문을 반영한 작업을 만들고, 종료 후에는 REST 호출이나 SQL 조회로 결과를 검증한다.
10. 25:07
    Harbor가 실행을 오케스트레이션하는 방식 Harbor는 호스트 머신에서 동작하는 CLI 오케스트레이터로, Docker 이미지 안의 정해진 스크립트를 찾아 작업 시작·verifier 실행·oracle 실행을 조율한다. 따라서 핵심 계약은 구현이 아니라 스크립트 배치와 이미지 구조에 있다.
11. 29:24
    복잡한 시스템과 데이터 크기 분산 시스템이나 대형 데이터셋은 단일 Docker로 감싸기 어려워 Harbor 적용이 더 까다롭고, 경우에 따라 인터페이스 경계를 잘라야 한다. 다만 전체 데이터를 다 넣을 필요는 없고, 테스트하려는 질문과 행동에 필요한 부분만 골라서 현실적으로 구성하면 된다.
12. 33:21
    SQL 도구로 유도한 사례 연구 REST나 GraphQL만으로는 집계 질문이 비효율적이어서 read-only SQL 도구를 추가했지만, 에이전트가 언제나 올바른 도구를 고르지 못하는 문제가 있었다. 프롬프트에 SQL 사용 조건을 명시하고, synthetic question 데이터셋과 oracle 기반 verifier로 실제로 SQL 사용이 늘고 tool call 수가 줄었는지 검증했다.
13. 38:34
    Phoenix에서 데이터셋과 실험 보기 Phoenix에서는 데이터셋 예시와 정답, version history, experiment별 reward와 비용, 지연시간, tool call 수를 한 화면에서 확인할 수 있다. 이 예시에서는 correctness는 유지되었고, 최적화 목표였던 tool call 감소와 SQL 사용 증가가 지표로 드러났다.
14. 44:10
    작업별로 job 비교하기 두 experiment를 나란히 놓고 task 단위로 reward, tool count, turn 수, SQL/GraphQL 사용 변화를 비교해 개선 여부를 확인한다. 일부 경우에는 trajectory까지 내려가 실제로 어떤 도구 호출 경로가 바뀌었는지 시각적으로 검증할 수 있다.
15. 48:31
    회귀 테스트와 스킬 회귀 테스트는 아직 초기 단계이지만, Harbor에서는 특히 workflow를 담는 skill 단위로 happy path를 검증하는 방식이 잘 맞는다. 필요하면 verifier가 trajectory를 들여다보는 더 결합된 테스트도 가능하지만, 유지보수성과 flakiness를 함께 고려해야 한다.

실무 인사이트

• 에이전트 평가는 모델 자체보다도 도구, 프롬프트, 스킬, 하네스가 합쳐진 시스템 전체를 대상으로 잡아야 실제 운영 품질을 정확히 볼 수 있다.
• 정답 검증이 가능한 작업에서는 trajectory를 보지 않는 순수한 verifier가 가장 강하지만, 최적화 목표가 도구 사용량 같은 행동 지표일 때는 제한적으로 trajectory를 섞는 것이 실용적이다.
• 데이터셋과 검증기를 먼저 잘 만들면, 이후에는 동일한 작업 묶음으로 구현 변경의 회귀를 매우 빠르게 잡아낼 수 있다.