실제로 출시되는 에이전트들
에이전트 하이프 사이클(hype cycle)의 해답은 명확합니다. 프로덕션 환경에서 에이전트로 승리하는 팀들은 자율적인 스웜(swarms)을 구축하지 않습니다. 그들은 지루한 시스템을 구축합니다.
한 달 동안 프로덕션에서 무엇이 작동하는지 지켜보았습니다. 패턴은 명확합니다. 돈을 벌어다 주거나 시간을 절약해 주는 에이전트들은 끝없는 루프를 돌지 않습니다. 관찰 가능하며, 범위가 제한되어 있습니다. 필요할 때는 인간에게 도움을 요청합니다.
이는 에이전트 플랫폼을 평가하는 방식을 바꿉니다.
프로덕션에서 에이전트를 사용하는 팀들은 다음 사항에 의존합니다:
- 수동 프롬프트 구성
- 기성 모델(Off-the-shelf models)
- 인간의 개입 전 10단계 이하의 제한된 실행
이것이 바로 엔지니어링 규율입니다.
데모에서는 완전한 자율성을 가진 자기 수정형 에이전트를 보여줍니다. 하지만 실제로 출시되는 에이전트는 모습이 다릅니다. 그들은 명시적인 게이트(gates)를 사용합니다.
고객 서비스 에이전트는 5단계를 처리한 후 상급자에게 전달(escalate)합니다. 코딩 에이전트는 테스트를 실행하지만 리뷰 없이 코드를 병합(merge)하지 않습니다. 데이터 에이전트는 쿼리를 실행하기 전에 승인을 요청합니다. 이것들은 실제로 작동하는 아키텍처적 선택입니다.
성공적인 에이전트는 좁고 반복 가능한 문제를 해결합니다. 반품 처리, 티켓 분류, 또는 컴플라이언스 이슈 플래그 지정 등을 수행합니다. 범위가 좁다는 것은 실패를 예측할 수 있고 디버깅이 더 쉽다는 것을 의미합니다.
에이전트를 출시할 때 가장 어려운 부분은 에이전트를 더 똑똑하게 만드는 것이 아닙니다. 에이전트를 가시화하고 관리 가능하게 만드는 것입니다.
팀들이 자주 실패하는 이유는 다음과 같습니다:
- 에이전트가 실패했을 때 무엇을 했는지 설명할 수 없음
- 잘못된 결과의 추적이 불가능함
- 비용 경계를 설정할 수 없음
- 도구 승인을 강제할 수 없음
- 결정을 이해하기 위해 세션을 재현(replay)할 수 없음
이것들은 인프라 문제입니다.
플랫폼을 선택할 때, 질문을 바꾸십시오.
- 속도에 대해 묻지 마십시오. 모든 결정과 추적 경로를 볼 수 있는지 물으십시오.
- 모델 지원 여부에 대해 묻지 마십시오. 한 곳에서 여러 런타임을 관리할 수 있는지 물으십시오.
- 자율성에 대해 묻지 마십시오. 인간의 게이트를 추가하는 것이 얼마나 쉬운지 물으십시오.
승리하는 인프라는 관찰 가능성, 거버넌스, 그리고 제한된 자율성을 제공합니다. 그것은 컨트롤 플레인(control plane)입니다. 신뢰할 수 있는 에이전트와 새벽 3시에 프로덕션을 망가뜨리는 에이전트를 구분해 줍니다.
프로덕션 팀들은 이제 에이전트를 구축할 수 있는지 묻지 않습니다. 어떻게 하면 에이전트를 안정적으로 운영할 수 있는지를 묻습니다.
지루한 인프라가 승리합니다.
Source: https://dev.to/paultwist/the-agents-that-actually-ship-why-boring-beats-autonomous-49li
Optional learning community: https://t.me/GyaanSetuAi