本地记忆工具

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "mcp-local-memory"]
    }
  }
}

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "mcp-local-memory"],
      "env": {
        "OPENAI_API_KEY": "your-key-here"
      }
    }
  }
}

You: "Remember: I prefer TypeScript over JavaScript"
AI: ✓ Saved in memory

You: "Store key information about this project we just discussed"
AI: ✓ 8 memories saved

You: "What programming language do I prefer?"
AI: [Searches memory] You prefer TypeScript over JavaScript

You: "What's the main Jira Epic for this project?"
AI: [Searches memory] It's [ABC-123](https://example.atlassian.net/browse/ABC-123)

You: "Hey, pls retrieve all the memories we've had about project ABC. Now that 
     there is a clear outline, pls structure them by frontend and backend. 
     Remove redundant memories. If you find conflicting memories -- ask me 
     before proceeding."

AI: [Searches memories for "project ABC"]
    Found 8 memories. I've organized them by adding clear tags:
    
    - 3 memories didn't have tags → added "frontend" tag
    - 4 memories had vague tags → updated to "backend" tag  
    - 1 memory was redundant (duplicate deployment info) → deleted
    
    Now structured as:
    
    Frontend (3 memories):
    - React + TypeScript stack
    - UI design in Figma, link: [...]
    - Deployment: Vercel
    
    Backend (4 memories):
    - Node.js API with Express
    - Database APIs
    - Database performance considerations
    - Hosted on Railway
    - API docs at [...]
    
    ⚠️ Conflict found: Memory bnL9Df8a says backend uses MongoDB, but memory Asq8Y6kq 
    (created recently) mentions CosmosDB. Which is correct?

### Working with Memory

Your memory tool helps maintain context across conversations. Use it thoughtfully:

**When to retrieve from memory:**
- User mentions something that could benefit from past context
- Information from other sources seems incomplete or could be enriched
- You need account IDs, project details, or other recurring facts
- **User gives you a task without full context—search memory to understand connections and background**

**When to update memory:**
- Important facts or connections emerge from the conversation
- Actions or decisions result in changed understanding
- **Project phase transitions** (started → in development → testing → deployed → production)
- **Major milestones reached** (infrastructure deployed, API complete, feature shipped)
- **New features or capabilities added** that weren't in original scope
- **Corrections to outdated information** (especially when you're corrected by the user)
- **Key URLs, endpoints, or deployment locations** discovered or changed
- **Meta-patterns emerge** (e.g., "when user asks X, they typically mean Y" or common workflows/preferences)

**What NOT to store as updates:**
- Incremental progress percentages (40% → 60% done)
- Temporary states that will change soon ("currently debugging X")
- Information already well-captured elsewhere unless it provides quick-reference value
- Minor task status changes within the same phase

**Think of memory as "overall situational awareness":**
- Can we do X? (features/capabilities)
- Where is Y? (URLs, locations, resources)
- What phase is Z in? (not started / active development / testing / production)
- How does A relate to B? (architecture, dependencies, relationships)

If you've already retrieved relevant memories during this conversation, you can update them directly without re-checking. Otherwise, search first to see what exists.

{
  "memory-work": {
    "command": "npx",
    "args": ["-y", "mcp-local-memory"],
    "env": {
      "OPENAI_API_KEY": "your-key",
      "CONTEXT_ID": "work"
    }
  },
  "memory-personal": {
    "command": "npx",
    "args": ["-y", "mcp-local-memory"],
    "env": {
      "OPENAI_API_KEY": "your-key",
      "CONTEXT_ID": "personal"
    }
  }
}

{
  "env": {
    "SQLITE_PATH": "/path/to/your/memory.db"
  }
}