AI 에이전트 재시험에 대한 관찰성: 복제 효과를 잡는다

에이전트가 도구 호출을 다시 시도해서는 안되는데 그 흔적이 타임아웃으로 끝나기 때문일 뿐입니다. 요청은 제공자에게 도달하고 실제 상태를 변경하고 응답만 잃었을 수도 있습니다. 두 번째 시도는 메시지를 두 번 보내거나, 두 개의 티켓을 만들거나, 두 개의 리소스를 제공 할 수 있습니다. 두 개의 흔적이 개별적으로 합리적인 것처럼 보일 때. 유용한 건강 규칙은 더 엄격하다: one 논리적인 동작은 한 가지 이상의 검증된 효과를 로 만들 수 없습니다. 운영에 안정적인 아이덴티티를 부여하고, 시도를 통해 그 아이덴티티를 유지하며, 공급자 측 효과 수신을 기록하고, 효과를 안전하게 찾아볼 수 없을 때 자동으로 다시 시도를 차단합니다. 시도 계산과 HTTP 상태는 여전히 진단에 도움이 되지만 결과는 증명되지 않습니다. 이 기사에서는 이 규칙을 작은 효과 리저로 구성하고 네 가지 작업에 대해 테스트합니다. 이 장치에는 8개의 시도와 4개의 제공자 관찰이 포함되어 있습니다. 오직 시도만 하는 정책은 시간제와 3개의 작전을 계속 시도할 수 있습니다. 그 대신 효과에 대한 인식의 감사는 한 건전한 재생, 한 복제 효과 사건, 한 무력성 핵심 충돌, 그리고 한 정직하게 불확실한 작업을 발견합니다. 타임아웃은 아무것도 일어나지 않았다는 증거가 아닙니다. 위험한 창은 원격 처형과 현지 인정을 사이에 두고 있습니다. 공급자는 효과를 일으켜 다시 돌아가는 길에 반응을 잃을 수 있습니다. 에이전트의 입장에서는 이 두 개의 역사가 관찰적으로 비슷합니다. 1. 요청은 제공자에게 도달하지 못했습니다. 2. 요청이 완료되었으나 대리인이 응답을 받지 못했습니다. 오직 첫 번째 역사만 다른 방안 없이 반복할 수 있습니다. 두 번째는 자연적으로 무력하지 않은 상태에서 복제물을 생성합니다. HTTP 의미론은 유용한 경계를 제공합니다. RFC 9110는 무능한 방법을 정의합니다.는 하나의 요청과 같은 여러 개의 동일한 요청에 따라 의도된 서버 효과와 동일합니다. 그것은 idempotent 방법의 통신 실패 후 자동 반복을 허용하지만 클라이언트가 작동이 효과적으로 idempotent 또는 원래 적용되지 않았다는 것을 감지 할 수 없는 한 자동으로 idempotent 요청 다시 시도해서는 안 된다고 말합니다. 그 차이점은 에이전트 건강입니다. 알려진 기록을 대체하는 PUT 와 이메일을 보내는 POST 은 모두 시간 종료 할 수 있지만 동일한 재실험 경계가 없습니다. 일반적인 timeout → 재시험 정책은 가장 중요한 의미적 사실을 지워버립니다. 제공자 지원은 도움이 되지만 계약은 정확하게 읽어야 합니다. 스트립 문서는 idempotency 키로 작성된 첫 번째 요청의 상태 코드와 인체를 저장하고, 그 결과를 동일한 키로 나중에 요청하는 결과로 반환합니다. 또한 매개 변수를 비교하고 다른 매개 변수와 재사용을 거부합니다. 따라서 열쇠는 각각의 시도에 부착된 무작위적인 표지판이 아닙니다. 그것은 하나의 안정적인 논리적인 동작을 나타냅니다. 아마존 EC2 문서는 유사한 클라이언트 토큰 패턴을: 동일한 토큰과 매개 변수를 성공적으로 다시 시도하면 더 이상의 행동을 수행하지 않으며, 변경된 매개 변수는 IdempotentParameterMismatch 를 생성할 수 있습니다. 또한 EC2는 지역 또는 지역별로 일부 보증의 범위를 포함하고 있습니다. 표가 있는 것은 충분하지 않습니다. 건강 기록은 토큰의 범위, 유용함 신분, 보유 창 및 공급자의 행동이 필요합니다. 합리적인 결함이: 모든 시도에서 하나의 운영 아이덴티티를 재사용한다. 제공자의 무제한 키를 동일한 카노닉 유용량에만 재사용한다. 모호한 결과 후에 다시 시도하기 전에 해당 아이덴티티에 의해 문의해야 합니다. 제공자가 무제속도 또는 검색도 제공하지 않으면 인적 의사결정을 요구합니다. 백오프는 실패한 서비스에 대한 압력을 줄입니다. 그것은 무능한 행동을 무능한 행동으로 바꾸지 않습니다. 기록 효과, 시도뿐만 아니라 일반적인 추적 답은 에이전트가 무엇을 시도했는가? 효과 리저는 다른 질문에 대답합니다. 우리가 증명할 수 있는 지속 가능한 변화는 무엇입니까? 두 기록을 연결시켜 두십시오. 시도는 유용한 증거로 남아 있지만, 시도의 최종 기간을 비즈니스 결과로 취급하지 마십시오. 최소한의 대책에는 다음과 같은 필드가 필요합니다. 현장 목적 건강상태가 좋지 않은 경우 operationId 사용자의 의도된 운용에 대한 안정적인 정체성 다시 시도할 때마다 새로운 ID가 생성됩니다. attemptId 한 번의 운송 시도의 신분 누락되거나 초복되는 시도 idempotencyKey 지원되는 경우 제공자의 분배 분배 정체성 재사용 중 주요 변경 사항 payloadHash 카노닉, 편집된 유용한 부하의 해시 동일한 키가 다른 목적으로 재사용됩니다. effectRef 실제 효과의 제공자 또는 목적지 신분 한 가지 이상의 내구성 효과 result timeout 또는 success 와 같은 운송 관측 모호한 인정 observedAt 증거가 수집된 시간 기존의 증거가 현재의 상태로 잘못 인식되고 있습니다. 이 필드에 비밀, 이메일 주소, 전체 명령어, 또는 원료 도구 사용 부하를 넣지 마십시오. 휘발성 값을 제거한 후 캐논िकल 표현을 해시합니다. 조사에서 요구될 때 민감한 원료를 원천에 보관한다. 작업 아이덴티티는 재실험 루프 내에서 아니라 의도가 내구성이 될 때 만들어져야 합니다. 예를 들어: 이 단편은 디자인적으로 불완전합니다. 예외를 잡고 계속하는 것은 안전성을 증명하지 않습니다. 호출자는 또한 제공자의 반환된 객체 ID를 유지하거나 모호한 응답 후 동일한 비즈니스 아이덴티티로 제공자에게 문의해야 합니다. 성공한 반응이 아닌 독특한 효과를 계산해 보세요. ticket 908 라는 두 개의 성공적인 반응은 하나의 효과를 설명합니다. delivery a 와 delivery b 라는 이름을 붙인 성공이 이어진 한 시간 동안 두 가지 효과를 설명합니다. 반대로, 검색 채널이 사용할 수 없을 때 0 인수라는 것은 0 효과를 증명하지 않습니다. 그 상태는 uncertain , 건강하지 않고 자동으로 갇혀 있지 않습니다. 유용물 신원은 별도의 게이트입니다. 만약 두 시도가 무력함 키를 공유하지만 다른 카논िकल 유용하시가 있다면, 효과 수를 해석하기 전에 멈추십시오. 호출자는 요청된 지역, 수신자, 양 또는 리소스 형태를 변경한 후 실수로 키를 재사용했을 수 있습니다. 공급자 측의 매개 변수 부합 오류는 이러한 정확한 오류에 대한 유용한 증거입니다. 4개의 작업 효과를 검사하는 이 문서에 사용된 검사 가능한 장치 는 NDJSON 이다. 각 선은 attempt 또는 effect 관찰이다. 전체 로컬 유물은 네 가지 논리적 동작을 포함합니다. op ticket 42 : 두 번의 시도는 하나의 키와 하나의 유용한 부하를 공유하며, 두 관찰은 모두 ticket 908 를 가리킨다. op webhook 77 : 두 번의 시도는 무력성 키가 없으며 delivery a + delivery b 를 나타냅니다. op vm 5 : 2번 다른 사용량 해시로 한 키를 재사용 시도 op email 3 : 두 번의 중단 시도, 효과 수신이 없습니다. 공급자는 검색 경로가 없습니다. 감사 그룹은 operationId 에 의해 기록하고, 효과를 계산하기 전에 유용한 부하 유동을 거부하고, 효과를 관찰하는 줄보다는 effectRef 의 다른 값을 계산합니다. 저장소 유물을 실행: 생산: 세 가지 관찰은 운영 결정에 변화를 가져온다. 첫째, op ticket 42 에는 두 번의 시도 기록과 두 번의 효과 관측이 있지만 두 번의 관측은 하나의 공급자 객체로 해결됩니다. 효과 행 1에 대한 경고는 거짓 긍정적입니다. 안정적인 공급자 참조는 분배를 증명하는 것입니다. 둘째, op webhook 77 는 성공한 두 번째 시도를 포함합니다. 운송용 단독 패시보드는 사건을 막을 수 있습니다. 두 가지 효과 참조는 복구가 두 번째 전달을 만들어냈다는 것을 증명합니다. 따라서 올바른 상태는 복제이고 다음 작업은 재 시도가 아니라 조화입니다. 셋째, op vm 5 는 장치에 복제 효과가 없지만 여전히 안전하지 않습니다. 재사용된 키는 2개의 다른 유용하시를 포함합니다. 두 번째 자료가 나올 때까지 기다린다면 문제가 너무 늦게 발견될 것입니다. 주요 갈등은 예방적인 건강 장애입니다. 감사는 중요한 한계를 가지고 있습니다. 그것은 제공된 증거만을 분류할 수 있습니다. op email 3 의 경우, 영수증과 검색 경로는 결과를 알 수 없습니다. 리저는 확실성을 만들 수 없습니다. 다시 시도하면 부족한 작업을 완료하거나 완료된 작업을 복제할 수 있으므로 제한된 반응은 모호함을 표면에 내세우고 권위를 요청하는 것입니다. 결과를 다시 시도한 경계로 변환합니다. 다음 동작을 제어하기 위해 분류를 사용하세요. 단순히 래시보드를 색칠하는 것이 아닙니다. 분류 증거 보안 기본 healthy 한 가지 유용한 로드 아이덴티티와 정확히 한 가지 독특한 효과 재시험을 중단하고, 예정된 배달값을 확인한다. duplicate 한 작업에 대해 하나 이상의 고유 효과 블록 재시험: 승인을 받아 조정하거나 보완 key conflict 여러 유용하스 해시에 연결된 하나의 키 블록 실행; 의도가 검토된 후에야 새로운 동작을 할 수 있습니다. uncertain 효과 증명도 없고, 신뢰할 수 있는 실재 증거도 없습니다. 다시 질문, 새로운 증거를 기다립니다, 또는 인간에게 물어보세요 아직 시간 제한이 필요합니다. 제공자의 무능력 기록은 만료될 수 있고 검색 지수는 지연될 수 있으며 목적지는 제공자의 거래 경계를 벗어날 수 있습니다. 문서화된 저장 및 범위를 열쇠 옆에 보관하십시오. 그 경계가 만료되면 원래 코드 경로가 변경되지 않았더라도 동일한 요청이 더 이상 안전하지 않을 수 있습니다. 회복 검증은 원래의 결과를 얻어야 합니다. 단일 공급자 객체는 여전히 잘못 될 수 있습니다: 티켓이 잘못된 프로젝트와 존재하거나 리소스가 생성 될 수 있지만 결코 준비가되지 않을 수 있습니다. 단일 효과 비변수는 복제 방지하고, 별도의 결과 계약은 생존 효과가 사용자가 의도한 효과라는 것을 확인합니다. 운영 건강 관측을 위해 다섯 가지 사실을 함께 보고하십시오. 1. 논리적인 작동과 유용한 부하의 지문; 2. 시도와 그 운송 결과; 3. 제공자의 무제한의 범위와 신선함 4. 관찰된 다른 지속가능한 효과; 5. 다시 시도, 보상 또는 화해를 위한 권한의 한계. 그래서 리트리 성공은 판결보다는 증거가 됩니다. 더 건강한 판단은 이 의도된 효과가 존재하고 검증되었거나, 증거가 불완전하면, 이 효과는 확실하지 않습니다. 자동으로 다시 시도는 차단됩니다. Sidewisp는 현재 비공개 프리뷰 단계입니다. 공개 문서 시스템과 인터랙티브 제품 시범은 실시간이지만 생산 에이전트 건강 수집, 런타임 어댑터, 크론 관리, 토큰 비용 분석 및 복구 일반적으로 배송되지 않습니다. 위의 예는 작동 패턴이며, Sidewisp이 현재 살아있는 요인을 검사하거나 수리하는 주장이 아닙니다. Sidewisp는 대체 실행 시간, 필수 게이트웨이, 원료 추적 제품, 기업 제어 비행기 또는 자율 고정 장치가 아닙니다. 만약 효과 레저의 건강 규칙이 기존 에이전트를 운영하는 데 도움이 된다면, 개인 미리보기에 가입하는 것을 고려하십시오. 이미 실행된 곳에서 집행을 유지하십시오. 증거로 다시 시도를 통해 안전성을 확보하십시오.