에이전트 및 기록 시스템

기록 시스템과 연결되지 않은 에이전트는 대화 도구입니다. 제한 없이 액세스할 수 있는 에이전트는 아무도 승인하지 않을 위험이 있습니다. 거의 모든 유용한 디자인은 이 두 위치 사이에 있습니다.

읽기와 쓰기는 동일한 결정이 아닙니다

조직은 에이전트에게 쉽게 읽기 액세스 권한을 부여하고 마지못해 쓰기 액세스 권한을 부여하는데, 이러한 본능은 단지 조심스럽다기보다는 정확합니다.

잘못된 기록을 반환하는 읽기는 사람이 잡을 수 있는 잘못된 답변을 생성합니다. 잘못된 기록에 대한 쓰기로 인해 비즈니스에 변화가 발생하고 이를 고객이 발견할 수 있습니다.

따라서 유용한 기본값은 광범위하고 잘 구성된 읽기 액세스와 프롬프트에서 요청하는 것이 아니라 작업 시점에 명시적으로 열거되고 적용되는 좁은 쓰기 액세스입니다.

프롬프트가 이 경계에 대해 잘못된 위치인 이유

프롬프트는 모델에 대한 지침입니다. 모델은 설득력이 있으며, 계획을 따르는 에이전트는 지침이 권장하지 않지만 방지하지는 못한 행동에 도달할 수 있습니다.

집행은 조치가 발생한 곳에 속합니다. 에이전트가 청구 테이블에 기록하면 안 되는 경우 해당 제약 조건은 연결에 적용되므로 "이런 일이 발생할 수 있었습니까?"에 대한 대답은 확실합니다. 이것이 감사를 의미 있게 만드는 것이기도 합니다. 기록은 무엇이 시도되었는지 보여주고, 경계는 무엇이 가능했는지 보여줍니다.

부실함은 누구도 계획하지 않는 실패이다

에이전트가 작업하는 동안 기록 변경 시스템. 달리기 시작 시 수립된 계획은 30초 후에 이동된 기록에 따라 실행될 수 있습니다.

이는 특정 종류의 피해를 낳습니다. 내부적으로는 일관성이 있고 외부적으로는 잘못된 작업을 수행하지 않은 사람이 선택해야 하는 작업입니다. 이를 위해 Oran 3.6의 상황 인식이 존재합니다. 즉, 실행 내에서 발생한 일과 그 아래에서 변경된 사항을 추적하여 단계가 반복되거나 이동된 기록에 적용되지 않습니다.

액세스보다 신원이 더 중요합니다

공유 서비스 계정으로 활동하는 에이전트는 추적성이 가장 중요한 곳에서는 추적이 불가능합니다. 6개월이 지나도 "어느 대리인이 이걸 바꿨는지"에는 답이 없습니다.

에이전트별로 범위가 지정된 조직 수준 저장소에서 런타임 시 자격 증명을 확인하면 이 문제가 루트에서 해결됩니다. 에이전트는 일반 텍스트로 비밀을 유지하지 않으며 취소는 하나의 작업이며 감사 추적의 모든 쓰기는 이를 수행한 ID를 전달합니다.

승인 경계

일부 쓰기는 사람 없이 진행되어서는 안 됩니다. 전부는 아니거나 상담원이 제안 상자인 경우도 있지만, 잘못된 경우 비용이 많이 들거나 되돌리기 어려운 경우도 있습니다.

이를 포괄적인 검토가 아닌 특정 작업의 속성으로 취급하면 의미가 유지됩니다. 모든 것을 승인하는 사람은 아무것도 승인하지 않습니다. 왜냐하면 관심은 반복에서 살아남지 못하기 때문입니다.

합리적인 순서

검색이 정말 어려운 시스템에 대해 읽기 전용으로 시작합니다. 에이전트가 읽는 내용과 생성되는 내용을 계측합니다. 실제 사례를 바탕으로 평가 기준을 작성합니다. 그런 다음 소수의 쓰기 세트를 열거하고 연결 시 이를 시행하며 비용이 많이 드는 쓰기 작업은 승인 뒤에 둡니다.

이는 모든 것을 연결하고 무슨 일이 일어나는지 보는 것보다 느립니다. 아무것도 뽑지 않아도 되는 버전이기도 합니다.

다음

에이전트 오케스트레이션 시스템 페이지에서는 정책 시행, 자격 증명 저장소 및 감사 추적을 다룹니다. 개발자 문서에서는 연결 메커니즘을 다룹니다.