에이전트 결과문 최소 근거 운영 적용안

1. 목적

최근 버스 메시지에서 반복된 missing_original_verification, missing_source, missing_execution_value, missing_verification_value 차단을 줄이기 위해 에이전트 결과문에 들어갈 최소 근거 양식을 운영 기준으로 고정한다.

이 문서는 코드 수정안이 아니다. 큐 지시문, 결과문 작성, 대행 작업 완료 검토에 바로 적용하는 운영 문서다.

2. 최근 실측 근거

• 조회 시각: 2026-09-01 04:56:59 KST.
• 조회 대상: ops_multiagent.db의 bus_commands 최근 result_note.
• 최근 확인 사례: #37628 cowork failed, #37625 ron failed, #37622 ron failed, #37619 ron done.
• 최근 차단 에이전트 집계: ron 3건, cowork 1건.
• 반복 차단 문구: missing_original_verification, missing_source, missing_execution_value, missing_verification_value, 근거 섹션 미기재.
• 완료 기준 근거: #37619는 최근 48시간 9건 전수 조회, failed 7건, done 1건, claimed 1건, missing_source 4건, missing_original_verification 4건을 포함해 done 처리됐다.

3. 공통 최소 근거 양식

모든 에이전트 결과문은 아래 6칸을 채운다.

칸	필수 내용	통과 기준
원본	원본 command id, 원래 요청자, 원래 대상, 대행 사유	어떤 요청을 처리했는지 다시 찾을 수 있다.
산출물	생성된 문서, 메시지, 패치, 표, 보고서, 데이터 묶음	이름이나 식별자가 있다.
실행값	조회 건수, 변경 건수, 표본 수, 통과 수, 실패 수 중 최소 1개 숫자	결론을 뒷받침하는 숫자가 있다.
검증값	재조회 결과, 테스트 결과, 원문 대조 결과, 기대값과 실제값	완료 판단이 결과문 안에서 재현된다.
저장위치	파일 위치, 메시지 id, 로그 식별자, 큐 id	사후 감사자가 다시 열어볼 수 있다.
다음 행동	추가 없음, 관찰, 재시도, 보류, 담당 전환, 쿨다운 대기	후속 상태가 명확하다.

공통 불합격 예시: - “정리 완료”만 있고 원본 id와 검증값이 없다. - “확인했습니다”만 있고 조회 건수나 실패 건수가 없다. - “근거 섹션 미기재”, “확인 못함”, “도구 실행 불가”가 남아 있다. - 인프라 장애, 요청 과다, 타임아웃을 검증근거 누락으로 다시 위임한다. - 존재하지 않는 파일명이나 메시지 id를 산출물처럼 적는다.

4. 에이전트별 필수 근거 항목과 불합격 예시

4.1 ron

필수 근거 항목: 1. 원본 command id와 실제 수행자, 원래 대상, 대행 사유. 2. 조회한 버스 메시지 수, 실패 수, 완료 수, 차단 문구 집계 중 최소 2개 숫자. 3. 생성한 운영 문서, 보고서, 메시지, 큐 처리 결과의 식별자. 4. 완료 전 재조회 또는 파일 확인 결과. 5. 미확인 항목이 있으면 미확인이라고 적고 done으로 닫지 않는다.

통과 예시: - “원본 #37628, cowork 인프라 쿨다운으로 ron 대행. 최근 4건 재조회 결과 ron 3건, cowork 1건 차단. 산출물 1건 작성. 파일 확인 완료. 다음 행동: 24시간 재발 관찰.”

불합격 예시: - “기준 정리 완료. 다음에 반영.” - “cowork 작업을 대신 처리함”만 있고 원본 id와 대행 사유가 없다. - “최근 사례 확인”이라고만 쓰고 몇 건인지 없다. - 이전 결론을 복사하고 실제 재조회 결과가 없다.

4.2 analyst

적용 대상: analyst-fundamental, analyst-macro, analyst-technical, analyst-pm.

필수 근거 항목: 1. 분석 대상: 기업, 지표, 티커, 포트폴리오, 섹터, 하위테마 중 하나. 2. 데이터 기준일과 원천 이름. 3. 표본 수, 변화율, 가격, 금리, 수익률, 점수 등 핵심 숫자. 4. 결론 바로 옆의 판단 근거와 시장 해석. 5. 다음 관찰 지표와 재확인 시점.

통과 예시: - “기준일 2026-09-01, 표본 26개 티커. 과열 신호 7개, 완화 3개. 반도체는 가격 상승보다 폭이 좁아 추격 매수 보류. 다음 확인: 내일 같은 지표 재측정.”

불합격 예시: - “시장 분위기 좋음”처럼 숫자와 원천이 없다. - “반도체 강세”라고 쓰고 기준일, 티커, 가격 변화가 없다. - 원천이 블로그인지 가격 데이터인지 구분하지 않는다. - 시장공통, 섹터, 하위테마를 섞어 결론을 낸다. - 최신성 확인 없이 과거 데이터를 오늘 판단처럼 쓴다.

4.3 guardian

필수 근거 항목: 1. 점검 범위: 프로세스, 데이터베이스, 크론, 큐, 디스크, 게이트웨이, 워커, 로그 중 무엇을 봤는지. 2. 점검 시각과 대상 수: 살아있는 수, 실패 수, 멈춘 수, 오래 막힌 수. 3. 장애 기준: 무엇이면 정상이고 무엇이면 실패인지. 4. 복구했다면 복구 전후 상태값. 5. 권한 차단, 쿨다운, 인프라 장애를 검증근거 누락과 분리한다.

통과 예시: - “점검 시각 04:56, 워커 8개 중 8개 생존, 큐 claimed 1건, failed 3건. 데이터베이스 무결성 ok. 복구 필요 없음. 다음 행동: failed 3건만 재분류.”

불합격 예시: - “시스템 정상”만 있고 프로세스 수나 실패 수가 없다. - “복구 완료”라고 쓰고 복구 후 재조회 값이 없다. - “blocked: not in whitelist”를 보안 사고로 오분류한다. - 크론 비활성화나 격리를 하고 사유와 되돌림 조건을 남기지 않는다. - 로그 원문 없이 요약만 남긴다.

4.4 codex

필수 근거 항목: 1. 변경한 파일과 변경 범위. 2. 실제 실행한 명령과 종료 결과. 3. 테스트 결과: 통과 수, 실패 수, 실패명 중 최소 1개. 4. 변경 전후 차이 또는 대상 함수 이름. 5. 남은 위험과 되돌림 조건.

통과 예시: - “파일 1개 수정, 함수 2곳에 검증값 추가. 문법검사 1건 통과, 관련 테스트 45건 통과. 변경 차이 확인. 다음 행동: 24시간 차단 로그 관찰.”

불합격 예시: - “테스트할 예정”처럼 실행 전 선언으로 끝난다. - 존재하지 않는 테스트 파일이나 함수명을 통과 근거로 쓴다. - 코드가 아닌 정책 문서 작업을 코드 완료처럼 보고한다. - 실패 로그 없이 “아마 환경 문제”라고 쓴다. - 검증 명령은 적었지만 실제 결과값이 없다.

4.5 cowork

필수 근거 항목: 1. 비교한 원본 문서, 버스 사례, 정책 기준의 식별자. 2. 표본 수와 결론 수: 몇 건을 보고 몇 개 기준으로 압축했는지. 3. 적용 대상: 어느 에이전트와 어느 결과문 표면에 적용하는지. 4. 운영 적용 문서나 메시지 식별자. 5. 불합격 기준과 보류 기준.

통과 예시: - “버스 사례 4건과 기존 기준 3건을 대조. ron, analyst, guardian, codex, cowork 5개 분류로 압축. 결과문 6칸 기준 작성. 불합격 예시 포함. 다음 행동: 큐 지시문에 문구 반영.”

불합격 예시: - “정책안 작성 완료”만 있고 어떤 사례를 봤는지 없다. - 적용 대상이 “전체”로만 되어 있고 에이전트별 차이가 없다. - 불합격 예시가 없어 현장에서 반려 기준으로 쓸 수 없다. - 코드 수정이 아닌데 테스트 통과만 완료 근거로 삼는다. - 원문 확인 없이 이전 요약을 다시 쓴다.

5. 결과문 작성 규칙

결과문은 아래 순서로 쓴다.

1. 결론: 한 문장.
2. 근거: 첫 600자 안에 원본 id, 표본 수, 차단 문구, 산출물 식별자 중 2개 이상.
3. 산출물: 실제 결과물 이름 또는 메시지 id.
4. 실행값: 숫자 1개 이상.
5. 검증값: 재조회, 파일 확인, 테스트, 원문 대조 중 하나.
6. 다음 행동: 추가 없음, 관찰, 재시도, 보류, 담당 전환, 쿨다운 대기 중 하나.

6. 즉시 반려 기준

아래 중 하나라도 있으면 done으로 닫지 않는다.

반려 문구 또는 상태	처리
missing_original_verification	원본을 다시 읽고 원본 id와 표본 수를 채운다.
missing_source	출처 이름과 기준시각을 채운다.
missing_execution_value	조회 건수, 변경 건수, 통과 수 같은 실행 숫자를 채운다.
missing_verification_value	기대값과 실제값을 채운다.
missing_stdout_excerpt	원문 일부 또는 로그 식별자를 채운다.
missing_verification_result	검증 결과값을 채운다.
근거 섹션 미기재	6칸 양식으로 다시 작성한다.
llm_infra_failure, 429, 타임아웃	검증근거 누락이 아니라 인프라 장애로 분리하고 쿨다운 또는 재시도로 보낸다.

7. 운영 적용 문구

새 결과문은 “원본, 산출물, 실행값, 검증값, 저장위치, 다음 행동” 6칸이 비면 완료로 닫지 않는다. ron은 대행 사유와 큐 재조회 숫자, analyst는 기준일·원천·핵심 수치, guardian은 점검 범위·상태값·복구 전후, codex는 변경 파일·실행 명령·테스트 결과, cowork는 비교 원본·표본 수·불합격 예시를 반드시 남긴다.

8. 이번 문서 검증

• 원본 확인: #37628, #37625, #37622, #37619를 조회했다.
• 기존 기준 확인: 260901 최소 기준, 260831 대행 작업 필수 필드 기준, 260827 검증근거 정책안을 읽었다.
• 포함 검증: ron, analyst, guardian, codex, cowork 각각 필수 근거 항목과 불합격 예시를 포함했다.
• 코드 수정 여부: 없음.

9. 지식망 연결

• [[260901_ron_검증근거_누락방지_최소기준]]
• [[260831_대행작업_필수필드_최종운영기준]]
• [[260827_cowork_완료보고-검증근거-필수화-정책안]]
• [[MOC-Hermes-비코딩-오배정방지-260831]]