AI 에이전트가 지시를 무시했다면? Sume Format 실행 디버깅

Sume Format 실행이 지시문의 일부를 무시했다면, 에이전트가 실제로 받은 내용부터 확인하세요. 에이전트 탭에서 실행의 thread_id를 열면 첫 메시지가 조합된 텍스트 그대로입니다. 그다음 지시문이 실제로 전달되는 약 4000자 안에 들어갔는지, 데이터가 input에 들어 있었는지, 어느 Format version이 실행됐는지 확인하세요.

아래 점검 항목은 2026-09-26에 확인한 Format 문서, 주로 instruction 조합 (영문), Format 호출하기 (영문), 실행과 결과 (영문)에서 가져왔습니다. 상태, 폴링, 웹훅은 Sume Format 실행 수명주기에서 다룹니다.

어떤 증상에는 무엇을 점검해야 하나요?

본 증상에서 출발해 두 번째 열의 필드나 위치를 확인하세요. 각 항목은 아래에서 설명합니다.

에이전트는 실제로 무엇을 받았나요?

Sume는 실행을 정해진 순서로 조합합니다. Format은 작업을 어떻게 할지 정하므로 먼저 옵니다. 지시문은 그 뒤에 오므로, 둘이 어긋나면 모델은 여러분이 요청한 쪽을 따릅니다. input은 /workspace/inputs/sume-action-input.json에 통째로 기록되며, 에이전트는 이 파일을 지시가 아니라 데이터로만 읽으라는 안내를 받습니다.

에이전트 탭에서 실행의 thread_id를 여세요. 첫 메시지가 바로 이 텍스트이며, 실행이 예상하지 못한 일을 했을 때 가장 먼저 읽어야 할 곳입니다. 이 텍스트는 API로는 볼 수 없습니다. 메시지 엔드포인트가 없기 때문입니다.

[Sume unattended run] 블록은 API 실행과 예약 실행에만 나타납니다. 채팅용으로 쓴 레시피는 승인을 기다리며 멈출 수 있지만, API에서는 응답할 사람이 없습니다. 그래서 실행은 그런 승인이 이미 부여됐다는 안내를 받고 지출 상한 안에서 계속 진행합니다. 사람 없이는 정말로 계속할 수 없는 실행은 unattended_blocked로 실패하며, 그 message에 이유가 담깁니다.

[Format: product-promo v12]     <- a pointer at the recipe; the body is never inlined
[Format attached: … SKILL.md]   <- the whole package, on disk in the run's workspace
[Format run instruction]        <- your instruction, or the Format's default
[Sume unattended run]           <- API and scheduled runs only
[Sume action input]             <- a pointer at your input, written whole to a file
[Attached files]                <- your attachments, when present

지시문이나 입력 데이터가 잘렸나요?

instruction은 8000자까지 수락되지만, 프롬프트 텍스트로 실행에 전달되는 것은 앞 ~4000자뿐입니다. 지시문은 그 안쪽으로 넉넉히 짧게 쓰고, 데이터는 input에 넣으세요. input은 2 MiB까지 에이전트가 읽는 파일로 통째로 전달됩니다.

input에는 공개된 필드 목록이 없습니다. Format의 레시피가 자기가 아는 키를 읽습니다. 빈 {}는 파일을 아예 만들지 않으므로, 입력에서 product_url을 읽으라고 적힌 Format은 읽을 것이 없습니다. Format이 무엇을 받는지 선언한 계약은 Format의 io 프로필뿐입니다. 신뢰할 수 없는 텍스트를 어디에 넣어야 하는지는 고객 데이터를 AI 에이전트에 안전하게 넘기기에서 다룹니다.

실행이 예상한 레시피 버전을 썼나요?

영수증의 format.version은 실제로 실행된 Format 버전이며, 이후 편집으로 바뀌지 않습니다. 편집은 이미 진행 중인 실행에 영향을 주지 않습니다. 편집이 무시된 것 같다면 그 번호를 Format의 현재 version과 비교하세요. 버전을 추적하는 방법은 Sume Format 버전에서 다룹니다.

실행이 멈춘 건가요, 아니면 느릴 뿐인가요?

GET /v1/format-runs/{run_id}/events는 phase 타임라인입니다. preparing, running(에이전트가 레시피대로 작업하는 단계로, 시간이 여기에 듭니다), finalizing으로 이뤄집니다. phase와 상태가 같은 연속 항목은 하나로 합쳐지므로, 마지막 항목의 at이 실행의 진행 시계입니다. 이 값이 몇 분 동안 움직이지 않으면 실행은 느린 것이 아니라 멈춘 것이며, 기한이 되면 종료 처리됩니다.

타임라인은 로그 스트림이 아닙니다. 에이전트 출력과 도구 호출은 API로 공개되지 않습니다. queued에 머무는 실행에는 queue.state라는 별도 신호가 있으며, Sume Format 실행 수명주기에서 다룹니다.

출력이 비어 있거나 실행이 만든 것과 다른 이유는 무엇인가요?

output을 읽기 전에 output_error를 확인하세요. output_schema.source는 어느 스키마가 output의 형태를 정했는지 알려 줍니다. 값은 default, Format 자체의 action_default, 여러분의 request_override 중 하나입니다. output_schema.filled_by는 누가 채웠는지 알려 줍니다. agent는 실행이 직접 제출했다는 뜻이고, projection은 폴백 패스가 실행의 미디어와 마무리 텍스트만으로 만들었다는 뜻입니다.

projection은 input이나 instruction을 절대 보지 못하므로, 이 경로에서는 보낸 식별자가 돌아오지 않습니다. 또 미디어 필드는 채워져 있는데 텍스트가 null이라면 일찍 멈춘 실행의 모양입니다. API에서는 projection이 스키마를 채우지 못하면 실행이 failed가 되고, artifacts[]에는 미디어가 그대로 나열됩니다. 각 코드의 의미는 Sume Format 실행 실패 코드에서 다룹니다.

Sume 지원팀에는 무엇을 보내야 하나요?

응답의 x-sume-request-id 헤더, 영수증의 request_id, 실행 id, error.code를 알려 주세요. API 키, 서명 시크릿, 원본 미디어 URL은 보내지 마세요. runtime_unavailable 큐 상태가 몇 분 넘게 이어지면 request_id를 담아 문의할 만합니다.

웹훅이 오지 않았다고 알리기 전에 영수증의 webhook_delivery를 읽으세요. failed나 exhausted라면 last_status_code와 last_error(여러분의 응답 본문이 아니라 Sume 쪽 전송 오류)가 이유를 알려 주며, 실행 자체는 바뀌지 않습니다. 나머지는 Sume 웹훅 전달 디버깅에서 다룹니다.