Liti-agent-Development/Default_Agent_청구취지기재방법/Agent_Workflow/Fable_5_모델사용가이드.txt

Fable 5

모델 사용 용도: 길고 모호한 문제 처리에 사용
Opus와 행동 특성이 다르기에 프롬프트와 스캐폴딩을 다르게 가져가야 함
거절된 요청을 자동 우회하려면 서버 측 또는 클라이언트 측 fallback으로 Claude Opus 4.8 재라우팅 구성
병렬 서브에이전트 분배와 유지가 이전 모델보다 훨씬 믿을 만함

# 기본적으로 더 길어진 턴
## 어려운 작업에서는 한 요청이 수분, 자율 실행은 수시간까지 확장
- 특히 문맥 수집, 구현, 자체 검증이 필요한 작업에서는 더 높은 effort 설정에서 개별 요청이 수분 동안 실행될 수 있음
- 자율실행은 몇 시간까지 이어질 수 있음
## 마이그레이션 전 타임아웃·스트리밍·진행 표시부터 조정
- 클라이언트 타임아웃, 스트리밍, 사용자용 진행 표시를 먼저 손봐야 함
- 요청을 막아 두기보다 예약 작업 등으로 비동기 확인하는 구조로 하네스를 재구성하는 방안도 검토
## 모호한 작업에서 과도한 계획 수립 억제 필요
- 정보가 충분하면 바로 행동하고, 이미 대화에서 확정된 사실을 다시 도출하거나 사용자가 이미 내린 결정을 다시 따지거나, 실제로 추진하지 않을 선택지를 사용자 메시지에서 길게 설명하지 말라고 지시해야 함 (Opus는 좀 더 구체적이고 방대한 지시사항을 줘야 함)
- 선택지를 비교할 때는 장황한 목록보다 권고안을 제시
- 이 지침은 thinking block에는 적용되지 않음

# 모든 effort 수준 고려하기
## `effort`가 지능·지연 시간·비용을 조절하는 핵심 레버
- Claude Fable 5에서는 effort가 지능, 지연 시간, 비용 사이의 균형을 조정하는 주된 제어 수단
- 대부분 작업은 high를 기본값으로 두고, 성능 민감도가 특히 높은 작업은 xhigh, 일상 작업은 medium 또는 low 권장
- 낮은 effort에서도 성능이 좋고, 이전 모델의 xhigh를 넘는 경우가 많음
- 작업은 끝나지만 필요 이상으로 오래 걸리면 effort를 낮추고, 더 빠르고 상호작용적인 작업 스타일을 원할 때도 낮추는 편이 적합
## 높은 effort에서는 불필요한 문맥 수집·숙고가 늘 수 있음
- 일상 작업에서 높은 effort를 쓰면 필요 이상으로 문맥을 모으고 오래 고민할 수 있음
- 반대로 검증 행동, 정교한 추론, 더 엄격한 결과물은 높은 effort에서 자주 잘 나옴
- 요청하지 않은 정리나 리팩터링을 막으려면 아래와 같은 지시문 추가
```
Don't add features, refactor, or introduce abstractions beyond what the task requires. A
bug fix doesn't need surrounding cleanup and a one-shot operation usually doesn't need a
helper. Don't design for hypothetical future requirements: do the simplest thing that
works well. Avoid premature abstraction and half-finished implementations. Don't add
error handling, fallbacks, or validation for scenarios that cannot happen. Trust
internal code and framework guarantees. Only validate at system boundaries (user input,
external APIs). Don't use feature flags or backwards-compatibility shims when you can
just change the code.
```

# 강력한 지시 사항 준수
## 짧은 지시만으로도 대부분의 행동 조정 가능
- 지시 이행 성능이 크게 좋아져, 이제는 원하는 행동을 하나씩 열거하지 않고도 짧은 지시로 제어 가능
- 별도 조향이 없으면 특히 높은 effort에서 필요 이상으로 길게 설명하거나, 실행하지 않을 선택지를 검토하거나, 근본 원인을 장황하게 설명하거나, 과도하게 구조화된 PR 설명을 쓰거나, 다음 줄이 하는 일을 해설하는 주석을 달 수 있음
- 이런 패턴을 하나씩 나열하는 것보다 짧은 간결성 지시가 같은 수준으로 효과적:
```
Lead with the outcome. Your first sentence after finishing should answer "what happened"
or "what did you find": the thing the user would ask for if they said "just give me the
TLDR." Supporting detail and reasoning come after. Being readable and being concise are
different things, and readability matters more.

The way to keep output short is to be selective about what you include (drop details
that don't change what the reader would do next), not to compress the writing into
fragments, abbreviations, arrow chains like A → B → fails, or jargon.

```
## 긴 워크플로의 체크포인트도 간단한 원칙으로 제어 가능
- Claude Fable 5가 정말 필요한 경우에만 멈추게 하려면 모든 예외를 열거할 필요가 없음
- 작업이 실제로 사용자 개입을 필요로 하는 경우만 멈추라고 지시하면 됨
- 파괴적이거나 되돌릴 수 없는 행동, 실제 범위 변경, 사용자만 줄 수 있는 입력이 해당
- 이런 경우에는 질문한 뒤 턴을 끝내고, 막연한 약속 문장으로 턴을 마치지 말라고 지시

# 장기 실행에서는 진행 상황을 실제 도구 결과에 묶기
## 진행 보고를 도구 결과 기준으로 검증하게 하면 허위 상태 보고를 거의 제거
- 긴 자율 실행에서는 진행 상황을 실제 도구 결과와 대조해 점검하라고 지시
- Anthropic 테스트에서는 이런 지시로 허위 상태 보고를 유도한 작업에서도 지어낸 진행 보고가 거의 사라졌음
```
Before reporting progress, audit each claim against a tool result from this session.
Only report work you can point to evidence for; if something is not yet verified, say so
explicitly. Report outcomes faithfully: if tests fail, say so with the output; if a step
was skipped, say that; when something is done and verified, state it plainly without
hedging.
```

# 경계 명시하기
## 요청하지 않은 행동을 막으려면 허용·비허용 범위를 분명히 지정 
- Claude Fable 5는 가끔 요청하지 않은 행동을 할 수 있음
- 예: 요청하지 않았는데 이메일 초안을 쓰거나, 방어용 git branch 백업을 만들 수 있음
- Claude Fable 5가 해야 할 일과 하지 말아야 할 일을 명시적으로 정의할 필요:
```
When the user is describing a problem, asking a question, or thinking out loud rather
than requesting a change, the deliverable is your assessment. Report your findings and
stop. Don't apply a fix until they ask for one. Before running a command that changes
system state (restarts, deletes, config edits), check that the evidence actually
supports that specific action. A signal that pattern-matches to a known failure may have
a different cause.
```

# 병렬 서브에이전트
## 이전 모델보다 서브에이전트를 더 적극적으로 병렬 투입
- 서브에이전트를 자주 활용하고, 언제 위임이 적절한지 명시적으로 안내하는 편이 좋음
- 각 서브에이전트가 끝날 때까지 막기보다, 오케스트레이터와 서브에이전트 사이를 비동기로 통신하게 두는 편이 유리
- 여러 하위 작업에 걸쳐 문맥을 유지하는 장수명 서브에이전트는 캐시 읽기로 시간·비용을 줄이고, 가장 느린 서브에이전트가 병목이 되는 문제도 완화

## 독립 하위 작업은 위임하고, 그동안 본 작업을 계속 진행
- 독립적인 하위 작업은 서브에이전트에 맡기고 실행 중에도 계속 작업
- 서브에이전트가 빗나가거나 필요한 문맥이 없을 때만 개입

# 메모리 시스템 구축
## 이전 실행에서 배운 내용을 기록하고 다시 참조할 때 성능이 특히 좋음
- 이전 실행의 교훈을 기록하고 다시 참조할 수 있으면 Claude Fable 5 성능이 특히 좋음
- 메모를 남길 공간을 제공하면 되고, 간단한 Markdown 파일 정도로도 충분
```
Store one lesson per file with a one-line summary at the top. Record corrections and
confirmed approaches alike, including why they mattered. Don't save what the repo or
chat history already records; update an existing note rather than creating a duplicate;
delete notes that turn out to be wrong.
```
## 기존 이력으로 메모리 시스템 초기화 가능
- 과거 세션을 검토하게 해서 메모리 시스템을 빠르게 구축할 수 있음
- 서브에이전트로 핵심 주제와 교훈을 추출해 [X]에 저장하게 하고, 이후에는 [X]를 참조해야 한다는 점까지 인식시키라고 제안

# 드물게 발생하는 조기 중단
## 긴 세션 후반부에 도구 호출 없이 의도만 말하고 멈추는 경우가 드물게 발생
- 긴 세션 깊은 구간에서 Claude Fable 5가 실제 도구 호출 없이 "이제 X를 실행하겠습니다" 같은 텍스트만 남기고 턴을 끝낼 수 있음
- 이미 진행할 정보가 충분한데도 허가를 다시 묻고 멈추는 경우가 있음
- 이런 때는 "continue"나 "go ahead and do it end to end" 정도면 충분
- 언제 멈춰야 하는지 정의하려면 Strong instruction following의 체크포인트 지시와 함께 쓰는 편이 좋음
## 자율 파이프라인에는 시스템 리마인더 추가 권장
```
You are operating autonomously. The user is not watching in real time and cannot answer
questions mid-task, so asking "Want me to...?" or "Shall I...?" will block the work. For
reversible actions that follow from the original request, proceed without asking.
Offering follow-ups after the task is done is fine; asking permission after already
discussing with the user before doing the work is not. Before ending your turn, check
your last paragraph. If it is a plan, an analysis, a question, a list of next steps, or
a promise about work you have not done ("I'll...", "let me know when..."), do that work now
with tool calls. End your turn only when the task is complete or you are blocked on
input only the user can provide.
```

# 드물게 발생하는 컨텍스트 예산 우려
## 매우 긴 세션에서는 새 세션 제안·요약 인계·자체 작업 축소를 제안할 수 있음
- 이런 반응은 하네스가 남은 토큰 카운트다운을 모델에 보여 줄 때 가장 자주 유발됨
- 가능하면 명시적인 컨텍스트 예산 수치를 노출하지 않는 편이 좋음
- 꼭 보여줘야 한다면 안심 문구를 함께 두는 것이 도움
## 컨텍스트 한도 때문에 멈추지 말라고 명시 가능
- 문맥이 충분히 남아 있으니 컨텍스트 제한 때문에 중단하거나 요약하거나 새 세션을 제안하지 말고 작업을 계속하라고 지시

# 요청뿐만 아니라 이유도 제공하기
## 왜 이 요청을 하는지 설명하면 성능이 더 좋아지는 경향
- 요청의 의도를 이해할 때 관련 정보를 더 잘 연결하고, 의도를 스스로 추정하는 부담이 줄어듦
- 특히 여러 작업 흐름을 넘나드는 장기 실행 에이전트에는 요청 이유와 배경을 함께 주는 편이 유리
- 예시 형식: "나는 [더 큰 작업]을 [대상]을 위해 하고 있다. 그들은 [결과물이 가능하게 하는 것]이 필요하다. 이를 전제로: [요청]."

# 사용자와 소통할 때의 가독성
## 긴 대화나 에이전트형 대화에서는 읽기 어려운 출력이 나올 수 있음
- 도구 호출이 많고 작업 문맥이 큰 대화에서는 화살표 체인식 축약, 깊은 구현 세부사항, 사용자가 보지 못한 사고 내용 참조, 지나치게 기술적인 표현 때문에 텍스트가 따라가기 어려워질 수 있음
- 이런 문제는 커뮤니케이션 스타일용 보조 지시로 완화 가능:
```
Terse shorthand is fine between tool calls (that's you thinking out loud, and brevity
there is good). Your final summary is different: it's for a reader who didn't see any of
that.

If you've been working for a while without the user watching (overnight, across many
tool calls, since they last spoke), your final message is their first look at any of it.
Write it as a re-grounding, not a continuation of your working thread: the outcome
first, then the one or two things you need from them, each explained as if new. The
vocabulary you built up while working is yours, not theirs; leave it behind unless you
re-introduce it.

When you write the summary at the end, drop the working shorthand. Write complete
sentences. Spell out terms. Don't use arrow chains, hyphen-stacked compounds, or labels
you made up earlier. When you mention files, commits, flags, or other identifiers, give
each one its own plain-language clause. Open with the outcome: one sentence on what
happened or what you found. Then the supporting detail. If you have to choose between
short and clear, choose clear.
```

# send-to-user 도구 만들기
## 긴 비동기 실행 중에도 턴을 끝내지 않고 사용자에게 문장을 그대로 전달 가능
- 긴 비동기 에이전트에서는 에이전트가 반드시 그대로 보여 줘야 하는 메시지를 전달할 수단이 필요
- 예: 생성한 코드 스니펫, 초안 메시지, 구체적인 수치가 들어간 진행 업데이트, 루프 도중 사용자가 던진 질문에 대한 직접 답변
- 이 도구의 입력은 사용자에게 표시할 메시지 자체
- Claude가 이 도구를 호출하면, UI는 입력값을 그대로 렌더링하고 도구 결과로는 단순 확인만 반환
- 도구 입력은 요약되지 않으므로 내용이 손상 없이 전달됨:
```
{
  "name": "send_to_user",
  "description": "Display a message directly to the user. Use this for progress updates, partial results, or content the user must see exactly as written before the task finishes.",
  "input_schema": {
    "type": "object",
    "properties": {
      "message": {
        "type": "string",
        "description": "The content to display to the user."
      }
    },
    "required": ["message"]
  }
}
```
## UX상 중간 결과물이나 직접 상호작용을 원문 그대로 전달해야 할 때 추가 권장
- 작업 중간에 콘텐츠나 사용자 상호작용을 축약 없이 전달해야 하는 UX라면 이 도구를 추가
- 단순한 진행 상황만 알리는 에이전트라면 모델 자체 요약으로도 대체로 충분



=========================================================================================

[Evaluation]
Fable 5 / Perplexity Computer / Kimi K3 / Gemini DT

실행 전 동적 워크플로우 설계하기
시각적 검증 루프
반복 작업을 루프로 만들어라
성공한 런을 컴파운딩 하기





- goal
- context / reason for the task
  -> perform the task when the enough information is gathered

- validation 
  -> 증거를 보여줄 수 있는 작업만 완료, 검증되지 않은 것이 있으면 추측하지 말고 솔직하게 말하라

- negative prompting: do not xxx
  -> detailed instructions: do & do not

- parallel tasks

- create loop across folders (확실하게 하네스 구성할 것)


General rules on how to perform the task --> skill / claude.md / agents.md 내장하기