범위가 엄격하고 수년간 운영되는 소규모 에이전트

첫 번째 에이전트 프로젝트 이후 12개월 동안 조직에서 여전히 실행 중인 내용을 살펴보면 패턴이 나타납니다. 전체 워크플로를 처리할 인상적인 에이전트가 사라졌습니다. 매주 화요일 아침에 보고서 형식을 다시 지정하는 작은 기능이 여전히 존재하며 몇 달 동안 아무도 그것에 대해 생각하지 않았습니다.

그것은 야망의 실패가 아닙니다. 이것이 범위가 하는 일입니다.

광범위한 에이전트가 붕괴되는 이유

광범위한 에이전트는 잘못될 수 있는 방법이 많으며, 각 방법은 개별적으로 신뢰를 약화시킵니다. 8가지 상황을 잘 처리하고 9번째 상황을 나쁘게 처리하며, 어느 상황이 9번째인지 예측할 수 없기 때문에 모든 출력을 주의 깊게 검토합니다.

모든 출력을 주의 깊게 검토한 후에도 상담원은 시간을 절약하지 못했습니다. 그것은 그것을 하는 것에서 확인하는 것으로 옮겼고, 익숙하지 않은 일을 확인하는 것이 익숙한 일을 하는 것보다 분명히 빠르지는 않습니다.

광범위한 에이전트는 또한 평가에 저항합니다. "고객 문의 처리"에 대한 작성 기준은 일반적으로 작성되지 않을 만큼 까다롭습니다. 이는 품질이 점수화되지 않고 저하가 눈에 띄지 않는다는 것을 의미합니다.

좁은 에이전트가 살아남는 이유

좁은 에이전트는 문장으로 설명할 수 있고 문장으로 설명할 수 있는 모든 항목을 평가할 수 있습니다. 좋은 출력이 어떤 것인지 기록하고, 이에 대한 모든 실행에 점수를 매기고, 검사가 실패하면 에이전트를 중지할 수 있습니다.

또한 타고난 소유자가 있습니다. "보고서 재구성자의 소유자는 누구입니까?"에 대한 대답은 분명합니다. "고객 문의 에이전트를 소유한 사람"은 그렇지 않으며 소유자가 없는 에이전트는 고아가 됩니다.

그리고 그 비용은 읽을 수 있습니다. 좁은 에이전트에 기인한 지출은 다음과 같이 해석할 수 있습니다. 실행 횟수, 실행당 금액, 결과. 광범위한 상담원에게 발생한 지출은 누구도 조치를 취할 수 없는 수치입니다.

유지되는 경계를 설정하는 방법

"and"를 사용하지 않고 한 문장으로 에이전트를 설명합니다. 연결이 필요한 경우 에이전트가 두 명 있습니다.

수행할 작업을 결정하기 전에 수행할 수 없는 작업을 결정하고 프롬프트가 아닌 작업 시점에 이를 시행하십시오. 작업이 발생하는 위치에서 정책이 시행되면 프로덕션에 작성해서는 안 되는 에이전트에 대해 논쟁을 벌일 수 없습니다.

구축하기 전에 평가 기준을 작성하십시오. 좋은 결과물이 어떤 것인지 설명할 수 없다면 범위가 여전히 너무 모호하고 건물에서 이를 명확하게 설명할 수 없는 것입니다.

누군가가 요청할 때가 아니라 첫날에 이름이 지정된 소유자를 지정하세요.

구성이 폭을 이긴다

야망의 유용한 버전은 열 가지 일을 하는 한 명의 대리인이 아닙니다. 10명의 에이전트가 각각 한 가지 작업을 수행하고 구성되어 있으며 각각 개별적으로 평가할 수 있고 개별적으로 교체할 수 있습니다.

이것이 에이전트를 공유 가능하게 만드는 이유이기도 합니다. 경계가 명확한 에이전트를 에이전트 허브에 게시하고 다른 팀에서 포크하여 개선하고 롤백할 수 있습니다. 거대한 것은 그것을 생산한 맥락에만 국한되며 다른 누구에게도 유용하지 않습니다.

불편한 부분

범위를 엄격하게 지정한다는 것은 에이전트가 흥미로운 예외 사례를 처리하지 않을 것이며 사람은 여전히 처리할 것임을 인정한다는 것을 의미합니다. 이것을 받아들이는 팀은 지속되는 것을 배송합니다. 마지막 10%를 확보하기 위해 계속 경계를 넓히는 팀은 일반적으로 처음 90%에 대해서는 아무도 신뢰하지 않는 에이전트가 됩니다.

다음

에이전트 허브 페이지에서는 팀 전체의 에이전트 게시, 포크 및 버전 관리를 다룹니다. 에이전트 오케스트레이션 시스템 페이지에서는 경계를 의도한 것이 아닌 현실로 만드는 소유권, 정책 및 평가를 다룹니다.