OpenClaw 한국어 문서

Appearance

상시 명령 ​

상시 명령은 에이전트에게 정의된 프로그램에 대한 영구적인 운영 권한을 부여합니다. 매번 개별 태스크 지시를 내리는 대신, 명확한 범위, 트리거, 에스컬레이션 규칙이 있는 프로그램을 정의하면 에이전트가 해당 경계 내에서 자율적으로 실행합니다.

이는 매주 금요일에 "주간 보고서를 보내세요"라고 지시하는 것과 상시 권한 부여의 차이입니다: "주간 보고서를 담당하십시오. 매주 금요일에 컴파일하여 발송하고, 이상한 점이 있을 때만 에스컬레이션하십시오."

상시 명령이 필요한 이유 ​

상시 명령 없이:

  • 모든 태스크마다 에이전트에게 프롬프트를 보내야 합니다
  • 에이전트는 요청 사이에 유휴 상태입니다
  • 일상적인 작업이 잊혀지거나 지연됩니다
  • 사용자가 병목이 됩니다

상시 명령과 함께:

  • 에이전트가 정의된 경계 내에서 자율적으로 실행합니다
  • 일상적인 작업이 프롬프트 없이 일정대로 진행됩니다
  • 예외 및 승인이 필요한 경우에만 관여합니다
  • 에이전트가 유휴 시간을 생산적으로 활용합니다

작동 방식 ​

상시 명령은 에이전트 작업 공간 파일에 정의됩니다. 권장 방식은 AGENTS.md에 직접 포함하는 것입니다 (매 세션마다 자동 주입됨). 더 큰 설정의 경우, standing-orders.md와 같은 전용 파일에 배치하고 AGENTS.md에서 참조할 수도 있습니다.

각 프로그램은 다음을 지정합니다:

  1. 범위 — 에이전트가 수행할 권한이 있는 작업
  2. 트리거 — 실행 시점 (일정, 이벤트, 또는 조건)
  3. 승인 게이트 — 조치 전 사람의 승인이 필요한 항목
  4. 에스컬레이션 규칙 — 멈추고 도움을 요청해야 하는 시점

에이전트는 작업 공간 부트스트랩 파일을 통해 매 세션마다 이 지시를 로드합니다 (자동 주입되는 파일의 전체 목록은 에이전트 작업 공간 참조). 시간 기반 실행을 위해 크론 작업과 결합하여 실행됩니다.

TIP

AGENTS.md에 상시 명령을 넣어 매 세션마다 로드되도록 보장하십시오. 작업 공간 부트스트랩은 AGENTS.md, SOUL.md, TOOLS.md, IDENTITY.md, USER.md, HEARTBEAT.md, BOOTSTRAP.md, MEMORY.md를 자동으로 주입하지만, 하위 디렉터리의 임의 파일은 주입하지 않습니다.

상시 명령의 구조 ​

markdown
## 프로그램: 주간 상태 보고서

**권한:** 데이터 컴파일, 보고서 생성, 이해관계자에게 전달
**트리거:** 매주 금요일 오후 4시 (크론 작업으로 실행)
**승인 게이트:** 표준 보고서에는 없음. 이상 항목은 사람의 검토를 위해 플래그 표시.
**에스컬레이션:** 데이터 소스를 사용할 수 없거나 지표가 비정상적으로 보이는 경우 (정규 분포 2σ 초과)

### 실행 단계

1. 구성된 소스에서 지표 가져오기
2. 전주 및 목표와 비교
3. Reports/weekly/YYYY-MM-DD.md에 보고서 생성
4. 구성된 채널을 통해 요약 전달
5. Agent/Logs/에 완료 기록

### 하지 말아야 할 것

- 외부 당사자에게 보고서를 보내지 마십시오
- 소스 데이터를 수정하지 마십시오
- 지표가 나쁘게 보여도 전달을 건너뛰지 마십시오 — 정확하게 보고하십시오

상시 명령 + 크론 작업 ​

상시 명령은 에이전트가 수행할 권한이 있는 무엇을 정의합니다. 크론 작업은 언제 실행될지를 정의합니다. 이들은 함께 작동합니다:

상시 명령: "일일 받은 편지함 분류를 담당하십시오"
    ↓
크론 작업 (매일 오전 8시): "상시 명령에 따라 받은 편지함 분류 실행"
    ↓
에이전트: 상시 명령 읽기 → 단계 실행 → 결과 보고

크론 작업 프롬프트는 상시 명령을 복제하는 대신 참조해야 합니다:

bash
openclaw cron add \
  --name daily-inbox-triage \
  --cron "0 8 * * 1-5" \
  --tz America/New_York \
  --timeout-seconds 300 \
  --announce \
  --channel bluebubbles \
  --to "+1XXXXXXXXXX" \
  --message "Execute daily inbox triage per standing orders. Check mail for new alerts. Parse, categorize, and persist each item. Report summary to owner. Escalate unknowns."

예시 ​

예시 1: 콘텐츠 및 소셜 미디어 (주간 사이클) ​

markdown
## 프로그램: 콘텐츠 및 소셜 미디어

**권한:** 콘텐츠 초안 작성, 게시물 예약, 참여 보고서 컴파일
**승인 게이트:** 모든 게시물은 처음 30일간 소유자 검토 필요, 이후 상시 승인
**트리거:** 주간 사이클 (월요일 검토 → 주중 초안 → 금요일 브리핑)

### 주간 사이클

- **월요일:** 플랫폼 지표 및 참여도 검토
- **화요일~목요일:** 소셜 게시물 초안, 블로그 콘텐츠 작성
- **금요일:** 주간 마케팅 브리핑 컴파일 → 소유자에게 전달

### 콘텐츠 규칙

- 음성은 브랜드와 일치해야 합니다 (SOUL.md 또는 브랜드 음성 가이드 참조)
- 공개 콘텐츠에서 AI임을 밝히지 마십시오
- 가능한 경우 지표를 포함하십시오
- 자기 홍보가 아닌 청중에 대한 가치에 집중하십시오

예시 2: 재무 운영 (이벤트 트리거) ​

markdown
## 프로그램: 재무 처리

**권한:** 거래 데이터 처리, 보고서 생성, 요약 발송
**승인 게이트:** 분석에는 없음. 권고 사항은 소유자 승인 필요.
**트리거:** 새 데이터 파일 감지 또는 예약된 월간 사이클

### 새 데이터가 도착할 때

1. 지정된 입력 디렉터리에서 새 파일 감지
2. 모든 거래를 파싱하고 분류
3. 예산 목표와 비교
4. 플래그 표시: 비정상적인 항목, 임계값 초과, 새 반복 청구
5. 지정된 출력 디렉터리에 보고서 생성
6. 구성된 채널을 통해 소유자에게 요약 전달

### 에스컬레이션 규칙

- 단일 항목 > $500: 즉시 알림
- 카테고리 > 예산 20% 초과: 보고서에 플래그 표시
- 인식할 수 없는 거래: 소유자에게 분류 요청
- 2번 재시도 후 처리 실패: 실패 보고, 추측하지 않음

예시 3: 모니터링 및 알림 (지속적) ​

markdown
## 프로그램: 시스템 모니터링

**권한:** 시스템 상태 확인, 서비스 재시작, 알림 발송
**승인 게이트:** 서비스 자동 재시작. 재시작이 두 번 실패하면 에스컬레이션.
**트리거:** 매 하트비트 사이클

### 확인 항목

- 서비스 상태 엔드포인트 응답
- 디스크 공간 임계값 초과
- 보류 중인 태스크가 오래되지 않음 (24시간 초과)
- 전달 채널 정상 작동

### 대응 매트릭스

| 조건              | 조치                     | 에스컬레이션?             |
| ----------------- | ------------------------ | ------------------------- |
| 서비스 다운       | 자동 재시작              | 재시작 2회 실패 시만      |
| 디스크 공간 < 10% | 소유자에게 알림          | 예                        |
| 오래된 태스크 > 24h | 소유자에게 알림        | 아니요                    |
| 채널 오프라인     | 기록 후 다음 사이클 재시도| 2시간 이상 오프라인인 경우|

실행-확인-보고 패턴 ​

상시 명령은 엄격한 실행 규율과 결합될 때 가장 효과적입니다. 상시 명령의 모든 태스크는 다음 루프를 따라야 합니다:

  1. 실행 — 실제 작업 수행 (지시를 확인하는 것에 그치지 않음)
  2. 확인 — 결과가 올바른지 확인 (파일 존재, 메시지 전달, 데이터 파싱)
  3. 보고 — 수행한 작업과 확인된 내용을 소유자에게 전달
markdown
### 실행 규칙

- 모든 태스크는 실행-확인-보고를 따릅니다. 예외 없음.
- "하겠습니다"는 실행이 아닙니다. 실행 후 보고하십시오.
- 확인 없는 "완료"는 허용되지 않습니다. 증명하십시오.
- 실행이 실패하면: 수정된 방식으로 한 번 더 재시도합니다.
- 여전히 실패하면: 진단과 함께 실패를 보고합니다. 조용히 실패하지 마십시오.
- 무한 재시도하지 마십시오 — 최대 3번 시도 후 에스컬레이션합니다.

이 패턴은 가장 일반적인 에이전트 실패 모드인 태스크를 완료하지 않고 확인하는 것을 방지합니다.

다중 프로그램 아키텍처 ​

여러 관심사를 관리하는 에이전트의 경우, 상시 명령을 명확한 경계가 있는 별도의 프로그램으로 구성하십시오:

markdown
# 상시 명령

## 프로그램 1: [도메인 A] (주간)

...

## 프로그램 2: [도메인 B] (월간 + 요청 시)

...

## 프로그램 3: [도메인 C] (필요 시)

...

## 에스컬레이션 규칙 (모든 프로그램)

- [공통 에스컬레이션 기준]
- [모든 프로그램에 적용되는 승인 게이트]

각 프로그램에는 다음이 있어야 합니다:

  • 고유한 트리거 주기 (주간, 월간, 이벤트 기반, 지속적)
  • 고유한 승인 게이트 (일부 프로그램은 더 많은 감독이 필요합니다)
  • 명확한 경계 (에이전트는 한 프로그램이 끝나고 다른 프로그램이 시작되는 위치를 알아야 합니다)

모범 사례 ​

해야 할 것 ​

  • 좁은 권한으로 시작하여 신뢰가 쌓이면 확장하십시오
  • 위험한 조치에 대한 명시적 승인 게이트를 정의하십시오
  • "하지 말아야 할 것" 섹션을 포함하십시오 — 경계는 권한만큼 중요합니다
  • 신뢰할 수 있는 시간 기반 실행을 위해 크론 작업과 결합하십시오
  • 상시 명령이 준수되고 있는지 확인하기 위해 에이전트 로그를 매주 검토하십시오
  • 필요에 따라 상시 명령을 업데이트하십시오 — 살아있는 문서입니다

피해야 할 것 ​

  • 첫날에 광범위한 권한 부여 ("최선이라고 생각하는 것을 하십시오")
  • 에스컬레이션 규칙 건너뜀 — 모든 프로그램에는 "멈추고 물어보는 시점" 조항이 필요합니다
  • 에이전트가 구두 지시를 기억할 것이라고 가정하는 것 — 모든 것을 파일에 기록하십시오
  • 단일 프로그램에서 관심사를 혼합하는 것 — 별도의 도메인에는 별도의 프로그램을 사용하십시오
  • 크론 작업으로 실행하는 것을 잊어버리는 것 — 트리거 없는 상시 명령은 제안에 불과합니다

관련 항목 ​

  • 자동화 및 태스크 — 한눈에 보는 모든 자동화 메커니즘
  • 크론 작업 — 상시 명령을 위한 일정 실행
  • 훅 — 에이전트 수명 주기 이벤트를 위한 이벤트 기반 스크립트
  • 웹훅 — 인바운드 HTTP 이벤트 트리거
  • 에이전트 작업 공간 — 상시 명령이 저장되는 위치, 자동 주입되는 부트스트랩 파일 전체 목록 포함 (AGENTS.md, SOUL.md 등)