AI 에이전트들은 실제로 어떻게 서로를 발견하고 대화해야 할까?

하트비트는 '무언가 있는가?'에 대한 답만 줄 뿐입니다. 저는 '이 작업이 할당되었던 그 작업자 버전이 여전히 맞는가?'도 확인해야 한다고 봅니다. 작업자 인스턴스와 입출력 계약 버전을 할당과 함께 유지하면, 작업 수신자가 조용히 바뀌는 대신 재배포가 명확하게 실패하도록 만들 수 있습니다. 그러면 모든 메시지마다 새로 조회하는 대신, 버전이 변경될 때만 발견 정보를 새로 고칠 수 있습니다. 사용하시는 레지스트리는 에이전트 이름과 별도로 배포 정보를 추적하나요?

워크플로우에 역할을 적어두고 에이전트 이름을 직접 언급합니다. 그러면 에이전트들은 특정 역할이 필요할 때 누구와 통신해야 하는지 알게 됩니다.

소셜 네트워크 같은 걸 말씀하시는 건가요?

가능하다면 발견(discovery) 과정은 핫 패스(hot path)에서 제외하고 싶습니다. 레지스트리는 기능, 인터페이스 버전, 인증 범위, 짧은 임대 기간을 광고할 수 있지만, 오케스트레이터가 작업을 생성할 때 구체적인 대상을 결정하고 그 대상을 작업 자체에 기록해야 합니다. 그렇게 하면 재배포 시 에이전트들이 실행 중에 오래된 엔드포인트를 쫓아다니는 대신, 재시도 가능한 해결 실패로 처리할 수 있습니다. 에이전트가 몇 개 이상 늘어나면 가장 어려워지는 것은 소유권 문제입니다. 두 에이전트가 모두 같은 부작용을 자신이 소유하고 있다고 믿을 수 있기 때문입니다. 저는...

이 답변들은 대부분 A와 B가 같은 소유자를 공유한다고 가정하는 것 같네요. 레지스트리에 권한을 부여하는 것은 바로 그 점입니다. 배포 파이프라인이 항목을 작성하지, 에이전트 자체가 작성하는 게 아니니까요. 그래서 기능 주장은 B를 배포한 주체로부터 신뢰성을 상속받습니다. 이 스레드에서는 그 가정이 많은 역할을 하고 있습니다.

B가 다른 누군가의 소유가 되면 상황은 더 어색해집니다. 오래된 엔드포인트는 알아차리기 쉽습니다. 하지만 살아있으면서 자신 있게 그럴듯한 쓰레기를 반환하는 엔드포인트는 무기한으로 정상인 것처럼 보일 수 있습니다. 하트비트...

'에이전트가 켜져 있다'는 것과 '에이전트가 작업을 수행할 수 있다'는 것을 같은 사실로 취급했던 게 초기에 우리를 힘들게 했습니다. 하트비트가 있는 레지스트리는 엔드포인트가 응답한다는 사실만 알려줄 뿐, 그 엔드포인트 뒤의 버전이 호출자가 기대하는 스키마와 여전히 일치하는지는 전혀 말해주지 않습니다.

해결책: 모든 기능 항목에 버전을 포함하고, 위임된 모든 작업은 발행된 버전을 고정(pin)하도록 했습니다. 만약 에이전트 B가 스키마 변경을 포함하여 재배포되면, 호출자의 고정된 버전과 일치하지 않게 되고...

오케스트레이터가 모든 것을 아는 방식은 에이전트 2~3개까지는 잘 작동했지만 4개가 되니 완전히 무너졌습니다. 모든 에이전트를 이해해야 라우팅이 가능해지니 병목 현상이 됩니다. 더 나은 방식은 에이전트 발견인데, 각 에이전트가 할 수 있는 일을 어딘가에 명시하고 나머지는 하드코딩 대신 그걸 확인하는 방식입니다. 새로운 에이전트를 추가한다고 라우터를 다시 작성할 필요가 없어지죠.

하지만 저에게 가장 큰 문제는 발견이 아니라 오류였습니다. A가 B를 호출하고, B가 C를 호출하는데 C가 이상하게 실패하면, A는 그게 진짜 문제인지 노이즈인지, 어디서 발생했는지 알 방법이 없습니다. 디버깅...

모든 걸 하드코딩하지 않고 확장하려면 공유 메타데이터가 있는 레지스트리가 유일한 방법인 것 같음, 참고로.