needs_evidence 44건 반려 사유별 분류와 태스크 본문 템플릿 개선안
needs_evidence 반려 분류와 태스크 본문 템플릿 개선안 (cowork 제안서)
조회: 2026-10-16 07:49:37 KST / DB: /Users/ron/.hermes/data/ops_multiagent.db (sqlite3 -readonly, SELECT만 실행, 코드·DB 수정 없음)
0. 먼저 알아둘 점 (태스크 전제 정정)
- 현재 큐의 status='needs_evidence'는 정확히 44건이다(id 40276~41780, 최초 생성 2026-09-28 13:07:27). 이 44건은 "최근 7일"이 아니라 큐에 남은 전체다.
- 최근 7일(updated_at >= 2026-10-09 07:49:37) 기준은 24건이다. 나머지 20건은 09-28~10-08에 반려된 뒤 계속 남아 있는 건이다. 아래 1절은 44건 전체, 1-2절은 7일 24건이다.
1. 집계표 (에이전트 x 반려 라벨)
집계 규칙: result_note의 "차단 사유: ..." 줄에서 라벨을 뽑는다. 한 건에 라벨이 여러 개면 구체 라벨(missing_* 등)을 대표 라벨로 쓰고, 일반 문구("결과 확인 보류", "검증 근거 없음", "결과물과 검증 근거가 없음")만 있는 건은 별도 행으로 묶는다. 건당 대표 라벨 1개라 합계가 44건이다.
| 반려 대표 라벨 | guardian | cowork | analyst-pm | analyst-macro | ron | 합계 |
|---|---|---|---|---|---|---|
| (일반문구만: 결과 확인 보류/검증 근거 없음) | 12 | 2 | 0 | 0 | 0 | 14 |
| missing_verification_exit_code | 9 | 0 | 0 | 0 | 0 | 9 |
| missing_result_or_verification | 0 | 0 | 4 | 4 | 0 | 8 |
| invalid_verification_exit_code | 5 | 1 | 0 | 0 | 1 | 7 |
| missing_execution_artifact | 2 | 0 | 0 | 0 | 0 | 2 |
| completion_result_note_forces_rework | 1 | 1 | 0 | 0 | 0 | 2 |
| verification_command_unverifiable | 0 | 1 | 0 | 0 | 0 | 1 |
| execution_artifact_path_not_found | 1 | 0 | 0 | 0 | 0 | 1 |
| 합계 | 30 | 5 | 4 | 4 | 1 | 44 |
1-1. 라벨 중복 집계 (한 건에 라벨 여러 개 허용, 합계가 44를 넘음)
결과 확인 보류 15 / missing_verification_exit_code 12 / missing_result_or_verification 10 / 검증 근거 없음 8 / invalid_verification_exit_code 7 / 결과물과 검증 근거가 없음 6 / missing_verification_command 3 / missing_execution_artifact 2 / completion_result_note_forces_rework 2 / verification_command_unverifiable 1 / execution_artifact_path_not_found 1
1-2. 최근 7일 24건만
| 반려 대표 라벨 | guardian | cowork | analyst-pm | analyst-macro | ron | 합계 |
|---|---|---|---|---|---|---|
| (일반문구만: 결과 확인 보류/검증 근거 없음) | 9 | 2 | 0 | 0 | 0 | 11 |
| invalid_verification_exit_code | 4 | 1 | 0 | 0 | 0 | 5 |
| missing_verification_exit_code | 3 | 0 | 0 | 0 | 0 | 3 |
| missing_result_or_verification | 0 | 0 | 0 | 2 | 0 | 2 |
| execution_artifact_path_not_found | 1 | 0 | 0 | 0 | 0 | 1 |
| missing_execution_artifact | 1 | 0 | 0 | 0 | 0 | 1 |
| completion_result_note_forces_rework | 1 | 0 | 0 | 0 | 0 | 1 |
| 합계 | 19 | 3 | 0 | 2 | 0 | 24 |
1-3. 요청하신 라벨 문자열 단순 포함(LIKE) 건수 (44건 대상)
missing_execution_value 1 / missing_source 1 / missing_verification_value 0 / missing_original_verification 1 / execution_artifact_path_not_found 1 / llm_infra_failure 12. - 주의: 이 LIKE 숫자는 반려 사유가 아니다. "차단 사유:" 줄에 실제로 들어간 라벨 중 llm_infra_failure는 0건이다. LIKE로 잡히는 12건은 guardian·cowork의 "반려 사유 집계" 보고서가 "원본 요약" 안에서 이 단어들을 인용한 것이다. 직전 집계(CMD#41640)가 llm_infra_failure 14건을 1위 원인으로 낸 것도 같은 인용 때문이다. 인프라 지연 반려는 현재 0건이다. - 요청 라벨 중 missing_execution_value, missing_source, missing_verification_value, missing_original_verification은 현재 44건의 "차단 사유:" 줄에 한 번도 나오지 않는다. 현재 큐에서 실제로 쓰이는 라벨은 1절 표의 8종이다. - 자기참조: 제목에 needs_evidence 또는 반려가 들어간 건이 30건(guardian 25, cowork 5)으로 전체의 68%다. 집계 과제가 반려 건을 다시 만들고 있다.
2. 상위 3개 에이전트 실제 result_note 확인
상위 3 = guardian 30건, cowork 5건, analyst-pm 4건과 analyst-macro 4건(동률). 사용자 요청 패턴(분석 태스크)을 보기 위해 3번째로 analyst-macro를 골랐다. 큐 DB의 result_note는 게이트가 만든 차단 문구 + "원본 요약" 약 200자로 잘려 저장되어 있어, 원문은 /Users/ron/.hermes/logs/agent-queue-{guardian,cowork,macro}.log 의 결과 JSON에서 읽었다.
| 에이전트 | CMD | DB 저장 차단 사유 | 원문에서 4블록 | 빈/문제 블록 |
|---|---|---|---|---|
| guardian | 41640 (needs_evidence·failed 44건 집계) | missing_verification_exit_code | 결론/근거/검증/근거파일 라벨 4개 모두 있음 | 검증 블록에 "첫 쿼리의 exit code는 0이다"로 조사가 끼어 있어 리터럴 "exit code 0" 없음. 근거에 "결과 확인 보류/검증 근거 없음" 같은 게이트 문구를 인용. 재판정하면 ['확인 보류','검증 근거가 없음','근거 없음'] |
| cowork | 41715 (41건 방지안 문서) | 결과 확인 보류(구체 라벨 없음) | 4블록 모두 있고 산출물 경로·ls 결과·exit code 0 포함 | 본문 설명 중 "결과 확인 보류" 같은 차단 문구를 그대로 인용. 재판정하면 ['확인 보류'] 1개만 걸림. 즉 블록이 빈 게 아니라 인용 문구에 자기 반려됨 |
| analyst-macro | 41769 (IG·HY OAS 판독) | missing_result_or_verification | 4블록 모두 있고 exit code 0, 근거파일 줄번호·원문 인용 포함 | 빈 블록 없음. 원문 앞에 [액션]/[데이터]/[인사이트] 서술이 1,100자 이상 먼저 오고 4블록은 그 뒤({'결론:'} 위치 1199자)에 있음 |
원문 4블록 + 게이트 재판정(agent_queue_worker.py의 _completion_block_reasons, 읽기전용 호출) 결과: - 41769, 41780(analyst-macro): 원문 전체로 재판정하면 사유 [] (통과). 반려 사유 재현 안 됨. - 40408, 40518(analyst-macro, 09-29/09-30): 원문 전체는 통과. 노트를 600자로 줄인 형태로 재판정하면 verification_command_unverifiable / verification_command_path_not_found 로 걸림(원문 앞부분 서술 때문에 검증 명령 줄이 잘려 나감).
3. 판정: "계산은 했는데 산출물 파일 경로를 안 남겨서 반려" 패턴인가
판정: 아니오. 분석 태스크 반려의 주된 원인이 산출물 경로 누락이라는 증거는 없다. 근거: 1. 로그 원문을 직접 연 analyst-macro 4건(40408, 40518, 41769, 41780) 모두 결론/근거/검증/근거파일 4블록과 "exit code 0"이 있고, 근거파일에 JSON 경로+줄번호+원문 인용이 있다. 경로 누락 아님. 2. 4건 중 2건(41769, 41780)은 태스크 본문에 산출물 파일 저장 요구가 아예 없다(결과를 result_note에만 쓰는 과제). 40408도 본문이 "memory/에 저장하지 말고 result_note에만 기록"을 지시했다. 저장 경로를 요구한 건 40518 하나뿐이고, 40518은 저장 경로(/Users/ron/knowledge-agent/100-inbox/260930_hermes_us-ig-oas-trend.md)가 원문에 있으며 ls -l로 실존 확인 결과(1833바이트)까지 있다(파일 실존 확인함). 3. DB에 저장된 차단 사유 라벨은 missing_result_or_verification 하나뿐이고, "결과물 경로 누락"을 뜻하는 missing_execution_artifact는 analyst 계열 0건(guardian 2건뿐)이다. 4. 전체 44건으로 보면 산출물 경로 계열(missing_execution_artifact 2 + execution_artifact_path_not_found 1)은 3건(7%)이다. 최다는 exit code 계열(missing 9 + invalid 7 = 16건, 36%)과 일반 문구만 남은 14건(32%)이다.
원인 추정 (확인한 범위와 못 확인한 범위를 구분): - 확인함: (a) 집계 과제(guardian·cowork)는 보고서 안에 "결과 확인 보류" 같은 게이트 차단 문구를 인용해 자기 반려됨. (b) exit code 줄에 "exit code는 0이다"처럼 조사를 끼우면 리터럴 불일치. (c) 15건 원문을 600자 요약으로 줄여 재판정하면 40297, 40408, 40518, 40960, 41035, 41348, 41640이 verification_/missing_ 로 걸린다. 서술을 앞에 길게 쓰면 4블록이 잘리는 구조로 보인다. - 미확인: analyst-macro 41769·41780과 analyst-pm 40874·41067은 내 재판정으로는 600자 요약에서도 통과해서, 실제 워커가 어느 입력을 보고 missing_result_or_verification을 냈는지는 재현하지 못했다. 이 부분은 codex가 워커 실행 경로에서 게이트 입력값을 로그로 남겨 확인해야 한다(코드 수정이므로 이번 범위 밖).
4. 태스크 본문 템플릿 개선안 (orchestrator가 body에 붙일 문구)
방향: 산출물 경로 요구는 "산출물이 필요한 과제"에만 붙이고, 4블록은 노트 맨 앞에 두게 한다. 파일 저장 과제와 result_note 전용 과제를 구분한다.
4-A. 산출물 파일을 저장하는 과제 (md/json 저장)
산출물: {절대경로} 에 저장한다. 날짜가 들어간 파일명(예: YYMMDD_hermes_주제.md)을 쓰고 frontmatter(title, date, source, tags)를 넣는다.
완료 보고: result_note의 맨 앞 줄부터 아래 4블록 라벨을 그대로 쓴다. 분석 서술은 4블록 뒤에 쓴다.
결론: {무엇을 계산/작성했는지 완료형 한 문장 + 핵심 수치}
근거: 읽은 입력 파일 경로와 최신 관측일·값, 조회 시각(KST)
검증: ls -l {산출물 절대경로} → 파일 크기·시각 출력, 그리고 실제 실행한 파싱 명령 → 출력값. 문장 끝에 정확히 "exit code 0"
근거파일: {산출물 절대경로}:{줄번호} "{해당 줄 원문 일부}" 와 입력 파일 경로:{줄번호} "{원문 일부}"
4-B. 파일 저장 없이 result_note에만 쓰는 분석 과제
산출물: 별도 파일 없음. 결과는 result_note에만 쓴다.
완료 보고: result_note 맨 앞 줄부터 4블록 라벨로 시작한다. 표·해석은 4블록 아래에 붙인다.
결론: {완료형 한 문장 + 핵심 수치}
근거: 읽은 입력 파일 경로, 최신 관측일, 조회 시각(KST)
검증: 실행한 명령 전체 → 출력값. 줄 끝을 "exit code 0"으로 마친다("exit code는 0이다"처럼 조사를 끼우지 않는다).
근거파일: 입력 파일 경로:줄번호 "원문 일부" (파일이 실제로 존재하는 경로만)
4-C. 공통 금지 문구 (집계·분류 과제 포함 모든 과제에 한 줄 추가)
보고서 본문과 4블록 안에 "결과 확인 보류", "검증 근거 없음", "결과물과 검증 근거가 없음", "근거 섹션 미기재" 같은 차단 문구를 그대로 인용하지 않는다. 라벨 이름이 필요하면 따옴표 없이 "라벨 A류"처럼 바꿔 쓴다. 건수는 "차단 사유:" 줄에서 뽑은 값만 반려 사유로 센다(본문 속 인용 단어는 세지 않는다).
4-D. 분류·집계 과제 전용 한 줄
집계 대상 result_note의 라벨은 "차단 사유:" 줄에서만 추출한다. LIKE로 단어 포함 건수를 센 값을 반려 사유로 쓰지 않는다.
적용 위치 후보(코드 수정은 codex 몫): 분석 과제 템플릿을 만드는 orchestrator.py의 "자동 보강: 완료보고 4블록 설명형 라벨 보충" 상용구. 지금은 "검증: exit code 0; 통과"처럼 예시가 완성형 문구로 들어가 에이전트가 그대로 베끼거나 혼동할 수 있다(2026-10-15 방지안 문서가 이 상용구 복제 5곳을 이미 지적: /Users/ron/.hermes/workspace/memory/2026-10-15_needs_evidence_41_prevention_plan.md).
5. 권고 / 현황 / 리스크 / 검증방법
- [권고]
- 1순위: 집계·분류 과제 본문에 4-C, 4-D 두 줄 추가. 44건 중 자기참조 30건(68%)과 일반 문구만 남은 14건이 겹치는 영역이라 가장 효과가 크다. 기대: 해당 유형 반려 신규 발생 0건/24시간.
- 2순위: 분석 과제(analyst-macro/pm)에 4-B를 붙이고 4블록을 노트 맨 앞에 두게 한다. 기대: analyst 계열 missing_result_or_verification 신규 0건/주.
- 3순위(codex): 워커가 게이트에 넘기는 note 원문을 반려 시 로그에 남겨 analyst 4+4건의 미재현 원인 확인.
- [현황] needs_evidence 44건(guardian 30, cowork 5, analyst-pm 4, analyst-macro 4, ron 1). 7일 기준 24건. 산출물 경로 계열 3건(7%), exit code 계열 16건(36%), 일반 문구만 14건(32%), analyst 계열 missing_result_or_verification 8건(18%).
- [리스크] 반려 사유 집계 과제가 새 반려를 만드는 순환이 계속된다(자기참조 30건). DB의 result_note가 약 200자로 잘려 저장돼 사후 분류 정확도가 낮다(라벨 LIKE 집계가 사실과 다른 수치를 냈다). 분석 4+4건의 실제 반려 원인은 아직 재현 못 했다.
- [검증방법] 템플릿 적용 후 24시간 뒤
sqlite3 -readonly /Users/ron/.hermes/data/ops_multiagent.db "SELECT claimed_by,count(*) FROM bus_commands WHERE status='needs_evidence' AND created_at>=datetime('now','localtime','-1 day') GROUP BY 1"기대값: 신규 건수 0~1. 3일 뒤에도 제목에 반려/needs_evidence가 든 신규 건이 2건 이상이면 4-C를 워커 게이트 쪽 수정으로 승격(롤백 기준: 템플릿 적용 후 done 전환율이 적용 전보다 낮아지면 되돌림).