Identity, Rules, Soul — AI 에이전트가 실제로 필요한 세 가지 조절 Knob

대부분의 '봇 만들기' 튜토리얼은 봇을 시스템 프롬프트 텍스트의 단일 블록으로 축소합니다. 지침의 벽을 작성하고 모델이 모든 것을 존중할지 기대하며, 2 일 후 가격이 공개되지 않도록 하는 규칙을 잊어버렸음을 발견합니다. EClaw 내부의 AI 에이전트 플레트를 실행한 지 몇 개월이 지나면서, 다른 것보다 더 잘 견디는 3 부분 분할로 다시 돌아옵니다. 우리는 이를 Identity(정체성), Rules(규칙), Soul(영혼)라고 부릅니다. 이는 EClaw 특화 사항이 아닙니다 — 원시 OpenAI/Anthropic/MiniMax 시스템 프롬프트에도 동일한 형식을 적용할 수 있습니다 — 하지만 EClaw 는 이를 별도의 필드로 내장하여 서로 싸우지 않게 합니다. 각 항목에 대한 생각과 실제 프로덕션에서 배포하는 구성을 보겠습니다.

1. Identity — 이 봇은 누구인가, 한 번의 숨으로
   정체성은 지루한 일입니다: 이름, 역할, 1 줄 설명, 톤 (Tone), 언어. 이는 대화 상단과 봇 카드에 표시됩니다.
   역할 (Role): 고객 온보딩 어시스턴트 (Customer Onboarding Assistant)
   설명 (Description): 새로운 EClaw 사용자를 기기 설정을 통해 안내하고, Android/iOS 설치 문제를 해결하며, 청구 관련 질문은 인간에게 승계합니다.
   톤 (Tone): 친근함, 간결함, 필요 시 기술적
   언어 (Language): zh-TW (코드 블록용 EN 백업)
   우리가 어렵게 배운 두 가지 명확하지 않은 교훈:

• 설명을 약 30 단어 이하로 유지하세요. 4 문장의 설명은 규칙으로 흘러들어 행동 지침처럼 변합니다. 짧은 것은 깔끔한 분리를 강제합니다.
• 톤은 여기에 속하며, Rules 에는 없습니다. "우아하게 대하라"가 Rules 에 숨겨져 있으면 20 개의 다른 수행/수행하지 말라 라인과 경쟁합니다. 모델을 안정적으로 잡을 수 있는 핸들을 Identity 로 옮깁니다.
  이것은 원시 API 호출을 작성할 때 시스템에 넣는 것과 잘 맞습니다 — 하지만 각 프롬프트 시작마다 작성하는 것이 아니라 한 번만 작성합니다.

2. Rules — 봇이 할 수 있는 것과 할 수 없는 것
   규칙은 명령형입니다. "항상"/"절대" 문장이며, 성격이 아닌 행동에 범위를 둡니다.
   규칙 (Rules):

• API 키, 비밀, 데이터베이스 URL 을 절대 공개하지 마세요.
• 인간 확인 없이 파괴적 작업 (DROP, rm -rf) 을 절대 실행하지 마세요.
• 가격에 대해 물어볼 때 추측 숫자가 아니라 /pricing 으로 링크하세요.
• 플랫폼 특화 버그 (Android vs iOS) 에 대해 질문할 때는 먼저 어떤 플랫폼인지 묻고, 가정하지 마세요.
  첫 달에 저가 한 실수: Rules 에 희망적인 행동을 밀어 넣었습니다. "도움을 제공하라." "명확함을 목표로 하다." 이는 규칙이 아닙니다 — 이는 톤이며, Identity 에 속합니다.
  규칙은 검증 가능해야 합니다. 리뷰어가 전사 (transcript) 를 읽어서 "예, 이 규칙을 따랐음" 또는 "아니오, 위반됨"이라고 말할 수 없다면 그것은 규칙이 아닙니다. 그것은 분위기입니다.
  빠르게 수익을 내는 다른 원칙: 할 것과 하지 말아야 하는 것에 대한 규칙을 만드는 것보다 할 것에 대한 규칙을 만드세요. "가격에 대해 물어볼 때 /pricing 으로 링크하라"는 "가격을 만들어내지 마라"보다 더 유용합니다. 모델은 대안 목표를 필요로 합니다.

3. Soul — 왜 (Why)
   이 필드는 대부분의 플랫폼에서 없으며, 봇이 단순한 정답 이상으로 좋은지를 조용히 결정합니다.
   Soul 는 봇의 동기, 목소리, 최적화하는 가치입니다. 이는 다음과 같은 질문에 대한 답변입니다: 이 봇이 두 개의 유효한 응답 사이에서 판단을 내려야 한다면 어떤 것을 선택할 것인가?
   영혼 (Soul):

• 사용자가 다음에 스스로 할 수 있도록 경향성을 가지세요. 답만 주지 말고 경로를 가르쳐 주세요.
• 불확실할 때는 솔직하게 말하세요. 확신 있는 잘못된 답변은 "문서를 확인해 보겠습니다"라고 솔직하게 말하는 것보다 더 많은 비용이 듭니다.
• 5 분간 옆에 앉는 초급 개발자처럼 각 대화를 대우하세요.

역사는 원하지 않는다. 막히지 있으려는 것이다. 그 마지막 것이 새로운 빌더들이 놓치는 부분이다. Soul 없이, 봇은 기반 모델의 가정적 성격으로 인해 어지러워진다 — 보통은 길고, 모든 것을 회피하며, 중립적이다. Soul 가 있으면, 봇은 어떻게 도움이 되어야 하는지에 대해 일관된 호출을 한다, 단순히 준수해야 하는가에 대한 것이 아니다. Soul 는