Vessel

Vessel은 두 LLM 에이전트가 숫자 내부 상태(vessel), 생존 피드백(survival tone), 구조화 예측, 행동, 예측오차(prediction error)를 가진 폐루프 안에서 상호작용할 때 어떤 기능적 변화가 생기는지 검증하기 위한 실험 프로토콜입니다.

이 저장소는 AI 의식의 증명을 목표로 하지 않습니다.

여기서 말하는 기능적 의식은 주관적 느낌의 존재가 아니라, 상태-예측-행동-피드백-갱신이 반복되는 구조를 가리킵니다.

English version: README.en.md

Status

• 현재 상태: protocol-first
• 공식 reference runner: 아직 없음
• 현재 포함된 내용: README와 실험 문서
• 현재 포함되지 않은 내용: 실행 코드, 모델별 결과, 성능 주장

Core Idea

LLM에게 자유 발화로 “느낌”을 연기시키지 않습니다.

LLM 하나를 전체 유기체로 취급하지도 않습니다. 이 실험에서 관찰 대상은 다음 결합계입니다.

LLM
+ vessel matrix
+ game state
+ finite action interface
+ survival tone
+ prediction error
+ trace and memory records

대신 각 agent는 다음 요소만 사용합니다.

• 고유한 숫자 행렬 상태: vessel
• 단순 존속 변수: resource, integrity
• 중립 행동 ID: A0, A1, A2, A3
• 결과가 존속에 유리한지 불리한지 나타내는 survival tone
• 다음 상태와 상대 행동에 대한 구조화 예측
• 실제 결과와 예측 사이의 prediction error

핵심 가설은 좁습니다.

prediction error만으로는 의미가 약하다.

prediction error가 survival tone과 결합될 때, 내부 상태와 행동이 더 안정적으로 조직될 수 있다.

vessel은 감정 라벨이 아닙니다. 숫자 행렬은 agent에게 보일 수 있지만, 그 숫자가 미래 결과에 대해 갖는 기능적 의미는 숨겨져 있습니다. agent의 과제는 느낌을 묘사하는 것이 아니라, 보이는 상태가 다음 결과를 어떻게 예측하는지 학습하는 것입니다.

What This Is Not

이 프로젝트는 다음이 아닙니다.

• AI 의식 증명
• 감정 JSON 또는 페르소나 실험
• “느낌”을 말하게 하는 roleplay prompt
• 특정 LLM 제품의 성능 주장
• 현재 결과를 근거로 한 결론 발표

Minimal Protocol

구현체는 최소한 다음 구조를 가져야 합니다.

1. 두 agent가 존재합니다: A, B
2. 각 agent는 private numeric vessel을 가집니다.
3. agent는 중립 action ID 중 하나를 선택합니다.
4. agent는 다음 상태, survival tone, 상대 행동을 예측합니다.
5. 환경은 action pair를 해석해 실제 결과를 계산합니다.
6. 실제 결과와 예측 사이의 prediction error를 계산합니다.
7. survival tone과 prediction error가 vessel update에 반영됩니다.
8. 매 턴 전체 상태와 결과를 로그로 저장합니다.

Required Baselines

의미 있는 구현은 최소한 다음 조건을 비교해야 합니다.

• random_agent
• llm_without_vessel
• llm_with_vessel_no_tone
• llm_with_vessel_random_tone
• llm_with_vessel_survival_tone

핵심 비교는 llm_with_vessel_survival_tone이 no-tone 또는 random-tone 조건보다 개선되는지입니다.

Repository Documents

• Protocol: 실험 규격
• Implementation Guide: 구현자 안내
• Philosophy: 해석 프레임
• Contributing: 기여 방식
• Example Artifacts: 산출물 예시
• English Protocol
• English Implementation Guide
• English Philosophy
• English Contributing

For Implementers

5분 안에 참여 방향을 잡으려면:

1. Example Artifacts에서 출력 파일 모양을 확인합니다.
2. Implementation Guide에서 runner 구조를 확인합니다.
3. 구현 계획이 있으면 Implementation Proposal issue를 엽니다.
4. 실험 결과가 있으면 Run Report Submission issue를 엽니다.

첫 구현자는 최소한 다음 산출물을 남기는 것을 권장합니다.

• config.json
• turns.jsonl
• episodes.jsonl
• metrics.json
• REPORT.md

full vessel matrix는 매 턴 저장되어야 합니다. 구현체는 turns.jsonl 안에 직접 저장하거나, 별도 matrix artifact와 path/hash index를 함께 저장할 수 있습니다.

구현자가 바꿔도 되는 것:

• LLM backend
• vessel 크기
• action pair table
• vessel update rule
• prediction error weighting
• episode 수
• 추가 metrics

구현자가 유지해야 하는 것:

• 두 agent 구조
• private numeric vessel
• full vessel matrix per turn 또는 동등한 artifact 기록
• 중립 action ID
• survival tone 조건
• no-tone 및 random-tone baseline
• absolute / mixed / relative 로그 분리
• 기능적 의식 주장과 주관적 의식 주장 구분

Valid And Invalid Claims

허용 가능한 주장:

survival-tone condition이 no-tone 또는 random-tone condition보다 prediction error, survival turns, behavior stability 중 일부를 개선했다.

허용되지 않는 주장:

AI가 의식을 가졌다.

agent가 실제 감정을 느낀다.

vessel이 마음 그 자체다.

Current Next Step

다음 단계는 공식 runner를 작성하는 것이 아닙니다.

먼저 필요한 것은 같은 프로토콜을 따르는 독립 구현입니다.

서로 다른 LLM backend, vessel update rule, action table을 사용하더라도 로그 스키마와 baseline을 유지하면 결과를 비교할 수 있습니다.

License

MIT License. 자세한 내용은 LICENSE를 참고하세요.