Goal

Goal은 Qwen Code가 명시된 조건이 충족될 때까지 턴 간에 작업을 계속 수행하게 합니다. /goal <objective>로 설정하면 세션이 자동으로 계속 진행됩니다. 각 턴은 증거로 기록되며, 모델이 목표가 완료되었거나 차단되었음을 제안하면 독립적인 검증자가 해당 증거만을 바탕으로 그 제안을 판정합니다. 세션은 검증자가 수락하거나, Goal이 일시 중지되거나, 해제되거나, 한도로 중지될 때 종료됩니다.

명령어

Goal을 생성, 수정 또는 재개하려면 신뢰하는 워크스페이스(/trust)가 필요합니다. 헤드리스 사용법은 헤드리스 모드에서 다룹니다.

Goal이 턴을 청구하면, 푸터 필과 모든 상태 카드는 허용된 창(window)에 대해 얼마나 소비했는지를 1.2k/30.0m 형태로 표시합니다. 이 수치는 Goal이 자체 턴에서 수행한 모델 호출 횟수를 세며, 서브에이전트와 검증자의 자체 검사는 포함되지 않습니다. 창은 model.goalTokenBudget으로 설정되며, 창을 모두 소모한 Goal을 재개하면 이미 소비한 양에 추가로 새 창이 부여되므로 수치는 처음부터 다시 시작하는 대신 30.0m/60.0m으로 표시됩니다. 예산이 없는 Goal은 소비한 양만 표시합니다. 아직 턴을 청구하지 않은 Goal은 아무 수치도 표시하지 않습니다.

두 가지 창이 더 있으며 기본적으로 꺼져 있습니다: model.goalMaxTurns는 Goal이 완료할 수 있는 턴 수를 제한하며(사용자 주도 Goal 턴 포함), model.goalMaxActiveMinutes는 실행 중인 프로세스에서 활성 상태인 동안의 경과 시간을 제한하며(턴 간 대기 및 유휴 시간 포함). Goal이 일시 중지, 차단 또는 중지된 동안의 시간은 두 번째 창에 포함되지 않으며, 재시작 사이의 다운타임도 포함되지 않습니다. 단순히 일시 정지된 프로세스는 여전히 과금됩니다. 어느 창이 먼저 소모되든, Goal은 동일한 단일 종료 턴을 통해 인계한 후 재개할 때까지 중지되며, 재개하면 이미 사용된 양에 추가로 새 창이 승인됩니다. 소모된 창만 이동하며 나머지는 그대로 유지되고, -1 옵트아웃 역시 이미 소모한 창의 상한만 제거합니다. 시간 창은 턴 사이에 읽히며 타이머로 강제되지 않으므로, Goal은 중지되기 전까지 훨씬 오래 실행될 수 있습니다. 이미 실행 중인 턴은 중단되지 않으며, 턴이 실행되지 않는 동안 창이 소모되면 다음 턴이 종료될 때까지 감지되지 않습니다. 활성 시간은 기록된 전환 사이에서 계산되므로 재시작이 중단한 턴의 시간은 과금되지 않습니다. 두 설정 모두 변경 시 재시작 후에 적용됩니다. 두 창 모두 변경 이후에 생성된 Goal에서만 작동하므로, 이미 기록된 Goal에 제한을 두려면 /goal set으로 교체해야 합니다—리비전 1의 새 Goal로, 턴, 토큰, 활성 시간 미터가 초기화되고 증거 창이 교체 시점에서 시작되므로 이전 Goal이 기록한 증거는 더 이상 인용할 수 없습니다—또는 해제하고 다시 시작해야 합니다. 재개나 수정은 생성 시점에 작동하지 않았던 상한을 추가하지 않습니다.

세션이 자체적으로 수행하는 각 턴은 Goal이 지금까지 소비한 양, 수행된 턴 수, 그리고 Goal이 무제한으로 실행되지 않는 한 허용된 창을 보고합니다. 이러한 각 턴은 최종 종료 인수인계를 제외하고, 이전 턴의 보고를 신뢰하기보다 워크스페이스를 다시 확인하고, 목표가 요구하는 최종 상태를 향해 작업하며, 이전 턴이 아무것도 변경하지 않았을 때 다른 작업을 수행하고(이전 턴이 존재하여 판단할 수 있는 두 번째 턴부터), Goal이 완료되었다고 제안하기 전에 모든 요구 사항을 인용 가능한 증거에 대해 확인하라는 상시 지시를 포함합니다.

긴 Goal은 주기적으로 기록한 증거를 사이드 모델 검사를 통해 체크포인트 주장으로 압축하므로, 이후 턴과 검증자가 여전히 이를 인용할 수 있습니다. 이 검사는 model.goalCheckpointTimeoutSeconds에 의해 제한되며, 기본값은 180초입니다. 마크다운 펜스로 감싼 응답은 펜스를 제거하고 읽습니다. 주장이 집계 바이트 예산을 초과하거나, 주장당 문자 제한을 초과하거나, 하나의 체크포인트가 보관할 수 있는 개수를 초과하거나, 요청에 없던 id를 인용하거나, 인용하는 출처의 증명 종류를 변경하면, 무엇이 잘못되었는지 명시하는 한 번의 수정 모델 호출을 수행하며 두 호출 모두 해당 상한을 공유합니다. 비어 있지 않은 claims 배열을 가진 JSON 객체가 아닌 응답에는 수정 호출이 이루어지지 않으며, 사용 가능한 주장 옆에 형식이 잘못된 주장이 있더라도 마찬가지입니다: 어느 수준이든 추가 키, 인식되지 않는 proofKind, 빈 주장, 또는 비어 있거나 비문자열이나 빈 id를 포함하거나 id를 반복하거나 32개를 초과하는 id를 가진 sourceRefs 목록이 해당됩니다. 시간 내에 완료하지 못한 검사는 결론 없이 포기됩니다. 이는 증거 창이 오버플로우된 경우에만 체크포인트 정지 한도에 포함되며, 오버플로우되지 않은 검사는 연속을 유지하고 이후 턴에 재시도합니다. 호출은 스트리밍되므로 요청별 전송 타임아웃은 연결 및 첫 번째 응답에만 적용되며, 상한 자체는 스트림 가드의 15분 수명 한도에서 중지됩니다. 이를 초과하면 설정이 아닌 가드가 검사를 종료합니다. 설정의 15분 한도는 고정되어 있으며, 스트림 가드 자체의 상한을 높여도 이 한도는 올라가지 않습니다.

실패한 체크포인트는 Goal을 중지하기 전에 표시됩니다. 활성 Goal의 정지 연속이 진행되는 동안 푸터 필은 자동으로 checkpoint N/3 stalled로 전환되며, Goal이 일시 중지되거나 중지되면 필이 해당 상태를 대신 표시합니다. Web Shell의 Goal 상태 표시줄은 상태에 관계없이 카운트를 표시합니다. 터미널 Goal 상태 카드가 렌더링될 때마다(예: /goal, 일시 중지, 재개 또는 검증자 카드), Goal이 허용하는 3회 중 연속으로 실패한 검사 횟수와 기록된 마지막 실패가 함께 표시됩니다. Web Shell의 Goals 대화상자와 헤드리스 /goal 텍스트 출력도 같은 라인을 표시하며, Web Shell의 Goal 이벤트 트랜스크립트 카드는 중지 이유만 표시하고, 모델은 Goal을 읽을 때 두 필드를 모두 확인합니다. 창에 아직 여유가 있는 동안 실패한 검사도 정지 횟수를 소모하지 않고 표시되지만, Goal이 활성 상태일 때만, 또는 해당 실패 자체가 Goal을 중지한 경우(체크포인트 요청이 너무 커서 전송할 수 없는 경우 등)에만 표시됩니다. 다른 이유로 중지된 체크포인트는 실패를 초기화하고 연속을 유지하며, 완료된 Goal은 체크포인트 라인을 표시하지 않습니다. 실패는 제어 문자가 제거된 단일 라인으로 보관됩니다. 3개의 정지된 체크포인트로 중지된 Goal은 마지막 체크포인트가 직면한 문제를 명시합니다. 체크포인트 주장 한도 내에서 창에 맞출 수 없었던 검사(여전히 증거를 남긴 전체 주장 목록이거나 주장 수나 크기 예산을 초과한 주장)는 목표가 하나의 창이 보관할 수 있는 것보다 더 많은 증거를 생성한다는 의미이므로 범위를 좁히세요. 주장으로 접을 수 없었던 응답은 체크포인트 모델이 요청된 구조화된 출력을 반환하지 않는다는 의미이며, 목표 범위를 좁힌다고 해결되지 않습니다. 응답이 전혀 없는 검사는 도달할 수 없거나 속도 제한이 적용된 제공자, model.goalCheckpointTimeoutSeconds 내에 완료하지 못한 검사, 또는 검사 자체의 오류를 의미할 수 있습니다. 기록된 실패가 어느 것인지 알려줍니다. 세 가지 중 어느 것으로부터든 재개하면 새 증거 창이 시작됩니다.

Goal 중단

Goal 턴을 취소하면 Goal이 일시 중지됩니다. 모델이 응답 중이거나 도구가 아직 실행 중인 동안 Esc을 누르면 턴이 중지되고 Goal이 paused로 이동하며, 카드와 /goal 모두 왜 중지되었는지 표시합니다. /goal resume을 실행할 때까지 아무것도 계속되지 않습니다.

Goal이 활성 상태인 동안 메시지를 입력해도 일시 중지되지 않습니다. 메시지는 다음 Goal 턴으로 실행되므로 이를 사용하여 작업을 유도하세요. 중지하려면 /goal pause 또는 /goal clear를 사용하세요.

모든 일시 중지는 그 이유를 명시합니다: 사용자가 중단한 경우, /goal pause를 실행한 경우, 세션 토큰 한도가 다음 모델 요청을 차단한 경우, 턴이 실패한 경우, 또는 연속 세 턴이 검증자가 판정할 수 있는 아무것도 기록하지 않고 제안도 하지 않은 경우입니다. Goal 북키핑 읽기(get_goal, update_goal)는 진행으로 간주되지 않습니다. 한도로 중지된 Goal은 해당 한도의 이유를 대신 유지합니다.

Goal 판정 방식

검증자는 자체적으로 명령어를 실행하거나 파일을 읽지 않습니다. 트랜스크립트에 이미 있는 내용만 증거로 봅니다:

• 보이는 어시스턴트 출력과 도구 결과가 증거로 인정됩니다. 목표 텍스트, 사용자 프롬프트, 모델의 숨겨진 추론은 증거가 되지 않습니다.
• 출력된 텍스트는 텍스트가 출력되었다는 것만 증명합니다. 테스트가 통과했다는 주장, 파일이 변경되었다는 주장, 원격이 업데이트되었다는 주장은 트랜스크립트에 해당 도구 결과가 필요합니다.
• 사용자가 확인, 선택 또는 승인했다는 주장은 사용자의 실제 메시지가 필요합니다. 검증자는 이를 가정하는 제안을 거부합니다.
• 증거가 없으면 판정은 “아직 완료되지 않음”이지 “완료”가 아닙니다. 아무도 증거로 확인할 수 없는 조건은 한도가 멈출 때까지 루프를 계속 실행합니다.

따라서 목표는 에이전트가 증거를 생산하도록 만들어야 합니다: 명시된 검사를 실행하고 결정적인 출력을 보여줘야 합니다.

좋은 목표 작성법

목표에 다음을 이 순서로 포함하세요:

목표는 하나로 유지하세요. /goal set과 /goal edit은 임의의 길이를 허용하지만 대략 1,200자 이하로 유지하세요. 목표는 매 Goal 턴마다 재전송됩니다. 모델이 propose_goal를 통해 제안하는 목표는 1,500자로 제한됩니다. 두 명령어 모두 개행을 공백으로 변환하므로, 줄바꿈에 의존하지 말고 항목에 번호를 매기세요.

Budget은 언제 중지하고 차단점을 보고할지에 대한 모델에 대한 지시이며, 모델이 이를 따를지 따르지 않을지는 보장되지 않습니다. 런타임 자체를 턴 수나 시간 제한에서 중지하려면 model.goalMaxTurns 또는 model.goalMaxActiveMinutes를 설정하세요. 목표에 이 둘을 작성하는 것은 해당 설정을 구성하지 않으며, Goal의 토큰 예산을 변경하지도 않습니다.

/goal-draft로 작성하기

/goal-draft <what you want done>는 위 과정을 대신 수행하는 번들 skill입니다. 워크스페이스를 범위와 실제 검증 명령어를 파악할 수 있을 만큼만 읽으며, 테스트 실행, 빌드, 의존성 설치, 서비스 시작은 하지 않습니다. 필수적인 선택이 불분명할 때 최대 한 번의 질문을 하고, 간결한 목표를 작성하며, 보통 3–5개의 완료 검사를 포함합니다(충분하면 더 적게). 명시적 요구사항은 유지되며, 횟수를 채우기 위해 검사를 추가하지 않습니다.

감사의 경우, 완료는 합의된 시나리오를 다루고 재현 단계를 포함한 증거를 보고하는 것을 의미합니다. 결함을 찾지 못한 것도 유효한 결과입니다. 초안은 시나리오, 증거 파일, 탐색 라운드, 결함의 최소 개수를 임의로 만들지 않습니다.

성공 기준, 명령어, 입력 경로 또는 필수 결정을 확정할 수 없으면, skill은 <TODO: …> 항목과 함께 “Needs clarification”로 표시된 초안을 반환합니다. 해당 초안을 승인용으로 제공하거나 실행 가능한 /goal set 또는 /goal edit 명령어를 출력하지 않습니다. 비필수적 기본값은 [ASSUMPTION]으로 표시되며, 누락된 성공 기준을 대신하지 않습니다.

목표가 준비되면 대화형 터미널 세션에서 아래에 설명된 propose_goal 승인 대화상자를 표시할 수 있습니다. Web Shell 및 기타 ACP 클라이언트, 헤드리스 실행, 도구가 비활성화된 세션, 활성 Goal이 있는 세션은 대신 수동으로 실행할 명령어를 받습니다. 전달 시 초안이 적용되지 않았음을 알립니다. skill은 자체적으로 작업을 시작하지 않으며, 승인 없이는 아무것도 설정되지 않습니다.

기존 목표를 전달하여 더 엄격하게 만들 수 있습니다: /goal-draft all tests pass and the lint is clean. 활성 Goal에 대해 명시적으로 엄격하게 만들도록 요청하면 /goal edit가 생성되며, 교체는 /goal set을 사용합니다. 의도한 작업이 불분명하면, skill은 단일 질문 라운드에서 해당 선택을 포함합니다.

모델이 제안한 Goal 승인

대화형 터미널 또는 연결된 클라이언트가 있는 Web Shell 턴에서 모델은 propose_goal 도구를 가집니다. /goal-draft가 완료되거나 여러 턴에 걸친 결과를 요청하면, 복사할 /goal set … 라인을 출력하는 대신 목표를 제안할 수 있습니다. 제안은 전체 목표를 표시하는 승인 대화상자로 나타납니다. 승인하면 현재 턴이 끝나는 순간(/goal set과 정확히 동일하게) Goal이 설정됩니다(모델이 확인하고 중지한 후 첫 번째 Goal 턴이 자동으로 시작됨). 거부하면 아무것도 설정되지 않으며, 모델은 도구 호출이 허용되지 않았다는 사실만 확인하며, 왜 허용되지 않았는지 묻지 않고 같은 목표를 다시 제안하지 않도록 지시됩니다. 승인은 그것을 요청한 턴에 바인딩됩니다: 해당 턴이 취소되거나 어떤 식으로든 종료에 도달하지 못하면, 승인은 이후 메시지나 자동 턴 아래에서 적용되는 대신 폐기됩니다. 어떤 권한 규칙이나 승인 모드(YOLO 포함)도 이 대화상자를 건너뛸 수 없으며, 다른 Goal이 활성 상태인 경우, 계획 모드에서, 그리고 신뢰할 수 없는 폴더에서는 도구가 거부되며, 서브에이전트에게는 제공되지 않습니다. Web Shell은 기존 Allow/Reject 권한 패널을 사용합니다. 중지된 Goal은 승인 시 표시된 버전과 여전히 일치하는 경우에만 교체할 수 있으며, 변경하면 제안이 무효화됩니다. 헤드리스 실행, Web Shell 채널 전달 및 자동 턴, 그리고 필요한 승인 및 턴 수명 주기를 지원하지 않는 ACP 클라이언트는 출력된 /goal set 전달 방식을 유지합니다.

사용자 설정에서 goals.modelProposed: "disabled"로 끌 수 있습니다. 이 설정은 모델이 자율 루프를 시작하도록 요청할 수 있는지 결정하므로, 사용자 및 시스템 범위에서만 적용됩니다. 워크스페이스의 .qwen/settings.json 값은 경고와 함께 무시됩니다.

이 skill은 읽기 전용으로 지시되며, 비변경 도구만 자동 승인됩니다(get_goal, read_file, glob, grep_search). ask_user_question는 의도적으로 자동 승인되지 않으므로, 답변 대화상자가 skill이 답변을 기반으로 초안 작성하기 전에 표시됩니다. 다른 번들 skill과 마찬가지로, goal-draft라는 이름의 프로젝트 또는 개인 skill이 이를 재정의하며, skills.disabled로 끌 수 있습니다. 번들 skill이 발견되는 방식은 Skills를 참조하세요.