에이전트가 중단을 실패로 간주하는 문제

'사용자의 승인'이라는 부분은 다른 무엇보다도 원본 메시지에 결합해야 한다고 봐. 실행 시점에 확인되는 건 보통 요청 자체가 아니라 모델이 스스로 다시 진술한 계획이니까. 계획을 쓰고, 다시 읽고, 그 안에서 승인을 찾아내지. 패러프레이징 대신 메시지 ID와 승인이 나온 정확한 범위를 저장하는 게 네가 말한 재예약 사례를 잡는 방법이야. 사용자의 말에는 기존 예약을 취소한다는 내용이 없었는데, 차단된 후 작성된 계획 옆에 두면 마치 포함된 것처럼 보이니까.

맞아, 그리고 그게 바로 스켈레톤이 처리하는 방식이야. 지시사항에서 가져온 값은 반드시 사용자의 메시지에 있는 세그먼트와 문자 범위를 명시해야 해, 안 그러면 거부되지. 모델의 계획은 소스(근거)가 될 수 없으니까, 재진술에서만 나타나는 승인은 절대 인정되지 않아.

난 무언가를 변경하는 작업에 대해서만 그걸 뒤집을 거야. 만약 모든 읽기 작업마다 명시적인 승인이 필요하다면, 사람들은 내용을 확인도 안 하고 그냥 대량으로 승인해버릴 테니까.

우리 쪽은 그렇게 분리해뒀어: 받은 편지함이나 웹 페이지를 읽는 건 알아서 돌아가고, 기록을 전송하거나 게시하거나 수정하는 건 반드시 해당 항목에 대해 '예'라는 승인이 필요하게끔. 네가 말한 예약 예시의 경우, 에이전트 지시사항에 이런 줄이 있어: 작업이 실패하면 해당 항목은 중단하고, 다른 경로를 시도하지 말고, 무엇이 실패했는지 보고할 것. 보고서는 먼저 감독 에이전트에게 전달되고, 결정이 필요할 때만 나한테 넘어와.

그 분리가 맞는 방향이고, 실패 규칙도 내가 주장하는 거랑 비슷하네. 궁금한 게 두 가지 있어. 그 규칙이 에이전트 지시사항에 들어있다면, 결국 중단 여부는 모델이 결정하는 거잖아. 모델이 실패를 실패로 인식하지 못하거나, 우회책을 재시도가 아닌 새로운 항목으로 처리하는 경우를 본 적 있어? 그리고 사용자가 자기만의 규칙을 추가할 때, 그것도 지시사항에 넣는 거야?

여기 몇몇 댓글들이 일반적인 설정을 잘 설명해주고 있네: 에이전트 지시사항에 규칙을 넣는 것("실패 시 중단하고 보고할 것")과 무언가를 변경하는 작업마다 승인을 받는 것. 여기 예약 사례를 그 방식과 실행 전 검사(spec)를 거쳐서 비교해봤어:

모델은 둘 다 똑같이 행동해. 유일한 차이는 그 행동이 실행 단계까지 도달하느냐 아니냐지. 지시사항 접근법은 모델이 실패를 실패라고 인정할 때만 작동해. 이 방식은 모델이 인정하지 않을 때도 작동하고.

혹시 궁금한 사람들을 위한 스펙: https://github.com/Jang-woo-AnnaSoft/execution-state-preflight/blob/main/model-reasons-agent-executes.en.md