ECHO_CLAW: Context-Driven Game Agent Framework

Introduction

While collaborating with Claude Code on development, I observed an interesting phenomenon: Claude Code doesn't have a complex "cognitive architecture" yet exhibits intelligent behavior. Its core is context management + skill invocation.

This inspired ECHO_CLAW's design: if Claude Code's simple architecture can make AI appear intelligent in programming tasks, can this approach be replicated in game scenarios?

Core Design Philosophy

Bridging Cognitive Science and Engineering Practice

ECHO_feeling adopts a cognitive science architecture (seven-layer cognition, emotional system), which is a theoretical exploration of "intelligence." But theory implementation faces challenges:

1. High Complexity: Each layer requires careful design
2. Difficult Debugging: Emergent behavior is hard to trace
3. Parameter Tuning: PAD/OCC emotional parameters require extensive testing

ECHO_CLAW takes the opposite approach: don't presuppose an intelligence framework, let intelligence emerge from context.

Core Formula

Intelligent Behavior = Rich Context + Complete Skill Library + LLM Reasoning

Here "context" includes:

• Current game state (position, items, surroundings)
• Conversation history (what player said, how AI responded)
• Task context (what's being done, what's been done)
• Available capabilities (what Skills can be invoked)

Analogy with Claude Code

Three-Layer Orchestration Architecture

Architecture Overview

┌─────────────────────────────────────────────────────────────┐
│                     ECHO_CLAW Core Architecture              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐     │
│  │ Fast Reflex │    │LLM Orchest. │    │ Execution   │     │
│  │ (Rule Match)│───▶│(Context Dr.)│───▶│ Engine      │     │
│  └─────────────┘    └─────────────┘    └─────────────┘     │
│         │                  │                  │             │
│         ▼                  ▼                  ▼             │
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐     │
│  │ Emergency   │    │ Skill       │    │ Game        │     │
│  │ Response    │    │ Orchestration│    │ Operations  │     │
│  └─────────────┘    └─────────────┘    └─────────────┘     │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │                 Context Manager                       │   │
│  │  • Current Window (Smart Compression)                 │   │
│  │  • Memory System (Persisted Query)                    │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │                 Tool Registry                         │   │
│  │  Skills(Decision) │ Plugins(Execution) │ MCP(External)│  │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Layer 1: Fast Reflex Layer

Handle emergencies, bypass LLM for direct execution:

interface ReflectionRule {
  trigger: {
    health?: { below?: number; above?: number }
    threat?: 'hostile' | 'neutral' | 'friendly'
    event?: string
  }
  action: () => Promise<void>
  priority: number
}
 
// Example rules
const rules: ReflectionRule[] = [
  {
    trigger: { health: { below: 20 }, threat: 'hostile' },
    action: async () => await bot.pathfinder.flee(hostileEntity),
    priority: 100
  },
  {
    trigger: { event: 'on_fire' },
    action: async () => await bot.equip(waterBucket, 'hand'),
    priority: 90
  }
]

Layer 2: LLM Orchestration Layer

Dynamic decision-making based on context:

interface OrchestrationContext {
  // Game state
  gameState: {
    position: Vec3
    health: number
    inventory: Item[]
    nearbyEntities: Entity[]
  }
 
  // Conversation history (compressed)
  conversationHistory: Message[]
 
  // Current task
  currentTask: Task | null
 
  // Available Skills
  availableSkills: SkillDeclaration[]
}
 
async function orchestrate(context: OrchestrationContext): Promise<ExecutionPlan> {
  // LLM selects and orchestrates Skills based on context
  const prompt = buildOrchestrationPrompt(context)
  const response = await llm.invoke(prompt)
 
  return parseExecutionPlan(response)
}

Layer 3: Execution Engine

Execute operations returned by Skills:

interface ExecutionEngine {
  // Execute plan
  execute(plan: ExecutionPlan): Promise<ExecutionResult>
 
  // Manage Plugin pool
  plugins: Map<string, PluginInterface>
 
  // Action queue
  actionQueue: Action[]
}
 
async function execute(plan: ExecutionPlan): Promise<ExecutionResult> {
  const results: ActionResult[] = []
 
  for (const step of plan.steps) {
    if (step.type === 'parallel') {
      // Parallel execution
      const parallelResults = await Promise.all(
        step.actions.map(a => executeAction(a))
      )
      results.push(...parallelResults)
    } else {
      // Sequential execution
      for (const action of step.actions) {
        results.push(await executeAction(action))
      }
    }
  }
 
  return { results, success: true }
}

Tool System: Three-Way Design

Skill vs Plugin vs MCP

Benefits of this separation:

1. Reusable Skills: Same Skill can be used in different games (e.g., explore-nearby)
2. Replaceable Plugins: Switch games by switching Plugins
3. Extensible MCP: Integrate external knowledge sources (Wiki, maps)

Skill Declaration Specification

Complete Skill declaration includes rich metadata:

interface SkillDeclaration {
  // Basic info
  name: string
  description: string
  version: string
 
  // Interface definition
  input: JSONSchema
  output: JSONSchema
 
  // Trigger conditions
  triggers: {
    keywords?: string[]      // Trigger keywords
    events?: string[]        // Trigger event types
    conditions?: Condition[] // Trigger conditions
  }
 
  // Capability declaration
  capabilities: {
    applicableScenes: string[]  // Applicable scenarios
    outputType: string          // Output type
    collaborationWith: string[] // Skills that can collaborate
  }
 
  // Execution metadata
  execution: {
    costEstimate: number      // Estimated cost (ms)
    reliability: number        // Reliability 0-1
    timeout: number           // Timeout
  }
 
  // Dependencies and conflicts
  dependencies: {
    requires: string[]        // Prerequisites
    conflicts: string[]       // Conflicting skills
    mutex: string[]           // Mutex resources
  }
 
  // Failure recovery
  recovery: {
    retryable: boolean
    fallbackSkill?: string
    rollbackStrategy?: 'none' | 'partial' | 'full'
  }
 
  // Priority
  priority: {
    base: number              // Base priority
    modifiers: {              // Dynamic adjustment factors
      urgency?: number
      relevance?: number
      userPreference?: number
    }
  }
}

Context Management

Dual-Track Design

Smart Compression Strategy

interface CompressionStrategy {
  // Trigger timing
  triggers: {
    taskBoundary: boolean     // Default trigger at task boundary
    thresholdRatio: number    // Force trigger at 80% window
    llmRequest: boolean       // LLM-initiated trigger
  }
 
  // Compression rules
  rules: {
    keep: string[]            // Keep: key decisions, promises, incomplete tasks
    compress: string[]        // Compress: detailed conversations, intermediate steps
    discard: string[]         // Discard: temporary states
  }
}

Game Extension Packs

Progressive Support Levels

Comparison with Other Paths

Current Status

Design phase complete, core architecture documentation produced. Next steps:

1. Create project skeleton
2. Implement core trio: Context Manager, Tool Registry, Execution Engine
3. Develop Minecraft Plugin as first example
4. Write basic Skills
5. Integration testing and iterative optimization

Related Links

• ECHO_feeling Project
• ECHO_loop Project
• MCP Protocol Specification(opens in a new tab)

Last updated: 2026-05-13